cdaab2:Template-Konzept

Dieses Material ist Teil des Leitfadens Arztbrief 2.x. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Konzept der Templates

Wie aus den vorhergehenden Erläuterungen ersichtlich ist, setzt sich ein Dokument aus verschiedenen Komponenten zusammen, die flexibel miteinander kombiniert werden können. Für ein Zusammensetzen der Einzelteile auf den unterschiedlichen Ebenen gibt es detaillierte „Baupläne“, die in CDA auch Templates – oder Schablonen oder auch Muster – genannt werden.

Tabelle: CDA-Templates

Template	Beschreibung	Inhalt
Document Level Template	Angabe der benötigten Einzelteile für eine bestimmte Art von Dokument. So legt die Schablone für einen Arztbrief beispielsweise fest, dass ein Arzt das Dokument für einen anderen Arzt erstellt und somit sowohl eine Anrede und eine Grußformel enthalten sollte. Bei einem einfachen Meldebogen ist letzteres nicht der Fall.	Festlegung des Inhalts des Dokuments inklusive der Header und Section-Level-Templates sowie weiterer Header-Metadaten
Header Level Template	Angabe, wie die größeren Blöcke im Header eines Dokumentes konkret aussehen sollen, zum Beispiel welche Details zu einem Patienten hinterlegt werden können.	Patient, Autor, Unterzeichner, weitere Beteiligte, ..
Section Level Template	Angabe, wie ein bestimmter Abschnitt konkret aussehen soll. Hier können auch Vorgaben gemacht werden, wie zum Beispiel Diagnosen in einer tabellarischen Form textuell aufbereitet werden sollen, damit sie einheitlich durch ein Stylesheet zur Anzeige gebracht werden können. Des weiteren kann hier auf die optionale oder verpflichtende Nutzung von Entry-Level-Templates hingewiesen werden.	Anrede, Diagnose, Maßnahme, ..
Entry Level Template	Angabe, wie die Einzelinformationen in struktierter und kodierter Form hinterlegt werden sollen, damit sie durch ein Programm ausgewertet und weiter verarbeitet werden können.	ICD-Diagnosen, Maßnahmen, Scores und Assessments, Meldeanlässe, ..
Datentypen	Hier handelt es sich genau genommen nicht um Templates, sondern um sog. „Datentypen-Flavors“, jedoch beschreiben diese wie ein Datentyp in einem bestimmten Use Case genutzt werden soll. So kann es beispielsweise zwei unterschiedliche Ausprägungen für Adressen geben, die vollständige Adresse lässt Straßennamen oder Postfächer zu, der Geburtsort wird auf die Stadt inklusive Land eingeschränkt.	Diese Datentypen werden in den drei vorgenannten Arten von Templates genutzt. Verwendung von Namen und Adressen, Telefonnummern, ..

Templates stellen somit sog. „Profile Components“ dar, sind also selber konkrete Ausprägungen allgemeiner Vorgaben für einen bestimmten Use Case. Derartige Ausprägungen können hierarchisch vorgenommen werden. Nachfolgend sei das einmal an einem Beispiel erläutert.

Tabelle: Beispiel für eine Template-Hierarchie

Stufe	Hierarchie	Inhalt	Einschränkung
1	Author	Originäre Spezifikation aus dem CDA-Header	Keine
2	Author allgemein	Ausdifferenzierung inklusiver aller Details	Anwendung von Datentypen-Flavors
3	Author Person	Reduzierung auf eine Person als Autor	Streichung der Auswahlmöglichkeit
3	Author Gerät	Reduzierung auf ein Gerät als Autor	Streichung der Auswahlmöglichkeit

Eine weitere wichtige Eigenschaft ist die Feststellung, ob Templates „offen“ oder „geschlossen“ sind, d.h. ob nur die definierten Elemente zugelassen sind (geschlossen) oder ob auch Erweiterungen – gemäß dem zugrunde liegenden Modell – erlaubt sind (offen). Hier gibt es unterschiedliche Vorgehensweisen. So macht es für die Angaben im Header durchaus Sinn, alle notwendigen Details soweit vorzugeben, so dass in Spezialisierungen bei nicht benötigten Attributen/Klassen nur die entsprechenden Auswahlmöglichkeiten gestrichen werden müssen, während für die Angaben im Body nur bedingt möglich ist, alle Eventualitäten vorzugeben.