Stream: german/isik
Topic: Bestätigungsverfahren (Titus)
Alexander Rohde (Jul 09 2021 at 09:34):
Ich habe gerade einen Testfall in Titus ausgeführt und bekomme folgende Fehlermeldung:'ID der Ressource entspricht nicht der angeforderten ID' Expression: id.contains('/10438/') konnte nicht bestätigt werden.
Der Anfang der FHIR Response sieht so aus:
<Patient xmlns="http://hl7.org/fhir">
<id value="10438"></id>
<meta>
<profile value="https://gematik.de/fhir/IsiK/StructureDefinition/IsiKPatient"></profile>
</meta>
Wieso ist das nicht richtig?
Patrick Werner (Jul 09 2021 at 09:49):
Guten Morgen Herr Rohde, vielen Danke für ihr Feedback.
Ihr Ressource sieht korrekt aus, ich werde der Fehlerursache nachgehen und Ihnen ein Update geben.
Alexander Rohde (Jul 27 2021 at 07:49):
Nach dem Titus-Update gestern kann unser FHIR-Server nicht von Titus erreicht werden (Connection Timeout). Können Sie da mal bitte nachschauen?
Patrick Werner (Jul 27 2021 at 13:22):
Alexander Rohde said:
Nach dem Titus-Update gestern kann unser FHIR-Server nicht von Titus erreicht werden (Connection Timeout). Können Sie da mal bitte nachschauen?
Hallo Herr @Alexander Rohde
hier lag noch ein Fehler des genutzten proxys vor. Vielen Dank für die Meldung, der Fehler wurde umgehend behoben.
Patrick Werner (Jul 27 2021 at 13:23):
Das System ist nun wieder funktional.
Alexander Rohde (Aug 31 2021 at 14:59):
Der Testfall "ISiK_Procedure_read_001" erwartet für den OPS-Code "5-470" den SNOMED-CT-Code "80146002", also genau den passenden SNOMED-CT-Code zum OPS-Code.
Ich habe das aber so verstanden, dass lediglich die Kategorie angegeben werden muss (Mapping siehe https://ig.fhir.de/basisprofile-de/stable/Terminologie-ConceptMaps.html).
Ansonsten müssten wir ja den vollständigen SNOMED-CT Katalog abbilden. Was ist nun richtig?
Patrick Werner (Aug 31 2021 at 15:09):
Guten Abend Herr @Alexander Rohde , danke für ihren Hinweis.
Das SnomedCT Slice auf Procedure.code.coding hat kein must-support flag, und muss dadurch nicht zwingend unterstützt werden. Procedure.category kann diese Werte enthalten: https://simplifier.net/isik/prozedurenkategorie-sct
Wir werden den Test anpassen und Procedure.code nicht mehr auf den SnomedCT code übeprüfen
Alexander Rohde (Sep 01 2021 at 13:06):
Vielen Dank für Ihre Antwort. Ich habe noch ein weiteres Problem, und zwar mit dem Testfall "CONDITION-SEARCH-005". Dieser ruft "/Condition?recorded-date=le2020-10-14" (LESSTHAN_OR_EQUALS) auf, geprüft wird aber ein Ergebnis auf EQUAL, also "/Condition?recorded-date=eq2020-10-14".
Patrick Werner (Sep 01 2021 at 13:38):
Auch hier vielen Dank für ihr Feedback. Auch hier kann ich ihre Beobachtung bestätigen, wir werden den TestStep fixen.
Alexander Rohde (Sep 03 2021 at 05:32):
Folgende Punkte habe ich noch beim Testen festgestellt:
- Der Testfall "PROCEDURE-SEARCH-004" (Procedure?code=http://snomed.info/sct|80146002) Suche nach SNOMED-CT nicht möglich, da kein SNOMED-CT Katalog vorhanden ist (sollte m.M. kein Testfall sein), relates to "PROCEDURE-READ-001".
- Der Testfall "Coverage-SEARCH-004" (/Coverage?type=SEL) erwartet genau ein Ergebnis, es können aber mehrere Ergebnisse vorliegen, weil es keinen Patienten- oder Fallbezug gibt.
- Der Tesfall "ENCOUNTER-SEARCH-006" (/Encounter?date=le2050-01-01) "Es gibt Suchergebnisse, die nicht dem Kriterium entsprechen", unklar, warum fehlerhaft
Alexander Rohde (Sep 10 2021 at 09:56):
Läßt sich der Testfall "PATIENT-SEARCH-012" (/Patient?_has:Encounter:patient:_id=12345) eigentlich mit HAPI FHIR umsetzen? Für "JPA Server" habe ich gefunden, dass es aktuell nicht implementiert ist (https://hapifhir.io/hapi-fhir/docs/server_jpa/search.html), ich verwende aber "Plain Server" (RestfulServer). Wie müsste die Methodensignatur aussehen?
Simone Heckmann (Sep 10 2021 at 10:06):
Ich lese die Restriktion als "chains within _has", also ich kan von dem reverse gechainten Patienten aus nicht mehr raus-chainen und beispielsweise auf patient:generalPractitioner.name suchen. _id sollte aber gehen.
Patrick Werner (Sep 10 2021 at 10:58):
Alexander Rohde said:
Läßt sich der Testfall "PATIENT-SEARCH-012" (/Patient?_has:Encounter:patient:_id=12345) eigentlich mit HAPI FHIR umsetzen? Für "JPA Server" habe ich gefunden, dass es aktuell nicht implementiert ist (https://hapifhir.io/hapi-fhir/docs/server_jpa/search.html), ich verwende aber "Plain Server" (RestfulServer). Wie müsste die Methodensignatur aussehen?
Ja das kann der HAPI, der TestServer gegen den Titus CI läuft basiert auf auf hapi.
Alexander Rohde (Sep 10 2021 at 14:19):
Ok danke, das klappt jetzt.
Alexander Rohde (Sep 21 2021 at 13:40):
Bei den Geschlechtskennzeichen "unbestimmt" und "divers" ist eine Extension zu verwenden (https://ig.fhir.de/basisprofile-de/0.9.2/Geschlecht.html). Wie kann ich in HAPI FHIR bei patient.gender eine Extension anwenden? AdministrativeGender ist ein enum, addExtension() gibts hier nicht.
Patrick Werner (Sep 21 2021 at 14:33):
Hallo Herr Rohde, sie können das GenderElement mittels https://github.com/hapifhir/org.hl7.fhir.core/blob/3db881a93bf88dd793910632a8cd2f5ae3a03aa2/org.hl7.fhir.r4/src/main/java/org/hl7/fhir/r4/model/Patient.java#L407 public Enumeration<AdministrativeGender> getGenderElement()vom Patienten abfragen. Dies ist ein Fhir Datalement welchem man extensions hinzufügen kann.
Alexander Rohde (Sep 22 2021 at 07:28):
Hallo Herr Werner,
danke für den Tipp, damit funktioniert es!
Alexander Rohde (Sep 24 2021 at 13:08):
Ist es richtig, dass die Composition Tests den POST auf die Base-URL machen, ohne resource type?
Failure during REST processing: ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: This is the base URL of FHIR server. Unable to handle this request, as it does not contain a resource type or operation name.
Simone Heckmann (Sep 24 2021 at 13:10):
Ja, 4. Fall in der Liste der Document-Endpoints. Der Payload muss allerding eine Bundle vom Typ "document" sein, keine Composition.
Alexander Rohde (Sep 24 2021 at 13:31):
Wie macht man das mit HAPI, ich bekomme immer eine Exception (s.o.)? Gibt's da ein Beispiel?
Alexander Rohde (Sep 24 2021 at 13:59):
OK, hier muss wohl @Transaction verwendet werden... da bekomme ich folgende Exception:
Failure during REST processing: ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: No Content-Type header was provided in the request. This is required for "TRANSACTION" operation
Simone Heckmann (Sep 24 2021 at 14:17):
Content-Type header muss bei jeder PUT/POST Interaktion gesetzt sein (auf application/fhir+xml oder application/fhir+json)
Simone Heckmann (Sep 24 2021 at 14:17):
Von Welchem HAPI-Server-Endpunkt kommt die Nachricht?
Alexander Rohde (Sep 24 2021 at 14:18):
Titus (ISiK_Composition_composition_001 POST eines Document-Bundles)
Simone Heckmann (Sep 24 2021 at 14:19):
Der sollte mit document-bundles eigentlich klarkommen (wenn der Content-Header-stimmt :wink: )
Patrick Werner (Sep 24 2021 at 14:20):
Alexander Rohde said:
Wie macht man das mit HAPI, ich bekomme immer eine Exception (s.o.)? Gibt's da ein Beispiel?
Hapi kann das nicht out of the box. Dies muss man hapi per eigenem Code beibringen.
Alexander Rohde (Sep 24 2021 at 14:24):
Das war vlt. missverständlich. Die Fehlermeldung "No Content-Type header..." kommt von unserem FHIR Server, den POST hat Titus gesendet.
Jetzt weiß ich nicht, ob Titus keinen Content-Header mitschickt, oder ob es an unserem Server liegt.
Patrick Werner (Sep 24 2021 at 14:24):
oh!
Simone Heckmann (Sep 24 2021 at 14:24):
ah! :big_smile:
Patrick Werner (Sep 24 2021 at 14:27):
Es wird aktuell noch kein content-type mitgesendet
Patrick Werner (Sep 24 2021 at 14:27):
Danke für den Hinweis, werden wir mit dem nächsten Update beheben.
Simone Heckmann (Sep 24 2021 at 14:27):
:bug: ?
Patrick Werner (Sep 24 2021 at 14:27):
ja
Alexander Rohde (Sep 24 2021 at 14:30):
Ok, danke & schönes WE!
Patrick Werner (Sep 24 2021 at 14:32):
wünsche ich ebenfalls
Patrick Werner (Sep 26 2021 at 12:59):
@Alexander Rohde
Ich habe heute den Test angepasst, es wird nun ein content-Header mit versandt.
Es wird noch ein wenig dauern bis diese Version ausgerollt wird - ich gebe Ihnen dann gerne Bescheid,
Patrick Werner (Sep 30 2021 at 09:42):
@Alexander Rohde eine neue Version wurde released, der Compostiontest sollte nun den conten-type header mitsenden
Alexander Rohde (Sep 30 2021 at 11:32):
Danke, werde ich testen!
Alexander Rohde (Oct 08 2021 at 12:50):
Eine Frage zum Composition Test: Aktuell verwende ich @Transaction in meinem CompositionProvider (IResourceProvider) zur Entgegennahme des Posts. Das funktioniert auch soweit, die CompositionResource ist vollständig gefüllt.
Als Antwort wird von Titus OperationOutcome erwartet, das kann ich aber in dieser Konstellation nicht erzeugen, weil IBaseBundle zurückgegeben werden muss. Wenn man das selber implementieren muss, an welcher Stelle kann ich ansetzen, eigener Interceptor?
Stoyan Halkaliev (Oct 28 2021 at 16:24):
Hi,
ich habe heute auch getestet, ich denke Titus sendet beim Composition-Test an das falsche Endpoint. In meinem Log finde ich:
POST http://xxx.xxx.xxx.xxx:8000/
und in die Body den Payload:
{ "resourceType": "Bundle",
"id": "#compositionBundle02",
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:uuid:0c3151bd-1cbf-4d64-b04d-cd9187a4c6e0"
},
"type": "document",
"timestamp": "2013-05-28T22:12:21Z",
"entry": [...
es wird also ein "type": "document" an das root-Endpoint geschickt. Das ist, glaube ich, nicht korrekt. Laut Spec here:
https://www.hl7.org/fhir/documents.html#bundle
sollte das an das /Bundle -Endpoint geschickt werden (also an POST http://xxx.xxx.xxx.xxx:8000/Bundle). Mein Server (SmileCDR) beschwert sich entsprechend:
{ "resourceType": "OperationOutcome",
"issue": [
{ "severity": "error",
"code": "processing",
"diagnostics": "Unable to process transaction where incoming Bundle.type = document"
} ]
}
@Patrick Werner - ja, nein, vielleicht ? ;-)
Stoyan Halkaliev (Oct 28 2021 at 16:34):
Simone Heckmann said:
Ja, 4. Fall in der Liste der Document-Endpoints. Der Payload muss allerding eine Bundle vom Typ "document" sein, keine Composition.
Hi @Simone Heckmann, da bin ich nicht ganz einverstanden. Ich denke, hier sind wir in den 1. Fall. Laut diese genauere Beschreibung:
http://hl7.org/fhir/http.html#other-bundles
A server may choose to accept bundle types other than batch or transaction when POSTed to the [base] URL....
Da also, laut FHIR selbst, das optional ist, denke ich, dass wir mit den /Bundle arbeiten sollen. Wir können es gerne heute Abend besprechen
Simone Heckmann (Oct 28 2021 at 16:54):
Nein, das ist schon korrekt so. Das Dokument soll ja nicht einfach 1:1 als Bundle in der DB "geparkt" sondern verarbeitet werden. In Stufe 1 besteht diese Verarbeitung zunächst nur aus der Übernahme des Narratives und der korrekten Einordnung (zu Patient und Fall). In weiteren Ausbaustufen sollten dann auch strukturierte Inhalte übernommen werden (soweit diese vom empfangenden System verstanden werden).
Da in FHIR nicht festgelegt ist, was unter der "Verarbeitung" eines Dokumentes zu verstehen ist, gibt es bei den Referenzimplementierungen wie z.B. HAPI eine entsprechende Fehlermeldung. Die Verarbeitung im Sinne von ISiK muss hier selbst implementiert werden.
Simone Heckmann (Oct 28 2021 at 16:58):
Wenn du ein FHIR-Natives System hast, das von Anfang an alle strukturierten Inhalte vollständig verarbeiten kann, dann kannst du das gerne tun, aber für die korrekte Zuordnung zu Patient und Fall anhand der Identifier braucht's dennoch ein paar Zeilen Businesslogik. Um den Narrative korrekt und vollständig wiederzugeben zu können, kannst du entwerder das HTML rausziehen und mit einer DocumentReference persistieren oder das Bundle 1:1 speichern und den Narrative bei Bedarf daraus extrahieren. Das Originaldokument sollte in seiner menschenlesbaren Form auf jeden Fall erhalten bleiben.
Patrick Werner (Oct 28 2021 at 17:18):
Die gängigen FHIR Server (Frameworks) können das nicht out-of-the-box. Wie Document Bundles verarbeitet werden ist im FHIR Standard nicht näher definiert.
Im hapi/Smile Umfeld lässt sich das Problem relativ leicht mittels eines Interceptors lösen.
Stoyan Halkaliev (Oct 28 2021 at 17:38):
@Simone Heckmann, ich gehe natürlich von einem FHIR-Natives System aus. Weil ein 3rd-Party-App später das auch erwarten würde. Wenn Dokumente geschickt werden (type="document"), die dann auch erhalten bleiben sollten, dann finde ich das [base]/Bundle passender. Wenn auseinandergenomen werden, dann entsprechend als "transaction". Wenn jetzt Titus darauf besteht an die [base] die dokumente zu schicken, sollte dann weningstens das Endpoint konfiguriertbar sein, damit FHIR-Native-Systeme auch sich standartkonform verhalten können. Ich denke, je konkreter die Vorgaben, desto besser. Für uns macht es keinen Sinn diese Sonderlocke zu implemetieren, um nur beim Titus-Test einen Check zu bekommen, wo Titus (technisch) auch an /Bundle schicken könnte.
Stoyan Halkaliev (Oct 28 2021 at 19:06):
Ah ja, beide Test-Compositions haben kein Narrative @Patrick Werner.
Simone Heckmann (Oct 28 2021 at 20:16):
Ein Post auf /Bundle wäre in diesem kontext völlig falsch, da das Dokument einfach in die DB gepackt würde, es hätte weder einen Bezug zum richtigen Patienten, noch zum Fall und würde folglich auch beim Aufruf der Patientenakte nicht angezeigt/BEi der Suche im Fallkontext nicht gefunden. Transaction/Batch wäre auch falsch, weil ein Client mit dem Versand eines Dokumentes keine Intention ausdrückt (Create/Update/Delete) sondern dem Empfänger die Entscheidung überlässt, wie mit dem Inhalt zu verfahren ist.
Beim posten eines Dokumentes auf [base] obliegt es dem Empfänger zu entscheiden, wie mit dem Dokument (und seinen Einzelteilen) umzugehen ist. Dazu braucht jedes System eine spezifische Business-Logik um diese Entscheidung treffen zu können. Diese Logik ist Use Case spezifisch und daher nicht Teil einer Referenzimplementierung wie HAPI.
Aus dem selben Grund kann HAPI keine Message Bundles verarbeiten, weil dies die Vereinbarung von Eventcodes und die Implementierung entsprechender Business-Logik voraussetzt. Das wäre aber kein Argument um zu sagen, dass man in FHIR kein Messaging machen darf.
Simone Heckmann (Oct 28 2021 at 20:16):
Die Test-Compositions in TITUS sollten aber selbstverständlich einen Narrative enthalten :D
Christof Gessner (Oct 28 2021 at 20:45):
Zum Verständnis: geht es Euch hier eigentlich um FHIR-Kommunikation via KIM? Oder was ist der betrachtete Transport-Use-Case hier?
Alexander Zautke (Oct 29 2021 at 06:01):
Nein, red geht um die Kommunikation eines Subsystems, das ein Dokument an ein KIS zurückübermitteln möchte.
Patrick Werner (Oct 29 2021 at 10:20):
Simone Heckmann said:
Die Test-Compositions in TITUS sollten aber selbstverständlich einen Narrative enthalten :D
Beide TestCompositions enthalten natürlich bereits ein Narrative. Einmal in für die gesamte Composition & einmal für eine Section.
Last updated: Apr 12 2022 at 19:14 UTC
