FHIR Chat · Patient Basisprofil · german (d-a-ch)

Stream: german (d-a-ch)

Topic: Patient Basisprofil

Simone Heckmann (Sep 01 2016 at 07:28):

Wir hatten in der bisherigen Diskussion zwei Constraints für ein Patient-Basisprofil identifiziert:

• Eine Extension für die Hausnummer und
• Einen Identifier-Slice für die GKV-Nummer des Patienten
  für ersteres gibt es jetzt hier eine Standard-Extension, die ich für geeignet halte: http://hl7-fhir.github.io/extension-iso21090-adxp-housenumber.html für letzteres habe ich mal gemäß der präferierten Konvention eine NamingSystem-Resource skizziert: https://simplifier.net/FHIRABENDSandbox/gesetzlichekrankenversichertennummer

Kommentare und weitere Anforderungen für ein Basis-Profil bitte hier eingeben.

Peter Scholz (Sep 02 2016 at 06:55):

Hab ich da was verpasst,
wo zum Teufel brauchen wir denn die Hausnummer gesondert von der Strasse ?

Stefan Lang (Sep 02 2016 at 07:20):

Das kam aus der ersten(?) Telko.
Viele Meldeverfahren wollen die Hausnummer separat, z.B. Krebsregister oder DMP

Patrick Werner (Sep 02 2016 at 08:21):

ich sehe auch keinen Mehrwert in einer separaten Hausnummer. Aber wenn man es eben Register gibt die das seperat benötigen finde ich ein separates Feld besser als regex expressions die für Register oder DMP die Adress.line wieder auseinanderpflücken

Stefan Lang (Sep 02 2016 at 08:34):

Exakt. Wobei das in der Praxis die nötige RegEx oft nur vom Empfänger zum Sender verschiebt.
In diesem Fall würde ich einfach sagen: wir gehen davon aus, dass sich die Register etwas dabei gedacht haben, und in anderen Use Cases kann man die Extension ja weglassen.

Patrick Werner (Sep 02 2016 at 08:38):

in manchen Usecases weglassen, in manchen Extension dazu klingt für mich nicht nach einem deutschen Basisprofil

Stefan Lang (Sep 02 2016 at 08:45):

Im Sinn von "extend when needed" hast Du Recht.
Die Extension ins Basisprofil reinzupacken und in konkreten Profilen auszuschließen, wäre wohl eher CDA-Stil.
Evtl. einfach ein (textueller) Verweis im Basisprofil, dass es die Extension gibt und man sie im Zweifel benutzen kann?

Simone Heckmann (Sep 02 2016 at 08:45):

Ich denke, das BASIS-Profil darf gar keine Vorschriften über Pflichtfelder machen, da wir ja den konkreten UseCase gar nicht kennen. Warum soll ein Notfallpatient, der überhaupt keine Adressdaten hat nicht auch gegen das BASIS-Profil validieren?
Ich sehe das BASIS-Profil gewissermaßen als Sammlung von Optionen der Art:

• Wenn der UseCase explizite Hausnummern erfordert, dann nimm DIESE Extension
• Wenn der UseCase GKV-Nummern erfordert, dann nimm DIESES NamingSystem
• Wenn der UseCase einen Typisierung der Organization erfordert, dann nimm DIESES ValueSet
  etc. pp.

Welche dieser Optionen dann konkrete Pflichtfelder sind, das kann nur UseCase-spezifisch entschieden werden.

Simone Heckmann (Sep 02 2016 at 08:47):

@Stefan Lang Eine Notwendigkeit, die Basis-Extensions in konkreten Profilen wieder auszuschließen sehe ich eigentlich nicht. Es tut ja keinen Schaden, wenn die Hausnummer in der Adresszeile UND der Extension angegeben wurde. Extensions ignorieren kann man ja immer...

Stefan Lang (Sep 02 2016 at 08:51):

OK, Definition eines (deutschen) Basis-Profils (zwecks semantischer Interoperabilität innerhalb der DACH-FHIR-Community ;-):

Ein Basisprofil enthält alles, was in Deutschland vorkommen kann und ist somit nur einschränkbar. Werden Erweiterungen benötigt, die nicht im Basis-Profil enthalten sind, dann wird auch das Basis-Profil erweitert.

Patrick Werner (Sep 02 2016 at 08:55):

wenn ich die Hausnummer in Adress.line habe + zusätzlich in einem Hausnummernfeld habe ich doch wieder das gleich Problem. Zum Übermitteln an die Register muss ich die Hausnummer aus line entfernen.
Evtl. sollte die Extension 2 Felder enthalten: Straßenname & Hausnummer. Zusammen kann das dann in line stehen,
Das wäre dann analog zu HumanName mit HumanName.text für den ganzen Namen und extra Feldern für Vor und Nachnamen.

Stefan Lang (Sep 02 2016 at 09:03):

Klingt konsistent.
Dann ist es allerdings keine Hausnr.-Extension mehr, sondern eine "physicalAddress"-Extension

Patrick Werner (Sep 02 2016 at 09:07):

Stefan Lang (Sep 02 2016 at 09:15):

... aber die Straße muss optional sein. Es gibt da ein paar Orte in Bayern, wo es nur Ortsnamen und Hausnr. gibt ;)

Simone Heckmann (Sep 02 2016 at 09:16):

http://hl7-fhir.github.io/extension-iso21090-adxp-streetname.html

Simone Heckmann (Sep 02 2016 at 09:16):

auch nützlich: http://hl7-fhir.github.io/extension-iso21090-adxp-postbox.html

Stefan Lang (Sep 02 2016 at 09:17):

Dann nehmen wir einfach diese 3 Extensions ins Profil auf und fertig. Right?

Simone Heckmann (Sep 02 2016 at 09:21):

Ich denke, in den meisten Fällen genügt die Standard-Adressline und da sollten IMMER ALLE Informationen, die zur Adresse bekannt sind, drin stehen (Straße, Hausnummer, Postfach, c/o). Das müssen wir ganz klar herausstellen. Wenn der UseCase eine weitere Differenzierung erfordert, dann mit den benannten Extensions. Aber das auch nur dann, wenn das wirklich UNVERZICHTBAR ist. Wir wollen den Client-Entwicklern damit nicht das Leben schwer machen, wo es gar nicht sein muss...

Stefan Lang (Sep 02 2016 at 09:23):

Genau

Simone Heckmann (Sep 02 2016 at 09:23):

Ich meine mich zu erinnern, dass die Differenzierung der Adresse beim Krebsregister zwar im Datensatz vorgesehen ist, aber in der Praxis meist gar nicht geschieht, da die Quellinformationen überwiegend undifferenziert vorliegen. Also vielleicht wäre sogar dort die Verwendung der Extensions optional??

Stefan Lang (Sep 02 2016 at 09:27):

Das kam von Tobias. Es gibt allerdings auch Register, die das anders sehen ;-)
Ich denke, für die Basis reicht es und ist nicht schädlich, das detaillierter (und sowieso optional) vorzusehen.
Wenn und falls es dann ein Krebsregister-Profil gibt, muss dann die Fachseite was dazu sagen. Aber zum Thema KR-Schnittstellen ist erstmal auf dem Interop-Forum bzw. Ende September überhaupt das Kickoff-Meeting

Simone Heckmann (Mar 21 2017 at 19:12):

Da STU3 nun final ist, müssen wir mit dem Basis-PROFIL zwar noch warten, bis das Tooling nachgereift ist, aber wir könnten uns schon mal Beispiele überlegen!

Simone Heckmann (Mar 21 2017 at 19:13):

Ich versuche mal, den Aufschlag zu machen mit einem Patienten, der Extensions für Straße und Hausnummer hat.

Stefan Lang (Mar 21 2017 at 19:14):

Tendenziell würde ich gern für uns ein allumfassendes Beispiel machen, das dann für den Leitfaden auf einzelne Teile runtergebrochen werden kann.

Simone Heckmann (Mar 21 2017 at 19:18):

Japp! Wir können ja Klötzchen bauen, die wir dann zu einem Beispiel zusammensetzen. Ich fange einfach mal mit dem Adress-Fragment an.
Es gibt inzwischen ISO-Standard-Extensions für das "Herunterbrechen" der Adresse:
http://build.fhir.org/datatypes-extras.html#Address
Ich denke, was wir brauchen ist houseNumber und streetName.

Stefan Lang (Mar 21 2017 at 19:19):

Korrekt

Simone Heckmann (Mar 21 2017 at 19:37):

<address>
    <!--zur Differenzierung, falls Heim- und Arbeitsplatz-Adresse angegeben werden-->   
    <use value="work"/>
    <line value="An der Schanz 1">
        <!--optional zusätzlich die Strukturierte form der Adress-Zeile-->
        <extension>
            <url value= "http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetName"/>
            <valueString value="An der Schanz"/>
        </extension>
        <extension>
            <url value= "http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber"/>
            <valueString value="1"/>
        </extension>
    </line>
    <city value= "Köln"/>
    <postalCode value= "50735"/>
        <!-- zweistellige ISO-3166-Ländercodes-->
    <country value= "DE"/>
</address>

Simone Heckmann (Mar 21 2017 at 19:55):

hier mal die Zusammenfassung dessen, was wir bisher zum Identifier haben:

    <identifier>
        <!--gesetzliche Krankenversichertennummer-->
        <system value= "http://fhir.de/NamingSystem/gkv/kvnr"/>
        <value value="I939216643"/>
    </identifier>
    <identifier>
        <!--PatientenID im Krankenhaus "MusterKlinik"-->
        <type>
            <coding>
                <system value="http://hl7.org/fhir/v2/0203"/>
                <code value="MR"/>
            </coding>
        </type>
        <!--eindeutiger Namespace des Identifiers-->
        <system value= "http://musterklinik.de/identifier/patienten"/>
        <!--PID-->
        <value value="123456"/>
    </identifier>

Simone Heckmann (Mar 21 2017 at 19:57):

Da war noch die Frage nach dem Discriminator offen....! Evtl. brauchen wir für die KVNR auch einen Type-Code.

Simone Heckmann (Mar 21 2017 at 19:59):

Slicing-Experte @Patrick Werner ? :)

Patrick Werner (Mar 22 2017 at 08:16):

gesliced würde das Ganze dann so:

 <element>
            <path value="Patient.identifier" />
            <slicing>
                <discriminator value="type.coding.system" />
                <ordered value="false" />
                <rules value="open" />
            </slicing>
            <min value="1" />
            <max value="*" />
</element>

Patrick Werner (Mar 22 2017 at 08:20):

Und das KVNR Slice dann so:

<element>
           <path value="Patient.identifier.system" />
           <name value="Krankenversichertennummer" />
           <min value="1" />
           <max value="1" />
           <fixedUri value="http://fhir.de/NamingSystem/gkv/kvnr" />
 </element>

Stefan Lang (Mar 22 2017 at 08:24):

Im Basisprofil bitte 0..1 ;-)
Und: dürfen wir anhand des system slicen?
Wie könnte man dann in einem abgeleiteten Profil eine interne Pat-ID auf 1..1 bzw. 1..* setzen?

Stefan Lang (Mar 22 2017 at 08:25):

Daher die Frage nach dem type

Simone Heckmann (Mar 22 2017 at 08:35):

Ah! Man kann den Discriminator pro Slice definieren? Ich dachte, man bräuchte ein einheitliches Kriterium über alle Slices hinweg.

Stefan Lang (Mar 22 2017 at 08:37):

Nee, der ist global. Patricks erster Codeblock ist die Klammer, der zweite Block der bisher einzige Slice

Stefan Lang (Mar 22 2017 at 08:39):

Äh, nee, hä?
<discriminator value="type.coding.system" /> <====> <path value="Patient.identifier.system" /> ?

Simone Heckmann (Mar 22 2017 at 08:40):

Ich glaube, wir brauchen mal einen Workshop "Slicing für Muggles" :D

Stefan Lang (Mar 22 2017 at 08:40):

Patrick, sicher, dass das kein Copy & Paste Fehler ist? ;-)

Patrick Werner (Mar 22 2017 at 08:40):

ja man darf und kann anhand des systems slicen

Patrick Werner (Mar 22 2017 at 08:41):

der erste snippet definiert slicing auf Patient.identifier mit dem disc. coding.system

Patrick Werner (Mar 22 2017 at 08:42):

Die Kardinalität hier gilt für alle Slices, im Slice kann dann auch die Kard. des Slices definiert werden

Stefan Lang (Mar 22 2017 at 08:43):

Identifier.type.coding.system !== Identifier.system ?

Patrick Werner (Mar 22 2017 at 08:43):

ah und ja @Stefan Lang das erste ist die klammer, das zweite ein slice

Patrick Werner (Mar 22 2017 at 08:45):

Und Identifier.system ist das richtige disc. Feld. Hatte ich mich mal verklickt

Patrick Werner (Mar 22 2017 at 08:52):

Wenn man dann ein sclicendes Profil von einem geslictem Profil ableitet muss man reslicen

Patrick Werner (Mar 22 2017 at 08:53):

https://www.hl7.org/fhir/profiling.html#reslicing
Also würde man für ein KH Profil einfach ein 1..1 Slice mit dem internen Identifier hinzufügen

Simone Heckmann (Mar 24 2017 at 11:04):

Den internen Identifier können wir ja schon im Basis-Profil vor-slicen, den wird man in 99% der Fälle brauchen.
Wir geben lediglich die identifier.system-url nicht fest vor. Da kann jeder machen, was er will. Kardinalität könnten wir auch auf 0..* lassen.

Simone Heckmann (Mar 24 2017 at 11:06):

...bräuchten wir also einen Code für identifier.type = KVNR, korrekt?

Stefan Lang (Mar 24 2017 at 14:00):

Genau

Patrick Werner (Mar 27 2017 at 15:23):

Ja Identifier type KVNR wird benötigt. Für den internen Identifier sind hier ja die existenten typen gelistet:
https://www.hl7.org/fhir/valueset-identifier-type.html

Patrick Werner (Mar 27 2017 at 15:24):

Hier fehlt noch der Type "KIS intern" oder so ähnlich

Patrick Werner (Mar 27 2017 at 15:25):

Dann könnten wir tatsächlich den type slicen, KVNR, KIS intern, und evtl. passport number (für ausländische Patienten)

Stefan Lang (Mar 27 2017 at 18:33):

Für "KIS intern" war ja "MR" angedacht, aber das ist in der deutschen Interpretation der v2 Table 0203 mit "Krankenaktennummer" beschrieben - tendenziell kein Identifier für den Patienten, eher für den Encounter (oder die Episode Of Care? Sollten wir in dem Kontext klären ;-)

Simone Heckmann (May 08 2017 at 14:53):

Hallo,
wir haben nun ein STU3 Patient-Basis-Profil für DE.
Features:

• Es gibt vordefinierte Identifier-Slices für die gesetzliche Versichertennummer und lokale PIDs
• Die für die vollständige Abbildung des Namens im VSDM-Format erforderlichen Extensions sind integriert
• Die erforderlichen Extensions für die Differenzierung von Straße und Hausnummer sind in der Adresse enthalten
  Das Profil gibt es hier zur Kommentierung/Testimplementierung: https://simplifier.net/BasisprofilDE/patient-de-basis/rendered
  Beispiele: https://simplifier.net/BasisprofilDE/patient-de-basis/examples

Alle in Deutschland verwendeten Profile für spezielle UseCases sollten von diesem Basis-Profil abgeleitet sein.

Simone Heckmann (Jun 13 2017 at 09:53):

@Christof Gessner : <---hier--->
:D

Simone Heckmann (Jun 13 2017 at 10:28):

Ich zitiere hier mal Christof, damit wir das im richtigen Kanal weiterdiskutieren können:

Hier ein Vorschlag zur Krankenversichertennummer in https://simplifier.net/BasisprofilDE/patient-de-basis
Short Description: KVNR
Definition: Die KVNR ist der unveränderbare Teil der Krankenversichertennummer nach § 290 SGB V. Dieser Teil der Krankenversichertennummer hat 10 Stellen. Die KVNR dient der Identifikation des Versicherten. Die elektronische Gesundheitskarte nach § 291 SGB V enthält neben anderen Angaben auch die KVNR.
Unter type/coding/code sollte meines Erachtens nicht "HC" stehen, sondern besser "NI" oder "NH" oder "NNDEU". Begründung: es handelt sich nicht um die "Kartennummer der Karte", die ist nämlich auf der Rückseite der Karte aufgedruckt.

Simone Heckmann (Jun 13 2017 at 10:31):

Ich könnte mit NH auch gut leben.

Peter Scholz (Jun 13 2017 at 10:40):

HC kennzeichnet nicht die Kartennummer sondern die Krankenversichertennumer nach eGK, dies ist seit jahren bereits schon der verwendete TypeCode in V2 und wir sollten den unter allen Umständen in FHIR konsistent verwenden.
Von daher nein, kein anderer TypeCode

Simone Heckmann (Jun 13 2017 at 10:41):

Stimmt, daher hatten wir ja auch den Code aus dem v2-ValueSet gefischt: https://simplifier.net/BasisprofilDE/patient-identifier-type-de-basis

Stefan Lang (Jun 13 2017 at 10:42):

sic!
Von daher pro "HC"

Simone Heckmann (Jun 13 2017 at 10:43):

...aber wenn das in V2 falsch gemacht wurde, dann hätten wir jetzt die Chance, das zu korrigieren. Es ist ja nicht wegzuleugnen, dass "HC" für "Health Card Number" steht...

Peter Scholz (Jun 13 2017 at 10:46):

Wir hatten damals einen eigenen TypeCode beantragt, FM hat das mit Verweis auf HC abgelehnt.
Alle existierenden Implementierungen beruhen nun darauf, von daher sollte der Wert bleiben wie er ist und auch in den offiziellen deutschen Nachrichtenprofilen für V2 definiert ist.

Simone Heckmann (Jun 13 2017 at 10:50):

Ähem, ich glaube, die Anzahl der existierenden V2 Implementierungen, die die KVNR mit einem Type Code versehen ist ...überschaubar.

Simone Heckmann (Jun 13 2017 at 10:57):

Die Tatsache, dass es im internationalen Standard keinen passenden TypeCode gibt, halte ich für unkritisch. Worin bestünde das Interesse, die KVNR über die Landesgrenze hinweg interoperabel kommunizieren zu wollen?

Stefan Lang (Jun 13 2017 at 15:45):

Rekapitulation:
"HC" hatten wir auch gerade deshalb gewählt, weil es in den deutschen v2-Profilen bereits vorkommt und als "eGK/KVK" definiert ist:
http://wiki.hl7.de/index.php?title=HL7v2-Profile_gemeinsame_Elemente
"NH", "NI" und "NNxxx" (alias: "NNDEU") gibt es dort nicht.
Keiner dieser vier Codes hat es ins FHIR-ValueSet geschafft:
https://www.hl7.org/fhir/valueset-identifier-type.html

Stefan Lang (Jun 13 2017 at 15:56):

Nebenbemerkung: eigentlich haben wir type.code nur deshalb einen solchen Stellenwert gegeben, um für das Slicing einen sauberen Diskriminator zu haben. Aber was spricht im Grunde dagegen, identifier.system als Diskriminator zu verwenden?

Peter Scholz (Jun 13 2017 at 16:31):

Ich bin grade noch einmal dabei, die uralte historie zu durchforsten,

Peter Scholz (Jun 13 2017 at 16:44):

und tatsächlich sind die gemeinsamen Nachrichtenprofile da unpräzise
HC ist in der Tat nicht die unveränderliche Versichertennummer, sondern die Nummer der EGK
NII ist die IK Nummer der Kasse
NIIP ist die VKNR

und somit fehlt uns die KVNR
wenn wir aufs System gingen wäre das einfacher
dann brauchen wir nur 2 sytems: OID 1.2.276.0.76.4.8(10 stellen) = lebenslange Versichertennummer, 1.2.276.0.76.4.1 komplette Versichertennr. (30stellen). Für die Versichertennummer brauchten wir da ja in V2 keinen Diskriminator da diese dort nur im GKV Fall vorkommt und ein eigenes Feld hat. Wogegen die IK Nummer der Kasse wie die VKNR beide in IN1-3 vorkommen und wir daher einen type code brauchten.

HC ist tatsächlich dort auch nicht in Verwendung.

Aber jetzt kommt auch das entscheidende: In V2 hatten wir bisher keinen Identifier bei Selbstzahlern und PKV

Peter Scholz (Jun 13 2017 at 16:51):

Ich frage mich allerdings auch warum wir überhaupt die KVNR als Identifier für den Patienten ins deutsche Basis Profil übernehmen sollen.
Meines Erachtens ist die da nicht richtig aufgehoben.

Stefan Lang (Jun 13 2017 at 16:56):

Aufgenommen als Identifier wurde sie, weil sie eben lebenslang den Patienten identifiziert, faktisch unabhängig vom jeweils aktuellen (GKV-)Versicherungsverhältnis.

Stefan Lang (Jun 13 2017 at 16:58):

Wenn seinerzeit mit "HC" tatsächlich die Nummer der Karte gemeint war, dann wäre HC an dieser Stelle tatsächlich falsch.

Stefan Lang (Jun 13 2017 at 17:01):

Eingeführt haben wir den Type Code (neben der Diskriminator-Begründung) auch, weil wir als Use Case folgendes identifiziert hatten:
"Suche mir alle Patienten, die gesetzlich|privat versichert sind".

Stefan Lang (Jun 13 2017 at 17:08):

Insofern erscheint mir der Type Code dann doch wieder wichtig.
Verbleiben also folgende Optionen:
1) v2 Table 0203, NH - National Health Plan Identifier: "Class: Insurance<p>Used for the UK NHS national identifier. In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions."
2) v2 Table 0203, NI - National unique individual identifier: "Class: Insurance In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions."
3) v2 Table 0203, NNxxx (NNDEU) - National Person Identifier where the xxx is the ISO table 3166 3-character (alphabetic) country code
4) was eigenes, z.B. "GKV", in Anlehnung an das existierende "PKV" in unserem Value Set

Simone Heckmann (Jun 13 2017 at 17:22):

Identifier.system geht nicht als discriminator, weil wir bei unserem zweiten Slice, dem (internen) Identifier, das System nicht kennen.

Stefan Lang (Jun 13 2017 at 17:23):

Das war der Hintergedanke, richtig. Und ein leerer Discriminator wäre böse.

Simone Heckmann (Jun 13 2017 at 17:24):

Ich finde die KVNR als Patient.identifier schon sinnvoll, um einen Patienten einrichtungsübergreifend zu reidentifizieren. Ist sicher auch für die meisten MPI-Systeme ein relevantes Kriterium für's Matching

Stefan Lang (Jun 13 2017 at 17:25):

Jup, MPI (natürlich immer im Kontext des geltenden Datenschutzes ...) ist ein absolutes Pro-Argument

Stefan Lang (Jun 13 2017 at 17:41):

NNDEU finde ich nicht so sinnvoll, denn "deutsch" ist für mich keine Eigenschaft eines Identifier-Typs sondern des Identifier-Systems.

Peter Scholz (Jun 13 2017 at 17:42):

Wenn wir einen Type Code nehmen, dann am ehesten was eigenes das verhindert Verwechslungen.
Nur ist die KVNR nichts was die Person wirklich identifiziert denn a) nur GKV Patienten haben eine, somit für MPI nur bedingt nutzbar

Stefan Lang (Jun 13 2017 at 17:45):

Die KVNR ist eine eindeutig identifizierende Eigenschaft des Patienten.
Es hat auch nicht jeder Patient eine PID aus dem Klinikum X, trotzdem ist diese ein Identifier.

Stefan Lang (Jun 13 2017 at 17:46):

Im MPI-Kontext kann sie nicht das alleinige Merkmal sein, richtig. Aber für Matching-Prozesse trotzdem eine elementare Information. Ca. 93% der Patienten müssen diesen Identifier besitzen.

Peter Scholz (Jun 13 2017 at 17:47):

wir müssten dann definitiv die 10stellige unveränderliche KVNR nehmen
die 30stellig ist zu variabel

Stefan Lang (Jun 13 2017 at 17:47):

Das (= 10-stellige Nr.) ist ja m.W. auch die, die eigentlich immer kommuniziert wird und in der GKV-Abrechnung relevant ist

Peter Scholz (Jun 13 2017 at 17:48):

denke ich auch. Hat jemand noch mal auf die Schnelle einen Link auf die XML Spezifikation der aktuellen eGK Version

Stefan Lang (Jun 13 2017 at 17:49):

https://www.gematik.de/cms/de/spezifikation/wirkbetrieb/release_0_5_2/release_0_5_2_fachanwendung/release_0_5_2_fachkonzeptvsdm.jsp

Peter Scholz (Jun 13 2017 at 17:53):

Also: der zehnstellige unveränderliche teil der Krankenversichertennr heisst offziell VersichertenId
daher mein Vorschlag für typeCode EGK_VID

Stefan Lang (Jun 13 2017 at 17:55):

wenn, dann VSDM_VID ;-)))

Peter Scholz (Jun 13 2017 at 17:56):

gekauft

Simone Heckmann (Jun 13 2017 at 18:04):

Ich habe darüber heute auch mit Christof gesprochen. Seiner Meinung nach:
10-stellig (VID) = Patient.identifier
30-stellig (bezeichnung?) = Coverage.identifier

Peter Scholz (Jun 13 2017 at 18:05):

30stellig = Krankenversichertennummer

Simone Heckmann (Jun 13 2017 at 18:14):

Meinem Gefühl nach identifizieren die ersten 10 Ziffern unveränderlich die Person (=den Versicherten), die gesamten 30 Stellen jedoch die (veränderliche) Police dieser Person bei einer konkreten Versicherungsanstalt, daher hätte ich jetzt eher die 10-stellige als die Versichertennummer bezeichnet und die 30-stellige als Versicherungsnummer...?

Peter Scholz (Jun 13 2017 at 18:17):

Das mag sein das Du das so gemacht hättest aber die 30stellige ist eben genau die Krankenversichertennummer nach §290 SGB V, die hat der Gesetzgeber genau so genannt, und damit heisst sie so (ob das sinnig ist oder nicht ist dann irrelevant)

die 10stellige wurde im Fachkonzept VSDM Versicherten_Id getauft und heiss somit auch leider so wie sie heisst.

Peter Scholz (Jun 13 2017 at 18:19):

"Die Krankenkasse verwendet für jeden Versicherten eine Krankenversichertennummer. Die Krankenversichertennummer besteht aus einem unveränderbaren Teil zur Identifikation des Versicherten und einem veränderbaren Teil, der bundeseinheitliche Angaben zur Kassenzugehörigkeit enthält und aus dem bei Vergabe der Nummer an Versicherte nach § 10 sicherzustellen ist, dass der Bezug zu dem Angehörigen, der Mitglied ist, hergestellt werden kann. "

http://www.sozialgesetzbuch-sgb.de/sgbv/290.html

Simone Heckmann (Jun 13 2017 at 18:20):

Gott, gib mir Kraft...

Peter Scholz (Jun 13 2017 at 18:22):

Der hat nun so rein gar nichts mit dem deutschen Gesundheitswesen am Hut

Stefan Lang (Jun 13 2017 at 18:45):

"Der unveränderbare Teil - dabei handelt es sich um die eigentliche Krankenversichertennummer, die ausschlaggebend für alle Verfahren ist - ist einer bestimmten Person, dem Hauptversicherten oder einem mitversicherten Familienangehörigen, zugeordnet und begleitet ihn ein Leben lang. Dieser Teil der Krankenversichertennummer hat 10 Stellen. Der veränderbare Teil enthält Informationen über die Krankenkasse. Die 9-stellige Nummer ist das so genannte Institutionskennzeichen der Krankenkasse. Der Bezug eines Angehörigen zum Mitglied wird über einen weiteren Nummern-Teil hergestellt. Dieser ist 10 Stellen lang. Für den Fall, dass für den unveränderbaren Teil (Stelle 1 - 10) und die Kassenzugehörigkeit (Stelle 11 - 19) in bestimmten Anwendungen nur ein Datenfeld zur Verfügung steht, ist eine zusätzliche Prüfziffer (Stelle 20) erforderlich. Werden alle drei Bestandteile der Krankenversichertennummer in einem Datenfeld verwendet, kommt ebenfalls eine zusätzliche Prüfziffer (Stelle 30) zum Einsatz. "

Stefan Lang (Jun 13 2017 at 18:46):

Q: https://kvnummer.gkvnet.de/(S(otnah4vgdm2h1tbmryywg0si))/pubPages/krankenversichertennummer.aspx

Peter Scholz (Jun 13 2017 at 18:59):

Wir sollten einfach bei den offiziellen Begrifflichkeiten bleiben sonst wird die Verwirrung zu gross.
Und die lauten nun mal Versicherten_Id (10stellig) und Krankenversichertennummer (30stellig)
Und nicht was irgendwer anderes denkt wie was besser heissen könne.

Die Versicherten-ID ist der 10-stellige unveränderliche Teil der 30-stelligen Krankenversichertennummer.

Q: https://www.gematik.de/cms/media/dokumente/release_0_5_2/release_0_5_2_fachanwendungen/gematik_VSD_Fachkonzept_VSDM_V270.pdf

Simone Heckmann (Jun 13 2017 at 19:08):

ergo:
Versicherten-ID (10stellig) ---> http://fhir.de/NamingSystem/gkv/kvid ----> Patient.identifier.system
Versichertennummer (30stellig) ---> http://fhir.de/NamingSystem/gkv/kvnr ----> Coverage.identifier.system
?

Stefan Lang (Jun 15 2017 at 08:28):

Simones Vorschlag ist ja inzwischen bereits teilweise (für patient-de-basis) im Profil auf Simplifier eingeflossen.
Dabei haben wir u.a. auch den Slicing-Discriminator verändert.
Anmerkung meinerseits dazu: auch, wenn wir identifier.type.code nicht mehr für das Slicing brauchen, sollten wir für implementierungsspezifische Besonderheiten den identifier.type auch im Slice "VersichertenID_GKV" erlauben. Im Moment steht der auf 0..0

Simone Heckmann (Jun 16 2017 at 08:17):

Mal warten, was hier herauskommt:
https://chat.fhir.org/#narrow/stream/conformance/topic/Identifier.20slicing.20discriminator

Die Spezifikation lässt hier mit "SHOULD NOT" be used" eigentlich keinen Freiraum.
Wenn sie Spezifikation sagt: "Mach das nicht!", dann sollten wir dafür sorgen, dass es niemand macht.

Stefan Lang (Jun 16 2017 at 08:25):

Wenn die Spezifikation es komplett ausschließen wollte, gäbe es gar keinen identifier.type ;-)

Stefan Lang (Jun 16 2017 at 08:26):

Insofern würde ich die Spezifikation nicht härter interpretieren als sie sich selbst.

Simone Heckmann (Jun 16 2017 at 13:08):

In den niederländischen Profilen hat der National Identifier auch keinen Type (...nicht dass das jetzt für uns ausschlaggebend sein muss..)
https://simplifier.net/NictizSTU3/nl-core-patient

Simone Heckmann (Jun 16 2017 at 13:09):

Der DAF-Practitioner auch nicht: https://simplifier.net/DAF/daf-pract

Stefan Lang (Jun 16 2017 at 13:16):

d'accord, dass wir (Resource).identifier.type nicht spezifizieren. Aber offen lassen für Implementierer.
Also im Prinzip genau so, wie es bei Nictiz und DAF auch ist.

Simone Heckmann (Jun 19 2017 at 14:13):

done.

Simone Heckmann (Jun 29 2017 at 20:11):

Wenn man mal herausgefunden hat, wie's geht, macht constrainen richtig Spaß
Folgende für HumanName:
hum-1: Wenn die Extension 'namenszusatz' verwendet wird, dann muss der vollständige Name im Attribut 'family' angegeben werden
(FhirPath: family.extension('http://fhir.de/StructureDefinition/humanname-namenszusatz').empty() or family.hasValue())
hum-2: Wenn die Extension 'nachname' verwendet wird, dann muss der vollständige Name im Attribut 'family' angegeben werden
(FhirPath: family.extension('http://hl7.org/fhir/StructureDefinition/humanname-own-name').empty() or family.hasValue())
hum-3: Wenn die Extension 'vorsatzwort' verwendet wird, dann muss der vollständige Name im Attribut 'family' angegeben werden
(FhirPath: family.extension('http://hl7.org/fhir/StructureDefinition/humanname-own-prefix').empty() or family.hasValue())
hum-4: Wenn die Extension 'prefix-qualifier' verwendet wird, dann muss ein Namenspräfix im Attribut 'prefix' angegeben werden
(FhirPath: prefix.extension('http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier').empty() or prefix.hasValue())

Fehlt noch was?

Stefan Lang (Jun 29 2017 at 20:24):

Passt m.E.

Simone Heckmann (Jun 29 2017 at 20:33):

Ist damit https://github.com/hl7germany/basisprofil-de/issues/11 erledigt? oder hat VSDM noch weitere Constraints?

Stefan Lang (Jun 29 2017 at 20:36):

Issue 11 kann zu. Was das Nachziehen patient-de-vsdm betrifft, gehört das imho zu Issue 10

Simone Heckmann (Jun 29 2017 at 20:40):

ok, geschlossen.

Simone Heckmann (Jun 29 2017 at 20:41):

Verwegener Gedanke: In Form von WARNING-Constrints lassen sich allerlei Best-Practice-Ratschläge in den Profilen verankern!

Stefan Lang (Jun 29 2017 at 20:43):

Uh, lass mal - Wir wollen doch, dass von diesen Profilen abgeleitet wird. D.h. im Wunsch-Fall tauchen diese Ratschläge dann im Produktivbetrieb auf, wenn ein Implementer sie begründet ignoriert hat...

Mathias Aschhoff (Jun 29 2017 at 20:44):

Aber für Schulungszwecke sicher richtig cool. Behalt die Idee mal im Hinterkopf

Stefan Lang (Jun 29 2017 at 20:51):

Jup, man könnte ja "xxx-de-basis-forStarters" ableiten :)

Stefan Lang (Jun 29 2017 at 21:06):

https://github.com/hl7germany/basisprofil-de/issues/12 kann doch damit auch zu, oder?

Simone Heckmann (Jun 29 2017 at 21:10):

Ha jo!
Weg damit.

Stefan Lang (Jun 29 2017 at 21:11):

14 open, 3 closed :D

Simone Heckmann (Jun 30 2017 at 10:32):

...und soeben ist das Deutsche ValueSet für maritalStatus um einen Code kleiner geworden

Simone Heckmann (Jun 30 2017 at 10:41):

#ehefüralle

Simone Heckmann (Jul 04 2017 at 08:23):

ich tu meinen letzten Stand der Diskussion im TCS, die ich mit der Absicht angestoßen hatte, herauszufinden, wie die eingetr. Lebenspartnerschaft bisher codiert wurde (es gibt nämlich keinen definierten Code dafür) der Vollständigkeit halber mal hierher:

Ich habe mal eine kurze nicht-repräsentative Analyse der HL7-Nachrichtenströme eines meiner Kunden gemacht und komme zur Feststellung, dass der Personenstand in der Tat äußerst selten erfasst wird. Auch die Bandbreite ist sehr gering:

Von 80.580 Orbis-Nachrichten waren
M=486
D=9
S=259
W=53
C/R/T/B/G/U=0

Das spricht für Jörgs Auffassung, dass der Personenstand ohne Bezug auf eine konkrete Person (Next of Kin) keine große Relevanz hat.
Und es erklärt, warum sich niemand bisher am Fehlen dieses Codes gestört hat.

In Bezug auf FHIR ergeben sich daraus zwei Optionen, den MaritalStatus zu kommentieren
a) eine Empfehlung, den maritalStatus nicht zu verwenden (Auf 0..0 constrainen würde ich nicht wollen. Dass man den Personenstand trotzdem erfasst hat, macht die Resource ja nicht ungültig) und statt dessen evtl. vorhandene "significant others" als Next of Kin zu erfassen. Zu wissen, dass es einen Partner gibt, ohne zu wissen, wie man diesen erreicht, hilft ja niemandem.
b) ein Hinweis, dass eingetragene Lebenspartnerschaften wie Ehen erfasst werden (weil es in diesem Kontext keinen Unterschied macht)

Ex post facto einen Code hinzuzufügen ist in der Tat wenig sinnvoll.

@Heike: Der Hinweis auf die Notwendigkeit einer Differenzierung bei z.B.  künstlicher Befruchtung ist sicher richtig, ich bezweifle jedoch, dass der administrativ erfasste Personenstand in einem solchen Fall zur Entscheidungsfindung herangezogen würde...

Gibt's dazu Meinungen?

Stefan Lang (Jul 04 2017 at 16:24):

Ich denke, das ist offensichtlich bis auf weiteres kein Item, das größerer Aufmerksamkeit bedarf.
evtl. noch die deutschen Interpretationen der Codes hinterlegen, mehr sollte man hier nicht tun

Mathias Aschhoff (Jul 04 2017 at 16:25):

Ah, etwas zur Diskussion um ANSI, PDF zur Kommentierung - https://build.fhir.org/toc.html daraus lässt sich sicher auch ein PDF für die werten Herren von ANSI generieren, ich probiere mich gerade mal daran. Allerdings sind da zich Value-Sets etc drin was es schwer macht Übersicht zu haben...

Stefan Lang (Jul 04 2017 at 16:47):

@Mathias Aschhoff Kann Dir gerade nicht folgen. ANSI? PDF? Und was hat das mit Patienten-Basisprofil zu tun? #threadpolice ;)))

Mathias Aschhoff (Jul 04 2017 at 18:11):

@Stefan Lang sorry ich hol dich eben ab, wir hatten darüber gesprochen, dass FHIR für die Normative Edition auch als PDF existieren müsste...

Simone Heckmann (Jul 08 2019 at 07:34):

Ich habe den R4 Leitfaden mit etwas Prosa zum Thema "eingetragene Lebenspartnerschaft" angereichert:
https://simplifier.net/guide/basisprofil-de-r4/Patient.maritalStatus

Simone Heckmann (Aug 08 2019 at 13:24):

Ich stelle gerade fest, dass wir damit inkompatibel zu den Schweizern sind :) @Oliver Egger :
Müssen/wollen/sollen wir da harmonisieren?

Simone Heckmann (Aug 08 2019 at 13:27):

Ah, moment, ich sehe, ihr geht da ganz eigene Wege: http://build.fhir.org/ig/hl7ch/ch-core/ValueSet-ch-core-maritalstatus.html
...ist das erlaubt, bei einem extensible Binding in der Spezifikation ein komplett anderes zu requiren!?

Patrick Werner (Aug 08 2019 at 13:44):

insofern alle concepts des ersten bindings im 2. required binding enthalten sind sollte das funktionieren. Was aber grenzwertig ist: extensible erlaubt weitere Konzepte nur wenn keines der Originalkonzepte passt.
Hier sind aber doppelte Konzepte enthalten, was nicht spec conform ist.

Oliver Egger (Aug 08 2019 at 13:45):

Ein CodeableConcept erlaubt ja mehrere Codings drinnen. Wir haben eine ConceptMap definiert wie die "Schweizer"-Zivilstände auf die HL7 FHIR mappen müssen: http://build.fhir.org/ig/hl7ch/ch-core/ConceptMap-maritalstatus-ech11-to-fhir.html. Ev. bräuchte es in dem Fall noch eine Regel dass der Basis Zivilstand auch übermittelt wird falls vorhanden.

Simone Heckmann (Aug 08 2019 at 13:47):

Wenn ihr "6" auf "M" mappt, dann sind wir konform ;-)

Oliver Egger (Aug 08 2019 at 13:59):

nehme ich mal so auf für die nächste telco, danke für den Input!

Last updated: Apr 12 2022 at 19:14 UTC