Stream: implementers
Topic: Is my API use case something that should stay out of FHIR?
Jeffrey Rudesyle (Mar 03 2022 at 17:35):
My company reads EHR data from nursing homes and hospitals. We only read the data, never write back to the source. We then perform a large number of analytics on this data. We are offering both the EHR data we read and the analytics to our customers via an api.
Questions:
(1)I know FHIR has extensions and custom resources. However, it feels like offering these analytics inside a FHIR request would not be wise?
(2)Does it make sense to use FHIR if we only read the EHR data?
Thank you so much!
Daniel Venton (Mar 03 2022 at 18:02):
If you already have these interfaces written, then it's probably not worth writing a replacement using FHIR or any other standard.
However, if you don't have the interface written or you want to interact with a new EHR that doesn't have your api written then making use of their FHIR server will probably help your long term. As you want to provide your service to more EHR systems then it is more likely that they'll have an existing FHIR interface than your custom one.
Although there are extensions available, there is a good chance that your analysis can be presented via existing FHIR resources with very little or no custom extensions. Custom extensions mean custom interface, custom interface means development time, development time means $$$. Even if there isn't perhaps you have a use case for a new FHIR resource for inclusion in R5.
Lloyd McKenzie (Mar 03 2022 at 18:47):
A lot of analytics will end up surfacing as Observation instances, so it may turn out that you won't need many extensions or use Basic at all to represent your information.
Jeffrey Rudesyle (Mar 03 2022 at 20:35):
Daniel Venton said:
If you already have these interfaces written, then it's probably not worth writing a replacement using FHIR or any other standard.
However, if you don't have the interface written or you want to interact with a new EHR that doesn't have your api written then making use of their FHIR server will probably help your long term. As you want to provide your service to more EHR systems then it is more likely that they'll have an existing FHIR interface than your custom one.Although there are extensions available, there is a good chance that your analysis can be presented via existing FHIR resources with very little or no custom extensions. Custom extensions mean custom interface, custom interface means development time, development time means $$$. Even if there isn't perhaps you have a use case for a new FHIR resource for inclusion in R5.
Thanks for your response.
Our API is still in its infancy. It combines both EHR data and our custom analytics data.
However, it "feels" to me like displaying the EHR data in one FHIR API makes sense, and then a second API for our custom data?
Lloyd McKenzie (Mar 03 2022 at 21:53):
There isn't necessarily a requirement to do that. You could distinguish your analytics Observations from 'clinical' Observations in a number of ways: the Observation.codes, the .performer, the .category or using Observation.meta.tag. That doesn't mean you need to use a single endpoint. If a distinct endpoint is useful for access control or other reasons, that's totally fine.
Jeffrey Rudesyle (Mar 04 2022 at 00:42):
Lloyd McKenzie said:
There isn't necessarily a requirement to do that. You could distinguish your analytics Observations from 'clinical' Observations in a number of ways: the Observation.codes, the .performer, the .category or using Observation.meta.tag. That doesn't mean you need to use a single endpoint. If a distinct endpoint is useful for access control or other reasons, that's totally fine.
Thanks Lloyd. Does this make sense if these are large data sets of analytics?
Lloyd McKenzie (Mar 04 2022 at 00:48):
The volume of records doesn't much matter - unless there's a desire to have two completely separate databases for indexing & performance reasons and managing queries that cross databases would be too unpleasant.
Last updated: Apr 12 2022 at 19:14 UTC
