Governance für die CDA-Leitfadenerstellung

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

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 Hilfe 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-Leitfaden (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 Hilfe:Leitfaden erstellen), 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 besteht üblicherweise aus den Kapiteln:

1. Zusammenfassung
2. Informationen über dieses Dokument
   1. Impressum
   2. Haftungsausschluss
   3. Sprachliche Gleichbehandlung
   4. Lizenzinformationen
      1. Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")
      2. SNOMED CT
      3. Weitere Terminologien
   5. Verwendete Grundlagen und Bezug zu anderen Standards
   6. Verbindlichkeit
   7. Wichtige unterstützende Materialien
   8. Bedienungshinweise
      1. Farbliche Hervorhebungen und Hinweise
      2. PDF-Navigation
3. Begriffsdefinitionen
4. Einleitung
   1. Ausgangslage und Motivation
   2. Zweck des Dokuments
   3. Zielgruppe
5. Leitfadenerstellungs- und Harmonisierungsprozess
   1. Revision der Leitfäden
   2. Autoren und Mitwirkende
      1. Autoren
      2. Mitwirkende
6. Technischer Hintergrund
7. Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden
8. Funktionale Anforderungen
   1. Voraussetzungen für den Zugriff auf e-Befunde in ELGA
   2. Anwendungsfälle des Dokumentenmanagements
      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
    1. Übersicht CDA Strukturen (Header & Body)
       1. (evtl. Übersichtstabelle der Header-Elemente für dokumenten-relevante Zeitpunkte/Zeitspannen)
    2. CDA Templates
       1. Document Level Templates
       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)
       3. Section Level Templates
       4. Entry Level Templates
       5. Weitere CDA Fragmente
       6. Terminologien
15. Anhang
    1. (evtl. Abkürzungsverzeichnis)
    2. Abbildungsverzeichnis
    3. Tabellenverzeichnis
    4. Einzelnachweise /
    5. Literatur und Weblinks
    6. Revisionsliste
    7. 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 - sollte keine Bindestriche enthalten, z.B. elgatest>
• 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 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:

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

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").

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

|| 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 - Semantic Competence Center - Extranet - ELGA Confluence). (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 OID, aber ein neues Erstellungsdatum. Die Versionsnummer im Version-Label des Templates muss an der entsprechenden Stelle um 1 erhöht werden (siehe Versionierung - Semantic Competence Center - Extranet - ELGA Confluence).

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 - Semantic Competence Center - Extranet - ELGA Confluence). 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. |}