Endpoint-Ressource im VZD-FHIR über TIM-Account ungeeignet

[mlangguth]

Im VZD-FHIR-Projekt wird zur Speicherung der zu einem TIM-Account zugehörigen MXID eine Endpoint-Ressource unterhalb einer HealthcareService-Ressource verwendet.

Aus meiner Sicht wurde hier eine FHIR-Ressource verwendet, die für etwas anderes gedacht war: Maschinen-Endpunkte für reine M2M-Kommunikationen. Daher findet sich dort auch lediglich ein Namensfeld, welche den techn. Endpoint für Menschen leichter identifizierbar machen soll.
Für die Suche und Identifikation nach dem TIM-Account eines Menschen (oder eines Funktionsaccounts) ist dieser Ressourcentyp eigentlich gänzlich ungeeignet, weil die für die Erkennung des gesuchten TIM-Accounts weitergehende Informationen erforderlich sind. Daher werden menschenbezogene Kommunikationsendpunkte in FHIR ja eigentlich in Knotenpunkten innerhalb der Organisations- bzw. HealthcareService- sowie der personenbezogenen Ressourcen unter telecom gespeichert.

Das größte Problem stellt dar, dass für Suchende nur das Namensfeld zur Verfügung steht. Werden unterhalb einer HealthcareService-Ressource die multiplen TIM-User mit ihren MXIDs eingehängt, steht zu jeder MXID nur "Nachname, Vorname" - ohne Kennung, ob es sich um den Apotheker, den Assistenzarzt, die Pflegekraft, den Chefarzt oder eine Schreibkraft dieser HealthcareService-Einheit handelt.
Das ist nicht zielführend.

Entsprechend muss aus unserer Sicht die Verwaltung der MXIDs und deren Zuordnung zu findbaren Einträgen im VZD-FHIR (oder einem TIM-eigenen Adressbuch!) dringend überdacht werden.

[spilikin]

Moin,

HealthcareService.telekom und PractitionerRole.telekom verwenden Datatype

http://hl7.org/fhir/R4B/datatypes.html#ContactPoint

Mit "geschlossenem" ValueSets für system und use.

phone | fax | email | pager | url | sms | other
home | work | temp | old | mobile

Kodierung von TIM Adressen dort drin erscheint uns zu restrikltiv und unflexibel. Zudem würden später die KIM-Mailadressen mit normalen E-Mail Adressen kollidieren.

Benutzung der Endpoints für Kontaktdaten der Mitarbeiter innerhalb der HealthcareService ist tatsächlich nicht optimal. Dafür ist PractitionerRole da. Allerdings gibt es derzeit werder Prozesse noch Tools die es erlauben die Zuordnung von Personen und Institutionen durchzuführen. Beides ist in Vorbereitung und teilweise in Diskussion, denn verantwortlich für die Daten im VZD sind laut Gesetz die Kartenherausgeber. Backend ist soweit vorbereitet, Prozesse und Clients werden folgen.

Ich erlaube mir hier die technokratische Sicht auf "Nutzerbedarf" zu hinterfragen. Besser wäre simpel anzufangen: persönliche Konten für Ärzte und überschaubare Anzahl der Mitarbeiter für die Außenkommunikation. Zentrales Adressbuch bist auf Mitarbeiterebene ist keine einzige (gute) Idee wie eine robuste, dezentrale Kommunikation erfolgen kann.

[mb010865]

Aus meiner Sicht sind die unter HealthcareService abgelegten Endpoints nur generische Matrix-Adressen für die Institution wie von Spilikin erwähnt. Gemäß der Diskussion um den PayloadTypes kann dies entweder ein generischer "Info" Account für die Praxis sein oder eine maschinelle Adresse, unter der das Primärsystem Workflow-Messages erhält.
Die persönlichen Matrix-IDs hängen unter der Practitioner-Role und dort kann man alle möglichen persönlichen Daten hinterlegen. Die Verbindung zur Institution wird über die Location realisiert.

[mlangguth]

@spilikin VZD-Pflege ist durch gesetzliche Vorgabe nur den Kartenherausgebern erlaubt? Diese Regelung kenne ich tatsächlich nicht. Hast Du einen Verweis auf die gesetzliche Grundlage? Ich vermute eher, dass sich das "so entwickelt hat" und man flexibler agieren könnte (aus juristischer Sicht). Lasse mich aber gerne eines besseren belehren. In diesem Falle müsste man auf das BMG zugehen, damit diese blockierende gesetzliche Vorgabe aufgehoben wird (Gesetzvorhaben ist ja gerade in Arbeit, da würde das gut passen).
...

Mit "geschlossenem" ValueSets für system und use.
Gemäß Vorgabe sollten TIM-Adressen unter URL eingebunden werden: tim://
Das gleiche Vorgehen könnte auch für die KIM-Adressen gewählt werden: kim://
Alternativ könnte auch das ValueSet erweitert werden, damit es auf den UseCase passt. (dafür ist Profilierung bei FHIR ja da 😉)

...

Die persönlichen Matrix-IDs hängen unter der Practitioner-Role und dort kann man alle möglichen persönlichen Daten hinterlegen.

Leider nein, das gilt nur für die HBA-User. Die "normalen User" (und das werden nicht unerheblich viele sein) hängen lediglich als Endpoint unter der HCS-Ressource.

...
Ich möchte noch einmal vorschlagen, dass wir die fachlichen Bedarfe zusammentragen, die für Suchen aus ambulanten Einrichtungen und aus stationären Einrichtungen heraus entstehen - ebenso wie die Informationsbedarfe, die die TIM-Teilnehmer im Rahmen der TIM-Nutzung über die Teilnehmer und Institutionen (und deren Rollen) haben.
Ohne vollständige Sicht auf die fachlichen Bedarfe wird die technische Lösung nur "mit Glück" passen.🤷‍♂️

[mb010865]

@mlangguth Ja den Auftrag haben nur die Kartenherausgeber (Kammern etc.). Die Sicherstellung, dass nur "offiziell" bestätigte
Heilberufler ist bisher das Qualitätskriterium des VZD.
Aus meiner Sicht kann man die Teilnehmer, welche nicht im Besitz eines HBA sind nicht einfach als Endpoint an den HealthcareService hängen. Das würde die Implementierung einer konsistente Suche erschweren.
Aber da wir grade den Orgadmin Client entwickeln stehen wir auch vor verschiedenen Fragestellungen, wie am Ende welche Art Nutzer angelegt bzw. mit MXID erweitert werden. Hier wäre sinnvoll, die Funktionalitäten noch etwas genauer zu beschreiben. Welche Daten sind nach Synchronisation mit LDAP-VZD schon vorhanden (evtl. aufgeschlüsselt nach verschiedenen Szenarien Klinik/Praxis/Apotheke). Welche Daten davon sind read-only und welche Strukturen müssen und können hinzugefügt oder geändert werden.
Das neue Beispiel der Zahnarztpraxis in Simplifier hat schon etwas weitergeholfen.
Dies sollte noch erweitert werden mit den weiteren Beispiel-Fällen.

[mlangguth]

Das neue Beispiel der Zahnarztpraxis in Simplifier hat schon etwas weitergeholfen.

Eventuell ein Link griffbereit?

...

Aus meiner Sicht kann man die Teilnehmer, welche nicht im Besitz eines HBA sind nicht einfach als Endpoint an den HealthcareService hängen.

Genau das ist spezifiziert - und nötig, da alle an der Versorgung beteiligten timmen können sollen - und nur die Minderheit hat einen HBA bzw. will als HBA-Inhaber als Einzelperson außerhalb einer zugeordneten Einrichtung gefunden werden. (Gilt nahezu für alle Klinkärzte).

Um so wichtiger ist es aus meiner Sicht, dass der Ansatz ("Kopieren wir die Einträge des eher nicht so gut funktionierenden VZD einfach nach VZD-FHIR") noch mal überdacht werden sollte.
Was es aus meiner Sicht braucht, sind durch die Organisation pflegbare Einträge im VZD-FHIR (kann man weitgehend durch Kopplung an das eigene AD automatisieren). Das beinhaltet die Organsisationsstrukturen (im heutigen VZD nicht vorhanden) und die Personzuordnungen (im heutigen VZD nicht vorhanden). Dabei ist es wichtig zu beachten, dass mit Organisation die juristische Person gemeint ist, nicht die "Organisation nach VZD", die darunter eine TID einer SMC-B versteht, welche gerade in Kliniken nur Untereinheiten der juristischen Person sind!

Zu jedem Eintrag (Orga und Personal) sollten dann Validierungsflags gesetzt werden, ob der Eintrag durch die SMC-B bzw. den HBA bestätigt wurde (bzgl. Name, Fachrichtung, Profession).
Über diesen Ansatz ließe sich ein Verzeichnis aufbauen (und pflegen), mit dem Suchende wirklich arbeiten könnten.