Hilfe:Template-Architektur
This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template. This page was last edited by Tkahlert (talk| contribs) 11 years ago. (Purge) Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage. This page was last edited by Tkahlert (talk| contribs) 11 years ago. (Purge) |
Inhaltsverzeichnis
- 1 Architektur der Wiki-Seiten
- 2 Konkrete Strukturelemente
- 2.1 Abschnitte des Dokumenten-Headers (Artefakte)
- 2.2 Zusammenbindung der Teile des Dokumenten-Headers (Artefakte)
- 2.3 Abschnitte des Dokumenten-Bodies (Artefakte)
- 2.4 Sektionen = Inhaltliche Abschnitte (Übersichtsseite + eigene Seite)
- 2.5 Zusammenbindung der Sektionen des Dokumenten-Bodies (Artefakte)
- 2.6 Textstrukturierung (aus Kap. 6.4)
- 2.7 Level 3 Elemente (Übersichtsseite + eigene Seite)
- 3 Konkrete Inhalte
Architektur der Wiki-Seiten
Nachfolgend eine kleine Grafik, die die Gesamtstruktur und damit die Verteilung der einzelnen Informationen über die einzelnen Seiten erläutert.
- Legende
- Durchgezogene Kästchen = Wikiseiten
- Gestrichelte Kästchen = Kategorien
- Buchstaben in Kreisen = Kategorien, über die die Kategoriehauptseiten aufgebaut werden
- Farben = verschiedene Namensräume
Im einfachsten Fall wird ein Implementierungsleitfaden durch eine einzige Seite dargestellt, auf die von der Hauptseite verwiesen wird. Dann kann man denselben Namensraum („IG“) verwenden. Wenn ein Leitfaden aber über verschiedene Seiten aufgeteilt werden soll – an der Stelle ist die weitere Struktur erstmal egal – dann bietet sich die Nutzung eines eigenen Namensraumes an. Damit können alle weiteren Seiten frei von einer weiteren Regelung erstellt werden.
Zur weiteren Aufteilung über verschiedene Seiten sollte aber eine Struktur erkennbar sein, die sich u.a. auch nach den Erfordernissen von CDA richtet. Also bspw. Sektionen und Entries darstellen. Hier bietet sich an, ebenfalls jeweils eine eigene Wiki-Seite einzurichten, auf die dann verlinkt wird.
Diskussionspunkte
- Es muss zwischen Seiten unterschieden werden, die für den Leitfaden gebraucht werden, und den Seiten für die CDA-„Einzelteile“.
- Grundsätzlich lassen sich die Seiten jeweils über Namensräume trennen. Dann müsste die Namenskonvention darüber erfolgen. Dann bekäme jeder Implementierungsleitfaden seinen eigenen Namensraum – zumindest für die zu einem Leitfaden gehörenden Abschnitte wäre das eine Lösung. Dies ist bereits so für den Mutterpass eingerichtet worden.
- Kategorisierung: Wie sollen die Seiten kategorisiert werden, damit eine automatische Aufzählung erfolgen kann?
Optimal wäre eine inhaltliche Zuordnung, so dass die Seiten aus den Namensräumen dann gruppiert und automatisch aufgelistet werden können.
Namenskonvention für die Wikiseite
Seite | Kommentar |
---|---|
Implementierungsleitfäden | Startseite (über alles); Von hier aus werden die Implementierungsleitfäden verlinkt |
IG:<LEITFADEN> | Alle Implementierungsleitfäden werden im Hauptnamensraum („IG“) erstellt. |
<NAMESPACE>:<SEITE> | Die verlinkten Teile eines Implementierungsleitfadens werden in jeweils einem eigenem Namensraum erstellt; für die Seiten existieren keine dedizierten Vorgaben (so kann in jedem Namensraum eine Seite „Einleitung“ erstellt werden) Damit kann jede Gruppe frei arbeiten. |
IG:CDA_Doc_Types | Übersicht Dokumenttypen; wird über Kategorie erstellt; alternativ über Referenzen bzw. Hyperlings (bei letzteren können noch Zusatzinformationen wie bspw. eine Hierarchbildung (s.u.) abgebildet werden) |
IG:CDA_Sections | Übersicht über alle Sektionen; Einbindung über Kategorien |
IG:CDA_Entries | Übersicht über alle Entries; Einbindung über Kategorien |
V3dtr1 | Gesamtseite Datentypen |
V3dtr1:<NAME> | Abschnitte der Gesamtspezifikation bzw. spezieller Datentyp |
IG:CDA_HL7_Mutterpass | Bereits existierender Satz von Seiten |
IG:Übermittlung_melde- pflichtiger_Krankheiten |
Bereits existierende Seite |
Kategorien
Beschreibung | Kategorie |
---|---|
Implementierungsleitfaden (kann auch über eigenen Namensraum erfolgen) |
A |
Dokumenttypen | Documenttype 0 |
Abschnitt/Sektion (Template) | Section B |
Artefakt | Artefakt C |
Entry (Template) | Entry D |
Zuständigkeiten
Es gibt eine Reihe von Initiativen, die eigene Dokumenttypen spezifizieren wollen. Diesen muss ein Namensraum zugewiesen werden, damit diese frei arbeiten können. Nachfolgend eine anfängliche Liste:
IG-NAME | Namespace | Zuständig |
---|---|---|
Arztbrief 1.x | cdaab1 | Heitmann |
Arztbrief 2.0 | cdaab2 | Heitmann, Oemig |
Mutterpass | cdaemp | Hellmuth |
Übermittlung meldepflichtiger Krankheiten (Meldepflichtige Infektions-Krankheiten) |
cdamik | Treinat |
Trainingsplan | cdatp | Houta |
CDA für die elektronische Fallakte (nur Sektionen) |
cdaefa | Caumanns |
Pathologiebefund | cdapath | Haroske, Schrader |
Übermittlung onkologischer Daten (onkolog. Versorgung) (Meldungen an Krebsregister) |
cdaonk | Altmann, Schütze, Lang, Ketterer |
IG |
Notwendige Korrekturen
Gemäß der vorhergehenden Aufstellung müssen einige Wiki-Seiten um-benannt sowie umstrukturiert werden:
URL (alt) | Namensraum | Kommentar |
---|---|---|
IG:Übermittlung_melde- pflichtiger_Krankheiten |
cdaonko | Auf eigenen Namespace umheben, wenn der Implementierungsleitfaden über mehrere Seiten aufgeteilt werden sollte |
Konkrete Strukturelemente
Abschnitte des Dokumenten-Headers (Artefakte)
Diese werden auf eigenen Seiten erstellt, die beliebig innerhalb des eigenen Namensraumes benannt werden können. Seiten aus anderen Namensräumen können referenziert werden.
Nachfolgende Elemente repräsentieren eine Substruktur und sollten deshalb in eigene Seiten ausgelagert werden:
Lvl | Bezeichnung | „CDA Name“ |
---|---|---|
Patient | recordTarget | |
Author | Author | |
Unterzeichner | legalAuthenticator | |
Informant | Informant | |
Teilnehmer | participant | |
Aufenthalt | encounter | |
... |
Andere Informationen sind wesentlich einfacherer Natur und können in der Hauptseite selber untergebracht werden.
Lvl | Bezeichnung |
---|---|
0 | Document Type |
0 | Document Template |
0 | Document ID |
0 | ... |
Zusammenbindung der Teile des Dokumenten-Headers (Artefakte)
Die Artefakte im Header müssen zusammengestellt werden, um bspw. Konformanzaspekte zu berücksichtigen. Dies sollte nach folgendem Schema passieren.
Artefakt | Bezeichnung | Kardinalität |
---|
Diese Aufstellung hat am Beginn der Header-Spezifikation zu erfolgen.
Abschnitte des Dokumenten-Bodies (Artefakte)
Nachfolgende Liste stellt Beispiele von Abschnitten dar.
Lvl | Bezeichnung |
---|---|
1 | Einleitung |
1 | Konzept und Begründung |
1 | Modellbeschreibung |
1 | Dynamisches Modell, Use Cases, Storyboards, etc. |
1 | CDA-Header |
1 | CDA-Body |
1 | Gemeinschaftliche Definitionen |
1 | Transport |
1 | Unterstützende Dokumente |
1 | Anhang |
1 | ... |
Diese Abschnitte sollten je spezifiziertem Dokument – sofern sie von der Grundlage abweichen – direkt aufgelistet bzw. über transcludes eingebunden werden.
Sektionen = Inhaltliche Abschnitte (Übersichtsseite + eigene Seite)
Nachfolgend eine (unvollständige) initiale Aufstellung der Abschnitte aus bereits in Arbeit befindlichen Implementierungsleitfäden:
Inhalt | Bezug | Kap. |
---|---|---|
Anrede | VHitG Arztbrief | 6.6.1 |
Fragestellung | VHitG Arztbrief | 6.6.2 |
Anamnese | VHitG Arztbrief | 6.6.3 |
Befunde | VHitG Arztbrief | 6.6.4 |
Diagnosen | VHitG Arztbrief | 6.6.5 |
Tumordiagnosen | Diagnoseleitfaden | |
Besondere Hinweise (Cave) | VHitG Arztbrief | 6.6.6 |
Therapien/Behandlungsmaßnahmen | VHitG Arztbrief | 6.6.7 |
Notizen | VHitG Arztbrief | 6.6.8 |
Epikrise | VHitG Arztbrief | 6.6.9 |
Anhänge | VHitG Arztbrief | 6.6.10 |
Schlusstext | VHitG Arztbrief | 6.6.11 |
Externe Dokumente | VHitG Arztbrief | 6.6.12 |
Mikroskopischer Befund | Pathobefund | |
Makroskopischer Befund | Pathobefund | |
Färbung | Pathobefund | |
... | Pathobefund | |
Infektionskrankheit | Infektionsschutz | |
Todesangabe | Infektionsschutz | |
Epidemiologische Situation | Infektionsschutz | |
Infektionsquelle | Infektionsschutz | |
Impfungen | Infektionsschutz |
Dazu kommt noch die Übersicht aus IHE PCC TF (als Referenz). Dies kann relativ einfach entweder als einzelne Tabelle auf einer Seite geschehen, oder etwas aufwändiger als jeweils eigene Seite, die dann nur minimale Informationen inkl. Template-ID mit Referenz auf das Technical Frame-work umfasst.
Zusammenbindung der Sektionen des Dokumenten-Bodies (Artefakte)
Die Artefakte im Body müssen zusammengestellt werden, um bspw. Konformanzaspekte zu berücksichtigen. Dies sollte nach folgendem Schema passieren.
Sektion | Bezeichnung | Kardinalität | Template-ID |
---|
Diese Aufstellung hat am Beginn der Body-Spezifikation zu erfolgen.
Textstrukturierung (aus Kap. 6.4)
Für die Angabe von Texten in einer Sektion sollten Randbedingungen eingehalten werden, die einmal generisch im „Arztbrief 2.0“ beschrieben sind. Hier ist dann der Namespace „cdamain“ zu verwenden.
Inhalt | Kap. |
---|---|
Listen | 6.4.1 |
Tabellen | 6.4.2 |
Unterabschnitte | 6.4.3 |
Überschriften | 6.4.4 |
Referenzierter Inhalt(content) | 6.4.5 |
Superskripts und Subskripts | 6.4.6 |
Zeilenumbrüche | 6.4.7 |
Fußnoten | 6.4.8 |
Referenz zu Multimedia-Inhalten | 6.4.9 |
Sonstige Zeichenstile | 6.4.10 |
Level 3 Elemente (Übersichtsseite + eigene Seite)
Inhalt | Element | Bemerkung | Kap. |
---|---|---|---|
Diagnose | Diagnose | ||
Prozedur | |||
SubstanceAdministration | Medikation | ||
Observation | Befund | ||
Organizer | |||
Battery | |||
... |
Konkrete Inhalte
Dokumenttypen (eigene Seite im Wiki)
Nachfolgend eine Liste von Dokumenttypen, die in verschiedenen Quellen benannt/benutzt werden und abgebildet werden sollen. In den beiden rechten Spalten ist ein Bezug zum eBPG-Projekt bzw. eFA angegeben.
Diese Struktur ist nur ein erster Vorschlag, der überarbeitet und ergänzt werden kann.
Es wäre zu überlegen, wenn die Dokumententaxonomie den Vorgaben von LOINC folgt, also z.B. auch Rücksicht nimmt auf die Achsen "setting" und "time" etc.