Stream: german (d-a-ch)
Topic: Leistungserbringer
Simone Heckmann (Aug 22 2016 at 14:50):
...da wir gerade mit der Betriebsstätte so eifrig dabei sind. Warum nicht auch gleich den Leistungserbringer mit anpacken? Mag jemand den Aufschlag machen und die Anforderungen formulieren? Basis: http://hl7-fhir.github.io/practitioner.html
Stefan Lang (Aug 22 2016 at 18:13):
Ich versuch mich gleich mal an einem XML-Beispiel ;-)
Stefan Lang (Aug 22 2016 at 18:24):
Auch Zahnärzte können Leistungserbringer sein. Das führt uns zu einem neuen Namespace (KZBV/Zahnarztnummer)
Stefan Lang (Aug 22 2016 at 18:24):
https://dejure.org/gesetze/SGB_V/293.html
Stefan Lang (Aug 22 2016 at 19:16):
1. Aufschlag:
<?xml version="1.0" encoding="UTF-8"?> <Practitioner xmlns="http://hl7.org/fhir"> <identifier> <!-- Ärzte: lebenslange Arztnr.; 0..* --> <use value="usual"/> <system value="http://kbv.de/LANR"/> <value value="123456789"/> <period> <start value="2010-07-01"/> <end value="2015-12-31"/> </period> </identifier> <identifier> <!-- Zahnärzte: Zahnarztnr.; 0..* --> <use value="usual"/> <system value="http://kzbv.de/Zahnarztnummer"/> <value value="112233445"/> <period> <start value="2012-07-01"/> <end value="2016-03-31"/> </period> </identifier> <!-- weitere identifier sind nach Bedarf möglich; 0..* --> <active value="false"/> <name> <use value="usual"/> <family value="Mustermann"/> <given value="Max"/> <prefix value="Prof. Dr."/> <suffix value="M.D."/> </name> <gender value="male"/> <birthDate value="1961-05-23"/> <role> <!-- 0..* --> <organization> <reference value="Organization/4746"/> <display value="Musterklinik Musterhausen"/> </organization> <code> <coding> <!-- SL: Wird hier eine stärkere Differenzierung benötigt (z.B. CA, OA, ...)? --> <system value="http://hl7.org/fhir/practitioner-role"/> <code value="doctor"/> <display value="Arzt"/> </coding> </code> <specialty> <!-- 0..* --> <coding> <!-- SL: Als Grundlage z.B. die Kennziffern für Gebiete, Facharzt- und Schwerpunktkompetenzen lt. Anlage 4 in https://www.kvberlin.de/20praxis/30abrechnung_honorar/50edv/barcode_verzeichnis.pdf --> <system value="http://kbv.de/fachgebiet"/> <code value="511"/> <display value="FA Gefäßchirurgie"/> </coding> </specialty> <!-- bei Bedarf weitere identifier für die Beziehung Arzt-Betriebsstätte; 0..* --> <!-- <identifier>...</identifier> --> <telecom> <!-- 0..* --> <system value="phone"/> <value value="09876/543-21012"/> <use value="work"/> </telecom> <period> <start value="2013-01-01"/> <end value="2014-12-31"/> </period> </role> </Practitioner>
Simone Heckmann (Aug 22 2016 at 19:47):
Danke Stefan! Ich versuche mich morgen mal am Profil. Heißt das Dings dann LZNA?
Stefan Lang (Aug 23 2016 at 07:15):
Meines Wissens gibt es für die Zahnarztnummer keine Abkürzung. In allen mir bekannten Dokumenten gibt es nur den vollen Begriff.
Simone Heckmann (Aug 23 2016 at 11:32):
Mir ist noch nicht ganz klar, ob die Fachgebiets-Ziffern von der KBV kommen, oder ob die KBV da auf ein fremdverwaltetes System verweist (Weiterbildungsordnung = Ärztekammer??)
Simone Heckmann (Aug 23 2016 at 11:45):
...das wäre dann ein Arzt mit Facharzt Gynäkologie und Schwerpunkt Endokrinologie:
<specialty> <!-- 0..* --> <coding> <system value="http://kbv.de/fachgebiet"/> <code value="050"/> <display value="FA Frauenheilkunde und Geburtshilfe"/> </coding> </specialty> <specialty> <!-- 0..* --> <coding> <system value="http://kbv.de/fachgebiet"/> <code value="516"/> <display value="SP Gynäkologische Endokrinologie und Reproduktionsmedizin"/> </coding> </specialty>
Stefan Lang (Aug 24 2016 at 08:28):
Die Schlüsseltabelle ist jedenfalls die S_BAR2_WBO (OID: 1.2.276.0.76.5.114 ) von der KBV.
Aktuellste Fassung: http://applications.kbv.de/keytabs/ita/schluesseltabellen.asp?page=S_BAR2_WBO_V1.10.htm
Stefan Lang (Aug 24 2016 at 08:29):
Evtl. sollten wir den Namespace entsprechend benennen. Also "http://kbv.de/S_BAR2_WBO"
Simone Heckmann (Aug 24 2016 at 08:30):
Ah Super, danke! Damit kann ich uns ein Value-Set bauen, das auf die Tabelle verweist.
Simone Heckmann (Aug 24 2016 at 08:31):
Hach ja... die Namespaces...
Nach der Anmerkung von Lloyd tendiere ich gerade mal wieder zur kanonischen Form:
https://chat.fhir.org/#narrow/stream/implementers/topic/choosing.20uniqueID.20url.20for.20NamingSystem
Patrick Werner (Aug 24 2016 at 08:32):
+1 für canonical form
Stefan Lang (Aug 24 2016 at 08:33):
+1 dito :D
Stefan Lang (Aug 24 2016 at 08:49):
(deleted)
Simone Heckmann (Aug 24 2016 at 15:48):
Aktuelle Version: https://simplifier.net/FHIRABENDSandbox/FHIRABENDSandbox-KBV-Leistungserbringer
Simone Heckmann (Aug 24 2016 at 19:23):
Nebenbei: Das mit der Zahnarztnummer finde ich nirgends sonst. In allen anderen Quellen heiß es nur: Zahnärzte haben keine LANR
Wikipedia: "Für Bundeswehrärzte, Zahnärzte und Hebammen gibt es keine LANR und keine BSNR. Diese sollten die Pseudo-Nummern 999999900 für die LANR und 179999900 für die BSNR verwenden"
Simone Heckmann (Aug 24 2016 at 19:23):
oder hier: https://www.zahnaerzte-hh.de/zahnarzt-team/kzv-hamburg/abrechnung/abrechnungsfragen-von-a-z/l/lebenslange-arztnummer.html
"Bei Überweisungen/Verordnungen/Rezepten kann es dazu kommen, dass die Empfänger eine Betriebsstättennummer und/oder lebenslange Arztnummer einfordern. Dann weisen Sie bitte daraufhin, dass diese Nummern im vertragszahnärztlichen Bereich nicht vorhanden sind. Im Zweifel möge sich der Empfänger an seine Kammer/Innung/KV etc. wenden."
Patrick Werner (Aug 24 2016 at 20:00):
@Simone Heckmann eine befreundete Zahnärztin bestätigt das Fehlen der LANR und BSNR für Zahnärzte, es gibt aber eine KZV Nummer der Zahnarztpraxis
Simone Heckmann (Aug 24 2016 at 20:10):
Tsk...Stefan, der Troll! :D
Patrick Werner (Aug 24 2016 at 20:11):
ich versuche mal mehr rauszubekommen, es scheint zur Abrechnung doch eine Nummer zu geben....
Stefan Lang (Aug 25 2016 at 10:53):
Nix Troll :D
Stefan Lang (Aug 25 2016 at 10:55):
Ein Item, das in Schnittstellen der GKV vorkommt, betrachte ich nicht als Trolling ;)
Stefan Lang (Aug 25 2016 at 10:56):
... und in §293 SGB V: https://www.gesetze-im-internet.de/sgb_5/__293.html
Stefan Lang (Aug 25 2016 at 10:58):
Der Datentyp ist 8-stellig alphanumerisch
Stefan Lang (Aug 25 2016 at 11:04):
Und dass Zahnärzte eine BSNR haben, hab ich nie behauptet. Im Gegenteil ;)
Die GKV kennt 3 Arten von Leistungserbringern (edit: in Bezug auf Diagnostik + Behandlung, ex Pflegedienste, Physiotherapie usw.):
- Kliniken, identifiziert durch IKNR
- Niedergelassene Ärzte, identifiziert durch BSNR+LANR
- Zahnärzte, identifiziert durch Zahnarztnummer
Bei der Zahnarztabrechnung sind bis zu 17 Stellen alphanumerisch möglich ("codierte Zahnarztnummer"): https://gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/zahnaerzte/technische_anlagen___aktuell_1/20151126_TA_Version_3_7_oA.pdf
Die 8 Stellen kenne ich aus der Krebsregister-Abrechnung
Stefan Lang (Aug 25 2016 at 11:18):
Es wäre allerdings ggf. rauszufinden, ob die Zahnarztnummer für die Praxis gilt (dann müssten wir sie bei der Organization ansiedeln) oder für den einzelnen Arzt (=> Practitioner)
Stefan Lang (Aug 25 2016 at 11:38):
https://gkv-datenaustausch.de/suche/suche?default=true&query=zahnarztnummer
"Ihre Suchanfrage für "zahnarztnummer" ergab 144 Treffer. "
Troll!
Pah!
Helmut Ristok (Aug 31 2016 at 05:54):
Vorstellung an Anmerkung zur eindeutigkeit der LANR
Helmut Ristok (Aug 31 2016 at 06:00):
tenwerkstätten und Jugendhilfe e.t.c.)
Nach einer intensiven Beschäftigung mit HL7 V2 wollen wir nun FHIR als Basis für den Interop-Standard verwenden.
Helmut Ristok (Aug 31 2016 at 06:02):
Anmerkung zur LANR: Ein Arzt kann auf jedne Fall mehrere LANR haben - konkret wird hier Arzt und FAchgebiet codiert.
Sollte das in der Struktur berücksichtigt werden - also ein Arzt mit merheren FAchgebieten als Unterordnung?
Simone Heckmann (Aug 31 2016 at 12:49):
Da ein Practitioner auch mehrere Identifier haben kann, sehe ich darin zunächst kein Problem. Das Attribut "Specialty" ist in dem wiederholbaren Element "role" gekapselt, also auch hier sehe ich kein Problem.
Simone Heckmann (Aug 31 2016 at 12:53):
Falls wir jedoch den Identifier in Zusammenhang mit der Rolle/dem Fachgebiet bringen müssen, dann müssten wir uns der PractitionerRole-Resource bedienen.
Simone Heckmann (Aug 31 2016 at 13:07):
Ach nö. Müssen wir nicht. Das "role"-Element hat ja auch einen eigenen identifier. Ich denke, die Diskussion, ob das role-Element in die separate PractitionerRole-Resource ausgelagert wird, ist noch nicht endgültig entschieden... Sollte und bei der Modellierung nicht weiter stören, da die Attribute weitgehend äquivalent sind.
Simone Heckmann (Aug 31 2016 at 13:11):
@Helmut Ristok Gibt es schon einen Plan, mit welchem UseCase begonnen werden soll? Wir helfen gerne beider Profilierung!
Simone Heckmann (Sep 20 2016 at 13:36):
Gruß vom HL7 WGM in Baltimore!
Morgen entscheidet die "Patient Administration" Arbeitsgruppe darüber, ob die PractitionerRole als separate Resource ausgegliedert wird oder ein Backbone-Element von Practitioner bleibt. Haben wir dazu eine Meinung/Präferenz? Das Hauptargument für eine Ausgliederung war IIRC, dass der Practitioner bei unterschiedlichen Organisations tätig sein kann und die Attribute der Rolle ggf unabhängig von einender gepflegt werden müssen. Dagegen spricht, dass das Gesamtkonstrukt von Organization, Practitioner und PractitionerRole dann ziemlich komplex und das Gros Fälle, in denen man einen Arzt einfach als Name, Adresse, Telefonnummer erfassen möchte, unnötig(?) verschwurbelt wird.
Stefan Lang (Sep 20 2016 at 14:48):
Wenn ich ins relationale Modell falle, brauche ich bei Practitioner:Organization = m:n eine Zwischen-Tabelle zur Referenzierung. Das würde in FHIR durch PractitionerRole abgebildet.
Andererseits sehe ich den Zweck von FHIR nach wie vor primär im Datenaustausch, und zwar durchaus auch von Systemen, die intern ganz anders strukturiert sind und die FHIR-Resourcen ohnehin on the fly generieren. Da dürfte es klar einfacher sein, das BackboneElement (0..*) beizubehalten.
Eine separate Resource würde m.E. auch der Grundphilosophie widersprechen, dass eine Referenzierung (gleich welcher Art) in der referenzierenden Resource zu finden ist.
Von meiner Seite also: pro BackboneElement
Simone Heckmann (Oct 28 2016 at 15:54):
Interessant: https://chat.fhir.org/#narrow/stream/implementers/topic/provider.20directory
Im Argonaut Project arbeitet man an der Spezifikation für ein ProviderDirectory, was dann in ein entsprechendes IHE-Profil übernommen werden soll. ETA 2017. Wäre doch auch für uns interessant, oder?
Tarik Idris (Oct 28 2016 at 17:00):
Ja, hab mich auch sehr stark dafür ausgesprochen. Spannend ist daran auch, dass es einen breiteren Scope als IHE HPD hat, da auch die Konstrukte "Services" und "Facility" aus IHE CSD unterstützt werden sollen. Das ist z.B. hilfreich um eine Terminvergabe zu unterstützen.
Simone Heckmann (Oct 28 2016 at 17:08):
Grahame Grieve (Oct 28 2016 at 21:25):
"große" as a VV? does it have the meaning I think it does? Michael "the big" Ballack?
Stefan Lang (Oct 29 2016 at 11:48):
Hat jemand schon ein Auge drauf, dass eventuelle deutsche Besonderheiten in dem Provider Directory bzw. dem folgenden IHE-Profil berücksichtigt bzw. ermöglicht sind? @Tarik Idris ?
Tarik Idris (Oct 31 2016 at 08:51):
Ich denke ich werde ein Auge drauf haben können, angenommen es wird angenommen ;-) Ich kann auch gerne auf diesem Channel Feedback geben.
Patrick Werner (Oct 31 2016 at 10:39):
(deleted, wrong topic)
Patrick Werner (Oct 31 2016 at 10:41):
(deleted, wrong topic)
Stefan Lang (Oct 31 2016 at 10:57):
@Tarik Idris Das wäre gut ;-)
Evelyn Dröge (Nov 29 2017 at 11:45):
Ich bin gerade über diese Diskussion gestolpert. Falls das noch nicht geklärt sein sollte: Zahnärzte haben tatsächlich keine LANR. Sie haben eine KZV und die KZV vergibt eine Nummer (ob immer, weiß ich nicht, aber das würde Sinn ergeben) - die Nummer ist dann KZV-übergreifend nicht eindeutig aber sollte in Kombination mit dem KZV-Code eindeutig sein.
Evelyn Dröge (Nov 29 2017 at 11:46):
Oh, ich sehe gerade, dass die Diskussion weiter ging, als ich über die Suche gesehen hatte. Vielleicht ist mein Beitrag gerade total überflüssig, ich muss nachlesen. Sorry, bin noch Zulip-Newbie.
Stefan Lang (Nov 29 2017 at 14:53):
Die Zahnarztnummer ist bisher nicht weiter verfolgt worden, von daher danke für's Wiederaufgreifen ;-)
Ich würde die schon gerne mit in die Basisprofile nehmen, immerhin ist es ein bundesweit relevanter Identifier. Wir hatten nur nicht weiter recherchiert.
Zur Sicherheit: "KZV" oder "KZBV"? Ich meine, letzteres
Stefan Lang (Nov 29 2017 at 14:54):
Ein anderer Punkt, der da nicht final geklärt war: ist das eine Nummer für den Arzt (analog LANR) oder für die Praxis (analog BSNR)?
Stefan Lang (Nov 29 2017 at 14:56):
https://github.com/hl7germany/basisprofil-de/issues/73
Patrick Werner (Nov 29 2017 at 15:29):
Die Zahnarztnummer wird von einer KZV (nicht KZBV) vergeben
Patrick Werner (Nov 29 2017 at 15:29):
wie oben bereits beschrieben: Zahnarztnummer & KVZ Nummer sind eindeutig
Patrick Werner (Nov 29 2017 at 15:30):
Zahnarztnummer alleine nicht
Evelyn Dröge (Nov 29 2017 at 16:39):
Gut auf den Punkt gebracht!
Wir verwenden die Kombination KVZ-Nummer und Zahnarztnummer mehr oder weniger analog zu LANR beim "normalen" ambulanten Arzt.
Wenn es die KZVen im Basisprofil gäbe (aktuelle Liste hier, S. 77: https://www.gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/zahnaerzte/technische_anlagen___aktuell_1/20170727_TA_Version_3_8_oA.pdf ) würden wir sie gerne nutzen. Stand jetzt würden wir ein eigenes CodeSystem verwenden. Nur ist das natürlich auch etwas, was prima in das Basisprofil passen würde!
Die Zahnarztnummer hat bei uns kein CodeSystem. Soweit ich weiß, unterscheidet sich der Aufbau je nach KZV. Man könnte dann also nur sagen, dass es eine Nummer ist, die in Kombination mit KZV-ID den Zahnarzt identifiziert, aber nicht viel zur Form sagen. Das ist aber nur Laienwissen - ich lasse mich gerne korrigieren.
KZBV ist die Kassenzahnärztliche Bundesvereinigung. Die KZVen mappen manchmal, aber nicht immer, auf ein Bundesland (siehe Liste auf S. 77). Die Kürzel kommen also irgendwie im gleichen Kontext vor, aber für die Indentifizierung des Arztes braucht es die KZV-Nummer. Es gibt ja nur eine KZBV .
Stefan Lang (Nov 30 2017 at 07:13):
Danke, das klärt es auf :)
Ich ging von einer zentralen Instanz (vulgo: KZBV) aus, weil z.B. im Krebsregister-Abrechnungsverfahren "die" Zahnarztnummer zu übermitteln ist, die aber ja offensichtlich nicht per se unique ist. Das ist dann wohl eine Schwäche dieser Verfahrensspezifikation.
Stefan Lang (Nov 30 2017 at 07:19):
Die Liste der KZVen (S. 77 des von Evelyn verlinkten Dokuments) ist ja überschaubar.
Ich schlage daher vor, jeweils ein NamingSystem zu definieren. Für das Muster sehe ich zwei sinnhafte Optionen:
A) http://fhir.de/NamingSystem/kzv/NN/zahnarztnummer
mit NN = zweistellige Nummer laut besagter Liste
Beispiel: http://fhir.de/NamingSystem/kzv/52/zahnarztnummer
B) http://fhir.de/NamingSystem/kzv-AAAAA/zahnarztnummer
mit AAAAA = String für die Region (Kleinschrift, keine Umlaute
Beispiel: http://fhir.de/NamingSystem/kzv-mecklenburg-vorpommern/zahnarztnummer
Gedanken dazu?
(Edit: Unterebene für die Zahnarztnr. ergänzt)
Simone Heckmann (Nov 30 2017 at 12:09):
+1 für Abbildung über verschiedene KZV-abhängige Namespace-URLs für Identifier.system
Sinnvoll wäre es vermutlich, bei diesen Identifiern einen Identifier.type fest zu definieren, damit Systeme die KZV-NR in der Liste der Identifier finden können. Im Gegensatz zur LANR ist dies hier ja nicht eindeutig über Identifier.system möglich.
Stefan Lang (Nov 30 2017 at 12:47):
+1 für den speziellen Identifier.type. Ich ergänze das gerade mal im GitHub-Issue.
Edit/kleine Korrektur: muss natürlich NamingSystem.type sein - in der Instanz wollten wir ja möglichst keinen Typ erzwingen.
Simone Heckmann (Dec 01 2017 at 10:21):
Genau das wäre hier ein Fall, in dem ich es in der Instanz erzwingen würde.
Evelyn Dröge (Dec 01 2017 at 11:42):
Wenn ich es richtig verstehe, dann hat man in den Beispielen beide Informationen in einer URL. Das finde ich nicht glücklich, weil eine Url oder Uri in einem Datenmodell aus meiner Sicht nur für ein Ding da sein sollte und nicht für zwei verschiedene Dinge. Zwar ergeben beide zusammen den eindeutigen Identifier, aber trotzdem stehen sie für Unterschiedliches. Oder würden beide zusätzlich separat abgebildet werden?
Simone Heckmann (Dec 01 2017 at 13:50):
würde in der Instanz dann so (ungefähr) aussehen:
<identifier> <type> <system value="http://fhir.de/CodeSystem/identifier-type-de-basis"/> <code value="LZANR"/> </type> <system value="http://fhir.de/NamingSystem/kzv/NN/zahnarztnummer"/> <value value="123456789"/> </identifier>
Simone Heckmann (Dec 01 2017 at 13:51):
...am Type könnte man erkennen dass es sich um eine LZANR handelt, und an system+value um welche es sich handelt.
Simone Heckmann (Dec 01 2017 at 13:54):
Würde man den Type in der Instanz weglassen, müssten Systeme, die nach der LZANR suchen entweder im NamingSystem den Type nachschlagen, was ich sehr aufwändig fände, oder über ein Pattern-Matching die system-URL prüfen, ob sie dem Schema .../NamingSystem/kzv/.*/zahnarztnummer entspricht. Beides irgendwie suboptimal...
Simone Heckmann (Dec 01 2017 at 14:00):
ups. type.system korrigiert...
Stefan Lang (Dec 01 2017 at 18:35):
Unabhängig von Identifier.type gehört es nach unseren Konventionen nach NamingSystem.type.
Wenn wir es bei der Zahnarztnummer im Identifier erzwingen wollen, sollten wir das dann aber auch konsistenterweise für die PKVen tun.
Bzw. generell dort, wo mehrere NamingSystems durch einen type geklammert werden. Das wäre dann mindestens eine textuelle Ergänzung im Leitfaden.
D'accord?
Stefan Lang (Dec 01 2017 at 18:44):
https://github.com/hl7germany/basisprofil-de/issues/74
Michael Sauer (Dec 02 2017 at 09:52):
Welch Nummern meinst Du bei den PKVen? Bei GKVen sollte das jedenfalls nicht aufgeteilt werden, den die Nummern sind für sich genommen schon eindeutig. Neben des KV Bereiches gibt es dort auch andere Präfixe (z.B. fürs Entlassmanagement).
Stefan Lang (Dec 02 2017 at 11:52):
Soweit wir wissen, vergibt jede PKV ihre eigenen Versichertennummern (bzw. Vertragsnummern).
Um diese global eindeutig zu machen, braucht es also pro PKV ein separates NamingSystem für die jeweiligen Identifier; das NamingSystem taucht als Identifier.system wieder auf. Beispiel:
<!- erste PKV --> <identifier> <system value="http://pkv1.de/NamingSystem/versichertennummer"/> <value value="123456789"/> </identifier> <!- zweite PKV --> <identifier> <system value="http://pkv2.de/NamingSystem/vnr"/> <value value="123456789"/> </identifier>
Da wir mit den Basisprofilen nicht für diese NamingSystems zuständig sind (das sollten die PKVen nach eigenem Gusto vergeben), wäre im Basisprofil-Leitfaden konsistenterweise zu erwähnen: "wenn eine PKV ein Namingsystem für die Versichertennummer verwendet, sollte es den Typ "PKV" haben und der Typ auch im Identifier de Ressourcen-Instanz werden." Somit:
<!- erste PKV -->
<identifier>
<type>
<system value="http://fhir.de/CodeSystem/identifier-type-de-basis"/>
<code value="PKV"/>
</type>
<system value="http://pkv1.de/NamingSystem/versichertennummer"/>
<value value="123456789"/>
</identifier>
Die GKV hat in der Tat die eindeutige lebenslang auch bei Kassenwechsel unveränderliche zehnstellige Nummer. In den Basisprofilen: https://simplifier.net/BasisprofilDE/gkv-kvid-10
Darüber hinaus gibt es in der GKV auch noch die (bis zu) 30-stellige Versichertennummer, die in den ersten 10 Stellen identisch ist mit der lebenslangen, danach aber variabel sein kann: https://simplifier.net/BasisprofilDE/gkv-kvnr-30
Es gibt also genau genommen 2 Identifier für GKV-Versicherte, wobei letzterer nur im Kontext der Identifikation von Versicherungsverhältnissen sinnvoll ist, während die 10-stellige Nummer auch (da lebenslang und persönlich) auch ein Identifier für Patienten ist.
Ganz pedantisch müsste man somit auch hier den Identifier.type in die Ressourcen-Instanz aufnehmen, zumindest bei Coverage-Ressourcen.
Simone Heckmann (Dec 04 2017 at 16:00):
Michael Sauer (Dec 04 2017 at 16:43):
(deleted)
Michael Sauer (Dec 04 2017 at 16:46):
@Stefan Lang
Verstehe, es geht um die Versichertennummer des Patienten. Ich bin etwas durcheinander gekommen, weil davon im Zusammenhang mit den (Zahn-)Arztnummern gesprochen wurde.
Bezüglich der Versichertennummer fände ich die hier dargestellte Nomenklatur allerdings ungünstig - den eine eindeutige URL der PKV liegt normalerweise nicht vor. Die Identifikation eines Patienten erfolgt über die Unternehmensnummer (bzw. IK-Nummer, die sich aus der Unternehmensnummer ableiten lässt), die Versicherungsnummer und die Personennummer.
Bsp:
4108: Union Krankenversicherung (IK 168141085)
00004711: Versichertennummer (hier fiktiv, führende 0'en kommen aber vor)
Pers-Nr 0001
Bsp2:
4028 Debeka IDUNA (IK 168140288)
12345678: Vesichertennummer
Pers-Nr 0101
Stefan Lang (Dec 05 2017 at 08:39):
@Michael Sauer Identifier sollten immer system + value haben, sonst sind sie nicht interoperabel.
Die besagten Nummern braucht man im Kontext von Versicherungsverhältnissen.
D.h. für die IK der PKV braucht man ein system (das wäre http://fhir.de/NamingSystem/arge-ik/iknr ) => Coverage.payor.identifier.
Für die Versichertennummer braucht man ein weiteres system (das ist zwangsläufig spezifisch für die jeweilige PKV) => Coverage.identifier.
Da es bis auf weiteres keine vollständige Liste dieser NamingSystems gibt, ist genau der Vorschlag: Coverage.identifier.type muss "PKV" lauten - z.B. um queries wie "zeig mir alle PKV-Versicherungsverhältnisse" einfach ausführen zu können.
Damit ist dann die Verwendung von "irgendeinem" NamingSystem für Coverage.identifier.system problemlos möglich.
Stefan Lang (Dec 05 2017 at 08:42):
Die Pers.-Nr. ist nochmal eine andere Sache; das Coverage-Profil für PKV steht ja noch aus.
Ein zweiter Identifier ist das nicht. Eher textuell an die Vers.-Nr. angehängt (z.B. "00004711/0001") oder, falls nötig als Extension(?)
Simone Heckmann (Dec 05 2017 at 10:00):
Ist Coverage.identifier.type nicht redundant, wenn wir Coverage.type schon auf "PKV" fixieren?
Stefan Lang (Dec 05 2017 at 10:11):
Guter Punkt.
An dieser Stelle wäre Coverage.identifier.type tatsächlich nicht erforderlich.
Es gibt allerdings Referenzen auf Coverage, z.B. in Account. Somit sind auch logische Referenzen möglich. Wird dort für die PKVen identifier.type="PKV" benötigt?
Falls ja, neige ich dazu, das konsistent zu halten, auch wenn es redundant ist.
Falls nein: wo soll dann der identifier.type="PKV" verwendet werden?
Simone Heckmann (Dec 05 2017 at 10:12):
Ich sehe keine Notwendigkeit den Type bei der logischen Referenz mitzuführen, da system+value eindeutig genug sind.
Stefan Lang (Dec 05 2017 at 10:16):
Und bei einem Account wird nie nach "zeig mir alle PVK-gedeckten Accounts" gesucht?
Simone Heckmann (Dec 05 2017 at 10:28):
[base]/Account?coverage.coverage.type=PKV
Stefan Lang (Dec 05 2017 at 10:34):
Ich meinte bei logischer Referenz, falls das ein Thema ist
Simone Heckmann (Dec 05 2017 at 10:35):
Ah jetzt blick ich's! Klar, da wäre das natürlich hilfreich...
Simone Heckmann (Dec 05 2017 at 10:36):
Wobei ich nicht weiß, ob bei Account eine logische Referenz auf Coverage sinnvoll ist... i.d.R. muss ich zu der Coverage ja schon mehr wissen als nur den Identifier...
Stefan Lang (Dec 06 2017 at 17:42):
Zurück zur Zahnarztnummer:
Wenn ich dem von @Evelyn Dröge verlinkten Spezifikationstext folge, identifiziert die Zahnarztnummer keineswegs den einzelnen Arzt. Auf besagter Seite 77:
"2.1 Zahnarzt-Abrechnungsnummer
1- bis 6 -stelliges numerisches Feld, das die Abrechnungsnummer des Zahnarztes bzw. der Praxis im Falle von Berufsausübungsgemeinschaften enthält. "
Da auch ein einzeln praktizierender Zahnarzt eine Organisation darstellt, sehe ich da ziemlich eindeutig eien Identifier von Organization, nicht von Practitioner.
Stefan Lang (Dec 06 2017 at 17:44):
Zahnarztnummer für Practitioner ist demzufolge nicht sauber, da sie mehrere Zahnärzte (= Practitioner) umfassen kann. Das widerspricht dem Begriff des (unique) Identifiers.
Meinungen hierzu?
Stefan Lang (Dec 06 2017 at 18:15):
KZV-NamingSystems sowie erweitertes identifier-type-de sind committed, mit einem ToDo bezüglich Klärung Organization oder Practitioner.
Beispiele machen natürlich auch erst Sinn, wenn das klar ist.
Evelyn Dröge (Dec 07 2017 at 10:17):
@Stefan Lang In Produktion sieht es so aus, dass die Zahnarztnummer in Kombination mit der KZV eindeutig pro Zahnarzt und nicht pro Praxis ist. Daher würde ich beim Practitioner bleiben.
Stefan Lang (Dec 07 2017 at 10:37):
D.h. auch bei einer Gemeinschaftspraxis gibt es >=2 Zahnarztnummern?
Stefan Lang (Dec 07 2017 at 10:42):
Wenn hier die Realität und die Spezifikation nicht zusammen passen, bin ich geneigt, der Realität zu folgen ;-)
Stefan Lang (Dec 07 2017 at 10:44):
Im Zweifel haben wir ja immer noch die nächste Kommentierungsphase der Basisprofile, falls jemand Einwände hat, das an Practitioner zu hängen.
Evelyn Dröge (Dec 07 2017 at 10:44):
Genau, jeder Arzt hat da eine individuelle Nummer und eine übergreifende Nummer für die Ärzte einer Praxis gibt es nicht. Das hat der Blick in die Echtdaten über ein paar Praxen hinweg ergeben (vielleicht kann das ja noch jemand anderes mit Praxisbezug zu Zahnärzten bestätigen).
Stefan Lang (Dec 07 2017 at 10:45):
Gut, ich ergänze das in den NamingSystems und baue ein Beispiel.
Stefan Lang (Dec 07 2017 at 11:25):
Done.
Nächster Punkt zum Thema ;-)
Sollte die Zahnarztnummer im Profil practitioner-de-basis als Slice aufgenommen werden?
Aufgrund der insgesamt 18 möglichen Identifier.system würde das etwas komplexer.
Ich sehe gerade folgende Optionen:
A) nicht als Slice aufnehmen. Nur im Leitfaden die NamingSystems und das Beispiel aufnehmen
B) 18 Slices definieren, jeweils mit fixed ValueSet
C) Pattern für Identifier.system definieren und anhand des Pattern slicen, nicht anhand des Value. Das würde implizieren, dass wir auch für die LANR ein Pattern definieren müssen (1:1 identisch mit dem dort vergebenen fixed value). Dazu die FHIR-Spec: " At present, pattern[x] is not recommended as a basis for slicing while issues related to this are investigated during the STU period."
Ich neige zu A). Meinungen?
Simone Heckmann (Dec 07 2017 at 21:43):
+1 für A
Evelyn Dröge (Dec 08 2017 at 11:04):
A
Stefan Lang (Dec 08 2017 at 12:58):
... und drin: https://simplifier.net/guide/LeitfadenBasisDE/Behandler
Christof Gessner (Mar 11 2018 at 14:17):
Frage zu https://simplifier.net/medikationsplanplus/composition-1 :
Ich bekomme von Simplifier keine Validierung für Composition.custodian. Gebe ich ihr eine Praxis (identifier.system: http://fhir.de/NamingSystem/kbv/bsnr), will sie eine Apotheke - gebe ich ihr eine Apotheke, will sie eine Praxis...
Vielleicht habe ich auch das Slicing hier noch nicht verstanden, Fehlermeldung lautet übrigens:
( Invalid : Value does not match pattern '{"resourceType":"Identifier","system":"http://fhir.de/NamingSystem/bfarm/btmnr"}' 1009
Bundle.entry[0].resource[0].custodian[0].identifier[0] )
Simone Heckmann (Mar 11 2018 at 14:24):
Hallo Christof, das könnte ein Fehler in der Definition des Discriminators sein...
Hast du den Link zu Deinem Beispiel?
Christof Gessner (Mar 11 2018 at 14:32):
<Composition xmlns="http://hl7.org/fhir">
<meta>
<profile value="http://fhir.de/StructureDefinition/medikationsplanplus/composition" />
</meta>
<identifier>
<system value="http://fhir.de/composition-identifier" />
<value value="02BD2867FB024401A590D59D94E1FFAE" />
</identifier>
<status value="final" />
<type>
<coding>
<system value="http://loinc.org" />
<code value="77603-9" />
<display value="Medication treatment plan.extended Document" />
</coding>
</type>
<subject>
<reference value="Patient/patient-1" />
</subject>
<date value="2017-05-02T12:00:00Z" />
<author>
<reference value="urn:uuid:1f0d0fc8-2e6f-415f-82ce-153b69476af6" />
</author>
<title value="Patientenbezogener Medikationsplan" />
<custodian>
<identifier>
<system value="http://fhir.de/NamingSystem/kbv/bsnr" />
<value value="123456" />
</identifier>
</custodian>
<section>
<code>
<coding>
<system value="http://loinc.org" />
<code value="19009-0" />
</coding>
</code>
<entry>
<reference value="List/medicationlist-1" />
</entry>
</section>
</Composition>
Christof Gessner (Mar 11 2018 at 14:41):
Ja, Discriminator sollte wohl besser pattern.id sein? z. B.
<slicing>
<discriminator>
<type value="="pattern"/>
<path value="="id"/>
</discriminator>
<rules value="="closed"/>
</slicing>
Simone Heckmann (Mar 11 2018 at 14:43):
Ich hab den Discriminator auf type=pattern und path=identifier geändert. Jetzt geht's: https://simplifier.net/Sandbox/Composition-example/$validate
Christof Gessner (Mar 11 2018 at 14:46):
Stimmt. Fein.
dr Kai U. Heitmann (Mar 11 2018 at 16:21):
Ich verstehe nicht ganz warum in den Medikationsplan Plus Definitionen nun der custodian auftaucht. Der war doch vorher nicht drin... Woher kommt Praxis und Apotheke?
Simone Heckmann (Mar 11 2018 at 16:35):
Das ist der Autor als Organisation statt Person...
Simone Heckmann (Mar 11 2018 at 16:35):
Die Organisation hat laut Datenmodell entweder eine IK oder eine BTNR
Evelyn Dröge (Jul 10 2018 at 06:04):
Ich habe zum Leistungserbringer des Medikationsplans zwei Fragen:
- Laut der Anlage 3 der Medikationsplan Spec (v 2.4 vom 30.04.17, http://www.kbv.de/media/sp/Medikationsplan_Anlage3.pdf) ist der Identifier einer Apotheke die IDF-Nummer. Dafür wird auch die BTNR verwendet, aber sind sie zwangsläufig identisch oder bräuchte es ein weiter gefasstes NamingSystem für den MedikationsplanPlus?
- Ist es im MedikationsplanPlus so gedacht, dass Custodian nur für IKNR, BTNR (IDF) genutzt wird und die Adresse, Telefonnummer, E-Mail usw. des Krankenhauses bzw. der Apotheke in Practitioner erfasst wird und nicht in der Organization? Einen Practitioner muss es ja geben und IKNR und IDF dürfen nur gespeichert werden, wenn es keine LANR gibt.
Simone Heckmann (Jul 10 2018 at 11:16):
Hallo Evelyn,
die Frage "was ist die IDF" hat uns auch viel Kopfzerbrechen bereitet, aber letztendlich haben unsere Recherchen ergeben, dass IDF und BTNR identisch sind.
Adresse, Telefonnummer, IDF, IKNR, BSNR usw. der Praxis/Apotheke/Krankenhauses gehört m.E. in Organization, die Kontaktdaten, LANR des Arztes in Practitioner.
Allerdings war uns das Datenmodell des MPPs an der Stelle auch etwas zu unscharf. Laut @dr Kai U. Heitmann sollte das aber nochmal nachgebessert werden. (https://github.com/hl7germany/medikationsplanplusplus/issues/22)
Evelyn Dröge (Jul 10 2018 at 11:55):
Hi Simone,
danke für die wie immer schnelle Antwort!
die Frage "was ist die IDF" hat uns auch viel Kopfzerbrechen bereitet, aber letztendlich haben unsere Recherchen ergeben, dass IDF und BTNR identisch sind.
Ich habe mir schon fast gedacht, dass ihr an der gleichen Stelle gegrübelt habt :) Gut, dass ich nachgefragt habe. Das deckt sich halbwegs mit meinem Bild - ich war mir nur nicht sicher, ob BTN eine Untermenge von IDF ist oder ob sie gleichgesetzt werden können.
Adresse, Telefonnummer, IDF, IKNR, BSNR usw. der Praxis/Apotheke/Krankenhauses gehört m.E. in Organization, die Kontaktdaten, LANR des Arztes in Practitioner.
Ausdruckender kann meiner Ansicht nach aber auch eine Organisation sein. Laut Spec (u.a. S. 60 der Anlage 3 von oben): "Ausdruckender des Medikationsplans - Name der aktuell ausdruckenden Person/Institution". Richtiger wäre aus meiner Sicht, bei einer IKNR oder einer BTN die Organization für die Kontaktdaten und nicht den Practitioner zu nehmen. In Kombination mit einer LANR können diese Identifier nicht auftreten. Es macht dann doch wenig Sinn, die Practitioner Ressource aufzubauen, wenn es die LANR und somit vermutlich den einzelnen Arzt nicht gibt. Schließt umgekehrt natürlich auch nicht aus, dass der Apotheker zu einer Apotheke mit genannt wird und dann in der Organization landen würde, aber der wäre ja auch nicht einzeln identifizierbar (die Apotheke aber schon). Das würde funktionieren, wenn der Practitioner nicht mehr verfplichtend wäre.
Würde mich sehr interessieren, wie eure Gedanken dazu sind..
(ping @dr Kai U. Heitmann )
Last updated: Apr 12 2022 at 19:14 UTC
