Quelltext der Seite WGM-2016-05 Montreal

{{#CustomTitle:Projekt-Arbeit FHIR-Basis-Profilierung auf dem WGM 2016/05 (Montréal)}}
{{Infobox Dokument
|Title     = Projekt-Arbeit FHIR-Basis-Profilierung auf dem HL7 International WorkGroup Meeting 2016/05 in Montréal, Canada
|Short     = Projekt-Arbeit FHIR-Basis-Profilierung auf dem WGM 2016/05 (Montréal)
|Type      = Agenda
|Version   = 1.0
|Copyright = 2016
|Namespace = iopfp
|Status    =
|Period    =
|OID       = 
|Realm     = 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 [http://wiki.hl7.org/index.php?title=201605_Conditional_Reference_Connectathon_Proposal wiki.hl7.org]

ERGEBNIS: siehe FHIR-ConditionalReferences_AID_Montreal_2016.pptx

[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=9998 ''CHANGE REQUEST #9998'']

[https://chat.fhir.org/#narrow/stream/implementers/topic/Connectathon.20Conditional.20Reference.20Stream ''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)

[https://chat.fhir.org/#narrow/stream/implementers/topic/_has.20parameter.20proposal ZULIP]
 
 
 
===TOPIC: [http://hl7-fhir.github.io/provenance.html 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.

[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=9996 ''CHANGE REQUEST #9996'']

[https://chat.fhir.org/#narrow/stream/implementers/topic/Provenance.20resource.20for.20Middleware ''ZULIP'']

==WORKGROUP: Patient Administration (PA)==
===TOPIC: [http://hl7-fhir.github.io/patient-definitions.html#Patient.careProvider 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:  [http://hl7-fhir.github.io/practitioner-definitions.html#Practitioner.practitionerRole 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: [http://hl7-fhir.github.io/patient-definitions.html#Patient.careProvider 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: [http://hl7-fhir.github.io/location.html 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.

[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=10017 ''CHANGE REQUEST #10017'']
 

===TOPIC: Definition der Operationen [http://hl7-fhir.github.io/patient-operations.html#match 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: [http://hl7-fhir.github.io/coverage.html 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.
[http://hl7-fhir.github.io/v3/ActCoverageTypeCode/vs.html ValueSet für Coverage.type] erweitern um einen Code für „Private Person Payor“ für Selbstzahler/Selbstzahler mit abweichendem Rechnungsempfänger

[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=9200 ''CHANGE REQUEST #9200'']

[https://chat.fhir.org/#narrow/stream/implementers/topic/Using.20Coverage.20for.20Selfpayor ''ZULIP'']


===TOPIC: Verwendung des Attributs [http://hl7-fhir.github.io/coverage-definitions.html#Coverage.network 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: [http://hl7-fhir.github.io/coverage.html 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 [http://hl7-fhir.github.io/coverage-definitions.html#Coverage.identifier Coverage.Identifier] sollte zur Harmonisierung mit anderen FHIR-Resourcen an erster Stelle in der Resource erscheinen.

[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=9115 ''CHANGE REQUEST #9115'']
 
 
 
==WORKGROUP: Patient Care (PC)==
===TOPIC: [http://hl7-fhir.github.io/observation.html Observation]/[http://hl7-fhir.github.io/condition.html 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 [http://wiki.hl7.de/index.php?title=FHIR-Kritzelblock_CRQ_Verlinkte_Diagnosen Change-Request] wurde eingereicht, jedoch auf dem WGM noch nicht diskutiert:

[http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_id=677&tracker_item_id=9970 ''CHANGE REQUEST #9970'']

[https://chat.fhir.org/#narrow/stream/implementers/topic/Related.20Observations ''ZULIP'']
 

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


== Nächste Termine ==
* Baltimore 2016/09


<!-- categories, no other code below -->
[[Kategorie:Protokolle (Projekt Basisprofilierung)]]