ART-DECOR Governance: Unterschied zwischen den Versionen
[unmarkierte Version] | [unmarkierte Version] |
(→Namenskonventionen für Templates) |
(→Namenskonventionen für Value-Sets) |
||
Zeile 160: | Zeile 160: | ||
'''[Präfix]_[ValueSetsName]_VS'''<br/> | '''[Präfix]_[ValueSetsName]_VS'''<br/> | ||
− | "Displayname" und "Name" des Value-Sets sind identisch. <br> | + | "Displayname" und "Name" des Value-Sets sind identisch. <br> Beispiel: |
:*Name: eimpf_Abrechenbarkeit_VS | :*Name: eimpf_Abrechenbarkeit_VS | ||
:*Wiedergabename: eimpf_Abrechenbarkeit_VS | :*Wiedergabename: eimpf_Abrechenbarkeit_VS |
Version vom 4. November 2019, 12:10 Uhr
Inhaltsverzeichnis
1 Zusammenfassung
Dieses Dokument enthält Richtlinien zur Erstellung von CDA-Implementierungsleitfäden mit Art-Decor® und der Dokumentation mit 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 Repositorien, Qualitätssicherung und den Support der Tools.
2 Einleitung
2.1 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. Sie definiert Regeln und Strukturen, die von allen Anwendern dieser Werkzeuge eingehalten werden müssen.
2.2 Weiterentwicklung des Dokuments
Dieses Dokument enthält die aktuellsten Fragen und Entscheidungen bezüglich der Arbeit mit Art-Decor und Mediawiki in Österreich und wird laufend angepasst.
Anfragen hinsichtlich der Änderung oder Erweiterung dieses Dokuments stellen Sie bitte an cda@elga.gv.at.
3 Richtlinien
3.1 Sprache
ELGA Implementierungsleitfäden werden in deutscher Sprache verfasst. Dazu gehören textuelle Beschreibungen im Wiki, Art-Decor-Templates und Datasets.
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. Nur Template-Namen im CDA-Body werden auf deutsch vergeben, da diese den in den Arbeitsgruppen abgestimmten Titel der Sektion tragen sollen.
3.2 OIDs
Im Zusammenhang mit der Verwendung von OIDs 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.
3.2.1 OIDs für Implementierungsleitfäden
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, kann 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
3.2.2 Art-Decor Root OIDs
Als neuer Root-Knoten für Art-Decor wird 1.2.40.0.34.6.0 (eHealth-Austria/services) verwendet:
- 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).
- 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).
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.
3.2.3 Root OIDs für Templates
Die OIDs 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 nächste freie OID für Templates und Value-Sets muss über die Art-Decor Governance Group, unter "List of Artefacts under this Governance Group" ermittelt werden.
3.3 Namenskonventionen
3.3.1 Versions-Label
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.
- Beispiele:
- 2019
- 2019.01
- 2019.01.16
3.3.2 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. „elgaimpf‑UpdateImmunisierungsstatus“.
3.3.3 Namenskonventionen für Templates
Die Namen von Templates werden wie folgt angegeben:
[Präfix]_[Template-Typ]_[ElementName]
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:
- Template einer unkodierten Sektion im Repository AT-CDA-BBR:
- Name: "atcdabrr_section_FruehereErkrankungUnkodiert"
- DisplayName: "Frühere Erkrankungen - unkodiert"
- Name: "atcdabrr_section_FruehereErkrankungUnkodiert"
- Template einer kodierten Sektion im ELGA e-Impfpass Repository:
- Name: "eimpf_section_ImpfrelevanteErkrankungenKodiert"
- DisplayName: "Impfrelevante Erkrankungen - kodiert"
- Name: "eimpf_section_ImpfrelevanteErkrankungenKodiert"
- Document Level Template im ELGA e-Impfpass Repository:
- Name: "eimpf_document_KompletterImmunisierungsstatus"
- DisplayName: "Kompletter Immunisierungsstatus"
- Name: "eimpf_document_KompletterImmunisierungsstatus"
- Entry im AT-CDA-BBR:
- Name: "atcdabbr_entry_Immunizations"
- DisplayName: "Immunization Entry"
- Name: "atcdabbr_entry_Immunizations"
- Template aus der Kategorie "Other" im AT-CDA-BBR:
- Name: atcdabbr_other_TextElementWithReferenceToNarrativeText
- DisplayName: Narrative Text Reference
- Name: atcdabbr_other_TextElementWithReferenceToNarrativeText
3.3.4 Namenskonventionen für Value-Sets
Die Namen von Value-Sets werden wie folgt angegeben:
[Präfix]_[ValueSetsName]_VS
"Displayname" und "Name" des Value-Sets sind identisch.
Beispiel:
- Name: eimpf_Abrechenbarkeit_VS
- Wiedergabename: eimpf_Abrechenbarkeit_VS
3.4 Versionierung
3.4.1 Versionierung von 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.
3.4.2 Versionierung von Value-Sets
OIDs für Value-Sets bleiben für alle Versionen gleich, werden aber durch das Gültigkeitsdatum effectiveDate unterschieden werden (Version ab....). Darüber hinaus kann eine Value-Set ein offizielles Freigabedatum tragen.
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.
- Beispiel:
- Versionlabel: YYYYMM.Korrekturnummer(-beta)
- Korrekturnummer ist optional. Bei Änderungen innerhalb eines Monats wird eine Korrekturnummer angehängt.
Hinweis: "Beta" wird nur bei Value Sets verwendet, die noch in Arbeit sind. Sobald die Version gültig ist, wird das beta entfernt.
3.5 Art-Decor
3.5.1 Repositories
3.5.1.1 Art-Decor BBR
Das ELGA Building Block Repository (BBR) enthält alle Basis-Templates:
Die im ELGA BBR befindlichen Templates dürfen nur von einem eingeschränkten Benutzerkreis bearbeitet werden.
3.5.2 Governance Groups
TODO
3.5.2.1 Artefact status in repositories
In a repository, artefacts shall be initially created in the status 'draft'. When finished, reviewed and endorsed, an artefact’s status can be changed in the repository according the rules of the responsible governance group (see Art-Decor.org/Template Editor for the Art-Decor default state/event diagram). Chapter #Repositories contains the description of the detailed process and responsibilities.
3.5.3 Documentation
3.5.3.1 Templates
TODO
3.5.3.2 Standard references
TODO
3.5.4 Datasets
3.5.4.1 Language
See chapter #Languages for language guidelines.
3.5.4.2 Optionality
TODO
3.5.4.3 Official ELGA implementation guides
3.5.4.4 Minimum Description
TODO
3.6 Mediawiki
3.6.1 Structure of an Implementation Guide
To ensure a consistent approach and display of the implementation guide, the following (minimum, German) structure is recommended:
TODO
3.6.2 Schematic View of Templates
TODO
3.6.3 Revisions
TODO
3.7 Releases
3.7.1 Art-Decor
TODO
3.7.2 Wiki
3.7.2.1 Check before finalizing
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 Art-Decor Support.
- Perform search for:
- "/dynamic"
- "/static"
- "Cannot find"
- ...
Afterwards: Create a revision according to Wiki revisions.
4 Governance
4.1 Responsibilities
4.1.1 Support for Art-Decor
TODO
4.1.2 Governance Groups
TODO
4.1.3 Repositories
TODO
4.1.4 Wiki
TODO
4.2 Art-Decor artifact states
The following state/event diagram shows the default states and possbile transitions for an artifact within Art-Decor:
[Abbildung 1] Default state diagram for Art-Decor artefacts
Each Governance Group may decide to avoid some of these states. It is not recommended to add new states by a Governance Group.
[Tabelle 1] Art-Decor state machine
4.3 Quality Assurance & Review
4.3.1 Art-Decor Repository
TODO
4.3.2 Implementation Guides
TODO
4.3.3 Official ELGA implementation guides
TODO
5 Annex
5.1 Links
5.2 List of Figures
- ↑ Default state diagram for Art-Decor artefacts
5.3 List of Tables
- ↑ Art-Decor state machine
5.4 List of future definitions
TODO