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.
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)
@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:
true success stories of openEHR adoption in similar/peer organisations
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.
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.
@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:
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.
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.
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!
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.
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.
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
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.
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.)
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.
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.
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.
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.
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!
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.