Änderungen

=Bekannte FehlerProbleme===Falsche Verwendung von AddressUse (statt ELGA_TelecomAddressUse)Arznei Entry == Einige Templates verlinken statt ELGA_TelecomAddressUse auf: 2Betrifft v.16a.840.1.113883.1.11.190 AddressUse betrifftdie e-Medikation, aber auch andere Leitfäden, die mit dem Arznei Entry arbeiten:* 1.2.40.0.34.6.0.11.1.21 Participant Ein-Entlassungsbrief, Ambulanzbefund, UeberTelemonitoring-, Zuweisender Arzt * 1Episodenbericht.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 BeschreibungInfusionen, aber das falsche Value Set wird referenziert. Sobald die Value Sets aus Basisleitfäden ins ATCDABBR verschoben wurdenmehreren Bestandteilen bestehen, können diese ebenfalls refereziert nicht adäquat abgebildet werden.([https://jira-neu.elga.gv.at/browse/ELGA-914 ELGA-914])

''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==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.