I’m re-structuring the FHIR Sessions email.
Starting today, I’ll be writing about my own experiences with FHIR. I’ll touch on the different things I’ve learned or worked on in the FHIR space over the previous weeks, and I’ll highlight interesting and useful posts from other people.
Expect an email every 1-2 weeks.
Using Contained Resources
I browse the FHIR chat forums every week or so and it always leads to something timely, interesting or new.
Last week I was working on how best to store a requesting physician’s details in FHIR for a procedure. The difficulty I was faced with was that the details might be incomplete — little more than a name — and not warrant a complete Practitioner resource.
A topic titled “Guidelines for using contained resources” caught my eye on the chat forum and presented a couple of different ways of handling the problem. Contained resources or populating the “display” attribute of a reference element.
You can read the discussion here.
I’m not an active participant on the forums, but I encourage others to weigh in on any topics they have expertise in and to ask whatever questions they might have. The pool of FHIR expertise on the forums spans many healthcare domains.
Tagging Data as AI Generated
My RSS reader reminds me every time John Moehrke publishes something new on his blog. John is one of those experts who offer advice on the chat forums I mentioned above and never disappoints.
Saturday’s topic was on “Healthcare AI – Provenance of AI outputs.” John wrote about how to tag AI generated data in FHIR using security labels at the resource level and Provenance resources.
I wasn’t familiar with the AIAST code he documented (Artificial Intelligence asserted), but it fits perfectly with a use case I’ve been working on for a few weeks.
If you’re not already following John’s blog, I recommend you do so. He’s particularly active in areas of Security and Consent, and you’ll find his posts detailed enough to take practical action on.
Logical Models in FHIR
An email came in last week from Health Samurai that mentioned Logical Models in FHIR — something I admit to being unfamiliar with at the time.
A little research led me to a blog post written by David Hay back in 2016, where he described the purpose of logical models as being “… to gather requirements from clinicians and other folk that can subsequently feed into the design process for profiles and Implementation Guides.”
A building block for Profiles, which most of us are familiar with to one degree or another. I’m not sure I’ll ever have a use for them in the FHIR context, but it’s good to have a basic understanding so I can hold a conversation about them.
You can read David’s post here.
20 FHIR resource types
I posted a survey on my website two weeks ago that threw up some surprises. One of the questions I asked was how many different FHIR resource types the respondent typically worked with.
78% of those who answered said 6-20.
Considering there are 145 FHIR resource types in R4, this was a very low number. To my mind it goes to show how focused so many FHIR projects are. While most projects work with the Patient and Observation resource types, there is probably little to no crossover between projects in the Financial, Medicinal and Procedure spaces.
The lesson here if you’re learning FHIR is don’t spend too much time learning about resource types. Learn about the common data types that are used across all resource types: Reference, CodeableConcept, Identifier, etc.
I’ll be writing more about the survey results later, but if you’re interested in the questions I asked you can read them here.
FHIR is Not a Database
Opinion posts can be hit or miss depending on how your opinion resonates with the community. I think I struck a chord a week ago when I suggested we should be actively discouraging any reference to FHIR as a database.
The prompt for this particular post was a business demo I attended the day before where the phrase popped up from developers on two different teams.
The problem with referring to FHIR as a database is that it creates false expectations amongst developers and business stakeholders who are new to FHIR. My own experience is that it can lead to surprises down the road when the true nature of FHIR APIs is better understood.
PATCH Requests in FHIR
A few weeks ago I was working on some demo scripts in Postman. A particular requirement led me to dig deeper into the more complicated parts of PATCH requests using FHIRPath expressions and the Parameter resource type. I was trying to update elements deep inside a FHIR resource without first loading that resource.
I got my script working after a lot of trial and error and I learned a lot about the PATCH request along the way.
I don’t see much practical use for the PATCH request outside the scenario I was faced with, as I feel most modern FHIR SDKs remove the need for them, but it was interesting to have a real-world use case for learning more about it.
---