cdaefa Diskussion:EFA XDS Document Metadata Binding

Aus Hl7wiki
Version vom 17. September 2013, 16:22 Uhr von Jcaumanns (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „== EDoct.01.01 == ;Comment :Für den classCode würde ich keine LOINC codes empfehlen. Mir ist es noch nicht gelungen dort wirklich passende codes…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

EDoct.01.01

Comment
Für den classCode würde ich keine LOINC codes empfehlen. Mir ist es noch nicht gelungen dort wirklich passende codes zu identifizieren. Inhaltlich haben wir für das Cookbook die Festlegung auf ein noch zu definierendes value set geplant: Quote: "XDSDocumentEntry.classCode: Festlegung auf ein value set geplant (ca. 5-10 Werte, z.B. Untersuchungsbefund, Diagnostische Rohdaten, Arztbrief, Bilddaten, Pflegedokumentation, Administratives Dokument, Patientendokument)" (ti, 03.06.2013)
Author
ti

EDoct.02

Comment
Es sollten für die folgenden Attribute auch Festlegungen unabhängig von der Telematikinfrastruktur getroffen werden. Viele der aufgeführten Optionen sind ja auch ohne diese Infrastruktur sinnvoll und nutzbar (z.B. KBV Arztnummer Praxis oder Institutskennzeichen). (ti, 07.06.2013)
Author
ti
Comment Editor
Vorschlag: Trennung der Tabellen nach TI Relevanz.

EDoct.02.01

Comment
Ich würde hier eine Affinity Domain spezifische Identifikation nicht ausschliessen wollen. Für die Verwendung als Author Institution bietet sich natürlich die vom EFA Provider geführte Liste der autorisierbaren Organisationen (Einrichtungen, Fachkliniken, Abteilungen, ...) an. Es sollte ausserdem klar definiert werden ob die AuthorInstitution ID verpflichtend ist und auch die Beziehung zum Klarnamen, d.h. muss der Klarname der ID entsprechen oder kann er zusätzliche Eingrenzungen enthalten. Z.B. wenn die ID der UniKlinik A entspricht, darf der Name "Abteilung 1 der Fachklinik X der Uniklinik A" sein? (ti, 07.06.2013)
Author
ti
Comment Editor
Vorschlag: Klare Kennzeichnung von Attributen als verpflichtend (bspw. Author Institution ID und Name) und Verweis in Cookbook auf Dienste zur Verwaltung und Bereitstellung der Attribute für Benutzer, Organisationen etc. (z.B. HPD).

EDoct.02.02

Comment
Das Beispiel verwendet den Slot name authorInstitution, nicht authorPerson. Ausserdem wird im Text von "mul-tiple schemes are available for a role" gesprochen. Das sollte doch wahrscheinlich "multiple schemes are available for an author's ID" heissen. (ti, 07.06.2013)
Author
ti
Comment Editor
analog authorInstitution

EDoct.02.02

Comment
Auch hier sollte klarer definiert werden wann/ob die ID verpflichtend ist, oder ob die ID nur wenn vorhanden wie unten definiert abgebildet werden muss. (ti, 07.06.2013)
Author
ti
Comment Editor
analog authorInstitution

EDoct.02.02

Comment
Wie ist der Satz "If multiple IDs are known, at least two SHOULD be provided" zu verstehen? Wenn ich drei IDs für einen Arzt nutzen könnte, welche 2 sollten dann verwendet werden? (ti, 07.06.2013)
Author
ti
Comment Editor
Inhalt der Spalte "Person Role" vereinheitlichen.

Namen müssen in den Metadaten im Klartext enthalten sein, da nicht gewährleistet werden kann, dass alle potentiell in den Metadaten von Dokumenten referenzierten Personen im Personenverzeichnis des EFA Providers bekannt sind.

EDoct.02.02

Comment
Für den Arzt in der Privatpraxis erscheinen mir alle gegebenen Optionen wenig hilfreich. Hier sollte auch für Niedergelassene die Option einer nicht globalen ID existieren. (ti, 07.06.2013)
Author
ti

EDoct.02.02

Comment
Ist mit "<representedOrganization>" die authorInstitution gemeint? Dieser Begriff ist im HL7v3 Umfeld gebräuchlich, aber bei einem Binding von EFA Konzepten auf ebxml unter Einsatz von HL7v2 Datentypen nicht eindeutig genug. (ti, 07.06.2013)
Author
ti

EDoct.02.02

Comment
Generell würde ich die Notwendigkeit eines verpflichtenden Einsatzes von nationalen IDs bei AuthorPerson und AuthorInstitution hinterfragen. Im Berechtigungssystem der EFA sind diese Felder nicht Interoperabilitäts-relevant. Es werden keine Berechtigungen anhand des Authors gesteuert (wie es z.B. in anderen Systemen gemacht wird um dem Autor weitergehende Rechte einzuräumen). Auch fürs Audit sind diese Daten nur begrenzt wichtig, da es keinerlei Überprüfung der gemachten Angaben gibt. Die einzigen Gründe die mir für eine Pflicht zu nationalen IDs hier einfallen würde wäre eine ordentliche Darstellung bei Cross-Community (die man aber eher über den Klartextnamen und ein paar nicht-verpflichtende Formatierungshinweise für den Namen erreicht) und für Auswertungen bei Cross-Community Nutzung. Wobei die Auswertung durch die min. 4 Optionen dadurch immer noch nicht eindeutig wird. Kurz: Ein SHOULD für die Nutzung der hier beschriebenen identification schemes sollte ausreichen. (ti, 07.06.2013)
Author
ti

EDoct.02.02

Comment
Ich würde ausserdem einen Vorschlag hinzufügen, wie die Author Role und Author Speciality gefüllt werden sollten. (ti, 07.06.2013)
Author
ti

EDoct.02.04

Comment
Die Formulierung ist irreführend. Z.Zt. würde ich es wie folgt übersetzen: "Mit diesem Feld darf man nicht die Vertraulichkeit von persönlichen medizinischen Daten schützen." Gemeint ist doch wahrscheinlich eher: "For reasons of protecting the confidentiality of personal medical information this slot SHALL NOT be used." (ti, 07.06.2013)
Author
ti

EDoct.02.04

Comment
Hier sollte ausserdem klar zwischen der sourcePatientInfo und der sourcePatientId unterschieden werden. Die sourcePatientId sollte immer gesetzt sein um Fehlzuordnungen (z.B. durch einen MPI) rückgängig machen zu können. Dies ist auch der Ansatz des X-PID [1] (ti, 07.06.2013)
Author
ti