cdaefa Diskussion:EFA XDS Document Metadata Binding

Aus Hl7wiki
Version vom 24. Januar 2014, 15:54 Uhr von Jcaumanns (Diskussion | Beiträge) (Aktuelle Fassung der Kommentar-Tabelle eingefügt.)
Wechseln zu: Navigation, Suche

Kommentierung

Author Status Section Existing Proposed Comment Comment Editor Discussion
ti rejected EDoct.01.01 : classCode 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) Die verbindliche Vorgabe eines value sets ist unserer Meinung nach nicht sinnvoll. Mit der EFA 1.2 wurde ein value set für Dokumentklassen definiert, was sich als hinderlich herausstellte.
ti included EDoct.02 : German Profile 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) Ein entsprechder Hinweis wurde hinzugefügt, dass die Telematik-ID und SMC-B nur im Zusammenspiel mit der Telematik-Infrastruktur zu nutzen sind. Vorschlag: Trennung der Tabellen nach TI Relevanz.
ti included EDoct.02.01 : Author Institution 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) Hinweis wurde hinzugefügt. Proprietäre Identifier sind zulässig, wenn sie über einen Verzeichnisdienst zugänglich sind. 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).
ti included EDoct.02.02 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) 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.

ti included EDoct.02.02 : Author Person 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)
ti included EDoct.02.02 : Author Person 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) Zusätzlich zu TI-spezifischen Vorgaben sollten weitere unverbindliche Vorschläge ausgearbeitet werden, bspw LDAP,HPD-Mapping (ti)
ti postponed EDoct.02.02 : Author Person Ich würde ausserdem einen Vorschlag hinzufügen, wie die Author Role und Author Speciality gefüllt werden sollten. (ti, 07.06.2013) Role und speciality Attribute werden über das Cookbook definiert, da sie für alle Aktensysteme einheitlich sind.
ti included EDoct.02.02 : Author Person 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) analog authorInstitution
ti included EDoct.02.02 : Author Person 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) analog authorInstitution
ti included EDoct.02.02 : Author Person 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) Tabelle wird korrigiert
ti included EDoct.02.04 : sourcePatientInfo 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)
ti included EDoct.02.04 : sourcePatientInfo 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) sourcePatientId ist immer gesetzt, aber sourcePatientInfo darf nicht genutzt werden, da vertrauliche Daten enthalten sein können weitere Felder sind betroffen und sollten entsprechend kommentiert sein: title, comment (ti)