2023-06-15 Developers Deep Dive Call



Date: 15.06.2023

Objective: Weekly space for deep dive topics

Participants: (kindly only add your own names, not those of other participants)

  • @Eric Darchis

  • @Thibault Dethier

  • @Christophe Philemotte

  • @Uwe Wahser


Topic Proposals:

  • Mobile REST API to FHIR


Move from C# REST API for mobile apps (Claim, Policies)


Reasons to move from C# REST API

  • The mobile apps (Claim and Policies) relies on the C# REST API

  • C# REST API relies on Msft SQL Server and stored procedure.

  • It can't work with PostgreSQL.

  • On PostgreSQL, none stored procedures are used.

  • It requires then to maintain 2 approaches. As consequence, I understand that
    it could slow down development and makes the updates brittle.

  • Moreover, it requires to maintain the C# REST API application, that means one
    more language and framework to develop with, and one more process to operate.

Replacement of the C# REST API

  • The Python backend offers 2 APIs: a GraphQL and a REST API that is an
    implementation of FHIR.

  • For several reasons (link to decision/doc), the FHIR REST API has been chosen
    to replace the C# REST API in the mobile apps

Mobile apps requirements

  • The C# REST API offers its resources packaged and prepared for their usage
    in the mobile apps. For instance, the services and items are retrieved all
    together or the enquire contains all the information that the claim mobile app
    needs. Each endpoint covers one mobile app use case.

  • Mobile apps have to work in poor network condition. As such, they work with
    a local database that they synchronize with the remote through the C# REST API.



Based on the available documents, experiments done with demo data, and code read,
we think that the current implementation present several limitations. They might
be incorrect as we don't have analyze 100% of the code. They are:

  • Search capabilities (.e.g. _include) are partially or not implemented.

  • Filtering are partially or not implemented (e.g. filter in for a given field
    value such as claim_administrator for claims).

  • Medication package conversion is buggy (PR submitted) .

  • Claim listing is buggy (to confirm and investigate further).

  • Some parameters are unclear (e.g. refDate for claim).

  • Some parameters seem to be buggy (e.g. coverage period seem to be one month
    later than enquire expiry and effective dates obtained with the C# REST API)

  • Each FHIR resource follows the standard and as such does not match.
    directly the mobile apps need. That means that sometimes, several calls are
    required to get all the expected data (e.g. the health facility code when
    listing the claim administrators, the patient details when retrieving a

  • At least one resource, Controls, is completely absent as it does not
    necessary fit the standard.

  • Some data could not be found with the FHIR API (e.g. all the amount left
    listed in the enquire response).


Considering the time put in the preparation, there are still several pending
questions about how to replace completely the C# REST API with the FHIR one.
When some limitations are known, there are still two important uncertainties:

  1. when some limitations are known (e.g. missing field, filtering), the
    complexity of their implementation or adequateness to the standard are still
    unknown. That could result in unexpected efforts or dead-ends.

  2. considering the found limitations and pending questions about some of them
    (e.g. buggy or exact meaning), there might be others to come that we do not
    know yet. That could result in unexpected delay.

Those 2 uncertainties result in in risk to delay the migration from the C# REST


If we go back to the initial context, it seems we are trying to achieve two
goals at the same time:

  1. remove the C# REST API,

  2. use the FHIR REST API.

Delaying the first one, will cause more maintenance due to the need to support
2 different implementations at the same time (Django vs stored procedure). As
such, one intermediary step would be to remove the C# REST API by using the
most certain approach, i.e. an API that we know well. Today, according our first
preparation, FHIR REST API is not yet that one, GraphQL is.

As such, we'd like to mitigate the delays with the following approach:

  1. remove the C# REST API by using the GraphQL,

  2. in parallel, continue the analysis of the FHIR REST API, and start the
    necessary work to make it ready for use by the mobile apps,

  3. and replace the GraphQL in mobile apps by FHIR.

In any cases, we try to change as less as possible the mobile apps by only
isolating the requests to the C# REST API and replace only those. That means,
we'd have already in place the isolation to ease the third step.

Presentations / Attachments

  File Modified

File new_product.odp

Jun 15, 2023 by Eric Darchis

PNG File image-20230615-081049.png

Jun 15, 2023 by Eric Darchis

PDF File diff_between_CS_REST_API_and_FHIR_API.pdf analysis of the difference between C# REST API and FHIR API in the case of the claim mobile app

Jun 15, 2023 by Christophe Philemotte



  • what is a practical way to remove MS SQL dependencies until August?

    • look at contract extension (costed/no-cost)

  • can the FHIR deficiencies be prioritized and costed?

    • BlueSquare will do that

  • can there be a mix of FHIR and GraphQL?

    • use the FHIR ressources that work already

    • fix the ones which are easy to fix

    • use GraphQL for the difficult ones

  • what’s important is to make sure that the business processes stay the same (the bug is less critical)

  • useful to improve FHIR through that integration

  • important to move from C# REST API (remove the stored procedures!)

  • binary endpoint (not yet implemented) could be useful

  • remove CHF-ID


Next Deep Dive:

  • FHIR Integration Roadmap

    • mobile apps integration through FHIR

    • country specific openIMIS FHIR R4 profile

    • openIMIS FHIR R4b update?

    • openIMIS FHIR R5 module

Additional Resources


Did you encounter a problem or do you have a suggestion?

Please contact our Service Desk

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. https://creativecommons.org/licenses/by-sa/4.0/