Implementations of openEHR applications operating in an offline capability

Implementation
1

I’ve been talking with @ian.mcnicoll recently who suggested I post in Discourse as well.

As part of some work I’m leading on in my current role, I’m on the look out for real world use examples of where openEHR underpinned mobile applications have been implemented, where they work in an offline capability.

Examples I was thinking of could be community nursing where there is a download of patients, they then record activities on the application (without connectivity ) and resync information when they get connectivity again, perhaps several days later.

Any examples gratefully received please.

Phil

6 Likes
2

This concept is also pretty important for resilience in the face of disruption, e.g. network failures, cyber incidents, etc.

1 Like
3

We might think about what a minimal CDR on a mobile device might look like

EHR : Create, Update, Delete
Composition: Create/ Update /Delete
- which formats?
- Canonical is more queryable, FLAT/STRUCTURED easier?? (both!)
- Versioning/ minimal contribution?
Templates: Upload, Read
Query: A minimal AQL processor??

I know people have talked about this in the past but not sure if there have been any attempts to implement it.

If there was no attempt to shred the Composition object, it might be fairly straightforward to store and retrieve these objects, the main challenge being the extent of granular querying that needed to be supported.

2 Likes
4

Thanks Ian really helpful

Agree a minimal CDR on the device is where we’re thinking but I’m also wondering what the licence implications are for that as it brings a different approach perhaps.

If we’re the first, that’ll be an interesting we’re up for. Will share how we get on

5

A micro CDR would be a very interesting challenge. And I also like the idea of a reliant net of decentralized EHRs.

But don’t you have a very constrained case only, e.g. your nursing example? Wouldn’t it suffice to just abstract the necessary data points away from the complexity of openEHR, temporary save them in the app’s own DB, and finally send them to the openEHR server/EHR with a SDK based client?
Adding a form solution based on dynamic openEHR templates could gentrify this approach.

It depends, but personally I would explore this path, before looking into the more complex ideas above.

1 Like
6

If one wants do go really deep and allow for distributed parallel offline work followed by merge (very much like Git for software versioning) then the things discussed in e.g. Exploring the Use of openEHR for Integrating Patient Health Records Across Multiple Systems - #8 by erik.sundvall could be of interest.

(I have been thinking of similar problems regarding disaster resilience but have not had time to go into depth.)

The design behind Applying representational state transfer (REST) architecture to archetype-based electronic health record systems | BMC Medical Informatics and Decision Making | Full Text (that has inspired part of the openEHR REST specs) also was intended to be easily represented in a file system hierarchy. Such a file hierarchy would make it easy to implement something that allows carrying along a number of EHRs - but one would need to cosider security implications of course.

7

Just leaving this here as a side note:

I imagine this to be how an openEHR architecutre will work in the future.

3 Likes