Separating Models from Implementation

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

I don’t think this discussion should detour too greatly into national trials and tribulations, of which there are many and all different. However, they probably all raise and illustrate issues about what should and can be tackled globally and what locally, and methodology (this is only partly about matters of technical method, but also of clinical professional practice, organisational management, supporting services, and governance) whereby we propose to connect the two. So it is always going to be hard.

John Pattison was my Dean at UCL and became the NHS supremo who went on to pitch the NHS NPfIT to the then Prime Minister, Tony Blair. And the chair of the NHS Trust where my department was then based had by then become a government health minister. So I know a bit about how this episode actually came about, and how it played out in government. The politics of globalising and localising ‘policy’ in the NHS has sadly become an electoral cycle pendulum swing to and fro in the UK. And in the related information policies, trusted industry voices seem, by and large, to have prevailed in the consequential financial and operational decisions made at national level. ‘Might’ is usually deemed ‘right’ in those circles. No wonder that people at all levels of services have had to, or chose to play safe, as Seref said.

Much nearer to the ground, team and working environment and context for doing the actual work entailed, are crucial in whatever scenario is adopted. NPfIT was a car crash for these teams - I sat representing my University on these boards, at Trust and London level, and it was a Kafka-like experience. Chapter 9 of my (hopefully, fingers crossed!) forthcoming book is about people doing the work and the environments where they do it. I head it with this quotation, which I think endorses Thomas’s central point.
“A good environment is not a luxury; it is a necessity.”

  • Richard Wollheim, 1978 (as quoted in the preface to Programs of the Brain by the luminary life-scientist of yesteryear, JZ Young).

There have been a number of good implementation-focussed IT development environments that I have known, such as that of my late close colleague and friend from earliest days, Jo Milan, who Thomas mentioned, recently. It was through Jo that Thomas and I first met, and Thomas joined our team, in about 1992! What a sliding-door moment that was, for all of us! We certainly need more such teams and environments, in all sectors - in health services, academia and industry. Jo’s qualities, and the team and environment he created at the Royal Marsden cancer hospital, have been few and far between. Octo Barnett at Harvard and Stan Huff at SLC, in the States, were of a similar ilk. When they did keep their heads above water in what was always a fiercely contested domain, such people were often not well recognized and supported in what they achieved, as they achieved it. The survival of the special environments and teams they created depended a great deal on the phenomenal resilience, personal skills and dedication of these pioneering leaders. As Ian says, hopefully the general situation is beginning to improve in the UK.

But, to have a chance of sustained improvement in the still rapidly evolving world of healthcare |IT, a much wider and shared, implementation-focused culture and community, centred on creating and sustaining a creative commons of relevant methodologies, is now, more than ever, another Wolheim necessity. For all its inevitable limitations and failings, that’s what openEHR folk have sought, and should always seek, to embody and help create and sustain. It’s never going to be anything but hard work!

3 Likes

I’ve reread the entire thread and looked for requirements for simplifications.

  • The clearest request I could find came from Erik and Ian for GraphQL.
  • OpenAPI was also mentioned often. I’ll work on it after GraphQL.
  • TypeScript model classes that act as proxies between openEHR CDR and client applications is also an option.
  • Anything else?

I created a separate topic focused only on GraphQL with a download link and source code:

  • There is a great Java example in the “java-apollo-android” folder.
  • Also “graphql.schema.json” for a Blood Pressure OPT GraphQL schema in JSON.
  • And the “schema.graphql”.
2 Likes

At Karolinska the most burning need* right now is actually generation of template-specific schema (that fit into mapping tools like Mirth and Altova MapForce) and corresponding bi-directional format-converters (converting data instances bidirectionally between simplified and canonical openEHR formats). This is available for XML in from of TDS+TDD+bidirectional XSLT from some openEHR system providers, but sadly not yet officially specified by openEHR.

That said, the GraphQL approach is highly interesting for other needs we also have, so I posted some initial questions in the corresponding thread.

*) We are currently working with populating our CDR with e.g. lab data coming from sources using EDI, HL7 v2 etc. Mapping tools handle the source formats well and can usually target XML schema or JSON schema and generate instances following those. With mapping tools informaticians and lab IT staff can create and maintain conversions without beeing programmers, then we’ll just need to call in the programmers for tricky parts that the tools don’t solve - this approach scales better than programming every conversion.

1 Like

Nothing scales as good as computers generating the converters/code/applications :blush:

Here is a sample of simplified code working with blood pressure template:

More in this answer.

More about the generator’s code in this answer. It takes only a few lines and the generator can output code in TypeScript, C#, Kotlin,…

3 Likes

I made a simple XSLT to transform an #openehr composition into a simpler form more easy to work with in tools like Altova. The idea was to help the national cancer registry in Norway.

Source here : kremt-examples/xslt at main · bjornna/kremt-examples · GitHub

They are not using this. They map the canonical xml using Altova.

Sounds painful

Indeed. Very patient and nice guy working on this.

The most important thing : They accept canonical openehr as input to the registry. No additional, unnecessary and resource driven mapping to a wire format like fhir.

2 Likes

Just out of curiosity: I guess the notation ..data = ... is a kind of builder pattern in Dart? Why the double dots?

Yes. It is called “Cascade notation”. Since I had to look-up the name, here is the link with explanation and examples: cascade notation

The main difference in my example is for “data” and “protocol”. With double dots I didn’t have to repeat “bloodPressure” twice:

var bloodPressure = BloodPressure();       <= there is an implicit "new"
bloodPressure.data = BloodPressureData();
bloodPressure.data.history = BloorPressureDataHistory();
bloodPressure.data.history.events = [BloorPressureDataHistoryEvent()];
...
bloodPressure.protocol = BloodPressureProtocol();