2.10 Wie ist eine Profil-Instanz strukturell aufgebaut?
Das Allergie-Profil soll als Beispiel dienen und ist unter folgendem Link zu finden:
Abbildung: Erste Hierarchieebene des Allergie-Profils aus der PIO-ULB Spezifikation auf simplifier
Simplifier stellt die Profile mithilfe einer aufklappbaren hierarchischen Struktur dar, welche die Schachtelung der XML-Tags eins zu eins widerspiegelt. Für jedes Element sind Kardinalitäten (z.B. 0..*) angegeben. "Must support" Elemente sind mit einem roten "S" gekennzeichnet. Im Folgenden soll der Aufbau des Allergie-Profils und einer zugehörigen Profil-Instanz genauer erklärt werden:
Der Header:
Der Header ist in jedem Profil der PIO-ULB Spezifikation identisch aufgebaut. Der Begriff "Header" wurde von uns eingeführt und ist keine offizielle FHIR-Bezeichnung. Dennoch fanden wir den Begriff passend. Im Header sind die ID der Profil-Instanz (in diesem Fall eine UUID) und die Art des Profils (siehe "profile") hinterlegt:
Abbildung: Header des Allergie-Profils auf simplifier
Abbildung: Header einer Allergie-Profil-Instanz als XML-Repräsentation
Der XML-Tag <id> ist auf simplifier nicht sichtbar, ist aber für jede FHIR Profil-Instanz verpflichtend. <id> wird von einer FHIR-Basisressource vererbt.
Binding und Pattern Symbole:
Simplifier verwendet folgende “Binding”- und “Pattern”-Symbole:
Abbildung: "Binding" und "Pattern" Symbole auf simplifier
“Binding” bedeutet, dass der Wert an ein Codesystem gebunden ist, während “Pattern” einen fixen Wert vorgibt, für den keine Nutzereingabe erforderlich ist.
Extension:
Nähere Informationen zu <extension> gibt es unter 2.8. Die Repräsentation einer <extension> in der XML-Datei sieht wie folgt aus:
Abbildung: Extension im Allergie-Profil auf simplifier (am Beispiel "abatement")
Abbildung: Extension einer Allergie-Profil-Instanz als XML-Repräsentation (am Beispiel "abatement")
CodeableConcept:
Oft werden codierte Informationen als CodeableConcept abgebildet. Beim Allergie-Profil wird z.B. der Verifikationsstatus mit einem CodeableConcept codiert. CodeableConcepts sind immer identisch aufgebaut und an ein spezielles Codesystem gebunden (siehe Binding-Symbol in der Abbildung). Ein CodeableConcept ist wie folgt aufgebaut:
Abbildung: Verifikationsstatus des Allergie-Profils als CodeableConcept auf simplifier
Abbildung: Verifikationsstatus einer Allergie-Profil-Instanz als XML-Repräsentation (als CodeableConcept)
Codierung des Allergie-Codes mittels Slice-Element:
Auch der Code der Allergie ist als CodeableConcept repräsentiert.
Abbildung: Allergie-Code des Allergie-Profils auf simplifier (als CodeableConcept)
Neu ist hier das blaue Slice-Element, welches dem Nutzer in diesem Fall die Freiheit gibt, die Allergie mittels SNOMED-CT oder ASK Code anzugeben. Die PIO-ULB Spezifikation lässt an dieser Stelle also zwei verschiedene Codesysteme zu. Unser PIO-ULB Editor unterstützt jedoch nur SNOMED-CT Codes.
Außerdem sieht man, dass ein CodeableConcept ein <text> Element besitzen kann. Dieses Element dient der Freitextbeschreibung des Codes. Der Nutzer hat also auch die Möglichkeit, keinen Code anzugeben, und die Allergie mit einem Freitext zu benennen. Die XML-Repräsentation könnte dann wie folgt aussehen:
Abbildung: Allergie-Code einer Allergie-Profil-Instanz als XML-Repräsentation (als CodeableConcept)
Referenzen auf andere Profil-Instanzen:
Jede Profil-Instanz ist mithilfe einer ID (z.B. UUID) innerhalb eines PIO-ULBs eindeutig identifizierbar. Diese ID kann verwendet werden, um von einer Profil-Instanz auf eine andere zu referenzieren. Im Fall der Allergie kann der Diagnosesteller referenziert werden. Dies kann der Patient selbst sein oder ein Hausarzt bzw. behandelnde Person (= Practitioner).
Abbildung: Referenz auf den Diagnosesteller des Allergie-Profils auf simplifier
Abbildung: Referenz auf den Diagnosesteller einer Allergie-Profil-Instanz als XML-Repräsentation