Overview

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)

Context

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.

FHIR

http://fhir.openimis.org

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
  coverage).

• 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).

Risks

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
API.

Mitigation

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

Minutes

• 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