Stream: german (d-a-ch)
Topic: Betriebsstätten
Simone Heckmann (Aug 17 2016 at 21:06):
Folgende Anfrage hat mich erreicht:
In unseren konkreten Fall mit der Betriebsstätte geht es darum dass eine “Fremdsoftware” die Betriebsstätten unseres Primärsystems haben möchte um im weiteren Workflow Daten bzw. Eingaben für einen Rückschrieb ins Primärsystem korrekt zuordnen zu können.
Die Betriebsstätte ist aktuell mit folgenden Eigenschaften definiert:
*Betriebsstättenbezeichnung
*Kennzeichen Haupt-/Nebenbetriebsstätte
*Betriebsstättennummer
*KV-Bezirk
*PLZ
*Gültig von/bis
*Aktiv/Inaktiv
Simone Heckmann (Aug 17 2016 at 21:06):
Mein erster Aufschlag zur Modellierung sieht so aus:
<?xml version="1.0" encoding="UTF-8"?> <Organization xmlns="http://hl7.org/fhir"> <identifier> <use value="usual"/> <system value = "http://kbv.de/BSNR"/> <value value="12345"/> </identifier> <active value="true"/> <type> <coding> <system value="http://hl7.org/fhir/organization-type"/> <code value="prov"/> <display value="Healthcare Provider"/> </coding> </type> <name value="Praxis Dr. Soundso"/> <telecom> <system value="phone"/> <value value="07223 12345"/> <use value="work"/> </telecom> <address> <use value="work"/> <line value="Musterstrasse 33"/> <city value="Irgendwo"/> <district value="KV-Bezirk 123"/> <postalCode value="5555"/> <country value="DE"/> </address> </Organization>
Simone Heckmann (Aug 18 2016 at 07:14):
Das Kennzeichen Haupt/Nebenbetriebsstätte sowie die Gültigkeitsperiode riecht nach Extension.
Stefan Lang (Aug 18 2016 at 07:17):
Ich returniere mal:
<?xml version="1.0" encoding="UTF-8"?> <Organization xmlns="http://hl7.org/fhir"> <!-- Betriebsstättennummer --> <identifier> <use value="usual"/> <!-- SL: Konsens zu Namespaces war afair, diese unter der HL7-Domäne aufzuhängen --> <system value="http://hl7.de/fhir/BSNR"/> <value value="12345"/> </identifier> <!-- Aktiv/Inaktiv --> <active value="true"/> <type> <coding> <!-- SL: Variante A zur Haupt-/Nebenbetriebsstätte: Eigenes Value Set für den type, als Erweiterung von http://hl7.org/fhir/organization-type: prov-main: Hauptbetriebsstätte prov-sub: Nebenbetriebsstätte --> <!-- Kennzeichen Haupt-/Nebenbetriebsstätte --> <system value="http://hl7.de/fhir/organization-type"/> <code value="prov-sub"/> <display value="Healthcare Provider, subsidiary"/> </coding> </type> <!-- Betriebsstättenbezeichnung --> <name value="Praxis Dr. Soundso"/> <telecom> <system value="phone"/> <value value="07223 12345"/> <use value="work"/> </telecom> <address> <use value="work"/> <line value="Musterstrasse 33"/> <city value="Irgendwo"/> <!-- KV-Bezirk --> <!-- SL: District im Sinn von FHIR meint eigentlich Unterbereiche von Bundesländern, also Kreise oder evtl. Regierungsbezirke. Der KV-Bezirk ist in diesem Sinn kein Adressbestandteil, das wäre also ein Missbrauch von District. Die KV-Bezirke ergeben sich m.W. implizit aus Stelle 1 und 2 der BSNR, vgl. http://www.kbv.de/media/sp/Arztnummern_Richtlinie.pdf dort §6 und Anlage 1. Insofern wäre mit dem Fragesteller abzuklären, ob das evtl. redundant ist. --> <district value="KV-Bezirk 123"/> <!-- PLZ --> <postalCode value="5555"/> <country value="DE"/> </address> <!-- SL: Variante B zur Haupt-/Nebenbetriebsstätte: Kennzeichnung einer Nebenbetriebsstätte als Teil der Hauptbetriebsstätte. Das würde allerdings voraussetzen, dass diese Information im Quellsystem immer bekannt ist und generell immer eine solche eindeutige Zuordnung existiert. --> <partOf> <reference value="Organization/1337"/> </partOf> <!-- Gültig von/bis --> <!-- SL: Extension oder Change Request? Ich plädiere für letzteres, vorbehaltlich einer Diskussion im Implementers Channel ;-) --> <!-- TODO Gültigkeitszeitraum --> </Organization>
Stefan Lang (Aug 18 2016 at 07:35):
Die Gültigkeit könnte man auch als identifier.period abbilden, wobei das insofern missbräuchlich ist, als sich das eigentlich auf die Gültigkeit des Identifiers bezieht und nicht auf die Organisation. Eventuell ist (im Kontext der BSNR) allerdings auch genau das gemeint?
Stefan Lang (Aug 18 2016 at 07:41):
Bei näherer Überlegung: in Deutschland kann es ja gar keine medizinische Einrichtung ohne BSNR (oder IKNR) geben, so dass die Ungültigkeit der BSNR auch die Ungültigkeit der Organisation impliziert. Es sei denn, die Betriebsstätte zieht um und erhält deswegen eine neue BSNR. In diesem Fall gibt es halt einen zweiten Identifier mit anderer period. Gefiele mir von daher ganz gut.
Bei Krankenhäusern (IKNR) lässt sich das ganze völlig analog abbilden.
Simone Heckmann (Aug 18 2016 at 07:42):
ad "Namespace": Durch die Einführung der NamingSystem resource (http://hl7-fhir.github.io/namingsystem.html) ergeben sich für uns einige neue Freiheitsgrade, was die Namespace-URLs betrifft. Wir könnten z.B. die "original" URL als Namen verwenden, aber in der Beschreibung der Resource dennoch klarstellen, dass dies "on behalf of..." vergeben wurde. Außerdem wäre die url stets auf dem Profil-Server von HL7 (z.B. Simplifier) nachschlagbar.
Simone Heckmann (Aug 18 2016 at 07:45):
ad "Gültigkeit": Eine Praxis/Ambulanz hört ja nicht notwendigerweise auf zu existieren, nur weil die BSNR ihre Gültigkeit verliert (könnte die nicht als Privat-Praxis weitermachen???). Ich denke schon, dass wir hier über die Gültigkeit des Identifiers reden.
Simone Heckmann (Aug 18 2016 at 07:47):
ad "KV-Bezirk": d'accord. "District" ist schon deswegen keine gute Idee, weil es ein String ist. Wir benötigen an dieser Stelle jedoch ein ValueSet.
Simone Heckmann (Aug 18 2016 at 07:50):
ad "Haupt-/Nebenstelle": über partOf habe ich auch nachgedacht. Aber ich glaube, das macht uns Ärger. Auch eine "Hauptbetriebsstätte" kann ja ein partOf einer größeren Einrichtung (z.B. Klinik, Klinikkette) sein. Außerdem geht die Verknüpfung von Neben- zu Hauptbetriebsstätte aus den Stammdaten wohl nicht hervor...
Stefan Lang (Aug 18 2016 at 07:54):
Namespace: ah, wieder was gelernt. In dem Fall ziehe ich den Kommentar zurück.
Gültigkeit: OK, reine Privatpraxis geht natürlich, insofern war mein "keine medizinische Einrichtung" zu stark gewählt ;-)
Der Bezug der Gültigkeit wäre sicher auch nochmal mit dem Fragesteller zu klären, aber wenn es so ist, wie wir vermuten, geht es problemlos via period.
Haupt-/Nebenstelle: jep, bei partOf würde ich auch davon ausgehen, dass es da Probleme gibt, das aus dem Quellsystem zu füllen. Bleibt m.E. das erweiterte ValueSet; ist ja ohnehin nur als Example geflaggt.
Stefan Lang (Aug 18 2016 at 07:58):
Dann ist der aktuelle Zwischenstand:
<?xml version="1.0" encoding="UTF-8"?> <Organization xmlns="http://hl7.org/fhir"> <!-- Betriebsstättennummer --> <identifier> <use value="usual"/> <system value="http://kbv.de/BSNR"/> <value value="12345"/> <!-- Gültig von/bis --> <!-- SL: Mit dem Fragesteller ist zu klären, ob die Gültigkeit der Organisation oder der BSNR gemeint ist. hier dargestellt: Gültigkeit der BSNR --> <period> <start value="1995-05-01"/> <end value="2015-12-31"/> </period> </identifier> <!-- Aktiv/Inaktiv --> <active value="true"/> <type> <coding> <!-- Kennzeichen Haupt-/Nebenbetriebsstätte --> <!-- SL: Eigenes Value Set für den type, als Erweiterung von http://hl7.org/fhir/organization-type: prov-main: Hauptbetriebsstätte prov-sub: Nebenbetriebsstätte --> <system value="http://hl7.de/fhir/organization-type"/> <code value="prov-sub"/> <display value="Healthcare Provider, subsidiary"/> </coding> </type> <!-- Betriebsstättenbezeichnung --> <name value="Praxis Dr. Soundso"/> <telecom> <system value="phone"/> <value value="07223 12345"/> <use value="work"/> </telecom> <address> <use value="work"/> <line value="Musterstrasse 33"/> <city value="Irgendwo"/> <!-- PLZ --> <postalCode value="5555"/> <country value="DE"/> </address> <!-- KV-Bezirk --> <!-- SL: Die KV-Bezirke ergeben sich m.W. implizit aus Stelle 1 und 2 der BSNR, vgl. http://www.kbv.de/media/sp/Arztnummern_Richtlinie.pdf dort §6 und Anlage 1. Insofern wäre mit dem Fragesteller abzuklären, ob das evtl. redundant ist. --> </Organization>
Stefan Lang (Aug 18 2016 at 08:03):
KV-Bezirk könnte man auch als identifier.assigner abbilden. Das ist zwar auch ein String, meint aber genau das, was die KV-Bezirke in Bezug auf die BSNR sind.
Stefan Lang (Aug 18 2016 at 08:12):
Korrekter formuliert: identifier.assigner ist eine Reference auf eine Organization, aber; "Organization that issued id (may be just text)" ( https://www.hl7.org/fhir/datatypes.html#Identifier )
Simone Heckmann (Aug 18 2016 at 08:34):
Clever 
Peter Klauß (Aug 18 2016 at 08:35):
Wir haben in unserem Datenmodell bereits eine Entität "Betriebsstätte". Sie kann z.B. auch eine Abteilung in einem Krankenhaus sein oder ein MVZ, das sich im selben Gebäude wie das Krankenhaus befindet. Wie könnte eine Zuordnung erfolgen a'la "gib mir alle Betriebsstätten dieser Organisation? In unserem Modell enthält die Betriebsstätte ggf. die ID einer übergeordneten Einheit.
Simone Heckmann (Aug 18 2016 at 08:37):
Wir müssen auf jeden Fall auch die UseCases für die Suche beachten. Nicht, dass wir wichtige Informationen in Attributen verstecken, die gar keine Suchparamerer sind.
Simone Heckmann (Aug 18 2016 at 08:38):
Identifier.assigner wäre so ein Fall...
Simone Heckmann (Aug 18 2016 at 08:41):
Ich denke aber schon, dass wir eine Suche nach KV-Bezirk brauchen. Oder?
Simone Heckmann (Aug 18 2016 at 08:42):
Wir können allerdings auch einen eigenen Suchparamerer im Profil definieren. Müssten wir eh, wenn wir das über eine Extension abbilden würden.
Stefan Lang (Aug 18 2016 at 08:44):
@Peter Klauß Die Referenz auf Abteilungen bzw. generell Sub-Organisationen ist über das oben erwähnte partOf abbildbar.
Stefan Lang (Aug 18 2016 at 08:45):
Genauer: die Abteilungen/Sub-Organisationen referenzieren auf die übergeordnete Organisation
Stefan Lang (Aug 18 2016 at 08:52):
@Simone Heckmann Suche nach dem KV-Bezirk ist eine Frage des konkreten Use Case, den kennst Du wahrscheinlich gerade besser ;-)
Wie gesagt: eigentlich ist die Information redundant, da in der (suchbaren) BSNR bereits enthalten.
Generisch fallen mir allerdings auch einige Use Cases ein, bei denen das suchbar sein sollte. Wenn das also im Profil definierbar ist, sollten wir das m.E. tun und hätten das ganze ohne Extension gelöst.
Simone Heckmann (Aug 18 2016 at 09:38):
Ich muss mal prüfen, ob die token Suche nach Identifier auch partielle matches unterstützt...
Peter Klauß (Aug 18 2016 at 09:56):
Können Leistungserbringer auch an mehreren Betriebsstätten tätig sein?
Rico Tetmeyer (Aug 18 2016 at 11:40):
Ja
Rico Tetmeyer (Aug 18 2016 at 11:41):
Es können sich sogar Leistungserbringer Betriebsstätten teilen
Simone Heckmann (Aug 18 2016 at 11:57):
Leistungserbringer = Practitioner
Simone Heckmann (Aug 18 2016 at 12:00):
Die Zuordnung zu mehreren Betriebsstätten kann über PractitionerRole abgebildet werden.
Simone Heckmann (Aug 18 2016 at 12:00):
Haha. Das Freud'sche Android autocorrect hat aus Role Rolex gemacht 
Simone Heckmann (Aug 18 2016 at 12:00):
http://hl7-fhir.github.io/practitionerrole.html
Peter Klauß (Aug 18 2016 at 12:01):
ACK
Simone Heckmann (Aug 18 2016 at 12:04):
Gibt es denn "offizielle" Datenquellen für Betriebsstätten und Leistungserbringer?
Rico Tetmeyer (Aug 18 2016 at 12:05):
Da bin ich gerade dabei das zu erforschen. Hab bis jetzt nur Hausintern unser PM bemüht. Möchte aber gern nochmal nach Doku von der KBV zu dem Thema schauen.
Rico Tetmeyer (Aug 18 2016 at 12:14):
Aus dem offiziellen Dokument der KBV geht auch nicht wirklich mehr hervor.
http://www.kbv.de/media/sp/Arztnummern_Richtlinie.pdf
Rico Tetmeyer (Aug 18 2016 at 12:16):
Also würde ich grundsätzlich die Betriebsstätte mit einer Gültigkeit von/bis und der Art der Betriebsstätte (Haupt- oder Nebenbetriebsstätte) versehen
Rico Tetmeyer (Aug 18 2016 at 12:17):
Die PartOf-Variante ist für mich eher eine instanzspezifische individuelle Zuordnung
Rico Tetmeyer (Aug 18 2016 at 12:35):
Hab jetzt nochmal jmd Richtung KBV geschickt um deren Semantik hinter der Geschichte zu begreifen.
Stefan Lang (Aug 18 2016 at 13:25):
@Rico Tetmeyer Nochmal nachgehakt: die Betriebsstätte mit eigenem Gültigkeits-Zeitraum, differenziert von der Gültigkeit der BSNR?
Gibt es da einen Bedarf/Use Case im Kontext der (FHIR-)Kommunikation? Das würde sich dann auch mit dem active-Flag überschneiden, sprich: wäre active evtl. für die existierenden Use Cases ausreichend?
Rico Tetmeyer (Aug 18 2016 at 13:26):
Also so wie ich das aktuell sehe und verstehe ist die Betriebsstätte an sich mit der BSNR Gültig von/bis
Stefan Lang (Aug 18 2016 at 13:28):
Dann wäre das ja mit identifier.period passend und ausreichend.
Rico Tetmeyer (Aug 18 2016 at 13:28):
Das aktiv-Flag impliziert sich wahrscheinlich aus der Gültigkeit.
Stefan Lang (Aug 18 2016 at 13:29):
Richtig, das wäre im Grunde für diesen Use Case redundant
Rico Tetmeyer (Aug 18 2016 at 13:30):
Ich hatte jetzt noch gedacht ob es in dem UserCase Sinn macht das es eine noch gültige Betriebsstätte gibt die aber nicht aktiv genutzt wird
Stefan Lang (Aug 18 2016 at 13:31):
active := "Whether the organization's record is still in active use" - Klingt passend.
Rico Tetmeyer (Aug 18 2016 at 13:31):
Ja
Stefan Lang (Aug 18 2016 at 13:54):
Eine Stammdatei der Leistungserbringer gibt es übrigens, allerdings aus Datenschutzgründen anonymisiert:
ftp://ftp.kbv.de/ita-update/Stammdateien/SDAV/
Simone Heckmann (Aug 18 2016 at 17:34):
Der Vorteil von Extensions ist, dass Server, die sich nicht dafür interessieren diese einfach ignorieren können. Bei der Differenzierung mittels Type finde ich das schwieriger. Da müssten dann alle Clients sich bewusst sein, dass sie nach beiden Typen suchen müssen, wenn sie einfach nur einen Provider finden wollen... (Ich glaube Token Parameter unterstützen keinen partial match) Sheet neige ich eher zur Extension
Simone Heckmann (Aug 18 2016 at 17:34):
(deleted)
dr Kai U. Heitmann (Aug 19 2016 at 07:21):
@Simone Heckmann und @Stefan Lang : bitte denkt daran, dass diese Erkenntnisse auch in unser Wiki sollten, zB "Best practice" http://wiki.hl7.de/index.php?title=Kategorie:Best_practice
Stefan Lang (Aug 19 2016 at 08:56):
@Simone Heckmann Good point. Bei näherer Überlegung ist eine Extension auch semantisch sauberer. Das "Haupt-" bzw. "Neben-" ist ja letztlich eine zusätzliche qualifizierende Information.
Rico Tetmeyer (Aug 19 2016 at 09:04):
@Simone Heckmann @Stefan Lang Die Art der Betriebsstätte sehe ich auch in einer Extension. Das ist nur durch die Vokal etwas überladen, eigentlich könnte es auch die Farbe sein. Dem entsprechend ist das nur eine Eigenschaft einer Betriebsstätte und mehr nicht.
Stefan Lang (Aug 19 2016 at 09:11):
@dr Kai U. Heitmann Berechtigte Anmerkung(en). Wobei die Punkte ja noch nicht so weit gediehen sind, dass man hier von einer Best Practice sprechen kann.
@Simone Heckmann Ich denke, da letztlich die Zwischen- und Endergebnisse in Simplifier oder ggf. Forge landen, reicht im WIki ein kurzer Background-Text mit entsprechenden Links zu (z.B.) dem Profil auf Simplifier. Quasi als landing spot
Simone Heckmann (Aug 22 2016 at 13:09):
Also ich bin auf jeden Fall der Meinung, dass der Gültigkeitszeitraum einer Betriebsstätte als Gültigkeit des Identifiers korrekt abgebildet wäre. Die Organisation wird ja dadurch zur Betriebsstätte, dass sie über einen Identifier vom Typ "BSNR" verfügt. Wenn der Vertrag mit der KBV endet (warum auch immer), dann ist die Organisation keine Betriebsstätte mehr, aber trotzdem noch eine Organisation, die auch weiterhin Gesundheitsdienstleistungen erbringen kann (gegen Cash). Wenn die Organisation komplett die Pforten schließt (wegen Alters oder Reichtums) dann wird die Organisation inaktiv. Das Ereignis "Ende der Betriebsstätte" und "Ende der Organisation" werden sicherlich häufig zusammenfallen, aber eben nicht immer...
Simone Heckmann (Aug 22 2016 at 13:09):
Nebenfrage: Hat jede BSNR immer ein ENDE-Datum? Oder kann das auch mal offen bleiben ("auf unbestimmte Zeit...")
Simone Heckmann (Aug 22 2016 at 13:14):
Außerdem: Sind alle Betriebsstätten vom Typ "prov", also Health-Care-Provider? Oder gibt's auch andere?
http://hl7.org/implement/standards/fhir/valueset-organization-type.html
Simone Heckmann (Aug 22 2016 at 13:23):
Ist dieses Kennzeichen Haupt/Nebenstelle seitens der KBV irgendwie codiert? z.B. als H/N oder so?
Simone Heckmann (Aug 22 2016 at 13:58):
Folgende Anfrage hat mich erreicht:
In unseren konkreten Fall mit der Betriebsstätte geht es darum dass eine “Fremdsoftware” die Betriebsstätten unseres Primärsystems haben möchte um im weiteren Workflow Daten bzw. Eingaben für einen Rückschrieb ins Primärsystem korrekt zuordnen zu können.
Die Betriebsstätte ist aktuell mit folgenden Eigenschaften definiert:
*Betriebsstättenbezeichnung
*Kennzeichen Haupt-/Nebenbetriebsstätte
*Betriebsstättennummer
*KV-Bezirk
*PLZ
*Gültig von/bis
*Aktiv/Inaktiv
Simone Heckmann (Aug 22 2016 at 13:58):
Mein erster Aufschlag zur Modellierung sieht so aus:
```lang=xml
<?xml version="1.0" encoding="UTF-8"?>
<Organization xmlns="http://hl7.org/fhir">
<identifier>
<use value="usual"/>
<system value = "http://kbv.de/BSNR"/>
<value value="12345"/>
</identifier>
<active value="true"/>
<type>
<coding>
<system value="http://hl7.org/fhir/organization-type"/>
<code value="prov"/>
<display value="Healthcare Provider"/>
</coding>
</type>
<name value="Praxis Dr. Soundso"/>
<telecom>
<system value="phone"/>
<value value="07223 12345"/>
<use value="work"/>
</telecom>
<address>
<use value="work"/>
<line value="Musterstrasse 33"/>
<city value="Irgendwo"/>
<district value="KV-Bezirk 123"/>
<postalCode value="5555"/>
<country value="DE"/>
</address>
</Organization>
Stefan Lang (Aug 22 2016 at 16:16):
Ad Gültigkeit: die Regel dürfte der Fall "auf unbestimmte Dauer" sein.
Stefan Lang (Aug 22 2016 at 16:18):
Ad "prov-only": Wikipedia sagt: "Die Betriebsstättennummer, kurz BSNR, ist eine neunstellige Nummer, die im Rahmen der vertragsärztlichen Versorgung den Ort der Leistungserbringung (Betriebsstätte) eindeutig identifiziert. Weitere Orte der Leistungserbringung werden mit einer Nebenbetriebsstättennummer (NBSNR) belegt."
Der Ort der Leistungserbringung eines Arztes dürfte immer ein Healtcare Provider sein.
Simone Heckmann (Aug 22 2016 at 16:18):
demnach:
period.start 1..1
period.end 0..1
im BSNR-Slice für Observation.identifier
Simone Heckmann (Aug 22 2016 at 16:20):
Mooooooomentchen. Heißt das wir haben gar keine unterschiedlichen Betriebsstätten-Typen, sondern statt dessen zwei unterschiedliche Namespaces für Haupt- und Nebenbetriebsstätten?
Stefan Lang (Aug 22 2016 at 16:20):
Hehe, das fiel mir auch gerade beim Lesen auf ;)
Stefan Lang (Aug 22 2016 at 16:21):
(ad period) Ich würde period.start nicht erzwingen wollen, eher 0..1. Dann kann man auch z.B. ausdrücken "galt nur bis 31.12.2015, aber ich weiß nicht seit wann"
Stefan Lang (Aug 22 2016 at 16:22):
NBSNR: In dem Fall hätten wir tendenziell vielleicht 2 identifier, aber kein separates Kennzeichen H/N
Simone Heckmann (Aug 22 2016 at 16:23):
...also brauchen wir gar keine Extension für den Type, sondern statt dessen zwei Slices auf den Identifier, einmal mit Namespace http://kbv.de/BSNR und einmal mit Namespace http://kbv.de/NBSNR ...?
Simone Heckmann (Aug 22 2016 at 16:28):
In weiser Voraussicht habe ich beim letzten Connectathon schon mal die Token-Suche der Form [parameter]=[system]| durchgeboxt. 
http://hl7-fhir.github.io/search.html#token
Also hätten wir dann auch eine Möglichkeit, z.B. nur nach Hauptbetriebsstätten (ohne Angabe einer konkreten BSNR) zu suchen, mit .../Organization?identifier=http://kbv.de/BSNR|
Simone Heckmann (Aug 22 2016 at 16:30):
Allerdings: Eine Suche nach allen Organisationen, die Betriebsstätten sind (egal ob Haupt-oder Neben-Betriebsstätte) wird hässlich...
Stefan Lang (Aug 22 2016 at 16:37):
Und es ist zu klären, ob im Quellsystem bei einer Nebenbetriebsstätte tatsächlich auch die NBSNR übermittelt werden soll. Sonst wird's auch hässlich
Stefan Lang (Aug 22 2016 at 17:56):
Also was ich meine: es ist zu klären, was genau übermittelt werden soll.
A) "Diese Organisation ist eine Nebenbetriebsstätte der Betriebsstätte 123456789" => BSNR-Identifier + "H/N"-Extension
oder B) "Diese Organisation ist die Nebenbetriebsstätte 987654321 einer Betriebsstätte" => NBSNR-Identifier
oder C) "Diese Organisation ist die Nebenbetriebsstätte 987654321 der Betriebsstätte 123456789
Variante C1: => NBSNR-Identifier + BSNR-Extension (die BSNR ist ja kein eindeutiger Identifier dieser Nebenbetriebsstätte)
Variante C2: => NBSNR-Identifier + partOf mit Referenz zur Haupt-Betriebsstätte (sauberer, aber eventuell in Real World Systemen so nicht abgebildet)
Was sagt denn der Use Case dazu?
Simone Heckmann (Aug 22 2016 at 18:17):
Ich frage mich gerade, ob es sein kann, dass eine Betriebsstätte gleichzeitig Haupt- und Nebenbetriebsstätte sein kann (vielleicht in unterschiedlichem Kontext) und ob wir BSNR und NBSNR überhaupt in einem gemeinsamen Namespace halten dürften oder ob dann die Eindeutigkeit nicht mehr gewährleistet wäre... So wie ich es verstehe, sind das wirklich getrennte Nummernsysteme...
Ich denke B) wird's werden, da ja aus den Quelldaten wohl nicht hervorgeht, zu welcher Hauptbetriebsstätte eine Nebenbetriebsstätte gehört. Die partOf-Referenz herzustellen würde ich dann als freiwillige Fleißarbeit betrachten...
Stefan Lang (Aug 22 2016 at 18:23):
Es reicht ja, partOf im Profil zu erlauben. Tut, denke ich, nicht weh.
Simone Heckmann (Aug 22 2016 at 18:31):
Im Prinzip sollte es ja eines Tages auch so sein, dass sich keiner mehr darüber Gedanken zu machen braucht wie man die Resourcen *erstellt*, weil irgendwo ein zentraler/offizieller KBV-Betriebsstätten-FHIR-Server steht, bei dem man die Resourcen einfach anfragen kann. 
Stefan Lang (Aug 22 2016 at 18:35):
Was wäre das Leben ohne Träume :D
Simone Heckmann (Aug 22 2016 at 19:42):
Ich hab schon mal angefangen zu profilieren (ist allerdings noch etwas aufgeblasen, das Simplifier noch keine Differentials macht)
https://simplifier.net/FHIRABENDSandbox/KbvBetriebsstaette
In dieser Version noch mit Extension und nur einem Slice für den Identifier...
Rico Tetmeyer (Aug 23 2016 at 05:34):
Ich muss das PartOf-Thema leider nochmal auspacken. Haben in der Zwischenzeit Antwort von einer KV erhalten die da sagen: "...In der KVBW existieren eindeutige Zuordnungen der Nebenbetriebsstättennummer (NBSNR) zu den Hauptbetriebsstättennummer (HBSNR). Die eindeutigen Zuordnungen sind für die KVBW unbedingt erforderlich..."
Rico Tetmeyer (Aug 23 2016 at 05:35):
Dem entsprechend wäre es sinnvoll zusätzlich zu der Kennung ob es eine Haupt- oder Nebenbetriebsstätte ist, noch hirarchisch zu glieder.
Rico Tetmeyer (Aug 23 2016 at 05:36):
@Simone Heckmann Eine Betreibsstätte ist immer nur Haupt- oder Nebenbetriebsstätte
Stefan Lang (Aug 23 2016 at 07:19):
@Rico Tetmeyer Dann ist es zur Übermittlung dieser Beziehung m.E. klar partOf
Stefan Lang (Aug 23 2016 at 07:21):
Die KBV-Stammdatei ( ftp://ftp.kbv.de/ita-update/Stammdateien/SDAV/ , siehe oben) bildet diese Hierarchie BSNR : NBSNR 1:n auch klar ab
Simone Heckmann (Aug 23 2016 at 07:42):
Letzter Stand der Diskussion (ich hoffe, ich habe nichts vergessen/überlesen):
<?xml version="1.0" encoding="UTF-8"?> <Organization xmlns="http://hl7.org/fhir"> <!-- Betriebsstättennummer --> <identifier> <use value="usual"/> <system value="http://kbv.de/BSNR"/> <value value="123456700"/> <!-- Gültigkeitszeitraum der BSNR --> <period> <start value ="01-01-2016"/> <end value ="31-12-2019"/> </period> </identifier> <!-- ...oder alternativ: Nebenbetriebsstättennummer --> <identifier> <use value="usual"/> <system value="http://kbv.de/NBSNR"/> <value value="987654300"/> <!-- Gültigkeitszeitraum der NBSNR, wenn Ende unbekannt --> <period> <start value ="01-01-2016"/> </period> </identifier> <!-- Aktiv/Inaktiv (Pflichtfeld)--> <active value="true"/> <!-- Typ = Healthcare-Provider (prov), fixed value--> <type> <coding> <system value="http://hl7.de/fhir/organization-type"/> <code value="prov"/> <display value="Healthcare Provider"/> </coding> </type> <!-- Betriebsstättenbezeichnung --> <name value="Praxis Dr. Soundso"/> <telecom> <system value="phone"/> <value value="07223 12345"/> <use value="work"/> </telecom> <address> <use value="work"/> <line value="Musterstrasse 33"/> <city value="Irgendwo"/> <postalCode value="55555"/> <country value="DE"/> </address> <!-- Bei Nebenbetriebsstätten: Referenz zur zugeordneten Hauptbetriebsstätte --> <partOf> <reference value="Organization/1337"/> </partOf> </Organization>
Offene Punkte:
*Suche nach KV-Bezirk über BSNR Ziffern 1-2 möglich/erforderlich?
*Suche nach allen Organisationen, die Betriebsstätten sind, unabhängig ob BS oder NBS ist kompliziert!
- Ist Type = prov als fixed value ok, oder gibt's Ausnahmen?
- Brauchen wir noch Constraints der Form: "Wenn NBSNR, dann *muss* eine partOf-Referenz angegeben werden" oder "Wenn BSNR, dann darf nicht gleichzeitig eine NBSNR angegeben werden", oder ist das overkill?
...weitere?
Simone Heckmann (Aug 23 2016 at 07:48):
Wer sich ein Fleißsternchen verdienen möchte, kann ja noch auf die zuständige KV referenzieren:
<identifier> <use value="usual"/> <system value="http://kbv.de/BSNR"/> <value value="123456700"/> <!-- Gültigkeitszeitraum der BSNR --> <period> <start value ="01-01-2016"/> <end value ="31-12-2019"/> </period> <!-- Referenz auf zuständige KV (Organisation)--> <assigner> <reference value = "Organization/1234"/> <display value = "KV Baden-Württemberg"/> </assigner> </identifier>
Simone Heckmann (Aug 23 2016 at 07:53):
...spätestens für die KV-Organization bräuchten wir dann aber einen neuen (deutschen!) Wert im ValueSet http://hl7-fhir.github.io/valueset-organization-type.html :D
Simone Heckmann (Aug 23 2016 at 18:53):
"In den Arztstammdaten wird hinterlegt, ob es sich bei einer Betriebsstättennummer um die Nummer einer Betriebsstätte oder einer Nebenbetriebsstätte handelt." (https://de.wikipedia.org/wiki/Betriebsst%C3%A4ttennummer#Vergabe) Huh? Jetzt komm ich gar nicht mehr klar. In den *Arzt*stammdaten? ...also beim Practitioner...?!
Simone Heckmann (Aug 23 2016 at 19:04):
Ah jetzt: "Jede Betriebstätte und jede Nebenbetriebsstätte nach den Definitionen des BMV-
Ä erhält jeweils eine Betriebsstättennummer" (http://www.kbv.de/media/sp/Arztnummern_Richtlinie.pdf)
Daraus folgere ich jetzt mal, dass auch Nebenbetriebsstättennummern BSNRs sind. Es gibt also nur einen Namensraum.
Rico Tetmeyer (Aug 24 2016 at 04:35):
Ja genau
Rico Tetmeyer (Aug 24 2016 at 04:35):
Wie gesagt, das sind bis auf die Unterscheidung ob Haupt- oder Nebenbetriebsstätte identische Entitäten
Stefan Lang (Aug 24 2016 at 08:16):
Die KBV-Stammdateien sind nicht immer völlig normalisiert ;-) Das "Arztstammdaten" würde ich also hier zunächst mal überlesen.
Zu den Namensräumen kann man jetzt in eine Detaildiskussion einsteigen, ob die offenbar vorliegende Tatsache, dass keine 9-stellige Ziffernfolge gleichzeitig BSNR und NBSNR ist, auch bedeutet, dass es sich um einen gemeinsamen Namespace handelt.
Ich finde die Lösung mit den separaten BSNR / NBSNR Namespace jedenfalls elegant und zweckmäßig.
Stefan Lang (Aug 24 2016 at 08:19):
partOf würde ich optional halten; hatten wir oben auch schon mal diskutiert.
Fixed "prov" sehe ich schon als gesetzt. Würde ich aber, z.B. beim Interopforum, einfach mal in die Runde fragen wollen.
Simone Heckmann (Aug 24 2016 at 09:25):
Am separaten Namespace gefällt mir die Tatsache nicht, dass die Suche nach "allen Betriebsstätten" damit kompliziert und kontraintuitiv wird. (Man müsste erst Organization?identifier=<BSNR-Namespace>| und dann nach Organization?identifier=<NBSNR-Namespace>| suchen, dann die Ergenisse kombinieren und sortieren...
Simone Heckmann (Aug 24 2016 at 09:26):
Eventuell gibt es auch eine Syntax für die oder-Suche nach beiden Namespaces, aber da wäre dann wieder die Frage: Wie viele Server unterstützen das?
Simone Heckmann (Aug 24 2016 at 09:27):
Ich würde vermuten dass die Frage, ob eine BS eine BS oder eine NBS ist, in den meisten Fällen eher zweitrangig ist.
Stefan Lang (Aug 24 2016 at 09:38):
Ist natürlich ein berechtigter Einwand.
Es mag sogar Subsysteme geben, die gar nicht zwischen BS und NBS unterscheiden (ich kenne bei näherer Überlegung mindestens eins ;-).
Also dann doch nur BSNR + H/N-Extension?
Rico Tetmeyer (Aug 24 2016 at 09:41):
Ja das fände ich auch besser, im Normalfall spielt die Art keine besondere Rolle
Simone Heckmann (Aug 24 2016 at 11:33):
+1 für Extension. Ob wir dafür dann auch einen Suchparameter brauchen wird sich zeigen. Ich gehe zunächst mal nicht davon aus, bis mich jemand vom Gegenteil überzeugt.
Simone Heckmann (Aug 24 2016 at 11:40):
Cool: /Organization?_include=Organization:partof&identifier=<BSNR>|123456789&partof.identifier=<BSNR>|müsste die Betriebsstätte mit der ID 123456789 zurückgeben und (sofern vorhanden) die übergeordnete BS. Übergeordnete Organisationen, die keine BS sind, würden ignoriert. Muss ich bei Gelegenheit mal verifizieren...
Simone Heckmann (Aug 24 2016 at 13:47):
Vorschlag: Wir machen die Extension boolean (istHauptbetriebsstaette=true|false) spart uns schon mal die Arbeit, Codes definieren zu müssen und sollte den UseCase bündig abdecken.
Stefan Lang (Aug 24 2016 at 13:50):
Boolean gern. In Abwesenheit der Information sollte das empfangende System dann m.E. ein true annehmen.
Simone Heckmann (Aug 24 2016 at 14:16):
Hmm... je länger ich darüber nachdenke: Ich vermute mal, die meisten Betriebsstätten sind Hauptbetriebsstätten und Nebenbetriebsstätten sind eher der Sonderfall? Demnach sollten wie eher die Ausreißer kennzeichnen, also istNebenbetriebsstätte=true|false. Alles was nicht explizit als Nebenbetriebsstätte gekennzeichnet ist, würde man dann als Hauptbetriebsstätte annehmen können. Aber ich vermute, das ist ziemlich egal..
Patrick Werner (Aug 24 2016 at 14:18):
fände ich auch schöner. Ist der boolsche Wert nicht spezifiziert nehmen wir einfach false an und gehen von einer Hauptbetriebstätte aus. Entspricht auch dem Coden: boolsche Variablen werden als false initialisiert :)
Stefan Lang (Aug 24 2016 at 14:33):
Mit Zahlen untermauert: die aktuelle Stammdatei zählt 155.410 unique (Haupt)BSNR und 27.658 unique NBSNR.
Die Haupt-BSNR ist damit definitiv der Normalfall.
"isNeben" oder "isHaupt" ist im Grunde egal, solange das Fehlen zu Haupt führt. Patricks Argument mit dem Default-Boolean bringt vielleicht den Ausschlag zu "isNeben" ;-)
Rico Tetmeyer (Aug 25 2016 at 04:31):
Finde ich nicht so schön. Auch wenn es nur eine zweistellige Enumeration ist sollte man es so abbilden.
Rico Tetmeyer (Aug 25 2016 at 04:33):
Wenn ich die Definitionen der KBV lese wundert es mich auch das es nicht sogar mehr Neben- als Hauptbetriebstätten gibt.
Simone Heckmann (Aug 25 2016 at 07:55):
Hm. Also ich habe immer nur von der Unterscheidung Haupt/Neben-BS gelesen. Die KBV selbst hat keine Liste von Betriebsstätten-Kategorien, sondern markiert auch nur den Sonderfall "Wenn Nebenbetriebsstätte, dann...". Zumindest lese ich das so. Die geringe Zahl der Nebenbetriebsstätten erschließt sich mir dadurch, dass die meisten Praxen nur an einem Standort tätig sind und nicht mehrer "Filialen" betreiben. Das ist eher ein Phänomen, das man bei Apotheken oder Sanitätshäusern antrifft, aber selten bei Arztpraxen...
Stefan Lang (Aug 25 2016 at 11:13):
Vermute ich auch. Filialwesen bei Praxen ist nicht sehr üblich. Das betrifft wahrscheinlich wenn, dann eher Fachärzte, die z.B. regional 2-3 Praxen haben
Rico Tetmeyer (Aug 25 2016 at 11:50):
Viele Hausarztpraxen haben eine Nebenbetriebsstätte zBsp im Pflegeheim, das ist nicht genau so viele sind wie Hauptbetriebsstätten ist klar trotzdem hat gut jede sechste HBSNR eine NBSNR und es sind halt verschiedene Arten und nicht Hauptbetriebsstätte=true/false
Rico Tetmeyer (Aug 25 2016 at 11:51):
Auch wenn es für die Enumeration nur zwei Zustände gibt fände ich deshalb die Abbildung als bool falsch.
Rico Tetmeyer (Aug 25 2016 at 11:52):
Aber das ist vielleicht auch Geschmackssache, wie ist bei dem Thema generell der weitere Lauf?
Rico Tetmeyer (Aug 25 2016 at 11:53):
Wir die Resource + Extension dann in ein Basisprofil gepackt und irgendwo veröffentlicht?
Simone Heckmann (Aug 25 2016 at 11:57):
Ich habe den letzten Stand unserer Diskussion bereits in ein Profil + Extension gepackt. Allerdings habe ich noch ein technisches Problem, was zur Folge hat, dass das Rendering der Resource etwas verkrüppelt aussieht:
https://simplifier.net/FHIRABENDSandbox/KBV-Betriebsstaette
Bevor wir veröffentlichen, wäre es sinnvoll, dass mindestens ein Hersteller eine Prototyp-Implementierung macht und uns ein Feedback gibt, ob das Profil auf den UseCase passt. Wer käme denn da in Frage?
Simone Heckmann (Aug 25 2016 at 12:06):
Momentan sind unsere Profile ja zunächst mal eine Ideensammlung zum Thema "Betriebsstätte". Für konkret implementierbare Profile müssten wir erst mal festlegen aus wessen Sicht und zu welchem Zweck wir das Profil erstellen.
Wollen wir mit dem Profil beschreiben, welche Daten eine Server liefern *muss*, der den Clients eine Art "Betriebsstätten-Telefonbuch" zur Verfügung stellen will? Oder beschreiben wir, welche Daten ein Client mindestens kennen *muss*, um eine Betriebsstätte zu einem bestimmten Zweck (Abrechnung?) identifizieren zu können? Wir sollten uns hier ein wenig am "IHE-Sprech" orientieren: Wer sind die Akteure? Was sind die Transaktionen?
Simone Heckmann (Aug 25 2016 at 12:30):
@Rico Tetmeyer : Im Prinzip hast du dich mit der Eingangsfrage ja schon als Implementierer für die Server-Seite freiwillig gemeldet, oder? =)
Simone Heckmann (Aug 25 2016 at 12:33):
Beinhaltet euer UseCase nur die Bereitstellung von Betriebsstätten, oder auch von Leistungserbringern?
Simone Heckmann (Aug 25 2016 at 12:47):
Ich würde mich ggf. auch mal daran Versuchen, einen Konverter zu bauen, der aus den KBV-Quelldaten FHIR-Resourcen erstellt. Hat jemand Quelldaten mit denen ich üben könnte? Was haben die für ein Format? Ist das XML?
Stefan Lang (Aug 25 2016 at 13:04):
Welche Quelldaten meinst Du? BSNR/NBSNR? Die sind anonymisiert und in einem xDT-artigen Format
Simone Heckmann (Aug 25 2016 at 13:05):
Äh. Wenn die anonymisiert sind, wie weiß ich dann, welche BSNR zu welcher Praxis gehört?
Stefan Lang (Aug 25 2016 at 13:08):
Das weißt Du nicht, und das ist, soweit ich gelesen habe, Absicht.
Stefan Lang (Aug 25 2016 at 13:09):
(Nein, ich hab keinen Sonnenstich )
Stefan Lang (Aug 25 2016 at 13:11):
"Die vorliegende Satzbeschreibung geht aus der Datensatzbeschreibung mit Stand
15.05.2000 (Versionsbezeichnung: SDAV0499.02) hervor. Aus datenschutzrechtlichen
Gründen wurden die persönlichen und adressbezogenen Daten eliminiert."
Stefan Lang (Aug 25 2016 at 13:12):
Q: ftp://ftp.kbv.de/ita-update/Stammdateien/SDAV/KBV_ITA_VGEX_Datensatzbeschreibung_SDAV.pdf
Simone Heckmann (Aug 25 2016 at 13:12):
ja, drum dachte ich, dass es irgendwo ja auch nicht-anonymisierte Daten oder Testdaten geben müsste...
Stefan Lang (Aug 25 2016 at 13:13):
Mit Sicherheit. Aber sehr wahrscheinlich nicht öffentlich zugänglich.
Simone Heckmann (Aug 25 2016 at 13:13):
Ich frag mal im Darknet... :)
Stefan Lang (Aug 25 2016 at 13:14):
5 US-ct pro Adresse
Patrick Werner (Aug 25 2016 at 13:14):
:) nicht dass dich der Herr de Maiziere dort erwischt
Stefan Lang (Aug 25 2016 at 13:14):
Ist für Darknet nicht der Öttinger zuständig?
Patrick Werner (Aug 25 2016 at 13:15):
auf EU Ebene ja
Simone Heckmann (Aug 25 2016 at 13:15):
Gleich macht die NSA den deutschen Zulip-Stream dicht :D
Stefan Lang (Aug 25 2016 at 13:15):
Stefan Lang (Aug 25 2016 at 13:16):
On Topic: Zumindest gibt es bei der KBV offenbar nicht mal eine XKM-verschlüsselte Variante, die dann von den zertifizierten Systemherstellern gelesen werden könnte ...
Stefan Lang (Aug 25 2016 at 13:16):
... und Namen/Adressen enthielte
Simone Heckmann (Aug 25 2016 at 13:19):
Tja, dann kann ich zum Implementierungsteil leider nichts beitragen...
Stefan Lang (Aug 25 2016 at 13:21):
Jep, das ist leider wirklich nur institutionsspezifisch darstellbar, fürchte ich.
Stefan Lang (Aug 25 2016 at 13:23):
Um noch ein bisschen zu jammern: Du kannst zwar über Jameda & Co. die Daten von 275.000 Ärzten einsehen und über die KBV die Nummern, aber Du darfst sie nicht zusammenbringen ...
Simone Heckmann (Aug 25 2016 at 13:25):
Ich erinnere mich dunkel aus meiner Zeit "an der Front", dass die Pflege der Zuweiserdaten in den KIS-Systemen immer ein Krampf war. Da gab's wohl CDs mit den Adressdaten, aber immer nur pro KV-Bezirk. Ob da BSNRs und LANRs drin waren, weiß ich nicht...
Stefan Lang (Aug 25 2016 at 13:28):
Höchstwahrscheinlich schon. Aber halt auch nur regional und auf sicherem Weg transportiert (CD, hüstel). Und wahrscheinlich zusätzlich verschlüsselt.
Auf jeden Fall nix, das man mal eben schnell durch nen Parser jagt
Rico Tetmeyer (Aug 26 2016 at 06:33):
Also die Implementierung ist bei uns für Ende des Jahres geplant, könnte das sobald es ernst wird nochmal vermelden.
Simone Heckmann (Aug 26 2016 at 06:59):
Super! Danke! Vielleicht finden wir noch ein paar Client-Kandidaten. Ich frage beim nächsten Interop-Forum mal in die Runde. Dann könnten wir gegen Jahresende vielleicht einen Mini-Connectathon veranstalten um den Zwischenstand zu testen. Seid ihr bei den Developer Days im November dabei?
Rico Tetmeyer (Aug 29 2016 at 08:19):
Bis jetzt noch nicht. Kommt ein wenig auf unsere Fortschritte bis dahin an.
Simone Heckmann (Nov 23 2016 at 10:45):
Vorschlag für die Haupt/Nebenbetriebsstätten-Extension: https://simplifier.net/BasisprofilDE/betriebsstaetten-hierarchie2/rendered
Simone Heckmann (Nov 23 2016 at 10:46):
mit Zugehörigem ValueSet: https://simplifier.net/BasisprofilDE/betriebsstaetten-hierarchie
Simone Heckmann (Jan 16 2017 at 23:02):
FYI: Die Kardinalität von Organization.type wurde gerade auf 0..* geändert. Hilft uns das?
Simone Heckmann (Jan 16 2017 at 23:05):
...damit könnten wir Organisationen als generische "Betriebsstätten", aber gleichzeitig auch zu Haupt- oder Nebenbetriebsstätten typisieren... Ich habe aber noch keine Meinung dazu, ob das besser oder schlechter als eine Extension ist)
Stefan Lang (Jan 18 2017 at 21:17):
Spontan würde ich sagen: nice, passt
Stefan Lang (Mar 27 2017 at 18:36):
Ich hole diesen Thread nochmal hoch:
Für die (Haupt-)BSNR und Neben-BSNR gab's schonmal was von HL7-D v2 (keine Ahnung, ob das finalen Status hat): http://wiki.hl7.de/index.php?title=LANR_und_BSNR#Antwort
Stefan Lang (Mar 27 2017 at 18:36):
Demnach wäre unser ValueSet konsistenterweise "BSNR" und "NBSNR" statt "Haupt" und "Neben"
Simone Heckmann (Mar 31 2017 at 20:38):
Wären BSNR und NBSNR nich zwei verschiedene Identifier-Namespaces? Wenn man die Akronyme ganz ausspricht, dann sind es ja eher zwei verschiedene Arten von Betriebsstätten-Identifiern als verschiedene Arten von Betriebsstätten...
Stefan Lang (Mar 31 2017 at 21:45):
Es gibt nur BSNummern, egal ob Haupt oder Neben (hatten wir vor einiger Zeit schon mal nachgeforscht). Insofern nur ein Namespace/NamingSystem.
Wir hatten dabei auch festgestellt, dass es wichtig sein kann, zwischen Haupt- und Neben-BS zu unterscheiden, daraus kam dieses ValueSet:
https://simplifier.net/BasisprofilDE/betriebsstaetten-hierarchie - mein Vorschlag zielte nur darauf, die Codes mit v2 zu harmonisieren
Simone Heckmann (Apr 03 2017 at 09:34):
Ja. stimmt, da war was. Es ist etwas gewöhnungsbedüftig, dass wir "HS*NR*" und BS*NR*" sagen, obwohl wir eben explizit nicht den Typ der *Nummer* sondern den Typ der Betriebsstätte meinen :)
Aber das bisherige "Haupt" und "Neben" war ja grammatikalisch auch nicht der Brüller, daher um der Harmonisierung Willen:
D'Accord :)
Stefan Lang (Apr 03 2017 at 10:06):
[x] changed
Peter Scholz (Apr 05 2017 at 10:46):
Btw. der Wiki Artikel bzgl BSNR ist nicht normativ, die Abstimmung zu der Empfehlung ist auf Grund mangelnder Teilnahme kein Beschluss des TCs
Den Simplifier Link kann ich nicht lesen
Stefan Lang (Apr 05 2017 at 13:00):
Aber es ist das "normativste", das dazu existiert, oder?
Stefan Lang (Apr 05 2017 at 13:00):
Simplifier hat gerade Probleme:
"Last Friday we upgraded to a new framework to prepare for STU3. Since then we have been experiencing stability issues a few times a day. The whole team is working very hard to resolve this. "
Stefan Lang (Apr 05 2017 at 13:01):
Da funktioniert im Moment nicht mal die Login-URL
Simone Heckmann (May 08 2017 at 10:06):
Wir haben jetzt ein STU3-Profil für die Betriebsstätte, die hoffentlich die Ergebnisse der bisherigen Abstimmung zufriedenstellend wiedergibt:
Ich bitte um Kommentare, Kritik und Anregungen zum Profil: https://simplifier.net/BasisprofilDE/organization-de-betriebsstaette/rendered
bzw. zum Beispiel: https://simplifier.net/BasisprofilDE/Example-organization-de-betriebsstaette-1/xmlview
Peter Scholz (May 12 2017 at 08:37):
Sorry ich hatte lange nicht mehr in den Thread geschaut.
Peter Scholz (May 12 2017 at 08:41):
Wenn man sich die (unabgestimmte und somit nicht verbindliche) Empfehlung des TC V2 aus 2008 ansieht,
ist dort die BSNR lediglich ein Attribut der Adresse nicht jedoch der Organisation, die ist ja über alle N(BSNR) identisch.
Insofern muss die Extension unterhalb der Adresse und nicht unterhalb der Organization sein.
Peter Scholz (May 12 2017 at 08:54):
Also so: XML Beispiel:
<Organization> <meta> <profile value="http://fhir.de/StructureDefinition/organization-de-betriebsstaette"/> </meta> <name value="Gemeinschaftspraxis Dres. Mustermann und Beispielfrau"/> <address> <extension url="http://fhir.de/StructureDefinition/betriebsstaetten-hierarchie"> <valueCode value="BSNR"/> </extension> <extension url="http://fhir.de/StructureDefinition/betriebsstaetten-identifier"> <valueIdentifier> <system value="http://fhir.de/NamingSystem/kbv/bsnr"/> <value value="123456789"/> <period> <start value="2015-01-01"/> </period> <assigner> <display value="KV Baden-Württemberg"/> </assigner> </valueIdentifier> </extension> <line value="Musterstraße 1"> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-houseNumber"> <valueString value="1"/> </extension> <extension url="http://hl7.org/fhir/StructureDefinition/iso21090-ADXP-streetName"> <valueString value="Musterstraße"/> </extension> </line> <city value="Musterstadt"/> <postalCode value="77777"/> <country value="DE"/> </address> </Organization>
Stefan Lang (May 12 2017 at 09:26):
Interessant!
Genau genommen ist eine BSNR ist natürlich ganz sicher nicht ein Identifier einer reinen Adresse, denn wenn die Praxis umzieht, gilt die BSNR ja nicht für diese Adresse weiter. Sie ist also der Identifikator der Organisation (sprich: Niederlassung) an dieser Adresse.
Die Niederlassung kann ja wieder Teil einer höheren (Haupt-)Organisation sein (Organization.partOf).
Von daher sehe ich die BSNR schon eher als Identifier der Organization.
Zusätzliches Argument in diese Richtung: die Niederlassung kann ja auch mehrere Adressen haben (z.B. postal, physical), die aber definitiv keine unterschiedlichen BSNRn haben.
Ich denke also, die Abbildung in v2 ist eher den Limitierungen von v2 geschuldet und würde die BSNR in Organization.identifier lassen.
Stefan Lang (May 12 2017 at 09:28):
(btw: ist das Absicht, dass die Referenz im Beispiel an address.line hängt? Sollte wenn, dann doch an address hängen)
Peter Scholz (May 12 2017 at 09:41):
oops, das war verrutscht ich hab das Beispiel dahingehend korrigiert.
Und nein die Abbildung in V2 war nicht den Limitierungen von V2 geschuldet,
der Text dazu lautet auch:
Die (N)BSNR stellt aber eine Adresse dar, so dass diese Information – um Missverständnisse zu vermeiden – nicht in demselben Feld untergebracht werden kann.
Und nein verschiedene Niederlassungen in diesem Zusammen sind nicht Unterorganisationen sondern lediglich unterschiedlich Standorte
Aus der KBV Richtlinie zure Vergabe von LANR und BSNR:
Die Betriebsstättennummer ermöglicht die Zuordnung ärztlicher Leistungen zum
Ort der Leistungserbringung.
Die BSNR ändert sich im Übrigen nicht wenn sich die Personen innehalb der Betriebsstätte ändern. Zu deutsch wenn aus der Praxisgemeinschaft Drs Jeckyll und Hyde die Praxisgemeinschaft Drs Frankenstein und Lector wid so bleibt die BSNR bestehen, obwohl es eine völlig anderer Organisation ist.
Stefan Lang (May 12 2017 at 09:53):
Frankenstein & Lector sind doch aber Rechtsnachfolger von Jeckyll & Hyde, oder?
Stefan Lang (May 12 2017 at 09:54):
Mit "Ort der Leistungserbringung" ist sicher nicht der physische Ort allein gemeint, sonst hätten ja alle Praxen in einem MVZ jeweils dieselbe BSNR ;)
Stefan Lang (May 12 2017 at 09:56):
Die Frage ist also: ist ein Standort immer eine Organization im FHIR-Sinn?
Stefan Lang (May 12 2017 at 09:58):
Und da die Referenzierung von Leistungen, Personal usw. zumindest zum Teil auf diese Standorte zugeordnet ist, tendiere ich dazu, diese Frage mit "ja" zu beantworten
Peter Scholz (May 12 2017 at 10:06):
Gegenbeispiel:
a) nein nicht Rechtsnachfolger
b) Gegenbeispiel : Landarzt mit mehreren Praxisräumen über seinen Bezirk verteilt in denen er umschichtig mit ein und demselben Personal aktiv ist, hat immer meherer BSNR's : pro Praxis-Location immer eine eigene
Das verquaste BSNR Konstrukt ist sicher irgendwo zwischen der Organisation und der Adresse. Wir haben es in V2 aus dem Grunde eindeutig einer Adresse zugeschlagen und da möchte ich es auch weiterhin sehen.
Oder um es anders zu formulieren: Sowohl Adresse als auch Organisation ist nicht ganz richtig. Aber Adresse ist weniger falsch.
Peter Scholz (May 12 2017 at 10:15):
Eine Adresse unterhalb einer Organisation hat immer genau eine BSNR
Eine Organisation kann aber meherer BSNR's haben, nämlich pro Leistungserbringungsort eine. Würden wie die BSNR unter der Organisation ansiedeln müssten wir zwingend soviele Organisationen erzeugen wie es Betriebsstätten gibt, auch wenn es nur eine echte Organisation gibt.
Hängen wir die BSNR an die Adresse, so ist sie a) fix mit der zugehörigen Organisation verknüpft und b) eindeutig einer Lokation zugeordnet.
Stefan Lang (May 12 2017 at 10:21):
"verquast" trifft es jedenfalls...
Das Landarzt-Beispiel hat natürlich noch andere Implikationen. Wenn man mal kurz die BSNR außer Acht lässt und sich die Organization-Ressource anschaut:
Stefan Lang (May 12 2017 at 10:25):
Variante A: der Landarzt ist in einer einzelnen Organization abgebildet.
Dann hat diese mehrere gleichzeitig aktive Adressen mit use="work" und type="physical".
Außerdem hat sie mehrere gleichzeitig aktive telecom-Elemente mit use="work"
Wenn ich nun wissen will, wie ich den Standort in Hintertupfing telefonisch erreichen kann, ist das nicht determiniert, denn die telecom-Daten aus Hintertupfing und Vordertupfing haben keine Beziehung zur Adresse in Hintertupfing bzw. Vordertupfing.
Wenn der Arzt seine Standorte "Dr. Müller Hintertupfinger Praxies" und "Dr. Müllers Vordertupfinger Praxis" nennt, ist das nicht abbildbar, da Organization.name = 0..1
Stefan Lang (May 12 2017 at 10:29):
Variante B: jeder Standort ist eine eigene Organization.
Damit sind telecom(work) und address(work/physical) tendenziell eindeutig und durch die Organization-Klammer auch eindeutig referenziert.
Und die Erfassung unterschiedlicher Namen für die Standorte ist möglich.
Die Organization in Vordertupfing erhält dann ein partOf(Hintertupfing)
Stefan Lang (May 12 2017 at 10:30):
Eine Organization ist ja nicht zwangsläufig eine rechtlich eigenständige Einheit. Abteilungen sind ja ebenfalls über Organization abgebildet.
Peter Scholz (May 12 2017 at 10:30):
Argggh ich hasse zulip
nun tippe ich meinen Text zum vierten mal:
Es gibt noch eine Änderung, wir haben für die BNSR eine OID, die sollten wir dann im system des identifiers auch verwenden.
<valueIdentifier> <system value="urn:oid:1.2.276.0.76.4.17"/> <value value="218099900"/> <period> <start value="2015-01-01"/> </period> <assigner> <display value="KV Baden-Württemberg"/> </assigner> </valueIdentifier>
Stefan Lang (May 12 2017 at 10:33):
Die OID ist im NamingSystem referenziert: https://simplifier.net/BasisprofilDE/kbv-bsnr
Ich denke, wir sollten, wie wir schon festgelegt hatten, generell der FHIR-Best-Practice folgen und URLs verwenden.
Peter Scholz (May 12 2017 at 10:36):
Zu deiner Landarzt Bemerkung:
wenn ich die Verknüpfung dort darstellen will würde ich nicht Telecom und Adress verwenden sondern pro Standort ein
contact Element herstellen bei dem es Adresse und Telefonnummer gibt
Stefan Lang (May 12 2017 at 10:37):
Ist natürlich auch eine Option, allerdings ist contact primär im Sinn von "Ansprechpartner" gedacht (contact.name ist z.B. ein HumanName). Edit: siehe auch http://build.fhir.org/valueset-contactentity-type.html
Peter Scholz (May 12 2017 at 10:38):
Zu Deiner OID Anmerkung,
das finde ich eher unglücklich, da dies doppelte Nachschlagarbeit benötigt
erst über die URL herausbekommen das es eine OID gibt und dann über das OID register herausfinden was die OID ist und wer die ID's vergibt :(
Peter Scholz (May 12 2017 at 10:38):
das ist für mich eher "worst practice"
Stefan Lang (May 12 2017 at 10:41):
Was wäre der Use Case, für den man explizit die OID benötigt?
Stefan Lang (May 12 2017 at 10:46):
Ich meine, wir können natürlich im Betriebsstätten-Profil sowohl URL als auch OID zulassen, das ist ja erlaubt. Das NamingSystem sagt ja im Grunde momentan nur aus, dass die URL preferred ist.
Ich bin mir nur nicht sicher, ob das langfristig eine glückliche Entscheidung ist.
Peter Scholz (May 12 2017 at 10:48):
Es geht um einheitlichere Verwendung und die Tatsache das es unschön mehrere Registries für Naming- und/oder Codesysteme zu verwenden
in CDA gibt man die BSNR in einem ID element mit der registrierten OID an
<id root="1.2.276.0.76.4.17" extension="21809990"/>
warum solle man hier für einen Implementierer der beides identifizieren können wil zwei unterschiedliche Suchstrategien einführen.
Wir haben doch aus CDA eine nahezu vollständige "Veroidung" von solchen Naming systems, warum also noch einmal was anderes einführen
Stefan Lang (May 12 2017 at 10:50):
" In FHIR the preferred system URI is a URL for readability reasons and the potential for resolving, i.e. a URL could 'lead somewhere'. "
http://wiki.hl7.org/index.php?title=Migrating_OIDs_to_FHIR
Stefan Lang (May 12 2017 at 10:51):
Die fhir.de URLs lösen z.B. tatsächlich direkt auf die Ressource auf (abgesehen davon, dass ein Simplifier-Bug das aktuell gerade verhindert)
Stefan Lang (May 12 2017 at 10:53):
(Ressource im Sinn von Profil/ValueSet/NamingSystem/...)
Peter Scholz (May 12 2017 at 10:54):
ja, aber da wo wir OID's haben die so beim DIMDI registriert sind, sollten wir unbeding diese verwenden.
Sie sind geprüft, in einer amtlichen und öffentlichen registry hinterlegt.
URL's lösen vielleicht auf oder auch nicht , aber ob der Inhalt korrekt und vollständig ist wird hier nicht sichergestellt), Bei der OID registry dagegen inkl. der verantwortlichkeit für die OID schon .
Stefan Lang (May 12 2017 at 11:02):
Die Registry für die URLs haben wir ja auch - aktuell, im Draft-Status, via Simplifier, später dann über die zentrale HL7-FHIR-Registry.
Und sie sind, einmal ballotiert, auch normativ
Peter Scholz (May 12 2017 at 11:04):
Zumal die Informationen in simplifier auch nicht denen der KBV zur BSNR entsprechen
Beschreibung der BSNR laut Resgistrierungseintrag
Je zugelassenem Ort der ärztlichen oder psychotherapeutischen Berufsausübung wird eine Betriebsstättennummer vergeben. Insbesondere wird für den Vertragsarztsitz, für den die Zulassung erfolgt, eine Betriebsstättennummer (BSNR) erteilt.
Verantwortliche Organisation und Kontaktpersonen etc fehlen auch.
Doppelte Registries sind immer schlecht
Peter Scholz (May 12 2017 at 11:05):
Der Inhalt kann gar nicht normativ sein, da das Objekt BSNR nicht HL7 "gehört" und nicht in seiner Hoheit liegt
Stefan Lang (May 12 2017 at 11:07):
Wenn die Beschreibungen nicht übereinstimmen (edit: oder Angaben fehlen), ist das eine Änderung - dafür sind wir im Draft-Status.
Und richtig - normativ ist dann die Darstellung des Konzepts in FHIR. Darum geht es doch zunächst?
Peter Scholz (May 12 2017 at 11:08):
und schau Dir mal die vielen OID's im Beispiel zum Practitioner an
https://www.hl7.org/fhir/practitioner-example-f002-pv.xml.html
Peter Scholz (May 12 2017 at 11:09):
Und falsch: Normativ ist natürlich die Bezeichnung des Konzepts von dem der "Eigentümer" des Konzeptes ist !
Stefan Lang (May 12 2017 at 11:17):
Wir können die Bedeutung des Konzepts nicht ändern, das ist definitiv Sache des "Eigentümers".
Wir können aber durchaus festlegen: "Wenn die OID 1.2.3.4.5 im Rahmen deutscher FHIR-Ressourcen abgebildet werden soll, so geschieht dies in der Form "http://fhir.de/xyz". Sprich: ein Synonym
Peter Scholz (May 12 2017 at 11:28):
was aber bei registrierten OID's keinen Vorteil sondern nur mehraufwand bietet.
erst über URL nachsehen welche OID sich dahinter verbirgt und dann im OID Register nachsehen was sie bedeutet und wer verantwortlich ist.
da kann man Pflegeaufwand sinnvoll einsparen, da eine beim DIMDI registrierte OID offiziell ist und auch eindeutig nachgeschlagen werden kann ohne den Umweg über fhir.de gehen zu müssen.
von daher bin ich eindeutig dafür, das für alle Fälle wo es eine solche beim DIMDI registrierte OID in deutschen Profile die urn:oid Vorrang haben sollte. Zumal ich nicht mehrer URNs für einen system Eintrag haben kann!
Stefan Lang (May 12 2017 at 11:47):
Den Punkt mit dem zusätzlichen Referenzierungs-Schritt sehe ich durchaus.
Ich sehe allerdings auch die Kernaussage " Resolvable URLs are generally preferred by implementers over non-resolvable URNs, particularly opaque URNs such as OIDs (urn:oid:) or UUIDs (urn:uuid:)", der ich aus meiner Praxis nur zustimmen kann.
Stefan Lang (May 12 2017 at 11:49):
ad system: Du hast Recht, system darf nicht doppelt sein. Aber Identifier sind ein CodeableConcept], man könnte also theoretisch synonym dieselbe BSNR sowohl mit system=(OID) als auch mit system=(URL) unterbringen.
[Edit: CodeableConcept ist natürlich Unfug, aber rein theoretisch analog in Form von zwei Identifiern darstellbar]
Stefan Lang (May 12 2017 at 11:50):
Die Frage ist, ob wir einen Kompromiss in dieser Form wollen bzw. ob das irgendwelche negative Implikationen auf die praktische Implementierung hat
Peter Scholz (May 12 2017 at 11:55):
Hier kann ich Dir bedingt zustimmen,
abriräre OIDs aus irgendwelchen Gebieten sind mangels einer Registry sicher problematisch
Aber: alle OIDs unterhalb von 1.2.276.0.76 sind mit Ausnahme des Teilbaumes für instanzenidentifikatoren (also unterhalb von 1.2.276.0.76.3 ) eindeutig, registriert und mit einem sinnvollen mass an Informationen beim Dimdi recherchierbar.
Aus dem Grund würde ich, wann immer wir in einer deutschen Extension auf etwas was hier definiert ist niemals auf einen "homebrewed" fhir.de registry ausweichen sondern immer die offizielle OID verwenden. Zumal wir an der Stelle dann auch direkt mit CDA kompatibel sind.
Peter Scholz (May 12 2017 at 12:03):
Von daher ist das für mich kein Kompromiss sondern eine stringentere Form als es die URL jemals sein kann.
Zumal es so ist, das eine URL zunächst einmal genauso viel oder wenig resolveable ist wie eine OID.
Verwendet man nur OID's die beim DIMDI registriert sind ist sie genauso resolveable wie eine URL. Umgekehrt ist eine URL auch nicht per se resolveable . Beides setzt in Wirklichkeit exakt dieselbe Disziplin voraus.
bei URL heisst es : wenn Du eine URL verwendest, so muss diese resolveable sein.
bei OID heisst es : wenn Du eine OID verwendest so muss sie in einer bekannten und aus der OID ableitbaren und öffentlich erreichbaren registry stehen.
oder anders formuliert:
<system value="mailto:ps@osm-gmbh.de"/> ist genauso sinnbefreit wie
<system value="urn:oid: 1.2.276.0.76.3.1.6.2.1.4711"/>
wogegen
<system value="urn:oid:1.2.276.0.76.4.17"/> eindeutig zu betriebsstaettenummer-kv führt
Stefan Lang (May 12 2017 at 12:18):
Stringenz und Disziplin sind etwas, das ich im Kontext einer Spezifikation voraussetze ;)
Stefan Lang (May 12 2017 at 12:20):
Ich denke, für den Moment wäre es gut, noch eine Dritt- oder Viertmeinung zu bekommen.
Sowohl, was die URL/OID-Frage angeht als auch die BSNR-Thematik.
Stefan Lang (May 12 2017 at 12:29):
Für URL/OID bitte hier weiter diskutieren: https://chat.fhir.org/#narrow/stream/german.20(d-a-ch)/topic/URL.20oder.20OID
Simone Heckmann (May 15 2017 at 17:41):
Hallo,
also der Gedanke, die BSNR an die Adresse zu hängen, widerstrebt mir.
Ist es denn tatsächlich so dass eine Praxis A an Adresse X, die ihren Sitz nach zwei Straßen weiter verlegt, eine neue BSNR bekommt!?
Und die Praxis B, die anschließend an Adresse X einzieht firmiert dann unter der BSNR von Praxis A!? Sicher nicht!
Zumal wir mit dieser Modellierung eine ganz wichtige Funktionalität verlieren: nämlich die Praxis anhand ihrer BSNR verlinken zu können. Es wird zweifelsohne etliche Usecases geben, in denen eine Praxis ausschließlich anhand ihrer BSNR identifiziert wird. (z.B. elektronische Überweiseung, eRezept oder wasweißich...)
<MedicationRequest> ... <requester> ... <onBehalfOf> <identifier> <system value = "http://fhir.de/NamingSysgtem/kbv/bsnr"/> <value value= "12345678"/> </identifier> <display value="Gemeinschaftspraxis Jekyll & Hyde"/> </onBehalfOf> ... </MedicationRequest>
Das funktioniert nur, wenn die BSNR ein Identifier der Organization ist.
Diese Option zu verlieren wäre ein sehr hoher Preis für die "semantical correctness".
Patrick Werner (May 15 2017 at 19:28):
Wikipedia meint dazu: Bei Umzug einer Betriebsstätte innerhalb eines Zulassungsbezirkes wird keine neue BSNR vergeben. Entscheidend ist, dass je genehmigtem Tätigkeitsort eine BSNR oder NBSNR existiert. Der Ort der BSNR oder NBSNR kann durch die dazugehörenden Stammdaten zugeordnet werden.
Patrick Werner (May 15 2017 at 19:47):
hier mal die Richtlinie zur Vergabe der Arzt- und Betriebsstättennummer - KBV
Patrick Werner (May 15 2017 at 19:48):
ist die Praxisnetznummer für uns auch relevant?
Patrick Werner (May 15 2017 at 20:03):
Ich finde die Idee die BSNR als Identifier zu nutzen auch gut und auch alternativlos, was gäbe es denn sonst noch? Und da wir für die Praxis den Indentifier brauchen, und nicht einen für die Adresse +1 für das Binding an die Organization
Stefan Lang (May 17 2017 at 08:53):
Nochmal, ergänzend zu meiner 100%igen Zustimmung zu den Aussagen von Simone und Patrick: Es geht darum, das Konzept der Haupt- und Nebenbetriebsstätten in FHIR abzubilden.
Genau diese Flexibilität erlaubt die Organization-Ressource, speziell mittels partOf. Insbesondere kann eine Organization-Ressource auch jeden denkbaren Bestandteil einer übergeordneten Organisation abbilden, sei es eine Abteilung, Filiale/Niederlassung oder auch einfach nur ein Standort (aka "Nebenbetriebsstätte"). Alle Details dazu finden sich in den Abschnitten "Scope and Usage" und "Boundaries and Relationships": http://build.fhir.org/organization.html
Und diese kann man eben jeweils über ihren Identifier (aka "BSNR" bzw. "NBSNR") finden.
Das sollte man sicher erläuternd in den Implementation Guide schreiben, aber damit sind dann doch m.E. alle Punkte klar referenziert.
Stefan Lang (May 17 2017 at 08:57):
In Bezug auf "semantical correctness": Ich halte es für semantisch sehr unsauber, wenn derselbe Identifier ("weltweit eindeutiger Identifikator für was-auch-immer") sowohl an einer Post-Adresse als auch an einer physischen Adresse hängt.
Allein das verbietet eigentlich die Kombination BSNR + Adresse.
Stefan Lang (May 17 2017 at 09:07):
ad Praxisnetznummer: ist mir zwar noch nicht untergekommen, aber da es sich immerhin um eine definierte Organisationsform im KBV-Kontext handelt ( http://www.kbv.de/html/praxisnetze.php ), sollten wir hierfür zumindest schon mal ein NamingSystem festlegen.
Stefan Lang (May 17 2017 at 09:13):
https://github.com/hl7germany/basisprofil-de/issues/13
Simone Heckmann (May 18 2017 at 06:45):
Ich vermute mal entweder: Nebenbetriebssätte(Organization).partOf=Praxis(Organization).partOf=Praxisnetz(Organization)
oder Praxisnetz als Extension an Organization. Das kommt wohl darauf an ob und wie das Attribut üblicherweise verwendet wird.
Die erste Variante macht die Ermittlung des Praxisnetzes zu einer Praxis natürlich recht aufwändig und würde verhindern, dass die Praxis ebenfalls .partOf einer anderen Organisation (MVZ, KV,...) sein kann, da partOf 0..1.
Also meine Tendenz wäre eine Extension vom Typ "Reference" mit Wahlweise Angabe des Praxisnetz-Identifiers oder einer Referenz auf die entsprechende Organization
Stefan Lang (May 18 2017 at 08:16):
Ja, partOf ist ziemlich klar für die Teile eines Unternehmens gedacht. Ein Praxisnetz ist nach Definition ein Kooperationsverbund rechtlich selbstständiger Organisationen ("Praxisnetze sind Zusammenschlüsse von selbstständig tätigen Vertragsärzten verschiedener Fachrichtungen und Psychotherapeuten").
Es kann auch durchaus passieren, dass es für eine Praxis mehrere Referenzen gibt, z.B.:
die Gynäkologie-Praxis X ist:
1. Mitglied im Praxisnetz 4711
2. Netzwerkpartner im Behandlungsverbund Ovarialkarzinom der Klinik Y
3. Teilnehmer an der wissenschaftlichen Tumorkonferenz der Uniklinik Z
Das sollten wir für die Extension beachten.
Simone Heckmann (Aug 03 2017 at 08:56):
Frage zu Betriebsstätten: Haben die immer auch eine IK-Nummer? Macht es Sinn, die IK-Nummer als zusätzlichen (optionalen?) Identifier in das Betriebsstätten-Profil mit aufzunehmen?
Patrick Werner (Aug 03 2017 at 13:59):
nach meinem Verständnis hat die Betriebstätte als Ort nicht direkt eine IK Nummer, gehört aber zu einem Leistungserbringer der die IK Nummer hat.
Hat ein Leistungserbringer mehrer BS hätte diese alle die gleiche IK Nummer. Daher würde ich die IK Nummer nur bei der Leistungserbringer Organization sehen, die Betriebstätten Organizations sind part-of des Leistungserbringers.
Simone Heckmann (Aug 03 2017 at 14:18):
OK, demnach bräuchten wir ein zweites Profil "Leistungserbringer (im Sinne der KBV?)", das die IK-Nummer verbindlich vorgibt.
Eine Organisation, die gleichzeitig Leistungserbringer und Betriebsstätte ist, müsste dann eben zu beiden Profilen kompatibel sein, was bei einem offenen Slicing der Identifier ja kein Problem sein dürfte.
Patrick Werner (Aug 03 2017 at 14:48):
Ich denke die Frage die sich hier stellt ob man das generell trennen möchte oder nicht. Also entweder Organisation welche auch Leistungserbringer und Betriebstätte gleichzeitig sein kann. Oder, weil Leistungserbringung ja den Scope Abrechnung hat, seperate Resourcen haben möchte.
Die Unterscheidung zwischen Praxis als Stätte und Leistungserbringer Organization könnte dann auch über den type erfolgen
Stefan Lang (Aug 03 2017 at 14:51):
"Leistungserbringer" ist im Kontext der IK-Nr. falsch.
Die IK ist ein Identifikator für alle möglichen Organisationen; Leistungserbringer, Kostenträger, Rechenzentren, ...
Insofern dürfte es genügen, die IK ins Organization-Basisprofil zu packen und nirgends explizit zu verbieten
Stefan Lang (Aug 03 2017 at 14:56):
Alles andere würde ich den realen Use Cases überlassen, sprich: ist Sache der Implementierer. Wir sollten nur definieren, wie eine IK in FHIR aussieht.
Patrick Werner (Aug 03 2017 at 14:56):
Aber im Kontext der Abrechnung brauche ich doch als Leistungserbringer zwingend eine IK Nummer um abrechnen zu können, also müsste falls man solch ein organization profil möchte hier die IK Nummer verbindlich setzen, oder?
Stefan Lang (Aug 03 2017 at 15:03):
Bei Niedergelassenen?
Stefan Lang (Aug 03 2017 at 15:07):
https://www.gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/aerzte/technische_anlagen___aktuell/20151117_TA1_16.pdf
kennt, soweit ich sehe, keine IK. Nur BSNR und LANR.
Stefan Lang (Aug 03 2017 at 15:08):
DMP verbietet explizit die gleichzeitige Übermittlung von IKNR und BSNR+LANR
Stefan Lang (Aug 03 2017 at 15:09):
Die KBV fokussiert also genau genommen gerade nicht auf IK, sondern auf BS.
Was nicht ausschließt, dass eine Organisation beides haben kann.
Stefan Lang (Aug 03 2017 at 15:10):
Insofern ist das IMHO wirklich eine Sache des jeweiligen (Abrechnungs-)Verfahrens, was bei Bedarf dann auch in den dort zugehörigen Profilen definiert werden sollte.
Stefan Lang (Aug 03 2017 at 15:38):
Ich tendiere eher dazu, die BSNR in organization-basis zu legen und organization-betriebsstaette wegzulassen.
Die Fälle, wo sowohl Betriebsstätten als auch Kliniken (aka "IKNR-Inhaber") Daten übermitteln müssen, wären damit viel einfacher abzubilden.
Im Moment wäre es so, dass ich dann sagen müsste "entweder es wird das Profil organization-betriebsstaette abgebildet oder das Profil organization-basis mit IKNR". Dafür gibt's innerhalb von FHIR keinen Mechanismus.
Wenn IKNR und BSNR parallel in organization-basis definiert sind, kann ich das über eine einzelne zusätzliche Invariante im abgeleiteten Profil spezifizieren.
Stefan Lang (Aug 03 2017 at 15:41):
Ich denke auch nicht, dass organization-basis damit "überfüllt" wäre. So viele andere offizielle Identifier für Organization gibt's in Deutschland ja nicht.
Stefan Lang (Aug 03 2017 at 15:57):
Die Arztstammdaten-Schnittstelle der KBV kennt übrigens ebenfalls keine IKNR:
https://www.gkv-datenaustausch.de/media/dokumente/leistungserbringer_1/aerzte/technische_anlagen___aktuell/ASD-SLE-Schema_V202.zip
Simone Heckmann (Aug 03 2017 at 19:11):
Hmm... Wenn ich bedenke, dass Apotheken, Ämter, Lieferanten, Kliniken, Arbeitgeber, Sanitätshäuser, Physiotherapie-Praxen, Pharma-Firmen und Software-Hersteller am Ende Organisations werden, dann könnte es schon eng werden mit allen erdenklichen Identifiern im Basis-Profil... ;-)
Stefan Lang (Aug 04 2017 at 08:14):
Mit allen erdenklichen sicher nicht ;-)
Es mag jetzt subjektiv geprägt sein, aber was zumindest mir immer über den Weg läuft, sind eben IKNR und BSNR, und das oft als exkludierende Alternativen für Kliniken bzw. Niedergelassene. Daher der Vorschlag, das auch auf dieselbe Ebene in den Basisprofilen zu stellen.
Stefan Lang (Aug 04 2017 at 08:19):
Im Kontext des Gesundheitswesens haben die genannten Organisations-Typen übrigens praktisch alle eine IK ;-)
Simone Heckmann (Aug 07 2017 at 16:23):
Hatten wir uns schon mal auf ein ValueSet für organization.type geeinigt? (Issue#29)?
https://github.com/hl7germany/basisprofil-de/issues/29
Simone Heckmann (Aug 07 2017 at 19:00):
OK, das ValueSet/CodeSystem ist vorhanden. Jetzt fehlen aber schon mal jegliche Arten von neidergelassenen Praxen, oder bin ich blind?
Simone Heckmann (Aug 07 2017 at 19:00):
Simone Heckmann (Aug 07 2017 at 19:00):
...aber Hauptsache, die Perückenmacher sind drin :P
Stefan Lang (Aug 07 2017 at 19:03):
Das hatten wir im September 2016 auch schon mal diskutiert und waren damals zu dem Schluss gekommen, dass "20" und "21" ausreichen, sofern niemand protestiert
Simone Heckmann (Aug 07 2017 at 19:08):
Ah ja, stimmt! Ich hab nach "Kassenärztliche Vereinigung.." nicht mehr weitergelesen :D
Last updated: Apr 12 2022 at 19:14 UTC
