Stream: implementers
Topic: Basic as an esoteric resource
Bill Harty (Feb 12 2021 at 16:27):
We have a use case where we need to provide a list of patients with typical attributes such as identifier, name, address, etc. However, the result set also needs to include a large number of "dynamic elements". The list of dynamic elements (about 100) will change/grow regularly, and these elements are not part of the FHIR spec, and likely never will be.
This is a BULK FHIR request. We're considering returning the Patient resource along with Basic, as an "esoteric resource", roughly following this example from the spec. Each Basic resource would consist of an "informal extension" for each of these dynamic elements
While this approach seems reasonable, I am a little hesitant. To my knowledge, Basic is rarely used and I don't love having a bunch of informal, undefined extensions in this sort of custom, key-value approach. This use case is not a narrow-constrained environment where a custom, non-compliant approach might be more palatable.
Would appreciate any thoughts, guidance, concerns, alternatives, etc. Thanks!
Lloyd McKenzie (Feb 12 2021 at 16:47):
Can you give some examples of the types of "dynamic elements" you're contemplating?
Bill Harty (Feb 15 2021 at 22:20):
Long story short, I believe we're going to abandon the idea of using esoteric Basic. Since my post last week, I have been able to get better information/clarity on the situation and had some discussions with EHR vendors.
More info if you're interested….
This is claims/EOB/coverage related data, and the data elements I'm referring to are things like risk flags, risk scores, enrollment flags, assignment types, etc. Some of them are generally applicable to the domain and could someday be part of FHIR. Others are very specific and narrow to this use case.
At this point I believe many of these elements can and should be defined as extensions and going forward we will explore that avenue. I think the original proposal to use esoteric Basic originated for a couple reasons:
1. There are a large number of these elements (potentially in the hundreds)
2. The data source provider frequently (roughly monthly/quarterly) adds new elements and sometimes drops/renames elements.
3. There are a lot of dependencies/criteria that determine the presence/absence of certain elements
So yes, keeping profiles/extensions up to date in this circumstance may be challenging but really the underlying difficulties of these 'dynamic elements' are more likely solved by changes to business process.
Thanks for your response, and I'm happy to provide additional info if you're still interested.
Michele Mottini (Feb 15 2021 at 23:14):
Note that there is a RiskAssesment resource that is suited for risk flags / risk scores. Things like enrollment flags can be Observation (I think most real-world system render a mixed bag of different things as Observation)
Lloyd McKenzie (Feb 15 2021 at 23:26):
Risk flags and Risk scores would typically be Observations (they reflect point-in-time assertions). Enrollment (if talking about coverage) has a specific resource. Enrollment in other programs is an unmet need.
Bill Harty (Feb 16 2021 at 15:44):
Thank you very much! I came from the clinical side of the world (financial domain is somewhat new to me), and admittedly always thought of Observations from a purely clinical perspective, but I'm really glad you steered me in that direction (will look at Coverage, RA also). Very promising. I will also ping Carin and DaVinci streams as well. Thanks again. Much appreciated.
Lloyd McKenzie (Feb 16 2021 at 16:23):
Most welcome - and welcome to the community :)
Last updated: Apr 12 2022 at 19:14 UTC
