Stream: uk
Topic: contained resources - is it FHIR?
Kevin Mayfield (Feb 18 2022 at 08:57):
Wondering what people think about the use of contained resources?
I'm working on a national programme (project A) and our solution is to use a Resource with no contained.
For another supplier I'm working on a very similar interaction (project B) and they have used the same resource but several complete FHIR resources via contained (the endpoint supplier is the same for both projects, just a different use case). From a FHIR purist point of view - I think this should be a FHIR Message (or a simple collection of resources in a Bundle).
However I see this a lot and I'm questioning if contained is something we should put up with?
Part of me thinks this is just taking the worst features of HL7v3 and continuing with them in FHIR. Project B could get rid of many of the resources, over 70% of them could just be turned into identifier references. (We have similar behaviour in STU3 FHIR Messages). Project B is not an easy spec to follow (and is described as a typical V3 project and suggests the same complex structured approach to development).
As a developer I prefer a list of resources (i.e. a Bundle) because it's easier for me to turn these into RESTful queries.
With contained I have to work out if the resource is a real resource or just a partial resource - e.g. for Patient is may just include DoB).
I would prefer contained just to be for partial resources - resources that don't necessarily validate 100%.
Richard Kavanagh (Feb 18 2022 at 09:34):
I think there are a few different points there..
-
Contained resources, they are part of FHIR and I don't necessarily see them as an issue. In the implementation space, it is often the case that the "purist" view of FHIR cannot easily be implemented. The use of contained resources is often desired when matching FHIR information models to internal data models. Not everything has unique id and even if it did the implications on the underlying architecture of exposing FHIR endpoints for minimal value has to be considered.
-
"something we should put up with?" - that's looks to be an internal issue within your organisation. Good governance and design rules should help to alleviate that. :stuck_out_tongue_wink:
-
The comparison between HL7v3 and FHIR is sometimes lost on people - relatively few people implemented HL7v3. The structure of the payloads and interactions between the resources is down to design patterns (see note above)
-
"As a developer" - no offence, but there are a lot of developers with different views - mileage will vary.
-
Despite the rumours, not everything is RESTful. The overheads of processing contained resources vs. bundled resources are not cut and dry - bundles come with their own challenges
-
"resources that don't necessarily validate 100%" - not sure whether you mean FHIR resource valid (they should be, always) or profile valid. If the latter, then that's for the system to handle. Profiles are only ever an assertion of compliance they are not guaranteed to be true. That said if this is central NHS, you would expect compliance to UK Core as a minimum.
On all of these issues, there will always be design decisions to be made. The best outcomes (IMHO) is when the "team" that makes these decisions includes representation from both the people creating the interface and also consuming the interface.
Rik Smithies (Feb 18 2022 at 09:35):
Long question, but some observations @Kevin Mayfield :
There is no "it should be a message". Message is a transport thing.
From a data representation point of view a message gets you nothing that you can't do with REST.
imho when people think like that it is just fear of REST ;-)
~I would prefer contained just to be for partial resources - resources that don't necessarily validate 100%
All resources must validate 100%, so this is not a rationale.
Rik Smithies (Feb 18 2022 at 09:37):
agree with that @Richard Kavanagh
Rik Smithies (Feb 18 2022 at 09:48):
Contained is for when you don't have enough information to make a full identifiable resource, and if you don't ever want that data to have a lifecycle independent of the thing it is contained in. In general unless you need to use contained (and that can happen), you should not be using contained.
Is the contained data actually considered to be part of the containing one, one complex entity, regardless of the representation?
If not - and you are just moving things around in the XML for some storage/transport/parsing reason - then that is not correct.
Kevin Mayfield (Feb 18 2022 at 09:53):
^ that's roughly what I meant by 100% valid.
Rik Smithies (Feb 18 2022 at 09:54):
Once you know what it is for then it becomes less of a choice or a source of variation, or a fudge. Contained is a necessary and useful consequence of mapping a "resource+references" oriented standard onto real data.
It isn't just an optional way to structure things. Rather than being a source of difference, contained actually promotes consistency. Data for a hospital always looks like an Organization resource, whether you have lots of data or just one string. The alternative to contained would be a bunch of extensions e.g. "hospitalName", to be used when you don't really know which hospital identifier it is and so cannot make a full resource.
Kevin Mayfield (Feb 18 2022 at 09:54):
""something we should put up with?" - that's looks to be an internal issue within your organisation. Good governance and design rules should help to alleviate that. "
This is not the organisation you are referring to, hence asking the question on UK forum.
Rik Smithies (Feb 18 2022 at 09:57):
so I suppose "resources that don't validate" == "data that isn't complete enough to be a validating resource" - which does make sense.
Kevin Mayfield (Feb 18 2022 at 10:00):
"As a developer" - no offence, but there are a lot of developers with different views - mileage will vary.
Yes, what are they???
As a supplier I don't want to be marshaling resources to and from different styles.
The supplier I'm working for is 100% REST (we used an off the shelf FHIR server). So assembling Bundles is trivial. Converting them to contained for transport isn't. Unpacking Bundles is also easy to handle, having to also process contained isn't.
Kevin Mayfield (Feb 18 2022 at 10:01):
We are not going to allow an external supplier to directly hit out FHIR server (except for queries)
Rik Smithies (Feb 18 2022 at 10:01):
@Richard Kavanagh I think all data can be REST, but indeed it doesn't have to be. And not all (existing) architectures can be REST. And REST is not always the best choice even when you do have a free choice. But in general, imho, it is, and you get some inherent benefits (it's a good model) and some more general ones (it's what people are familiar with, and will be even more so in future, for a while, and so it leverages experience).
Rik Smithies (Feb 18 2022 at 10:51):
and @Kevin Mayfield re implementation and developers - I think issues with contained are not what they may seem.
Assuming the data is going to be consumed and not left as FHIR (which would be trivial), then it may seem as if the dev options are:
A - "just do bundles"
vs
B - "just do bundles and also do contained" (sounds like more work!)
But in a real system it is more like:
A - "just do bundles and then map a lot of inline data in each resource"
vs
B - "just do bundles and then map a lot of inline data in each resource (some of which is incidentally in tags called 'contained')".
It is true that contained means two ways to resolve references rather than just one. But mapping multi-resource data to your own data model is not going to be handled in some generic one-size-fits-all way. It is going to need bespoke rules, with joins, splits/merges etc. So having some data in a node that happens to be called "contained" is not going to be a big deal I think (especially compared with bespoke extensions, which are the likely alterative - no easier to process and non-standard).
Kevin Mayfield (Feb 18 2022 at 12:42):
I'm not sure.
My default is to map solely to resource. Have done that with SQL based systems and HL7v2 conversions.
Assembling/Disassembling a collection (bundle) is trivial (as I'm resource based).
Turning those into a single resource (with contained) ..... doesn't seem right and I'd have to depack it into a Bundle before I can process the resources.
Kevin Mayfield (Feb 18 2022 at 12:51):
However I think the point I'm seeing is I favour a resource based approach and I think I may be arguing against an 'information' model approaches (which tends to come with documents/messages/contained interactions)
Richard Kavanagh (Feb 18 2022 at 13:31):
OK my final point. When considering the deployment within an existing interface, it is important to understand that FHIR is for most organisations an interface concern. The underlying database structures will not necessarily be aligned to FHIR. Couple that internal architecture esp microservices then the problem moves beyond an SQL concern.
Rik Smithies (Feb 18 2022 at 14:38):
@Kevin Mayfield
~Turning those into a single resource (with contained) ..... doesn't seem right and I'd have to depack it into a Bundle before I can process the resources.
I don't see why. A resource allows contained just like it allows extensions. We don't take those concepts and stash them elsewhere, because they are about that resource.
Contained data is considered to be extra data of the resource itself, that just happens (as a bonus) to be in a compatible format to if it was an external resource.
No need to move the data, and in fact, if contained is being used correctly that would probably not be possible. If they can be turned into other resources in the Bundle, that is where they should be in the first place. Contained is not a transport choice.
If you are thinking about how to undo contained, then it sounds like it is not the correct design.
Kevin Mayfield (Feb 18 2022 at 15:51):
I think you've just backed up my initial point?
So slightly confused :)
Kevin Mayfield (Feb 18 2022 at 15:55):
That isn't the pattern I'm seeing by a variety of NHS organisations (most to be honest)
Kevin Mayfield (Feb 18 2022 at 16:12):
Let me put this another way.
Many developers seem to have an opinion that FHIR is difficult.
As a developer (for a private supplier) I came across a spec which is difficult to understand, mostly because it's in a PDF and also because it uses contained.
So I would concur with developers that FHIR is not that easy.
Obviously swapping to my day job (this organisation is not involved), that's not a good thing. How do we stop this behavior?
Rik Smithies (Feb 18 2022 at 16:46):
FHIR is difficult. But everything else is more difficult.
I guess my main point is there is a definite use for contained, but it needs to be that use - and not just a wish to avoid some other construct that doesn't appeal.
~How do we stop this behaviour? I don't know. But education as to what the rules really are is a good start. If necessary tell people higher up that standard principles are being not followed. Then it's a choice.
Peter Jordan (Feb 18 2022 at 20:36):
Richard Kavanagh said:
The best outcomes (IMHO) is when the "team" that makes these decisions includes representation from both the people creating the interface and also consuming the interface.
A very wise comment indeed, @Richard Kavanagh !!
Kevin Mayfield (Feb 19 2022 at 06:54):
Don't disagree with that.
Where in the UK do we capture that feedback and feed into standards.
It's probably fair to say the API I'm looking at hasn't been reviewed by a developer (consuming the interface).
Rik Smithies (Feb 19 2022 at 09:54):
There is no single place. People who develop an API don't need to go anywhere to get it reviewed. Have you tried contacting them about this?This is a good forum to point people to, if they are looking for advice - but they may not know they need it. Or you can put them in contact with me as HL7 UK Technical Chair.
Kevin Mayfield (Feb 19 2022 at 13:22):
I have contacted them.
I don't know where feedback is going because it must be going somewhere. If I was say a pharmacy, I would be surprised if they accept doing FHIR REST single resource and multiple resources in contained, FHIR Document and FHIR Message.
This depends on whether they are sending to a GP, NHS BSA direct, NHS BSA via EPS or EPS.
Or am I barking up the wrong tree, people think this is ok?
Kevin Mayfield (Feb 23 2022 at 06:36):
Moving on from contained resources - found a better example.
If we consider Observations, many organisations and suppliers are using HL7v2 ORU_R01 and/or not using SNOMED.
The official view is this is FHIR and uses SNOMED concepts with UCUM units.
If we are going to get interoperability I'm wondering if the key bit here is getting standardisation on codes and units. It's not FHIR, the use of SNOMED and UCUM in FHIR is a consequence.
We would probably want to define the link between codes and units in FHIR (ObservationDefinition) or as properties in the ontology server.
Kevin Mayfield (Feb 23 2022 at 06:36):
What is the collective view?
Richard Kavanagh (Feb 23 2022 at 08:07):
So I agree on this one. The ability to use FHIR in a manner that people would expect is very much dependent on the underlying data.
The use of SNOMED outside of Primary Care is very patchy indeed, certainly a long way from being ubiquitous. The use of FHIR is not going to drive the uptake of SNOMED, the benefits of SNOMED itself or other national levers will be required to do that. The same would go for UCUM.
I suspect that for any system to transition from its existing terminology model towards SNOMED is going to be challenging as it clearly is far more than just "using a different code". This translates to a "terminology debt" that would require significant investment to address. The systems will have numerous other interfaces (apart from FHIR) and also reporting dependencies that will need to be considered. There are complexities (and benefits) from using SNOMED which many are putting in the "too difficult" bucket at the moment.
From my perspective, I see that the UK Terminology team are raising their game in the support and advice they are giving in this area which I am sure will have a positive impact. The establishment of the implementation community will also hopefully provide further benefits. I'm hoping that the industry as a whole can share thoughts on how to implement SNOMED as the benefits are shared across the whole system.
The OntologyServer helps in using SNOMED to some degree but it is but one tool in the toolbox that would be required to do this at scale within an enterprise.
Finally, the use of ObservationDefinition is conceptually beneficial but I suspect for many systems this is a step-change in capability. IMHO it's probably going to be useful in the future but not within the grasp of many (existing) systems today.
Rik Smithies (Feb 23 2022 at 09:02):
There is UK work on UCUM going on, covered in the Pathology & Diagnostics Information Standards Collaboration Space. But that and SNOMED are big issues and can't be wished into being deployed. It will probably need a combination of big programmes, that perhaps have little teeth, and small focussed ones that can move one area or one interface forward at a time.
Rik Smithies (Feb 23 2022 at 09:24):
Going back to contained briefly, obviously it is better for any organisation to have one FHIR mode (e.g. REST) and one resource structure (e.g. Bundles of resources, and not inappropriate uses of contained or unnecessary extensions).
But I suppose multiple systems may be needed and they could have different architectures. However, given that the move to FHIR already means change, and HTTP is ubiquitous, it doesn't seem unattainable to switch to a common REST interface style.
Kevin Mayfield (Feb 23 2022 at 10:19):
From a practical point of view. I believe I may be coming up with a 'how to send a document from A->B' requirement, I've talked about it at HL7 UK a few years ago but its coming back on the radar.
We don't want to use any of the methods that primary care has - too many of them and overly complicated.
Kevin Mayfield (Feb 23 2022 at 10:20):
I'll wait until we have a live requirement to send docs to an acute supplier
Richard Kavanagh (Feb 23 2022 at 10:25):
@Kevin Mayfield Would be interested to see what you come up with. I'd agree that some of the current patterns are overly complicated and make presumptions around the architecture in place (MESH, SDS, etc.)
A lightweight alternative could get traction.
Last updated: Apr 12 2022 at 19:14 UTC
