Seeing the frequent need for a FHIR API for healthcare settings - we decided to build one. The first step was the Implementation Guide which is still in a draft phase. We’re hoping to open this up to the community to get a sense of how well it aligns to the needs of the Senaite Community.
At the moment the IG describes:
-
Supported Workflows: Specific data exchanges between Provider and Consumer. See discussion below.
-
Project Management: The configuration and business decisions to adapt the FHIR API to a specific deployment.
-
Concept Mapping: The relationship between FHIR Resources and their underlying SENAITE Objects.
-
Artefacts: Examples, Profiles and Extensions.
Please note it is currently in early draft - so the IG is subject to updates without notification.
The FHIR Implementation Guide describes two initial workflows with the aim of extending into additional workflows in the future.
We have:
-
Request and Results: This is the most frequently used workflow for clinical settings. Orders are sent from the consumer to the FHIR API as a Service Requests Bundle. These will become SENAITE AnalysisRequests (A.K.A Samples) and related objects, available to be processed, verified and published. Once published, the results will become available as a FHIR Diagnostic Report.
-
Instrument Integration: Historically, instrument integrations has become the most fiddly aspect of clinical implementations. Each instrument often strays from the standard ASTM format in undocumented ways. We hope supporting a new standard will make life easier. Our design involves a SENAITE instrument mapping to a Device while each analysis is mapped to filler-order Service Requests. The results are then returned as FHIR Observations. We are currently designing additional support Worksheets as FHIR Tasks.
I am hoping this might trigger a “requirements” conversation so if you have time would be great to hear back.