Umgang mit Kardinalitäten

• Pflichtfelder sollten sparsam verwendet werden! Um darzustellen, welche Elemente einer Ressource in einem konkreten Kontext relevant sind, sollten niemals Kardinalitäten verwendet werden, sondern stets MustSupport-Flags.
  Begründung: Wird die minimale Kardinalität auf 1 erhöht, so zeigt dies nicht die Relevanz eines Feldes an, sondern nur, dass dieses Feld immer ausgefüllt sein muss, damit ein Datensatz als valide gilt. Im Einzel- oder Sonderfall fehlende Informationen führen zu nicht validen Instanzen. Pflichtfelder sollten nur dann definiert werden, wenn es akzeptiert/gewollt ist, dass aufgrund des Fehlens dieser einzelnen Information eine ganze Instanz verworfen/zurückgewiesen werden muss.

• Die Begrenzung der maximalen Kardinalität von Elementen sollte vermieden werden. Constraints auf wiederholbaren Elementen sollten durch ein offenes Slicing definiert und spezifiziert werden.
  Begründung: Werden maximale Kardinalitäten eingeschränkt, zwingt dies die Implementierer dazu, individuelle Schnittstellen zu entwickeln, die nicht benötigte Elemente gezielt entfernen, während hingegen das Ignorieren überflüssiger Informationen niemanden etwas kostet. Wird eine maximale Kardinalität auf 0 reduziert, so bedeutet dies, dass die Verwendung des Feldes explizit verboten ist. Instanzen, in denen diese Felder gefüllt sind, gelten als nicht valide. Dies sollte nur dann verwendet werden, wenn es die ausdrückliche Intention ist, ein Element zu verbieten, niemals um auszudrücken, dass ein Feld nicht relevant/nicht benötigt/nicht genutzt wird.
  Ausnahmen: Was aus Gründen der Interoperabilität technisch sinnvoll erscheint, ist nicht immer mit datenschutzrechtlichen Vorgaben übereinzubringen. Häufig sind Spezifizierer gezwungen, Elemente durch Constraints zu verbieten, weil die Übermittlung der darin enthaltenen Information in einem konkreten Kontext nicht gestattet ist. Irrelevante Informationen einfach auf Empfängerseite zu ignorieren genügt nicht dem Gebot der Datensparsamkeit! In solchen Situationen sollte die Spezifikation auf Basis von SDC-Questionaires als Alternative in Betracht gezogen werden, da dort die Selektion der benötigten Elemente mit Hilfe der Prepopulation-Extensions automatisiert werden kann.

Umgang mit Modifying Elements

Elemente, die in der FHIR-Spezifikation als modifying gekennzeichnet sind (?!-Flag), sollten nach Möglichkeit in einem Profil genauer spezifiziert werden, um Entwicklern den Umgang mit solchen Elementen zu erleichtern. Dies kann beispielsweise erreicht werden indem die Elemente

• als MustSupport-Elemente gekennzeichnet werden und/oder
• als Pflichtfelder deklariert werden und/oder
• auf nicht-modifizierende Werte begrenzt werden oder
• mit einer Begründung versehen werden, warum das modifying Element im konkreten UseCase keine modifizierende Wirkung hat und bei der Implementierung nicht als solches betrachtet werden muss oder
• durch Einschränkung der maximalen Kardinalität verboten werden.

Begründung: Entweder muss sichergestellt sein, dass alle beteiligten Systeme die Semantik des Elementes verstehen und korrekt implementieren (mustSupport) oder es muss sichergestellt sein, dass in diesen Elementen keine modifizierenden Informationen übermittelt werden. Wenn keine weiteren Constraints auf optionale, modifizierende Elemente angelegt werden können, so sollte in der Dokumentation explizit darauf aufmerksam gemacht werden, dass diese aufgrund ihrer modifizierenden Wirkung dennoch unbedingt beachtet werden müssen. Dies wird bei der Implementierung leider häufig übersehen. Beispiel: Patient.deceased mag weder Pflichtfeld noch mustSupport-Element sein, muss aufgrund seiner modifizierenden Eigenschaft aber dennoch beachtet werden. AllergyIntolerance.verificationStatus mag optional und nicht mustSupport sein, Implementierungen müssen dennoch richtig reagieren, wenn der Wert "entered-in-error" übermittelt wird.

Umgang mit Meta-Daten

Resource.meta dient Systemen zur internen Verwaltung(Identifikation, Versionierung, Kenzeichnung) von Datensätzen. Constraints auf Resource.meta sollten mit äußerster Zurückhaltung und Vorsicht erfolgen, um nicht in die interne Logik von Systemen, die FHIR implementieren, einzugreifen.

Im Speziellen gilt:

• meta.profile sollte nicht constrained werden. Es sollte ausreichen, dass eine Instanz die Regeln eines Profils erfüllt, ohne dies explizit deklarieren zu müssen.
  Begründung: Die Deklaration von meta.profile hat keine semantische Bedeutung und sollte auch niemals dazu verwendet zu werden, Semantik zu transportieren. Instanzen, die ohne eine Deklaration gegen ein Profil validieren, sollten genauso behandelt werden wie Instanzen, die mit Deklaration validieren. Ebenso sollte die Deklaration eines Profils niemals dazu führen, dass die Validierung übergangen wird. Die Konformität zu einem Profil muss trotz Deklaration stets überprüft werden, sofern die Konformität zu diesem Profil für das validierende System von Belang ist.
• Es sollte NIEMALS verhindert werden, dass meta.profile zusätzliche Werte enthalten kann.
  Begründung: Es muss immer davon ausgegangen werden, dass einzelne Systeme mehrere Spezifikationen gleichzeitig implementieren und deren Instanzen daher Konformität zu mehreren Profilen deklarieren müssen. In Zukunft kann es erforderlich sein, über meta.profile auch Auskunft über die FHIR-Version, auf der Instanz basiert, zu kommunizieren.

Dokumentation und Nachvollziehbarkeit

Bei der Erstellung von Profilen sollten folgende grundsätzlichen Regeln beachtet werden um zu einer vollständig, verständlich und nachvollziehbar dokumentierten Spezifikation zu gelangen:

• in StructureDefinition.description sollte eine ausführliche Beschreibung des Profils angegeben werden.
• Hinweise, die nur für die Autoren, aber nicht für die Nutzer einer Spezifikation relevant sind, können als Kommentarzeilen im Quellcode angegeben werden.

Für alle Elemente, die mit Constraints versehen wurden, gilt:

• in ElementDefinition.short sollte die im jeweiligen UseCase gebräuchliche Bezeichnung für die Information (evtl. auch übereinstimmend mit deren Bezeichnung im Informationsmodell) angegeben werden.
• in ElementDefinition.comment sollte eine Begründung für die auf diesem Element geltenden Constraints angegeben werden.

Beispiel in FSH:

* birthDate
  * ^short = "Geburtsdatum"
  * ^comment = "Pflichtfeld gem. §199a SGB V"
//ToDo: Prüfen, unter welchen Bedingungen die birthtime-Extension benötigt wird.

Im IG Template von HL7 Deutschland werden die genannten Elemente automatisch im Dokument angezeigt und für den Anwender gut sichtbar dargestellt.

Weitere Empfehlungen

Umgang mit UCUM-Annotations ("curly-brace-notation")

Bei der Verwendung von UCUM-Einheiten in Quantity-Datentypen sollten keine Annotationen verwendet werden (vgl. https://ucum.org/ucum 2.4 Style §12 "curly braces"). Der anzuzeigende Text sollte stattdessen in Quantity.unit geschrieben werden.

Begründung: Die Annotationen der UCUM-Spezifikation wurden unter der Annahme spezifiziert, dass bei der Nutzung der Codes nicht zwischen der maschinenlesbaren und der menschenlesbaren Repräsentation des Codes differenziert werden kann. In FHIR ist dies jedoch möglich (Menschenlesbare Repräsentation der Maßeinheit in Quantity.unit, maschinenlesbare Repräsentation in Quantity.code). UCUM-Annotationen sind daher im Kontext von FHIR redundant.

Beispiel

UCUM-Notation: /g{wet'tis}

Statt in FHIR die codierte Einheit mitsamt der Annotation in Quantity.code zu schreiben, sollten Code und Anntoation separiert werden:

<code value="/g"/>
<unit value="per gram of wet tissue"/>

Analog sollte die dimensionslose Einheit "Punkte" nicht als 1 notiert werden, sondern als

<code value="1"/>
<unit value="Punkte"/>

Umgang mit Target-Profilen im Datentyp Reference

Bei der Profilierung des Datentyps Reference sollte - wo möglich - auf die Verwendung von Target-Profilen verzichtet werden.

Begründung: Im Kontext einer Spezifikation mag es zwar sinnvoll sein, auszudrücken, dass beispielsweise eine konforme Observation nur auf einen konformen Patienten verweisen darf, jedoch verhindert diese Festlegung die Wiederverwendung des Observation-Profils in anderen Kontexten. Klinische Profile aus Spezifikationen wie z.B. US Core oder International Patient Summary konnten daher in der Vergangenheit trotz identischer fachlicher Anforderungen nicht wiederverwendet werden, weil die Constraints der dort referenzierten Patienten- oder Practitioner-Profile nicht übereinstimmten. Das Weglassen von Target-Profilen hingegen hat meist keine negativen Konsequenzen, da davon ausgegangen werden kann, dass Systeme, die das Observation-Profil einer Spezifikation implementieren auch erfordern, dass die Patienten-Ressourcen konform zur selben Spezifikation sind. Bei Konformitäts-Tests werden üblicherweise beide Profile unabhänig voneinander getestet (Systeme müssen nachweisen, dass sowohl ihre Observation- als auch ihre Patienten-Ressourcen konform sind), eine indirekte Prüfung der Konformität von Patienten-Ressourcen über die Observation wäre unüblich.

Weitere Hinweise

Weitere Hinweise von HL7 International siehe: https://build.fhir.org/ig/FHIR/ig-guidance/best-practice.html#profiles