Stream: implementers
Topic: FHIR - Using extensions or contained instead of a resource
Kevin Mayfield (Dec 09 2021 at 12:21):
Do we have any concrete guidance on this?
For contained we have https://www.hl7.org/fhir/references.html#contained
but we have a group arguing that we should be converting resources into extensions in order to get RESTful interactions.
It seems a little daft to me but could do with some references.
René Spronk (Dec 09 2021 at 12:52):
? why would you want to to do either alternative thing?
Rik Smithies (Dec 09 2021 at 13:04):
@Kevin Mayfield Contained uses the standard. Ad hoc extensions don't.
Contained works fine as part of REST. Hard to see why resources need to be converted to extensions, and hard to find a references to say "don't do that it's obviously weird" :-)
@René Spronk I believe the issue (from the UK) may be that a "single resource" needs to be sent (MedicationRequest), with a reference to a Patient. However the Patient has to be included in the payload for "legal reasons" of completeness. So that needs a Bundle. But there is a feeling that Bundles are complicated somehow or not REST, or are not MedicationRequest. Or a feeling that using a FHIR message makes this better, because a REST Bundle is not correct somehow and servers don't know what to do with them.
So the thinking is to have MedicationRequest with an extension for the patient data (and some other things). I have expressed my strong view that that is not a good way to do things. Contained would be ok. But people don't like that either.
Kevin Mayfield (Dec 09 2021 at 13:13):
Yes we have a requirement to send a (full) PractitionerRole and Patient resource data alongside 1..4 MedicationRequests.
The best I can find at the moment is this
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1
which to me implies the RESTful proposal to use extensions is not RESTful as the resources are moving back to the single entity model rather than collection of entities (I may have misread though)
Kevin Mayfield (Dec 09 2021 at 13:15):
The stated requirement is the interaction MUST be RESTful.
René Spronk (Dec 09 2021 at 13:16):
Bundle is a RESTful Resource, it's as simple as that.
Rik Smithies (Dec 09 2021 at 15:35):
@Kevin Mayfield using extensions (for embedded resources) is not non-REST I don't think, but it does kind of break the idea of a REST api that supports those resource types as collections in their own right (unless via a sanctioned method - which is "contained").
However I don't expect that point carries much weight here, or it would not even be on the table.
So this is not non-REST perhaps, it's just non-standard-FHIR.
FHIR has standard ways to do this, and extensions for embedded resources are not one of them.
The message from this thread perhaps is that the other methods on the table are known to be standard FHIR, and are REST (except the messaging one obviously) and therefore should be preferred to other methods which are not standard FHIR - regardless of whether or not they are REST.
Kevin Mayfield (Dec 09 2021 at 15:53):
That's roughly my view, its not standard FHIR and so starts to cause issues/difficulties.
To be honest it's stumped me, I'm of similar opinion to @René Spronk and just could find a simple answer to rebut it.
Lloyd McKenzie (Dec 09 2021 at 16:09):
There's no mechanism to send a resource in an extension - all you can do is send a reference. Contained is only for resources without independent identity and can't stand alone. If you need to send multiple resources at once, then Bundle is the 'correct' way to do so.
Kevin Mayfield (Dec 09 2021 at 16:20):
@Lloyd McKenzie that's not the intent. Its to create an extension to hold Patient or PractitionerRole data, so we would literally be creating a complex extension with name, identifier, address, birthDate, etc.
Lloyd McKenzie (Dec 09 2021 at 16:23):
Ok. That's, in general, a bad idea. There are rare circumstances where it might be justifiable (e.g. I need one element from a resource that I'd otherwise have to chain through two resources to get). But if you're representing multiple elements from a related resource, then just point to that resource.
Lloyd McKenzie (Dec 09 2021 at 16:23):
If it's a situation like a prescription where you've got a prescriber name and phone number, but that information is maintained as a part of the prescription and doesn't have independent identity, then 'contained' is appropriate.
Elliot Silver (Dec 09 2021 at 17:18):
Unless an extension is marked modifier, a recipient has to be free to ignore the extension without changing the meaning of the underlying resource. It doesn't sound like that's the case here.
Rik Smithies (Dec 09 2021 at 18:15):
That is true and a very good point. However the idea that any data could be safely ignored tends to go down very badly with system specifiers in my experience, so this fact may not have an impact.
Lloyd McKenzie (Dec 09 2021 at 18:25):
The challenge is that systems may have all sorts of extensions you don't recognize - and it's bad practice to reject instances that contain extensions you don't recognize because that increases costs for everyone. That leaves ignoring them unless the system has an ability to manage unrecognized extensions.
Grahame Grieve (Dec 09 2021 at 19:01):
However the Patient has to be included in the payload for "legal reasons" of completeness
Whatever legal langauge leads to this statement, the interpretation means that it's impossible to use REST, or any other technical approach that modularises information for technical reasons. As interpreted, it is outright a requirement to use messaging.
I don't think you should muck around on this, or try to weasel around it with extensions, because if the interpretation stands, you'll disappear up a recursive creek with no paddle
Grahame Grieve (Dec 09 2021 at 19:03):
what's the actual language that leads to this interpretation?
Rik Smithies (Dec 09 2021 at 21:44):
Except for contained though? That is REST. All the data is right there. There is no semantic that says what to do with it - which messaging would add (or a Task) - but it is still REST.
I don't have the language but I assume the gist is that the "message" (meaning data in transit - ideally paper :-) has to be identified to the patient. I don't see why that precludes REST even if it makes references a bit useless. The receiver can fix that up.
Vassil Peytchev (Dec 09 2021 at 22:03):
the message [...] has to be identified to the patient
Isn't the patient NHS number provided in the reference as an identifier sufficient?
Besides, this whole conversation helps illustrate the difficulties one may get into when trying to oversimplify a workflow and forgo Task. If instead the sequence were
Prescriber -------------------- POST Task ---------------> Fulfiller
<-- GET MedicationRequest + _inlcude Patient --
You have your single structure (Bundle) satisfying the letter and the spirit of the law in a RESTful environment.
Grahame Grieve (Dec 09 2021 at 22:22):
That is REST
There's no clear definition of that. But what I can tell you is: it's a bad idea to use contained resources which aren't really contained. It's a bad idea to let a legal requirement for consistency affect your technical choices around modularity.
Rik Smithies (Dec 09 2021 at 22:23):
@Vassil Peytchev
I don't think that an identifier counts as identification of the patient. A piece of paper with just an NHS number on it would not be enough I guess, so the same applies to electronic paper.
To the second point that means all clients need a server, and the Bundle fetched from the Prescriber has the same issues as we already have. Your solution is fine though, just as the original unpopular FHIR conforming proposals are. The originally proposed Bundle is fine, or even a MedicationRequest with a contained Task. There is no technical problem that I can see.
Vassil Peytchev (Dec 09 2021 at 22:29):
To the second point that means all clients need a server
I think every time we are talking about system-to-system interoperability and expressing a workflow while using REST, both sides have to be both clients and servers. The exception might be if there is infrastructure to provide a common FHIR server for all participants, then all participants are clients.
Lloyd McKenzie (Dec 09 2021 at 23:53):
If there's an expectation for resolution of the contained resource, then you're using contained incorrectly. If the intention is "store this script with the contained information and don't link it to anything else for that patient", then that's a valid use.
Rik Smithies (Dec 10 2021 at 01:14):
A Bundle is preferable, because the patient info is intended for resolution. I suppose it may depend if the data stays as readable RESTful FHIR or is consumed some other way where the fact that it was contained disappears (like a one way message basically). But still a Bundle seems best, presumably a transaction that always creates the MedicationRequest and which is linked to a Patient in the Bundle that has a conditional create (that always finds a pre-existing match).
Lloyd McKenzie (Dec 10 2021 at 06:01):
There are a variety of options:
- you can go full rest and query for the providers and patient and reference them
- you can post just the MedicationRequest within a transaction Bundle with conditional references to allow resolving to the patient and providers on the target system
- You can post all 3 types of resources in a single transaction
- You can send the combination in a document
- You can send everything in a message
- You can use contained resources and not expect resolution/linking on the other end
Typically those later in the list are costlier/less flexible than the former - but sometimes architectures make them necessary
Kevin Mayfield (Dec 10 2021 at 06:04):
@Vassil Peytchev Yes FHIR Workflow is the basis of the current system, which is currently based on https://www.hl7.org/fhir/workflow-management.html#optionh
The workflow approach was also in the previous HL7v3 model. (I see this as a bonus)
The main technical group has took exception to initial POST request (item 1 in the workflow option H diagram) being a FHIR Message (https://simplifier.net/guide/DigitalMedicines/prescription-orxder).
We do use NHS Number and currently we recommend a supplier use our Patient api to source the resource (so they just need to copy the resource into the message). The other non MedicationRequest data is mostly based on data we hold and maintain.
So roughly all the supplier needs to do is supply the MedicationRequest , call a few APIs and assemble the Bundle.
Rik Smithies (Dec 10 2021 at 13:25):
to @Lloyd McKenzie's list, "post just the MedicationRequest within a transaction Bundle with conditional references" - is that something other than another Patient in the Bundle with a conditional create (POST and an If-None-Exist query)?
Lloyd McKenzie (Dec 10 2021 at 14:03):
Definitely different - see the section on conditional references here
Brian Diggle (Dec 10 2021 at 17:26):
To clarify this context for this thread:
There is no requirement to send full PractitionerRole and Patient resources alongside the Medication Request.
This is a legal requirement to send Patient name, patient address, and in some circumstances patient DOB "in the request". These pieces of information are there for purely legal reasons for the purposes of the request message being classed as a "prescription"
We are not looking to "convert resources into extensions"
In designing an API we are considering how to present the simplest, most easily understood API to consumers - following "consumer first thinking". Our starting position therefore is a set of restful resource based endpoints with CRUD operations, and we are considering how to stay close to that simplicity while staying "legal" in FHIR terms.
@René Spronk Bundle to me is not simply a RESTful resource. I think of a resource as a real entity - a bundle is a collection of arbitrary entities. Exposing CRUD operations on a Bundle doesn't fit nicely with a resource based architecture concept. And it doesn't make sense to consumers. If I POST a MedicationRequest I know what I'm doing - but if I POST a Bundle, it's not obvious. REST APIs should be self-documenting.
John Moehrke (Dec 10 2021 at 17:36):
I think this is a problem of perceived reality. If one defines a set of RESTful requirements at the Resource level, classic FHIR REST. And this "set of RESTful requirements" is then viewed as a 'whole'. Then that 'whole' meets the legal requirement. This is systems-engineering. Creating a system that is greater than the parts, yet all the parts are necessary for the system.
I don't think that this is systems-engineering deception. We (IT geeks) are all happy understanding that a "server" is one thing, yet that server is made up of many hardware components from many suppliers, assembled by many factories, with many software components orchistrated by an operating system..... etc... etc...etc.
Vassil Peytchev (Dec 10 2021 at 17:45):
If I POST a MedicationRequest I know what I'm doing.
When you post a MedicationRequest you are recording the authorization for a Medication to be provided to a patient, with the expectation that the resource is persisted and available for future access and retrieval.
What you are not doing is requesting the fulfillment of the prescription (unless the MedicationRequest is specially flagged), and you are not starting a workflow that can track the process of prescribing, dispensing, and in some cases administering a medication.
Rik Smithies (Dec 10 2021 at 23:06):
@Vassil Peytchev that would be true for other resources, but I believe MedicationRequest, as a "request" resource, does have the meaning of being a request. It does not need a Task for instance. http://hl7.org/fhir/medicationrequest.html#scope
Vassil Peytchev (Dec 10 2021 at 23:19):
From that page:
the existence of a "Request" instance doesn't necessarily imply that fulfillment will be requested immediately - or even ever.
Form the documentation of the Request Pattern:
Requests are related to Task in that tasks can both request and track the fulfillment of a request. In some cases, fulfillment may also result in the creation of sub-tasks. Requests do not track their own fulfillment - i.e. requested/accepted/in-progress. This is managed through Task. The status of a request only reflects the status of the "authorization/intention", not how the request is being executed or not. It is possible for multiple tasks to be associated with the fulfillment of a single Request.
Rik Smithies (Dec 10 2021 at 23:49):
I read that and think it means you don't need a Task, and that MedicationRequest, suitably labelled in itself (though I am not sure exactly how), can do the request. But also it is possible for it just to be a record - a non-actionable copy of a script is also something that may be needed. I assume that is not what you are getting Vassil?
Rik Smithies (Dec 10 2021 at 23:53):
@Brian Diggle No two architects will agree about what is REST - REST is well known for that.
My feeling is that consumers will expect a FHIR interface to work the standard FHIR way, even if they only recognise that later when other APIs they come across along just happen to work the same way, with the same flavour of REST (however "pure" that flavour is judged to be).
FHIR doesn't, and never could, conform to everyone's idea of REST. And of course, there us room for variability in FHIR, but less so than with ad hoc APIs that bend the FHIR rules.
Given a choice of "pure REST" (whatever that is) or pure FHIR, I think most would go for the latter. FHIR is what gets the job done, not REST-ful principles.
The API that consumers understand and take to will be the one that dozens of suppliers and hundreds of interfaces support, with excellent documentation, tooling and training.
It would be nice if a UK prescription was as similar as possible to others worldwide, for both data and implementation reasons. That is what FHIR can give, but with well meaning but non-standard twists on top I worry that that could be lost before we start.
Vassil Peytchev (Dec 10 2021 at 23:59):
I believe the key points are:
- The status of a request only reflects the status of the "authorization/intention"
- Requests do not track their own fulfillment
In addition, I think it is very important to keep the resources, including those that follow the Request pattern, within the ownership of the systems that are responsible for them. In other words, the authorization (MedicationRequest in this case) belongs to the Prescriber, and the prescriber is responsible for its maintenance. Sharing the information about the authorization can take various forms, but the request to fulfil the Prescription needs to be a Task in order not to preclude the ability to track, including with proper justification, the status of the prescription.
Lloyd McKenzie (Dec 11 2021 at 05:48):
No request resource is implicitly actionable. You must use tag, task, operation or message to initiate fulfillment. Simply posting a Request to a server is never a safe way to initiate workflow - because there are use-cases where the same type of Request might also be posted as an FYI. (The workflow pages in FHIR provide a full description of the different mechanisms and their trade-offs).
Kevin Mayfield (Dec 11 2021 at 05:48):
Rik Smithies
This is not a UK prescription, it is for a national English API for use in several care settings. So really this should as similar as possible to both UK and English EPMA implementations (in my opinion)
The current role of this system is both a messaging passthrough which helps with delivery by providing a queue and managing prescription fulfilment (a polling event based system).
The new version swaps to central resource model, similar to IHE CMPD (https://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharmacy_Suppl_CMPD.pdf)
Kevin Mayfield (Dec 11 2021 at 06:15):
(deleted)
Kevin Mayfield (Dec 12 2021 at 06:13):
If these items are not required for processing, then they don't need to be structured. They could be carried in the text sections (I wouldn't recommend this though).
If they are, then to make it easier for suppliers this should be linked to proper the resource. If only a few elements are used, then contained should be used, Extensions can be discussed, this still has to link to the resource and UKCore &NHSDigital profiles, same element names etc. (Need to review how this is tested/validated, probably not easy but maybe converting back to resource can be automated)
Is some sort of balance to work out here as contained is not normally profiled, so it will be difficult to test. Extensions increase cognitive complexity considerably. The key bit here for me is if consumers are handling this data as a resource, it should be a resource (we don't put the hard work on consumers).
Kevin Mayfield (Dec 12 2021 at 06:23):
As a supplier. We've not looked at prescribing yet but the data we are referring to is already resource based and available via a RESTful resource (FHIR) API. We would prefer not to do the work to convert these to extension or NHS Digital uses our (standard) open API.
We expect local ICS to agree to this approach, as the HIE's already support it.
Brian Diggle (Dec 13 2021 at 11:16):
@Rik Smithies
Re: "Given a choice of "pure REST" (whatever that is) or pure FHIR, I think most would go for the latter. FHIR is what gets the job done, not REST-ful principles."
REST has become the de-facto standard for designing APIs globally. Why? Because its simple - define your nouns, then define which verbs act on nouns. I think most architects would agree with that. I would suggest that FHIR owes much of it's success to the simplicity of REST. So when I design my API in FHIR, I work to that principle - aim to preserve the simplicity of the REST approach.
Rik Smithies (Dec 13 2021 at 11:51):
hi Brian, my point is that the FHIR flavour of REST has become highly successful and has huge advantages. To deviate from it because people may prefer some other dialect of REST would be a mistake I believe. You lose a lot in practical terms. It is not REST alone that has revolutionised the healthcare data industry, it is FHIR REST.
Last updated: Apr 12 2022 at 19:14 UTC
