3.869
Bearbeitungen
Änderungen
keine Bearbeitungszusammenfassung
''(*) 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.''
|}
<br />
= Datasets =
Die Zuordnung von Dataset-Elementen und erstellten Templates unter "Template" → "Template-Mapping" wird '''empfohlen und 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.
= 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.''
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.
== 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 belieben 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"
== 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.
== 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 - Semantic Competence Center - Extranet - ELGA Confluence.
* 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
<code><nowiki>https://art-decor.org/temple/modules/temple.xquery?id=</nowiki>[OID des Templates]</code>
der '''XML-Code jedes Templates''' via '''Temple''' (im Lesemodus) anzeigen und anschließend kopieren. Der kopierte Inhalt kann dann in ein neu erstelltes, leeres Template (mittels "+" und "Create from scratch") 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.
== Inhalt ==
* 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.
** 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!
'''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 <nowiki>https://art-decor.org/mediawiki/index.php?title=DECOR-rules#Mandatory_.2F_Conformance</nowiki>).
{| 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>
'''Achtung,''' bei templateIds sollte zusätzlich ein Prädikat angegeben werden, damit auch das Schematron richtig erstellt wird:
<code><element name="hl7:templateId[@root='1.3.6.1.4.1.19376.1.3.3.2.1']" datatype="II" conformance="NP"></code>
<code> <attribute name="root" value="1.3.6.1.4.1.19376.1.3.3.2.1" datatype="uid" /></code>
<code></element></code>
|-
| colspan="1" |1..1 R
| colspan="1" |erlaubt
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="1" conformance="R"></code>
|-
|1..* R
|erlaubt
|<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R"></code>
|-
| 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
| colspan="1" |Abhängig vom Kontext
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformace="C"></code>
|-
| colspan="1" |0..* C
| colspan="1" |Abhängig vom Kontext
| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformace="C"></code>
|}
{| class="wikitable"
! colspan="2" |Für Attribute
|-
!Vorgaben Allgemeiner Leitfaden
!Umsetzung Art-Decor
|-
|0..0 NP
|<attribute name="root" datatype="uid" prohibited="true"/>
|-
| colspan="1" |1..1 R
| colspan="1" |<attribute name="root" datatype="uid"/>
|-
| colspan="1" |0..1 O
| colspan="1" |<attribute name="root" datatype="uid" isOptional="true"/>
|-
| colspan="1" |1..1 F
| colspan="1" |<attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.2.1"/>
|-
| colspan="1" |0..1 F
| colspan="1" |<attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.2.1" isOptional="true"/>
|}
= Value Sets =
Eine Anleitung zur Verwendung des Value Set Editors ist unter ART Value Set Editor zu finden.
== Name ==
Der '''Name''' und '''Display-Name (Bezeichnung/Wiedergabename)''' eines Value Set 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]:''' Name des Value Sets in Upper-CamelCase-Notation
'''"VS":''' steht immer am Ende jeder Value Set Bezeichnung
"Displayname" und "Name" des Value Sets sollen identisch sein!
Beispiel:
* Name: eimpf_Abrechenbarkeit_VS
* Wiedergabename: eimpf_Abrechenbarkeit_VS
== 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.
== Version & Metadaten ==
Versionierung: Siehe Versionierung - Semantic Competence Center - Extranet - ELGA Confluence
== 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.
= 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.
= 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.
== 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.
== 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.
= Qualitätssicherung =
== 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: formatCode, Versionierungsinfo + Publikationsdatum im Label anpassen
* 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)
== 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
* Revisionsliste 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"
== 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
== Feedback/Wünsche/Anregungen ==
Anfragen hinsichtlich der Änderung oder Erweiterung dieses Dokuments stellen Sie bitte an cda@elga.gv.at.
= Anhang =
== Links ==
* Art-Decor Workspace
* Art-Decor Dokumentation
* Wiki-Portal von HL7 Austria: eHealth Wiki & Wiki Hilfe
<span title="Filterspalte" class="tf-inline-filter"></span>
