Best Practice ...bei der Profilierung von Ressourcen

• Um darzustellen, welche Elemente einer Ressource in einem konkreten Kontext relevant sind, sollten NIEMALS Kardinalitäten verwendet werden, sondern immer MustSupport-Flags.

  • 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 akzeptiert wird, dass aufgrund des Fehlens dieser einzelnen Information eine ganze Instanz verworfen/zurückgewiesen werden muss.
  • Wird eine maximale Kardinalität auf 0 reduziert, so bedeutet dies, dass die Verwendung des Feldes VERBOTEN ist. Instanzen, in denen diese Felder gefüllt sind, gelten als nicht valide. Dies sollte nur dann verwendet werden, wenn es die explizite Intention ist, ein Element zu verbieten, nicht um auszudrücken, dass ein Feld nicht relevant/nicht benötigt/nicht genutzt wird.
  • Werden maximale Kardinalitäten einschrä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.

• Maximale Kardinalitäten wiederholbarer Elemente sollten möglichst nicht eingeschränkt werden. Stattdessen sollten die relevanten Wiederholungen eines Elements durch ein offenes Slicing definiert und spezifiziert werden.

• 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 oder
  • als Pflichtfelder deklariert werden oder
  • auf nicht-modifizierende Werte begrenzt werden oder
  • mit einer Begründung versehen werden, warum das Element im konkreten Kontext keine modifizierende Wirkung hat und bei der Implementierung nicht als solches betrachtet werden muss oder
  • durch Einschränkung der maximalen Kardinalität verboten werden.

  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.

• 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.

  • 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.
  • 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.
  • Es sollte niemals verhindert werden, dass meta.profile zusätzliche Werte enthalten kann.
  • Es muss immer davon ausgegangen werden, dass einzelne Systeme mehrere Spezifikationen gleichzeitig implementieren und deren Instanzen daher Konformität zu mehreren Profilen deklarieren.

• Bei der Verwendung von UCUM-Einheiten in Quantity-Datentypen sollten keine Annotationen verwendet werden. Der anzuzeigende Text sollte stattdessen in .unit geschrieben werden.

• Bei der Profilierung des Datentyps Reference sollte - wo möglich - auf die Verwendung von Target-Profilen verzichtet werden. 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 alle 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 siehe: https://build.fhir.org/ig/FHIR/ig-guidance/best-practice.html#profiles