Separating Models from Implementation

In that particular case I think the (quite reasonable) question could then be formulated as - should we go for:

  1. either some tested closed EHR platform supported by a supplier (like Cerner) with some API interaction points (e.g. FHIR+proprietary) for predefined data sets
  2. or an open (vendor neutral) EHR platform with everything open - both APIs (full+simplified) and the full internal semantics/structures open. And in case #2 either…
  • 2a. do it ourselves or
  • 2b. do it together with a partner/group that provides and helps us use an openEHR based platform and clinical modelling

In case #1 your architects would have found the internal data models of the platform (in this case Cerner’s) to be even more complicated than openEHR’s - if they were allowed to look at them - but they likely never saw them, only big picture architecture and the things Cerner choose to expose via API - and that may look simple enough.

For case #2 to be comparable you could also choose to NOT have the architects look at the internal openEHR models, and instead only look at APIs for certain use cases, e.g. openEHR simplified formats for the particular templates/use-cases that solution #1 would also expose. In that case - to achieve the comparable situation as with buying Cerner - you should also go for #2b and pick an openEHR supplier (or supplier group) that gives you corresponding support, including creating templates and documenting simplified APIs for external parties that do not want to dive into openEHR internals.

Going for #2 without a partner with strong openEHR skills, international network and general EHR experience is like trying yourself to do all things Cerner have done to build their platform. (But with openEHR you’d at least get a good head start with a basic framework compared to starting from scratch.) It’s doable but it took Cerner some years to get there - and has taken openEHR platform suppliers some (but considerably fewer) years to do similar things…

The discussion of going for #1 or #2 is reasonable and still a living in reality (at least in Sweden)- A couple of years ago most big organisations (and consulting firms) would argue for #1, nowadays many argue for #2 after seeing the drawbacks of #1 and the possibilities and examples of #2. At least in region Stockholm (where I work) there are still people arguing for a mini-version of #1 after we stopped the procurement of a big (EPIC/Cerner-sized) procurement in #1-style. They think it will be way to complicated and take too long to go for #2. I personaly think #2 is certainly doable by having good partners/suppliers and simultaneously continue to train/recruit a strong team of our own. Two other Swedish Regions chose Cerner some years ago and are now working to implement/configure it to be able to run it in production.

Most other Swedish regions have Cambio Cosmic that used to be of type #1 but is now piece by piece moving over to #2(b) using openEHR. (The Cambio case has similarities with what DIPS in Norway has done and what TietoEVRY is doing.)

@ToStupidForOpenEHR Does this reasoning resonate with your experiences and thoughts? Would such a modified #1 vs #2a/#2b comparison be of use if you’d get into similar situations again?

5 Likes