Prozess der CDA-Leitfadenerstellung in Art-Decor

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][unmarkierte Version]
(Dataset-Mapping erstellen)
(Testen und Fehlerbehebung)
Zeile 155: Zeile 155:
  
 
==Testen und Fehlerbehebung==
 
==Testen und Fehlerbehebung==
Informationen hierzu unter [https://www.art-decor.org/mediawiki/index.php?title=ART_Project_Editor#Preflighting%20publication%20and%20quality%20checks Preflighting publication and quality checks].
+
Informationen zu den entsprechenden Funktionalitäten des
 +
ART Project Editors finden Sie unter [https://www.art-decor.org/mediawiki/index.php?title=ART_Project_Editor#Preflighting%20publication%20and%20quality%20checks Preflighting publication and quality checks].
  
 +
===Workflow Decor Prüfung===
 
Menü Projekt – Entwicklung:
 
Menü Projekt – Entwicklung:
 
* "Decor prüfen": Prüfung über gesamtes Modell
 
* "Decor prüfen": Prüfung über gesamtes Modell

Version vom 19. November 2019, 10:22 Uhr

Folgende Vorgehensweise wird bei der Erstellung von Leitfäden als Best Practice empfohlen.

Eine Einleitung in Art-Decor finden Sie unter ART Introduction.
Eine Übersicht verfügbarer Anleitungen sind unter ART user manual aufgelistet.

1 Projekt erstellen

Ein neuer CDA-Leitfaden muss in einem eigenen Projektverzeichnis angelegt alle Autoren müssen entsprechend berechtigt werden. Dies muss gegebenenfalls beim Art-Decor-Support beantragt werden.

Informationen zu den Funktionen des Projekt-Editors finden Sie unter ART Project Editor.

2 Datasets erstellen

Die Modellierung der Datasets soll in enger Abstimmung mit Experten der Arbeitsgruppe erfolgen, bereits unter Einbeziehung potentiell zu verwendender Standards (IHE Profile).

Wenn möglich sollen bestehende Dataset-Elemente verwendet werden oder von diesen geerbt werden (Dataset versioning).
Die anzugebenden Inhalte eines Dataset-Elements sind in der Governance festgelegt.

Eine Anleitung zur Modellierung von Datasets finden Sie unter ART Dataset Editor.

3 Szenarios erstellen

Für jede Dokument-Ausprägung muss eine Transaktion erstellt werden. Diese ist für die Generierung von Schematronregeln erforderlich.
Transaktionen stellen einen (Teil-)Satz von Konzepten eines Datasets dar und ergänzen ihn um Kardinalität, Konformität und mögliche Bedingungen, damit die Anforderungen des Anwendungsfalles angemessen widergespiegelt werden. Die Angabe der Element-Konformanz und -Kardinalität ist jedoch für die Erstellung eines Schematrons nicht zwingend erforderlich.
Eine Transaktion muss das entsprechedende Document-Level-Template referenzieren (dies ist die technische Darstellung der Transaktion und der zugrunde liegenden Konzepte).

Die Bezeichnung der Transaktion soll der Governance für die CDA-Leitfadenerstellung mit Art-Decor folgen.
Eine Beschreibung zur Erstellung von Transaktionen finden Sie unter ART Scenario Editor.

4 Referenzen auf andere Projektverzeichnisse setzen

Um bestehende Templates anderer Building Block Repositories referenzieren zu können, müssen die entsprechenden Verzeichnisse dem Projekt hinzugefügt werden

Empfehlung: Dem Projekt Referenzen für ad1bbr-, ad2bbr-, at-cda-bbr-, IHE-PCC- hinzufügen.

Eine Anleitung hierfür finden Sie unter Reference a building block repository.

5 Templates erstellen

Hinsichtlich OID, Namensgebung, Beschreibung und Inhalte neuer Templates sind die Richtlinien der Governance für die CDA-Leitfadenerstellung mit Art-Decor einzuhalten.
Alle Funktionen des Template Editors finden Sie unter ART Temple Editor.
Direkt-Links:

5.1 Hinweise für die Erstellung von Templates

5.1.1 Verwendung von Standards

Im zugrundeliegenden Basis IHE Leitfaden müssen vorgeschriebene Sektionen, Kardinalitäten, Optionalitäten, Terminologien, ServiceEvents usw. ermittelt werden.

  • Wenn möglich, sollen bereits vorhandene Templates verwenden werden (siehe Übernahme bestehender Templates)
  • Wenn ein neues Template erstellt werden muss (siehe Erstellung neuer Templates), müssen verwendete Template-IDs mit den IHE-Vorgaben übereinstimmen
  • Optionalitäten und Reihenfolge der Elemente müssen eigenhalten werden
Hinweis: Wenn ein Template laut IHE "required" ist, aber für die Anwendung in Österreich 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 IHE-Template kann trotzdem verwenden zu können (Interoperabilität!).

5.1.2 Übernahme bestehender Templates

Alle bestehenden Templates werden unter Art-Decor Governance Group aufgelistet.
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.
Je nachdem, ob das Projekt, in dem sich das zu übernehmende Template befindet, im eigenen Projekt verlinkt ist, muss wie folgt vorgegangen werden:

5.1.2.1 Verlinktes Projektverzeichnis

Übernahme eines vorhandenen Templates aus einem verlinktem Projektverzeichnis (siehe ART Temple Editor)

  • Referenzieren des Templates mit Kettensymbol
  • Keine Änderung des Templates möglich!
  • Nur verwenden, wenn es bereits ein passendes ELGA-/e-Health-Template gibt
  • Kopieren und Anpassen eines Templates
  • Ein passendes Template wird via „+“-Symbol als Prototyp angegeben, welches im Anschluss spezifiziert werden muss (neue OID).
5.1.2.2 Nicht verlinktes Projektverzeichnis

Die Übernahme vorhandener Templates aus Projektverzeichnissen, die NICHT verlinkt sind, ist nicht über die GUI möglich, da 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

https://art-decor.org/temple/modules/temple.xquery?id=[OID des Templates]

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.

5.1.3 Änderung bestehender Templates

Solange sich ein Template noch im Status Entwurf befindet, kann es jederzeit bearbeitet werden. Dabei ist folgendes zu beachten:

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

Wichtiger Hinweis: Sollte das Template bereits produktiv sein ("active"), finden Sie Informationen unter Versionierung.

5.1.4 Erstellung neuer Templates

  • Wenn neue Templates erstellt werden, vergibt Art-Decor per Default eine dem Projektverzeichnis untergeordnete OID, welche nach den Vorgaben der Governance geändert werden muss (siehe Metadata).
Hierfür die Governance Seite aufrufen und alle bestehenden Templates auflisten lassen, sodass deren Wiederverwendbarkeit geprüft und Nachschau gehalten werden kann, welche OID als nächstes vergeben werden darf.
  • Neue, allgemeine e-Health-/ELGA-Basistemplates sollen generell im ATCDABBR angelegt werden und sollen so allgemein definiert werden, dass sie für andere Leitfäden verwendbar sind (ohne Value Sets, ohne projektspezifischen Angaben!)(*). Dies stellt sicher, dass alle Projekte Templates aus dem ATCDABBR ableiten und spezifizieren können (Value Sets ergänzen usw.).
Beispiel: Section-Template „Durchgemachte Krankheiten“ im ATCDABBR wird abgeleitet in Section-Template „Impfrelevante Erkrankungen - kodiert“ im e-Impfpass.

(*) Bei fehlender Berechtigung können Basistemplates im Projektverzeichnis erstellt werden und später durch berechtigte Personen in das ATCDABBR verschoben werden.

5.2 Inhalte von Templates

Hinsichtlich folgender Elemente gelten die Vorgaben der Governance.

5.2.1 Templatename

Es gelten die Definitionen der Governance hinsichtlich Templatename

5.2.2 Versions-Label

Es gelten die Definitionen der Governance hinsichtlich Versions-Label

5.2.3 Item-Label

Es gelten die Definitionen der Governance hinsichtlich Item-Label

5.2.4 Beispiel-Snippets

In allen Templates (außer DLTs) werden nur Code-Snippets eingefügt. Snippets zu den Entries werden nur im Entry selbst und nicht im aufrufenden Template angeführt.
Code-Snippets sollen immer zuletzt ergänzt werden, um den Aufwand nach Änderungen im Template gering zu halten.

5.2.5 Metadaten

TODO: Hinweis auf Metadata-Mapping

5.3 Document Level Template erstellen

Für jede Dokumentart (jede Transaktion) muss ein neues Document-Level-Template (DLT) erstellt werden (nach Vorgaben der Governance).
Anmerkung: 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.

5.3.1 Workflow Document Level Template erstellen

  1. Neues DTL anlegen: Angabe Name, Version Label, Display Name laut Governance, dann Template speichern
  2. Anschließend OID entsprechend Governance korrigieren (Template bearbeiten, "#")(nur über GUI möglich, nicht via Temple).
  3. Kopieren der Inhalte eines bestehenden DLT (XML via Temple) und einfügen (effective DATE und OID bleiben erhalten).
  4. Inhaltliche Korrekturen und Anpassungen am Besten in einem XML-Editor durchführen und dann in Temple einfügen.
  5. „Included Templates“ aus DTL-Header mit Kettensymbol zum Projekt hinzufügen

6 Terminologien hinzufügen

Bestehende ValueSets können mit Kettensymbol unter Value-Sets hinzugefügt werden

https://wiki.hl7.at/index.php?title=ART-

7 Dataset-Mapping erstellen

Die Zuordnung von Datensatz-Elementen und erstellten Templates wird empfohlen. 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, dass alle erforderlichen Datensatz-Elemente in den Templates modelliert wurden.

ART Template Associations

8 Testen und Fehlerbehebung

Informationen zu den entsprechenden Funktionalitäten des ART Project Editors finden Sie unter Preflighting publication and quality checks.

8.1 Workflow Decor Prüfung

Menü Projekt – Entwicklung:

  • "Decor prüfen": Prüfung über gesamtes Modell
  • "Optionale Prüfungen konfigurieren": alle Optionen auswählen
  • Schema und Schematron-Prüfung durchführen, eventuelle Fehler werden aufgelistet.

9 Schematron erstellen

Generell gilt:

  • Ein Art-Decor Schematron prüft, ob ein gültiges HL7 CDA Dokument (HL7 v3) vorliegt, während eine XSD-Schemaprüfung, nur prüft ob ein gültiges XML Dokument vorliegt
  • Wenn Geschäftsregeln geprüft werden sollen, müssen zusätzlich notwendige Asserts von Hand eingetragen werden (z.B. Logik: Schwangerschaftsstatus, prüfen ob Impfempfehlung in diesem Jahr noch gültig)
  • Informationen zu den entsprechenden Art-Decor Tool finden Sie unter Live Runtime Compile (LRC).
  • Es wird empfohlen, bereits zu Beginn der Modellierung (z.B. nachdem ein DLT mit Header und noch leerem structuredBody erstellt wurde) eine Kompilierung durchzuführen und dann z.B. nach Ergänzung jeder neuen Sektion zu testen.
  • Art-Decor bietet die Möglichkeit nach korrekter Schematron-Generierung ein Beispieldokument zu prüfen.

9.1 Workflow Schematron erzeugen

Menü Projekt – Entwicklung:

  • "Compiliere Entwicklungsversion":
  • "Optionale Prüfungen konfigurieren": Optionen "Force recompile", "Explicit includes", "Schematron geschlossen" (falls gewünscht)
  • Bei jeder Compilierung entsteht eine neuer Listeneintrag, das zip-File kann gespeichert werden um lokal Beispieldokumente zu validieren -> Achtung, nur die jeweils letzten beiden Versionen bleiben zum Download verfügbar!
  • Nach Publikation soll nur die letzte, gültige Schematron-Version verfügbar sein (alle restliche können entfernt werden).

10 Asserts erstellen

(TODO)

11 Beispielbefunde erstellen und testen

  • Im jedem Document-Level-Template soll nur ein Verweis auf ein vollständiges CDA-Beispiel angeführt werden (z.B. auf HL7.at), damit dies bei Bedarf angepasst werden kann. Änderungen im Template erfordern sonst eine neue Template-ID!
  • Beispielbefunde und sollen immer zuletzt ergänzt werden, um den Aufwand nach Änderungen im Template gering zu halten.

12 Versionierung

12.1 Versionierung von Templates

12.1.1 Major

12.1.2 Minor

12.2 Versionierung von Value Sets

Creating a new version of a value set, based on a previous

13 Publikation

Preflighting publication and quality checks TODO