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.
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.
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.
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)
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.
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.
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.
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.”
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.
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 ?
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.
In that particular case I think the (quite reasonable) question could then be formulated as - should we go for:
either some tested closed EHR platform supported by a supplier (like Cerner) with some API interaction points (e.g. FHIR+proprietary) for predefined data sets
or an open (vendor neutral) EHR platform with everything open - both APIs (full+simplified) and the full internal semantics/structures open. And in case #2 either…
2a. do it ourselves or
2b. do it together with a partner/group that provides and helps us use an openEHR based platform and clinical modelling
In case #1 your architects would have found the internal data models of the platform (in this case Cerner’s) to be even more complicated than openEHR’s - if they were allowed to look at them - but they likely never saw them, only big picture architecture and the things Cerner choose to expose via API - and that may look simple enough.
For case #2 to be comparable you could also choose to NOT have the architects look at the internal openEHR models, and instead only look at APIs for certain use cases, e.g. openEHR simplified formats for the particular templates/use-cases that solution #1 would also expose. In that case - to achieve the comparable situation as with buying Cerner - you should also go for #2b and pick an openEHR supplier (or supplier group) that gives you corresponding support, including creating templates and documenting simplified APIs for external parties that do not want to dive into openEHR internals.
Going for #2 without a partner with strong openEHR skills, international network and general EHR experience is like trying yourself to do all things Cerner have done to build their platform. (But with openEHR you’d at least get a good head start with a basic framework compared to starting from scratch.) It’s doable but it took Cerner some years to get there - and has taken openEHR platform suppliers some (but considerably fewer) years to do similar things…
The discussion of going for #1 or #2 is reasonable and still a living in reality (at least in Sweden)- A couple of years ago most big organisations (and consulting firms) would argue for #1, nowadays many argue for #2 after seeing the drawbacks of #1 and the possibilities and examples of #2. At least in region Stockholm (where I work) there are still people arguing for a mini-version of #1 after we stopped the procurement of a big (EPIC/Cerner-sized) procurement in #1-style. They think it will be way to complicated and take too long to go for #2. I personaly think #2 is certainly doable by having good partners/suppliers and simultaneously continue to train/recruit a strong team of our own. Two other Swedish Regions chose Cerner some years ago and are now working to implement/configure it to be able to run it in production.
@ToStupidForOpenEHR Does this reasoning resonate with your experiences and thoughts? Would such a modified #1 vs #2a/#2b comparison be of use if you’d get into similar situations again?
Can I suggest you (or someone) start a new topic on ‘ADL export formats’ or similar - that problem can be solved, but the details of what you want need to be discussed.
This thread is really more about openEHR and HIT solutions generally I think.
I’d suggest the opposite, the intend of the author of the topic is to discuss ADL export options. But others (including me) have hijacked the topic to state why you shouldn’t want it (still my position). So I think it’s nice to the author to split of that general HIT discussion and keep this topic focused on export of ckm models in a meaningful and clinically safe way in a format that allows Gary to do DDD.