| ID
|
Author
|
Status
|
Section
|
Vote
|
Existing
|
Proposed
|
Comment
|
Comment Editor
|
Discussion
|
| 83
|
ti
|
postponed
|
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)
|
Sobald die entsprechenden Festlegungen im Cookbook getroffen sind, wird die EFA-Spezifikation entsprechend für dieses Value Set geöffnet.
|
|
| 84
|
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.
|
| 85
|
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).
|
| 86
|
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.
|
|
| 87
|
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)
|
|
|
| 88
|
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)
|
| 89
|
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.
|
|
| 90
|
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
|
|
| 91
|
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
|
|
| 92
|
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
|
|
| 93
|
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)
|
|
|
| 94
|
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)
|
