Ballotierung des zentralen MII-Terminologieservers

In den vergangenen Jahren war der zentrale Terminologieserver für die MII, der durch die SU-TermServ betrieben wird, unter der Adresse https://terminology-highmed.medic.medfak.uni-koeln.de/fhir erreichbar. Gestartet hat dieser Server entsprechend aus dem HiGHmed-Projekt. Mit dem Beginn der aktuellen Förderphase der MII im Januar 2023 wurde der Betrieb dieses Server professionalisiert und die Zielgruppe auf die gesamte MII und das NUM ausgeweitet wurde offiziell mittels eines eigenständigen 2b-Projekt verstetigt. Wir freuen uns, dass wir Ihnen unsere Arbeit nun endlich präsentieren können. Mehr Infos zur Ballotierung finden Sie im unteren Bereich dieser Seite.

Fokus

Als Server für die MII ist unser Fokus in der Bereitstellung der für den Kerndatensatz (KDS) benötigten terminologischen Ressourcen. Aktuell stellen wir die stabilen KDS-Module bereit. Darüber hinaus haben wir die Ressourcen, die für eine Implementierung des KDS weiterhin benötigt werden, ebenfalls paketiert. Neben SNOMED CT und LOINC betrifft dies z.B. die Ressourcen, die durch das BfArM bereitgestellt werden, die Ressourcen aus der FHIR-Basis-Spezifikation oder aus , sowie deren Abhängigkeiten (falls zutreffend). So entsteht ein Abhängigkeitsgraph (unten illustriert) auf Paket-Ebene, und unser Server stellt aktuell bereit:

• 1680 CodeSystem-Ressourcen
• 5155 ValueSet-Ressourcen
• 100 ConceptMap-Ressourcen

Darüber hinaus sind auch die durch die HiGHmed-Usecases, durch GECCO sowie durch BBMRI/ERIC und DKTK erstellte Ressource verfügbar - dies spiegelt unser bisheriges Deployment. Sofern weitere Ressourcen für standortübergreifende Anwendungen benötigt werden, können wir diese auf Anfrage mit Ihnen gemeinsam paketieren und bereitstellen.

Neues Konzept

In diesem Zuge haben wir in einem aufwendigen Prozess die inhaltliche und technische Basis unseres Servers überarbeitet. Während in HiGHmed-Zeiten der Schwerpunkt auf der ad-hoc-Bereitstellung notwendiger Ressourcen lag, haben wir nun eine stabile und nachhaltige Infrastruktur geschaffen, die den wandelnden Anforderungen der MII gerecht wird. Anstatt Ressourcen jeglicher Herkunft unstrukturiert auf Zuruf hochzuladen, baut unser neues Deployment auf maximale Transparenz und Nachhaltigkeit. Sämtliche Ressourcen werden mittels FHIR-Packages verwaltet, die über Abhängigkeiten miteinander in Relation gesetzt werden. Alle Pakete werden in unserem GitLab-Bereich transparent verwaltet und können per GitLab NPM Registry bezogen werden.

Paketinhalte

Das wichtigste Paradigma in unserem neuen Deployment ist die Trennung unterschiedlicher Belange (separation of concerns). Jedes Paket enthält nur Ressourcen, die inhaltlich zusammengehören. So gibt es beispielsweise ein Paket für die ICD-10-GM und ein Paket für LOINC. Die Pakete sind in sich geschlossen und können unabhängig voneinander installiert und aktualisiert werden. Dies ermöglicht es uns, die Ressourcen inhaltlich und technisch zu trennen und so eine hohe Qualität und Stabilität zu gewährleisten. Um die Abhängigkeiten zwischen den Paketen zu verwalten, haben wir diese innerhalb der Paket-Manifeste (package.json) deklariert. Abhängigkeiten zwischen den Paketen haben wir durch automatisiertes Tooling identifiziert, um z.B. Bindings innerhalb der FHIR-Profildefinitionen zu erkennen, die auf andere Pakete verweisen.

Sämtliche Pakete, die auf unserem Server gehostet werden, werden durch unser GitLab verwaltet. Wenn schon FHIR-NPM-Pakete durch die Spezifizierer:innen existierten, haben wir die Inhalte dieser Pakete in unsere eigenen Pakete überführt. So können wir sicherstellen, dass die Ressourcen auf unserem Server stets aktuell und korrekt sind, und können die Ressourcen mit den relevanten Metadaten anreichern. Die Versionsnummern in unseren Paketen tracken dabei die Versionen der Ursprungspakete.

Zur Illustration der Abhängigkeiten zwischen den Paketen ist die folgende Grafik hilfreich. Hier werden alle Paket-Abhängigkeiten des Paketes @mii-termserv/de.medizininformatikinitiative.kerndatensatz.terminology.bill-of-materials in der aktuell hochgeladenen Version 2024.8.27-rc2 [GitLab-Package-Registry] dargestellt:

Abhängigkeiten des Paketes @mii-termserv/de.medizininformatikinitiative.kerndatensatz.terminology.bill-of-materials in der Version 2024.8.27-rc2

Etwas übersichtlicher ist sicher das Fragment, dass nur die ausgehenden Abhängigkeiten des Paketes hl7.fhir.r4.terminology in der aktuellen Version 4.0.1-rc2 [GitLab-Package-Registry] zeigt:

Abhängigkeiten des Paketes hl7.fhir.r4.terminology in der Version 4.0.1-rc2. In den Zellen sind die Menge an CodeSystems, ValueSets und ConceptMaps in den Paketen angegeben.

Alle Paketabhängigkeiten beruhen auf tatsächlich festgestellten Abhängigkeiten auf Paket-Ebene. Natürlich brauchen die meisten Pakete nicht die kompletten terminologischen Inhalte der FHIR-Spezifikation, aber Spezifizierende können sich so ohne Einschränkungen darauf verlassen, dass die von ihnen verwendeten Ressourcen auch durch die SU-TermServ bereitgestellt werden. Für DIZ-Mitarbeitende ist es so möglich, die Ressourcen, die sie benötigen, einfach zu installieren und zu aktualisieren.

Metadaten

Jede Ressource innerhalb der Pakete wurde durch uns mit Metadaten versehen. Zum einen verwenden wir meta.tag, um den Projekt- und Datensatz-Kontext jeder Ressource zu illustrieren. Zum anderen verwenden wir die CQF-Scope-Extension, um von den Ressourcen auf die Pakete zu verweisen. Weiterhin haben wir die IDs der Ressourcen angepasst, um Kollisionen zwischen Ressourcen zu vermeiden, und um diese sprechender zu gestalten. Hier ein gekürztes Beispiel aus einem ValueSet aus der FHIR R4-Spezifikation:

{
  "resourceType": "ValueSet",
  "id": "fhir.r4-administrative-gender",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/StructureDefinition/shareablevalueset"
    ],
    "tag": [
      {
        "system": "https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-project",
        "code": "hl7",
        "display": "HL7 International"
      },
      {
        "system": "https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-dataset",
        "code": "hl7-fhir",
        "display": "HL7 FHIR"
      },
      {
        "system": "https://mii-termserv.de/fhir/su-termserv/CodeSystem/mii-cs-suts-resource-tags-license",
        "code": "https://mii-termserv.de/licenses#fhir",
        "display": "HL7 FHIR License"
      }
    ]
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/cqf-scope",
      "valueString": "@mii-termserv/hl7.fhir.r4.terminology"
    }
  ],
  "url": "http://hl7.org/fhir/ValueSet/administrative-gender"
}

Die Tags werden in von uns verwalteten Code-Systemen definiert und gepflegt. Die Lizenz-Tags sind URLs, die auf eine Seite unserer Web-Präsenz verweisen, auf der wir Lizenzbedingungen der Ressourcen illustriert haben (z.B. hier).

Auf Basis unserer Metadaten generieren wir weiterhin Narrative, die in den Ressourcen eingebettet werden, um diese Metadaten für unser Anwender:innen transparent zu machen, hier ein Beispiel:

Canonical Resources Management Infrastrucutre (CRMI)

Die Verwendung der CQF-Scope-Erweiterung wurde durch den kürzlich veröffentlichen CRMI-ImplementationGuide empfohlen. Wir haben die Empfehlungen dieses IGs in folgenden Bereichen umgesetzt:

• Paketierung der Ressourcen als NPM-Pakete [Packaging]
• Distribution innerhalb einer NPM-Registry [Publishing]: https://gitlab.com/mii-termserv/fhir-resources
• Identifikation von Abhängigkeiten auf Ressourcen-Ebene [Dependency Tracing]
• Implementierung des Syndication-Profils auf Paket-Ebene mit selbstimplementierter Open-Source API [Syndication]: https://ontoserver-ballot.mii-termserv.de/crmi/syndication.xml

Eine vollständige Umsetzung dieses IGs ist allerdings nicht möglich, sofern nicht der gesamte Kerndatensatz der MII nach diesen Vorgaben gestaltet wird.

Aktualisierungen

Sobald Aktualisierungen der Upstream-Pakete und Ressourcen veröffentlicht werden, werden wir unsere Pakete aktualisieren.

Für KDS-Pakete bedeutet dies, dass wir alle stabilen Versionen veröffentlichen. Die Pakete für die BfArM-Ressourcen werden jährlich zum Jahreswechsel mit den neuen Versionen aktualisiert. Für SNOMED CT und LOINC werden zum Jahreswechsel Aktualisierungen durchgeführt, bei denen die jeweils aktuelle Version zum Beginn des Jahres bereitgestellt werden.

Bei der Veröffentlichung der endgültigen Pakete werden wir die Versions-Ranges in den NPM-Paketen so formulieren, dass die Paketversionen der Abhängigkeiten kompatibel mit den zu antizipierenden neuen Versionen sein werden. Die in den Paketen dann angegebenen Versionen sind damit als Minimal-Versionen zu verstehen. Durch unser Tooling werden wir die Kompatibilität der Pakete untereinander sicherstellen.

Tooling

Unsere Pakete werden automatisiert mit der GitLab-CI gebaut und in der GitLab-Registry veröffentlicht.

Unser Tooling wurde in einem Python-Tool implementiert, das zwar auf unsere Anforderungen zugeschnitten ist, aber dennoch interessante Funktionen für Andere bereithalten kann. Das Tool ist daher unter der CC0-Lizenz in unserem GitLab verfügbar.

Deployment

Der Ballot-Server ist nun unter https://ontoserver-ballot.mii-termserv.de verfügbar. Unter https://ontoserver-ballot.mii-termserv.de/fhir ist der FHIR-Endpunkt erreichbar. Die Homepage des Servers ist unter https://launch.ontoserver-ballot.mii-termserv.de erreichbar (von https://ontoserver-ballot.mii-termserv.de wird hierhin weitergeleitet).

Auf der Startseite sind Verweise zu weiteren Apps und Diensten, die auf den Server zugreifen, hinterlegt.

Wir sind gemäß unseren Lizenzbedingungen für Ontoserver verpflichtet sicherzustellen, dass unsere Kunden in Deutschland ansässig sind. Dazu ist zwingend ein SSL-Zertifikat erforderlich, das die Identität der anfragendenden Partei bestätigt. Es ist daher notwendig, dass Sie ein Zertifikat aus der aktuellen Géant- oder der alten DFK-PKI verwenden. Wenn Sie kein Zertifikat aus diesen PKIs haben, können Sie sich an uns wenden, um eine Ausnahme zu beantragen. Wir werden dann ein Zertifikat aus einer alternativen—von uns verwalteten PKI—für Sie ausstellen. Eine IP-Allow List wird in Zukunft nicht mehr verwendet, da mit der Pflege aus unserer Sicht ein unverhätnismäßig hoher Aufwand verbunden wäre. Bei Bedarf greifen Sie bitte auf unser Angebot für durch uns ausgestellte Zertiikate zurück.

Auf dem Server werden Sie weiterhin nur lesen können. Mit Ihrem Zertifikat haben Sie die Berechtigung, alle Ressourcen auf dem Server zu lesen, und per FHIR-API anzufragen (sofern Ihr Client-Code auch das Zertifikat präsentiert). Zum Schreiben ist eine weitergehende Authentifizierung notwendig, die nur für Mitarbeitende in der SU-TermServ zur Verfügung steht. Wir werden in Zukunft auch einen Test-Server bereitstellen, auf dem autorisierte Nutzer schreibend arbeiten können.

Unter https://ontoserver-ballot.mii-termserv.de/crmi/syndication.xml ist unsere CRMI-API verfügbar, mit der wir die hochgeladenen Pakete transparent machen (siehe oben).

Ballotierung

Bis zum 20.10.2024 freuen wir uns auf Ihr Feedback zur Ballot-Umgebung. Bitte kommentieren Sie in unserem Zulip-Channel oder per E-Mail. Die Verwendung von Zulip wird dabei präferiert, da wir so eine transparente Diskussion führen können, die auch anderen Interessierten zugänglich ist.

Insbesondere interessiert uns Ihr Feedback zu folgenden Punkten:

• Sind alle Ressourcen, die Sie benötigen/erwarten, auf dem Server verfügbar?
• Sind die Metadaten der Ressourcen für Sie hilfreich?
• Haben Sie Anregungen zur Verbesserung der Server-Infrastruktur?
• Ist die Repräsentation der komplexeren CodeSystem-Ressourcen zu Ihren Anforderungen kompatibel? Haben Sie weitere Verbessungerungsvorschläge?

Wie geht es weiter?

Nach der Ballotierungsphase werden wir Ihr Feedback sammeln und auswerten. Wir werden dann ggf. Rücksprache mit der Community in einer Videokonferenz halten, um offene Fragen zu klären. Anschließend werden wir das neue produktive Deployment mit den gezogenen Lehren aus diesem Deployment und Ihrem Feedback angehen. Der Ballot-Server wird dabei bis auf weiteres weiterhin zur Verfügung stehen.

Ebenso wird das bisherige Deployment unter https://terminology-highmed.medic.medfak.uni-koeln.de/fhir bis auf weiteres weiterhin verfügbar sein. Schon jetzt wird dieser Server aber nicht mehr aktualisiert. Zur Abschaltung des alten Servers werden wir aktuell die Planungen vornehmen und Sie rechtzeitig informieren. Erwarten Sie eine Abschaltung spätestens zum 30.03.2025 zum Ende des ersten Quartals.

Darüber hinaus haben wir weitere spannende Arbeiten für die kommende Zeit geplant, die Ihre Arbeit mit den terminologischen Ressourcen erleichtern soll:

• Unser Tooling zum Erstellen/Konvertieren von Ressourcen in FHIR-CodeSystem (BabelFSH) wird weiterentwickelt.
• Über das Data Sharing Framework und weitere Technologien werden wir ein Distributionskonzept für unsere Ressourcen vorstellen, damit auch in den DIZen ohne eigenen Terminologieserver eine lokale Validierung von ValueSet-Membership möglich ist.
• Auf Basis der paket-basierten Ressourcenverwaltung werden wir Oberflächen entwickeln, mit denen die Abhängigkeiten der Ressourcen transparent gemacht werden können.