Separating Models from Implementation

Edit: Moved this post here from the thread OpenAPI schemas generated from BMM files - #21 by thomas.beale

@thomas.beale “fixed” may have been a bad chioce of word let’s say “limited” domains instead - then the strategy to go for “several specialised app’s working across fairly limited domains” that @ToStupidForOpenEHR describes is the same I believe we are aming for at Karollinska University Hospital (and hopefully the entire publicly owned part of Region Stockholm’s healthcare in a while - likely pending further procurements).

However there is another part of the story that I believe @ToStupidForOpenEHR may have left out in his descriptions and might be the thing you are reacting against @thomas.beale. We’ll buy+build the apps/modules with the extra requirement that we use the same semantic core (archetypes, terminoloiges etc) in all (shared) data stored by the apps/modules. We’ll also usually require that apps be able to either use our shared openEHR CDR as storage backend or sync their internal data store to the shared CDR. Otherwise we’ll for example never be able to do data intense clinical research in a scalable way - the same reason I believe the university hospitals in HiGHmed has procured openEHR based CDRs and informatics work (right @birger.haarbrandt?).

There will of course be some modules (e.g. overviews) that use data from all subsystems. And we’ll likely have some modules that can be used in several domains, e.g. medication management (without limiting the possibility to include medication features in a specialized “limited” domain apps).

@martin.grundberg at Cambio (Karolinska’s current main openEHR CDR provider) expressed this in a good way in two pictures:


and

Getting back to the main theme of the thread: To the right in the bottom picture above, some of the blue “best of breed” apps may actually be ones that interact with the openEHR ecosystem mainly using simplified one-level models (like TDO, TDD or new JSON equivalents) derived from a specific set of templates. The system providers may gradually later see the benefits of integrating deeper into the openEHR ecosystem and make use of e.g. the more rapid data model adjustments to new needs and enjoy bonuses such as making/maintaining multilingual UX a lot easier.

2 Likes