Governance für die CDA-Leitfadenerstellung (Version 1)

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][geprüfte Version]
(Namespace)
(Art-Decor Projekt)
 
(240 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{#customtitle:Governance für die CDA-Leitfadenerstellung mit Art-Decor und Mediawiki}}
+
{{#customtitle:Governance für die CDA-Leitfadenerstellung (Version 1)}}
 +
{{#css:
 +
.toc{
 +
    width: 20%;
 +
    float: right !important;
 +
    margin: 10px 0px 10px 30px !important;
 +
    border: 1px solid #AAA;
 +
    background-color: #F9F9F9;
 +
    display: table;
 +
    padding: 7px !important;
 +
}
 +
}}
 +
 
 +
<pre class="ilfbox_code">
 +
Governance für die CDA-Leitfadenerstellung mit Art-Decor und Mediawiki
 +
Version: 1.1.1+20230503
 +
Status: Final
 +
</pre>
 +
 
  
 
<!--
 
<!--
Zeile 6: Zeile 24:
 
|Short    = Art-Decor Governance  
 
|Short    = Art-Decor Governance  
 
|Type      = Governance
 
|Type      = Governance
|Version  = 0.1
+
|Version  = 1
|Date      = 07.11.2019
+
|Date      = 3.5.2023
|Copyright = 2019 - 2022
+
|Copyright = 2021 - 2025
|Status    = Draft
+
|Status    = Final
|Period    = 07.11.2019
 
|OID      = TODO
 
 
|Realm    = Österreich
 
|Realm    = Österreich
|Submitted = 07.11.2019}}
+
|Submitted = 3.5.2023}}
  
 
{{Versionbox Begin}}
 
{{Versionbox Begin}}
 
{{VersionboxEntry | Version = 0.1 | Date = 15.1.2019 | Status = Draft | Inititalversion beim Workshop mit Tony Schaller (CH)}}
 
{{VersionboxEntry | Version = 0.1 | Date = 15.1.2019 | Status = Draft | Inititalversion beim Workshop mit Tony Schaller (CH)}}
 
{{VersionboxEntry | Version = 0.2 | Date = 07.11.2019| Status = Draft| History=Überarbeitung und Einarbeitung der Erkenntnisse nach Erstellung des CDA-Leitfadens e-Impfpass}}
 
{{VersionboxEntry | Version = 0.2 | Date = 07.11.2019| Status = Draft| History=Überarbeitung und Einarbeitung der Erkenntnisse nach Erstellung des CDA-Leitfadens e-Impfpass}}
 +
{{VersionboxEntry | Version = 1 | Date = 14.12.2021| Status = Final| History=Überarbeitung}}
 +
{{VersionboxEntry | Version = 1.1.1 | Date = 3.5.2023| Status = Final| History=Überarbeitung Kapitel Value Sets}}
 
{{Versionbox End}}
 
{{Versionbox End}}
 
-->
 
-->
Zeile 26: Zeile 44:
 
|-
 
|-
 
! Status   
 
! Status   
| Draft
+
| Final
 
|-
 
|-
 
! Document version
 
! Document version
| 0.2
+
| 1
 
|-
 
|-
 
! Authors
 
! Authors
 
|  
 
|  
 
* Andrea Klostermann (ELGA GmbH)
 
* Andrea Klostermann (ELGA GmbH)
 +
* Gabriel Kleinoscheg (ELGA GmbH)
 
* Stefan Sabutsch (ELGA GmbH)
 
* Stefan Sabutsch (ELGA GmbH)
 +
* Nikola Tanjga (ELGA GmbH)
 +
|}
 +
-->
 +
 +
= Einleitung =
 +
Dieses Dokument enthält Richtlinien zur Erstellung von CDA-Implementierungsleitfäden mit Art-Decor® und Mediawiki und anderen Werkzeugen in Österreich.
 +
 +
Diese Richtlinien entstanden in Zusammenarbeit mit der ELGA GmbH und beruhen auf den bisher gemachten Erfahrungen in der Leitfadenerstellung.
 +
 +
Weiters werden die notwendigen Verantwortlichkeiten und Prozesse definiert, um klare Strukturen für die Zusammenarbeit zwischen Art-Decor®, Wiki und anderen Werkzeugen zu gewährleisten. Dies umfasst die Verantwortung für Art-Decor Repositories, Qualitätssicherung und den Support der Tools.
 +
 +
= Anwendungsbereich =
 +
Das Dokument geht nicht auf die Modellierung von HL7 CDA-Dokumenten ein, sondern beschreibt den Einsatz der Tools für Österreich. Es definiert Regeln und Strukturen, die von allen Anwendern dieser Werkzeuge eingehalten werden müssen.
 +
 +
= Weiterentwicklung des Dokuments =
 +
Dieses Dokument enthält die aktuellen Festlegungen bezüglich der Arbeit mit Art-Decor®, Mediawiki und weitere Werkzeuge in Österreich und wird laufend angepasst.
 +
{{BeginYellowBox}}''Wichtiger Hinweis:'' Anfragen hinsichtlich der Änderung oder Erweiterung dieses Dokuments stellen Sie bitte an [mailto:office@hl7.at office@hl7.at].{{EndYellowBox}}
 +
 +
=Governance für die CDA-Leitfadenerstellung=
 +
Die folgenden Vorgaben sind verpflichtend einzuhalten. Empfehlungen werden entsprechend markiert. Die Reihenfolge der Kapitel soll eine übliche Vorgehensweise darstellen, jedoch ist die Reihenfolge selbst nicht verpflichtend einzuhalten.
 +
==Governance Groups==
 +
Governance-Gruppen sind organisatorische Einheiten, die dazu dienen, die Verantwortung für Artefakte (Templates und Value Sets) in Art-Decor darzustellen. Unter der [https://art-decor.org/art-decor/decor-governance-group?id=1.2.40.0.34.3.1.2 ELGA Art-Decor Governance Group] sind alle Projekte der ELGA sichtbar, sowie alle angelegten Artefakte mit OID, Displayname, Artefaktstatus, BBR und Repositories), z.B. "at-cda-brr"-Projekte, die das Template oder Value Set referenzieren. Weiters existiert die [https://art-decor.org/art-decor/decor-governance-group?id=2.16.840.1.113883.2.16 HL7 Austria Art Decor Governance Group], welche alle eHealth Austria Vorgaben umfasst. Dabei wird die hier beschriebene ELGA Governance auch für die HL7 Austria relevant und soll von dieser übernommen werden. 
 +
 +
==Implementierungsleitfaden (inkl. Wiki)==
 +
'''ELGA Implementierungsleitfäden''' werden in '''deutscher Sprache''' verfasst. Dazu gehören textuelle Beschreibungen im Wiki, Art-Decor-Templates und Art-Decor-Datasets.
 +
Ausnahmen gelten bei der Benennung von Templates (siehe [[#Name]]).
 +
 +
'''eHealth Implementierungsleitfäden''' können auch in englischer Sprache verfasst werden.
 +
 +
Wichtige Informationen hinsichtlich der '''technischen''' Erstellung eines CDA-Leitfadens mit Mediawiki sind unter [https://wiki.hl7.at/index.php?title=Hilfe:Wiki Leitfaden erstellen mit Mediawiki] nachzulesen.
 +
 +
Die Einbindung eines neuen Leitfadens folgt einem vorgegebenen Prozess, dieser ist ersichtlich unter Benutzung von [https://wiki.hl7.at/index.php?title=Hilfe:Flagged_Revisions#Benutzung_von_Flagged_Revisions Flagged Revisions].
 +
 +
=== Name ===
 +
Der '''Name''' eines Leitfadens wird wie folgt angegeben:
 +
 +
* HL7 Austria & ELGA
 +
* HL7 CDA® R2 Implementierungsleitfaden
 +
* '''[Titel]'''
 +
* OID: '''[OID]'''
 +
 +
 +
''Beispiel:''
 +
 +
HL7 Austria & ELGA
 +
 +
HL7 CDA® R2 Implementierungsleitfaden
 +
 +
Labor- und Mikrobiologiebefund
 +
 +
OID: 1.2.40.0.34.7.4.9.3
 +
 +
===OID===
 +
Im Zusammenhang mit der Verwendung von OID sind die österreichischen Richtlinien einzuhalten (siehe [https://www.gesundheit.gv.at/OID_Frontend/OID_Konzept_1-1-0.pdf Object Identifier (OID) Konzept für das österreichische Gesundheitswesen]). Das österreichische OID Portal ist zu finden unter [https://www.gesundheit.gv.at/OID_Frontend/ OID Portal Österreich].
 +
 +
Für jeden Implementierungsleitfaden muss über das '''OID-Portal''' eine Dokumentenklassen-OID unterhalb des Knotens '''1.2.40.0.34.7''' (eHealth-Austria/documents) '''registriert''' werden.
 +
 +
Für die Verwaltung der Hauptversionen muss darunter eine '''zusätzliche Ebene''' angelegt werden.
 +
 +
''Beispiel:''
 +
*1.2.40.0.34.7.'''18''': Dokumentenklassen-OID des Implementierungsleitfadens "Meldung von antimikrobieller Resistenzen"
 +
**OID wird im OID-Portal beantragt (Root-Knoten aller Versionen des entsprechenden Leitfadens)
 +
*1.2.40.0.34.7.'''18.1''': Implementierungsleitfaden Meldung von antimikrobieller Resistenzen, Version 1
 +
**OID des PDF-Leitfadens (Titelblatt)
 +
**wird im DLT als templateId[2] als informative Referenz angegeben
 +
**Hauptversionen verlangen eine neue Verordnung durch das BM*G
 +
**OID wird ebenfalls im OID-Portal beantragt
 +
Die Leitfaden-OID von Nebenversionen ändert sich nicht. Die Version des Leitfadens ist im Leitfadentitel (Wiki) bzw. auf dem Titelblatt (PDF) und dem Versionlabel des DLT ersichtlich. Siehe [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung].
 +
 +
===Version & Metadaten===
 +
Der Verwendung von Namespaces ist wesentlich für Versionierung der Wiki-Seiten mit Flagged Revisions.
 +
{{BeginYellowBox}}''Wichtiger Hinweis:'' Alle Seiten von CDA-Leitfäden müssen im Namespace ["ILF"] erstellt werden.{{EndYellowBox}}
 +
Das Wiki-Leitfadenprojekt DARF NICHT unabhängig vom ART-DECOR-DLT versioniert werden, siehe [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung].
 +
 +
Alle '''Hauptversionen und Nebenversionen''' eines Leitfadens sind als '''Wiki''' verfügbar. In der "Lese-Ansicht ist die publizierte Version ersichtlich, aktuelle (noch nicht freigegebene) Überarbeitungen/Änderungen sind der "Revisions-Ansicht" zu entnehmen. Zum Zeitpunkt der Publikation (z.B. Ballotversion / Publikation neue Haupt- oder Nebenversion) wird die Hauptseite des Leitfadens von einer berechtigten Person als "abgenommen" markiert (siehe dazu [https://wiki.hl7.at/index.php?title=Hilfe:Wiki#Versionierung_von_Wiki-Seiten Versionierung von Wiki-Seiten]), sodass die "Revisions"-Ansicht in die stabile "Leseansicht" übernommen wird. Die "Leseansicht" bleibt unverändert, bis eine neue Version des Leitfadens abgenommen wird.
 +
 +
Alle veröffentlichten Leitfadenversionen sind zusätzlich zum Wiki als PDF verfügbar (Anleitung siehe [https://wiki.hl7.at/index.php?title=Hilfe:Leitfaden_erstellen#PDF_Generierung PDF-Generierung]). Eine Übersicht der Versionen eines Leitfadens findet sich im jeweiligen Guide (alle vorhandenen Guides sind zu finden unter [https://wiki.hl7.at/index.php?title=Implementierungsleitf%C3%A4den Übersicht der CDA Implementierungsleitfäden].
 +
 +
===Inhalt===
 +
Der Inhalt eines Implementierungsleitfadens besteht üblicherweise aus den Kapiteln:
 +
 +
:1 Zusammenfassung
 +
:2 Informationen über dieses Dokument
 +
::2.1 Impressum
 +
::2.2 Haftungsausschluss
 +
::2.3 Sprachliche Gleichbehandlung
 +
::2.4 Lizenzinformationen
 +
:::2.4.1 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")
 +
:::2.4.2 SNOMED CT
 +
:::2.4.3 Weitere Terminologien
 +
::2.5 Verwendete Grundlagen und Bezug zu anderen Standards
 +
::2.6 Verbindlichkeit
 +
::2.7 Wichtige unterstützende Materialien
 +
::2.8 Bedienungshinweise
 +
:::2.8.1 Farbliche Hervorhebungen und Hinweise
 +
:::2.8.2 PDF-Navigation
 +
:3 Begriffsdefinitionen
 +
:4 Einleitung
 +
::4.1 Ausgangslage und Motivation
 +
::4.2 Zweck des Dokuments
 +
::4.3 Zielgruppe
 +
:5 Leitfadenerstellungs- und Harmonisierungsprozess
 +
::5.1 Revision der Leitfäden
 +
::5.2 Autoren und Mitwirkende
 +
:::5.2.1 Autoren
 +
:::5.2.2 Mitwirkende
 +
:6 Technischer Hintergrund
 +
:7 Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden
 +
:8 Funktionale Anforderungen
 +
::8.1 Voraussetzungen für den Zugriff auf e-Befunde in ELGA
 +
::8.2 Anwendungsfälle des Dokumentenmanagements
 +
:::8.2.1 Dokument-Metadaten (XDS-Metadaten)
 +
:9 Konformitätsprüfung
 +
:10 Datentypen
 +
:11 Vorgaben zum medizinischen Inhalt
 +
:12 Anwendungsfälle / User Stories
 +
:13 Dataset
 +
:14 Technische Spezifikation
 +
::14.1 Übersicht CDA Strukturen (Header & Body)
 +
::(evtl. Übersichtstabelle der Header-Elemente für dokumenten-relevante Zeitpunkte/Zeitspannen)
 +
::14.2 CDA Templates
 +
:::14.2.1 Document Level Templates
 +
:::14.2.2 Header Level Templates (Hinweis: hier sollten nur jene Header Level Templates aufgeführt werden, die für spezielle Leitfäden erstellt / adaptiert wurden. Alle anderen werden als Teil der DLTs angezeigt)
 +
:::14.2.3 Section Level Templates
 +
:::14.2.4 Entry Level Templates
 +
:::14.2.5 Weitere CDA Fragmente
 +
::14.3 Terminologien
 +
:15 Anhang
 +
::(15.1 evtl. Abkürzungsverzeichnis)
 +
::15.2 Abbildungsverzeichnis
 +
::15.2 Tabellenverzeichnis
 +
::15.3 Einzelnachweise
 +
::15.4 Literatur und Weblinks
 +
::15.5 Revisionsliste
 +
::15.6 Erratum
 +
 +
 +
Bei Kapiteln ohne Inhalt soll kurz darauf eingegangen werden, warum dieser Leitfaden dieses Kapitel nicht füllt.
 +
 +
Aufgrund bisheriger Erfahrungen wird '''nicht empfohlen''', Textabschnitte in Teildokumente (eigene Wiki-Seiten) '''auszulagern und zu [https://de.wikipedia.org/wiki/Transklusion transkludieren]''', da Änderungen an dem Teildokument automatisch in alle transkludierenden Wiki-Leitfäden übernommen werden und einer Abstimmung mit den Leitfadenverantwortlichen bedürfen. Weiters ist beim Bearbeiten eines Seitenabschnittes nur im Seitenlink bzw. unter Menüpunkt "Links auf diese Seite" ersichtlich, ob man sich auf der Hauptseite des eigenen Leitfadens oder auf einer bereits transkludierten Seite befindet, was die Gefahr eines unbeabsichtigten Änderns anderer bestehender Leitfäden erhöht.
 +
 +
Ausnahmen bilden folgende Seiten, welche transkludiert werden können, aber '''nicht bearbeitet werden dürfen''' (liegen in der Obhut des Allgemeinen Leitfadens):
 +
*ILF:Lizenzinformationen
 +
Für die '''Kapitel Section Level Templates, Entry Level Templates''' und '''Weitere CDA Fragmente''' in speziellen Leitfäden gilt, dass für Templates, die im Allgemeinen Implementierungsleitfaden spezifiziert sind, eine einfache Referenz auf den Allgemeinen Implementierungsleitfaden ausreicht. Dabei MUSS aber angegeben werden, um welche Hauptversion des Allgemeinen Leitfaden es sich handelt.
 +
 +
=Art-Decor Projekt=
 +
Ein neuer CDA-Leitfaden '''muss''' in einem eigenen Projektverzeichnis angelegt, alle Autoren müssen entsprechend berechtigt werden. Dies muss beim [https://www.art-decor.org/mediawiki/index.php?title=Contact Art-Decor-Support] beantragt werden.
 +
 +
Das neue Projekt kann am besten mit folgendem E-Mail-Template beantragt werden:
 +
{{BeginValueSetBox}}Dear Art-Decor-Support,
 +
we would like to ask you to create a new project in Art-Decor:
 +
*Name: <'''displayName des Projekts'''>
 +
*Prefix: <'''Projektkürzel''' - soll immer mit at- beginnen, z.B. "at-emed-" oder "at-lab-" (Vorweg: an bestimmten Stellen werden Bindestriche durch das System ausgeblendet)>
 +
*ContainsReusableContent=false
 +
*Experimental/Test=false
 +
*defautLanguage=de
 +
*id=1.2.40.0.34.777.<'''nächste freie ID''', siehe Kapitel OID>
 +
*Governance-Groups: ELGA, HL7 Austria
 +
*Wiki-Bot activated à wiki.hl7.at
 +
 +
Thank you in advance.{{EndValueSetBox}}
 +
 +
 +
Eine Liste der Art-Decor Projekte ist unter der HL7-Austria Governance Group verfügbar [https://art-decor.org/art-decor/decor-governance-group?id=1.2.40.0.34.3.1.2 ELGA Art-Decor Governance Group].
 +
 +
Weitere offizielle Informationen sind unter [https://www.art-decor.org/mediawiki/index.php?title=ART_Project_Editor ART Project Editor] zu finden.
 +
 +
==Name==
 +
Der Name des Projekts, auch displayName des Projekts genannt, soll sprechend gewählt werden und ist mit dem ELGA SCC Team abzusprechen.
 +
 +
Dies gilt auch für das Prefix, auch Projektkürzel genannt. Dabei soll dieses keine Bindestriche enthalten, z.B. "''elgatest''".
 +
 +
==OID==
 +
Alle Art-Decor Projekte bekommen die unter ([https://art-decor.org/art-decor/decor-governance-group?id=1.2.40.0.34.3.1.2 Governance Group (art-decor.org)] -> Projects) einsehbaren OID mit der nächste ID im 1.2.40.0.34.777 Knoten.
 +
 +
==Version & Metadaten==
 +
Projekte selbst werden nicht versioniert. Nur die beinhaltenden DLT werden versioniert.
 +
 +
Projektkürzel unter "prefix" werden im lowercase geschrieben, ohne jegliche Trennzeichen. Bsp.: "elgatgd".
 +
 +
Neue Projekte dürfen keine bbr sein! Die Checkbox [[Datei:Image2021-6-24 13-41-12.png|200px]] darf nicht angehackt sein!
 +
 +
Es wird empfohlen dem Projekt standardmäßig Referenzen zu den Building Block Repositories ''ad1bbr-, ad2bbr-, at-cda-bbr-, IHE-PCC-'' hinzuzufügen (siehe auch [https://www.art-decor.org/mediawiki/index.php?title=ART_Project_Editor#Reference_a_building_block_repository Reference a building block repository]).
 +
 +
==Inhalt==
 +
In Österreich kann derzeit folgendes bereichsspezifische '''Building Block Repository''' (BBR) für die Ableitung oder Referenzierung von Templates verwendet werden:
 +
*[https://art-decor.org/art-decor/decor-project--at-cda-bbr- at-cda-bbr]
 +
Dies soll in Zukunft alle für Österreich relevanten Basis-Templates enthalten, die für spezifische Anwendungen (eHealth und ELGA) in die einzelnen Projektverzeichnisse abgeleitet werden können.
 +
 +
Das at-cda-bbr wird laufend mit neuen Templates erweitert. Nach Fertigstellung eines neuen CDA-Leitfadens sollen weiter zu verwendete Templates in dieses Verzeichnis übernommen werden. Die im at-cda-bbr befindlichen Templates dürfen nur von einem eingeschränkten Benutzerkreis bearbeitet werden.
 +
 +
===Statuswechsel eines Templates===
 +
In einem Repository werden Artefakte (Templates/Value Sets) zunächst im Status "Entwurf" erstellt. Der Status eines Artefakts im Repository kann gemäß den Regeln der hier beschriebenen Governance geändert werden (siehe [https://art-decor.org/mediawiki/index.php?title=ART_Template_Editor#Changing_the_status_of_a_template "Changing the status of a template"]).
 +
 +
{|
 
|-
 
|-
! unter Mitwirkung von
+
| [[Datei:Kyellow.png|15px|rahmenlos|left]]||Entwurf: Das Template verbleibt bis zur Veröffentlichung im Status „Entwurf“ und ist bearbeitbar.
| Tony Schaller (IHE Suisse)
+
|-
 +
|[[Datei:Kgreen.png|15px|rahmenlos|left]]||Aktiv: Gültiges Template, dessen Inhalt nicht mehr verändert werden kann. Zum Bearbeiten (Entwurf) muss das Template eine neue Version bekommen.
 +
|-
 +
|[[Datei:Kdeprecblue.png|15px|rahmenlos|left]]||Veraltet: Aktive Templates, die nicht mehr verwendet werden sollen, können in den Status „veraltet“ versetzt werden. Dieser Status ist endgültig.
 
|}
 
|}
-->
 
  
= Zusammenfassung =
+
{| class="wikitable"
Dieses Dokument enthält Richtlinien zur Erstellung von CDA-Implementierungsleitfäden mit Art-Decor® und Mediawiki in Österreich.
+
|-
 +
|[[Datei:TemplateStatuswechsel2021-9-22.png|top]]|| '''Beschreibung Statuswechsel eines Templates (Diagramm)'''
 +
 
 +
'''1.''' Bevor ein Template neu angelegt wird, soll überprüft werden, ob ein verwendbares Dummy-Template(*) vorhanden ist. Ein neues Template erhält immer Version 1.0.0 und hat den Status "'''Entwurf'''".
 +
 
 +
'''2.''' Nach erstmaliger Erstellung eines Templates oder nach Durchführung von Major- oder Minor-Änderungen, muss vor der Publikation ("Aktiv-Setzung" des Templates) ein Ballotverfahren durchgeführt werden. (Der Status "Revision vor Publikation" kann verwendet werden, um anzuzeigen, dass eine Publikation bevorsteht. Vom Status "Revision vor Publikation" kann in den Stauts "Aktiv" gewechselt werden.)
 +
 
 +
'''3.''' Wurde ein Ballotverfahren durchgeführt, erfolgt der Template-Statuswechsel zu "'''Aktiv'''" zum Publikationszeitpunkt des Leitfadens. Wird ein Template "Aktiv" gesetzt, wird die bestehende Versionsnummer im Version-Label mit dem Publikationsdatum  ergänzt (z.B. 1.0.0+20210504, siehe [[https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung]). (Der Status "Revision nach Publikation" kann verwendet werden, um anzuzeigen, dass eine neue Version vorbereitet wird. Vom Status "Revision nach Publikation" kann man wieder in den "Aktiv" Status wechseln.)
 +
 
 +
'''4.''' Solange keine Änderungen an dem Template durchgeführt werden müssen, werden verbleibt es im Status "Aktiv".
 +
 
 +
'''5.''' Ist das Template veraltet oder wird es durch ein neues ersetzt, muss der Status auf "'''veraltet'''" gesetzt werden ('''6.'''). Dieser Status ist unveränderbar (Status endgültig). Veraltete Templates, scheinen weiterhin in referenzierenden Templates auf.
 +
 
 +
'''7.''' Sind Änderungen eines aktiven Templates erforderlich, muss unterschieden werden, ob es sich um Minor/Major-Änderungen oder um einen Patch handelt.
 +
 
 +
'''8.''' Handelt es sich um einen Patch oder wurden die Änderungen von den referenzierenden Leitfäden akzeptiert, kann mit "'''neue Version erzeugen'''" eine neue Templateversion von Art-Decor erstellt werden. Diese hat den Status "Entwurf", die '''gleiche Template-OID''', aber ein neues Erstellungsdatum. Die Versionsnummer im Version-Label des Templates muss an der entsprechenden Stelle um 1 erhöht werden (siehe [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung]).
 +
 
 +
'''9.''' Sind die Änderungen nicht von allen referenzierenden Leitfäden gewünscht oder noch nicht bekannt ob dies des Fall ist, muss eine "'''neue Bearbeitung'''" dieses Templates erstellt werden. Es erhält eine '''neue Template-OID''', Version 1.0.0, siehe [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung]). Die neue Bearbeitung kann ein Zwischenschritt sein, um kurzzeitig eine Major-Änderung für eine neue Version eines Templates zu erstellen, welche kurz vor Ballot dann als neue Version des originalen Templates erstellt wird.
 +
'''10.'''Major und Minor-Änderungen an Templates erfordern (unabhängig davon, ob eine neue Version oder eine neue Bearbeitung erstellt wurde), immer ein Ballotverfahren vor Aktiv-Setzung des Templates. Patch-Änderungen können sofort "Aktiv" gesetzt werden, sollten jedoch idealerweise ebenfalls im Rahmen eines Ballotverfahrens "Aktiv" gesetzt werden.
 +
 
 +
''(*) Anmerkung: Wird ein Template im Status „Entwurf“ nicht mehr benötigt (und wird auch von keinem anderen Leitfaden referenziert), soll es '''nicht auf "annulliert"''' oder '''"zurückgewiesen"''' gesetzt werden, sondern stattdessen soll der Inhalt gelöscht, der Titel auf „dummy“ (o.ä) umbenannt und die Template-Id auf .999 geändert werden. Dieses Dummy-Template kann später für neue Templates verwendet werden. Durch das Löschen des Inhalts werden auch evtl. bestehende Referenzen (Beziehungen zu anderen Templates) entfernt, und es scheint auch nicht mehr in den Beziehungen der referenzierenden Templates auf.''
 +
|}
 +
 
 +
= Datasets =
 +
Die Verwendung von Art-Decor-Datasets wird für neue Projekte empfohlen. Diese bilden die funktionalen Anforderungen an das Projekt ab und sind Diskussionsgrundlage bei Fachexpertengesprächen (erfordern kein technisches Hintergrundwissen).
 +
 
 +
Für Datasets gibt es '''keine speziellen Vorgaben''' hinsichtlich '''OID und Version & Metadaten'''.
 +
 
 +
Bereits bei der Modellierung der Datasets sollen bestehende Standards berücksichtigt werden (z.B. IHE PCC) und bestehende Dataset-Elemente so gut es geht '''aus anderen Projekten wiederverwendet''' werden (siehe auch [https://www.art-decor.org/mediawiki/index.php?title=DECOR-dataset#Dataset_versioning Dataset versioning]). Dies funktioniert durch die Eingabe eines Names und dem mit etwas Ladezeit folgendem Vorschlag von ähnlichen Konzepten. Dabei sollte der Sinn des Datasets, der aus der Beschreibung hervorkommt, derselbe sein. 
 +
 
 +
Weitere offizielle Informationen sind unter [https://www.art-decor.org/mediawiki/index.php?title=ART_Dataset_Editor ART Dataset Editor] zu finden.
 +
 
 +
== Name ==
 +
Es gibt keine speziellen Namenskonoventionen, der '''Name''' ist jedoch '''anzugeben'''!
 +
 
 +
== Inhalt ==
 +
Es ist eine '''Beschreibung''' und der '''Werttyp/Valuetype''' anzugeben.
 +
 
 +
'''Wenn vorhanden''' muss zusätzlich angegeben werden:
 +
 
 +
* '''Auswahllisten'''
 +
* Link zu '''codierten Konzepten / Value Sets''' (Terminologien)
 +
 
 +
Die Zuordnung von Dataset-Elementen und erstellten Templates unter "Template" → "Template-Mapping" wird '''empfohlen, ist aber nicht verpflichtend''' (siehe auch [https://www.art-decor.org/mediawiki/index.php?title=ART_Template_Associations ART Template Associations]). Dadurch sind alle mit einem Template assoziierten Konzepte in der Template-Beschreibung zusammengefasst, sowie direkt beim assoziierten CDA-Element bzw. Attribut des Templates ersichtlich. Dies dient der Kontrolle (auch für die Experten-/Arbeitsgruppe), dass alle erforderlichen Dataset-Elemente in den Templates modelliert wurden.
  
Diese Richtlinien sollen als Empfehlungen und Best Practices dienen, um eine nationale und auch internationale Konformität und eine harmonisierte Verwendung der Tools zu gewährleisten. Sie entstanden in Zusammenarbeit mit Tony Schaller (CH) und der ELGA GmbH (AT).  
+
= Templates =
Dieses Dokument wird laufend aktualisiert, sobald die Nutzer der Tools einen neuen Konsens erzielen.
+
Ein Leitfadenprojekt besteht aus '''einem oder mehreren Document Level Templates (DLT)''' (jedes DLT entspricht dabei einem Dokumententyp), welche die Struktur für ein gültiges CDA-Dokument vorgeben. Darüber hinaus werden in einem Leitfadenprojekt zahlreiche nicht-DLT-Templates referenziert, die im at-cda-brr spezifiziert wurden. Ein Leitfadenprojekt kann außerdem nicht-DLT-Templates beinhalten, die ausschließlich für das Projekt spezifiziert wurden. Für die Verwendung ist folgende Seite [https://www.art-decor.org/mediawiki/index.php?title=ART_Template_Editor ART Template Editor] zu lesen.
  
Weiters werden die notwendigen Verantwortlichkeiten und Prozesse definert, um klare Strukturen für die Zusammenarbeit zwischen Art-Decor und dem Wiki zu gewährleisten. Dies umfasst die Verantwortung für Art-Decor Repositories, Qualitätssicherung und den Support der Tools.
+
''Info: Solange das DLT noch nicht in der Transaktion des Szenarios verlinkt ist, wird dessen Label (im Template-Baum) als oranges Dreieck mit Pfeilen angezeigt, sonst als oranges Viereck/Buch.''
  
= Einleitung =
+
==Vorbedingungen für die Erstellung neuer Templates==
== Anwendungsbereich ==
+
Bevor neue Templates erstellt werden, sollte geprüft werden, ob bestehende Templates (bestenfalls im at-cda-bbr), die Anforderungen bereits erfüllen. Gibt es passende Templates können diese durch '''Referenzierung''' (unveränderte Übernahme) mittels Kettensymbol in das bestehende Projekt übernommen werden. In diesem Fall sind keine Änderungen an dem Template möglich! Diese Funktion sollte nur verwendet werden, wenn es bereits ein passendes ELGA-/e-Health-Template gibt.
Das Dokument geht nicht auf die Modellierung von HL7 CDA-Dokumenten ein, sondern beschreibt hauptsächlich den Einsatz der Tools Art-Decor und Mediawiki, begleitet von Do's und Don'ts für  Österreich. Sie definiert Regeln und Strukturen, die von allen Anwendern dieser Werkzeuge eingehalten werden müssen.
 
  
== Weiterentwicklung des Dokuments ==
+
Um herauszufinden, welche Art-Decor Projekte (auch außerhalb der eigenen Governance-Group) bereits ein bestimmtes Template umgesetzt haben, kann man im Menüpunkt '''„Auge“''' (links oben in der ArtDecor-Projektseite), die Template-ID oder den Namen eines Templates angeben -> alle Templates mit zugehörigem Projekt werden aufgelistet.
Dieses Dokument enthält die aktuellsten Fragen und Entscheidungen bezüglich der Arbeit mit Art-Decor und Mediawiki in Österreich und wird laufend angepasst.
 
{{BeginYellowBox}}
 
''Wichtiger Hinweis:'' Anfragen hinsichtlich der Änderung oder Erweiterung dieses Dokuments stellen Sie bitte an [[cda@elga.gv.at]].
 
{{EndYellowBox}}
 
  
= Art-Decor =
+
==Vorbedingungen für Änderungen bestehender Templates==
 +
Bevor ein bestehendes Template geändert wird (Erstellung einer neuen Version, welche automatisch von allen dynamisch referenzierenden Templates verwendet wird), ist zu überprüfen, wie sich diese Änderung auf andere Leitfäden auswirkt bzw. ob diese gewünscht ist. In allen betroffenen Leitfäden muss die Änderung auf der Diskussionsseite im Abschnitt "Ausblick" festgehalten werden.
  
== Sprache ==
+
''Zu Beachten:''
'''ELGA Implementierungsleitfäden''' werden in '''deutscher Sprache''' verfasst. Dazu gehören textuelle Beschreibungen im Wiki, Art-Decor-Templates und Datasets.
+
*Wenn eine neue Version eines aus dem ATCDABBR referenzierten Templates (graues Icon im Template-Baum) benötigt wird, MUSS diese im ATCDABBR erstellt werden.
 +
*Soll ein Template, das im ATCDABBR erstellt wurde, in ein Projekt-Repository verschoben werden, muss dort zuerst eine evtl. bereits existierende Referenz darauf entfernt werden.
 +
*Fehlen die Berechtigungen für schreibenden Zugriff auf das ATCDABBR, sollen die erforderlichen Anpassungen zuerst im Projekt-Repository durchgeführt werden und können nach abgeschlossenem Ballot von Berechtigten ins ATCDABBR übernommen werden.
  
Eine Ausnahme bilden '''Template-Namen'''. Diese sind grundsätzlich in '''englischer Sprache''' zu vergeben, sodass die Bezeichnungen entsprechend ihrer Definition in den anderen (internationalen) CDA-Leitfäden beibehalten werden können und die Wiederverwendbarkeit bestehender Templates in weiteren Leitfäden erleichtert wird.
+
== Name ==
Nur Template-Namen im '''CDA-Body''' werden auf '''deutsch''' vergeben, da diese den in den Arbeitsgruppen abgestimmten Titel der Sektion tragen sollen.
+
Template-Namen sind grundsätzlich in '''englischer Sprache''' zu vergeben, sodass sie entsprechend ihrer Definition in internationalen Standards beibehalten werden können und die Wiederverwendbarkeit bestehender Templates erleichtert wird.
  
== Verwendung von OIDs ==
+
Eine Ausnahme bilden die Namen von Section-Level Templates. Diese werden auf deutsch vergeben, da sie den in den Arbeitsgruppen abgestimmten Titel der Sektion tragen sollen. Bei einer möglichen Unterscheidung zwischen uncodiert und codiert, ist dies mit einem Bindestrich anzugeben. (Alte Schreibweise mit unkodiert und kodiert ist nicht mehr zu verwenden!)
Im Zusammenhang mit der Verwendung von OIDs sind die österreichischen Richtlinen einzuhalten
 
([https://www.gesundheit.gv.at/OID_Frontend/OID_Konzept_1-1-0.pdf Object Identifier (OID) Konzept für das österreichische Gesundheitswesen]).
 
Das österreichische OID Portal ist zu finden unter [https://www.gesundheit.gv.at/OID_Frontend/ OID Portal Österreich].
 
  
==OIDs für Implementierungsleitfäden==
+
'''Empfehlung für Entries''': Sind im Entry Referenzen auf andere Standards enthalten, soll der Name des Entries auch den entsprechenden Namen tragen (englisch). Ist dies nicht der Fall (im Entry gibt es z.B. nur eine ELGA Template ID), soll der Name des Entries an den Namen der Sektion angelehnt sein (deutsch).
{{BeginYellowBox}}
+
''Beispiel'': Die Sektion '''''"Impfungen - codiert"''''' (1.2.40.0.34.6.0.11.2.1) (mit AG abgestimmter Titel) referenziert durch Angabe der TemplateID (1.3.6.1.4.1.19376.1.5.3.1.3.23) auf den Standard IHE PCC (Immunizations Section) (und hält auch dessen Vorgaben ein). '''''"Impfungen - codiert"''''' beinhaltet u.a. ein Entry: '''''"Immunization Entry"''''' (1.2.40.0.34.6.0.11.3.1), welches wiederum laut Standarddefintion folgende Template IDs enthalten muss: HL7 CCD Medication activity (1.2.40.0.34.6.0.11.3.1) und IHE Immunizations Entry (2.16.840.1.113883.10.20.1.24). Daher trägt das Entry den Namen, der auch im Standard angegeben wird (mit dem Zusatz "Entry").
''Wichtiger Hinweis:'' Für '''jeden Implementierungsleitfaden''' muss (über das OID-Portal) eine OID '''unterhalb des Knotens 1.2.40.0.34.7''' (eHealth-Austria/documents)
 
'''registriert''' werden.
 
{{EndYellowBox}}
 
Falls Dokumente in aufeinander aufbauenden Versionen vorliegen, kann dafür darunter eine zusätzliche Ebene angelegt werden.  
 
  
  
Beispiel:  
+
Weitere Vorgaben für Name und Display-Name (Bezeichnung) eines Templates:
* 1.2.40.0.34.7.18: Implementierungsleitfaden Meldung von antimikrobieller Resistenzen 
+
*Der '''Name''' eines Templates wird wie folgt angegeben:
* 1.2.40.0.34.7.18.1: Implementierungsleitfaden Meldung von antimikrobieller Resistenzen - Version 1.00
+
:'''[Präfix]_[Template-Typ]_[ElementName]'''
 +
:Als Trenner fungieren Unterstriche ("_"), wobei folgendes gilt:
 +
:*'''[Präfix]:''' Als Präfix dient das Projektkürzel (Name des Repositories) ohne Bindestriche, z.B. "atcdabrr" oder "atlab". Diese Präfixe bleiben auch beim Verschieben ins at-cda-bbr bestehen!
 +
:*'''[Template-Typ]:''' Der Template-Typ muss einen der folgenden Template-Typen enthalten:
 +
::*"document": für Document-Level-Templates
 +
::*"header": für Header-Level-Templates
 +
::*"section": für Sektionen
 +
::*"entry": für Entries
 +
::*"other" : alle Templates/Fragmente, die nicht in obige Kategorien fallen ("Template type not specified")
 +
::*'''[ElementName]:''' Entspricht dem Display-Name ohne Leerzeichen, Bindestriche und Klammern "( )". Der ElementName wird in Upper-CamelCase-Notation angegeben.
 +
*Der '''Display-Name''' enthält nur den ElementName (kein Präfix oder Template-Typ), wobei aber Leerzeichen, Bindestriche und Klammern "( )" verwendet werden dürfen. Dieser wird in der Template-Baum-Struktur angezeigt.
  
==Art-Decor Root OIDs==
+
''Beispiele:''
Als neuer '''Root-Knoten für Art-Decor''' wird 1.2.40.0.34'''.6.0''' (eHealth-Austria/services) verwendet. Er enthält OID für Value Sets und Templates.
+
* '''Document-Level-Template''' im ELGA e-Impfpass Repository:
{{BeginYellowBox}}
+
::Name: "eimpf_document_KompletterImmunisierungsstatus"
''Wichtiger Hinweis:'' Die Verwaltung der unter diesen Knoten liegenden Templates und Value-Sets unterliegt Art-Decor und benötigt daher '''keine Registrierung''' über das '''OID-Portal'''.
+
::Display-Name: "Kompletter Immunisierungsstatus"
 +
* '''Header-Level-Template''' im at-cda-bbr:
 +
::Name: "atcdabbr_header_Author"
 +
::Display-Name: "Author"
 +
* '''Uncodierten Sektion''' im Repository at-cda-bbr:
 +
::Name: "atcdabrr_section_FruehereErkrankungUncodiert"
 +
::Display-Name: "Frühere Erkrankungen - uncodiert"
 +
* '''Codierten Sektion''' im ELGA e-Impfpass Repository:
 +
::Name: "eimpf_section_ImpfrelevanteErkrankungenCodiert"
 +
::Display-Name: "Impfrelevante Erkrankungen - codiert"
 +
* '''Entry''' im at-cda-bbr:
 +
::Name: "atcdabbr_entry_ImmunizationEntry"
 +
::Display-Name: "Immunization Entry"
 +
* '''Compilation/Other'''-Template im at-cda-bbr: Compilations/Other sind Template-Fragmente, wie z.B. Adressinformationen. Da sich diese in einem Leitfaden oft wiederholen können, sollen sie mit "contains" in Templates eingebunden werden (d.h. der Inhalt der Compilation wird nicht im verlinkenden Template angezeigt). Diese sollen aber im Leitfaden als eigene Kapitel vorhanden sein.
 +
::Name: "atcdabbr_other_AddressCompilation"
 +
::Display-Name: "Address Compilation"
  
Die nächste '''freie OID''' für '''Templates und Value-Sets''' muss über die [https://art-decor.org/art-decor/decor-governance-group?id=1.2.40.0.34.3.1.2 '''Art-Decor Governance Group'''], unter "List of Artefacts under this Governance Group" ermittelt werden.
+
== OID ==
{{EndYellowBox}}
+
OIDs werden einmalig gesetzt und nicht mehr geändert. Alle Art-Decor '''Templates''' müssen unterhalb des OID-Knotes 1.2.40.0.34.6.0'''.11''' liegen (eHealth-Austria/services/art-decor/templates). Die OID der Art-Decor Templates sollen außerdem '''entsprechend ihres CDA-Template-Typs''' aus folgenden '''Unterknoten''' vergeben werden:
<br>
+
:'''.0.''' Document-Level Template
===Root OIDs für Templates ===
+
:'''.1.''' Header-Level Template
Alle Art-Decor '''Templates''' müssen unterhalb des OID-Knotes 1.2.40.0.34.6.0'''.11''' liegen (eHealth-Austria/services/art-decor/templates).
+
:'''.2.''' Section-Level Template
Die OIDs der Art-Decor Templates sollen außerdem '''entsprechend ihres CDA-Template-Typs''' aus folgender Unterknoten vergeben werden:
+
:'''.3.''' Entry-Level Template
 +
:'''.9.''' other CDA Fragment Template
  
: '''.0 Document-Level Template'''
+
''Beispiele:''
: '''.1 Header-Level Template'''
+
* Header-Level-Template: 1.2.40.0.34.6.0.11.1.2 Author (eHealth-Austria/services/art-decor/templates/header/xxx)
: '''.2 Section-Level Template'''
+
* Entry-Level-Template: 1.2.40.0.34.6.0.11.3.15 Antikörper-Bestimmung Data Processing Entry (eHealth-Austria/services/art-decor/templates/entry/xxx)
: '''.3 Entry-Level Template'''
+
{{BeginYellowBox}}''Wichtiger Hinweis:''Die Verwaltung der unter diesen Knoten liegenden Templates unterliegt Art-Decor und benötigt daher '''keine Registrierung''' über das '''OID-Portal'''. Die nächste '''freie OID''' für '''Templates''' muss über die [https://art-decor.org/decor/services/GovernanceGroupList?gg=1.2.40.0.34.3.1.2&language=en-US&format=html#tabs1-templates1 '''ELGA Art-Decor Governance Group Template'''] (Vorsicht!: lange Ladezeit) ermittelt werden.{{EndYellowBox}}
: '''.9 other CDA Fragment Template'''
 
  
Beispiele:
+
== Version & Metadaten ==
*Header-Level-Template:
 
: 1.2.40.0.34.6.0.11.1.2 Author (eHealth-Austria/services/art-decor/templates/header/xxx)
 
*Entry-Level-Template:
 
: 1.2.40.0.34.6.0.11.3.15 Antikörper-Bestimmung Data Processing Entry (eHealth-Austria/services/art-decor/templates/entry/xxx)
 
  
===Root OIDs für Value Sets===
+
* Für neu angelegte Templates (''Entwurf''-Status) soll im Version Label die '''Version''' 1.0.0 angegeben werden. Wenn das Template ''aktiv'' gesetzt wird, wird das aktuelle Datum ergänzt. Nur das DLT erhält immer das Datum, an dem der Leitfaden veröffentlicht wird. Die genauen Vorgaben zur Versionierung sind hier zu nachzulesen [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung].
Alle Art-Decor '''Value-Sets''' müssen unterhalb des OID-Knotes 1.2.40.0.34.6.0'''.10''' liegen (eHealth-Austria/services/art-decor/value-sets).
+
* Der Zweck des Templates muss aus der '''Beschreibung''' hervorgehen. Im Fall von generischen Templates, die im at-cda-bbr angelegt werden und abgeleitet werden müssen (z.B. weil noch kein Value Set referenziert wurde), soll die Beschreibung möglichst allgemein gehalten werden.
 +
* Modellierung der Templates  "'''offen/geschlossen'''":
 +
** ELGA Implementierungsleitfäden werden seit 2020 "geschlossen" modelliert. Somit können nur die Elemente verwendet werden, die explizit modelliert werden oder durch den Datentypen implizit erlaubt sind. Sobald bei einem Element mit gesetzten Datentypen ein Unterelement einfügt wird, sind die vom Datentypen möglichen Elemente nicht mehr implizit erlaubt, sondern müssen nun auch explizit modelliert werden. Attribute sind davon ausgenommen.
 +
** Templates von eHealth Implementierungsleitfäden können auch "offen" modelliert werden.
 +
* Es ist zumindest ein korrektes '''Beispiel''' anzugeben.
  
==Versionierung==
+
Beim '''Ableiten von Templates''' ist durch einen der folgenden '''Beziehungstypen''' anzugeben, wie sie sich zueinander verhalten (siehe auch [https://www.art-decor.org/mediawiki/index.php?title=ART_Template_Editor#Creating_a_new_version_of_an_existing_template Creating a new version of an existing template]). Die Template-ID des Basistemplates wird nur zu Zwecken der Nachvollziehbarkeit in den Metadaten angegeben, in der Template-Spezifikation selbst muss sie entfernt werden, weil dies sonst bei der Generierung von "closed" Schematron-Regeln zu Inkonsistenzen und zu falsch-positiven Schematron-Fehlern bei der Validierung führen kann.
==Versionierung von Templates ==
 
===Document-Level Templates===
 
Für jede neue Version eines Document-Level Templates ist eine neue OID zu verwenden. Der Bezug zur alten OID ist anzugeben. Dadurch wird die Anwendung der korrekten Schematron-Regeln gemäß dem getesteten CDA-Dokument sichergestellt.
 
  
===Alle anderen Templates===
+
* '''Spezialisierung''': bestehende Vorgaben werden weiter '''eingeschränkt''' (z.B. von [O] auf [M] oder von 0..* auf 0..1, ebenfalls [O] auf [NP])
TODO
+
* '''Adaptierung''': bestehende Vorgaben werden '''erweitert oder geändert''' (z.B. von [M] auf [O] oder von 0..1 auf 0..*) oder neue Elemente, Attribute, ValueSets, Fixe Werte werden hinzugefügt.
  
==Versionierung von Value-Sets==
+
Die Übernahme vorhandener Templates aus Projektverzeichnissen, die '''NICHT referenziert''' sind, ist nicht über die GUI möglich, weil diese Templates nicht als Prototyp angegeben werden können (d.h. von ihnen kann nicht geerbt werden).
Die '''OIDs''' der Value-Sets bleiben '''für alle Versionen gleich''', werden aber durch das Gültigkeitsdatum '''"effectiveDate"''' unterschieden ("Gültig ab"). Darüber hinaus kann eine Value-Set ein '''offizielles Freigabedatum''' tragen. <br><br>
 
Best Practices für die Erstellung und Pflege von Value Sets müssen angewendet werden, z.B. können Konzeptcodes hinzugefügt, aber nicht gelöscht werden, nur auf den Status "deprecated" gesetzt werden. Wenn sich die Gesamtbedeutung der Codes in einem Value-Set ändert, muss die neue Version des Value-Sets eine neue OID erhalten.
 
  
Bei der Aktualisierung eines Value Sets muss das effectiveDate auf das aktuelle Datum (Gültig ab-Datum) geändert werden.
+
Soll der Inhalt eines Templates trotzdem verwendet werden, lässt sich mittels Browser-Direktlink
  
:Beispiel:
+
<code><nowiki>https://art-decor.org/temple/views/temple.html?id=</nowiki>[OID des Templates]&[effectiveDate]&[prefix]&[language]&mode=readonly</code>
:*Versions-Label: '''YYYYMM.Korrekturnummer(-beta)'''
 
  
''Hinweise:'' <br>
+
der '''XML-Code jedes Templates''' via [https://www.art-decor.org/mediawiki/index.php?title=Temple '''Temple'''] (im Lesemodus) anzeigen und anschließend kopieren. Der Inhalt kann dann in ein neu erstelltes Template eingefügt werden. Dabei ist zu beachten, dass der '''Zeitpunkt (effectiveDate)''' und die '''OID des neu erstellten Templates nicht verändert''' werden. Alle weiteren Inhalte können entsprechend angepasst werden. Die OID muss in einem späteren Arbeitsschritt über die GUI korrigiert werden.
Die "Korrekturnummer" ist ''optional'': bei Änderungen innerhalb eines Monats wird diese angehängt.<br>
 
"Beta" wird nur bei Value Sets verwendet, die noch bearbeitet werden. Sobald die Version gültig ist, wird das "beta" entfernt.
 
  
== Repositories ==
+
''Beispiel'':
=== Art-Decor Building Block Repository ===
 
In Österreich kann derzeit folgendes bereichsspezifische '''Building Block Repository''' (BBR) verwendet werden:
 
*[https://art-decor.org/art-decor/decor-project--at-cda-bbr- '''ATCDABBR''']: Dies soll in Zukunft alle für Österreich relevanten Basis-Templates enthalten, die für spezifische Anwendungen (e-Health und ELGA) in die einzelnen Projektverzeichnisse abgeleitet verwendet werden können. <br>
 
:Derzeit sind Templates für den CDA-Header sowie Basis-Templates für den e-Impfpass vorhanden. Dieses Verzeichnis wird laufend erweitert. Nach Fertigstellung von CDA-Leitfäden sollen entsprechende Templates in dieses Verzeichnis übernommen werden.
 
  
:Die im ATCDABBR befindlichen Templates dürfen nur von einem eingeschränkten Benutzerkreis bearbeitet werden.
+
<code><nowiki>https://art-decor.org/temple/views/temple.html?id=</nowiki>2.16.756.5.30.1.1.10.2.63&effectiveDate=2020-06-26T00:00:00&prefix=cdachvacd-&language=de-DE&mode=readonly</code>
:Verantwortlichkeiten und Prozesse sind im Kapitel [[#Revision]] beschrieben.
 
  
=== Projektverzeichnisse ===
+
== Inhalt ==
* e-Impfpass (Pilot)
 
* Basisleitfäden (alte Versionen)
 
* TODO
 
  
== Governance Groups ==
+
* [[Datei:Warning.png|15px]] Wenn möglich, sollen bereits vorhandene Templates verwenden werden.
Governance-Gruppen sind organisatorische Einheiten, die dazu dienen, die Verantwortung für Artefakte in Art-Decor darzustellen. Unter [https://art-decor.org/art-decor/decor-governance-group?id=1.2.40.0.34.3.1.2 Governance-Gruppen] sind alle Projekte der Gruppe sichtbar, sowie alle angelegten Artefakte mit OID, Displayname, [[#Artefaktstatus]], BBR und Projekte, die das Template oder Value-Set referenzieren.  
+
* Zugrundeliegende Standards dürfen nur eingeschränkt, aber nicht erweitert werden.
 +
** ''Hinweis: Wenn ein Template laut Standard "required" ist, aber für den konkreten Leitfaden nicht benötigt wird, kann das Template mit einem '''nullFlavor''' erstellt werden (z.B. Freitext-Inhalt „keine Information“ oder Code „entry empty“). Dadurch wird der Standard nicht verletzt und das Template kann trotzdem verwenden werden.''
 +
* Optionalitäten und Reihenfolge der Elemente müssen eingehalten werden.
 +
* Die '''erste Template-ID''' soll wie folgt bezeichnet werden: "HL7 Austria - [Name des Templates]". Diese Template-ID '''muss''' aus dem OID-Knoten 1.2.40.0.34.6.0'''.11''' stammen.
 +
** [[Datei:Warning.png|15px]] Jene Template-ID, die beim Erstellen eines neuen Templates oder Ableiten eines Prototyps von Art-Decor automatisch hinzugefügt wird, '''muss''' entfernt bzw. ersetzt werden ('''nur über GUI mögich, nicht via Temple:''' "Template bearbeiten" → "#")
 +
* Weitere Template-IDs können angegeben werden, sofern das im zugrundeliegenden Standard gefordert ist (z.B. IHE).
 +
* include vs. contains
 +
** Im CDA-Header sollen alle Elemente mit <code>include</code> eingebunden werden.
 +
*** Ausgenommen davon sind so genannte Compilation-Elemente, die in die Kategorie "Template type not specified" fallen (z.B. Address Compilation, Performer Body - Laboratory, etc.)
 +
** Ab dem <code>component/structuredBody</code> soll nur mehr mit <code>contains</code> gearbeitet werden.
 +
* Elemente und Attribute, die im Template verwendet werden, sind zu dokumentieren. Dabei kann in der Dokumentation auch auf den zugrundeliegenden Standard verwiesen werden.
 +
* Elemente die auf XDS-Metadaten gemappt werden müssen, sollen mit "↔ Hinweis zum XDS-Mapping" gekennzeichnet sein.
 +
** '''Beispiel:'''  '''↔ Hinweis zum XDS-Mapping:''' Das "templateId"-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut "formatCode" gemappt (ohne Präfix XDSdocumentEntry.formatCode^)
 +
* Es ist beim Neu-Erstellen wie auch beim Bearbeiten eines Templates zu überprüfen, ob die Datentypen nach R-MIM richtig eingehalten werden.
 +
* Wen man bei Elementen mit Datentypen Unterelemente vorgibt, muss man dabei alle anderen Unterelemente auch vorgeben. Es werden die möglichen Unterelemente des Datentyps sonst nicht erlaubt.
 +
* Bei einigen Datentypen muss man neben der Art-Decor Dokumentation, zusätzlich das ELGA-Schema beachten, damit die ELGA-Anpassungen mitbeachtet werden.
 +
* Es sollen in Art-Decor immer nur CD, CE und CV verwendet werden, nicht die IPS oder SDTC Varianten. Das ELGA-Schema bietet diese Erweiterungen bereits innerhalb CD, CE und CV an.
 +
* Jedes Template sollte ein Beispielsnippet enthalten, in dem die korrekte Anwendung des Templates angegeben wird. In der Regel werden Beispielsnippets nur zum Template selbst erstellt, nicht zu den darin verlinkten Templates (z.B. included Entries).
 +
** Idealerweise werden Beispielsnippets als letztes ergänzt, um den Aufwand an Änderungen im Template gering zu halten.
 +
* Der '''Name''' eines Templates (nicht der Display-Name!) kann nach dem Erstellen des Templates nur mittels '''Temple''' geändert werden! Die Änderung des Namens hat keinen Einfluss auf die Referenzierung durch andere Templates -> hier gilt die '''OID'''. Der Display-Name kann jederzeit über GUI oder Temple geändert werden.
 +
* Wird die OID geändert, wenn das Template bereits durch andere Templates refereziert wird, werden alle bestehenden Referenzen darauf '''ungültig'''! Daher vor der Änderung der OID die Liste aller referenzierenden Templates abspeichern und diese hinsichtlich der neuen OID anpassen!
  
=== Artefaktstatus ===
+
'''Kardinalität / Konformität'''
In einem Repository werden Artefakte zunächst im Status "Entwurf" erstellt. Nach Abschluss, Überprüfung und Bestätigung kann der Status eines Artefakts im Repository gemäß den Regeln der zuständigen Governance-Gruppe geändert werden (siehe [https://art-decor.org/mediawiki/index.php?title=ART_Template_Editor#Changing_the_status_of_a_template "Changing the status of a template"]). Das Kapitel [[#Repositories]] enthält die Beschreibung des detaillierten Prozesses und der Verantwortlichkeiten.
 
  
Das folgende Zustandsdiagramm zeigt die Standardzustände und möglichen Übergänge für ein Artefakt in Art-Decor:
+
Im Allgemeinen Implementierungsleitfaden wird unter der Legende der Konformitätskriterien beschrieben, welche Kardinalitäten und Konformitäten in den ELGA Leitfäden vorkommen können. Die folgende Tabelle stellt dar, wie diese Kriterien in Art-Decor umzusetzen sind (siehe auch [https://art-decor.org/mediawiki/index.php?title=DECOR-rules#Mandatory_.2F_Conformance Mandatory/Conformance]).
 +
{| class="wikitable"
 +
! colspan="3" |Für Elemente
 +
|-
 +
!Vorgaben Allgemeiner Leitfaden
 +
! colspan="1" |Verwendung von nullFlavor
 +
!Umsetzung Art-Decor am Beispiel eines <code>id-</code>Elements mit dem Datentypen <code>II</code> (in Temple)
 +
|-
 +
|1..1 M
 +
| colspan="1" |nicht erlaubt
 +
|<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="1" conformance="R" isMandatory="true"></code>
 +
|-
 +
| colspan="1" |1..* M
 +
| colspan="1" |nicht erlaubt
 +
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R" isMandatory="true"></code>
 +
|-
 +
| colspan="1" |0..0 NP
 +
| colspan="1" |nicht erlaubt
 +
| colspan="1" |<code><element name="hl7:id" datatype="II" conformance="NP"></code>
  
{{ HL7img | Governance state machine.png |center|  Zustandsautomat }}
+
'''Achtung,''' bei templateIds sollte zusätzlich ein Prädikat angegeben werden, damit auch das Schematron richtig erstellt wird:
  
<ref group="Abbildung">Default state diagram for Art-Decor artefacts</ref> ''Default state diagram for Art-Decor artefacts''
+
<code><element name="hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.3.2.1']" datatype="II" conformance="NP"></code>
  
'''TODO: Beschreibung, wann von draft in active wechseln. <br>
+
<code>  <attribute name="root" value="1.3.6.1.4.1.19376.1.3.3.2.1" datatype="uid" /></code>
'''TODO: Example for CH anpassen, nicht verwendete Zustände aus Tabelle entfernen'''
 
  
<br>
+
<code></element></code>
<ref group="Tabelle">Art-Decor state machine</ref> ''Art-Decor state machine''
 
{| class="hl7table"
 
! width="80px" | Status !! Action !! Trigger / Description !! Example for CDA-CH !! Responsibility
 
 
|-
 
|-
| [[File:Kyellow.png|16px]] draft
+
| colspan="1" |1..1 R
| activate
+
| colspan="1" |erlaubt
| Artefact is finished and it is considered as final (no review needed).
+
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="1" conformance="R"></code>
| ''n/a for CDA-CH as review necessary.''
 
| Developer
 
 
|-
 
|-
|  
+
|1..* R
| consider
+
|erlaubt
| If an artefact is considered to be moved into a repository, this action is applied and the artefact has to be reviewed by the owner/team of the repository.
+
|<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R"></code>
| ''final draft for a CDA-CH V2 template ready to review.''
+
|-
| Developer (info to the Reviewer)  
+
| colspan="1" |0..1 R
 +
| colspan="1" |nicht erlaubt
 +
| colspan="1" |<code><element name="hl7:id[not(@nullFlavor)]" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformance="R"></code>
 +
|-
 +
| colspan="1" |0..* R
 +
| colspan="1" |nicht erlaubt
 +
| colspan="1" |<code><element name="hl7:id[not(@nullFlavor)]" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformance="R"></code>
 +
|-
 +
| colspan="1" |0..1 O
 +
| colspan="1" |erlaubt
 +
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1"></code>
 +
|-
 +
| colspan="1" |0..* O
 +
| colspan="1" |erlaubt
 +
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*"></code>
 
|-
 
|-
|  
+
| colspan="1" |0..1 C
| cancel
+
| colspan="1" |Abhängig vom Kontext
| If an artefact is not further developed, it is cancelled.
+
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformace="C"></code>
| ''any developed draft template not to be used anymore.''
 
| Developer
 
 
|-
 
|-
| [[File:Korange.png|16px]] pending
+
| colspan="1" |0..* C
| activate
+
| colspan="1" |Abhängig vom Kontext
| Upon decision of the review team.
+
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformace="C"></code>
| ''CDA-CH V2 template has been reviewed within HL7 Switzerland and was considered to be ready for release.''
+
|}
| Review team of the repository.
+
{| class="wikitable"
 +
! colspan="2" |Für Attribute
 
|-
 
|-
+
!Vorgaben Allgemeiner Leitfaden
| reject
+
!Umsetzung Art-Decor
| If the artefact is considered as not appropriate for the repository, it's rejected.
 
| ''HL7 Switzerland does not consider the template.''
 
| Review team of the repository.
 
 
|-
 
|-
| [[File:Kpurple.png|16px]] rejected
+
|0..0 NP
+
|<attribute name="root" datatype="uid" prohibited="true"/>
| Decision necessary for what next status applies, it is recommended to set the status to draft and re-evaluate it for a repository or set is as active only within the project.
 
| ''As appropriate, propose to set it to draft again or move it to another BBR.''
 
| Developer
 
 
|-
 
|-
| [[File:Kgreen.png|16px]] active
+
| colspan="1" |1..1 R
| review
+
| colspan="1" |<attribute name="root" datatype="uid"/>
| Maintenance or update of a project/repository.
 
| ''Review CDA-CH template to consider it for CDA-CH v2.''
 
| Repository / Project owner
 
 
|-
 
|-
|  
+
| colspan="1" |0..1 O
| retire
+
| colspan="1" |<attribute name="root" datatype="uid" isOptional="true"/>
| In case of a new version, the old version is retired in order to have only one valid version of an artefact.
 
| ''A CDA-CH template is not used anymore or replaced by another one.''
 
| Repository / Project owner
 
 
|-
 
|-
| [[File:Korange.png|16px]] pre-publication review
+
| colspan="1" |1..1 F
| reactivate
+
| colspan="1" |<attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.2.1"/>
| If updated and considered as final by the responsible person, the artefact is re-activated.
 
| ''template is reviewed within HL7 Switzerland and considered to be ready for release.''
 
| Repository / Project owner
 
 
|-
 
|-
|  
+
| colspan="1" |0..1 F
| retire
+
| colspan="1" |<attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.2.1" isOptional="true"/>
|  
 
| ''A CDA-CH template is not used anymore or replaced by another one.''
 
|
 
 
|}
 
|}
  
== Dokumentation ==
+
= Value Sets =
=== Templates ===
+
Eine Anleitung zur Verwendung des Value Set Editors ist unter [https://www.art-decor.org/mediawiki/index.php?title=ART_Value_Set_Editor ART Value Set Editor] zu finden.  
Elemente und Attribute, die im Template verwendet werden, sind zu dokumentieren. Die Beziehung zu anderen Templates ist anzugeben, um festzuhalten, wie sie sich zueinander verhalten (z.B. Spezialisierung, Anpassung usw.).
 
<br><br>
 
TODO: prüfen <br>
 
Other elements that were in addition available according the HL7 CDA standard shall not be mentioned in the Art-Decor template.
 
* Open vs. Closed Templates
 
  
=== Standard-Referenzen ===
+
{{BeginYellowBox}}
Daten- und Template-Elemente sollen in ihrem Label zu der entsprechenden Spezifikation verlinken, auf der sie basieren (z.B. IHE PHARM, Kap. 4.4). Dies liegt in der Verantwortung des Entwicklers.
+
Seit 2022 steht  unter '''https://termgit.elga.gv.at/ ein neuer Terminologieserver''' zur Verfügung. Die Dokumentation findet sich auf https://termgit.elga.gv.at/documentation_and_support_de.html und https://termgit.elga.gv.at/faq_de.html
 +
{{EndYellowBox}}
  
== Datasets ==
+
== Name ==
Die Verwendung von Art-Decor-Datensätzen wird für neue Projekte empfohlen. Diese bilden die funktionalen Anforderungen an das Projekt ab und sind Diskussionsgrundlage bei Fachexpertengesprächen (erfordern kein technisches Hintergrundwissen).
+
'''Name''' und '''Display-Name''' (bzw. '''Title''' auf Termgit) eines Value Sets müssen wie folgt angegeben werden:
<br>
 
Wenn möglich, soll von bereits vorhanden Elementen geerbt werden und diese, falls erforderlich, enterbt und den speziellen Anforderungen angepasst werden.
 
<br>
 
Folgende Inhalte eines Dataset-Elements sind mindestens anzugeben:
 
* Name
 
* Beschreibung
 
* Datentyp
 
<br>
 
wenn vorhanden:
 
* Auswahllisten
 
* Link zu kodierten Konzepten / Value-Sets (Terminologien)
 
  
== Szenarios ==
+
*'''Name''': '''[Präfix]-[ValueSetName]''' (lowercase-Schreibweise)
Das Erstellen von '''Transaktionen''' im Rahmen von Szenarios ist für die Generierung von Schematron-Regeln '''zwingend erforderlich'''.<br>
+
*'''Display-Name'''/'''Title''': '''[Präfix]_[ValueSetName]''' (UpperCamelCase-Schreibweise)
Die Angabe von Kardinalität (optional, wiederholbar) und Konformität (erforderlich, obligatorisch) für die einzelnen Elemente des Datasets '''wird empfohlen'''.
 
  
== Dataset-Mapping ==
+
Sonderzeichen sind nicht erlaubt.
Die Zuordnung von Datensatz-Elementen und erstellten Templates wird '''empfohlen'''.  
+
Als Präfix dient das Projektkürzel (Name des Repositories), z.B. "eimpf".
Dadurch sind alle mit einem Template assoziierten Konzepte in der Template-Beschreibung zusammengefasst, sowie direkt beim assoziierten CDA-Element bzw. Attribut des Templates ersichtlich. Dies dient der Kontrolle, dass alle erforderlichen Datensatz-Elemente in den Templates modelliert wurden.
 
  
== Namenskonventionen ==
+
Beispiele:
 +
* Name: eimpf-antikoerperbestimmung
 +
* Title: eImpf_Antikoerperbestimmung
  
=== Versions-Label ===
+
* Name: elga-administrativegender
Im ''Version-Label'' wird prinzipiell die '''Jahrzahl''' der Verabschiedung des '''Templates''', des '''Value-Sets''' bzw. des '''Datasets''' eingetragen. Sollte die Angabe des Jahres nicht ausreichend sein, wird sie mit .Monat ergänzt. Gleiches gilt für tagesaktuelle Versionen.
+
* Title: ELGA_AdministrativeGender
:Beispiele:
 
:* 2019
 
:* 2019.01
 
:* 2019.01.16
 
  
=== Item-Label ===
+
== OID ==
Der im Item-Label des '''Document-Level Templates''' angegebene Name wird von Art-Decor später automatisch als Name für das entsprechende Schematron verwendet, z.B. „elgaimpf‑UpdateImmunisierungsstatus“.
+
Alle Art-Decor '''Value Sets''' müssen unterhalb des OID-Knotes 1.2.40.0.34.6.0'''.10''' liegen (eHealth-Austria/services/art-decor/value-sets).  
  
=== Namenskonventionen für Templates ===
+
''Beispiele'':
Die Namen von Templates werden wie folgt angegeben:
+
* Value Set: 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (eHealth-Austria/services/art-decor/value-sets/xxx)
'''[Präfix]_[Template-Typ]_[ElementName]'''<br/>
+
{{BeginYellowBox}}''Wichtiger Hinweis:'' Die Verwaltung der unter diesen Knoten liegenden Value Sets unterliegt Art-Decor und benötigt daher '''keine Registrierung''' über das '''OID-Portal'''. Die nächste '''freie OID''' für '''Value Sets''' muss über die [https://art-decor.org/decor/services/GovernanceGroupList?gg=1.2.40.0.34.3.1.2&language=en-US&format=html#tabs1-valuesets1 '''ELGA Art-Decor Governance Group Value Sets'''] (Vorsicht!: lange Ladezeit) ermittelt werden.{{EndYellowBox}}
Wobei folgendes gilt:
 
;[Präfix]: Als Präfix dient das Projektkürzel (Name des Repositories) in CamelCase-Notation, z.B. "atcdabrr"
 
;[Template-Typ]: Der Template-Typ muss einen der folgenden Template-Typen enthalten:
 
:* '''"document"'''
 
:* '''"header"'''
 
:* '''"section"'''
 
:* '''"entry"'''
 
:* '''"other"'''  
 
;[ElementName]: Bezeichnung des Templates in CamelCase-Notation. Als Trenner fungieren Unterstriche "_".
 
  
Beispiele:
+
== Version & Metadaten ==
*Template einer '''unkodierten Sektion''' im Repository AT-CDA-BBR:
+
Versionierung: Siehe [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung].
::Name: "atcdabrr_'''section'''_FruehereErkrankung'''Unkodiert'''"<br>
+
 
::DisplayName: "Frühere Erkrankungen - '''unkodiert'''"
+
== Inhalt ==
*Template einer '''kodierten Sektion''' im ELGA e-Impfpass Repository:
+
Best Practices für die Erstellung und Pflege von Value Sets müssen angewendet werden, z.B. können Konzeptcodes hinzugefügt, aber nicht gelöscht werden, nur auf den Status "deprecated" gesetzt werden.
::Name: "eimpf_'''section'''_ImpfrelevanteErkrankungen'''Kodiert'''"<br>
+
{{BeginYellowBox}}''Wichtiger Hinweis:'' Wenn sich die Gesamtbedeutung der Codes in einem Value Set ändert, muss die neue Version des Value Sets eine '''neue OID''' erhalten.{{EndYellowBox}}
::DisplayName: "Impfrelevante Erkrankungen - '''kodiert'''"
+
 
*'''Document Level''' Template im ELGA e-Impfpass Repository:
+
= Beispielbefunde =
::Name: "eimpf_'''document'''_KompletterImmunisierungsstatus"<br>
+
Neben den Beispielsnippets in den Templates sind Beispielbefunde und Falsch-Beispielbefunde zu erstellen. Ein Grundgerüst für ein Beispieldokumentekann erstellt werden, indem man im entsprechenden DLT den Zauberstab des Template Editors anwendet und rekursiv alle Code-Snippets der darin verlinkten Templates einfügt.
::DisplayName: "Kompletter Immunisierungsstatus"
+
 
*'''Entry''' im AT-CDA-BBR:
+
Name
::Name: "atcdabbr_'''entry'''_Immunization"<br>
+
 
::DisplayName: "Immunization '''Entry'''"
+
Der Name von (Falsch-)Beispielbefunden sollte folgendermaßen aufgebaut sein. Die einzelnen Elemente werden mit "_" verbunden.
*Template aus der Kategorie '''"Other"''' im AT-CDA-BBR:
+
 
::Name: atcdabbr_'''other'''_TextElementWithReferenceToNarrativeText<br>
+
'''"falsch_":''' Angabe, dass es sich um einen Falsch-Beispielbefund handelt.
::DisplayName: Narrative Text Reference
 
  
=== Namenskonventionen für Value-Sets ===
+
'''[Präfix]:''' Als Präfix dient das Projektkürzel (Name des Repositories), z.B. "eimpf"
Die Namen von Value-Sets werden wie folgt angegeben:
 
'''[Präfix]_[ValueSetsName]_VS'''<br/>
 
  
"Displayname" und "Name" des Value-Sets sind identisch. <br>
+
'''[optional DLT-Name]:''' Name des DLTs, wenn es in dem Projekt mehrere DLTs gibt.
:Beispiel:
 
:*Name: eimpf_Abrechenbarkeit_VS
 
:*Wiedergabename: eimpf_Abrechenbarkeit_VS
 
  
= Mediawiki =
+
'''[Kurztitel des Beispiels]:''' Erklärt ganz kurz, worum es in dem Beispielbefund geht.
==Leitfaden erstellen==
 
Wichtige Informationen hinsichtlich der technischen Erstellung eines CDA-Leitfadens mit Mediawiki sind unter [https://wiki.hl7.at/index.php?title=Hilfe:Leitfaden_erstellen "Leitfaden erstellen"] nachzulesen.
 
  
===Namespace===
+
Beispiele:
Der Verwendung von Namespaces ist wesentlich für Versionierung der Wiki-Seiten mit Flagged Revisions.
 
{{BeginYellowBox}}
 
''Wichtiger Hinweis:'''''Alle Seiten''' von CDA-Leitfäden im Namespace '''[[https://wiki.hl7.at/index.php?title=Hilfe:Leitfaden_erstellen#Verwendung_von_Namespaces "ILF"]]''' erstellt werden.
 
{{EndYellowBox}}
 
  
== Struktur eines CDA-Implementierungsleitfadens ==
+
* at-lab_Laborbefund_Kompletter_Befund.xml
Folgende Angaben hinsichtlich des [Hilfe:Leitfaden_erstellen#Aufbau_eines_Implementierungsleitfadens Aufbaus einen Implementierungsleitfadens] sind einzuhalten.
+
* falsch_at-lab_Laborbefund_Constraint_gebrochen.xml
  
Aufgrund bisherige Erfahrungen wird empfohlen, nur jene Textabschnitte in Teildokumente auszulagern, die aufgrund deren allgemeinen Inhalten auch zur Transklusion in andere Leitfäden verwendet werden können.
+
Inhalt
Dies hat den Vorteil, das mit den Onboard-Mitteln des Wikis verschiedene Seiten-Versionen (über den Reiter "Versionsgeschichte") leichter verglichen werden können.
 
  
===Typische Gliederung eines Dokuments===
+
* '''Beispielbefunde'''
Um eine konsistente Vorgehensweise bei der Erstellung und Darstellung eines Implementierungsleitfadens zu gewährleisten, wird folgende (minimale) Struktur vorgegeben:  '''TODO REVIEW'''
+
** sind vollständig valide und bilden verschiedene reale Szenarien ab.
* Informationen über dieses Dokument
+
* Für '''Falsch-Beispielbefunde''' sollte mindestens jeweils ein Befund vorhanden sein für
** Allgemeines
+
** das Brechen eines Contraints,
** Sprachliche Gleichbehandlung
+
** das Verwenden eines falschen Wertes wo ein Value Set Wert erwartet wird,
** Verbindlichkeit
+
** das Verwenden eines nicht CDA-Elementes (nicht im Schema vorhanden),
** Zielgruppe
+
** das Verwenden eines verbotenen Elementes
** Hinweis auf verwendete Grundlagen
+
** das Weglassen eines Pflichtfeldes.
** Danksagung
 
** Hinweise zur Nutzung des Leitfadens
 
** Revisionsliste
 
** Weitere unterstützende Materialien
 
** Bedienungshinweise
 
** Impressum
 
* Harmonisierung
 
* Einleitung
 
** Ausgangssituation
 
** Zweck
 
** Hierarchie der Implementierungsleitfäden
 
* Anwendungsfälle
 
* Administrative Daten (CDA Header)
 
* Fachlicher Inhalt (CDA Body)
 
* Technische Konformitätsprüfung
 
** Schema-Prüfung
 
** Schematron-Prüfung
 
** Online-Validation von CDA-Dokumenten
 
* Anhang
 
** Referenzen
 
** Revisionsliste
 
  
== Schematische Template-Darstellung ==
+
= Szenarios / Schematron =
TODO: evtl. Grafikvorlage
+
Das Erstellen von '''einer Transaktion pro DLT''' in den Szenarien ist für die Generierung von Schematron-Regeln '''zwingend erforderlich''', siehe [https://confluence.elga.gv.at/display/SCC/Schematron-Erstellung+und+Bereitstellung Schematron-Erstellung und Bereitstellung].
  
== Revision ==
+
Für Szenarios gibt es '''keine speziellen Vorgaben''' hinsichtlich '''OID oder Version & Metdaten'''.
TODO:
 
* Versionierung: https://wiki.hl7.at/index.php?title=Hilfe:Leitfaden_erstellen#Versionierung
 
* PDF-Generierung: https://wiki.hl7.at/index.php?title=Hilfe:Leitfaden_erstellen#PDF_Generierung
 
  
= Releases =
+
Eine Anleitung zur Verwendung des Szenario Editors ist unter [https://www.art-decor.org/mediawiki/index.php?title=ART_Scenario_Editor ART Scenario Editor] zu finden.
== Art-Decor ==
 
TODO
 
  
== Wiki ==
+
== Name ==
==Check before finalizing==
+
Der Name/Label der Transaktionen soll dem Schema '''[NameDesSzenarios]''' folgen. Alles zusammengeschrieben, kein Prefix.  
Thew folowing checks help to identify possible errors or missing includes from Art-Decor. Templates from other repositories than under the governance from eHealth Suisse need to be imported separatly. Please send the necessary OID and related project information to the [mailto://support@art-decor.org Art-Decor Support].  
 
  
*Perform search for:
+
Der im Label der Transaktion angegebene Name wird von Art-Decor später automatisch als Name für das entsprechende Schematron verwendet, z.B. „eimpf-UpdateImmunisierungsstatus“, wobei das Präfix des Projektes mit dem folgenden Bindestrich automatisch ergänzt wird.
** "/dynamic"
 
** "/static"
 
** "Cannot find"
 
** ...
 
  
'''Afterwards:'''
+
== Inhalt ==
Create a revision according to [[#Revisions | Wiki revisions]].
+
Optional ist es für jede Transaktion möglich das Dataset ("Konzepte") anzugeben und für jedes Element Kardinalität (optional, wiederholbar) und Konformität (erforderlich, obligatorisch) festzulegen. Die Angabe von Kardinalität und Konformität ist für die Erstellung eines Schematrons nicht zwingend erforderlich.
  
= Verantwortliche Personen =
+
= Qualitätssicherung =
== Support for Art-Decor ==
 
TODO
 
  
== Governance Groups ==
+
== Art-Decor ==
TODO
+
Offizielle Informationen zur Qualitätssicherung eines Projekts in Art-Decor finden sich auf der Seite [https://www.art-decor.org/mediawiki/index.php?title=ART_Project_Editor#Preflighting_publication_and_quality_checks Preflighting publication and quality checks].
  
== Repositories ==
+
* Template-Checks:
TODO
+
** korrektes Präfix, Name, Displayname
 +
** open/closed
 +
** korrektes Value Set
 +
** Beispielsnippets
 +
** Templatebeschreibung
 +
** Standardreferenzen
 +
** Dataset Mapping (optional)
 +
** im Beispieldokument enthalten
 +
** Schematron Asserts ergänzen
 +
* DLT bei '''jeder Version MUSS''' in <code>hl7at:formatCode</code> die Versionierungsinfo + Publikationsdatum im Label angepasst werden.
 +
** Entsprechende Adaptierung von CodeSystem '''ELGA_FormatCode''' und ValueSet '''ELGA_FormatCode'''
 +
* Temlatestatus:
 +
** für Ballot: Templates bleiben im Entwurf-Status
 +
** nach Ballotabschluss: Versionlabel mit Publikationsdatum ergänzen und Templates aktiv setzen
 +
* Zur Prüfung des Projektschemas unter dem Menü "Project" → "Development" → "Check DECOR" ein Dataset auswählen und die Prüfung durchführen. Eventuelle Fehler, Warnungen oder Hinweise werden anschließend in einer Liste dargestellt.
 +
* Nach der Erstellung eines Schematrons unter "Project" → "Development" → "Compile a development version" (für Details siehe [https://confluence.elga.gv.at/display/SCC/Schematron-Erstellung+und+Bereitstellung Schematron-Erstellung und Bereitstellung]) ist es möglich, über "Validate XML instance" Beispielbefunde für die verschiedenen Szenarios zu validieren.
 +
* AD-Bot starten (lassen) (am Vortag der Publikation)
  
 
== Wiki ==
 
== Wiki ==
TODO
+
Im Wiki werden die Metadaten vor dem setzen des Seiten-Status auf Abnahme nochmals überprüft.
 +
 
 +
* Anpassung Titelblatt
 +
** Publikationsdatum
 +
** Versionsinformationen mit DLT abgleichen
 +
* Infobox: „In Arbeit“ entfernen
 +
* Prüfen, ob alle Templates eingefügt und Value Sets verlinkt wurden
 +
* Linkverzeichnisse, Referenzen prüfen
 +
* ggf. Informationen bezüglich <code>hl7at:formatCode</code> auf der Wiki-Seite aktualisieren
 +
* Diskussionsseite aktualisieren
 +
** Diskussionsseiten sollen wie folgendes Beispiel aufgebaut sein ([[ILF_Diskussion:Telemonitoring-Episodenbericht_(Version_1)|Diskussionseite Telemonitoring-Episodenbericht]])
 +
** prüfen, ob Elemente aus dem "Ausblick" in der aktuellen Version umgesetzt wurden. Falls ja, sind diese in die Tabelle des "Release-Log" zu verschieben.
 +
* Revisionsliste des Leitfadens auf Basis der Diskussionsseite aktualisieren
 +
* Links prüfen und optimieren: Nur externe Links sollen in neuem Tab geöffnet werden, Sprungmarken sollten immer mit # gekennzeichnet sein.
 +
* PDF: Druck checken (leere Seiten, Suche nach: „Error“, „Fehler“, "TODO")
 +
* Wiki-Seite Status ändern auf "abgenommen"
 +
* falls neue Hauptversion dann OID im OID Portal eintragen lassen
 +
* Wiki-Guide aktualisieren (neue Zeile für neue Version, PDF upload)
 +
* Seiten-Status ändern auf "abgenommen"
  
= Quality Assurance & Review ==
+
== GitLab ==
== Art-Decor Repository ==
+
Eine erweiterte Qualitätssicherung wird auch in GitLab erstellt. Hier werden beim Einstellen von (Falsch-)Beispielbefunden oder Schematron-Regeln in die jeweiligen Projekte automatisch Prüfroutinen (Schematron-Validierung) gestartet.
TODO
 
  
== Implementation Guides ==
+
* Beispielbefunde aktualisieren
TODO
+
* Falsch-Beispielbefunde aktualisieren
 +
* Schematron aktualisieren
  
== ELGA Implementierungsleitfäden ==
+
= Anhang =
TODO: Prozess # muss eingehalten werden
+
 
 +
== Links ==
  
= Anhang=
 
==Links==
 
 
* [http://art-decor.org/art-decor/home Art-Decor Workspace]
 
* [http://art-decor.org/art-decor/home Art-Decor Workspace]
 
* [https://www.art-decor.org/mediawiki/index.php?title=Documentation Art-Decor Dokumentation]
 
* [https://www.art-decor.org/mediawiki/index.php?title=Documentation Art-Decor Dokumentation]
* [https://wiki.hl7.at/index.php?title=Willkommen_auf_dem_Wiki-Portal_von_HL7_Austria eHealth Wiki]
+
* Wiki-Portal von HL7 Austria: [https://wiki.hl7.at/index.php?title=Willkommen_auf_dem_Wiki-Portal_von_HL7_Austria eHealth Wiki] & [https://wiki.hl7.at/index.php?title=Hilfe:Wiki Wiki Hilfe]
* [https://wiki.hl7.at/index.php?title=Hilfe:Wiki Wiki Hilfe]
 
 
 
==Abbildungsverzeichnis==
 
<references group="Abbildung"/>
 
 
 
==Tabellenverzeichnis==
 
<references group="Tabelle"/>
 
 
 
==Zur Diskussion stehende Änderungsvorschläge==
 
TODO
 
  
[[Kategorie:Hilfe]]
+
<span title="Filterspalte" class="tf-inline-filter"></span>
[[Kategorie:Best Practices]]
 
[[Kategorie:Governance]]
 
[[Kategorie:Anleitung]]
 

Aktuelle Version vom 30. Januar 2024, 14:20 Uhr


Governance für die CDA-Leitfadenerstellung mit Art-Decor und Mediawiki
Version: 1.1.1+20230503
Status: Final



1 Einleitung

Dieses Dokument enthält Richtlinien zur Erstellung von CDA-Implementierungsleitfäden mit Art-Decor® und Mediawiki und anderen Werkzeugen in Österreich.

Diese Richtlinien entstanden in Zusammenarbeit mit der ELGA GmbH und beruhen auf den bisher gemachten Erfahrungen in der Leitfadenerstellung.

Weiters werden die notwendigen Verantwortlichkeiten und Prozesse definiert, um klare Strukturen für die Zusammenarbeit zwischen Art-Decor®, Wiki und anderen Werkzeugen zu gewährleisten. Dies umfasst die Verantwortung für Art-Decor Repositories, Qualitätssicherung und den Support der Tools.

2 Anwendungsbereich

Das Dokument geht nicht auf die Modellierung von HL7 CDA-Dokumenten ein, sondern beschreibt den Einsatz der Tools für Österreich. Es definiert Regeln und Strukturen, die von allen Anwendern dieser Werkzeuge eingehalten werden müssen.

3 Weiterentwicklung des Dokuments

Dieses Dokument enthält die aktuellen Festlegungen bezüglich der Arbeit mit Art-Decor®, Mediawiki und weitere Werkzeuge in Österreich und wird laufend angepasst.

Wichtiger Hinweis: Anfragen hinsichtlich der Änderung oder Erweiterung dieses Dokuments stellen Sie bitte an office@hl7.at.

4 Governance für die CDA-Leitfadenerstellung

Die folgenden Vorgaben sind verpflichtend einzuhalten. Empfehlungen werden entsprechend markiert. Die Reihenfolge der Kapitel soll eine übliche Vorgehensweise darstellen, jedoch ist die Reihenfolge selbst nicht verpflichtend einzuhalten.

4.1 Governance Groups

Governance-Gruppen sind organisatorische Einheiten, die dazu dienen, die Verantwortung für Artefakte (Templates und Value Sets) in Art-Decor darzustellen. Unter der ELGA Art-Decor Governance Group sind alle Projekte der ELGA sichtbar, sowie alle angelegten Artefakte mit OID, Displayname, Artefaktstatus, BBR und Repositories), z.B. "at-cda-brr"-Projekte, die das Template oder Value Set referenzieren. Weiters existiert die HL7 Austria Art Decor Governance Group, welche alle eHealth Austria Vorgaben umfasst. Dabei wird die hier beschriebene ELGA Governance auch für die HL7 Austria relevant und soll von dieser übernommen werden. 

4.2 Implementierungsleitfaden (inkl. Wiki)

ELGA Implementierungsleitfäden werden in deutscher Sprache verfasst. Dazu gehören textuelle Beschreibungen im Wiki, Art-Decor-Templates und Art-Decor-Datasets. Ausnahmen gelten bei der Benennung von Templates (siehe #Name).

eHealth Implementierungsleitfäden können auch in englischer Sprache verfasst werden.

Wichtige Informationen hinsichtlich der technischen Erstellung eines CDA-Leitfadens mit Mediawiki sind unter Leitfaden erstellen mit Mediawiki nachzulesen.

Die Einbindung eines neuen Leitfadens folgt einem vorgegebenen Prozess, dieser ist ersichtlich unter Benutzung von Flagged Revisions.

4.2.1 Name

Der Name eines Leitfadens wird wie folgt angegeben:

  • HL7 Austria & ELGA
  • HL7 CDA® R2 Implementierungsleitfaden
  • [Titel]
  • OID: [OID]


Beispiel:

HL7 Austria & ELGA

HL7 CDA® R2 Implementierungsleitfaden

Labor- und Mikrobiologiebefund

OID: 1.2.40.0.34.7.4.9.3

4.2.2 OID

Im Zusammenhang mit der Verwendung von OID sind die österreichischen Richtlinien einzuhalten (siehe Object Identifier (OID) Konzept für das österreichische Gesundheitswesen). Das österreichische OID Portal ist zu finden unter OID Portal Österreich.

Für jeden Implementierungsleitfaden muss über das OID-Portal eine Dokumentenklassen-OID unterhalb des Knotens 1.2.40.0.34.7 (eHealth-Austria/documents) registriert werden.

Für die Verwaltung der Hauptversionen muss darunter eine zusätzliche Ebene angelegt werden.

Beispiel:

  • 1.2.40.0.34.7.18: Dokumentenklassen-OID des Implementierungsleitfadens "Meldung von antimikrobieller Resistenzen"
    • OID wird im OID-Portal beantragt (Root-Knoten aller Versionen des entsprechenden Leitfadens)
  • 1.2.40.0.34.7.18.1: Implementierungsleitfaden Meldung von antimikrobieller Resistenzen, Version 1
    • OID des PDF-Leitfadens (Titelblatt)
    • wird im DLT als templateId[2] als informative Referenz angegeben
    • Hauptversionen verlangen eine neue Verordnung durch das BM*G
    • OID wird ebenfalls im OID-Portal beantragt

Die Leitfaden-OID von Nebenversionen ändert sich nicht. Die Version des Leitfadens ist im Leitfadentitel (Wiki) bzw. auf dem Titelblatt (PDF) und dem Versionlabel des DLT ersichtlich. Siehe Versionierung.

4.2.3 Version & Metadaten

Der Verwendung von Namespaces ist wesentlich für Versionierung der Wiki-Seiten mit Flagged Revisions.

Wichtiger Hinweis: Alle Seiten von CDA-Leitfäden müssen im Namespace ["ILF"] erstellt werden.

Das Wiki-Leitfadenprojekt DARF NICHT unabhängig vom ART-DECOR-DLT versioniert werden, siehe Versionierung.

Alle Hauptversionen und Nebenversionen eines Leitfadens sind als Wiki verfügbar. In der "Lese-Ansicht ist die publizierte Version ersichtlich, aktuelle (noch nicht freigegebene) Überarbeitungen/Änderungen sind der "Revisions-Ansicht" zu entnehmen. Zum Zeitpunkt der Publikation (z.B. Ballotversion / Publikation neue Haupt- oder Nebenversion) wird die Hauptseite des Leitfadens von einer berechtigten Person als "abgenommen" markiert (siehe dazu Versionierung von Wiki-Seiten), sodass die "Revisions"-Ansicht in die stabile "Leseansicht" übernommen wird. Die "Leseansicht" bleibt unverändert, bis eine neue Version des Leitfadens abgenommen wird.

Alle veröffentlichten Leitfadenversionen sind zusätzlich zum Wiki als PDF verfügbar (Anleitung siehe PDF-Generierung). Eine Übersicht der Versionen eines Leitfadens findet sich im jeweiligen Guide (alle vorhandenen Guides sind zu finden unter Übersicht der CDA Implementierungsleitfäden.

4.2.4 Inhalt

Der Inhalt eines Implementierungsleitfadens besteht üblicherweise aus den Kapiteln:

1 Zusammenfassung
2 Informationen über dieses Dokument
2.1 Impressum
2.2 Haftungsausschluss
2.3 Sprachliche Gleichbehandlung
2.4 Lizenzinformationen
2.4.1 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")
2.4.2 SNOMED CT
2.4.3 Weitere Terminologien
2.5 Verwendete Grundlagen und Bezug zu anderen Standards
2.6 Verbindlichkeit
2.7 Wichtige unterstützende Materialien
2.8 Bedienungshinweise
2.8.1 Farbliche Hervorhebungen und Hinweise
2.8.2 PDF-Navigation
3 Begriffsdefinitionen
4 Einleitung
4.1 Ausgangslage und Motivation
4.2 Zweck des Dokuments
4.3 Zielgruppe
5 Leitfadenerstellungs- und Harmonisierungsprozess
5.1 Revision der Leitfäden
5.2 Autoren und Mitwirkende
5.2.1 Autoren
5.2.2 Mitwirkende
6 Technischer Hintergrund
7 Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden
8 Funktionale Anforderungen
8.1 Voraussetzungen für den Zugriff auf e-Befunde in ELGA
8.2 Anwendungsfälle des Dokumentenmanagements
8.2.1 Dokument-Metadaten (XDS-Metadaten)
9 Konformitätsprüfung
10 Datentypen
11 Vorgaben zum medizinischen Inhalt
12 Anwendungsfälle / User Stories
13 Dataset
14 Technische Spezifikation
14.1 Übersicht CDA Strukturen (Header & Body)
(evtl. Übersichtstabelle der Header-Elemente für dokumenten-relevante Zeitpunkte/Zeitspannen)
14.2 CDA Templates
14.2.1 Document Level Templates
14.2.2 Header Level Templates (Hinweis: hier sollten nur jene Header Level Templates aufgeführt werden, die für spezielle Leitfäden erstellt / adaptiert wurden. Alle anderen werden als Teil der DLTs angezeigt)
14.2.3 Section Level Templates
14.2.4 Entry Level Templates
14.2.5 Weitere CDA Fragmente
14.3 Terminologien
15 Anhang
(15.1 evtl. Abkürzungsverzeichnis)
15.2 Abbildungsverzeichnis
15.2 Tabellenverzeichnis
15.3 Einzelnachweise
15.4 Literatur und Weblinks
15.5 Revisionsliste
15.6 Erratum


Bei Kapiteln ohne Inhalt soll kurz darauf eingegangen werden, warum dieser Leitfaden dieses Kapitel nicht füllt.

Aufgrund bisheriger Erfahrungen wird nicht empfohlen, Textabschnitte in Teildokumente (eigene Wiki-Seiten) auszulagern und zu transkludieren, da Änderungen an dem Teildokument automatisch in alle transkludierenden Wiki-Leitfäden übernommen werden und einer Abstimmung mit den Leitfadenverantwortlichen bedürfen. Weiters ist beim Bearbeiten eines Seitenabschnittes nur im Seitenlink bzw. unter Menüpunkt "Links auf diese Seite" ersichtlich, ob man sich auf der Hauptseite des eigenen Leitfadens oder auf einer bereits transkludierten Seite befindet, was die Gefahr eines unbeabsichtigten Änderns anderer bestehender Leitfäden erhöht.

Ausnahmen bilden folgende Seiten, welche transkludiert werden können, aber nicht bearbeitet werden dürfen (liegen in der Obhut des Allgemeinen Leitfadens):

  • ILF:Lizenzinformationen

Für die Kapitel Section Level Templates, Entry Level Templates und Weitere CDA Fragmente in speziellen Leitfäden gilt, dass für Templates, die im Allgemeinen Implementierungsleitfaden spezifiziert sind, eine einfache Referenz auf den Allgemeinen Implementierungsleitfaden ausreicht. Dabei MUSS aber angegeben werden, um welche Hauptversion des Allgemeinen Leitfaden es sich handelt.

5 Art-Decor Projekt

Ein neuer CDA-Leitfaden muss in einem eigenen Projektverzeichnis angelegt, alle Autoren müssen entsprechend berechtigt werden. Dies muss beim Art-Decor-Support beantragt werden.

Das neue Projekt kann am besten mit folgendem E-Mail-Template beantragt werden:

Dear Art-Decor-Support,

we would like to ask you to create a new project in Art-Decor:

  • Name: <displayName des Projekts>
  • Prefix: <Projektkürzel - soll immer mit at- beginnen, z.B. "at-emed-" oder "at-lab-" (Vorweg: an bestimmten Stellen werden Bindestriche durch das System ausgeblendet)>
  • ContainsReusableContent=false
  • Experimental/Test=false
  • defautLanguage=de
  • id=1.2.40.0.34.777.<nächste freie ID, siehe Kapitel OID>
  • Governance-Groups: ELGA, HL7 Austria
  • Wiki-Bot activated à wiki.hl7.at
Thank you in advance.


Eine Liste der Art-Decor Projekte ist unter der HL7-Austria Governance Group verfügbar ELGA Art-Decor Governance Group.

Weitere offizielle Informationen sind unter ART Project Editor zu finden.

5.1 Name

Der Name des Projekts, auch displayName des Projekts genannt, soll sprechend gewählt werden und ist mit dem ELGA SCC Team abzusprechen.

Dies gilt auch für das Prefix, auch Projektkürzel genannt. Dabei soll dieses keine Bindestriche enthalten, z.B. "elgatest".

5.2 OID

Alle Art-Decor Projekte bekommen die unter (Governance Group (art-decor.org) -> Projects) einsehbaren OID mit der nächste ID im 1.2.40.0.34.777 Knoten.

5.3 Version & Metadaten

Projekte selbst werden nicht versioniert. Nur die beinhaltenden DLT werden versioniert.

Projektkürzel unter "prefix" werden im lowercase geschrieben, ohne jegliche Trennzeichen. Bsp.: "elgatgd".

Neue Projekte dürfen keine bbr sein! Die Checkbox Image2021-6-24 13-41-12.png darf nicht angehackt sein!

Es wird empfohlen dem Projekt standardmäßig Referenzen zu den Building Block Repositories ad1bbr-, ad2bbr-, at-cda-bbr-, IHE-PCC- hinzuzufügen (siehe auch Reference a building block repository).

5.4 Inhalt

In Österreich kann derzeit folgendes bereichsspezifische Building Block Repository (BBR) für die Ableitung oder Referenzierung von Templates verwendet werden:

Dies soll in Zukunft alle für Österreich relevanten Basis-Templates enthalten, die für spezifische Anwendungen (eHealth und ELGA) in die einzelnen Projektverzeichnisse abgeleitet werden können.

Das at-cda-bbr wird laufend mit neuen Templates erweitert. Nach Fertigstellung eines neuen CDA-Leitfadens sollen weiter zu verwendete Templates in dieses Verzeichnis übernommen werden. Die im at-cda-bbr befindlichen Templates dürfen nur von einem eingeschränkten Benutzerkreis bearbeitet werden.

5.4.1 Statuswechsel eines Templates

In einem Repository werden Artefakte (Templates/Value Sets) zunächst im Status "Entwurf" erstellt. Der Status eines Artefakts im Repository kann gemäß den Regeln der hier beschriebenen Governance geändert werden (siehe "Changing the status of a template").

Kyellow.png
Entwurf: Das Template verbleibt bis zur Veröffentlichung im Status „Entwurf“ und ist bearbeitbar.
Kgreen.png
Aktiv: Gültiges Template, dessen Inhalt nicht mehr verändert werden kann. Zum Bearbeiten (Entwurf) muss das Template eine neue Version bekommen.
Kdeprecblue.png
Veraltet: Aktive Templates, die nicht mehr verwendet werden sollen, können in den Status „veraltet“ versetzt werden. Dieser Status ist endgültig.
TemplateStatuswechsel2021-9-22.png Beschreibung Statuswechsel eines Templates (Diagramm)

1. Bevor ein Template neu angelegt wird, soll überprüft werden, ob ein verwendbares Dummy-Template(*) vorhanden ist. Ein neues Template erhält immer Version 1.0.0 und hat den Status "Entwurf".

2. Nach erstmaliger Erstellung eines Templates oder nach Durchführung von Major- oder Minor-Änderungen, muss vor der Publikation ("Aktiv-Setzung" des Templates) ein Ballotverfahren durchgeführt werden. (Der Status "Revision vor Publikation" kann verwendet werden, um anzuzeigen, dass eine Publikation bevorsteht. Vom Status "Revision vor Publikation" kann in den Stauts "Aktiv" gewechselt werden.)

3. Wurde ein Ballotverfahren durchgeführt, erfolgt der Template-Statuswechsel zu "Aktiv" zum Publikationszeitpunkt des Leitfadens. Wird ein Template "Aktiv" gesetzt, wird die bestehende Versionsnummer im Version-Label mit dem Publikationsdatum ergänzt (z.B. 1.0.0+20210504, siehe [Versionierung). (Der Status "Revision nach Publikation" kann verwendet werden, um anzuzeigen, dass eine neue Version vorbereitet wird. Vom Status "Revision nach Publikation" kann man wieder in den "Aktiv" Status wechseln.)

4. Solange keine Änderungen an dem Template durchgeführt werden müssen, werden verbleibt es im Status "Aktiv".

5. Ist das Template veraltet oder wird es durch ein neues ersetzt, muss der Status auf "veraltet" gesetzt werden (6.). Dieser Status ist unveränderbar (Status endgültig). Veraltete Templates, scheinen weiterhin in referenzierenden Templates auf.

7. Sind Änderungen eines aktiven Templates erforderlich, muss unterschieden werden, ob es sich um Minor/Major-Änderungen oder um einen Patch handelt.

8. Handelt es sich um einen Patch oder wurden die Änderungen von den referenzierenden Leitfäden akzeptiert, kann mit "neue Version erzeugen" eine neue Templateversion von Art-Decor erstellt werden. Diese hat den Status "Entwurf", die gleiche Template-OID, aber ein neues Erstellungsdatum. Die Versionsnummer im Version-Label des Templates muss an der entsprechenden Stelle um 1 erhöht werden (siehe Versionierung).

9. Sind die Änderungen nicht von allen referenzierenden Leitfäden gewünscht oder noch nicht bekannt ob dies des Fall ist, muss eine "neue Bearbeitung" dieses Templates erstellt werden. Es erhält eine neue Template-OID, Version 1.0.0, siehe Versionierung). Die neue Bearbeitung kann ein Zwischenschritt sein, um kurzzeitig eine Major-Änderung für eine neue Version eines Templates zu erstellen, welche kurz vor Ballot dann als neue Version des originalen Templates erstellt wird. 10.Major und Minor-Änderungen an Templates erfordern (unabhängig davon, ob eine neue Version oder eine neue Bearbeitung erstellt wurde), immer ein Ballotverfahren vor Aktiv-Setzung des Templates. Patch-Änderungen können sofort "Aktiv" gesetzt werden, sollten jedoch idealerweise ebenfalls im Rahmen eines Ballotverfahrens "Aktiv" gesetzt werden.

(*) Anmerkung: Wird ein Template im Status „Entwurf“ nicht mehr benötigt (und wird auch von keinem anderen Leitfaden referenziert), soll es nicht auf "annulliert" oder "zurückgewiesen" gesetzt werden, sondern stattdessen soll der Inhalt gelöscht, der Titel auf „dummy“ (o.ä) umbenannt und die Template-Id auf .999 geändert werden. Dieses Dummy-Template kann später für neue Templates verwendet werden. Durch das Löschen des Inhalts werden auch evtl. bestehende Referenzen (Beziehungen zu anderen Templates) entfernt, und es scheint auch nicht mehr in den Beziehungen der referenzierenden Templates auf.

6 Datasets

Die Verwendung von Art-Decor-Datasets wird für neue Projekte empfohlen. Diese bilden die funktionalen Anforderungen an das Projekt ab und sind Diskussionsgrundlage bei Fachexpertengesprächen (erfordern kein technisches Hintergrundwissen).

Für Datasets gibt es keine speziellen Vorgaben hinsichtlich OID und Version & Metadaten.

Bereits bei der Modellierung der Datasets sollen bestehende Standards berücksichtigt werden (z.B. IHE PCC) und bestehende Dataset-Elemente so gut es geht aus anderen Projekten wiederverwendet werden (siehe auch Dataset versioning). Dies funktioniert durch die Eingabe eines Names und dem mit etwas Ladezeit folgendem Vorschlag von ähnlichen Konzepten. Dabei sollte der Sinn des Datasets, der aus der Beschreibung hervorkommt, derselbe sein.

Weitere offizielle Informationen sind unter ART Dataset Editor zu finden.

6.1 Name

Es gibt keine speziellen Namenskonoventionen, der Name ist jedoch anzugeben!

6.2 Inhalt

Es ist eine Beschreibung und der Werttyp/Valuetype anzugeben.

Wenn vorhanden muss zusätzlich angegeben werden:

  • Auswahllisten
  • Link zu codierten Konzepten / Value Sets (Terminologien)

Die Zuordnung von Dataset-Elementen und erstellten Templates unter "Template" → "Template-Mapping" wird empfohlen, ist aber nicht verpflichtend (siehe auch ART Template Associations). Dadurch sind alle mit einem Template assoziierten Konzepte in der Template-Beschreibung zusammengefasst, sowie direkt beim assoziierten CDA-Element bzw. Attribut des Templates ersichtlich. Dies dient der Kontrolle (auch für die Experten-/Arbeitsgruppe), dass alle erforderlichen Dataset-Elemente in den Templates modelliert wurden.

7 Templates

Ein Leitfadenprojekt besteht aus einem oder mehreren Document Level Templates (DLT) (jedes DLT entspricht dabei einem Dokumententyp), welche die Struktur für ein gültiges CDA-Dokument vorgeben. Darüber hinaus werden in einem Leitfadenprojekt zahlreiche nicht-DLT-Templates referenziert, die im at-cda-brr spezifiziert wurden. Ein Leitfadenprojekt kann außerdem nicht-DLT-Templates beinhalten, die ausschließlich für das Projekt spezifiziert wurden. Für die Verwendung ist folgende Seite ART Template Editor zu lesen.

Info: Solange das DLT noch nicht in der Transaktion des Szenarios verlinkt ist, wird dessen Label (im Template-Baum) als oranges Dreieck mit Pfeilen angezeigt, sonst als oranges Viereck/Buch.

7.1 Vorbedingungen für die Erstellung neuer Templates

Bevor neue Templates erstellt werden, sollte geprüft werden, ob bestehende Templates (bestenfalls im at-cda-bbr), die Anforderungen bereits erfüllen. Gibt es passende Templates können diese durch Referenzierung (unveränderte Übernahme) mittels Kettensymbol in das bestehende Projekt übernommen werden. In diesem Fall sind keine Änderungen an dem Template möglich! Diese Funktion sollte nur verwendet werden, wenn es bereits ein passendes ELGA-/e-Health-Template gibt.

Um herauszufinden, welche Art-Decor Projekte (auch außerhalb der eigenen Governance-Group) bereits ein bestimmtes Template umgesetzt haben, kann man im Menüpunkt „Auge“ (links oben in der ArtDecor-Projektseite), die Template-ID oder den Namen eines Templates angeben -> alle Templates mit zugehörigem Projekt werden aufgelistet.

7.2 Vorbedingungen für Änderungen bestehender Templates

Bevor ein bestehendes Template geändert wird (Erstellung einer neuen Version, welche automatisch von allen dynamisch referenzierenden Templates verwendet wird), ist zu überprüfen, wie sich diese Änderung auf andere Leitfäden auswirkt bzw. ob diese gewünscht ist. In allen betroffenen Leitfäden muss die Änderung auf der Diskussionsseite im Abschnitt "Ausblick" festgehalten werden.

Zu Beachten:

  • Wenn eine neue Version eines aus dem ATCDABBR referenzierten Templates (graues Icon im Template-Baum) benötigt wird, MUSS diese im ATCDABBR erstellt werden.
  • Soll ein Template, das im ATCDABBR erstellt wurde, in ein Projekt-Repository verschoben werden, muss dort zuerst eine evtl. bereits existierende Referenz darauf entfernt werden.
  • Fehlen die Berechtigungen für schreibenden Zugriff auf das ATCDABBR, sollen die erforderlichen Anpassungen zuerst im Projekt-Repository durchgeführt werden und können nach abgeschlossenem Ballot von Berechtigten ins ATCDABBR übernommen werden.

7.3 Name

Template-Namen sind grundsätzlich in englischer Sprache zu vergeben, sodass sie entsprechend ihrer Definition in internationalen Standards beibehalten werden können und die Wiederverwendbarkeit bestehender Templates erleichtert wird.

Eine Ausnahme bilden die Namen von Section-Level Templates. Diese werden auf deutsch vergeben, da sie den in den Arbeitsgruppen abgestimmten Titel der Sektion tragen sollen. Bei einer möglichen Unterscheidung zwischen uncodiert und codiert, ist dies mit einem Bindestrich anzugeben. (Alte Schreibweise mit unkodiert und kodiert ist nicht mehr zu verwenden!)

Empfehlung für Entries: Sind im Entry Referenzen auf andere Standards enthalten, soll der Name des Entries auch den entsprechenden Namen tragen (englisch). Ist dies nicht der Fall (im Entry gibt es z.B. nur eine ELGA Template ID), soll der Name des Entries an den Namen der Sektion angelehnt sein (deutsch). Beispiel: Die Sektion "Impfungen - codiert" (1.2.40.0.34.6.0.11.2.1) (mit AG abgestimmter Titel) referenziert durch Angabe der TemplateID (1.3.6.1.4.1.19376.1.5.3.1.3.23) auf den Standard IHE PCC (Immunizations Section) (und hält auch dessen Vorgaben ein). "Impfungen - codiert" beinhaltet u.a. ein Entry: "Immunization Entry" (1.2.40.0.34.6.0.11.3.1), welches wiederum laut Standarddefintion folgende Template IDs enthalten muss: HL7 CCD Medication activity (1.2.40.0.34.6.0.11.3.1) und IHE Immunizations Entry (2.16.840.1.113883.10.20.1.24). Daher trägt das Entry den Namen, der auch im Standard angegeben wird (mit dem Zusatz "Entry").


Weitere Vorgaben für Name und Display-Name (Bezeichnung) eines Templates:

  • Der Name eines Templates wird wie folgt angegeben:
[Präfix]_[Template-Typ]_[ElementName]
Als Trenner fungieren Unterstriche ("_"), wobei folgendes gilt:
  • [Präfix]: Als Präfix dient das Projektkürzel (Name des Repositories) ohne Bindestriche, z.B. "atcdabrr" oder "atlab". Diese Präfixe bleiben auch beim Verschieben ins at-cda-bbr bestehen!
  • [Template-Typ]: Der Template-Typ muss einen der folgenden Template-Typen enthalten:
  • "document": für Document-Level-Templates
  • "header": für Header-Level-Templates
  • "section": für Sektionen
  • "entry": für Entries
  • "other" : alle Templates/Fragmente, die nicht in obige Kategorien fallen ("Template type not specified")
  • [ElementName]: Entspricht dem Display-Name ohne Leerzeichen, Bindestriche und Klammern "( )". Der ElementName wird in Upper-CamelCase-Notation angegeben.
  • Der Display-Name enthält nur den ElementName (kein Präfix oder Template-Typ), wobei aber Leerzeichen, Bindestriche und Klammern "( )" verwendet werden dürfen. Dieser wird in der Template-Baum-Struktur angezeigt.

Beispiele:

  • Document-Level-Template im ELGA e-Impfpass Repository:
Name: "eimpf_document_KompletterImmunisierungsstatus"
Display-Name: "Kompletter Immunisierungsstatus"
  • Header-Level-Template im at-cda-bbr:
Name: "atcdabbr_header_Author"
Display-Name: "Author"
  • Uncodierten Sektion im Repository at-cda-bbr:
Name: "atcdabrr_section_FruehereErkrankungUncodiert"
Display-Name: "Frühere Erkrankungen - uncodiert"
  • Codierten Sektion im ELGA e-Impfpass Repository:
Name: "eimpf_section_ImpfrelevanteErkrankungenCodiert"
Display-Name: "Impfrelevante Erkrankungen - codiert"
  • Entry im at-cda-bbr:
Name: "atcdabbr_entry_ImmunizationEntry"
Display-Name: "Immunization Entry"
  • Compilation/Other-Template im at-cda-bbr: Compilations/Other sind Template-Fragmente, wie z.B. Adressinformationen. Da sich diese in einem Leitfaden oft wiederholen können, sollen sie mit "contains" in Templates eingebunden werden (d.h. der Inhalt der Compilation wird nicht im verlinkenden Template angezeigt). Diese sollen aber im Leitfaden als eigene Kapitel vorhanden sein.
Name: "atcdabbr_other_AddressCompilation"
Display-Name: "Address Compilation"

7.4 OID

OIDs werden einmalig gesetzt und nicht mehr geändert. Alle Art-Decor Templates müssen unterhalb des OID-Knotes 1.2.40.0.34.6.0.11 liegen (eHealth-Austria/services/art-decor/templates). Die OID der Art-Decor Templates sollen außerdem entsprechend ihres CDA-Template-Typs aus folgenden Unterknoten vergeben werden:

.0. Document-Level Template
.1. Header-Level Template
.2. Section-Level Template
.3. Entry-Level Template
.9. other CDA Fragment Template

Beispiele:

  • Header-Level-Template: 1.2.40.0.34.6.0.11.1.2 Author (eHealth-Austria/services/art-decor/templates/header/xxx)
  • Entry-Level-Template: 1.2.40.0.34.6.0.11.3.15 Antikörper-Bestimmung Data Processing Entry (eHealth-Austria/services/art-decor/templates/entry/xxx)
Wichtiger Hinweis:Die Verwaltung der unter diesen Knoten liegenden Templates unterliegt Art-Decor und benötigt daher keine Registrierung über das OID-Portal. Die nächste freie OID für Templates muss über die ELGA Art-Decor Governance Group Template (Vorsicht!: lange Ladezeit) ermittelt werden.

7.5 Version & Metadaten

  • Für neu angelegte Templates (Entwurf-Status) soll im Version Label die Version 1.0.0 angegeben werden. Wenn das Template aktiv gesetzt wird, wird das aktuelle Datum ergänzt. Nur das DLT erhält immer das Datum, an dem der Leitfaden veröffentlicht wird. Die genauen Vorgaben zur Versionierung sind hier zu nachzulesen Versionierung.
  • Der Zweck des Templates muss aus der Beschreibung hervorgehen. Im Fall von generischen Templates, die im at-cda-bbr angelegt werden und abgeleitet werden müssen (z.B. weil noch kein Value Set referenziert wurde), soll die Beschreibung möglichst allgemein gehalten werden.
  • Modellierung der Templates  "offen/geschlossen":
    • ELGA Implementierungsleitfäden werden seit 2020 "geschlossen" modelliert. Somit können nur die Elemente verwendet werden, die explizit modelliert werden oder durch den Datentypen implizit erlaubt sind. Sobald bei einem Element mit gesetzten Datentypen ein Unterelement einfügt wird, sind die vom Datentypen möglichen Elemente nicht mehr implizit erlaubt, sondern müssen nun auch explizit modelliert werden. Attribute sind davon ausgenommen.
    • Templates von eHealth Implementierungsleitfäden können auch "offen" modelliert werden.
  • Es ist zumindest ein korrektes Beispiel anzugeben.

Beim Ableiten von Templates ist durch einen der folgenden Beziehungstypen anzugeben, wie sie sich zueinander verhalten (siehe auch Creating a new version of an existing template). Die Template-ID des Basistemplates wird nur zu Zwecken der Nachvollziehbarkeit in den Metadaten angegeben, in der Template-Spezifikation selbst muss sie entfernt werden, weil dies sonst bei der Generierung von "closed" Schematron-Regeln zu Inkonsistenzen und zu falsch-positiven Schematron-Fehlern bei der Validierung führen kann.

  • Spezialisierung: bestehende Vorgaben werden weiter eingeschränkt (z.B. von [O] auf [M] oder von 0..* auf 0..1, ebenfalls [O] auf [NP])
  • Adaptierung: bestehende Vorgaben werden erweitert oder geändert (z.B. von [M] auf [O] oder von 0..1 auf 0..*) oder neue Elemente, Attribute, ValueSets, Fixe Werte werden hinzugefügt.

Die Übernahme vorhandener Templates aus Projektverzeichnissen, die NICHT referenziert sind, ist nicht über die GUI möglich, weil diese Templates nicht als Prototyp angegeben werden können (d.h. von ihnen kann nicht geerbt werden).

Soll der Inhalt eines Templates trotzdem verwendet werden, lässt sich mittels Browser-Direktlink

https://art-decor.org/temple/views/temple.html?id=[OID des Templates]&[effectiveDate]&[prefix]&[language]&mode=readonly

der XML-Code jedes Templates via Temple (im Lesemodus) anzeigen und anschließend kopieren. Der Inhalt kann dann in ein neu erstelltes Template eingefügt werden. Dabei ist zu beachten, dass der Zeitpunkt (effectiveDate) und die OID des neu erstellten Templates nicht verändert werden. Alle weiteren Inhalte können entsprechend angepasst werden. Die OID muss in einem späteren Arbeitsschritt über die GUI korrigiert werden.

Beispiel:

https://art-decor.org/temple/views/temple.html?id=2.16.756.5.30.1.1.10.2.63&effectiveDate=2020-06-26T00:00:00&prefix=cdachvacd-&language=de-DE&mode=readonly

7.6 Inhalt

  • Warning.png Wenn möglich, sollen bereits vorhandene Templates verwenden werden.
  • Zugrundeliegende Standards dürfen nur eingeschränkt, aber nicht erweitert werden.
    • Hinweis: Wenn ein Template laut Standard "required" ist, aber für den konkreten Leitfaden nicht benötigt wird, kann das Template mit einem nullFlavor erstellt werden (z.B. Freitext-Inhalt „keine Information“ oder Code „entry empty“). Dadurch wird der Standard nicht verletzt und das Template kann trotzdem verwenden werden.
  • Optionalitäten und Reihenfolge der Elemente müssen eingehalten werden.
  • Die erste Template-ID soll wie folgt bezeichnet werden: "HL7 Austria - [Name des Templates]". Diese Template-ID muss aus dem OID-Knoten 1.2.40.0.34.6.0.11 stammen.
    • Warning.png Jene Template-ID, die beim Erstellen eines neuen Templates oder Ableiten eines Prototyps von Art-Decor automatisch hinzugefügt wird, muss entfernt bzw. ersetzt werden (nur über GUI mögich, nicht via Temple: "Template bearbeiten" → "#")
  • Weitere Template-IDs können angegeben werden, sofern das im zugrundeliegenden Standard gefordert ist (z.B. IHE).
  • include vs. contains
    • Im CDA-Header sollen alle Elemente mit include eingebunden werden.
      • Ausgenommen davon sind so genannte Compilation-Elemente, die in die Kategorie "Template type not specified" fallen (z.B. Address Compilation, Performer Body - Laboratory, etc.)
    • Ab dem component/structuredBody soll nur mehr mit contains gearbeitet werden.
  • Elemente und Attribute, die im Template verwendet werden, sind zu dokumentieren. Dabei kann in der Dokumentation auch auf den zugrundeliegenden Standard verwiesen werden.
  • Elemente die auf XDS-Metadaten gemappt werden müssen, sollen mit "↔ Hinweis zum XDS-Mapping" gekennzeichnet sein.
    • Beispiel: ↔ Hinweis zum XDS-Mapping: Das "templateId"-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut "formatCode" gemappt (ohne Präfix XDSdocumentEntry.formatCode^)
  • Es ist beim Neu-Erstellen wie auch beim Bearbeiten eines Templates zu überprüfen, ob die Datentypen nach R-MIM richtig eingehalten werden.
  • Wen man bei Elementen mit Datentypen Unterelemente vorgibt, muss man dabei alle anderen Unterelemente auch vorgeben. Es werden die möglichen Unterelemente des Datentyps sonst nicht erlaubt.
  • Bei einigen Datentypen muss man neben der Art-Decor Dokumentation, zusätzlich das ELGA-Schema beachten, damit die ELGA-Anpassungen mitbeachtet werden.
  • Es sollen in Art-Decor immer nur CD, CE und CV verwendet werden, nicht die IPS oder SDTC Varianten. Das ELGA-Schema bietet diese Erweiterungen bereits innerhalb CD, CE und CV an.
  • Jedes Template sollte ein Beispielsnippet enthalten, in dem die korrekte Anwendung des Templates angegeben wird. In der Regel werden Beispielsnippets nur zum Template selbst erstellt, nicht zu den darin verlinkten Templates (z.B. included Entries).
    • Idealerweise werden Beispielsnippets als letztes ergänzt, um den Aufwand an Änderungen im Template gering zu halten.
  • Der Name eines Templates (nicht der Display-Name!) kann nach dem Erstellen des Templates nur mittels Temple geändert werden! Die Änderung des Namens hat keinen Einfluss auf die Referenzierung durch andere Templates -> hier gilt die OID. Der Display-Name kann jederzeit über GUI oder Temple geändert werden.
  • Wird die OID geändert, wenn das Template bereits durch andere Templates refereziert wird, werden alle bestehenden Referenzen darauf ungültig! Daher vor der Änderung der OID die Liste aller referenzierenden Templates abspeichern und diese hinsichtlich der neuen OID anpassen!

Kardinalität / Konformität

Im Allgemeinen Implementierungsleitfaden wird unter der Legende der Konformitätskriterien beschrieben, welche Kardinalitäten und Konformitäten in den ELGA Leitfäden vorkommen können. Die folgende Tabelle stellt dar, wie diese Kriterien in Art-Decor umzusetzen sind (siehe auch Mandatory/Conformance).

Für Elemente
Vorgaben Allgemeiner Leitfaden Verwendung von nullFlavor Umsetzung Art-Decor am Beispiel eines id-Elements mit dem Datentypen II (in Temple)
1..1 M nicht erlaubt <element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="1" conformance="R" isMandatory="true">
1..* M nicht erlaubt <element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R" isMandatory="true">
0..0 NP nicht erlaubt <element name="hl7:id" datatype="II" conformance="NP">

Achtung, bei templateIds sollte zusätzlich ein Prädikat angegeben werden, damit auch das Schematron richtig erstellt wird:

<element name="hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.3.2.1']" datatype="II" conformance="NP">

  <attribute name="root" value="1.3.6.1.4.1.19376.1.3.3.2.1" datatype="uid" />

</element>

1..1 R erlaubt <element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="1" conformance="R">
1..* R erlaubt <element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R">
0..1 R nicht erlaubt <element name="hl7:id[not(@nullFlavor)]" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformance="R">
0..* R nicht erlaubt <element name="hl7:id[not(@nullFlavor)]" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformance="R">
0..1 O erlaubt <element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1">
0..* O erlaubt <element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*">
0..1 C Abhängig vom Kontext <element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformace="C">
0..* C Abhängig vom Kontext <element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformace="C">
Für Attribute
Vorgaben Allgemeiner Leitfaden Umsetzung Art-Decor
0..0 NP <attribute name="root" datatype="uid" prohibited="true"/>
1..1 R <attribute name="root" datatype="uid"/>
0..1 O <attribute name="root" datatype="uid" isOptional="true"/>
1..1 F <attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.2.1"/>
0..1 F <attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.2.1" isOptional="true"/>

8 Value Sets

Eine Anleitung zur Verwendung des Value Set Editors ist unter ART Value Set Editor zu finden.


Seit 2022 steht unter https://termgit.elga.gv.at/ ein neuer Terminologieserver zur Verfügung. Die Dokumentation findet sich auf https://termgit.elga.gv.at/documentation_and_support_de.html und https://termgit.elga.gv.at/faq_de.html

8.1 Name

Name und Display-Name (bzw. Title auf Termgit) eines Value Sets müssen wie folgt angegeben werden:

  • Name: [Präfix]-[ValueSetName] (lowercase-Schreibweise)
  • Display-Name/Title: [Präfix]_[ValueSetName] (UpperCamelCase-Schreibweise)

Sonderzeichen sind nicht erlaubt. Als Präfix dient das Projektkürzel (Name des Repositories), z.B. "eimpf".

Beispiele:

  • Name: eimpf-antikoerperbestimmung
  • Title: eImpf_Antikoerperbestimmung
  • Name: elga-administrativegender
  • Title: ELGA_AdministrativeGender

8.2 OID

Alle Art-Decor Value Sets müssen unterhalb des OID-Knotes 1.2.40.0.34.6.0.10 liegen (eHealth-Austria/services/art-decor/value-sets).

Beispiele:

  • Value Set: 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS (eHealth-Austria/services/art-decor/value-sets/xxx)
Wichtiger Hinweis: Die Verwaltung der unter diesen Knoten liegenden Value Sets unterliegt Art-Decor und benötigt daher keine Registrierung über das OID-Portal. Die nächste freie OID für Value Sets muss über die ELGA Art-Decor Governance Group Value Sets (Vorsicht!: lange Ladezeit) ermittelt werden.

8.3 Version & Metadaten

Versionierung: Siehe Versionierung.

8.4 Inhalt

Best Practices für die Erstellung und Pflege von Value Sets müssen angewendet werden, z.B. können Konzeptcodes hinzugefügt, aber nicht gelöscht werden, nur auf den Status "deprecated" gesetzt werden.

Wichtiger Hinweis: Wenn sich die Gesamtbedeutung der Codes in einem Value Set ändert, muss die neue Version des Value Sets eine neue OID erhalten.

9 Beispielbefunde

Neben den Beispielsnippets in den Templates sind Beispielbefunde und Falsch-Beispielbefunde zu erstellen. Ein Grundgerüst für ein Beispieldokumentekann erstellt werden, indem man im entsprechenden DLT den Zauberstab des Template Editors anwendet und rekursiv alle Code-Snippets der darin verlinkten Templates einfügt.

Name

Der Name von (Falsch-)Beispielbefunden sollte folgendermaßen aufgebaut sein. Die einzelnen Elemente werden mit "_" verbunden.

"falsch_": Angabe, dass es sich um einen Falsch-Beispielbefund handelt.

[Präfix]: Als Präfix dient das Projektkürzel (Name des Repositories), z.B. "eimpf"

[optional DLT-Name]: Name des DLTs, wenn es in dem Projekt mehrere DLTs gibt.

[Kurztitel des Beispiels]: Erklärt ganz kurz, worum es in dem Beispielbefund geht.

Beispiele:

  • at-lab_Laborbefund_Kompletter_Befund.xml
  • falsch_at-lab_Laborbefund_Constraint_gebrochen.xml

Inhalt

  • Beispielbefunde
    • sind vollständig valide und bilden verschiedene reale Szenarien ab.
  • Für Falsch-Beispielbefunde sollte mindestens jeweils ein Befund vorhanden sein für
    • das Brechen eines Contraints,
    • das Verwenden eines falschen Wertes wo ein Value Set Wert erwartet wird,
    • das Verwenden eines nicht CDA-Elementes (nicht im Schema vorhanden),
    • das Verwenden eines verbotenen Elementes
    • das Weglassen eines Pflichtfeldes.

10 Szenarios / Schematron

Das Erstellen von einer Transaktion pro DLT in den Szenarien ist für die Generierung von Schematron-Regeln zwingend erforderlich, siehe Schematron-Erstellung und Bereitstellung.

Für Szenarios gibt es keine speziellen Vorgaben hinsichtlich OID oder Version & Metdaten.

Eine Anleitung zur Verwendung des Szenario Editors ist unter ART Scenario Editor zu finden.

10.1 Name

Der Name/Label der Transaktionen soll dem Schema [NameDesSzenarios] folgen. Alles zusammengeschrieben, kein Prefix.

Der im Label der Transaktion angegebene Name wird von Art-Decor später automatisch als Name für das entsprechende Schematron verwendet, z.B. „eimpf-UpdateImmunisierungsstatus“, wobei das Präfix des Projektes mit dem folgenden Bindestrich automatisch ergänzt wird.

10.2 Inhalt

Optional ist es für jede Transaktion möglich das Dataset ("Konzepte") anzugeben und für jedes Element Kardinalität (optional, wiederholbar) und Konformität (erforderlich, obligatorisch) festzulegen. Die Angabe von Kardinalität und Konformität ist für die Erstellung eines Schematrons nicht zwingend erforderlich.

11 Qualitätssicherung

11.1 Art-Decor

Offizielle Informationen zur Qualitätssicherung eines Projekts in Art-Decor finden sich auf der Seite Preflighting publication and quality checks.

  • Template-Checks:
    • korrektes Präfix, Name, Displayname
    • open/closed
    • korrektes Value Set
    • Beispielsnippets
    • Templatebeschreibung
    • Standardreferenzen
    • Dataset Mapping (optional)
    • im Beispieldokument enthalten
    • Schematron Asserts ergänzen
  • DLT bei jeder Version MUSS in hl7at:formatCode die Versionierungsinfo + Publikationsdatum im Label angepasst werden.
    • Entsprechende Adaptierung von CodeSystem ELGA_FormatCode und ValueSet ELGA_FormatCode
  • Temlatestatus:
    • für Ballot: Templates bleiben im Entwurf-Status
    • nach Ballotabschluss: Versionlabel mit Publikationsdatum ergänzen und Templates aktiv setzen
  • Zur Prüfung des Projektschemas unter dem Menü "Project" → "Development" → "Check DECOR" ein Dataset auswählen und die Prüfung durchführen. Eventuelle Fehler, Warnungen oder Hinweise werden anschließend in einer Liste dargestellt.
  • Nach der Erstellung eines Schematrons unter "Project" → "Development" → "Compile a development version" (für Details siehe Schematron-Erstellung und Bereitstellung) ist es möglich, über "Validate XML instance" Beispielbefunde für die verschiedenen Szenarios zu validieren.
  • AD-Bot starten (lassen) (am Vortag der Publikation)

11.2 Wiki

Im Wiki werden die Metadaten vor dem setzen des Seiten-Status auf Abnahme nochmals überprüft.

  • Anpassung Titelblatt
    • Publikationsdatum
    • Versionsinformationen mit DLT abgleichen
  • Infobox: „In Arbeit“ entfernen
  • Prüfen, ob alle Templates eingefügt und Value Sets verlinkt wurden
  • Linkverzeichnisse, Referenzen prüfen
  • ggf. Informationen bezüglich hl7at:formatCode auf der Wiki-Seite aktualisieren
  • Diskussionsseite aktualisieren
    • Diskussionsseiten sollen wie folgendes Beispiel aufgebaut sein (Diskussionseite Telemonitoring-Episodenbericht)
    • prüfen, ob Elemente aus dem "Ausblick" in der aktuellen Version umgesetzt wurden. Falls ja, sind diese in die Tabelle des "Release-Log" zu verschieben.
  • Revisionsliste des Leitfadens auf Basis der Diskussionsseite aktualisieren
  • Links prüfen und optimieren: Nur externe Links sollen in neuem Tab geöffnet werden, Sprungmarken sollten immer mit # gekennzeichnet sein.
  • PDF: Druck checken (leere Seiten, Suche nach: „Error“, „Fehler“, "TODO")
  • Wiki-Seite Status ändern auf "abgenommen"
  • falls neue Hauptversion dann OID im OID Portal eintragen lassen
  • Wiki-Guide aktualisieren (neue Zeile für neue Version, PDF upload)
  • Seiten-Status ändern auf "abgenommen"

11.3 GitLab

Eine erweiterte Qualitätssicherung wird auch in GitLab erstellt. Hier werden beim Einstellen von (Falsch-)Beispielbefunden oder Schematron-Regeln in die jeweiligen Projekte automatisch Prüfroutinen (Schematron-Validierung) gestartet.

  • Beispielbefunde aktualisieren
  • Falsch-Beispielbefunde aktualisieren
  • Schematron aktualisieren

12 Anhang

12.1 Links