ILF Diskussion:Allgemeiner Implementierungsleitfaden (Version 3): Unterschied zwischen den Versionen
K (→Diskussion) |
K (→Gelöst) |
||
| Zeile 8: | Zeile 8: | ||
Derzeit keine | Derzeit keine | ||
| − | = | + | =Beendete Diskussionen= |
==Ü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] --> Erledigt | 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 | ||
Version vom 29. Juli 2020, 14:27 Uhr
Inhaltsverzeichnis
1 Bekannte Fehler
keine
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.
