Stream: german (d-a-ch)
Topic: Schedule für Privat/Gesetzlich versicherte Patienten
Markus Ast (Jul 28 2017 at 06:38):
Hallo, in der Schedule Resource scheint es ohne Erweiterung nicht möglich zu sein, ein Schedule nur für Privat versicherte Patienten und ein Schedule für gesetzlich versicherte Patienten zu erstellen / einzuschränken. Das könnte jedoch über eine Erweiterung gelöst werden. Meine Frage wäre hier, ob es Sinn macht so etwas in das DE Profil aufzunehmen, oder ob das ein zu spezieller Anwendungsfall ist?
Stefan Lang (Jul 28 2017 at 07:28):
Hallo @Markus Ast! Interessante Frage.
Mit Schedule haben wir uns bei den deutschen Basisprofilen bisher noch nicht befasst. Ich lasse also einfach mal meinen Gedanken freien Lauf.
Grundsätzlich denke ich, die Unterscheidung PKV vs. GKV ist bei der Terminvergabe ein sehr entscheidendes Kriterium, also meines Erachtens durchaus wert, in den Basisprofilen berücksichtigt zu werden.
Schedule selbst kennt derzeit tatsächlich keine Klassifizierung in dieser Richtung. Grundsätzlich ist ja die Idee in Schedule, die Information, was scheduled wird, in Actor zu referenzieren.
Eine Option ist also, einen actor(HealthcareService) zu haben, der wiederum über einen Code in eligibility (also z.B. PKV|GKV) den Versicherungstyp einschränkt.
Das würde ggf. implizieren, dass "Versorgung von Privatpatienten mit Leistung X" und "Versorgung von Kassenpatienten mit Leistung X" getrennte HealthcareService-Ressourcen sind.
Zusatz-Argument dafür: auch die unter "Scope and Usage" genannten Beispiele für HealthcareService ( https://www.hl7.org/fhir/healthcareservice.html#scope ), z.B. Verzeichnisse sprechen dafür, diese Information im HealthcareService unterzubringen. Es nutzt ja z.B. dem Kassenpatienten wenig, wenn ihm bei der Suche nach einem Neurologen auch Ergebnisse geliefert werden, die er versicherungsbedingt gar nicht nutzen kann.
Das mal als ersten Aufschlag,.
Stefan Lang (Jul 28 2017 at 07:30):
HealthcareService.availableTime spielt ja ebenfalls hier mit rein ("nachmittags nur Privatpatienten")
Markus Ast (Jul 28 2017 at 07:34):
Hallo @Stefan Lang, vielen Dank für die ausführliche Antwort! Ich habe tatsächlich in einem ersten Prototypen die Unterscheidung über eine HealthcareService Resource vorgenommen, wobei mir bisher nicht bewusst war, das HealthcareService eventuell sogar das korrekte Vorgehen sein könnte. Wobei ich es in dem Fall noch nicht über eligibility gelöst habe, was jedoch nach einem guten Ansatz klingt. Ich werde mir die HealthcareService resource mal noch etwas genauer anschauen, danke schonmal für den Hinweis!
Stefan Lang (Jul 28 2017 at 07:40):
Falls es passt (und vorbehaltich anderer Kommentare) wäre es sicher nicht verkehrt, das in die Basisprofile aufzunehmen. Der Zeitpunkt ist jedenfalls gerade günstig dafür ;-)
Stefan Lang (Jul 28 2017 at 07:45):
Insbesondere ist ein "it works for me" natürlich genau das, was wir auch für den normativen Status von Profilen brauchen. Ein Basisprofil, das sich aus einer konkreten Implementierung entwickelt, ist quasi der FHIR-idealfall.
Simone Heckmann (Jul 28 2017 at 08:52):
Ich vermute, dass dies auch für BG als Versicherungsart relevant ist, daher wäre das ValueSet für eligibility vermutlich identisch mit dem, welches wir ohnehin für CoverageType benötigen. FHIR hat hierfür ein 'preferred' Binding an http://build.fhir.org/valueset-coverage-type.html
Wollen wir uns dieses ValueSet zurechtbasteln, oder sind wir dreist und nehmen ein eigenes? Ich halte in diesem Punkt die Interoperabilität über Staatsgrenzen hinweg für zweitrangig, daher tendiere ich zu letzterem...
Höchstens den SELFPAY-Code würde ich zur Adoption in Betracht ziehen, da dieser am ehesten bei ausländischen Patienten zum Tragen kommt.
Simone Heckmann (Jul 28 2017 at 09:55):
...ich hatte dazu schon mal vorgeschlagen:
PAY = Selbstzahler
EHCPOL = private Zusatzversicherung
MANDPOL = gesetzl. Versicherung?
SOCIAL = Sozialamt?
WCBPOL = BG?
das wäre der Fall, dass wir uns die Rosinen aus dem vorhandenen ValueSet herauspicken.
Die Alternative wäre ein eigenes Set aus den handelsüblichen Codes GKV, PKV, BG...
Stefan Lang (Jul 28 2017 at 10:01):
Ich tendiere auch zum eigenen ValueSet und CodeSystem. Die Werte aus coverageType sind eher "haarscharf daneben".
Falls für eligibility nur ein Subset gebraucht wird, kann man ja immer noch ein separates ValueSet aus Teilen dieses CodeSystems ziehen
Simone Heckmann (Jul 28 2017 at 16:03):
Da gibt es noch nix, oder? V2? V3?
Simone Heckmann (Jul 28 2017 at 16:45):
Hat irgendwer das DOC von Frank & Marek bzgl der Versicherungsarten parat. Ich hab's verbummelt!
Simone Heckmann (Jul 28 2017 at 16:48):
Nee, hab's: https://drive.google.com/file/d/0B_Prx4RHDXzWZXFXSzFWWEo5TEU/view?usp=sharing
Simone Heckmann (Jul 28 2017 at 16:52):
darin haben wie SEL, PKV, GKV...
In V2 hatten wir PKV, GKV, BG: http://wiki.hl7.de/index.php?title=Segment_IN1#Tabelle_0072:_Insurance_Plan_ID
Simone Heckmann (Jul 28 2017 at 17:59):
Ich hab das CodeSystem und ValueSet erstellt und hochgeladen, aber der Simplifier-WebHook merkt heute gar nix.
Stefan Lang (Jul 29 2017 at 08:53):
@Markus Ast Zur Info: es gibt im Moment ein paar technische Probleme beim Upload der Basisprofile auf Simplifier. Im Zweifel kann man auch auf GitHub schauen, dort sind immer die aktuellen Draft-Fassungen: https://github.com/hl7germany/basisprofil-de
Stefan Lang (Jul 29 2017 at 08:53):
(Falls es eilt - ich hoffe, dass Furore das Problem schnell lösen kann)
Markus Ast (Jul 29 2017 at 09:04):
Wow, ihr seid aber fix! Ich werde im Laufe der nächsten Woche meine Prototypen mal anpassen, dafür reicht mit auch Github (ist mir tatsächlich sogar lieber 
). Danke, dass ihr euch dem Use Case so schnell angenommen habt, hätte eine solche Resonanz gar nicht erwartet, aber das bestärkt mich nur darin, dass auch in DE genügend Leute hinter FHIR stehen, sodass es sich lohnt darauf aufzubauen.
Stefan Lang (Jul 29 2017 at 09:10):
Es geht nicht immer ganz so schnell wie im Moment, aber wir schauen schon, dass die Anforderungen aus der Praxis sich in den Basisprofilen niederschlagen ;-)
Wenn der Prototyp steht und passt, würde ich das wie gesagt gern in ein Basisprofil-Draft überführen, falls dem nichts entgegen steht.
Markus Ast (Aug 08 2017 at 14:14):
Ich habe den Prototypen eigentlich schon länger angepasst, hatte jedoch noch keine Rückmeldung gegeben, weil es noch einen Punkt gibt, der mir noch nicht ganz gefällt. Die Actor Liste im Schedule gibt mir genügend Informationen um ein Formular zur Filterung zu befüllen (ID und Name reicht mir dazu), bis auf der Actor HealthcareService, welche als Reference die Eligibility noch nicht beinhaltet. D.h. ich müsste hier entweder einen weiteren Request machen um alle referenzierten HealthcareServices abzurufen oder als Contained Resource hinzufügen. Ersteres würde ich, wenn möglich, gern vermeiden und mit letzterem habe ich mich jetzt noch nicht genauer beschäftigt. Da ich für ein paar Wochen abwesend bin, wollte ich trotzdem schon mal soweit Feedback geben, dass das CodeSystem der Versicherungsart selber für den Use Case an Sich super ist!
Stefan Lang (Aug 08 2017 at 14:24):
Top, danke für die Info
Last updated: Apr 12 2022 at 19:14 UTC
