WGM-2016-05 Montreal

Projekt-Arbeit FHIR-Basis-Profilierung auf dem HL7 International WorkGroup Meeting 2016/05 in Montréal, Canada

Projekt-Arbeit FHIR-Basis-Profilierung auf dem WGM 2016/05 (Montréal)

Agenda

Version:	1.0
Datum:	{{{Date}}}
Status:
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2016: HL7 Deutschland

Veranstaltungsort und -zeiten

HL7 International Work Group Meeting 2016/05 in Montréal, Canada

Protokoll

Erläuterungen

CHANGE REQUEST-Links verweisen auf Items im GForge-Tracker von HL7 International. Der Tracker wird verwendet, um Change Requests nachzuverfolgen und strukturiert von den jeweils zuständigen WorkingGroups abgearbeitet zu werden.

ZULIP-Links verweisen auf eine zu einem Thema gehörende Diskussion im internationalen FHIR-Chat. Die Seiten sind nur für registrierte User einsehbar. Für die Erstellung eines ZULIP-Accounts gibt es jedoch keine Zugangsvoraussetzungen.

CONNECTATHON

TRACK: Conditional Reference

FUNKTION: Track Lead, Client Implementer, TestScript Editor

MOTIVATION: siehe wiki.hl7.org

ERGEBNIS: siehe FHIR-ConditionalReferences_AID_Montreal_2016.pptx

CHANGE REQUEST #9998

ZULIP

WORKGROUP: FHIR-Infrastructure (FHIR-I)

TOPIC: _has-Parameter als Erweiterung des reverse Include

DISKUSSION: Einführung des Suchparameters _has, um Resourcen zu identifizieren, die von einer anderen Resource, die das Kriterium erfüllt, referenziert werden. Derzeit ist das nur über den Parameter _revinclude möglich, der jedoch primär die Resoure mit dem Suchkriterium zurückliefert und zusätzlich die referenzierenden Resourcen (eingrenzbar nach Typ) enthält. Es ist also nicht möglich eine Liste aller Patienten, die von Benutzer X (Provenance) angelegt wurden, anzurufen oder eine Liste aller Observations, die von einem bestimmten Device erzeugt wurden, ohne stets ein Bundle mit einer Mischung aus Patient/Provenance oder Observation/Device zu erhalten.

STANDPUNKT: Der Mechanismus ist von erheblicher Bedeutung im Hinblick auf die Abbildung des in V2 üblichen Snapshot-Verfahrens (die aktuell übermittelten Allergien/Diagnosen/Prozeduren ersetzen alle zuvor übermittelten Allergien/Diagnosen/Prozeduren), da hier eine Selektion basierend auf Eigenschaften der Provenance Resource erforderlich ist, die als Ergebnis ein Liste der zutreffenden Allergien/Diagnosen/Prozeduren erwartet. (Bspw. Für ein conditional DELETE)

ZULIP

TOPIC: Provenance

STANDPUNKT: Die Möglichkeit der Nutzung der Provenance Resource zur Darstellung einer Herkunft einer Resource als Derivat aus einem Mapping (CDA-> FHIR, V2->FHIR…) durch eine Middleware-Komponente ist unzureichend.

CHANGE REQUEST #9996

ZULIP

WORKGROUP: Patient Administration (PA)

TOPIC: Patient.careProvider

DISKUSSION: Nomenklatur und Kardinalität und Typisierung

STANDPUNKT: Der „Hausarzt“ in seiner Funktion als Gatekeeper hat i.d.R die Kardinalität 0..1, es kann jedoch Sonderfälle geben, in denen der Patient den Hausarzt häufig wechselt oder unentschlossen ist und daher möchte, dass mehrere Ärzte über den Ausgang der Behandlung informiert werden. In diesem Fall ist jedoch keine Typisierung erforderlich, da die Ärzte „gleichberechtigt“ mit identischer Funktion sind. Die genannten Fälle, in denen eine Typisierung erforderlich wäre (z.B: um zusätzlich den „Hausapotheker“ zu erfassen oder den „Hauszahnarzt“, handelt es sich um regionale oder domänenspezifische Sonderfälle, die zwar als Standard-Extension modelliert, jedoch nicht Teil der Patient-Resource werden sollten). Die Motion zur Umbenennung von careProvider in generalPractitioner um den Scope klarer zu definieren, wurde unterstützt.

TOPIC: Practitioner.practitionerRole

DISKUSSION: BackboneElement oder eigene Resource

STANDPUNKT: Keep it simple! Es muss möglich sein, einen Parctitioner zu erfassen, der z.B. nur durch seinen Namen und seine Telefonnummer bekannt ist, ohne dafür mehrere Resourcen bilden zu müssen. Es wird jedoch anerkannt, dass auch in DE die Möglichkeit besteht, dass ein Practitioner durch unterschiedliche Rollen mit verschiedenen Organisationen verknüpft sein kann, wobei sich dann auch die Kontaktinformationen abhängig von der jeweiligen Rolle, ändern.

TOPIC: Account

DISKUSSION: allgemeine Modellierung

STANDPUNKT: Unterstützung der Auffassung von PA, dass es eine unmittelbare Referenz von Account zu Coverage geben sollte. Sonst keine diesbezüglichen Anforderungen aus DE bekannt.

TOPIC: Location (allgemeine Modellierung)

STANDPUNKT: Die Modellierung von HL7 V2 PV1.#3 (Patient Location mit den Subfeldern POC/Room/Bed/Department) in FHIR bringt einige Schwierigkeiten mit sich:

• Wann verwendet man Location, wann Organization?
• Welche Codes für Location.physicalType bzw. Organization.type eignen sich jeweils?
• Muss ein Client die gesamte Hierarchie modellieren oder genügt es, die Location auf unterster Ebene zu referenzieren, davon ausgehend, dass die Hierarchie auf dem Server bekannt ist?

Zusammenstellung einer Kurzpräsentation und Übermittlung an PA zur weiteren Diskussion in der WorkingGroup.

CHANGE REQUEST #10017

TOPIC: Definition der Operationen Patient/$match bzw. Patient/$search

STANDPUNKT: Es sollten keine einzelnen Such-Parameter für die Operationen definiert werden. Statt dessen sollte der Client stets eine Patient-Resource übermitteln, die alle bekannten Informationen zu dem Patienten enthält. Vorteil:

• Keine sensiblen Patientendaten in der URL (Security!)

Der Server kann die Matching-Kriterien ändern/anpassen, ohne dass die Definition der Operation geändert werden muss. (--> Query by Example)

• Die Operation $match würde meist von Middlewarekomponenten angesprochen und sollte stets nur ein oder kein Ergebnis zurückliefern (Patient oder OperationOutcome), niemals ein Search-Result-Bundle. (Unklare Matches werden vom MPI geklärt, nicht von der anfragenden Applikation!!)
• Die Operation $search würde jedoch von einer Endanwender-Applikation aufgerufen, um bei der Erfassung von Patientendaten möglich Treffer zurückzugeben, die nach Qualität sortiert zurückübermittelt werden. Der Client sollte eine Information über die ermittelte Qualität des Treffers erhalten (Score). Dazu wäre jedoch eine Erweiterung der Bundle-Resource erforderlich.

WORKGROUP: Patient Administration (PA) j/w Financial Management (FM)

TOPIC: Coverage - Modellierung von Selbstzahlerverhältnissen

STANDPUNKT: Selbstzahler, abweichender Rechnungsempfänger als Coverage mit Payor statt Guarantor modellieren, dazu erforderlich: Attribut issuer umbenennen in payor und Referenz auf Organization|Patient|RelatedPerson erlauben. ValueSet für Coverage.type erweitern um einen Code für „Private Person Payor“ für Selbstzahler/Selbstzahler mit abweichendem Rechnungsempfänger

CHANGE REQUEST #9200

ZULIP

TOPIC: Verwendung des Attributs Coverage.network

STANDPUNKT: Da sich in der Diskussion deutliche regionale Unterschiede bei der Verwendung des Attributs (als String vs Code vs CodableConcept vs Referenz auf Organization) ergeben und DE derzeit keine bekannte Verwendung für das Attribut hat, sollte das Attribut als Extension modelliert werden, wo es je nach regionalem Bedarf typisiert werden kann.

TOPIC: Coverage - allgemeine Modellierung

STANDPUNKT: Das Attribut Coverage.bin scheint in Abstimmung mit anderen europäischen Affiliates ein US-amerikanisches Phänomen zu sein und sollte daher entweder als Instanz eines Identifiers oder als Extension modelliert werden. Das Attribut Coverage.Identifier sollte zur Harmonisierung mit anderen FHIR-Resourcen an erster Stelle in der Resource erscheinen.

CHANGE REQUEST #9115

WORKGROUP: Patient Care (PC)

TOPIC: Observation/Condition

DISKUSSION: Abgrenzung der beiden Resourcen STANDPUNKT: Grundsätzlich ist die im Wording unklare Abgrenzung „ Wann verwende ich Condition, wann Observation“ kritisch zu sehen. Aus Implementierer-Sicht wäre eine Zusammenführung beider Resourcen einfacher zu handhaben. Es ist jedoch davon auszugehen, dass in DE eine recht einfache Abgrenzung der Art: ICD10-Diagnose -> Condition, alles andere -> Observation möglich wäre. Daher Enthaltung in der Frage. Das Voting fiel gegen eine Zusammenführung und für eine Präzisierung der jeweiligen Scopes aus.

TOPIC: Harmonisierung von Observation.related und Condition.dueTo

STANDPUNKT: Die Mechanismen zur Referenzierung sollten harmonisiert werden. Derzeit verfolgt Observation den Ansatz einer generischen Referenz mit Typisierung, während Condition spezifische Referenzen pro Typ modelliert. Teilweise sind diese in Extensions ausgelagert, was verhindert, dass die in ICD10 typischen +/*-Diagnosen-links nicht mit der Standard-Resource abgebildet werden können.

Der Change-Request wurde eingereicht, jedoch auf dem WGM noch nicht diskutiert:

CHANGE REQUEST #9970

ZULIP

Teilnehmer

• Simone Heckmann (Health-Comm), stellvertretend für die AG FHIR Basisprofilierung

Nächste Termine

• Baltimore 2016/09