use of the _profiel parameter in FHIR Searches

[andries]

Hello,

I have a question/suggestion on the use of the FHIR _profile search parameter I would like to solicit feedback on.

In the FHIR standard, in the definition of the search (https://www.hl7.org/fhir/search.html) operation, there is mention of a _profile parameter. When used it should indicate a FHIR server to restrict the search to resources that are tagged as conforming to a particular profile. 

However, when reading a variety of FHIR Implementation Guides it seems that a profile defines more than just a set of resources. For example the USCore implementation Guide also defines resource search parameters, operations, terminology, etc. Some of the IHE profiles that use FHIR do the same (e.g. PDQm, PIXm, etc.). 

As an IHE profile (and a FHIR IG) are thus defining the "behaviour" (or capabilities) of both the client and server it assumes that a client has prior knowledge of the server it is interacting with. For example, should a PDQm Consumer actor interact with a non-PDQm Supplier the response may not be as expected according to what the PDQm profile defines.

Hence, my question/suggestion. Would it make sense to mandate the use of the _profile parameter in (at least) IHE profiles that define a "FHIR consumer" actor. Doing so would allow a "FHIR Server" to determine what the response expectations of the FHIR consumer are in terms of resource content, error handling, etc. If the profile specified is not supported by the server the latter can give a graceful response (i.e. an error, a warning, etc.). It also allows a FHIR server to validate the incoming request/resource to the profile specified. 

The alternative to using the _profile parameter would be to have a FHIR server create different end-points. One for each profile it supports. However, that puts the burden on the FHIR client to find out which end-point(s) to call. Theoretically this can be done by first requesting the server's capability statement. However, that adds additional complexity to the FHIR consumer. 

Curious to learn what this groups thoughts are.

Best regards,

Andries Hamster

[John Moehrke]

My opinion is that this would be a bad idea. 

First of all the structureDefinition Profile is more of a specification of the "Message Encoding" as part of the typical IHE Volume 2 transaction (trigger event, message encoding, expected actions), or Volume 3 content specification. These structureDefinition Profiles do have a canonical URI and can be decoration in the profile element of a resource... but population in a resource should never be required.

Second of all, a client should always follow Postel's Law, and be robust to deviations from norm. 

If you included the profile canonical on the search, this would be an indication that you don't want any resources that don't have that profile declared. which means you would/could miss resources that are perfectly compliant, they simply were not decorated with the profile.

If you really need more tight behaviour, then an Operation should be used. Such as we did with PIXm, where we could not get tight enough behaviour out of the query with REST search.

Postel's Law is key to interoperability. 

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

--
You received this message because you are subscribed to the Google Groups "IHE ITI Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/c9041f95-50d8-41b4-9caf-1038b7b25eban%40googlegroups.com.

[Vassil Peytchev]

In addition, the original question seems to mix the “StructureDefinition profiles” with “IHE profiles” – the _profile search parameter is strictly for the former and should not be use in any other way.

 

From: iti...@googlegroups.com <iti...@googlegroups.com> On Behalf Of John Moehrke
Sent: Wednesday, November 9, 2022 8:04 AM
To: andries <and...@founda.com>
Cc: IHE ITI Technical Committee <iti...@googlegroups.com>
Subject: Re: [ititech:9196] use of the _profiel parameter in FHIR Searches

 

External Mail. Careful of links / attachments. Submit Helpdesk if unsure.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/CACDGQjtV5%3DBxGOBmeMkoaH7NqjosTDiuW2QaD_cH38mehNsUKw%40mail.gmail.com.

[andries]

Thanks John and Vassil,

To Vassils point I am indeed not clear on use of the term 'profile'. In the end what I am looking for is a way for a (fhir) client to indicate to a (fhir) server what "behaviour" it is expecting. For example, as a client (application) that implements the IHE PDQm profile I would like to indicate to the server that my request follows the PDQm definitions, and that I expect the server to return a response according the the IHE PDQm profile. 

Best regards,

Andries Hamster

[Oliver Egger]

Hi Andries

Thanks John and Vassil,

To Vassils point I am indeed not clear on use of the term 'profile'. In the end what I am looking for is a way for a (fhir) client to indicate to a (fhir) server what "behaviour" it is expecting. For example, as a client (application) that implements the IHE PDQm profile I would like to indicate to the server that my request follows the PDQm definitions, and that I expect the server to return a response according the the IHE PDQm profile. 

The building blocks for this are the CapabilityStatements a client (https://profiles.ihe.net/ITI/PDQm/CapabilityStatement-IHE.PDQm.client.html) or a server (https://profiles.ihe.net/ITI/PDQm/CapabilityStatement-IHE.PDQm.server.html) would claim conformance too.

This can then be used on the instance level for a client or a server. I'm however not aware that in that way

a client could communicate an expected behaviour to the server.

Best regards,

Oliver

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/bcface32-5735-4d27-afa6-3ef646d7920bn%40googlegroups.com.

[andries]

Hi Oliver

Thanks for replying. The challenge we have is formulated in your last sentence ("I'm however not aware that in that way a client could communicate an expected behaviour to the server."). 

Since we are building a gateway product that implements multiple IHE profiles and FHIR IGs we're looking for a way a client can indicate to the server what IHE Profile or FHIR IG it is using. We expose one FHIR endpoint per resource., for example https://<server>/fhir/R4/patient, and would like to "behave" differently for a client that indicates to follow IHE PDQm versus one that follows the FHIR US Core Implementation Guide. 

Using the _profile parameter doesn't seem to be an option given the discussion in this thread. However, we would like to stay away from creating an endpoint per profile (e.g. https://<server>/fhir/R4/IHE-PDQm/patient, and https://<server>/fhir/R4/uscore-ig/patient). 

Any suggestions?

Thanks

Andries

[John Moehrke]

When using FHIR search, the only thing that can be expected is that you are following the FHIR search. Neither US-Core nor IHE should expect anything other than FHIR search behaviour. In what way has one of them expected different behaviour? This should be reported as a problem for that specification to fix. 

If a more specific behaviour is needed, then an Operation is the method available from FHIR.

John Moehrke 🔥 Architect: Healthcare Informatics Standards - Interoperability, Privacy, and Security
IHE Co-Chair IT Infrastructure Planning and Technical
HL7 Co-Chair Security WG, FHIR FMG, FHIR facilitator, and FHIR Foundation founding member

Employee of By Light -- Contractor to VHA MyHealtheVet
JohnM...@gmail.com  |  M +1 920-564-2067  |  John.M...@bylight.com
 https://healthcaresecprivacy.blogspot.com

To view this discussion on the web visit https://groups.google.com/d/msgid/ititech/4a83e674-d0f9-4646-8a06-a64d2868f816n%40googlegroups.com.