597
Bearbeitungen
Änderungen
→Art-Decor Projekt
{{#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>
<!--
{{Infobox Dokument
|Title = Best Practices and Governance for für die CDA-Leitfadenerstellung mit Art-Decorund Mediawiki
|Short = Art-Decor Governance
|Type = Governance
{{Versionbox Begin}}
{{VersionboxEntry | Version = 0.1 | Date = 0215.021.2017 2019 | Status = Draft | History=Initial Draft for review on 03.02.2017 Inititalversion beim Workshop mit Tony Schaller (JGNCH)}}{{VersionboxEntry | Version = 0.2 | Date = 0307.0211.2017 2019| Status = Draft | History=Inputs from Telco on 03.02.2017: State Diagram for artefacts (JGN)Überarbeitung und Einarbeitung der Erkenntnisse nach Erstellung des CDA-Leitfadens e-Impfpass}}{{VersionboxEntry | Version = 0.3 1 | Date = 1514.0212.2017 2021| Status = Draft | History=Include comments from review (JBL, OEG, JGN, KHE, TSC)}}{{VersionboxEntry | Version = 0.4 | Date = 20.02.2017 | Status = Draft Final| History=finalize document for audit within HL7 & IHE Switzerland (JGN)}}{{VersionboxEntry | Version = 0.5 | Date = 28.02.2017 | Status = Draft | History=Include comments from review (Tony Schaller, IHE, HL7) (JGN, TSC)Überarbeitung}}{{VersionboxEntry | Version = 1.0 | Date = 21.03.2017 | Status = Final | DocumentLink=| History=First release}}{{VersionboxEntry | Version = 1.1 | Date = 073.055.2018 2023| Status = Draft Final| History=Changes according lessons learned from CDA-CH V2, LREP, VACD, EMED.<ul><li>[[#Structure of an Implementation Guide | Specification: chapter structure]]</li><li>[[#Support for Art-Decor | Involvement of Art-Decor Support]]</li><li>[[#Revisions | PDF Generation with Prince and Github Link]]</li><li>[[#Art-Decor artifact states | Status Pre-publication Review for art-decor artefacts]]</li><li>[[#Revisions | Art-Decor release notes]]</li></ul>Überarbeitung Kapitel Value Sets}}
{{Versionbox End}}
-->
|-
! Status
| DraftFinal
|-
! Document version
| 1.1
|-
! Authors
|
* Johannes Gnägi Andrea Klostermann (eHealth SuisseELGA GmbH)* Sang-Il Kim Gabriel Kleinoscheg (eHealth SuisseELGA GmbH)* Kai Heitmann Stefan Sabutsch (Heitmann Consulting and Services , ART-DECOR Open ToolsELGA GmbH)* Jürg Bleuer Nikola Tanjga (eHealth SuisseELGA GmbH)* Tony Schaller (IHE Suisse)* Oliver Egger (HL7 Benutzergruppe Schweiz)|-! Stakeholder Contributor(s)| HL7 Schweiz, IHE Suisse, Heitmann Consulting and Services
|}
-->
= Zusammenfassung 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 Dokumentation 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 Österreichund 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.
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= Introduction === Purpose ==TODOHilfe: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= Scope ==TODOImplementierungsleitf%C3%A4den Übersicht der CDA Implementierungsleitfäden].
== Process of developing =Inhalt===TODODer Inhalt eines Implementierungsleitfadens besteht üblicherweise aus den Kapiteln:
=== Namenskonventionen für Templates ==Datasets =Die Namen Verwendung von Templates werden wie folgt angegeben:'''[Präfix]_[TemplateArt-Decor-Typ]_[ElementName]'''<br/>Wobei folgendes gilt:; [Präfix]: Als Präfix dient Datasets wird für neue Projekte empfohlen. Diese bilden die funktionalen Anforderungen an das Projektkürzel Projekt ab und sind Diskussionsgrundlage bei Fachexpertengesprächen (Name des Repositorieserfordern kein technisches Hintergrundwissen) in CamelCase-Notation, z.B. "atcdabrr"; [Template-Typ]: Der Template-Typ kann enthalten::* "document":* "header":* "section":* "entry":* "other" ; [ElementName]: Bezeichnung des Templates in CamelCase-Notation. Als Trenner fungieren Unterstriche "_".
===Versionierung von Value-Sets=Name ==Bei Es gibt keine speziellen Namenskonoventionen, der Aktualisierung eines Value Sets muss das effectiveDate auf das aktuelle Datum (Gültig ab-Datum) geändert werden.'''Name''' ist jedoch '''anzugeben'''!
Die Zuordnung von Dataset-Elementen und erstellten Templates unter "BetaTemplate" → "Template-Mapping" wird nur bei Value Sets verwendet'''empfohlen, die noch 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 Arbeit sindder Template-Beschreibung zusammengefasst, sowie direkt beim assoziierten CDA-Element bzw. Attribut des Templates ersichtlich. Sobald Dies dient der Kontrolle (auch für die Version gültig istExperten-/Arbeitsgruppe), wird das beta entferntdass alle erforderlichen Dataset-Elemente in den Templates modelliert wurden.
== Art-Decor =Templates ==== Repositories ======= Art-Decor BBR====Das ELGA Building Block Repository Ein Leitfadenprojekt besteht aus '''einem oder mehreren Document Level Templates (DLT)''' (BBRjedes DLT entspricht dabei einem Dokumententyp) enthält alle Basis, 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-Templatesbeinhalten, 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.
==== Artefact status in repositories ==Vorbedingungen für Änderungen bestehender Templates==In a repositoryBevor ein bestehendes Template geändert wird (Erstellung einer neuen Version, artefacts shall be initially created in the status 'draft'. When finishedwelche automatisch von allen dynamisch referenzierenden Templates verwendet wird), reviewed and endorsedist zu überprüfen, an artefact’s status can be changed in the repository according the rules of the responsible governance group (see [https://art-decorwie sich diese Änderung auf andere Leitfäden auswirkt bzw.org/mediawiki/indexob diese gewünscht ist.php?title=ART_Template_Editor Art-Decor.org/Template Editor] for the Art-Decor default state/event diagram). Chapter [[#Repositories]] contains the description of the detailed process and responsibilitiesIn 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.
=== Documentation =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 ====TODOerleichtert wird.
==OID = Namenskonventionen für Value=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-Sets ===Level Template:'''.3.''' Entry-Level Template:'''.9.''' other CDA Fragment Template
== Mediawiki Version & Metadaten ===== Structure of an Implementation Guide ===To ensure a consistent approach and display of the implementation guide, the following (minimum, German) structure is ''recommended'':
''Beispiel''Afterwards:''' Create a revision according to [[#Revisions | Wiki revisions]].
<code><nowiki>https://art-decor.org/temple/views/temple.html?id= Governance </nowiki>2.16.756.5.30.1.1.10.2.63&effectiveDate=2020-06-26T00:00:00&prefix=cdachvacd-&language= Responsibilities ===== Support for Artde-Decor ==DE&mode=TODOreadonly</code>
==Inhalt = Governance Groups ===TODO
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 artifact states 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 erlaubtThe following state| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R" isMandatory="true"></event diagram shows the default states and possbile transitions for an artifact within Artcode>|-Decor| colspan="1" |0..0 NP| colspan="1" |nicht erlaubt| colspan="1" |<code><element name="hl7:id" 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>
<ref groupcode></element></code>|-| colspan="Tabelle1"|1..1 R| colspan="1" |erlaubt| colspan="1" |<code>Art<element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="1" conformance="R"></code>|-Decor state machine|1..* R|erlaubt|<code><element name="hl7:id" datatype="II" minimumMultiplicity="1" maximumMultiplicity="*" conformance="R"></refcode> ''Art|-Decor state machine''{| classcolspan="1" |0..1 R| colspan="hl7table1"|nicht erlaubt! width| colspan="80px1" | Status !! Action !! Trigger <code><element name="hl7:id[not(@nullFlavor)]" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformance="R"></ Description !! Example for CDA-CH !! Responsibilitycode>
|-
| [[File:Kyellowcolspan="1" |0..png* R|16px]] draftcolspan="1" |nicht erlaubt| activatecolspan="1" | Artefact is finished and it is considered as final <code><element name="hl7:id[not(no review needed@nullFlavor).| ''n]" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformance="R"></a for CDA-CH as review necessary.''| Developercode>
|-
| colspan="1" |0..1 O| considercolspan="1" |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 ownercolspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1"></team of the repository.code>| ''final draft for a CDA-CH V2 template ready to review| colspan="1" |0..''* O| Developer (info to the Reviewer) colspan="1" |erlaubt| colspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*"></code>
|-
| colspan="1" |0..1 C| cancelcolspan="1" | If an artefact is not further developed, it is cancelled.Abhängig vom Kontext| ''any developed draft template not to be used anymore.''colspan="1" | Developer<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="1" conformace="C"></code>
|-
| [[File:Korangecolspan="1" |0..png* C| colspan="1" |16px]] pendingAbhängig vom Kontext| activatecolspan="1" |<code><element name="hl7:id" datatype="II" minimumMultiplicity="0" maximumMultiplicity="*" conformace="C"></code>| Upon decision of the review team.}{| ''CDA-CH V2 template has been reviewed within HL7 Switzerland and was considered to be ready for release.''class="wikitable"! colspan="2" | Review team of the repository. Für Attribute
|-
|-
| [[File:Kpurple0.png|16px]] 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.''0 NP| Developer<attribute name="root" datatype="uid" prohibited="true"/>
|-
| [[File:Kgreencolspan="1" |1.png|16px]] active| review| Maintenance or update of a project/repository.1 R| ''Review CDA-CH template to consider it for CDA-CH v2.''colspan="1" | Repository <attribute name="root" datatype="uid"/ Project owner>
|-
| colspan="1" | retire| In case of a new version, the old version is retired in order to have only one valid version of an artefact0..1 O| ''A CDA-CH template is not used anymore or replaced by another one.''colspan="1" | Repository <attribute name="root" datatype="uid" isOptional="true"/ Project owner>
|-
| [[File:Korangecolspan="1" |1..png|16px]] pre-publication review 1 F| reactivatecolspan="1" | If updated and considered as final by the responsible person, the artefact is re-activated<attribute name="root" datatype="uid" value="1.3.6.1.4.1.19376.1.3.| ''template is reviewed within HL7 Switzerland and considered to be ready for release2.''| Repository 1"/ Project owner>
|-
| colspan="1" | retire0..1 F| colspan="1" | ''A CDA-CH template is not used anymore or replaced by another one<attribute name="root" datatype="uid" value="1.3.6.1.''| 4.1.19376.1.3.2.1" isOptional="true"/>
|}
=Value Sets = Quality Assurance 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. {{BeginYellowBox}}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}} == 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 == 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){{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}} == Version & Review Metadaten ==Versionierung: Siehe [https://confluence.elga.gv.at/display/SCCTERM/Versionierung Versionierung]. == 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.{{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}} = 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 [https://confluence.elga.gv.at/display/SCC/Schematron-Erstellung+und+Bereitstellung 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 [https://www.art-decor.org/mediawiki/index.php?title=ART_Scenario_Editor 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 Repository 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]. * 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 <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 ==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"
=== Implementation Guides =GitLab ==TODOEine 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.
= Annex Anhang ===Links==* [http://art-decor.org/art-decor/home Workspace]* [http://art-decor-open-tools.net Art-Decor Open Tools]* [http://e-health-wiki.ch/index.php/Hauptseite eHealth Wiki]* [http://www.e-health-suisse.ch eHealth Suisse]* [https://groups.google.com/d/forum/swiss-art-decor-implementors Art-Decor Google Group]
==List of FiguresLinks ==<references group="Abbildung"/>==List of Tables==<references group="Tabelle"/>
* [http://art-decor.org/art-decor/home Art-Decor Workspace]* [https://www.art-decor.org/mediawiki/index.php?title=Documentation Art-Decor Dokumentation]* Wiki-Portal von HL7 Austria: [https://wiki.hl7.at/index.php?title=List of future definitions=Willkommen_auf_dem_Wiki-Portal_von_HL7_Austria eHealth Wiki] & [https://wiki.hl7.at/index.php?title=TODOHilfe:Wiki Wiki Hilfe]