That is also my suggestion for the simplest export that is still actually useful.
1 Like
From my own experience, it depends on the role of the person learning. When I started learning openEHR my role was Java developer, and my goal was to implement the RM in a working EMR. For an implementer I would say it takes 3 months to get a basic understanding of the basic models (RM and AOM), but requires also hands-on testing of reference implementations like the Java Ref Impl and using the modeling tools (at that time only Ocean tools were available, this was 15 years ago). Then in a total of 6 months I got a good grasp of the specs and basic implementation, which requires almost daily communication with the community (I asked a lot of questions in the mail lists we had back then). I was also able to contribute to the specs and the Java implementation, reporting errors and things that were not so well defined/described in the specs.
Then I had I degree thesis project, which was basically an year and a half of openEHR implementation and integration with DICOM and CDA. This gave me in deep knowledge of the implementation of the specs and how it plays with other standards. After 2 years in total of implementation experience I felt proficient enough to create an online course 100% about openEHR, including specs, modeling and implementation topics.
That is a simple equation: benefits perceived vs. investment estimated should be positive for them to get into openEHR. The issue I see is most companies just get into the specs for a couple of weeks, some without any experience implementing other standards, and want to build a full EHR compliant with openEHR. I believe there is a wrong expectation for some of these companies, which most get into openEHR just for the hype.
To get into openEHR a company should know 1. which problem openEHR solves, 2. see the value in that, 3. most important: they should have detected the problems that openEHR solves into their current systems.
Most want a solution to a problem they don’t have… yet.
For companies that have specific EMR systems or clinical apps, openEHR might not be a good fit. openEHR is about EHR platforms, not apps. It’s about what will happen to clinical information in 20-50 years, not what will happen in 6 months.
This is not the problem, and it is clearly not the how openEHR works. First thing to understand about openEHR is the layered model paradigm, where each layer adds semantics to the previous layer. The RM is the basic semantic model in openEHR, defining the basic information building blocks. The archetype model is the second layer, adding semantics to the RM layer, defining clinical information building blocks. Templates are a third layer, CDS rules a fourth, and so on.
Then, if the archetype model doesn’t reference an RM, you are losing the basic building blocks, and if the archetype model is totally stand-alone, then it will need to define it’s own RM or another RM that is simpler than the openEHR RM. Though, the AM currently can reference ANY reference model, so that is totally possible right now, I mean defining a simpler RM and define archetypes over that RM.
Another point is the current RM has 20 years of R+D of designing, testing and fixing. Though it still has it’s problems, I doubt anyone can come up with a simpler RM that is expressive enough and is better than the current RM. On the other hand, ISO13606 is simpler than openEHR and is expressive enough to represent any clinical data structure, so I guess that one is the best candidate you have today without the need of another 20 years to design and refine a new model.
As a related comment there is no “more generic way”, since when you get your hands dirty in the “generic” approach you will end up with something similar than we have right now. “generic” without any concrete requirement behind is too generic.
My recommendation for companies wanting to get into openEHR but don’t want to spend too much:
- understand your problem(s)
- contact an expert with real world implementation experience
- ask him/her all the questions you have to estimate the effort you need to implement openEHR and/or have your employees trained in openEHR to own the know-how, or just hire people that already knows to lead your team so your team can learn along the way
There is no simple approach to health information management and health platforms, the inherent complexity is just too high.
5 Likes
I’m not sure Gary came here for the lectures.
I learnt some new information from all the provided information but I would rather focus on letting Gary present his point of view.
I would like to learn what his requirements are first. Without any judgment or trying to convince him to follow somebody else’s approach to openEHR.
@ToStupidForOpenEHR Gary - please find some time to answer these questions:
3 Likes
@pablo I agree with what you write, but would like to improve a streamlined way for app-building etc for use-cases where a template (made by people understanding enough of openEHR and the use case) is already available.
Perhaps a way to, based on an OPT/Web-template file, generate running example projects in environments like https://stackblitz.com/ based on an operational template.
4 Likes
CKM has a lovely REST API which is very simple to use and will give you most of the things the interface gives you. If you are only interested in the mindmap (or other derived materials) other tooling that made use of that API can provide you with the output you need (e.g. LinkEHR can access CKM archetypes and can export them to xmind, but I’m sure there are several examples on other tools)
2 Likes
Here is the blood pressure archetype in Web Template format (stripped out from the parent composition wrapper
I think this is currently the easiest approach.
The full template, which has to include the parent composition is at
and example of how to parse it to an Asciidoc Thx @bna is at
I think what we are really talking about is not to ‘remove the RM’ as such, since have others have said, it provides a lot of basic components such as datatyypes, some basic clinical structures like Observation, Action etc and provenance.
I think it should be possible to construct a subset of the RM that can be folded into Entry-level archetypes, sufficient for clinical sense-making/ implementation guidance and supported in our tooling as well as ‘external’ efforts as @ToStupidForOpenEHR is suggesting.
In a sense, this is exactly what the web template format is doing - it brings in only those aspects of the RM that are necessary to ‘understand’ the model without a deeper commitment to those aspects which are necessary for CDR persistence.
2 Likes
I should add that in reality, you often have to combine archetypes to create viable models e.g. We may need to include a device Cluster archetype into the context of a blood pressure archetype to allow it to capture manufacturer, device Id.
We also often need templates to add the correct terminology bindings as these are often locally determined.
@ToStupidForOpenEHR - I suggest you get to grips with the Archetype Designer and its various output formats ,as well as CKM as you will nearly always need to create templates to construct ‘proper models’. CKM is a great tool but it is only part of the story.
2 Likes
This is beginning to feel a bit like twitter again, with people telling me I’m wrong, or that I need to invest time learning OpenEHR.
Let me give you a real world scenario without naming names. I’m engaged as an Enterprise Architect on a major national programme to define a Target Architecture. The budget is decent, around £100m. I write a strategy paper talking about separating the data from the application, and liberating data. Basically creating a national CDR. Calling out OpenEHR as potential option.
Directors come back to me and say, we really like the idea, and would like to adopt the clinical models developed by OpenEHR, but our architects have looked at OpenEHR and the specification programme and decided it’s not something we can invest the time and effort in. It’s too much of a heavy lift.
Result…OpenEHR removed from the strategy.
I’ve lost count of the number of times a technical representative of a client has looked at OpenEHR and recommended to their bosses that they would be unable to support.
If you want to be successful you need to make things easier.
3 Likes
I was recently at a conference where the national body wanted to encourage an ecosystem of development, i.e. allowing ISV’s to develop a whole range of apps targeting certain conditions or groups of cohorts. The biggest barrier to this is that ISV’s don’t really understand healthcare data, and they don’t want to reinvent the wheel. The ISV in the room had tried to develop an app using FHIR interfaces, but this had not worked. The national body did not want to develop app’s they wanted to provide a CDR and API’s that ISV’s could consume to develop apps.
This I think is the future, and something OpenEHR could support if it was easier to consume. (I also know that some technical clients are put off by the binding of the models to the UI via templates, they want to fold in their own design and components…it’s the CDR they want, not the full stack)
1 Like
That’s a perfectly reasonable perspective and doable by all of the CDR products on the market. None are tied to UI generation.
1 Like
Did the directors propose an alternative for the CDR?
I don’t see how the CDR part could be simplified. They will spend more time and effort if they start building it from scratch (they might prefer this as it is more profitable for those building it).
The ISV applications that connect to the CDR are already simplified with WebTemplates, Simplified Data Templates. If that is too complicated for the ISVs then they shouldn’t work on the projects that are outside their competencies.
Would a generated ORM model help the ISVs? Or even as a higher level library to the CDR data?
Not meant as a self promotion but I want to show you that there are many options how to approach what you describe:
It would be a valuable information to understand what the directors expect. If you can help us understand their expectations/requirements then we may start working on providing what they wish for.
I’ll be happy to spend some time generating a proof-of-concepts.
1 Like
You have a £100m budget, and the organisation employed engineers who can’t be bothered to learn a new information model? The solution to that problem is very obvious… (and I hope it’s not public money).
On one level that is true, for competent people working in good faith and trying to do a particular application or whatever. But the overall problem isn’t easy. Why do you think HL7 have been through 4 revolutions of the standards wheel, throwing out everything each time and starting again? Why has the entire ‘interoperability’ approach solved nothing beyond lab panels, a bit of prescription and ADT? Why is there still no patient-centric EHR, just EMRs that physicians hate?
Anytime the organisation in question wants to get some real value for say £10m, I can tell them where to spend it very economically. I’m not kidding. We’ll leave the result of the expenditure of the other £90m to the National Audit Office, they have good experience with this kind of thing…
Well, I’d say the CDR API is easier and more standard than the FHIR one (there is no standard FHIR API).
That is actually a reasonable need, and they are not required to connect templates to UI in any particular way. But low-code tools are emerging and are making injection of local semantics possible.
1 Like
Would the directors be willing to spread the risk and dedicate £1-5m to parallel exploratory projects? If each gets £1m and only one succeeds the payout is worth it.
Edit:
Alternative is spending £100m on a single project and after 5 years writing it off if the project fails.
1 Like
They opted for Cerner instead I believe. Was a past client.
1 Like
I think what I am hearing again is “no, you are wrong OpenEHR is the correct answer” - “it’s up to people to invest time, money and resources learning OpenEHR.”
1 Like
I try to direct this thread in your direction Gary:
But to be honest you are not providing information on what would be needed for you or your projects.
Saying that you expect JSON Schema instead of the already available JSON is not enough.
How did you explain to the directors what the requirements for their CDR are? Or for the ISVs? What they have to be careful about in the procurement of these apps?
Please take us much space as everybody else in this thread. Don’t answer in single sentences.
1 Like
Ok, let’s go back to the original ask/suggestion :
What I would like to see is an option to separate the Clinical model from any dependencies introduced by OpenEHR, such as the RM. I can see how the RM is very useful for Clinical Modellers, but there should be an option to express (export from the CKM) the model in a more generic way, one that does not require any understanding of the RM, or indeed require OpenEHR tooling to parse/understand.
This I think would increase the usage of the OpenEHR clinical models.
Essentially an export to XML, JSON or similar, with no dependency on the RM, the model exported a concrete rather than meta-model. - the closest thing I can see to this at the moment is the mind-map or printable version of the archetype.
What do I think people would do with it ?
I think follow more of a DDD approach rather than meta-model. Not saying one is better than the other, but surely better to have >1 way to implement the model ?
2 Likes
I asked if you would prefer to have DDLs or ORM model classes for openEHR archetypes. No RM or anything openEHR related. Just pure classes.
Wouldn’t that enable your DDD approach?
1 Like
Possibly, but I think the option I suggest is neater, then folks can generate their own ORM, classes etc
Personally I prefer .NET, so if I was going to do this then I’d want to take advantage of the features in C#.
1 Like
Can we find a way to make the archetype models more ‘RM-independent’ - to which the answer is yes - but the RM carries a lot of critical ‘clinical’ parts of the models e.g datatypes, provenance, utility structures like Action, without which they make no sense, unless you add the same things back in again. So the answer to your question is not to make the archetype RM -indpendent because they can’t be any more than clinical SCI-XML models could be independent of the base types , or FHIR resources could work without their pre-defined datatypes. So what we need to do is to be able to fold in those parts of the RM that are critical to the faithful clinical meaning of the archetype.
There are a number of different ways of doing that, and this is not dissimilar to what developers end up with in pure openEHR-land, via Web templates, flattened data forms, proxy object generation - these are all about folding things back together and hiding most of the RM ‘persistence’ sub-structure away, where it needs to be inside CDRs
I’d really like you to have a look at the Web template example and say what is wrong with it from your POV. All of the model, including those critical parts of the RM are expressed in a readily parsable way in JSON.
3 Likes