Hauptseite > Allgemeiner Implementierungsleitfaden (Version 3)
|
|
| Zeile 9: |
Zeile 9: |
| | | | |
| | Derzeit keine | | 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==
| |
| − | 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==
| |
| − | ===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==
| |
| − | 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 21. August 2020, 14:27 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
