Commenting procedure and results
The development of content on the central terminology server and its coordination with the user specialist groups and software manufacturers is carried out via public commenting procedures. The content available for commenting is provided in a separate area of the central terminology server. Here you will find information on completed and upcoming commenting procedures. Information on upcoming commenting procedures is provided via the BfArM-Newsletter Kodiersysteme and the HL7 Deutschland Newsletter .
Comment period from May 24, 2024 to July 3, 2024 (completed)
In a first step, the BfArM coding systems and value lists from the Coding Systems & Registries section were converted into a FHIR format and made available as download packages for commenting via a commenting platform. The coding systems, value lists and mappings provided are intended to be used and made available in the electronic patient record. The packages contain all values used for structured data transmission. The formats are used to validate semantic content.
The following FHIR packages have been provided for comment:
- ICD-10-GM 2024 / 2023 / 2022
- ICD-O-3 Zweite Revision 2019
- ICF 2004
- LOINC - Linguistic Variants Deutschland 2.77
- OPS 2024 / 2023 / 2022
- ORPHAcodes 2024
Comment results (in German)
| Kommentar | Ergebnis |
|---|---|
| Downloadbedingungen: Bevor die Terminologien herunterladbar sind, müssen die Nutzungsbedingungen bestätigt werden. Es findet sich etwa bei ICD-10-GM in § 1 Nr. 4 die Formulierung „Der Erwerber ist nicht berechtigt, die Daten im erworbenen Format auszugsweise oder vollständig an Dritte weiterzugeben. Der Erwerber ist berechtigt, vom Format abgeleitete Mehrwertprodukte zu fertigen und zu vertreiben.“ Dies bedeutet, dass Hersteller die Terminologiepakete nicht herunterladen und an Kunden weitergeben können. | Umsetzung: Vielen Dank für den Hinweis, dass die Downloadbedingungen nicht den Anforderungen für die technische Bereitstellung und Nutzung auf dem Terminologieserver entsprechen. Die Downloadbedingungen wurden vorerst für ICD-10-GM und OPS angepasst. Für ICF und ICD-O-3 sind Abstimmungen mit der WHO als Herausgeber erforderlich, die noch nicht abgeschlossen sind. |
| Bereitstellung der Dateien: Die Form der Bereitstellung der Dateien ist für ein Kommentierungsverfahren ungeeignet. FHIR-Ressourcen im JSON-Quellcode inspizieren zu müssen, schränkt den Kreis der Personen, die fachlich in der Lage sind, am Kommentierungsverfahren teilzunehmen, ein. Terminologen oder andere, weniger JSON-affine Personengruppen werden damit de facto von der Kommentierung ausgeschlossen. Eine Publikation von FHIR-Ressourcen sollte in menschenlesbarer Form mittels geeigneter Tools, z.B. als Simplifier-IG, mit dem IG-Publisher oder per TerminoloGIT erfolgen. | Erläuterung: Wie als Begleitinformation zum Kommentierungsverfahren mitgegeben, war dieses Kommentierungsverfahren darauf ausgerichtet, Rückmeldungen aus dem überwiegend technischen Nutzerkreis der Softwareherstellenden und –nutzenden zu erhalten, ob die zur Kommentierung gestellten FHIR-Packages den technischen Anforderungen genügen und geeignet sind, für die Bereitstellung von Daten in der elektronischen Patientenakte genutzt zu werden. Die Hinweise, dass für Fachkreise, Projektmanager und Entscheider erläuternde Informationen erforderlich sind, hat das BfArM aufgenommen und wird dies für die Ausgestaltung des zentralen Terminologieservers berücksichtigen. Dies beinhaltet auch einen menschenlesbaren „Preview“ der bereitgestellten Informationen. |
| Bereitstellung weiterer Inhalte: Folgende weitere Inhalte sollen auf dem Terminologieserver bereitgestellt werden: ATC und PZN, DRG/PEPP, EBM Ziffern, Alpha-ID, SNOMED CT Int., deutsche Version von SNOMED CT | Erläuterung: Die Inhalte des zentralen Terminologieservers werden gemäß dem gesetzlichen Auftrag nach § 355 SGB V und den Anforderungen der Bereitstellung von Inhalten auf der elektronischen Patientenakte kontinuierlich schrittweise erweitert werden. |
| Bestätigung der Downloadbedingungen: Die Bereitstellung der Terminologie erfolgt über ein die Website. In der gewählten Umsetzung ist jedoch kein automatisierbarer Download im CI/CD Prozesse möglich. Die Inhalte sind nicht wie auf einem Package-Server auffindbar und über Version downloadbar, vielmehr muss immer eine manuelle Bedienung erfolgen. | Umgesetzt: Für den zentralen Terminologieserver (Ausbaustufe 1) ist auch der Zugriff über eine NPM-Schnittstelle (API) geplant, vergleichbar mit der offiziellen FHIR-Package Registry. Über diese API wird eine Einbindung in automatisierten CI/CD-Prozesse möglich sein. |
| Weiterführende Informationen zu den Inhalten: Zum besseren Verständnis sollten Implementation Guides für Kodiersysteme ergänzt werden und die Properties besser beschrieben werden, damit in 15 Jahren noch nachvollziehbar ist, was dargestellt wurde. | Umgesetzt: Die Hinweise, dass für Fachkreise, Projektmanager und Entscheider erläuternde Informationen erforderlich sind, hat das BfArM aufgenommen und wird dies für die Ausgestaltung des zentralen Terminologieservers berücksichtigen. In der Übersicht zu jedem Kodiersystem wurden weitere beschreibende Inhalte ergänzt und ein Hinweis gegeben, wo weiterführende Informationen zu finden sind. |
| Weiterführende Informationen zu den Inhalten: Zum besseren Verständnis sollten die Properties besser beschrieben werden, damit in 15 Jahren noch nachvollziehbar ist, was dargestellt wurde. | Umgesetzt: Die Beschreibungstexte zu den Properties wurden weitgehend ergänzt, wo in den Quellsystemen entsprechende Informationen vorhanden waren. Weiterhin wurde im Sinne einer besseren Nutzerunterstützung darauf geachtet, dass Descriptions erweitert und ergänzt wurden. |
| Anklicken der Downloadbedingungen: Ist es notwendig, dass der Nutzer die Downloadbedingungen für jedes FHIR-Package einzeln bestätigen muss? Es wäre benutzerfreundlicher, wenn man die Bedingungen zusammenfassen könnte und mit einer Bestätigung die Berechtigung für alle FHIR-Pakete erhält. | Teilweise umgesetzt: Die Anwendung wurde so umgestellt, dass die Einhaltung der Downloadbedingungen für ein Kodiersystem, eine Werteliste oder Mapping nur ein einziges Mal bestätigt werden muss. Da die Downloadbedingungen jeweils unterschiedlich sind und ggf. nur einzelne Inhalte abgerufen werden, wurde von einer „Sammel“-Bestätigung Abstand genommen. Für den Abruf per NPM-API wird davon ausgegangen, dass die Nutzenden vorab die Downloadbedingungen geprüft haben und damit einverstanden sind. Dies wird technisch durch die Verwendung von lang gültigen JWTs durchgesetzt, welche in entsprechende API-Request eingebettet werden müssen. |
| Kommentar | Ergebnis |
|---|---|
Betrifft alle Packages: Ein nachvollziehbares Versionierungskonzept sollte verwendet werden. Die Versionsnummern der FHIR-Packages für jährlich publizierte Kodiersysteme sollten fortlaufend eine Information über das Erscheinungsjahr preisgeben. | Umgesetzt: Das Versionierungskonzept wurde grundlegend überarbeitet. Die Versionsnummer lehnen sich nun an die Versionierung der Referenzsysteme an. Für die jährlich publizierten Kodiersysteme ist das Versionsjahr berücksichtigt. Für Packages wird das semantic versioning genutzt. |
| Betrifft alle Packages: Die Festlegung von Canonicals mit der Domäne https://terminologieserver.bfarm.de für die im zentralen Terminologieserver publizierten Terminologien ist insofern ungünstig, da sie eine Verwechslung von Adresse und Name eines Artefaktes / Canonical begünstigt. Dies sollte geändert werden in http://terminologien.bfarm.de. Auf die Verwendung von “https” statt “http” sollte in Canonicals verzichtet werden. (siehe Erläuterungen des TC FHIR/Terminologien von HL7 Deutschland e.V.) | Umgesetzt: Die Subdomain des zentralen Terminologieservers wurde zu https://terminologien.bfarm.de geändert und die Inhalte umgezogen. Grundsätzlich streben wir einen Gleichlauf der Canonical-URLs und der technischen Endpunkt-Adressen an, um die „Auflösung“ von Artefakten durch den Terminologieserver bestmöglich zu unterstützen und im Sinne der Verfügbarkeit und einheitlichen Interpretation einen direkten Zugang zu diesen zu ermöglichen. Aufgrund behördlicher Vorgaben ist die Nutzung einer http-Domain hierbei nicht gewünscht. |
| Betrifft alle Packages, insbesondere ORPHAcodes : Über ein Backport von CodeSystem.author von R5 auf R4 könnte zusätzlich zum „Publisher“ BfArM auch der Herausgeber / Autor INSERM benannt werden. | Umgesetzt: In R4 wird bereits eine author-Extension beschrieben (vgl. https://hl7.org/fhir/R4/codesystem-profiles.html), die für eine differenzierte Darstellung genutzt werden kann. Es ist vorgesehen, diese in zukünftigen Releases zu berücksichtigen. Hierfür bedarf es noch einiger inhaltlicher Abstimmungen. |
| Betrifft ICD-10-GM, ICF, ICD-O-3, OPS: Für die bereitgestellten Pakete werden neue Canonical URLs verwendet. Die HL7 Basisprofile haben bereits eine Canonical URL definiert, welche in vielen Softwaresystemen implementiert und daher breit Verwendung finden. Eine Umstellung widerspricht den Anforderungen und Prozessen bei HL7 International und wäre mit hohem Implementierungsaufwand und Fehlerrisiko verbunden (siehe Erläuterungen des TC FHIR/Terminologien von HL7 Deutschland e.V.) | Umgesetzt: Die Vor- und Nachteile einer Umstellung von Canonical URLs und deren Auflösung im zentralen Terminologieserver § 355 SGB V wurden umfänglich diskutiert. Die von HL7 Deutschland zugewiesenen Canonical URLs wurden in die FHIR-Pakete übernommen, sodass eine Weiternutzung von Bestands-Canonical URLs gewährleistet ist. Als zusätzliche Identifikatoren („identifier“) werden die OID als auch der identifizierende Link im Terminologieserver und historische Canonical URLs mitgeführt. Organisationen, die Canonical URLs für Kodiersysteme und Valuesets in der elektronischen Patientenakte vergeben, werden angehalten, ein Redirect auf die entsprechende Sprungmarke im zentralen Terminologieserver zu setzen, um eine Auflösung der Konzepte und eine zentrale Verfügbarkeit zu unterstützen. Hierfür wird ein Positionspapier „Strategie zur Bereitstellung und Nutzung von Canonical URLs für FHIR-Modellierungen im deutschen Gesundheitswesen“ gemeinsam mit dem Kompetenzzentrum für Interoperabilität im Gesundheitswesen erarbeitet. |
| Betrifft insbesondere ICD-10-GM, OPS: Eine Bereitstellung von FHIR-Dateien für die Versionen mindestens ab 2016, möglichst ab dem Zeitraum 2002 ist wünschenswert, damit auch Altfalldaten sauber mit FHIR abgebildet werden können | Erläuterung: Sofern Kapazitäten verfügbar sind und sofern dies technisch rückwirkend möglich ist, möchte das BfArM diesen Wunsch gerne unterstützen und zukünftig auch ältere Versionen bereitstellen. Entsprechende Anforderungen aus dem Bereich Sekundärdatennutzung und Forschung liegen vor. Dies hängt jedoch von der Kontinuität der Verfügbarkeit und des Formats der vorhandenen Quelldaten und dem damit verbundenen Aufwand bei der Nachpflege ab. |
| Betrifft ICD-10-GM, OPS, ICF: Warum werden die strukturierten Inhalte für Properties als separate Kodiersysteme bereitgestellt und nicht direkt in der Hauptressource? Beispielsweise könnten Boolean Operatoren auch direkt in der Hauptressource modelliert werden. Diese komplexeren Strukturen bedeuten einen höheren Implementierungsaufwand für Softwarehersteller. | Erläuterung: Die Bereitstellung von strukturierten Inhalten für ausgewählte Properties in Form von separaten CodeSystem-Ressourcen bietet die Möglichkeit, diese deutlich differenzierter zu beschreiben, als es mit den jeweiligen Basistypen der Fall wäre. Im Rahmen der Abbildung der ClaML basierten Klassifikation (u.a. ICD-10-GM und OPS) wird für alle Informationen aus den ClaML-Meta-Elementen, eine entsprechende Abbildung gewählt. Im Sinne einer einheitlichen und standardisierten Vorgehensweise, die Softwareherstellenden auch entgegenkommt, wurde dabei entschieden, alle zugehörigen Unterstrukturen (auch „Boolean“-Typen) entsprechend zu modellieren. |
| Alle Packages: Gibt es die Möglichkeit der Verlinkung zwischen den unter- und übergeordneten Dateien und/oder älteren Versionen? | Erläuterung: Unter- und übergeordnete Dateien werden durch den „Package-Kontext“ zusammengehalten und somit immer gemeinsam distributiert. Sowohl die Pakete als auch die enthaltenen Ressourcen sind dabei versioniert und ermöglichen somit eine Nachvollziehbarkeit der Entwicklung der Inhalte über die Zeit. Innerhalb der Hauptsysteme (z.B. ICD-10-GM, OPS) kommen zur Abbildung der ClaML-Meta-Informationen Properties von Typ Coding zum Einsatz. Über diesen Mechanismus wird entsprechend auf die jeweiligen Untersysteme (über die Elemente system und version) verwiesen. |
| Betrifft ICD-10-GM, OPS, ICF: Die zusätzlichen CodeSystems und die korrespondierenden Valuesets sollten in einem eigenen FHIR-Package verwaltet werden und nur darüber distributiert werden. Die Distribution der Property-Codesystem in jedem Package sind redundant. | Erläuterung: Im Sinne einer Komplexitätsreduktion wurde entschieden, das Hauptsystem und die zusätzlichen CodeSystem-Ressourcen (+ korrespondierende ValueSets) innerhalb eines einzigen Paketes zu distributieren. Komplexe Prozesse zum Auflösen von zusätzlichen Paketabhängigkeiten müssen durch die Hersteller somit nicht implementiert werden. Eine ggf. notwendige Fortschreibung der Untersysteme ist auf diese Weise immer mit dem allgemeinen Veröffentlichungsprozess verzahnt. |
| Betrifft ICD-10-GM, OPS, ICD-O-3, ICF: Warum wurde als FHIR-Modellierung kein implizites Valueset mit allen Kodes und eines expliziten ValueSet mit gleicher URL gewählt? | Erläuterung: Dies dient ebenfalls der Komplexitätsreduzierung für Hersteller und soll eine möglichst leichtgewichtige Umsetzung ermöglichen, ohne komplexe Funktionalität in den jeweiligen Systemen umsetzen zu müssen. Vorteil sind u.a.: - die implizite Definition des all-concept-ValueSets wird über eine intensionale Definition expliziert. - der intensionalen ValueSet-Definition wird eine passende Expansion beigefügt, sodass eine entsprechende Funktionalität nicht erst implementiert werden muss. Durch die Berücksichtigung der Best-Practices für die Definition impliziter ValueSets (Namenskonventionen, inhaltliche Vorgaben etc.) kann sich ein Hersteller natürlich auch entscheiden, nicht auf das bereitgestellte ValueSet zurückzugreifen, sondern entsprechende Inhalte zur Laufzeit zu erzeugen. Aus fachlich-inhaltlicher Sicht sind beide Ansätze äquivalent. |
Betrifft ICD-10-GM, OPS: Warum wurde für die Darstellung der Properties ein Coding für Boolesche Operatoren verwendet? Betrifft OPS: Warum wurde ein Coding für boolesche Properties verwendet? | Erläuterung: Die Bereitstellung von strukturierten Inhalten für ausgewählte Properties in Form von separaten CodeSystem-Ressourcen bietet die Möglichkeit, diese deutlich differenzierter zu beschreiben, als es mit den jeweiligen Basistypen der Fall wäre. Im Rahmen der Abbildung der ClaML basierten Klassifikation (u.a. ICD-10-GM und OPS) wird für alle Informationen aus den ClaML-Meta-Elementen, eine entsprechende Abbildung gewählt. Im Sinne einer einheitlichen und standardisierten Vorgehensweise, die Softwareherstellenden auch entgegenkommt, wurde dabei entschieden, alle zugehörigen Unterstrukturen (auch „Boolean“-Typen) entsprechend zu modellieren. |
| Betrifft ICF: Worauf bezieht sich die Zahl bei „Counts“? | Erläuterung: Die Summe der „Counts“ entspricht der Anzahl der 4 „Components“ (b,s,d,e) + die Anzahl der „Kapitel“ (z.B. „b1“) + die Anzahl der „Blöcke“ (z. B. b110-b139) + die Anzahl der endständigen Kodes (z. B. „b110“). In der Summe ergibt das 1495 Einträge. |
| Betrifft ICF: Welche Vorgaben gibt es für die Reihenfolge der Einträge in der FHIR-Datei? | Erläuterung: Die Reihenfolge in der FHIR-Datei entspricht der Reihenfolge in der ClaML-Datei. Die Reihenfolge ist in ClaML und auch in der FHIR-Repräsentation nicht festgelegt. Es steht jedem Softwareherstellenden frei, die Anordnung der Kodes festzulegen. Vorgaben dafür gibt es in der Referenzversion für die ICF auf den Webseiten des BfArM sowie für das technische Format CLaML in der DTD (Document Type Definition). |
| Betrifft ICF: Wieso ist die ICF-Version 2005 veröffentlicht und nicht das neueste ICF-Release der WHO vom 14.2.2024? | Erläuterung: Die offiziell in Deutschland zu nutzende ICF-Version ist die Version 2005. Diese ist daher nach wie vor gültig. Die ICF wird fortlaufend weitergeschrieben. Diese Fortschreibungen sind jedoch bisher nicht offiziell als „Major Release“ von der WHO veröffentlicht und freigegeben worden. |
| Betrifft ICF: Warum sind die Definitionen aus der Referenzfassung nicht in das FHIR-Format übernommen worden? | Erläuterung: Die im FHIR-Paket bereitgestellten Informationen dienen der Nutzung und Bereitstellung in der elektronischen Patientenakte. Der Fokus liegt darauf, dass Kodes ausgetauscht und systemübergreifend korrekt angezeigt werden. Für Informationen und Formate, die der Unterstützung zur Kodierung bzw. zur Auswahl des korrekten Kodes dienen, wird auf die entsprechenden Informationen auf den Webseiten des BfArM und im Downloadcenter Kodiersysteme verwiesen. |
| Betrifft ICF, ICD-O-3: Die Bereitstellung der ICF bzw. der ICD-O-3 sind eine Übersetzung, keine nationale Erweiterung. Daher sollten die URLs "http://hl7.org/fhir/sid/icf" bzw. http://terminology.hl7.org/CodeSystem/icd-o-3 verwendet werden. | Umgesetzt: Die deutschsprachige Übersetzung der ICF bzw. der ICD-O-3 wurden in ein Supplement „CodeSystem-icf-translation-2005-0-0“ bzw. „CodeSystem-icdo3-translation-2019-0-0“ überführt sowie die internationale Bezugsdatei als „Backbone“ mit den entsprechenden Metadaten und Kodes. Dadurch wird der Übersetzung die lokale Canonical URL https://terminologien.bfarm.de/fhir/CodeSystem/icf-translation zugewiesen. |
| Betrifft ICF, ICD-O-3: Die Bereitstellung der ICF bzw. der ICD-O-3 sind eine Übersetzung, keine nationale Erweiterung. Daher sollte die FHIR-Repräsentation den internationalen Vorgaben der WHO entsprechen. | Umgesetzt: In Absprache mit der WHO wurden weitere Anpassungen vorgenommen, um sich möglichst genau an die Vorgaben der WHO zu halten. "hierarchyMeaning" wurde mit "classified-with" ausgezeichnet. Die beiden Qualifier „Ausmaß der Schädigung“ wurden in einer Kodiersystematik zusammengeführt. |
| Betrifft ICD-O-3: Da die Kodes zur Topographie und Morphologie konsekutiv genutzt werden, wäre eine Bereitstellung als separate Valuesets sinnvoll. | Umgesetzt: Die Kodes zur Topographie und zur Morphologie werden zukünftig als separate Valuesets bereitgestellt. |
| Betrifft ORPHAcodes: Warum wurde die Alpha-ID nicht veröffentlicht? | Erläuterung: Zielsetzung der Bereitstellung von Kodiersystemen, Wertelisten und Mappings auf dem zentralen Terminologieserver ist die Unterstützung der elektronischen Patientenakte. Das in der Alpha-ID-SE bereitgestellte Mapping von ICD-10-GM zu ORPHAcodes dient der Zuordnung von Diagnosen seltener Erkrankungen zu den entsprechenden ICD-10-GM-Kodes bzw. der Möglichkeit spezifischer über die ICD-10-GM hinaus seltene Erkrankungen zu erfassen. Im Ergebnis wird eine seltene Erkrankung immer über einen ORPHAcode in der Arztdokumentation erfasst und dokumentiert werden. Zur korrekten Interpretation von ORPHAcodes wurde eine entsprechende Kodiersystematik auf dem Terminologieserver bereitgestellt. |
| Betrifft ORPHAcodes: Aufgrund der Relevanz von Seltenen Erkrankungen für internationale Forschungsvorhaben ist eine Darstellung der englischen Preferred Terms und Synonyme auch wünschenswert. | Erläuterung: Die Bereitstellung der Inhalte auf dem zentralen Terminologieserver ist primär ausgerichtet auf die Nutzung in der elektronischen Patientenakte in Deutschland und die Interpretation von übermittelten Kodes. Über die von Orphanet bereitgestellte Schnittstelle (API) kann die Werteliste um weitere Sprachen erweitert werden. Die Anforderung des Bedarfs, auch Synonyme mit zu publizieren, nimmt das BfArM auf. |
| Betrifft ORPHAcodes: Eine Ver-FHIR-ung der Classifications als ValueSet/CodeSystem sollte geprüft werden. | Erläuterung: Die Ver-FHIR-ung der Classifications wurden geprüft und lässt sich vermutlich durch das Einfügen von parent/child Beziehungen in die Kodiersystematik umsetzen. Im Ergebnis würde eine polyhierarchische Struktur entstehen. Allerdings sind bei diesem Ansatz noch einzelne Punkte fachlich zu bewerten, so dass eine Umsetzung voraussichtlich erst in folgenden Ausbaustufen erfolgen wird. |
| Betrifft ORPHAcodes: Warum wurde die Display-Strings für Designation Use nicht gesetzt? | Erläuterung: Das Einfügen eines Display-Wertes für die designation-use bietet aus unserer Sicht keinen Mehrwert im Hinblick auf den gesetzlichen Auftrag gemäß §355 SGB V, da die Verarbeitung der entsprechenden Angaben durch IT-Systeme erfolgen soll. Diese können bei Bedarf den jeweiligen Kode nachschlagen. Der Verzicht auf die entsprechende Angabe verkleinert zusätzlich die FHIR-Repräsentation und somit auch deren Speicherverbrauch. |
| Betrifft LOINC Linguistic Variant: Warum wird LOINC International Version nicht auf dem Terminologieserver bereitgestellt? | Erläuterung: Ziel des zentralen Terminologieservers ist es nicht, internationale Quellen, die nativ im FHIR-Format vorliegen zu duplizieren. Daher wurde für LOINC die deutschsprachige Übersetzung auf dem Terminologieserver bereitgestellt und auf die internationale Referenz beim Regenstrief Institute mit dem entsprechenden Link verwiesen. Internationale Quellen werden nur „dupliziert“, wenn diese nicht im FHIR-Format verfügbar sind. |
| Betrifft LOINC Linguistic Variant: Asparagin wurde fälschlicherweise mit Aspargin übersetzt. | Umgesetzt: Der Fehler wurde korrigiert und ist im Release 2.78 nun korrekt. |
Betrifft UCUM Werteliste: Der Sinn und Unsinn der Verwendung von UCUM-Bracketexpressions (z.B. /kg{Körpergewicht}) im Umfeld von FHIR, wo Codierung und Anzeigetexte üblicherweise voneinander getrennt werden, wurde in der Community bereits umfassend diskutiert. Das Ergebnis ist in den Best Practice-Empfehlungen dokumentiert: https://simplifier.net/guide/best-practice-bei-der-implementierung-und-spezifizierung-mit-hl7/%C3%9Cbersicht/Spezifikation/Profilierung?version=1.0.0#Weitere-Empfehlungen Die Publikation von Deutschen Übersetzungen für Bracket-Expressions in einer FHIR-CodeSystem-Ressource legitimiert die Verwendung von Bracket-Expressions im Kontext von FHIR und steht damit den BestPractice-Empfehlungen von HL7 Deutschland entgegen. Hier sollte eine Einigung zwischen BfArM und der FHIR Community herbeigeführt werden, wie in FHIR mit UCUM-Bracket-Expressions umgegangen werden soll. | Erläuterung: Die Bracketexpressions sind Teil der UCUM-Notation, wie sie in der UCUM-Spezifikation als Syntax-Regel vorgegeben werden. Mit curly Brackets werden Arbitrary Units (§ 24) annotiert. Die als ValueSet bereitgestellte Liste basiert auf der UCUM Common Units List Version 1.5, die eine Auswahl von häufig elektronisch ausgetauschten Einheits-Patterns darstellt. Die Bereitstellung wurde in der AG LOINC abgestimmt. Eine Abstimmung müsste daher zwischen Regenstrief Institute und der FHIR-Community erfolgen. Wir bitten HL7 Deutschland als Vertreter in der AG LOINC, einen Änderungsvorschlag einzubringen. |
| Betrifft UCUM Werteliste: Eine Übersetzung eines UCUM Kodes macht wenig Sinn, dieser ist zur Maschinenverarbeitung vorgesehen welche die geschweifte Klammer sowieso ignoriert. Keine Übersetzung von UCUM Kodes und Displaywerten, das Supplement kann entfernt werden. | Erläuterung: UCUM ist eine Annotation für den elektronischen Austausch und die technische Interoperabilität und Skalierbarkeit von Einheiten. Daher ist für den Austausch von in UCUM notierten Einheiten eine Übersetzung von UCUM Annotierungen nicht notwendig und sinnvoll. In der fachlichen Praxis hat es sich jedoch gezeigt, dass bei der Erfassung in UCUM notierte Einträge zum Teil interpretationsbedürftig sind und die Annotationen mittels Arbitrary Units (in curly brackets {}) übersetzt werden müssen. Eine Erfassung von komplexen Einheitensystemen über komplexe Datenmodelle ist oft nicht praktikabel. Daher wird für den Austausch von Einheiten hilfsweise eine Werteliste von Common Units publiziert. Diese ist auch für den Datenaustausch in Europa vorgesehen. |
| Betrifft UCUM Werteliste: Es könnte noch als Designation die Singular- und die Pluralform angegeben werden, also z.B. für den Kode "h" die Designations "Stunde" und "Stunden". Smarte Anwendungssoftware könnte dann bei Vorliegen der Designations eine bessere UI rendern. | Erläuterung: Diese Anforderung nimmt das BfArM auf zur Abstimmung in der AG LOINC. |
| Betrifft ICD-10-GM: Warum wurde als Datentyp für classKind ein String anstatt Coding oder Kode gewählt? | Erläuterung: Basis der FHIR-Konvertierung ist das ClaML-Format. Da die entsprechenden Optionen für classKind nicht als fachlicher Bestandteil der Klassifikation selbst enthalten sind, sondern lediglich eine Klasse näher auszeichnen, konnte der Datentyp „Kode“ nicht verwendet werden. Im Rahmen der Abbildung wurde jedoch überlegt – ähnlich wie bei den Meta-Informationen – eine eigenständige Kodiersystematik zu erstellen und auf die jeweiligen Konzepte über „Codings“ zu verweisen. Diese Idee wurde jedoch bis auf Weiteres verworfen, da sich eine Reihe von Implikationen ergeben hätte: - classKind wird sowohl in der ICD-10-GM, ICD-10-WHO, OPS, ICF und ICD-O-3 verwendet. Entsprechend wäre es – anders als bei den Klassifikations-spezifischen Meta-Informationen - konsequent gewesen, hierfür ein gemeinsames und einheitliches CodeSystem zu generieren. Dieses wäre im besten Fall international abzustimmen (Benennung, Inhalte usw.). - Dieses CodeSystem müsste in einem separaten Paket distributiert werden. Entsprechende Abhängigkeiten wären in den jeweiligen Packages für ICD-10-GM und Co. zu vermerken und durch Primärsysteme aufzulösen. Dies erhöht die Komplexität der Umsetzung. |
| Betrifft OPS: Die URL https://terminologieserver.bfarm.de/fhir/CodeSystem/ops-p17bd ist fehlerhaft. Sie sollte korrekt https://terminologieserver.bfarm.de/fhir/CodeSystem/ops-p17b-d sein. | Umgesetzt: Vielen Dank! Dieser Fehler wurde umgesetzt und noch einmal nach fehlenden Bindestrichen bei der Übertragung von Titeln geprüft. |