Stream: implementers
Topic: Is FHIR and HealthCareService a good fit?
Tommy Bjornsgard (Mar 18 2021 at 10:47):
At Norsk Helsenett SF, and we are responsible for the CMS platform hosting the websites for all Norwegian public hospitals. This is a SharePoint-platform, which have publically available information about the hospital (departments, locations etc.), detailed information of treatments provided by the individual departments and loosely coupled information such as news and events. All the hospitals are also responsible for their own clinical trials, which is also displayed on the helsenorge.no.
With all of this mentioned, our next task is to provide all of this information via a publicly available API, at first only health care related information (treatments coupled with who/where).
While investigating if FHIR might be a plausible path, we have had several sessions with Kenneth Myhra, discussing how FHIR might be utilized in our situation and with the data we wish to publish.
We have especially looked at the resources HealthCareService coupled with Organization. While we at first glance found it to be a plausible fit, we have some concerns.
A good example of a treatment can be found here:
https://translate.google.com/translate?sl=no&tl=en&u=https://stolav.no/behandlinger/gulsott-hos-nyfodte-lysbehandling%23transport-oya.
Keep in mind that no data is in context of an individual person (citizen). All data displayed is the same, regardless of the consumer of webpage/API.
All information shown on this webpage, will be available through the same method in the API.
Any thoughts on this?
Vassil Peytchev (Mar 18 2021 at 15:18):
At first glance, it looks like a good fit. How much of the content on the page is meant to be computable via the API, and how much can be just xhtml in the narrative?
Tommy Bjornsgard (Mar 23 2021 at 10:00):
Thank you for the reply Vassil!
All of the content on the page is meant to be available trough the API. In addition, a code (preferably SNOMED-CT) will also be added (not shown on the webpage).
A requirement is that the description of the treatment, with all content, can be recreated using the API.
A good suggestion, but you should able to differentiate between the "For", "Under", "After"-texts, which can be difficult when putting most of the HTML in the narrative?
Vassil Peytchev (Mar 23 2021 at 21:21):
It looks to me that it makes sense to add an extension (or maybe right away an element, e.g. extraDetailsReference) that is a reference to a Composition, where "For", "Under", and "After" are sections.
Entering a Jira ticket to represent your use case may be helpful
Lloyd McKenzie (Mar 23 2021 at 21:34):
Why Composition? This seems more like a protocol - and the resource for that would be PlanDefinition. @Bryn Rhodes ?
Vassil Peytchev (Mar 23 2021 at 21:41):
That is why I asked what needs to be computable, and from what I understand, the main concern is the structure and content of the narrative. If there is no underlying formal structure beyond that, PlanDefinition seemed like an overkill. Getting deeper into the requirements will probably uncover many more assumptions that will affect any particular solution.
Lloyd McKenzie (Mar 23 2021 at 22:40):
Composition is also overkill. You can have a PlanDefinition that's just text if that's what you want - no need for sections - you can just have narrative if that's what's needed.
Vassil Peytchev (Mar 23 2021 at 22:54):
Depends on what the importance of the sections is.
you should [be] able to differentiate between the "For", "Under", "After"-texts
Sections with potentially a code describing "For", "Under", "After" seem to fit this.
Regardless of the exact approach, it seems that HealthcareService needs something extra to satisfy the use case...
Bryn Rhodes (Mar 24 2021 at 02:41):
If I understand the use case (and as good as Google translate is, I'm sure I'm missing some nuance) then conceptually, this seems more like a definition (i.e. patient independent) than an event pattern (i.e. patient-specific). PlanDefinition seems like it would be a good fit in that case, and it essentially has the same hierarchical structure. Using PlanDefinition would also have the added benefit of being able to _apply_ it to a patient, though I don't know if this use case needs to support that.
Tommy Bjornsgard (Mar 24 2021 at 11:04):
None of the information we seek to publish through the API will be in context of a patient or a single person. However, the must be a connection between a treatment and a treatment provider (as in providedBy), i.e. a doctor, clinic, hospital etc. This is because a given treatment can be performed in different ways by different treatment providers.
I share @Vassil Peytchev 's concern that HealthCareService needs something more in order to be usable.
WIth regards to PlanDefiniton, how can that be applied or connected towards an organization or treatment provider?
Lloyd McKenzie (Mar 24 2021 at 13:03):
HealthcareService is typically used as just a declaration that "this site offers this service" - it doesn't get into the details of 'how' the service will be performed. However, establishing such a linkage is reasonable and would likely be done with an extension. The HealthcareService is already tied to a specific Organization, so if you have different variations, one option is to have one HealthcareService for each, each one tied to a PlanDefinition. If you want to have a single HealthcareService and indicate what specific providers offer it as well as how they do it, then you'd be looking at a repeating complex extension that links to both Practitioner and PlanDefinition.
Last updated: Apr 12 2022 at 19:14 UTC
