ILF Diskussion:Allgemeiner Implementierungsleitfaden (Version 3): Unterschied zwischen den Versionen
K (→Bekannte Fehler) |
K (→Diskussion) |
||
| Zeile 4: | Zeile 4: | ||
=Diskussion= | =Diskussion= | ||
''Zu diesen Punkten würden die Autoren der Spezifikation gerne die Meinung der Ballot-Teilnehmer und potentiellen Implementierer erfahren.'' | ''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 | |
| − | |||
=Gelöst= | =Gelöst= | ||
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 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.
