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

5

Hello @jkuester

I would like to have a look into that, as a middle solution I like to add a “report_summary” document that will have only relevant data in it (Condition, Observation … ) this could be used in a structured manner to create FHIR resources.

Do you think it is difficult to add a document type ? and then to create instance within tasks.js ?

My idea will be to create a new document type “report_summary” with a simple structure (only code/type/value as “mandatory”) so the report could be removed shortly after being collected leaving only the data that matters : less storage, less sync, faster retrieval etc

{
   "when" : "captureDate",
   "report": "reportId"
   "contact": {"id": "contactID"},
   "data":[
        {
        "type":"Observation",
        "code": "rectal_temp",
        "value": "39",
        "unit":"Cel",
       "validity":{"to": "datetime"}
        }, ....

]
}

Thanks in advance

poke @magp18

6

I am not sure if I am 100% following what you are describing here, but as far as I understand, I don’t think tasks.js is going to be useful in doing background data transformation of report > report_summary when user input is not required. That would be more of a job for a Sentinel transition. I have not yet taken the months to have a good understanding of FHIR, but I could imagine a Sentinel transition that would automatically do the aggregation your are describing.

Regarding specific challenges with adding a report_summary doc type, I think the main trickiness would be around querying and replication. A lot of our existing Couch views depend on doc.type === 'data_record' and would not index docs with a different type. However, this might actually be desired behavior if you don’t actually want users to see/replicate report_summary records… You might need additional views for efficiently querying report_summary records.

7

thank you for your reply (I missed the notification so I am replying months later)

I mentioned the tasks.js because the mapping need to be done somewhere and offline too (as far as I know sentinel is on server side ) but any approach that can apply “a mapping done by the form author” should do it.

regarding the indexing it would be required because such report_summary will be used as patient data record instead of the report themself (less data to parse, standardized format)

but maybe we could just manage it as a report with a standard form name, something like __patient__report__summary__ with data list acting like a repeat group answer list

then we might use sentinel to generate FHIR resource from it.

br

8

We do have the concept of client-side transitions that get executed whenever a form is submitted. Of course, there is no support right now for configuring any kind of mapping like what you need…

And yes, a data_record doc with a special form value would probably be the most straightforward way to store/sync the data.

All this being said, I want to note that there has been a considerable amount of consideration here at Medic over the past 6-12 months given to the best way for the CHT to interoperate with FHIR. The approach we have chosen to take to production is to leverage mediators to enable two-way data flow between the CHT and an OpenHIM server.

9

Thank for the reply

I don’t really get how client-side transitions works but I will have a look

regarding the mediators: the issue with mediator that does everything (we have experience with commcare->DHIS2, we even build an openFn openHIM mediator) is that the configuration is complex and you need to updated it every time you add or remove a element that matters (uncoupled from form authoring, that could lead to discrepancies). In addition you will need one mediator per form or a very complex mediator that does not simplify the management

The approach I was proposing is compatible with a generic mediator that will look for this __patient__report__summary__; it could also generate this kind on form from FHIR resource so any form card/task will only have to look for data in the __patient__report__summary__ forms to retrieve patient data from past forms or FHIR

this is an example how we retrieve data from the reports:

once on the contact we can use it in the inputs of the forms

Br