bundle of type "transaction" vs contained ressource

[PBACIN]

As this is an important subject that will be repeated in other projects, could you explain the approach taken by uhmep and why?

https://www.hl7.org/fhir/R4/bundle.html https://www.hl7.org/fhir/search.html#contained ...

Thank you.

[MatonAnthony]

I'm very sorry, I was unable to get this on paper on-time for our meeting. I'm not forgetting you, I will come up with a written version ASAP

[bdc-ehealth]

WG: Robin (Corilus) thinks that the transaction approach for creation could be interesting as well.

[MatonAnthony]

Here is our reasoning, sorry it's a bit late but we had a last meeting on this yesterday.

The decision has been made a while back to forego the use of contained resources. This is an attempt to explain why we took this decision.

Context

The application concerned here is UHMEP, an application made for the treatment of referral prescriptions. The applications offers access and workflow to and around the referral prescriptions. Since those characteristics are not fitting with the FHIR message oriented patterns, we have decided to go for the FHIR REST API patterns.

For this patterns, we are trying to be as much as we can compliant with the REST idioms and patterns, and of course compliant with the FHIR recommendations.

Contained resources vs Bundle vs Reference

Contained resources

A contained resource, is a FHIR resource contained inside of another resource. If your prescription (ServiceRequest) needs a patient (Patient), you would directly embed the patient inside the ServiceRequest.

It's well adapted when the resource you package inside is a "dead" resource, it complements the resource it's embedded in but has no lifecycle of its own.

So if we resume it:

• No lifecycle of its own
• More complex search
• Everything is packaged in the resource

Transactional Bundle

A transactional bundle is a FHIR resource that contains all FHIR resources necessary to process a request. It's the recommended way to implement the FHIR message oriented patterns. The message is completely contained in this transactional Bundle.

For UHMEP, we are not a message broker. We are not receiving complete document that are destined to be offloaded to another system. We are a workflow engine for healthcare professionals and patients. As such, while this pattern could have fit, it seemed to us (and it is to some extend a judgement call we made) to be the wrong fit for UHMEP compared to the FHIR REST API patterns.

It presents the same benefit as the contained resources, the request is complete on its own and the lifecycle is tied to the message.

So if we resume it:

• Everything is packaged in the request
• The message in itself has a lifecycle, but not the resource contained in the Bundle, they are there solely to support the message as a whole
  • How the lifecycle is handled afterwards is not the concern of the sender
• Since every resource is sent separately you could search on them, assuming they are saved

References

The reference model is the more REST API like, we reference an existing resource that has a lifecycle of its own and should be referenced when you make the request. Depending of the ownership of this resource, you might have to create it first or make a reference to an authentic source.

For UHMEP this seemed like the better fitting model, aligned with the REST standard. If the resource belongs to the doctor creating it, he should be able to create it and the lifecycle expectations are clearly defined. On the other side, if the information belongs to an authentic source or to the system in itself, its lifecycle is completely hidden from the integrator.

So if we resume it:

• Nothing is packaged with the request, everything should be referenced
• The lifecycle concerns are only those of the resources owned by the integrator
• The ownership of resource provided by authentic source is clear and so are the validation tied to it

Limitations

The solution we chose present one big limitation, the authentic source we use are not providing a FHIR facade to query them. As such they do not support FHIR references. To alleviate this issue, we provide as UHMEP a limited FHIR facade on top of the one we use, with extremely limited functionalities (the ones needed for the reference to be meaningful).

[bdc-ehealth]

Comments by René Spronk (HL7 FHIR Int'l) on the document below. Question by Philippe Baise. @MatonAnthony uhmep approach (1).docx

From: Rene Spronk [XXX@fire.ly](mailto:XXX@fire.ly) Sent: Tuesday, July 4, 2023 4:15 PM To: Philippe Baise [XXX@intermut.be](mailto:XXX@intermut.be) Subject: Re: fhir advies

Hi Philippe,

The containment mechanism is only applicable in a very constrained set of use cases, which doesn't apply here. Practitioners and PractitionerRoles have business identifiers are are managed by an authoritative registry, so the containment option isn't available.

If the 'cobra' registry had an FHIR api, you would either

1. ask clients to first search for the logical id of a practitioner/practitioner role, before using their logical ids in the ServiceRequest. A very REST way of doing things, but with some overhead of having to look at the registry first. uhmep offers a FHIR API to cobra data, so this is an option.

2. normally, with an authoritative registry, and identifiers known to all systems, one would use a reference based on business identifiers instead of on a logical id. See http://build.fhir.org/references-definitions.html#Reference.identifier - that option specifically exists for this kind of situation (known business identifier, unknown logical id).

However, option 2 will work for Practitioners, but not for PractitionerRoles, as I understand from the document these don't have a business identifier in the cobra registry - the identifier is a tuple of (ssin, role) [to me that's a bad design on the part of cobra, but that's beside the point right now]. So for PractitionerRoles you'd have to use option 1.

The Bundle (transaction, message) option gets around the problem for a client and forces the server to resolve the references.

In a limited context one could document/assume that cobra (its FHIR frontent) has a certain logical id based on a business identifier. That's not pretty, but we've seen that elsewhere as well. For PractitionerRoles I'm less confident that it'll work because I don't know the details of cobra - GET /PractitionerRole/82042605839-NURSE - what if you have 2 nursing roles in different organizations? Two periods in history when you've been a nurse ? BePractitionerRole allows one to have multiple specialties (from SNOMED) and multiple codes. A mapping to a logical id structure is not a really clean one. It can probably be made to work, be it needs some very careful implementation and strong guidance how to do so. I don't have a positive gut feeling with this type of workaround for PractitionerRole, such hacks tend not to scale too well.

If I had a choice in the matter I'd prefer to go for option 1, it's scalable, most REST-like as an option, and allows for a lot of flexibility moving forward. Some sort of bundle would be my second preference.

I hope this helps your decision making process,

With best regards,

-Rene