TelKo-FHIR 2016-01-19

Projekt-Arbeit FHIR-Basis-Profilierung TelKo vom 19. Januar 2016

Projekt-Arbeit FHIR-Basis-Profilierung TelKo vom 19. Januar 2016

Agenda

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

Copyright © 2016: HL7 Deutschland

Veranstaltungsort und -zeiten

TelKo vom 19. Januar 2016

Gotomeeting: Meeting-ID: 315-770-069 https://global.gotomeeting.com/join/315770069

• Deutschland: +49 (0) 692 5736 7211
• Niederlande: +31 (0) 208 080 379
• Norwegen: +47 21 03 58 96
• Vereinigte Staaten: +1 (786) 358-5410
• Österreich: +43 7 2088 1400

vorgesehene Agenda

• Aktuelle Themen FHIR international
  • CDS Hooks
• Change Requests (Item im GForge tracker)
• Möglichkeiten zur Partizipation
  • ListServ abonnieren
  • Blogs
  • twitter.com/#FHIR
• FHIR Kritzelblock
  • Versicherungsverhältnisse
  • Location, Location, Location
  • Medikationsplan
• Offene Punkte des vorherigen Protokolles

Protokoll

Aktuelle Themen FHIR international

• Grahame Grieve wurde zum "Product Manager" für HL7 FHIR ernannt http://www.healthintersections.com.au/?p=2434
• Weitere Infos zum Zeitplan: DSTU3 Ballot im September http://www.healthintersections.com.au/?p=2436

Möglichkeiten zur Partizipation

• ListServ abonnieren (-> www.hl7.org -> Resources -> ListServ -> anmelden und Listen auswählen
  

Am Seitenanfang jeder FHIR Resource ist angegeben, welche WorkingGroup dafür zuständig ist. Bei Interesse an konreten Resourcen, macht es Sinn, neben den allgemeinen FHIR-Listen auch die Liste der WorkingGroup zu abonnnieren

• twitter.com/#FHIR

Change Requests

• Item 9138: Add "PI" and "VN" to Identifier.Type Code
  

Status: Triaged Ohne Gegenstimme zurückgenommen, da "PI" semantisch äquivalent mit "MR=Medical Record Number" und "VN" der einzig in Frage kommende Typ für Fallnummern darstellt, daher ist explizite die Angabe eines Type-Codes bei Fallnummern nicht erforderlich.

• Item 9115:BIN as Coverage attribute should be moved to extension or identifier
  

Status: Triaged Wurde auf dem WorkingGroup Meeting in Orlando neben einigen weiteren Anpassungen angepasst, überarbeitete Spezifikation ist jedoch noch nicht veröffentlicht.

• Item 9196:ValueSet binding to version specific ICD10 in Structure definition needs example or best practice advice (Nachtrag vom 9.1.)
  

Analog auch bei OPS!

Nachtrag vom 19.1.2016 (Simone Heckmann)

Das Problem kann gelöst werden, in dem man ein ValueSet (mit fixer URL) definiert, in dem alle Codes aller ICD-GM-Ausgaben unter Angabe des jeweiligen CodeSystems (als URL mit Jahreszahl) enthalten sind. Jeder Code in einer Instanz muss dann verpflichtend immer mit Angabe des verwendeten CodeSystems übermittelt werden. Dann kann bei der Validierung festgestellt werden, ob der Code in Verbindung mit dem genannten CodeSystem innerhalb des Value Sets valide ist.
Frei erfundenes Beispiel: Der Code X99.0 existiert in ICD10-GM-2014 nicht.
X99.0 wird in ICD10-GM-2015 hinzugefügt mit der Semantik "Patient ist krank"
In ICD10-GM-2016 wird die Semantik geändert auf "Patient ist sehr krank"

Im Profil wird Observation.Code gebunden an das ValueSet mit dem Namen "https://www.dimdi.de/icd10-gm" Das Valuset enthält zum Code X99.0 folgende Einträge:

Code	Codesystem	Beschreibung
X99.0	https://www.dimdi.de/icd10-gm-2015	Patient ist krank
X99.0	https://www.dimdi.de/icd10-gm-2016	Patient ist sehr krank

Die Instanz sieht dann so aus:

    <Observation>
      ...
     <code>
       <coding>
         <system value = "https://www.dimdi.de/icd10-gm-2016"/>
         <code value  = "X99.0" />
         <display value = "Patient ist sehr krank" />
      </coding>
    </code>
      ...
    </Observation>

Damit kann jede Instanz gegen das ValueSet validiert werden und die Semantik des Codes ist ebenfalls eindeutig.

Eine Instanz mit

         <system value = "https://www.dimdi.de/icd10-gm-2014"/>
         <code value  = "X99.0" />

würde als ungültig abgelehnt, da es den Code aus diesem CodeSystem im ValueSet nicht gibt. Die Profile müssen nicht jedes Jahr geändert werden, da der Name des ValueSets konstant bleibt. Jedoch erhält das ValueSet jedes Jahr eine neue Version, da alle gültigen Codes des neuen Jahres hinzugefügt werden müssen. Außer einem etwas unhandlichen ValueSet sollte das technisch unproblematisch sein. (Bei der nächsten TelKo nochmal durchdenken und ggf. den Request zurückziehen.)

Extensions

Resource Patient

Namespace URLs

• Vorschlag für eGK-Nummer als Patient.identifier: System = "http://kvnummer.gkvnet.de/"
• Vorschlag für eGK-ValueSets (z.B: Geschlechtskennzeichen): System = "http://www.gematik.de/ValueSets/<Name>"
  (Wird bspw. für ConceptMaps benötigt)
• TODO: Ergänzen mit URLs für LANR und BSNR und erstellen einer Übersichtsseite im Wiki

Beruf

Name:Beruf
Datentyp: CodableConcept
Binding: http://statistik.arbeitsagentur.de/nn_10414/Statischer-Content/Grundlagen/Klassifikation-der-Berufe/KldB2010/Systematik-Verzeichnisse/Systematik-Verzeichnisse.html
TODO: Erstellen der Extension, hat aber niedrige Priorität, da derzeit in einem UseCase benötigt

Staatsangehörigkeit

Es gibt bereits die Core-Extensions

• Nationality
• Citizenship

die hierfür in Frage kommen. Es ist lediglich ein Binding an ein geeignetes ValueSet erforderlich, z.B.: ISO 3166 (Namespace: urn:iso:std:iso:3166 gemäß [1]

• Hier ein Beispiel für die Einbindung der Nationality mit Binding an ISO-Ländercodes: hspc-patient
• CAVE: Es gibt unterschiedliche Codes im ISO-Standard (2-stellig/3-stellig alphanum/numerisch)
• Im GKV-Umfeld werden 3stellige (Auto)-Kennzeichen verwendet, TODO: Klären, ob diese identisch sind mit ISO

Adresse

• Hausnummer fehlt
• Adresstyp "BI=Billing Address" fehlt in ValueSet AdressUse. Interessanterweise gibt es für den Code keine deutsche Übersetzung! Wird der wirklich verwendet/benötigt? Konnte im Rahmen der TelKo nicht geklärt werden. Von wem kam die Anforderung?

Resource Observation

Todesursache

Im Kontext von Onkologischen Registern erforderlich.
Eventuell als Extension an die Observation, die den Tumor/ die Diagnose beschreibt, die als Todesursache identifiziert wurde, analog zur Extension hspc-allergyintolerance-CauseOfDeathInd
TODO: Warum YES/NO-Indicator als Datentyp statt Boolean!?

• Wie werden nicht-tumor-Todesursachen als tumorbedingt gekennzeichnet?
• Sollte strukturell analog zu CDA übermittelt werden (siehe: http://wiki.hl7.de/index.php?title=IG:%C3%9Cbermittlung_onkologischer_Daten#Section:_Todesursache)
• Sollte auch auf andere Primär-Erkrankungen (z.B. HIV) übertragbar sein.

Coverage

• Wurde auf WGM komplett überarbeitet, neue Spezifikation noch nicht online, aber Beispiele verfügbar: http://wiki.hl7.de/index.php?title=FHIR-Kritzelblock_Versicherungsverh%C3%A4ltnisse
• Bitte an alle: Drüberschauen und kommentieren!

weitere Fragen/Themen

• Frage von Uwe: wohin ist die DSTU1-Resource "Alert" verschwunden? Übergegangen in Communication?

-> Teilnahme an PC workgroup TelKos/Listserv empfehlenswert, um an der Diskussion teilzunehmen.

Teilnehmer (Tba)

• Simone Heckmann (Health-Comm)
• Klaus Urban (Frey)
• Patrick Werner (Hochschule Heilbronn)
• Stefan Lang (Lang-HITC)
• Silvan Pollozek
• Tobias Hartz (Ärztekammer Niedersachsen, Projektgruppe "Gründung des KKN (Klinisches Krebsregister Niedersachsen)"
• Uwe Meyer (MT2IT)
• Salima Houta (ISST)

Nächste Termine

Fr., 19. Februar 2016, 11:00h

Agendapunkte für das nächste Treffen

• siehe TODOs aus dem Protokoll