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.