How to support multiple verion releases in a year

Implementation
1

Hi all,

I have some concerns about ability to build UX iteratively and quickly enough on OpenEHR.

If great UX comes from effective, frequent iteration, how does/can OpenEHR support this e.g. a software product benefitting from multiple releases in a year based on user feedback built into the product?

This is normally the sign of a great software IMHO and achieved by the good, modern proprietary SaaS out there but in healthcare the likes of the big EPRs are woeful at it, preferring rigid long term, large value contracts where no user agency exists (unable to vote with their feet, so no commercial impetuous/pressure exists to iterate the product fast through listening/building great UX).

As such, fast iteration feels like an area that if it can somehow be improved/enabled, could help OpenEHR to another level of delivering the satisfaction and efficacy needed in healthcare.

Olly

2

We use Semver-based versioning, which is supported in tooling like CKM and Archetype Designer

Here is an example for the Archetype Designer ‘IUpdates’ view - you have to turn it on in Settings.

It shows the diff between the local reo on the left and the CKM versions on the right.

So this is working and helpful but we are also investigating more formal package mgt ideas )NPM) etc to help manage this more easily.

But yes, frequent updates with a good handle on impact of up-versioning, is critical.

image
image1518×517 81.4 KB

3

In fact re-reading your question, openEHR’s ability to rapidly iterate improved/ extended data models is a great fit for agile UX development, and why so many low-code UX environments are now appearing around it.

Why do you think openEHR would be to slow to adapt?

1 Like