ILF Diskussion:Allgemeiner Implementierungsleitfaden (Version 3): Unterschied zwischen den Versionen
Tanjga (Diskussion | Beiträge) (→Diskussion) |
K (→Diskussion) |
||
| Zeile 13: | Zeile 13: | ||
Bitte über das Ballot Formular[https://download.hl7.at/ballot-2020-1/HL7-Ballot-2020-1_MeineOrganisation.xlsx] abstimmen und an [mailto:office@hl7.at office@hl7.at] senden. Weitere Informationen zum Abstimmungsverfahren unter https://hl7.at/abstimmungsverfahren-2020-1-gestartet/ | Bitte über das Ballot Formular[https://download.hl7.at/ballot-2020-1/HL7-Ballot-2020-1_MeineOrganisation.xlsx] abstimmen und an [mailto:office@hl7.at office@hl7.at] senden. Weitere Informationen zum Abstimmungsverfahren unter https://hl7.at/abstimmungsverfahren-2020-1-gestartet/ | ||
| + | |||
| + | |||
| + | =Gelöst= | ||
==Übersichtstabelle der CDA Strukturen des Headers== | ==Ü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] | + | 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 [[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)? | 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== | ||
===Welche TemplateId?=== | ===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? | [[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?=== | ===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]] | 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? | 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 zB 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 29. Juli 2020, 15:21 Uhr
Inhaltsverzeichnis
1 Bekannte Fehler
1.1 Falsche Verwendung von AddressUse (statt ELGA_TelecomAddressUse)
Einige Templates verlinken statt ELGA_TelecomAddressUse auf: 2.16.840.1.113883.1.11.190 AddressUse betrifft:
- 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 referenziert werden.
2 Diskussion
Zu diesen Punkten würden die Autoren der Spezifikation gerne die Meinung der Ballot-Teilnehmer und potentiellen Implementierer erfahren.
Bitte über das Ballot Formular[1] abstimmen und an office@hl7.at senden. Weitere Informationen zum Abstimmungsverfahren unter https://hl7.at/abstimmungsverfahren-2020-1-gestartet/
3 Gelöst
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.
