ART-DECOR Governance

1 Zusammenfassung

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

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). Dieses Dokument wird laufend aktualisiert, sobald die Nutzer der Tools einen neuen Konsens erzielen.

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.

2 Anwendungsbereich

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. Es definiert Regeln und Strukturen, die von allen Anwendern dieser Werkzeuge eingehalten werden müssen.

Wichtiger Hinweis: Informationen zum Erstellungsprozess von Art-Decor CDA-Implementierungsleitfäden finden Sie unter Prozess der CDA-Leitfadenerstellung in Art-Decor.

3 Weiterentwicklung des Dokuments

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

Wichtiger Hinweis: Anfragen hinsichtlich der Änderung oder Erweiterung dieses Dokuments stellen Sie bitte an cda@elga.gv.at.

4 Governance für die CDA-Leitfadenerstellung mit Art-Decor

4.1 Sprache

ELGA Implementierungsleitfäden werden in deutscher Sprache verfasst. Dazu gehören textuelle Beschreibungen im Wiki, Art-Decor-Templates und Datasets.

Template-Namen sind grundsätzlich in englischer Sprache zu vergeben, sodass die Bezeichnungen entsprechend ihrer Definition in anderen (internationalen) CDA-Leitfäden beibehalten werden können und die Wiederverwendbarkeit bestehender Templates in weiteren Leitfäden 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. Empfehlung für Entries: Sind im Entry Referenzen auf andere (internationale) 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 - kodiert" (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 - kodiert" 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").

4.2 Verwendung von OID

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

4.2.1 OID für Implementierungsleitfäden

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.

Falls Dokumente in aufeinander aufbauenden Versionen vorliegen, muss dafür darunter eine zusätzliche Ebene angelegt werden.

Beispiel:

• 1.2.40.0.34.7.18: Implementierungsleitfaden Meldung von antimikrobieller Resistenzen
• 1.2.40.0.34.7.18.1: Implementierungsleitfaden Meldung von antimikrobieller Resistenzen - Version 1.00

4.2.2 Art-Decor Root OID

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.

4.2.2.1 Root OID für Templates

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 folgender 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 Art-Decor Governance Group, unter HL7 Austria - "List of Artefacts under this Governance Group" / Reiter "Templates" ermittelt werden.

4.2.2.2 Root OID für Value Sets

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 Art-Decor Governance Group, unter HL7 Austria - "List of Artefacts under this Governance Group" / Reiter "Value Sets" ermittelt werden.

4.3 Namens- und Versionierungs-Konventionen

Es wird zwischen den Namens- und Versionierungs-Konventionen von Datasets, Templates und Value Sets unterschieden.

4.3.1 Datasets

Zu jedem Dataset müssen Name und Versions-Label (VersionLabel) angegeben werden.

Der Name des Datasets ist passend dem Inhalt zu wählen.

Das Versions-Label (VersionLabel) des DataSets muss wie folgt angegeben werden: [Hauptversions-Jahr].[optionale Nebenversions-Nummer]

Als Trenner fungiert ein Punkt ("."), wobei folgendes gilt:

[Hauptversions-Jahr]

Das Jahr in welcher die Hauptversion publiziert wurde. Es wird zur Zeit als sehr unwahrscheinlich genommen das eine Hauptversion mehr als ein Mal im Jahr publiziert wird.

[optionale Nebenversions-Nummer]

Eine darauffolgende Nummer welche für jede neue Nebenversion um eins hochgezählt wird.

Beispiele:

• 2019 für die erste Hauptversion
  
• 2019.1 für eine neue Nebenversion der Hauptversion 2019
  
• 2019.2 für eine weitere Nebenversion der Hauptversion 2019
  
• 2021 für eine neue Hauptversion im Jahr 2021
  
• 2021.1 für eine neue Nebenversion der Hauptversion 2021
  
• usw.

4.3.2 Templates

Zu jedem Template müssen Bezeichnung (DisplayName), Versions-Label (VersionLabel) und Name des Templates angegeben werden.

Die Bezeichnung (DisplayName) des Templates ist passend zu wählen und bei einer möglichen Unterscheidung zwischen unkodiert und kodiert dies mit einem Bindestrich folgend anzugeben, z.B.: "Kompletter Immunisierungsstatus" oder "Frühere Erkrankungen - unkodiert". Ist das Template unverändert aus einer anderen Spezifikation übernommen, empfielt es sich dieses mit dem originalen Namen des Templates zu bennen, wie z.B.: "Author" oder "Immunization Entry".

Das Versions-Label (VersionLabel) des Templates muss gleich dem des DataSets angegeben werden ([Hauptversions-Jahr].[Nebenversions-Nummer], siehe oben).

Der Name des 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), z.B. "atcdabrr".

[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, die nicht in obige Kategorien fallen ("Template type not specified")

[ElementName]

Bezeichnung des Templates in Upper-CamelCase-Notation.

Beispiele:

• Document-Level-Template im ELGA e-Impfpass Repository:

Name: "eimpf_document_KompletterImmunisierungsstatus"

DisplayName: "Kompletter Immunisierungsstatus"

• Header-Level-Template im AT-CDA-BBR:

Name: atcdabbr_header_Author

DisplayName: Author

• Unkodierten Sektion im Repository AT-CDA-BBR:

Name: "atcdabrr_section_FruehereErkrankungUnkodiert"

DisplayName: "Frühere Erkrankungen - unkodiert"

• Kodierten Sektion im ELGA e-Impfpass Repository:

Name: "eimpf_section_ImpfrelevanteErkrankungenKodiert"

DisplayName: "Impfrelevante Erkrankungen - kodiert"

• Entry im AT-CDA-BBR:

Name: "atcdabbr_entry_Immunization"

DisplayName: "Immunization Entry"

• Other-Template im AT-CDA-BBR:

Name: atcdabbr_other_AddressCompilation

DisplayName: "Address Compilation"

Hinweise zur Änderung bestehender Templates siehe [Leitfadenerstellung - Änderung bestehender Templates]

4.3.3 Value Sets

Die Namen von Value Sets werden wie folgt angegeben: [Präfix]_[ValueSetName]_VS
Als Trenner fungieren Unterstriche ("_"), wobei folgendes gilt:

[Präfix]

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

[ValueSetName]

Bezeichnung des Value Sets in Upper-CamelCase-Notation, wobei "Displayname" und "Name" des Value Sets identisch sein sollen

VS

steht immer am Ende jeder Value Set Bezeichnung

Beispiel:

• Name: eimpf_Abrechenbarkeit_VS
• Wiedergabename: eimpf_Abrechenbarkeit_VS

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.

Bei der Aktualisierung eines Value Sets muss im Version-Label prinzipiell das Datum der Gültigkeit eingetragen werden. Dies geschieht im Format [Jahreszahl]-[Monat]-[Tag].
Beispiele:

• 2019-01-16 für den 16.1.2019
  
• 2020-11-20 für den 20.11.2020

4.4 Item-Label

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. „eimpf-UpdateImmunisierungsstatus“.

4.5 Repositories

4.5.1 Art-Decor Building Block Repository

In Österreich kann derzeit folgendes bereichsspezifische Building Block Repository (BBR) verwendet werden:

• 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 werden können.

Das ATCDABBR wird laufend mit neuen Templates erweitert. Nach Fertigstellung eines neuen CDA-Leitfadens sollen entsprechende Templates in dieses Verzeichnis übernommen werden.

Die im ATCDABBR befindlichen Templates dürfen nur von einem eingeschränkten Benutzerkreis bearbeitet werden. Verantwortlichkeiten und Prozesse sind im Kapitel #Revision beschrieben.

4.5.1.1 Ableitung von Templates

Beim Ableiten von Templates soll einer der folgenden Beziehungstypen angegeben werden:

• 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 (z.B. von [M] auf [O] oder von 0..1 auf 0..*) oder neue Elemente, Attribute, ValueSets, Fixe Werte werden hinzugefügt.

Weitere Informationen sind im "Prozess der CDA-Leitfadenerstellung" unter Relationship zu finden.

4.5.2 Projektverzeichnisse

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

4.6 Governance Groups

Governance-Gruppen sind organisatorische Einheiten, die dazu dienen, die Verantwortung für Artefakte in Art-Decor darzustellen. Unter Art-Decor Governance Group sind alle Projekte der HL7 Austria sichtbar, sowie alle angelegten Artefakte mit OID, Displayname, #Artefaktstatus, BBR und Projekte, die das Template oder Value Set referenzieren.

4.6.1 Artefaktstatus

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 "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:

Default state diagram for Art-Decor artefacts

TODO: Beschreibung, wann von draft in active wechseln.
TODO: Example for CH anpassen, nicht verwendete Zustände aus Tabelle entfernen

Art-Decor state machine

Status	Action	Trigger / Description	Example for CDA-CH	Responsibility
draft	activate	Artefact is finished and it is considered as final (no review needed).	n/a for CDA-CH as review necessary.	Developer
	consider	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.	final draft for a CDA-CH V2 template ready to review.	Developer (info to the Reviewer)
	cancel	If an artefact is not further developed, it is cancelled.	any developed draft template not to be used anymore.	Developer
pending	activate	Upon decision of the review team.	CDA-CH V2 template has been reviewed within HL7 Switzerland and was considered to be ready for release.	Review team of the repository.
	reject	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.
rejected		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
active	review	Maintenance or update of a project/repository.	Review CDA-CH template to consider it for CDA-CH v2.	Repository / Project owner
	retire	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
pre-publication review	reactivate	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
	retire		A CDA-CH template is not used anymore or replaced by another one.

4.7 Dokumentation

4.7.1 Templates

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

TODO:

• Open vs. Closed Templates

4.7.2 Standard-Referenzen

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.

4.8 Datasets

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).
Folgende Inhalte eines Dataset-Elements sind mindestens anzugeben:

• Name
• Beschreibung
• Datentyp

wenn vorhanden:

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

4.9 Szenarios

Das Erstellen von Transaktionen im Rahmen von Szenarios ist für die Generierung von Schematron-Regeln zwingend erforderlich.
Die Transaktion soll dem Schema [Projektkürzel]_[Name des Szenarios] folgen.
Die Angabe von Kardinalität (optional, wiederholbar) und Konformität (erforderlich, obligatorisch) für die einzelnen Elemente des Datasets wird empfohlen.

4.10 Dataset-Mapping

Die Zuordnung von Datensatz-Elementen und erstellten Templates wird empfohlen (Informationen zum Dataset-Mapping)

5 Governance für die CDA-Leitfadenerstellung mit Mediawiki

5.1 Leitfaden erstellen

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

5.1.1 Namespace

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

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

5.2 Struktur eines CDA-Implementierungsleitfadens

Folgende Angaben hinsichtlich des Aufbaus einen Implementierungsleitfadens sind einzuhalten.

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. Dies hat den Vorteil, das mit den Onboard-Mitteln des Wikis verschiedene Seiten-Versionen (über den Reiter "Versionsgeschichte") leichter verglichen werden können.

5.2.1 Typische Gliederung eines Dokuments

Um eine konsistente Vorgehensweise bei der Erstellung und Darstellung eines Implementierungsleitfadens zu gewährleisten, wird folgende (minimale) Struktur vorgegeben: TODO REVIEW

1 Zusammenfassung

2 Informationen über dieses Dokument

2.1 Impressum

2.2 Haftungsausschluss

2.3 Sprachliche Gleichbehandlung

2.4 Lizenzinformationen

2.5 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")

2.6 Verbindlichkeit

2.7 Verwendete Grundlagen und Bezug zu anderen Standards

2.8 Weitere unterstützende Materialien

3 Einleitung

3.1 Ausgangslage und Motivation

3.2 Zweck des Dokuments

3.3 Zielgruppe

4 Harmonisierung

4.1 Autoren und Mitwirkende

5 Begriffsdefinitionen

6 Technischer Hintergrund

6.1 Allgemeine Richtlinien

6.2 Datentypen

7 Funktionale Anforderungen

7.1 Darstellung

7.2 Verwendung in der ELGA Infrastruktur

7.2.1 Vorgaben zu Dokument-Metadaten (XDS-Metadaten)

7.3 Versionierung & Stornierung von Dokumenten

7.4 Mehrsprachigkeit und grenzüberschreitender Austausch

8 User Storys ("Anwendungsfälle")

9 Dataset

10 Technische Spezifikation

10.1 Übersicht CDA Strukturen (Header & Body)

10.2 CDA Templates

10.2.1 Document Level Templates

10.2.2 Header Level Templates

10.2.3 Section Level Templates

10.2.4 Entry Level Templates

10.2.5 Weitere CDA Fragmente

10.3 Terminologien

11 Anhang

11.1 Abbildungsverzeichnis

11.2 Abkürzungsverzeichnis

11.3 Literaturverzeichnis

5.3 Revision

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

6 Releases

6.1 Art-Decor

TODO

6.3 Check before finalizing

Thew folowing checks help to identify possible errors or missing includes from Art-Decor.

• Perform search for:
  • "/dynamic"
  • "/static"
  • "Cannot find"
  • ...

Afterwards: Create a revision according to Wiki revisions.

7 Verantwortliche Personen

7.1 Support for Art-Decor

TODO

7.2 Governance Groups

TODO

7.3 Repositories

TODO

7.4 Wiki

TODO

8 Qualitätssicherung und Review

8.1 Art-Decor Repository

TODO

8.2 ELGA Implementierungsleitfäden

TODO: Prozess # muss eingehalten werden

9 Anhang

9.1 Links

• Art-Decor Workspace
• Art-Decor Dokumentation
• eHealth Wiki
• Wiki Hilfe

9.4 Zur Diskussion stehende Änderungsvorschläge

TODO