Beibehaltung der id bei Fremddatenübernahme
jcaumann opened this issue · 11 comments
In dem Abschnitt der übergreifenden Hinweise steht im Zusammenhang mit der Fremddatenübernahme: "Sollte die erzeugte Ressource dauerhaft in das bestätigungsrelevante System übernommen werden, KANN der entsprechende Tag in Patient.meta.tag entfernt werden. In diesem Falle MUSS die id der Ressource stabil bleiben und darf nicht verändert werden."
Der letzte Satz ist mir in seiner Bedeutung nicht klar bzw. mir ist nicht klar, wozu es ihn braucht:
- wenn das System die Ressource via CREATE angenommen hat, hat er die id auch selbst erzeugt und DARF sie gemäß Basisspezifikation NICHT ändern. Damit sagt der Satz nichts anderes als eh schon gegeben ist und sollte gestrichen werden.
- Warum "In diesem Falle"? Bedeutet dass, dass der Server die id verändern darf, wenn er den Tag zur Kennzeichnung der Frfemdübernahme nicht entfernt?
Sofern es keinen guten Grund für den letzten Satz gibt, würde ich ihn einfach streichen.
Die Intention hinter hatte ich kurz schonmal in dem JIRA Tickets zum MS Flag auf .id angerissen. Es geht darum, dass das System bei der Übernahme nicht eine Ressource mit einer neuen id erzeugt, nur die Daten aus der externen Patienten-Ressource übernimmt, jedoch alle anderen externen Referenzen nicht auf die neue id umbiegt. Das System kann die Daten übernehmen dies es möchte, muss aber die id intakt lassen. Ansonsten sehe ich zu viel kaputt gehen…
@alexzautke : Hattet ihr das auch mal mit den KIS Herstellern diskutiert? Eigentlich sollte jedes System die Möglichkeit haben, bei der Persistierung einer Ressource dieser eine neue logische Id zu geben, die der eigenen "ID-Policy" entspricht. Die "alte" ID wäre dann maximal ein Fremdschlüssel (oder würde verworfen). Auch hier stellt sich mir damit die Frage, ob das überhaupt ein Interoperabilitätsproblem ist. Eigentlich gibt es doch nur 3 UseCase-Muster für die Übernahme einer Ressource:
- Die Übernahme erfolgt über eine proprietäre Schnittstelle. In diesem Fall ist ISiK aus dem Spiel und es ist uns egal, wie das übernehmende System die Verlinkung zwischen Ressourcen aufrecht erhält.
- Die Übernahme erfolgt per PUSH, d.h. das übergebende System reicht die Ressource per FHIR ReSTful CREATE an das übernehmende System weiter. In dem Fall MUSS das übernehmende System sogar eine neue id vergeben, die es dann anschließend nicht mehr ändern darf.
- Die Übernahme erfolgt per PULL, d.h. das übernehmende System ruft die Ressource per FHIR ReSTful READ oder SEARCH an von dem übergebendem System ab. Was es dann mit der Ressource macht und wie es die speichert, ist kein ISiK-Thema (hat mit interoperabler Schnittstelle nichts zu tun, sondern ist internes Systemverhalten). Selbst wenn das übernehmende System die Ressource danach als "eigene" über ein FHIR ReSTful API bereitstellt, steht es ihm nach der FHIR Basisspezifikation frei, der Ressource eine neue logische ID zu geben (was ja auch richtig ist, da die logische Äquivalenz zweier Ressourcen nur über die Business ID hergestellt/geprüft werden kann).
Je mehr ich darüber nachdenke, desto mehr scheint es mir sogar, dass der Satz mit der stabil zu haltenden id nicht nur unklar, sondern sogar falsch ist. Vielleicht brauche ich aber auch nur einen konkreten Use Case, um die Intention des Satzes zu verstehen...
"Die Übernahme erfolgt über eine proprietäre Schnittstelle. In diesem Fall ist ISiK aus dem Spiel und es ist uns egal, wie das übernehmende System die Verlinkung zwischen Ressourcen aufrecht erhält." Genau das ist der Punkt, die Verlinkung muss aufrecht erhalten werden. Es ist aus meiner Sicht schon ein Interoperabilitätsproblem, wenn die Referenzen gebrochen werden und ins leere Laufen. Dieser Workflow kommt aus den Arbeitsterminen zu ISiK Terminplanung und wurde anschließend in ISiK Basis übernommen.
Hier sind wir wieder bei der Frage nach dem Scope. FHIR ist ein Austauschformat und ISiK definiert interoperable Schnittstellen für den Austausch von Daten zwischen IT-Systeme im und am Krankenhaus. Mit der Annahme der Daten ist der Austausch abgeschlossen und wie und wo der Server die Daten ablegt, ist weder im Scope von ISiK noch im Scope von FHIR.
Was wir jedoch in ISiK festlegen können, ist das Außenverhalten, denn das ist ja durchaus ein Thema der Interoperabilität. In diesem Fall geht es ja auch garnicht um die technische Vorgabe, dass der Server die id nicht verändert, sondern um das herzustellende, von außen sichtbare Verhalten, dass alle Bindung dieser Ressource an andere Ressourcen erhalten bleiben. Daher schlage ich folgende Formulierung für den letzten Satz vor:
"Das bestätigungsrelevante Systeme MUSS bei einer dauerhaften Übernahme einer Ressource sicherstellen, dass Referenzen auf diese und aus dieser Ressource weiterhin auflösbar sind."
@alexzautke , @f-peverali : Wäre das ein Weg, den ihr mitgehen könntet?
@pavlodyban Habt ihr ein Create auf Patient bereits bei euch umgesetzt und habt eine Meinung dazu?
Hier sind wir wieder bei der Frage nach dem Scope. FHIR ist ein Austauschformat und ISiK definiert interoperable Schnittstellen für den Austausch von Daten zwischen IT-Systeme im und am Krankenhaus. Mit der Annahme der Daten ist der Austausch abgeschlossen und wie und wo der Server die Daten ablegt, ist weder im Scope von ISiK noch im Scope von FHIR.
Was wir jedoch in ISiK festlegen können, ist das Außenverhalten, denn das ist ja durchaus ein Thema der Interoperabilität. In diesem Fall geht es ja auch garnicht um die technische Vorgabe, dass der Server die id nicht verändert, sondern um das herzustellende, von außen sichtbare Verhalten, dass alle Bindung dieser Ressource an andere Ressourcen erhalten bleiben. Daher schlage ich folgende Formulierung für den letzten Satz vor:
"Das bestätigungsrelevante Systeme MUSS bei einer dauerhaften Übernahme einer Ressource sicherstellen, dass Referenzen auf diese und aus dieser Ressource weiterhin auflösbar sind."
@alexzautke , @f-peverali : Wäre das ein Weg, den ihr mitgehen könntet?
Aus meiner Sicht erzeugt es nur unnötig Arbeit auf Seite des Clients. Der Server kann beim Create die Ids vergeben. Alles was gefordert wird ist, dass nach Außen keine neue Ressource angelegt wird sondern maximal ein Update erfolgt. Das ist einer Festlegung der Schnittstelle, wie das intern umgesetzt wird es vollkommen egal und kann beliebig umgesetzt werden.
@markus020 könntest Du hierzu auch noch deine Perspektive einbringen?
ich sehe hier zwei Aspekte, die es zu unterscheiden gibt:
- POST einer Ressource: aus Sicht des Subsystems stellt die ISiK-API eine API zum KIS dar -> d.h. die Frage, ob eine Übernahme in das KIS erfolgt oder die Ressource (nativ) gespeichert und lediglich visualisiert wird, spielt in der Außensicht keine Rolle. Wird durch einen Client eine Ressource mittels POST im im Server (=KIS aus Client-Sicht) erzeugt, erhält diese eine id, welche dem Client mitgeteilt wird. Die weiteren Schritte obliegen dem KIS und dürfen für das Subsystem keine Auswirkungen haben.
- POST eines Dokuments (BerichtSubsystem): hier ist es tatsächlich schwierig, da hier die einzelnen Ressourcen ggfs. mit einer id kommen und mit dieser auch innerhalb des Bundles referenziert werden. Wenn diese nicht nur, wie in dem IG vorgesehen, als Dokument einem Patienten und Fall zugeordnet werden müssen, sondern auch in das KIS übernommen werden, MÜSSEN die id sogar überschrieben werden. Vor diesem Hintergrund ist diese Aussage kritisch, allerdings stellt sich hier die Frage, wie man die tracebility hier erhalten kannt.
Ich würde folgende Formulierung vorschlagen:
_Erlaubt ein System die Erzeugung von Ressourcen durch Subsysteme (CREATE mittels http POST) MUSS das System für die Ressource eine eindeutige id vergeben und diesem dem Subsystem in der Response mitteilen. Das System DARF NICHT eine weitere Ressource für den selben Sachverhalt (etwa bei der Übernahme und Persistierung in das System) erzeugen. Das gilt nicht, bei der Übernahmen von Ressourcen aus einem Dokument (ISiKBerichtSubsystem). _
@pavlodyban Habt ihr ein Create auf Patient bereits bei euch umgesetzt und habt eine Meinung dazu?
Wir haben den POST auf Patient im Produktivbetrieb noch nicht umgesetzt. Aus meiner Sicht spielt der obige Satz im folgenden Usecase eine wichtige Rolle:
- Ein Patportal übermittelt einen neuen Termin ans KIS. Der Termin hat einen Bezug zum vorläufigen Patienten. Der vorläufige Patient hat eine PID vom Patportal und er hat vorerst keine PID im KIS.
- Das KIS speichert den Termin. Laut ISiK muss der vorläufige Patient auch im KIS gespeichert werden. (mit KIS-PID?)
- Der Patient kommt am Tag des Termins und wird im KIS aufgenommen. Dabei wird die eGK eingelesen und die Patientenstammdaten werden im KIS eingetragen. Im KIS wird ein Fall für den verifizierten KIS-Patienten angelegt.
- Der KIS-Patient und der aufgenommene Fall müssen an das Patportal zurückgespiegelt werden, damit das Patportal die im Vorfeld hochgeladene Dokumente mit Patienten- und Fallbezug ans KIS übermitteln kann.
Ergo: ein Patportal muss aus dem vorläufigen Patienten auf den verifizierten Patienten im KIS schließen können. Dabei wäre wünschenswert, dass das KIS die Verlinkung zw. dem vorläufigen und dem verifizierten Patienten in der ISiK API darlegt. Sonst können die Zuordnung des vorläufigen Patienten und die anschließende Dokumentenübermittlung (ein KHZG-Usecase) nicht stattfinden.
Ob der Satz oben dieses Ziel verfolgt, kann ich nicht beurteilen. Diese Problematik wollten wir in der AG zur Patientenzusammenführung zeitnah angehen.
Zur Persistierung der Dokumenten-ID habe ich keine starke Meinung. Dokumente werden aus dem Patportal meist als "immutable" übertragen, sprich eine Überschreibung der bereits übermittelten Dokumente ist nicht erfoderlich.
Für Stufe 4
gelöst über #359