Stream: implementers
Topic: REST API & Nested resourcess
natus (Jul 13 2017 at 16:11):
Hello
I have a client, consuming my FHIR web services. He retrieves (search functionality) multiple linked resources. Say Encounter and Observations.
Then I provide him a bundle containing both Encounters and Observations.
My client complains because he needs to join Observations to the Encounter on his client side himself. He would like to get labs nested into Encounters.
1) is there any way to nest resources together (put the resources in place of "reference")
2) Have you any thought about the FHIR API design, and is there any reason not to provide resources as nested ?
Thanks by advance
Lloyd McKenzie (Jul 13 2017 at 17:05):
The reason we don't provide them as nested is because there'll be situations where Observations are retrieved on their own and Encounters are retrieved on their own. Allowing nesting dramatically increases the complexity of the specification. It also causes issues when there isn't a strict hierarchy - e.g. Encounters that are tied to multiple patients, Observations that aren't tied to an Encounter at all, etc. We talked seriously about this in the early days of FHIR, but it quickly became clear that while it provided a minor benefit in certain simple cases, it added significant complexity or simply fell down in a lot of other cases. So I'm afraid the answer to your client has to be "that's just how FIHR works".
natus (Jul 13 2017 at 17:27):
Thank you very much for this clear answer.
What about using custom resources for this purpose ? For example, an encounter resource, with extensions of type "resource" such array of observation, array of patient.... I mean, is there really no workaround, and the answer to my client : "just optimize your client side, even if you have to fetch and process 10 years of medical records"
Side question would be "is FHIR designed to share such amount of data". It looks like it was more designed to fetch 1 patient medical record, but not thousand or millions
Lloyd McKenzie (Jul 13 2017 at 20:47):
Custom resources for content that's already supported by FHIR isn't really adhering to the spirit of the standard - and it's also not going to give you interoperability. There are ways to send a query that will return patients with all of their observations. Certainly JSON and XML aren't extremely suitable when you're looking at millions of rows. You might want to look at some of the recent discussions around Parquet and similar high-density syntaxes for data exchange. (None of those would involve nesting resources though.)
Last updated: Apr 12 2022 at 19:14 UTC
