ILF Diskussion:Allgemeiner Implementierungsleitfaden (Version 3): Unterschied zwischen den Versionen
K |
K (→Bekannte Fehler) |
||
(14 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
− | =Bekannte | + | =Bekannte Probleme= |
− | == | + | ==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. ([https://jira-neu.elga.gv.at/browse/ELGA-914 ELGA-914]) | |
− | |||
− | |||
− | |||
− | |||
− | |||
=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
Inhaltsverzeichnis
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.