Separating Models from Implementation

I’m curious for that list.

1 Like

Each CKM archetype and Element has a Reference model tab with a short list of ‘clinical’ RM attributes - a bit arbitrary but probably close enough.

@sebastian.garde - are you able to share the underlying XML file?

1 Like

There are even markers in the RM BMM to indicate which RM attributes are interesting and which really are not - ADL Workbench filters using these and can generate any variant of RM flattening onto a template or archetype. It’s easy to put more classifiers like that in BMMs generally.

Example here.

2 Likes

They are all template-specific “streamlined” things, I belive TD… = Template Data…

  • TDS …Schema (XML schema)
  • TDD …Document (xml instances adhering to a TDS)
  • TDO …Object(s) (Class definitions, used for simplifying programming applications & integrations)

The template specific “streamlined” OpenAPI descriptions discussed in this thread could be used to produce the equivalent of TDO in any programming language (I believe TDO from the back then was usually in some .NET format)

@heath.frankel is likely the main guru on the topic and was involved in creating TDS/TDD/TDO formats many years ago at Ocean Informatics (now called https://oceanhealthsystems.com/). I believe many of the reasons for their creation were basically the same as the ones @ToStupidForOpenEHR brought up and that started this thread - to make it easier for developers and others to, for a specific use case, integrate/interact with openEHR systems - using familiar tools and without a learing too much about openEHR or openEHR specific tools.

When searching for TDS in the old openEHR mailing list archives you’ll find a lot of the same thoughts as in the current discussion, e.g. in 2008 and 2013. I believe the main problem regarding adoption was that the TDS/TDD approach was never published as an official specification back then - it was used by Ocean and some of their customers (including Better/Marand for example).

In 2016-2017 things had changed and there was a willingness from Ocean to share/publish the approach and create a specification, work was started, see the wiki page https://openehr.atlassian.net/wiki/spaces/spec/pages/30408770/Template+Data+Schema+TDS+Specification+and+associated+Template+Data+Document+TDD but never finished because of peoples’ busy schedules. Heath (who was very busy then) sent me some files that I (also busy) never got around to analyze and publish on that wiki page as a basis for further standardisation work. Perhaps it is time to pick that up again and let anybody interested help documenting the approach? @heath.frankel could you attach any files/descriptions for curious people to look at - on that wikipage or in this thread?

Others may have more information and links about TDS/TDD/TDO, please share. @Seref may know of current use at Ocean.

4 Likes

Thanks @erik.sundvall

TDS/TDD does look fairly close to what I am suggesting.

2 Likes

In order to not kidnap the thread about @NeoEHR’s cool generators I’ll clarify some thoughts here instead, where I believe the core of this discussion fits better.

@NeoEHR and @thomas.beale I am not sure I explained my point well enough in OpenAPI schemas generated from BMM files - #9 by erik.sundvall when refering to @heath.frankel’s comment from 2012 on the wiki page https://openehr.atlassian.net/wiki/spaces/spec/pages/4915205/Ocean+EhrGate+-+Composition+Builder+programming+example

Yes developers/integrators need to learn a little bit about openEHR basics (but not much) if they e.g. have a template-specific use-case that is one of their first tasks to interact with an openEHR system.

However it would be great if they did NOT have to switch tooling or start using openEHR-specific path-based ways of interacting with components like the one suggested in the 2012 wiki page or the more elegant/compact toJson() method described by @NeoEHR in OpenAPI schemas generated from BMM files - #10 by NeoEHR

By tools/methods they are already used to, I mean…

  1. for integrators/informaticians creating and maintaining integrations: low code tools like Altova MapForce or Mirth as described in Graphical data mapping tools supporting openEHR? (these tools work best if supplied with a template specific schema with user friendly node names derived from the template labels - TDS is one such approach, a similar way to do JSON schema for the “structured” (JSON tree) simplified format described as structSDT in the end of section 3.2 of a spec would also be a great option for such tools
  2. for software developers: a template-specific litte library of classes with names derived from the template labels. TDO is/was such an approach, template specific openAPI definitions would do the same job in a more modern and programming language-neutral approach. Then they can just generate and import the library/classes and keep using their favourite editor/IDE and get syntax higlighting, auto completion, validation etc based on the template (Instead of string based path/key approaches where errors often are only found at runtime).

So it’s not that we would try to “hide” everything in openEHR, it’s about making the integrator and developer experience more efficient and less error prone.

Edit: @Seref pointed out in a recent SEC-meeting that the simplifications in TDOs etc stopped somewhere around the openEHR data-type lower levels, and there reused a generic part for different use-cases/templates. Perhaps @seref or somebody else that is used to working with this could explain further in a few sentences?

5 Likes

You also have to consider the case that HealthCare providers that I work with e.g. NHS Scotland, NSS, Boards, Trusts across England, NHSx, NHS Wales, eHealth Ireland do not have particularly big or strong development teams, and almost universally work with .NET. So trying to uplift OpenEHR in a primarily JVM based world is a real challenge.

It’s also very rare for a developer to be allowed to spend time learning a technology without this being part of the strategic roadmap for the provider.

This goes right back to my initial point, I want OpenEHR and in particular the models to be widely adopted, but HealthCare providers (boards, trusts etc) are put off by the complexity of OpenEHR, so are not including OpenEHR in their strategic roadmap.

I’ve taken a fair amount of abuse trying to get this point across. It’s nothing about me learning OpenEHR that would not change a thing. It’s about getting someone like NHSx to adopt it strategically across NHS England.

Myself and colleagues are pushing OpenEHR on the policy front not only in the UK, but across EMEA and in Australia and NZ.

We are trying our best to get OpenEHR adopted.

Joost and I had a chat, and we think that OpenAPI is a good way to go.

If you want to help then please let us know.

Gary

5 Likes

I’ll respond carefully and in case I fail to reflect the history/motivation accurately, @heath.frankel is welcome to correct me.

Both the TDS/TDD and TDO approaches were Heath’s babies. He’s the one who came up with the idea, and the aims were at some level overlapping with what’s being discussed here: make it easy for non-openEHR systems/actors to talk to openEHR, make it easy to work with templates for a developer.

In case of TDS/TDD, Ocean’s template designer produces an XSD from a template, called TDS, and if you can produce an XML file (called TDD) that is valid according to that XSD (schema). This approach dealt with the interoperability requirements of the time neatly. Back then, XML was the dominant ITS for exchange, and an XSD and an XML file did not take much explaining. Sure, XSD could not express all the constraints expressed by a template, but it was a good balance between stopping openEHR leaking to non-openEHR world and validation at source. When TDD(XML) arrives at Ocean land, it is transformed to a canonical Composition XML, then deserialised to RM and validated. Ocean template designer is still freely available after all these years, so you can play with it. The transformation to canonical XML is done via XSLT but I’m not sure if we made that available publicly.

The slight problem with TDSs is, they’re fully self contained. As in, each XSD creates its own little type universe, and with xml namespacing etc, two DV_TEXTs in two XML files end up having different XML types from two different schemas. Not a real problem because a TDS is meant to be a messaging artefact, but in the context of conversation going on here, it is something to keep in mind. Actually, the openEHR SDK from EhrBase had the same behaviour (or I think it did): it generates a set of Java artefacts from models and same RM types end up with duplicate, yet technically different representations in generated code, because they’re based on different opts. Again, corrections are welcome.

A TDO is actual C# source code, generated from templates, and it allows a developer to populate data using the names/concepts as they’re used in the template. This makes a big difference in terms of productivity, but Heath was concerned about various software engineering aspects of using TDOs so he was not entirely enthusiastic about using them, and I disagreed :slight_smile: If my memory is correct, when they started using openEHR based on the Ocean platform, Marand (Better now) even produced Java TDOs and used them for a while. Happy to be corrected on this if my memory is wrong.

The tricky bit with TDOs was that they required code to go from the TDO type to a canonical RM composition, which is what’s done with XSLT in TDS scenario, and that functionality was not convenient for us to distribute as a library, though at some point around 2014 or so I remember doing it for a partner in an Australian project.

As of today, we have TDOs in our production code, I’m pretty sure of that, and one or more of our integration endpoints may be using TDSs; this I’d need to ask Chunlan Ma, who’s the queen of openEHR implementation :slight_smile:

So as you can see, the idea of isolating (which I prefer to separating as a term) openEHR from the non-specialised developers is something we’ve been experimenting with and doing in different ways for some time.

I personally think it is a very good idea, and the eco-system of today provides a lot more options than the time Ocean did TDS/TDD: that’s the thing with arriving too early, there’s nothing around for you to leverage…

This thread has enough disagreements without me pouring gasoline over it, so I’ll keep my specific opinions to myself, but as someone who does this for a living, I see a worrying gap between off the shelf developers and their practices and what we’re doing. Yes, we’re taking steps, but there’s a long way to go and I see lots of good ideas being exchanged, so hopefully we’ll do better come this time next year.

8 Likes

Right - but one has to ask - do they even realise the problem they need to solve is fundamentally complex? If they don’t, then there’s nothing to say, they will fail, guaranteed. But if they do, really, they need to hire proper engineers and developers to do some core work, e.g. deploy the platform, learn the platform API, and how to do a few things with templates. If they don’t want to even do this, and the current employees simply want an easy ride with everything so ‘simple’ they don’t have to do any work, well then I am afraid there is no path to success. They will continue to fail as they have been for decades, apart from a couple of centres of excellence like Marsden (Jo Milan).

I hate to re-iterate the question of complexity, but it will not go away by complaining about it. If NHS trusts cannot realise what kind of problem they are solving, they have no route to success. None.

Now, there is no doubt that we have not quite arrived at the optimal point of application development today - the things that @erik.sundvall and others are talking about (and web templates, created by Better, TDS etc by Ocean in the past) are needed, in an updated form. (As you can see, there is furious activity in this area).

BUT. If the NHS wants to be serious, it needs to invest in this phase of technology development. Unlike the millions they waste on closed source EMR systems that don’t work, every penny they spend on openEHR is public IP and costs nothing once developed (other than the cost of maintenance obviously). The central question is: are they serious?

It’s not a technology question. It’s an organisational question.

2 Likes

This community will definitely help. But orgs like the NHS can’t sit around and expect the equivalent of £50m of technology to appear like magic (or what the likes of IBM would charge £500m for), with no investment from their side. They waste that amount every week on some useless procurement that just creates technical debt for a decade to come.

Many people including @tonyshannon , @ian.mcnicoll , @ewan Davis, and @DavidIngram have tried everything to get the NHS to think strategically about this, and to provide just a small mount of investment. The NHS instead funds technical debt creation projects. So that’s where we are.

If you can make the NHS understand something they hitherto refuse to, I will send a case of fine wine.

2 Likes

I think there is the opportunity to help change the opinion of the NHS. Most people I speak to are fed up of vendor lock-in, and looking for alternatives.

I think the multi-level modelling is the right approach for developing Archetypes and Templates and where most of the complexities are found.

But I think you should offer the option of generating a single level, self contained, easy to parse model from this multi-level model. That would IMO greatly increase the uptake. (gives people two options, DDD or AOM etc)

4 Likes

Thanks for a wonderfully informative post @seref.

@thomas.beale I’m not sure you understand how decisions are made in many healthcare regions (probably in NHS trusts too) and also how hard it can be to hire and keep great health-IT staff including good engineers, architects etc. Bashing regions/trusts for not wanting to staff up and handle complexity themselves likely won’t help them nor will it help the cause of openEHR.

Such decision makers and their advisors, architects etc. want to feel safe and they also know that their own tech organisation is already busy trying to keep all current systems afloat and updated. That is a main reason for them to turn to well known systems and suppliers that other peer organisations have used, rather than trying something too different and demanding.

I believe some things that will increase the opeEHR adoption in such regions/trusts are rather:

  1. true success stories of openEHR adoption in similar/peer organisations
  2. Companies, or groups of collaborating companies with openEHR based solutions, that (credibly) offer to help handle complexity and change rate of healthcare-IT in a similar or better ways than current non-openEHR suppliers do.
  3. Efficient ways for already busy average developers in the region/trust to integrate existing data and systems with the openEHR platform (the main theme of this thread)

Thankfully enough, a lot more such openEHR-based examples (#1) and commercial offerings (#2) are now available than a couple of years ago. Let’s continue the discussion regarding solving #3.

I believe @ToStupidForOpenEHR, I and others are suggesting the option to offer single level facades fronting multi level openEHR backends, not the removal of multi level modeling.

2 Likes

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

The concept is based on shared information management and governance between independent hospitals and thereby being able to use a common information architecture to a) establish standards for primary documentation and data quality to avoid expensive ETL processes in the future b) allow to develop and share innovative applications and algorithms between participating sites, c) avoid new shadow IT/feral systems to make all data potentially available for secondary use and d) enable cross-enterprise usage of data for analytics and machine learning.

3 Likes

Thank you for drawing together and focussing the discussion in this way, Erik. It could not be more important. I very much hope and trust that our growing cadre of organisational partners, like yours, will be able to join forces and align around an expressed integrating vision of this kind, in support of the everyday communities of clinical practice that they serve, which so much need it. We first promoted the importance of thinking about the ensemble (that’s physicist-speak - now we have biologist- speak ecosystem!) of archetypes and archetype systems over ten years ago, but only now have the necessary combination of clinical, technical and organisational preconditions started to become a reality and gain traction. That is in large part a tribute to the whole of the wonderful openEHR community. Well done all!

3 Likes

I completely agree, that is my experience. The CIO in eHealth Ireland took one look at OpenEHR, the resources he would need to find, and immediately called Cerner.

2 Likes

Correct. I am now of the opinion after talking to some of our prominent modellers that the multi-level approach is correct for designing models.

2 Likes

Here’s another angle that complements yours. Assume you have lots of money, either as a gov org or as a tech company and you want to hire great staff. What’ll you do when engineers do not want to work with openEHR because it is such a big divergence from the safe career path?

This is happening to us at all levels of hiring. Technical staff keep an eye on where they’re going from a tech-stack perspective, and they want to make sure what they’ll be working on will improve their prospects in the industry a few years down the line. So in the interviews they ask us if they’ll be working with Spring Boot, Asp.net core, microservices, DDD, GraphQl, REST, OpenAPI etc. Don’t even get me started on explaining what we do to recruiters, without whom you can’t deal with the signal/noise ratio of the candidate pool.

If you fail to isolate the engineering complexity and very specialised tech aspects of openEHR to a degree, you can’t grow the technical capability you need, even if you have the money. This is why I keep repeating “off the shelf tech, off the shelf developers” for years: narrow and extreme specialisation becomes a sustainability problem, not only for the customers, but even for the vendors

I’ve been working on one healthcare platform company or another for 20 years now, and based on that I’d say you’ll always have a technical pyramid where you have a few core platform people at the top, and you’ll only grow the delivery capability by growing the base of the pyramid, where you have abundantly available developers working on whatever the trend is at the moment. FHIR absolutely nailed extending that base by pushing the whole spec as REST, which is what every line of business application developer knows.

If you insist on people having to conquer the complexity, and don’t focus on extending the base of your tech pyramid, you’ll end up with an ivory tower of tech.

Gary’s points and other feedback here would serve to extend the base of the pyramid.

5 Likes

Spot on. We think about this as an onion model:
-Specialized backend devs (just a few)
-Tool developers using the APIs and things as WebTemplates
-App developers
-Frontend developers

With every layer, you should need to know less about health IT and openEHR

3 Likes

I’m assuming it is also in the sense that you cry more for each layer you remove :rofl:

7 Likes