# Double way integration with FHIR servers **URL:** \ **Category:** Product\ **Tags:** interoperability\ **Created:** [March 23, 2023, 3:16pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595 "2023-03-23T15:16:04Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [March 23, 2023, 3:16pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/1 "2023-03-23T15:16:04Z")
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 ---
**Author:** ![njuguna](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/njuguna/32/829_2.png) [@njuguna](https://forum.communityhealthtoolkit.org/u/njuguna)\ **Post date:** [March 28, 2023, 7:29am UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/2 "2023-03-28T07:29:48Z")
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](https://docs.communityhealthtoolkit.org/apps/reference/app-settings/outbound/) 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](https://github.com/medic/interoperability) is to use an [OpenHIM](http://openhim.org/) mediator to do the querying and translate the result to something the CHT can understand. ---
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [March 30, 2023, 2:08pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/3 "2023-03-30T14:08:45Z")
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: - interoperability to FHIR servers (similar to what you linked) - ability have cleaned records accessible though the app: ---
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [March 31, 2023, 7:08am UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/4 "2023-03-31T07:08:02Z")
A bit of context: Since 1.5 year, I am creating the FHIR resources the [WHO EmCare project](https://github.com/WorldHealthOrganization/smart-emcare) which aims to build the IMCI guidline using only FHIR, we do have a working application ([done by Argusoft](https://argusgit.argusoft.com/who-public/emcare) based on google [android-fhir](https://github.com/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](https://github.com/SwissTPH/pyfhirsdc) 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 ---
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [November 27, 2023, 11:50am UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/5 "2023-11-27T11:50:07Z")
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 ```auto { "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 ---
**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\ **Post date:** [December 1, 2023, 2:57pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/6 "2023-12-01T14:57:17Z")
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](https://docs.communityhealthtoolkit.org/apps/reference/app-settings/transitions/). 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](https://github.com/medic/cht-core/tree/master/ddocs) 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. ---
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [April 24, 2024, 2:58pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/7 "2024-04-24T14:58:45Z")
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 ---
**Author:** ![jkuester](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/jkuester/32/806_2.png) [@jkuester](https://forum.communityhealthtoolkit.org/u/jkuester)\ **Post date:** [April 24, 2024, 7:33pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/8 "2024-04-24T19:33:13Z")
We do have the concept of [client-side transitions](https://github.com/medic/cht-core/blob/master/webapp/src/ts/services/transitions/transition.ts) 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](https://docs.communityhealthtoolkit.org/apps/concepts/interoperability/#cht-interoperability) to enable two-way data flow between the CHT and an OpenHIM server. ---
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [April 25, 2024, 7:51am UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/9 "2024-04-25T07:51:55Z")
Thank for the reply I don’t really get how [client-side transitions](https://github.com/medic/cht-core/blob/master/webapp/src/ts/services/transitions/transition.ts) 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 ---
**Author:** ![delcroip](https://communityhealthtoolkit.b-cdn.net/user_avatar/forum.communityhealthtoolkit.org/delcroip/32/1568_2.png) [@delcroip](https://forum.communityhealthtoolkit.org/u/delcroip)\ **Post date:** [March 10, 2026, 1:04pm UTC](https://forum.communityhealthtoolkit.org/t/double-way-integration-with-fhir-servers/2595/10 "2026-03-10T13:04:09Z")
Thanks for the link shared during today’s call : [feat(#9835): add cht datasource apis for creation and update of contacts and reports by sugat009 · Pull Request #10083 · medic/cht-core · GitHub](https://github.com/medic/cht-core/pull/10083) it means that such API will allow to create those summary reports from external systems