Projekt-Arbeit FHIR-Basis-Profilierung TelKo vom 05.01.2016
Dieses Dokument gibt wieder:
Agenda Projekt-Arbeit FHIR-Basis-Profilierung TelKo vom 05.01.2016 (1.0). Die Teilmaterialien gehören der Kategorie iopfp an. |
Inhaltsverzeichnis
Veranstaltungsort und -zeiten
TelKo vom 05.01.2016
vorgesehene Agenda
- Aktuelle Themen FHIR international
- Change Requests
- Extensions
Protokoll
Aktuelle Themen FHIR international
- http://FHIR.org als Heimseite für die FHIR Implementer Community gestartet.
- Aufruf von G. Grieve an die internationalen Affiliates, verstärkt ihre Interessen wahrzunehmen, um die Dominanz Amerikanischer Interessen zu verhindern
- aktive Diskussionsthemen:
- OrderEntry: POST Order als FYI/Archiving vs. Action request.
Wer Interesse hat, sich zu beteiligen -> http://wiki.hl7.org/index.php?title=FHIR_Workflow
- Modellierung komplexer Observations (Related/Contained/Components) insbesondere im Bereich Mikrobiologie
Eventuell auch für Onkologie relevant? (TNM)
- neue Tools:
- Notepad++ PlugIn
- ValueSet Editor
- FHIRPath als Alternative zu XPath um Elemente innerhalb einer Resource zu referenzieren.
- Informationen zum kommenden 11. Connectathon in Orlando
Change Requests
- Item 9138: Add "PI" and "VN" to Identifier.Type Code
Status: Triaged
Rückfrage von Lloyd McKenzie via Tracker vom 24.12.2015: What's the difference between patient internal identifier and medical record number? (Agree on VN)
Diskussion: Semantisch sind der üblicherweise als "PID" bezeichnete systeminterne Patienten-Identifikator und die "Medical Record Number" äquivalent. Es ist lediglich eine Umstellung im Sprachgebrauch.
Kommentar von Lloyd McKenzie via Skype vom 5.1.2016:
For us to add additional codes, we'd need the following:
- concept has to exist in multiple countries and be consistently understood in all countries where it appears
- concept has to be orthogonal to the existing codes. I.e. No implementer should have to wonder whether they should use code A or B for a given identifier
- concept has to provide business value (i.e. you need to look at the type to figure out what to do with the identifier)
PI seems to fail on #2 and VN seems to fail on #3, so that's what would need to be addressed for us to add the concepts to the "official" code set. Locally, you can supplement with whatever you wish, though you'd be well advised to only break rule #1 when you do that.
- Item 9115:BIN as Coverage attribute should be moved to extension or identifier
Status: Triaged
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)
Beruf
Name:Beruf
Datentyp:CodableConcept
Binding: Codesystem der Bundesagentur für Arbeit?
Nachtrag vom 9.1.: Ergebnis der Recherche von Hr. Hartz:
- Die neuen klinischen Krebsregister nach KFRG, die derzeit überall im Land entstehen, erfassen den Beruf nicht. Ist somit kein Teil des ADT/GEKID-Datensatzes.
- In der epidemiologischen Krebsregistrierung wurde nach dem alte (Bundes-) Krebsregistergesetz KRG von 1995 zurückgehend der Beruf erhoben, aktuell aber anscheinend in der Regel nicht mehr.
- Genutzter Katalog: KldB 2010 (Klassifikation der Berufe von 2010) [weitere Infos siehe Anhang und http://statistik.arbeitsagentur.de/nn_10414/Statischer-Content/Grundlagen/Klassifikation-der-Berufe/KldB2010/Systematik-Verzeichnisse/Systematik-Verzeichnisse.html]
Staatsangehörigkeit
Es gibt bereits die Core-Extensions
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
Todesursache
vermutlich eher als Flag an Observation zu sehen
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?
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!?
ValueSet Binding
TODO: Beispiel für Binding an ICD 10-GM mit Jahresversion erarbeiten
- Namespace-URL Vorschlag: https://www.dimdi.de/icd10-gm
- Version-ID: 2015, 2016...
- Dynamisches versionsspezifisches Binding ???
- evtl. mit FHIRPath möglich? : "Observation.Code.Coding.Version must be equal to the year portion of Observation.Encounter.Period.start IF the Observation.Code.Coding.System.value = ICD-10-GM" ???
- Was ist mit weiteren Regeln wie geschlechtsspezifischen/abhängigen/ausgeschlossenen Codes???
- Was ist das ausschlaggebende Datum für die korrekte Version?
- Observation.effective
- Observation.issued
- Observation.Encounter.Period.start
- Beispiel (Instanz):
<Observation>
...
<code>
<coding>
<system value = "https://www.dimdi.de/icd10-gm"/>
<version value = "2016"/>
<code value = "H44.5" />
<display value = "Absolutes Glaukom" />
</coding>
</code>
...
</Observation>
oder besser:
<Observation>
...
<code>
<coding>
<system value = "https://www.dimdi.de/icd10-gm-2016"/>
<version value = "1"/>
<code value = "H44.5" />
<display value = "Absolutes Glaukom" />
</coding>
</code>
...
</Observation>
Nachtrag vom 9.1.: Anmerkung von S. Lang
Eine Anmerkung noch zum ICD-10:
Genau genommen ist die jährliche ICD-10-GM-"Version" jeweils ein komplett neues Codesystem, da sich auch die Bedeutung bestehender Codes ändern kann (Beispiel: Veränderung der Bedeutung von "sonstige", wenn ein neuer Code hinzukommt). Das spiegelt sich auch darin wider, dass jeweils eine neue code system OID vergeben wird.
Insofern wäre es konsequent, den Namespace analog zu benennen (also z.B. ".... /icd-10-gm/2016") und version bei Bedarf für eventuelle unterjährige Errata/Addenda zu benutzen.
TODO: Klärung mit HL7 international, da es nicht um ein spezifisch "Deutsches" Problem handelt. Tracker item #9196
Coverage
TODO: V2 Beispieldaten in FHIR mappen und analoge Abbildungen für V2, CDA und FHIR im Wiki gegenüberstellen. (Ideal wäre eine separate Wiki-Seite mit den Beispielszenarien und den entsprechenden Abbildungen (Repräsentationen) in den Standards wie bspw. HL7 v2, V3/CDA und FHIR.)
Teilnehmer
- Simone Heckmann (Health-Comm)
- Bettina Lieske (SAP)
- Klaus Urban (Frey)
- Patrick Werner (Hochschule Heilbronn)
- Stefan Lang (Lang-HITC)
- Mike Kulisch (Fraunhofer)
- Ben Krausmann (Fraunhofer Fokus)
- Tobias Hartz (Ärztekammer Niedersachsen, Projektgruppe "Gründung des KKN (Klinisches Krebsregister Niedersachsen)"
- Uwe Meyer (MT2IT)
- Frank Oemig (DTHS)
Nächste Termine
19.1.2016 14:00h GoTo-Meeting
Agendapunkte für das nächste Treffen
- siehe TODOs aus dem Protokoll