ILF Diskussion:Allgemeiner Implementierungsleitfaden (Version 3): Unterschied zwischen den Versionen

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
K
K (Bekannte Fehler)
(14 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
=Bekannte Fehler=
+
=Bekannte Probleme=
==Falsche Verwendung von AddressUse (statt ELGA_TelecomAddressUse)==  
+
==Arznei Entry ==
Einige Templates verlinken statt ELGA_TelecomAddressUse auf: 2.16.840.1.113883.1.11.190 AddressUse
+
Betrifft v.a. die e-Medikation, aber auch andere Leitfäden, die mit dem Arznei Entry arbeiten: Entlassungsbrief, Ambulanzbefund, Telemonitoring-Episodenbericht.
betrifft:
+
Infusionen, die aus mehreren Bestandteilen bestehen, können nicht adäquat abgebildet werden. ([https://jira-neu.elga.gv.at/browse/ELGA-914 ELGA-914])
* 1.2.40.0.34.6.0.11.1.21    Participant Ein-, Ueber-, Zuweisender Arzt
 
* 1.2.40.0.34.6.0.11.1.42    Auftraggeber / Ordering Provider
 
* 1.2.40.0.34.6.0.11.1.28    Participant Weitere Behandler
 
* 1.2.40.0.34.6.0.11.9.13    Participant Body
 
Steht richtig in der Beschreibung, aber das falsche Value Set wird referenziert. Sobald die Value Sets aus Basisleitfäden ins ATCDABBR verschoben wurden, können diese ebenfalls refereziert werden.
 
  
 
=Diskussion=
 
=Diskussion=
 +
''Zu diesen Punkten würden die Autoren der Spezifikation gerne die Meinung der Ballot-Teilnehmer und potentiellen Implementierer erfahren.''
 +
Diskussionsbeiträge bitte an [mailto:office@hl7.at office@hl7.at] senden.
 +
 +
Derzeit keine
 +
 +
=Beendete Diskussionen=
 +
==Übersichtstabelle der CDA Strukturen des Headers==
 +
In der [[ILF:Allgemeiner_Implementierungsleitfaden_2020#.C3.9Cbersichtstabelle_der_CDA_Strukturen_des_Headers|Ü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
 
==XDS-Mapping von clinicalDocument.code und translation==
 
==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)?
+
Beim Mapping von [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Dokumentenklasse_.28.E2.80.9Ecode.E2.80.9C.29|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
 
==Mapping von XDS.formatCode==
 
==Mapping von XDS.formatCode==
Sollte man die Extension von FormatCode besser zur templateID[2] (die für das Leitfaden-PDF) hängen?
+
===Welche TemplateId?===
 +
[[ILF:Allgemeiner_Implementierungsleitfaden_2020#ELGA_Implementierungsleitfaden-Kennzeichnung_.28.E2.80.9EtemplateId.E2.80.9C.29|TemplateIDs]]: Sollte man die Extension von FormatCode besser zur templateID[2] (die für das Leitfaden-PDF) hängen?
 +
--> Erledigt. Eigenes Schema Element
 +
===Statt TemplateID lieber neue Schema-Elemente?===
 +
Anstatt [[ILF:Allgemeiner_Implementierungsleitfaden_2020#ELGA_Implementierungsleitfaden-Kennzeichnung_.28.E2.80.9EtemplateId.E2.80.9C.29|XDS.formatCode]] und [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Terminologiedatum|Terminologie-Datum]] an TemplateID Elemente zu binden, könnte man auch Schema-Erweiterungen definieren, ähnlich wie bei  [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Fachliche_Zuordnung_des_Dokuments_.28.E2.80.9Ehl7at:practiceSettingCode.E2.80.9C.29|hl7at:practiceSettingCode]]
 +
Wäre das nicht eleganter?
 +
--> Erledigt. Eigenes Schema Element
 +
==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
 
==Verwendung von ungenauen Datums-Angaben==
 
==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 in problem entry
+
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.

Version vom 30. Juli 2020, 14:43 Uhr

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.