ILF Diskussion:Allgemeiner Implementierungsleitfaden (Version 3)

1 Bekannte Probleme

1.1 Arznei Entry

Betrifft v.a. die e-Medikation, aber auch andere Leitfäden, die mit dem Arznei Entry arbeiten: Entlassungsbrief, Ambulanzbefund, Telemonitoring-Episodenbericht. Infusionen, die aus mehreren Bestandteilen bestehen, können nicht adäquat abgebildet werden. (ELGA-914)

2 Diskussion

Zu diesen Punkten würden die Autoren der Spezifikation gerne die Meinung der Ballot-Teilnehmer und potentiellen Implementierer erfahren. Diskussionsbeiträge bitte an office@hl7.at senden.

Derzeit keine

3 Beendete Diskussionen

3.1 Übersichtstabelle der CDA Strukturen des Headers

In der Übersichtstabelle sollte die Optionalität jeweils für ELGA und für eHealth angegeben werden. ZB Authorization ist für ELGA NP, für eHealth [O] --> Erledigt

3.2 XDS-Mapping von clinicalDocument.code und translation

Beim Mapping von clinicalDocument.code und clinicalDocument.code.translation auf XDS.documentClass und XDS.documentType: Ist es besser clinicalDocument.code auf XDS.documentClass zu mappen oder auf XDS.documentType (und vice versa)? --> Erledigt: clinicalDocument.code ↔ XDS.typeCode; clinicalDocument.code.translation ↔ XDS.classCode

3.3 Mapping von XDS.formatCode

3.3.1 Welche TemplateId?

TemplateIDs: Sollte man die Extension von FormatCode besser zur templateID[2] (die für das Leitfaden-PDF) hängen? --> Erledigt. Eigenes Schema Element

3.3.2 Statt TemplateID lieber neue Schema-Elemente?

Anstatt XDS.formatCode und Terminologie-Datum an TemplateID Elemente zu binden, könnte man auch Schema-Erweiterungen definieren, ähnlich wie bei hl7at:practiceSettingCode Wäre das nicht eleganter? --> Erledigt. Eigenes Schema Element

3.4 Erklärung warum das [R2] nicht mehr existiert

Im Leitfaden sollte für Implementierter, die die vorhergehenden Leitfäden kennen, erklärt werden das das [R2] entfallen ist weil Art-Decor dies nicht unterstützt und durch [R] 0..1 ersetzt wurde. --> Erledigt. Hinweis in der Legende der Konformitätskriterien, dass die Notation R 0.. der alten R2 entspricht. Begründung nicht notwendig

3.5 Verwendung von ungenauen Datums-Angaben

Es soll einen Datentyp geben, der neben YYYYMMDD und YYYYMMDDhhmmss[+/-]HHMM auch YYYYMM und YYYY zulässt. Sinnvoll zur strukturierten Information von lange zurückliegenden Episoden ("Masern im Juli 1997" und "OS-Fraktur 1966"). Verwendung zB in problem entry --> Erledigt.