medizininformatik-initiative / kerndatensatzmodul-consent

Kerndatensatzmodul Consent
2 stars 0 forks source link

Search Parameter problems #23

Closed nektarios-ladas closed 1 year ago

nektarios-ladas commented 1 year ago

Hi, I have installed an out-of-the-box Blaze Server. After inserting a Consent , I am defining a search parameter resource. { "resourceType": "SearchParameter", "id": "mii-provision-provision-code", "url": "https://www.medizininformatik-initiative.de/fhir/modul-consent/SearchParameter/mii-sp-consent-provisioncode", "version": "1.0.3", "name": "MII_SP_Consent_ProvisionCode", "status": "active", "date": "2023-03-08", "description": "Suche im Code der Provison", "code": "mii-provision-provision-code", "base": [ "Consent" ], "type": "token", "expression": "Consent.provision.provision.code" }

The search parameter is generated successfully on the server. Whenever I make a search on the server for

http://localhost:8080/fhir/Consent?mii-provision-provision-code=2.16.840.1.113883.3.1937.777.24.5.3.30

I am getting a result, If I change a code with a none existing one, I am still getting a result. Can you please advice me with any hints or suggestions ? It seems that the search parameter is being ignored, still If I search for a parameter that does not exist , I am always getting a result.

Best Regards Nektarios

mosaic-hgw commented 1 year ago

Hi,

2.16.840.1.113883.3.1937.777.24.5.3.30 refers to a MODULE of the MII Broad Consent.

I suggest, you are trying to request a consent policy by policy-code. The correct code for the consentpolicy "Rekontaktierung Zusatzbefund" is 2.16.840.1.113883.3.1937.777.24.5.3.31,

Details from https://www.medizininformatik-initiative.de/Kerndatensatz/Modul_Consent/IGMIIKDSModulConsent-TechnischeImplementierung-Terminologien.html

Hope this helps.

We forward the second part of your question to a responsible collegue and come back with more details on your issue soon.

Regards,

M

nektarios-ladas commented 1 year ago

Thank you

Nektarios Ladas, MSc Peter L. Reichertz Institut für Medizinische Informatik der TU Braunschweig und der Medizinischen Hochschule Hannover Research Associate Raum: M02-S0-0139, Et-Cetera-Gebäude, Karl-Wiechert-Allee 3 Postanschrift: Medizinische Hochschule Hannover, PLRI - OE 8420, Carl-Neuberg-Straße 1, 30625 Hannover, Deutschland @.***https://webmail.mh-hannover.de/owa/redir.aspx?C=2o3c9Nz9291JzMYfCHI81wOZ2Dz5UnIQPO1-V3jzZdUd34nZNC7YCA..&URL=mailto%3achristina.demmer%40plri.de www.plri.dehttps://webmail.mh-hannover.de/owa/redir.aspx?C=K252-oZ4AJWX9WBDTNu6K8-NG8W9S6GBSdGCLrvqy3wd34nZNC7YCA..&URL=https%3a%2f%2fwebmail.mh-hannover.de%2fowa%2fredir.aspx%3fSURL%3da57EiDIJoyoRW5ZZqI8D8WOYIWMkLY4Sa_Fc8rqtjN7Wc6ZIuGHVCGgAdAB0AHAAOgAvAC8AdwB3AHcALgBwAGwAcgBpAC4AZABlAC8A%26URL%3dhttp%253a%252f%252fwww.plri.de%252f / https://www.mh-hannover.de/medic.htmlhttps://webmail.mh-hannover.de/owa/redir.aspx?C=FT5gyx4cr6j6E9ivH0lksuH5PGIvcnQXXXoJIIdcCOEd34nZNC7YCA..&URL=https%3a%2f%2fwww.mh-hannover.de%2fmedic.html / http://www.highmed.org/https://webmail.mh-hannover.de/owa/redir.aspx?C=QutrKN2ZUEufE749npE4L03dyN3IsH4v0HDlhubfcpUd34nZNC7YCA..&URL=http%3a%2f%2fwww.highmed.org%2f


Von: mosaic-hgw @.***> Gesendet: Donnerstag, 11. Mai 2023 11:29:35 An: medizininformatik-initiative/kerndatensatzmodul-consent Cc: Ladas, Nektarios; Author Betreff: Re: [medizininformatik-initiative/kerndatensatzmodul-consent] Search Parameter problems (Issue #23)

Hi,

2.16.840.1.113883.3.1937.777.24.5.3.30 refers to a MODULE of the MII Broad Consent.

I suggest, you are trying to request a consent policy by policy-code. The correct code for the consentpolicy "Rekontaktierung Zusatzbefund" is 2.16.840.1.113883.3.1937.777.24.5.3.31,

Details from https://www.medizininformatik-initiative.de/Kerndatensatz/Modul_Consent/IGMIIKDSModulConsent-TechnischeImplementierung-Terminologien.html

Hope this helps.

We forward the second part of your question to a responsible collegue and come back with more details on your issue soon.

Regards,

M

— Reply to this email directly, view it on GitHubhttps://github.com/medizininformatik-initiative/kerndatensatzmodul-consent/issues/23#issuecomment-1543656625, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACIOIR44OS6SJTGQMCFN4JDXFSWP7ANCNFSM6AAAAAAX4XJJVE. You are receiving this because you authored the thread.Message ID: @.***>

juliangruendner commented 1 year ago

@nektarios-ladas please note that for blaze you cannot insert search params using the SearchParameter Endpoint. We do however provide a version of the blaze server which comes with these search parameters pre-installed: https://github.com/medizininformatik-initiative/blaze Image see: ghcr.io/medizininformatik-initiative/blaze:0.20.6

For the next iterations of blaze we are working on a version of blaze which allows mounting additional search parameters via a file, which will then allow you add new search parameters later. @alexanderkiel FYI

juliangruendner commented 1 year ago

@nektarios-ladas further it is worth noting, that blaze will ignore "bad" search parameters unless you have the following header set for your request: --header 'Prefer: handling=strict'

if you try the same search with handling strict you should get an error in your case which should look something like this:

{ "issue": [ { "severity": "error", "code": "not-found", "diagnostics": "The search-param with code mii-provision-provision-code and type Consent was not found." } ], "resourceType": "OperationOutcome" }

lhitc commented 1 year ago

Die FHIR-Spec spricht sich allerdings klar gegen ein Default-Verhalten "strict" aus:

http://www.hl7.org/fhir/r4/search.html#errors :

Servers may receive parameters from the client that they do not recognize, or may receive parameters they recognize but do not support (either in general, or for a specific search). In general, servers SHOULD ignore unknown or unsupported parameters for the following reasons:

Various HTTP stacks and proxies may add parameters that aren't under the control of the client
The client can determine what parameters the server used by examining the self link in the return (see [below](http://www.hl7.org/fhir/r4/search.html#conformance))

Clients can specify how the server should behave, by using the prefer header

Prefer: handling=strict: Client requests that the server return an error for any unknown or unsupported parameter
Prefer: handling=lenient: Client requests that the server ignore any unknown or unsupported parameter

Servers SHOULD honor the client's request, but are not required to do so."

alexanderkiel commented 1 year ago

Die FHIR-Spec spricht sich allerdings klar gegen ein Default-Verhalten "strict" aus:

http://www.hl7.org/fhir/r4/search.html#errors :

Servers may receive parameters from the client that they do not recognize, or may receive parameters they recognize but do not support (either in general, or for a specific search). In general, servers SHOULD ignore unknown or unsupported parameters for the following reasons:

Various HTTP stacks and proxies may add parameters that aren't under the control of the client

The client can determine what parameters the server used by examining the self link in the return (see [below](http://www.hl7.org/fhir/r4/search.html#conformance))

Clients can specify how the server should behave, by using the prefer header

Prefer: handling=strict: Client requests that the server return an error for any unknown or unsupported parameter

Prefer: handling=lenient: Client requests that the server ignore any unknown or unsupported parameter

Servers SHOULD honor the client's request, but are not required to do so."

Right. That's why I implemented lenient handling by default in Blaze.