Use openEHR for DIGA mobile applications

Implementation Apps
1

Medical mobile applications can now be remunerated if they are included in the DiGA directory.
The patient must be able to export the data, in a human-readable form and in a schema for the practitioner.
FHIR should represent the export schema.

Should the user data in the openEHR scheme be saved on the device?
Is a medical mobile application a use case for openEHR?

2

openEHR is mainly for platform / backend, which can support any app, but the scope is not about apps directly.

3

Hi Henning,

medical mobile applications are in the scope of openEHR. We recently built an app for cardiology at Hannover Medical School (The Hannover Medical School Independently Develops a Cardiology Anamnesis Application). However, I think it depends a bit on the given use-case and requirements. You can surely hold some openEHR based data directly on the patients’ devices but you might not want to have a whole backend inlcluding an RDBMS running locally on the phone or tablet. OpenEHR has the capability to build whole EMR systems comparable to Orbis, Cerner, Meierhofer etc. which induces some weight into the (backend) architecture.

This being said, you could use some backend service to handle the data correctly in a medico-legal sense (versioning, logging, security, access control etc.) and have a recent copy of the data in the app if needed. This could be a lightweight database or files containing data in the flat format:

  "bericht/symptome/körpertemperatur/temperatur|magnitude": 39.0,
  "bericht/symptome/körpertemperatur/temperatur|unit": "°C",
  "bericht/symptome/körpertemperatur/time": "2020-05-11T22:53:12.039139+02:00",
"bericht/symptome/gestörter_geruchssinn/spezifisches_symptom_anzeichen/bezeichnung_des_symptoms_oder_anzeichens.": "gestörter Geruchssinn",
  "bericht/symptome/gestörter_geruchssinn/spezifisches_symptom_anzeichen/vorhanden|code": "at0024",
  "bericht/symptome/gestörter_geruchssinn/spezifisches_symptom_anzeichen/vorhanden|value": "Nicht vorhanden",
  "bericht/symptome/gestörter_geruchssinn/spezifisches_symptom_anzeichen/vorhanden|terminology": "local",
  "bericht/symptome/gestörter_geruchssinn/time": "2020-05-11T22:53:12.039139+02:00",

or just cached java objects. This would allow you to have sort of an “offline-mode” in your app. Regarding export to FHIR, we follow a platform level approach in HiGHmed:

Bild1
Bild1910×363 12.5 KB

For the mapping part, we are using a component called FHIR-Bridge: GitHub - ehrbase/fhir-bridge: FHIR Bridge is an official component of EHRbase.. For the German realm, we are actively developing bi-directional mappings. While we currently concentrating on integration of COVID-19 relevant data, we will soon proceed with further German profiles.

1 Like
4

Hello Birger,

Thank you for your great answer. If I understand correctly, your mobile application is a higher risk class, right? The embedded image also helps a lot.
The platform’s worship of FHIR is undoubtedly necessary.
Is there an obligation to use “openEHR” in order to use the data structure on your ‘own’ frontend / backend? In order to classify it in the picture, should a separate structure be used instead of “openEHR”?

Many greetings and many thanks for your comments so far.
Henning

5

I’m not sure if I understand this part

Is there an obligation to use “openEHR” in order to use the data structure on your ‘own’ frontend / backend? In order to classify it in the picture, should a separate structure be used instead of “openEHR”?

Can you elaborate a bit further? I think I need a clearer picture of your requirements

6

Mobile medical is most definitely a use-case for openEHR. I am working with several clients right now to do exactly that , for both professional and patient-facing apps.

It would be good to a bit more information as Birger suggests but broadly speaking, the idea is that openEHR takes over the data management aspects of the app (data definitions, storage and increasingly business rules).

This can seem counter-intuitive at first since a lot of individual apps themselves have quite simple information requirements / rules or are operating as purely patient-facing apps, where provenance and trusted, medico-legallly safe data handling seems out-of-scope. The complexity of openEHR, which largely reflects the real complexity of health data, seems overkill.

However, at some point, if the data in the app is seen to be valuable to health professionals as well as patients, you start to hit hurdles. How does my app’s data definitions line up with everything else (usually not), how does it hook up with professional-grade authentication/authorisation services, and proper provenancing/versioning of data commits. How do we integrate with the need to use terminologies like SNOMED CT etc.

The premise of ‘open platform’ is that it makes much more sense to offload many of these burdens of data management, and the integrations that surround it.

You certainly do not need to use the openEHR data-structures natively in your app until the point of commit, but doing so does provide some advantages, as when you commit the data to the openEHR datastore backend, you do need to use the openEHR data definitions.

So quick answer frontend optional, backend mandatory, though there are various efforts ongoing to make it easier for third-party devs to bridge that gap, through simplifications.

1 Like
7

Thank you very much for your answer. In our case, the aim is to create a mobile application that receives approval according to DiGAV. One requirement is that personal medical data can be exported in a commonly used format.
According to my research, FHIR or openEHR are ideal for this. The question is whether we can meet the requirement of exporting to the electronic patient record and other mobile applications with both standards.

1 Like