Double way integration with FHIR servers

Product
1

this is just an idea to be discussed, creating this post is only for record purpose.

Concept: integrate FHIR server to CHT instance to save the data but also to pull data for card and context.

FHIR resource to be used:

  • Patient : to keep a reference
  • Encounter or Task: form/report used (or main in case of embedded forms)
  • Observation: to save the data collected
  • Condition: to save the patient condition such as pregnancy, allergy but also simply classifications/diagnostic

process:

  • after submission of the report, somehow (name based ? tasks.js ? ) report data could be transformed into FHIR resource (Observation or Condition) saved locally

  • in contact-summary.templated.js new helpers could be created to pull data from FHIR database: directly from observation or condition

I think implementing further support of FHIR would be really difficult

How to keep the link CHT-FHIR:

upon sync the “FHIR data” could be sync with a real fhir server, Fhir identifier approach allow “double” identifier for a single resource: every resource may have several identifier that are composed by a namespace (aka system) and an ID, so the FHIR server migh have his and CHT another

3 Likes
2

Hello @delcroip,

Thank you for your post and for starting this discussion. Do you mind providing a bit more detail on what sort of workflows or use cases the integration between a FHIR server and the CHT would solve for you?

You can currently create a FHIR compliant resource using outbound push and push that directly to your FHIR server. In terms of pulling data from a FHIR database one way that we have explored in this repo is to use an OpenHIM mediator to do the querying and translate the result to something the CHT can understand.

1 Like
3

the idea would be the save those FHIR resource on the CHT database, and maybe to have those few FHIR endpoint on CHT server (nice to have)

It has 3 usecases:

  • syncing 2 CHT servers:

    • without going through the couchDB sync issue
    • sending only relevant data (smaller payload)

  • interoperability to FHIR servers (similar to what you linked)

  • ability have cleaned records accessible though the app:

    • each record come with an ‘issued’ date
    • possibility to use the js fhirpath libraries (conversion between units)
    • normalization of data (different question name might generate same code)
4

A bit of context:

Since 1.5 year, I am creating the FHIR resources the WHO EmCare project which aims to build the IMCI guidline using only FHIR, we do have a working application (done by Argusoft based on google android-fhir SDK)

BUT:

  • The entry barrier for FHIR workflow is huge, it takes months to have a good understanding of the required FHIR resources

  • FHIR workflow rely on 3 different languages CQL, Fhirpath (should be a subset of CQL but not really in reality), Mapping language; there is only an handful of person mastering all of those

  • Even if we try to develop a XLSForm like approach it remains much more complex that XLSForms

  • The formfiller application are not mature, FHIR features are often not implemented or there is important variation between implementation (cql for firely server might not work on HAPI server)

→ I think CHT don’t suffer from the same issues but could benefit of the “datastorage” part of few FHIR resource for the usecase mentionned above