Separating Models from Implementation

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

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.

Completely agree but the same will apply to FHIR or anything else , as the complexity under the hood grows (and needs to be kept coherent across all applications.

For me this major first step that I saw in openEHR was TDS/TDD but then the SDT json formats (and example composition generation). We have had success at getting third-party apps developers to work with these with pretty complex datasets, but need to do much better . Folding in industry-familiar ideas like OpenAPI or GraphQL etc is also important but we also need good implementation guidance generation to explain the various constraints on particular nodes.

2 Likes

And this is where I wish the CIO would also have called experienced openEHR provider(group)s as I explained in post 36: Separating Models from Implementation - #36 by erik.sundvall

I also wish that they would find out that they would get all the help they need - and that they even would neeed less resources of their own than they would need to get the Cerner solution productive. If you look at the two Swedish regions now setting up Cerner solutions, it is a REALLY big and VERY resource consuming process (but any big bang EHR rip&replace operation would be) - the thing is though that Cerner tells them how to do it according to their standard process. That makes decision makers feel safe.

If a group of openEHR suppliers and consultants band together with each other and with some specialized software suppliers (PDMS, PAS etc) - then a service & modular open solution equal to or better than Cerner/EPIC could be delivered - and likely at a lower price. That would likely be more convincing than telling the trusts/regions to staff up and take full responsibility themselves.

And to get back to one of the main themes of the thread - when talking to and joining forces with those specialized software suppliers (PDMS, PAS etc) you’d likely find that one-level-model facades is what will get the initial integration up to speed in a fast, productive and reliable way. (Later they can expore more of the openEHR ecosystem.)

3 Likes

I know how it exactly works in the NHS. That’s why I don’t have any expectations of most of them here in the UK.

The old dictum holds: if you don’t want to keep getting the same outcome (failure), don’t keep doing
the same thing…

yep, I know all this in detail (from Leeds primarily, also contacts in Norther Ireland, and of course NPfIT…). THat’s why the solution isn’t to actually try to do this new kind of work initially in trusts (which are just fire-fighting a constant mess), but in a protected space (think of it as a HIT research institute - It’s a small university) managed by NHS Digital or similar. To do new kinds of work means learning new paradigms, methodologies, hiring, training, developing locally workable methods.

That’s what I mean by ‘investment’. That is what the previous attempts to obtain funding have mainly proposed, unfortunately without success.

It is a second phase to transfer what has been created and learned - technology, methods, tools etc, to locales of specific application development and operational contexts.

If the NHS were serious it could start now with an HIT institute and expect to be transferring highly effective methods and tools to the regions within 18m or 2y (given where we are now).

Trying to do anything at all directly in each locality from the outset is highly inefficient, and will be held back by friction between the ‘new work’ and the existing workload, which cannot be compromised for operational reasons.

I completely support of course the various technical tricks and resources we may bring to bear on the problem to do what @ToStupidForOpenEHR and others want (TDOs etc), but technology really isn’t the main difficulty here.

That is indeed a good graphic - an oldie but a goodie…!

But like I say, the real way to establish the practice and skills this efficiently isn’t in the regions, it’s in a protected space. I don’t expect this will happen; what I am pointing out is that since it won’t happen, expectations should not be raised too high that just by creating a new breed of TDO or whatever (which I personally can’t wait to see) will do the magic that some may expect. New paradigms, methodologies, and tools, no matter how wonderful, do not just magically drop into place in those over-heated and under-resourced engine rooms of regional/trust/city HIT infrastructures. I urge people to think more about the psycho-social angle.

Don’t worry, I get it. I know how it works in the NHS since 2005 when I was working as a specialist expert with Ken Lunn’s team. Hence the need for an HIT institute / NHS university kind of thing.

Sure - but relatively few people are needed to create platform tech + tools - but these people do need to be first rate technical people (and in the openEHR implementing comapnies/orgs, they are).

The two things these people develop - platform, and crucially, low-code development tools (and tricks, like TDOs, web templates etc) are the essential thing to enable a much larger number of developers do application development at the domain cognitive level, rather than as a technical exercise of interpreting ‘requirements’ and mentally translating into Java classes and DB schemas, as per the old textbooks.

To ‘solve’ NHS or Sweden doesn’t need people working on platform regionally (other than specific integrations, but even that is not actually a regional thing); what it needs is to do that centrally, and to promulgate Low-code development environments (with all appropriate localisations, e.g. terminology) worked out in advance.

Unfortunately that is unlikely, just for reasons of market psychology, though not impossible.

Which is why we shouldn’t do that.

2 Likes

Actually things have moved on quite a bit with ‘the NHS’ since the Leeds days!

At least 14 English Trusts have adopted openEHR in some shape or form, with several actively pursuing open platform strategies (as are Wales and Scotland).

Strategically ‘separating the apps for the data’ is definitely on the English NHS national agenda, and openEHR is specifically mentioned in those contexts. That is big change.

So oddly, it is really the Trusts who are leading, not the centre, at least in England. And more or on track to join.

4 Likes

This was in late September 2021 - I am aware of at least 2 more actual sites now and at least 2 more ‘in the works’

and BTW - the very worst place to start with openEHR (IMO) is in competing with a Cerner or Epic, in the megasuite EPR space.

There is a huge market out there alongside these systems (including bi-modal) - community. social care, mental health , regional shared records.

3 Likes

:sweat_smile: In similar vein, this Escher version of the Tower of Babel is quite evocative of the stacks of Babel (babble? !) that become entrenched in shaky computational edifices. Best not to get too philosophical, here, but it is sometimes salutary to remind ourselves that limitations of languages are ages old, and are amplified, often out of sight, in the complexities of computational languages today.

1 Like

I didn’t realise it was so many - that’s good to know. But - do they have a joint, protected R&D operation to develop the understanding of the paradigms, technology, tools, methods and localisations? If they don’t, it’s 14 small disconnected teams independently struggling to solve the same (not insignificant) intellectual and technology challenges.

THat is also good of course. But without an R&D group that has protected time and resources to concentrate on this (as CatSalut will do in fact), it won’t work out very well. Just having realised the importance of separated data doesn’t make it magically come into being…

To really function properly, they need an organisation like SKL in Sweden, that has resources to pursue common work for all member trusts. AFAIK, this does not exist in the UK, except, theoretically at the NHS Digital level.

Could not agree more.

2 Likes