cdaefa Diskussion:EFA XDS Document Metadata Binding
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…“)
Inhaltsverzeichnis
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