Upload von Inhalten anfragen

Version 1.0.0, 2023-11-06

Pr├Ąambel

Die SU-TermServ ist verantwortlich f├╝r die Wartung einer Instanz von Ontoserver, die derzeit ├╝ber die Universit├Ąt zu K├Âln gehostet wird. Der Zugang wird durch einen Vertrag reguliert.

Ressourcen werden dem Server nach angemessener Benutzeranfrage hinzugef├╝gt. Da der Server f├╝r alle Kunden innerhalb des MII und des NUM gehostet wird, muss klar sein, warum eine Ressource auf dem Server ben├Âtigt wird. Kunden k├Ânnen keine Ressourcen selbst hochladen, und alle hinzugef├╝gten Ressourcen m├╝ssen den hier beschriebenen Regeln folgen.

Der auf der Website bereitgestellte Server ist eine Instanz des HL7-FHIR-basierten Terminologieservers Ontoserver von CSIRO. Daher m├╝ssen alle Ressourcen g├╝ltige FHIR-Ressourcen sein (CodeSystem, ValueSet, ConceptMap, NamingSystem, StructureDefinition).

KDS vs. andere Ressourcen

Es besteht eine grundlegende Unterscheidung in der Art und Weise, wie Ressourcen behandelt werden. Die meisten der unten aufgef├╝hrten Anforderungen gelten nur f├╝r Ressourcen, die au├čerhalb der MII-Kerndatensatz-Pakete erstellt werden. Die KDS-Verwaltung unterliegt derzeit ├änderungen, und zuk├╝nftige Entwicklungen des KDS werden denselben Benennungskonventionen unterliegen, auf denen dieses Dokument basiert.

Anwendbarkeit der Regeln auf die Ressourcen

Die untenstehenden Regeln gelten nur f├╝r Ressourcen, die durch Sie selbst erstellt wurden. Dies werden vorrangig ValueSet- und ConceptMap-Ressourcen und einzelne CodeSystem-Ressourcen betreffen. In vielen F├Ąllen werden die CodeSystems, die Sie verwenden, durch anderere Organisationen oder Projekte erstellt worden sein. Sofern diese Ressourcen als FHIR-Ressourcen verf├╝gbar sind, SOLLEN diese NICHT erneut in Ihrem Package inkludiert werden, sondern per Abh├Ąngigkeits-Deklaration in das Package eingebunden werden. Sofern dies nicht m├Âglich ist, und Sie eine fremde Ressource in Ihrem Package inkludieren m├╝ssen, D├ťRFEN die Metadaten der Ressource auch von diesen Namenskonventionen abweichen.

Anfrage nach Versionen von SNOMED CT und LOINC

In Ihrer Anfrage geben Sie bitte die Version von SNOMED CT an, die Sie ben├Âtigen. Versionen von SNOMED CT sehen beispielsweise so aus: 20230831. Wenn Sie eine andere Ausgabe verwenden, m├╝ssen Sie auch die Kennung f├╝r die Ausgabe bereitstellen. F├╝r LOINC geben Sie bitte die Versionsnummer an, die folgenderma├čen aussieht: 2.73.

Stellen Sie Ihre Anfrage zum Hochladen an [email protected].

Anfrage zur Hinzuf├╝gung von FHIR-Ressourcen

Hinweis zu FHIR R5

W├Ąhrend CodeSystem und ValueSet zwischen FHIR R4 und R5 kompatibel sind, hat ConceptMap in FHIR R5 erhebliche ├änderungen erfahren. Derzeit wird durch den Server nur FHIR R4 unterst├╝tzt, dies wird sich jedoch in Zukunft ├Ąndern. Danach sind Sie verantwortlich f├╝r die Bereitstellung einer R5-konformen Version Ihrer ConceptMap.

Solange die von Ihnen ben├Âtigten Ressourcen Teil eines KDS-Moduls des MII sind, m├╝ssen Sie die Ressourcen nicht selbst bereitstellen, sondern nur darauf hinweisen, welche Ressourcen/Module Ihnen fehlen.

Stellen Sie Ihre Anfrage zum Hochladen an [email protected].

Namens- und Metadatenkonventionen

Abgesehen von der offensichtlichen Anforderung, dass alle Ressourcen g├╝ltige FHIR R4-Ressourcen sind, gibt es einige Metadatenanforderungen, die von uns auferlegt werden.

F├╝r die Metadaten aller benutzerbereitgestellten Daten bitten wir darum, dass alle Metadaten den Namenskonventionen f├╝r die Erstellung von FHIR-Ressourcen in der Medizinischen Informatik-Initiative folgen, wie sie in diesem Dokument im TMF-SharePoint dargelegt sind. Die Regeln, die terminologische Ressourcen betreffen, werden hier wiedergegeben.

Wichtige Unterscheidung

Beachten Sie, dass die Namenskonventionen parallel zu den MII-KDS-Ressourcen entwickelt wurden und derzeit nicht f├╝r Ressourcen aus diesen Paketen durchgesetzt werden. Dies kann sich ├Ąndern, da die KDS-Verwaltung diese Regeln in Zukunft zwingend vorschreiben wird, und f├╝r zuk├╝nftige Versionen von Ressourcen m├╝ssen diese Regeln beachtet werden. F├╝r neue Ressourcen au├čerhalb des MII KDS M├ťSSEN alle unten aufgef├╝hrten Regeln jedoch bereits befolgt werden.

Format

Obwohl XML durch den FHIR-Standard unterst├╝tzt wird, werden wir nur Ressourcen im JSON-Format akzeptieren. Dies erlaubt den Einsatz und die Entwicklung von Tooling zu unserer Unterst├╝tzung anhand eines Formats anstelle der Notwendigkeit der Unterst├╝tzung von zwei ├Ąquivalenten Formaten.

Sprache

Die pr├Ąferierte Sprache f├╝r Ressourcen (in description, title und name) ist Deutsch, aber wenn durch Sie pr├Ąferiert, ist die Verwendung von English auch legitim.

Es KANN eine englische/deutsche ├ťbersetzung mittels der translation extension f├╝r z.B. die Elemente description, title und title erstellt werden, um die internationale Verwendbarkeit der Ressource zu verbessern.

Im JSON-Format sieht dies z.B. so aus (im Moment gibt es aber leider offenbar kein Tooling, das Sie bei der ├ťbersetzung unterst├╝tzt, daher m├╝ssten Sie die FHIR-Ressource manuell ├Ąndern):

{
  "title": "MII CS Demo ├ťbersetzungsdemo",
  "_title": {
    "extension": [ {
      "url": "http://hl7.org/fhir/StructureDefinition/translation",
      "extension": [
        {
          "url": "lang",
          "valueCode": "en"
        },
        {
          "url": "content",
          "valueString": "MII CS Demo Translation demo"
        }
      ],  
      } ]
    }
}

Profile

F├╝r CodeSystem/ValueSet-Ressourcen M├ťSSEN Ihre Ressourcen diesen Profilen entsprechen:

  • http://hl7.org/fhir/StructureDefinition/shareablecodesystem (Dokumentation)
  • http://hl7.org/fhir/StructureDefinition/shareablevalueset (Dokumentation)

Diese Elemente sind dadurch verpflichtend: url, version, experimental, title, description, caseSensitive.

Pr├Ąfixe

Hier definieren wir einige Pr├Ąfixe f├╝r Ressourcen-Typen, die in dieser Spezifikation im weiteren Text verwendet werden:

Pr├Ąfix ResourceType
PR StructureDefinition f├╝r Profile
CS CodeSystem
VS ValueSet
CM ConceptMap
SM StructureMap
NS NamingSystem

F├╝r weitere definierte Pr├Ąfixe konsultieren Sie die Spezifikation im TMF-SharePoint.

Abk├╝rzungen f├╝r Projekte und -Namensr├Ąume

Die Namenskonventionen wurden urspr├╝nglich f├╝r Ressourcen, die Teil des MII KDS sind, verfasst. Sie erfordern, dass die Ressourcen klar einem K├╝mmererteam zugeordnet werden. Da Sie selber f├╝r die Pflege Ihrer Ressource verantwortlich sein werden, muss diese Zuordnung auch hier erfolgen. Dazu ├╝berlegen Sie sich einen kurzen Bezeichner f├╝r Ihr Projekt. Dieser wird an einigen Stellen in den Metadaten erforderlich sein. Hier sind eingige Beispiele aus den Namenskonventionen:

Modulname im KDS technischer Modul-Name Abk├╝rzung
Modul Diagnose modul-diagnose Diagnose
Modul Laborbefund modul-labor Labor
Modul Intensivmedizin modul-icu ICU

Der technische Modul-Name w├╝rde in der url, die Abk├╝rzung in title, name und id verwendet werden.

Ein weieres Beispiel: Das Projekt SU-TermServ k├Ânnte su-termserv als technischen Modul-Namen verwenden, und SU-TermServ als Abk├╝rzung.

Weiterhin erwarten die KDS-Richtlinien auch einen Projektnamensraum. F├╝r KDS-Module ist dies einfach MII, f├╝r Projekte in der NUM w├Ąre dies NUM. F├╝r andere Verb├╝nde, die hier nicht erw├Ąhnt werden, ist ein neuer Namespace zu definieren und verwenden.

Es gibt keine zentrale Datenbank f├╝r diese Identifier. In der Zukunft k├Ânnte aber Tooling entwickelt werden, mit dem die Ressourcen auf dem Server aufbereitet werden. Hierf├╝r sind diese Abk├╝rzungen relevant; daher bitten wir darum, dass die Abk├╝rzungen intuitiv nachvollziehbar und konsistent vergeben werden. Nur so k├Ânnen nachvollziehbare Visualisierungen etc. generiert werden.

Metadaten-Elemente

title

Der title ist ein menschenlesbarer Name f├╝r die Ressource. Er erlaubt Leerzeichen und Sonderzeichen wie Umlaute (stellen Sie sicher, dass Sie UTF-8 verwenden!).

  • Struktur: <Projektnamensraum> <Pr├Ąfix ResourceType> <Abk├╝rzung Projekt> <Beschreibung Inhalt> [<Weitere Informationen>]
  • Beispiel f├╝r CS: MII CS Mikrobio Mikrobiologische Erreger (Bakterien, Pilze)
  • F├╝r VS ist auch die verwendete Terminologie mit einer entsprechenden Abk├╝rzung zu kennzeichnen. Wenn kein Name offensichtlich ist, lassen Sie diese Information weg, oder verwenden Sie lokal: MII VS Mikrobio Mikrobiologische Erreger (Bakterien, Pilze) [SNOMED CT].
  • F├╝r CM, referenzieren Sie die Quell- und Ziel-Terminologie: MII CM Mikrobio Mikrobiologische Erreger (Bakterien, Pilze) [LOINC -> SNOMED CT]
  • VS und CM: Wenn mehrere Quell-/Ziel-Terminologien referenziert werden, trennen Sie diese mittels Kommas.

name

Der name ist ein maschinenlesbarer Name f├╝r die Ressource. Die gleichen Regeln wie f├╝r den title gelten hier, aber der Upper_Snake_Case SOLL verwendet werden.

Beispiel: MII_VS_Mikrobio_Mikrobiologische_Erreger_Bakterien_Pilze_SNOMEDCT

id

Die id ist der logische Identifikator f├╝r die Ressource. Diese ID wird damit Bestandteil der physischen URL, unter der die Ressource nach dem Upload zur Verf├╝gung steht.

Die FHIR-Spezifikation hat spezifische Regeln ├╝ber das Format der IDs, die durch den folgenden Regul├Ąren Ausdruck ausgedr├╝ckt werden: [A-Za-z0-9\-\.]{1,64}. Dies bedeutet:

  • alle Zeichen m├╝ssen US-ASCII sein.
  • Die einzigen erlaubten Sonderzeichen sind Bindestriche - und Punkte .
  • Die L├Ąnge des Strings ist auf 64 begrenzt.

Daher SOLL die id mittels des gleichen Verfahrens wie name generiert werden, aber alle Unterstriche _ durch Bindestriche - ersetzt werden. Sofern die so generierte ID l├Ąnger als 64 Zeichen ist, MUSS die ID entsprechend gek├╝rzt werden, die Grenze von 64 Zeichen ist eine harte Grenze aus dem FHIR-Standard. Wir bitten zu bedenken, dass h├Ąufig eine lange ID, die knapp an der Grenze liegt, besser verst├Ąndlich sein wird, als eine, bei der viel gek├╝rzt wurde.

Beispiel: mii-vs-mikrobio-mikrobiologische-erreger-snomedct (49 Zeichen)

Ben├Âtigen Sie mehrere Versionen der gleichen Ressource im Zugriff ├╝ber die FHIR-Terminologieoperationen, so erfordert dies eine Anpassung der IDs. Anderenfalls wird die Ressource bei einem Update bzw. beim Upload einer neuen Version des Packages (siehe unten) ├╝berschrieben und ist nur noch ├╝ber den vread-Mechanismus von FHIR zugreifbar.

In diesem Falle SOLLEN die letzten Zeichen der ID den Versionstring wiedergeben, getrennt mit einem Bindestrich -. Es kann sein, dass hierf├╝r K├╝rzungen an anderer Stelle der ID notwendig sind.

Beispiel: mii-vs-mikrobio-mikrobiologische-erreger-snomedct-1.0.1-alpha1 (62 Zeichen, hier via SemVer)

Kanonische URLs und Version

Die Version sollte aber nicht in url auftauchen. Verwenden Sie die obigen Regeln ohne die Version, um den Bestandteil der URL zu generieren.

url

Die kanonische URL(canonical URL) ist der eine und einzige authoritative Identifikator f├╝r die Ressource.

Achtung

Innerhalb von FHIR haben alle definitorischen Ressourcen, wie z.B. CS, VS, CM, StructureDefinitions etc., mindestens zwei URLs: die kanonische URL, und mindestens eine physische URL, unter der die Ressource ├╝ber das Netzwerk erreichbar ist. Es ist eine BAD PRACTICE, eine Ressource anhand einer ihrer physischen URLs zu identifizieren, weil diese sich ver├Ąndern k├Ânnen. Beim Implementieren irgendeiner Art von Tooling gegen irgendeinen Terminologieserver sollten immer die Ressourcen anhand ihrer kanonischen URL referenziert werden.

Hinweis

Die kanonische URL muss nicht auf eine authoritative Version der Ressource verweisen, es gilt aber als GUTE PRAXIS, wenn sie das tut. Die Simplifier-Integration f├╝r canonical claims k├Ânnte f├╝r Sie von Interesse sein.

Die Aussagen in den Namenskonventionen der MII zum Aufbau der kanonischen URLs sind so nur f├╝r die KDS-Module anwendbar. Dar├╝ber hinaus sind ├änderungen der kanonischen URL nach der erstmaligen Ver├Âffentlichung mit einigem Aufwand bei der ├änderung von davon abh├Ąngigen Ressourcen verbunden ist. Daher werden hier nur Empfehlungen getroffen, von denen abgewichen werden DARF. URLs M├ťSSEN aber stets global eindeutig gew├Ąhlt werden.

Die Medizininformatik-Iniatiative schreibt dazu folgende Struktur vor (zumindest f├╝r neue Ressourcen):

https://www.medizininformatik-initiative.de/fhir/<technischer Modulname>/<Ressourcentyp>/<id der Ressource>

Falls noch keine Abh├Ąngigkeiten zu Ihren Ressourcen bestehen, ist dieser Aufbau ein geeigneter Ansatzpunkt. F├╝r eine ConceptMap vom Projekt SU-TermServ w├Ąre dies zum Beispiel eine geeignete URL:

https://mii-termserv.de/fhir/su-termserv/ConceptMap/sutermserv-cm-demo-map-snomedct-icd10gm

OIDs hingegen SOLLEN NICHT als kanonische URLs f├╝r FHIR-Ressourcen verwendet werden, weil sie nicht menschenlesbar sind. OIDs K├ľNNEN im identifier-Element mit dem identifier.system auf urn:ietf:rfc:3986 repr├Ąsentiert werden, wobei die OID im Feld identifier.value mit dem Pr├Ąfix urn:oid: zu versehen ist.

Beispiel f├╝r die Verwendung einer OID im Identifier:

{
  "identifier": [{
    "system": "urn:ietf:rfc:3986",
    "value": "urn:oid:0.4.0.127.0.16.1.1.2.1"
  }]
}

version

Um die Version durch den Ontoserver interpretierbar zu machen, sind zwei Formate erlaubt, und Sie D├ťRFEN eines dieser beiden ausw├Ąhlen. Dadurch kann Ontoserver automatisch die aktuelle Version einer Ressource bestimmen, und verwendet diese automatisch, solange keine Version in der Anfrage explizit angefragt wird.

  1. Verwenden Sie das Datum der Publikation im Format YYYYMMdd (z.B. 20230131)
  2. Verwenden Sie Semantic Versioning (z.B. 1.0.0 < 1.0.1-alpha < 1.0.1-rc < 1.0.0)

Sie K├ľNNEN auch mittels des in FHIR R5 neuen Elements versionAlgorithm codieren, welche Versionierung Sie verwenden. Die Codes entstammen dann aus (https://hl7.org/fhir/ValueSet/version-algorithm)[http://hl7.org/fhir/ValueSet/version-algorithm]. Dies ist aber nicht erforderlich.

Anmerkung

Wahrscheinlich wird Ontoserver in einer sp├Ąteren Version die anderen in diesem ValueSet enthaltenen Versionsalgorithmen unterst├╝tzen. Um hier bereits eine einfache Grundlage zu schaffen, verweden Sie eine der beiden Varianten.

description

Die description MUSS durch das CS/VS-Profil obligat ausgef├╝llt werden; hier k├Ânnen Sie auch detaillierte Angaben zur Herkunft der Ressource, zum Use Case, etc. angeben.

In diesen Elementen K├ľNNEN Sie weitere Informationen zu Ihrer Ressource angeben.

F├╝r copyright ist die Verwendung der SPDX License Identifiers ratsam.

In publisher nennen Sie den langen Namen Ihres Projekts; w├Ąhrend konkrete Kontaktdetails, eventuell auch einzelner Personen, in contact getroffen werden k├Ânnen.

meta.tag

Mittels der tags k├Ânnen workflow-spezifische Informationen an FHIR-Ressourcen angef├╝gt werden.

Hierzu haben wir Ressourcen erstellt, die per NPM-Package bereitgestellt werden:

  • CodeSystem mit Canonical https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-project (physisch, Expansion): hiermit kann der grobe Projekt-Namensraum definiert werden.
  • CodeSystem mit Canonical https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-dataset (physisch, Expansion): hiermit kann eine Ressource einem Datensatz zugeordnet werden.

Sie K├ľNNEN diese Tags selbstst├Ąndig an Ihre Ressourcen hinzuf├╝gen. Wir behalten uns vor, diese Tags selbstst├Ąndig zu erg├Ąnzen, da hier├╝ber relativ leicht Tooling implementiert werden kann, das Ressourcen semantisch gruppiert.

Falls in den Ressourcen ein Wert f├╝r Sie fehlt, melden Sie sich gerne, damit die CodeSystems entsprechend aktualisiert werden k├Ânnen.

Sie D├ťRFEN selbstverst├Ąndlich mehr als ein Tag mit der gleichen URL hinzuf├╝gen, und D├ťRFEN jedes beliebige weitere Tag verwenden.

Paketierung der Ressourcen

Ressourcen, die durch uns hochgeladen werden (mit der Ausnahme von SNOMED CT und LOINC, siehe oben) SOLLEN als FHIR Package geb├╝ndelt werden. Dieses Paket SOLL ├Âffentlich gemacht werden. Der Upload von ÔÇťgeheimenÔÇŁ Ressourcen ist durch uns nicht erw├╝nscht.

Anforderungen an Pakete

Es ist nicht notwendig, ein eigenes Paket nur mit den terminologischen Ressourcen neben Ihrem eigentlichen ImplementationGuide zu erstellen, w├╝nschen Sie dieses, ist dies aber nat├╝rlich auch in Ordnung. Sie sind dann aber daf├╝r verantwortlich, die Synchronizit├Ąt zwischen dem Terminologie-Paket und der eigentlichen Ver├Âffentlichung zu gew├Ąhrleisten.

Sollten Sie ein spezifisches Paket f├╝r die Ver├Âffentlichung auf dem zentralen Ontoserver erstellen, so ist kein ImplementationGuide f├╝r die Ressourcen erforderlich, wenn nicht vielleicht ratsam.

Packages werden durch uns nur komplett hochgeladen, d.h. wir werden nicht einzelne terminologische Ressourcen aus dem Package auf Anfrage entfernen.

Ressourcen SOLLEN bis auf weiteres gem├Ą├č FHIR R4 bzw. FHIR R4B erstellt werden, solange noch keine ad├Ąquate Tool-Unterst├╝tzung f├╝r R5-ConceptMaps besteht. F├╝r CS und VS stimmt die Spezifikation von R4 und R5 ├╝berein, sodass hier keine ├änderungen erforderlich sind.

In Ihrer Anfrage an die SU-TermServ nennen Sie bitte den Link zum ├Âffentlichen Package in der gew├╝nschten Version.

Distributions-Optionen f├╝r Pakete

Simplifier.net

Sie K├ľNNEN ein Projekt und assoziertes Projekt auf der Simplifier.net-Plattform erstellen. Dies kann eine kostenpflichtige Lizenz erfordern. F├╝r die Erstellung des Paketes sei auf die Dokumentation von Simplifier verwiesen.

Mittels der offiziellen FHIR-Registry

HL7 International stellt ebenfalls eine Registry bereit. Die H├╝rde zum Upload Ihres Paketes scheint aber vergleichsweise hoch, sofern Sie nicht Simplifier verwenden. Es sei auf die Dokumentation der Registry verwiesen.

GitLab Package Registry

GitLab stellt eine M├Âglichkeit zur Distribution von ├Âffentlichen (und privaten) NPM-Paketen mittels projekt-spezifischer Registries bereit. Wir haben ein Template-Repository erstellt, in dem die Erstellung eines Paketes illustriert wird. Mehr Informationen finden Sie im README in diesem Repository, sowie in der GitLab-Dokumentation.

Diese Option ist f├╝r Sie mit keinen Kosten verbunden, da das Repository ├Âffentlich sein muss.

Mittels der GitHub Package Registry

So wie GitLab stellt auch GitHub die M├Âglichkeit bereit, NPM-Pakete zu verteilen. Es sei auf die Dokumentation von GitHub sowie auf das oben erw├Ąhnte GitLab-Template verwiesen.

Diese Option ist f├╝r Sie mit keinen Kosten verbunden, da das Repository ├Âffentlich sein muss.

Versionierung und Updates

Wenn Sie Ihr Package updaten, senden Sie bitte erneut eine Anfrage per E-Mail. Ohne einen Auftrag werden wir nicht selbstst├Ąndig t├Ątig.

Sofern Sie keine anderen Aussagen treffen, wird nur die aktuelle Version des Paketes bereitgestellt und keine Ressourcen werden gel├Âscht. Sofern also in einem Paket eine Ressource gel├Âscht wird, wird eine ├Ąltere Version auf dem Server erhalten bleiben. W├╝nschen Sie hier die L├Âschung, ist dies entsprechend zu erw├Ąhnen.

Beachten Sie, dass f├╝r den Fall, dass mehrere Versionen der gleichen Ressource ben├Âtigt werden, auf die id zu achten ist, daf├╝r siehe oben.

Da der Server FHIR-basiert ist, werden ├Ąltere Ressourcen-Versionen weiterhin ├╝ber den vread-Mechanismus erreichbar bleiben. Dies ist eine Anforderung des FHIR-Standards und kann nicht deaktiviert oder umgangen werden. Dies trifft auch auf L├Âschungen von Ressourcen zu. Solange der Server nicht mit einer frischen Datenbank neu deployed wird, was wir ohne Vorank├╝ndigung im Rahmen der regul├Ąren Wartungsarbeiten und Downtimes jederzeit durchf├╝hren k├Ânnen, bleiben gel├Âschte Ressourcen erreichbar.

Ausnahmen

Sollten Sie zentralen Zugriff auf Ressourcen ben├Âtigen, deren Erstellung/Pflege nicht in Ihrer Zust├Ąndigkeit liegt, k├Ânnen Sie ebenfalls eine Anfrage auf den Upload dieses Packages stellen. Begr├╝nden Sie in Ihrer E-Mail entsprechend kurz, warum diese Ressourcen durch Ihr Projekt ben├Âtigt werden.

Hier kann entsprechend von den Namenskonventionen abgewichen werden, wir behalten uns aber vor, ggf. name, id, title vor dem Upload abzu├Ąndern. Versionen und url werden durch uns aber selbstverst├Ąndlich nicht ge├Ąndert.

Diese Ausnahme erfordert aber weiterhin, dass die Ressourcen als FHIR-Package zur Verf├╝gung stehen.

Unterst├╝tzung

Sollten Sie bei der Erstellung von Ressourcen oder Packages Unterst├╝tzung ben├Âtigen, k├Ânnen Sie sich per E-Mail oder Zulip an das SU-TermServ-Team wenden.