ILF:ENDS 2: Unterschied zwischen den Versionen

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][unmarkierte Version]
(→‎Implementierungsleitfaden Export-Normdatensatz 2)
(→‎IHE XDM)
Zeile 60: Zeile 60:
 
[[Datei:Verzeichnisstruktur.png|miniatur|Vorgeschriebene Verzeichnisstruktur laut IHE-ITI Vol2b, Transaction ITI-32<ref name="ITI_Vol2b">[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf], IHE-ITI Vol2b]</ref>]]
 
[[Datei:Verzeichnisstruktur.png|miniatur|Vorgeschriebene Verzeichnisstruktur laut IHE-ITI Vol2b, Transaction ITI-32<ref name="ITI_Vol2b">[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol2b.pdf], IHE-ITI Vol2b]</ref>]]
  
−
Für den export der beschlossenen Normdaten wird als Basis das IHE XDM (Cross-Enterprise Document Media Interchange) Profile herangezogen. Dieses Profile ist in den IHE Technical Frameworks IT-Infrastructur definiert (IHE-ITI Vol1<ref name="ITI_Vol1">[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf], IHE-ITI Vol1</ref> und IHE-ITI Vol2b<ref name="ITI_Vol2b"/>). Das XDM Profil definiert wie Daten abseites einer technischen Infrastruktur geteilt werden können, i.e. es definiert den Austausch von Daten über Datenträger (z.B. USB-Speicherstick, CD/DVD). Hierzu wird in XDM eine Verzeichnisstruktur vorgegeben. Betreffend der verspeicherten Fileformate ist das Profil jedoch agnostisch. Das bedeutet, dass mithilfe von XDM nicht nur CDA (XML) Dokumente übertragen werden können, sondern auch die anderen geforderten Dokumentenklassen wie z.B.: iCalander, .json. Anzumerken ist, dass IHE XDM für die Datei- und Ordnerbezeichnungen den ISO9660 Standard vorschreibt. Dies bedeutet, dass für die Benennung die "8.3" Konfenzion zu verwenden ist. Im Zuge dieses Leitfadens und basierend auf der Anforderung, dass .json Dateien verwendet werden können, wird gegen bewusst gegen die ISO9660 und somit IHE XDM verstoßen (es gibt keine Dateiextension für .json mit nur 3 Zeichen).
+
Für den Export der beschlossenen Normdaten wird als Basis das IHE XDM (Cross-Enterprise Document Media Interchange) Profile herangezogen. Dieses Profile ist in den IHE Technical Frameworks IT-Infrastructur definiert (IHE-ITI Vol1<ref name="ITI_Vol1">[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf], IHE-ITI Vol1</ref> und IHE-ITI Vol2b<ref name="ITI_Vol2b"/>). Das XDM Profil definiert wie Daten abseits einer technischen Infrastruktur geteilt werden können, es definiert also den Austausch von Daten über Datenträger (z.B. USB-Speicherstick, CD/DVD). Hierzu wird in XDM eine Verzeichnisstruktur vorgegeben. Betreffend der verspeicherten Fileformate ist das Profil jedoch agnostisch. Das bedeutet, dass mithilfe von XDM nicht nur CDA (XML) Dokumente übertragen werden können, sondern auch die anderen geforderten Dokumentenklassen wie z.B.: iCalander, .json. Anzumerken ist, dass IHE XDM für die Datei- und Ordnerbezeichnungen den ISO9660 Standard vorschreibt. Dies bedeutet, dass für die Benennung die "8.3" Konvention zu verwenden ist. Im Zuge dieses Leitfadens und basierend auf der Anforderung, dass .json Dateien verwendet werden können, wird gegen bewusst gegen die ISO9660 und somit IHE XDM verstoßen (es gibt keine Dateiextension für .json mit nur 3 Zeichen).
  
  
Zeile 66: Zeile 66:
 
==== README.TXT ====
 
==== README.TXT ====
 
Laut IHE Profile XDM ist zwingend eine README.TXT Datei in der Orderstruktur zu führen. Nach <ref name="ITI_Vol2b"/> MUSS diese Datei folgende Informationen beinhalten:
 
Laut IHE Profile XDM ist zwingend eine README.TXT Datei in der Orderstruktur zu führen. Nach <ref name="ITI_Vol2b"/> MUSS diese Datei folgende Informationen beinhalten:
−
* Kontaktinformtionen über das dokumenterstellende Institut
+
* Kontaktinformationen über das dokumenterstellende Institut
 
* Informationen über das Softwareprodukt welches an der Erstellung beteiligt war
 
* Informationen über das Softwareprodukt welches an der Erstellung beteiligt war
 
** Name und Version
 
** Name und Version
−
** Kontaktinformtionen zum Softwareprodukthersteller
+
** Kontaktinformationen zum Softwareprodukthersteller
 
* Information über die Struktur des XDM Datenset
 
* Information über die Struktur des XDM Datenset
  
−
Es ist anzumerken, dass das README.TXT File von der tranportierten klinischen Information unabhängig ist. Somit kann die gleiche README.TXT in verschiedenen Exporten vorkommen.
+
Es ist anzumerken, dass das README.TXT File von der transportierten klinischen Information unabhängig ist. Somit kann die gleiche README.TXT in verschiedenen Exporten vorkommen.
  
 
<pre>Erzeugt von:
 
<pre>Erzeugt von:

Version vom 15. Oktober 2019, 06:16 Uhr

ELGA mitClaim.png
ELGA GmbH
Leitfaden Export-Normdatensatz®
im ELGA CDA® R2 Laborbefund
Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.10.1]
30. August 2019
1.00
draft




Under construction icon-blue.png Diese Seite oder Abschnitt ist derzeit ein Entwurf und kann sich noch ändern.
This article was last edited by Krondraf (talk| contribs) 5 years ago.
This article or section is in the middle of an expansion or major restructuring.
This article was last edited by Krondraf (talk| contribs) 5 years ago.


1 Implementierungsleitfaden Export-Normdatensatz 2

--Frohner (Diskussion) 12:55, 2. Sep. 2019 (UTC) IHE XDM Attribut patientId: Laut ELGA "Patienten-ID in der XDS Affinity Domain" ist R. Gegen dieses Konformanzkriterium könnte verstoßen werden, wenn die ASW (welche den Export triggert) nicht an einer XDS Affinity Domain angeschlossen ist. Von Seiten der IHE wäre dies kein Problem. Dort wird dieses Attribut als R2 definiert. ACHTUNG: In diesem Kontext: Die homeCommunityId (ID der Affinity Domaine) wird ebenfalls benötigt (u.a. auch als Teil der referencedIdList).

1.1 IHE XDM

Vorgeschriebene Verzeichnisstruktur laut IHE-ITI Vol2b, Transaction ITI-32[1]

Für den Export der beschlossenen Normdaten wird als Basis das IHE XDM (Cross-Enterprise Document Media Interchange) Profile herangezogen. Dieses Profile ist in den IHE Technical Frameworks IT-Infrastructur definiert (IHE-ITI Vol1[2] und IHE-ITI Vol2b[1]). Das XDM Profil definiert wie Daten abseits einer technischen Infrastruktur geteilt werden können, es definiert also den Austausch von Daten über Datenträger (z.B. USB-Speicherstick, CD/DVD). Hierzu wird in XDM eine Verzeichnisstruktur vorgegeben. Betreffend der verspeicherten Fileformate ist das Profil jedoch agnostisch. Das bedeutet, dass mithilfe von XDM nicht nur CDA (XML) Dokumente übertragen werden können, sondern auch die anderen geforderten Dokumentenklassen wie z.B.: iCalander, .json. Anzumerken ist, dass IHE XDM für die Datei- und Ordnerbezeichnungen den ISO9660 Standard vorschreibt. Dies bedeutet, dass für die Benennung die "8.3" Konvention zu verwenden ist. Im Zuge dieses Leitfadens und basierend auf der Anforderung, dass .json Dateien verwendet werden können, wird gegen bewusst gegen die ISO9660 und somit IHE XDM verstoßen (es gibt keine Dateiextension für .json mit nur 3 Zeichen).


1.1.1 README.TXT

Laut IHE Profile XDM ist zwingend eine README.TXT Datei in der Orderstruktur zu führen. Nach [1] MUSS diese Datei folgende Informationen beinhalten:

  • Kontaktinformationen über das dokumenterstellende Institut
  • Informationen über das Softwareprodukt welches an der Erstellung beteiligt war
    • Name und Version
    • Kontaktinformationen zum Softwareprodukthersteller
  • Information über die Struktur des XDM Datenset

Es ist anzumerken, dass das README.TXT File von der transportierten klinischen Information unabhängig ist. Somit kann die gleiche README.TXT in verschiedenen Exporten vorkommen. 

Erzeugt von:
Amadeus Spital
Mozartgasse 1-7
5350 St.Wolfgang, Salzburg

Für Unterstützung:
IT Amadeus Spital
+43 6138 3453446 122

Erzeugt durch xy GmbH - Arztsoftware, Version 8.123, www.xy-arztsoftware.at

Der IHE_XDM Ordner enhält für jeden Patienten/jede Patientin einen eigenen Unterordner. Der Name des Unterordners ist die PatientenID aus dem Quellsystem.

Zur Darstellung der Inhalte können folgende Softwareprodukte genutzt werden:
- Für CDA Dokumente (.XML): Browser und ELGA-Referenzstylesheet, bzw. ENDS2-Importtool
- Für iCalender Dateien (.ICS): Kalenderapplikation, bzw. ENDS2-Importtool
- Für JSON Dateien (.JSON): Texteditor, bzw. ENDS2-Importtool

1.1.2 INDEX.HTM

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html>

<head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <title>XDM - klinische Dokumente für Maximilian TEST0000000036</title>
</head>

<body>
    <h1>XDM Dokumente:</h1>
    <p>
        Erzeugt von:<br/> 
	Amadeus Spital - Urologische Ambulanz<br/> 
	Mozartgasse 1-7<br/> 
	5350 St. Wolfgang
    </p>
    <p>
        Name des Patienten: Maximilian TEST0000000036<br/> 
	Pat-ID: 36<br/> 
	Geschlecht: M<br/> 
	Geburtsdatum: 26.08.2001<br/> 
	STR0000000036<br/> 
	0036 WIEN0000000036
    </p>
    
    <h2>Dokumente:</h2>
    <p>
	<a href="IHE_XDM\00000036\00000036.XML">CDA Dokument</a><br/>
	<a href="IHE_XDM\00000036\TERMIN001.ICS">Termin Verbandswechsel</a>
    </p>
</body>

</html>

1.1.3 METADATA.XML

Das Metadata.xml enthält neben den Identifiern für die/das Dokument(en) und der/des Patienten die notwendigen Context-Informationen. Dieses XML File basiert auf dem ebXML Standard und im folgenden werden die notwendigen XML-Strukturen kurz vorgestellt.

  • External Identifier
  • Name
  • Classification
  • Slot
1.1.3.1 External Identifier

Das "External Identifier" Element hat folgende 4 XML-Attribute welche zu befüllen sind:

  • registryObject: UUID des zugehörigen Registry Packages (Ausprägungen: SubmissionSet, Folder, bzw. Document)
  • identificationScheme: UUID des laut IHE ITI Vol3 definerten Metadaten Vokabular (siehe Kapitel 4.2.5 Metadata Vocabulary im ITI-TF Vol3[3])
  • value: Codierter Wert - Hinweise bezüglich der Codierung ist aus der jeweiligen Spezifikation ersichtlich.
  • id: global eindeutiger Identifier des "External Identifier"-Elements

Als Child-Element ist ein "Name"-Element zu führen, welches die Klartextdarstellung des "identificationSchema" laut IHE ITI-TF Vol3 Vokabulars enthält.

1.1.3.2 Name
1.1.3.3 Classification
1.1.3.4 Slot
1.1.3.5 iCalendar
BEGIN:VCALENDAR
VERSION:2.0
PRODID:http://www.example.com/calendarapplication/
METHOD:PUBLISH
BEGIN:VEVENT
UID:461092315540@example.com
ORGANIZER;CN="Dr. Max Mustermann":MAILTO:max.mustermann@example.com
LOCATION:Praxis Dr. Mustermann, Raum 01
SUMMARY:Verbandswechsel
DESCRIPTION:Verbandswechsel Hr. Tester
CLASS:PUBLIC
DTSTART:20190910T090000Z
DTEND:20190910T091500Z
DTSTAMP:20190903T130000Z
END:VEVENT
END:VCALENDAR

2 ArtDecor Test

Id1.2.40.0.34.6.0.11.2.27
ref
at-cda-bbr-
Gültigkeit2021‑02‑19 11:43:57
Andere Versionen mit dieser Id:
  • Kblank.png atcdabbr_section_BisherigeMassnahmenUnkodiert vom 2019‑04‑02 15:48:15
StatusKgreen.png AktivVersions-Label1.0.0+20210219
Nameatcdabbr_section_BisherigeMassnahmenUnkodiertBezeichnungBisherige Maßnahmen - unkodiert
BeschreibungEnthält relevante Maßnahmen, die schon vor dem Aufenthalt durchgeführt wurden
KontextElternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.27
KlassifikationCDA Section level template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.6.0.11.3.19ContainmentKgreen.png Eingebettetes Objekt Entry (1.0.2+20230717)DYNAMIC
BeziehungVersion: Template 1.2.40.0.34.6.0.11.2.27 Bisherige Maßnahmen - unkodiert (2019‑04‑02 15:48:15)
ref
at-cda-bbr-
Beispiel
Strukturbeispiel
<section>
  <templateId root="1.2.40.0.34.6.0.11.2.27"/>  <!-- Code der Sektion -->
  <code code="67803-7" displayName="History of Procedures - Reported" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->
  <title> Bisherige Maßnahmen </title>  <!-- Textbereich der Sektion -->
  <text> ... Lesbarer Textbereich ... </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(atc...ert)
Treetree.png@classCode
cs0 … 1FDOCSECT
Treetree.png@moodCode
cs0 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(atc...ert)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.2.27
Treetree.pnghl7:id
II0 … 1Eindeutige ID der Sektion(atc...ert)
wo [not(@nullFlavor)]
Treetree.pnghl7:code
CE1 … 1M(atc...ert)
Treeblank.pngTreetree.png@code
CONF1 … 1F67803-7
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1M(atc...ert)
 CONF
Elementinhalt muss "Bisherige Maßnahmen" sein
Treetree.pnghl7:text
SD.TEXT1 … 1MInformation für den menschlichen Leser.
(atc...ert)
Treetree.pnghl7:entry
0 … *RBeinhaltet 1.2.40.0.34.6.0.11.3.19 Eingebettetes Objekt Entry (DYNAMIC)(atc...ert)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FDRIV
 DRIV (is derived from) deutet an, dass der section.text aus den Level 3 Entries gerendert wurde und keinen medizinisch relevanten Inhalt enthält, der nicht aus den Entries stammt.
Treeblank.pngTreetree.png@context​Conduction​Ind
cs0 … 1Ftrue
  1. ↑ 1,0 1,1 1,2 [1], IHE-ITI Vol2b]
  2. ↑ [2], IHE-ITI Vol1
  3. ↑ [3], ITI-TF Vol3
Abgerufen von „http://wiki.hl7.at/index.php?title=ILF:ENDS_2&oldid=110679“