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.
do you want to start from a template (use-case specific data set) or an archetype?
how do you want the necessary RM context attributes to appear?
A manual exercise to sketch out a converted archetype, say a heart rate Observation inside a Composition might be a good starting point. Can @ToStupidForOpenEHR provide a steer on what you want to see in the output in a chunk of rough JSON or other common format? If we can see the source and target, we will have a better idea of what you want. I think it is probably very close to TDS / TDO, which was developed over a decade ago, but not used that much these days.
I find your original request there very reasonable. I believe that what you are asking for is exactly what the TDS/TSS approach did/does using normal XML-schema and XML instances (that any XML tool understood, without being an openEHR-specific tool). We’d need a JSON schema-based equivalent nowadays. (And likely a similar GraphQL approach.) Would the approach discussed in post #12 above achieve what you are asking for?
The Web template JSON-files are semantically a schema like TDS but in a custom JSON structure, not in a format that non-openEHR tools like Altova can ingest. Let’s fix that by creating a way to generate proper (template specific) JSON schema (that can be used in regular non-openEHR tools).
The openEHR vendor Better has separated out some generic things (user, language etc) into a context (ctx) object that can be reused in API calls and automatically populate some COMPOSITION and VERSION values from that. That kind separation would likely be clever to allow if we want a simpler format for specific templates.
Yes, what you have in post 12 is closer to my suggestion, a format that non-OpenEHR Tools can ingest.
Let me give you a simple use case. Let’s say an app developer in the UK wants to build a small app for Diabetes patients, they know that the concrete classes will be small, they conclude that a single level model approach is sufficient, rather than two-level. At the moment they have the choice of creating the information model themselves, trying to adapt something from FHIR or going to somewhere like https://theprsb.org/ or using models designed by the OpenEHR clinical community. As it stands the models from the OpenEHR community are only available to those with OpenEHR tools and I think in fairness do require at least a decent understanding of the relationship between the RM, Archetypes and Templates.
If the model could just be exported from the CKM or as you suggest from Templates then I think more people would use the OpenEHR clinical models. This app developer may in due course realise the power of OpenEHR and expand their offering, at which time they may decide to fully adopt OpenEHR.
Yes, that’s a great usecases for the described export!
I think we should do OpenAPI as a format mainly because it allows code generation from the models to first class citizen, so no RM/openEHR or anything! (More detail in the topic by Pieter references by Borut)
You state you don’t want a multi level modelling approach. The challenge here is what kind of data do you record and how does the app record enough context (meta information) to make it meaningful. Simplest way to do this would be to only use the BP observation archetype and set an (potentially implicit) default context (e.gl time, non professional recorder, etc) in the app. This might be ok, but I’d still say it’s much easier and safer to export the relevant RM attributes (qualification of recorder, time of measurement etc) from the RM with the archetypes. These are the ones on CKM you see at the ‘reference model tab’ Clinical Knowledge Manager
But what the app builder will also have to do is to only render the relevant datapoints from multiple archetypes in a form like ui: e.g. to record a glucose measurement once a day, you need 3-5 archetypes, and disable 95% of the available data points. And if you also want to record say blood pressure and some more related data this gets to be a lot off work quickly. And there’s already a solution for this in the form of templates. And tools to easily create those to achieve the described requirements and export to a webtemplate.
So I’d argue the best way to achieve your scenario currently would be to use archetype designer to do the data modelling work, export as webtemplate and use medblocks ui to render it. Should be doable in less than a day without knowing about openEHR.
If you don’t want an openEHR export format (again I’d prefer openapi), someone would have to build that into Archetype designer (or CKM). What would you be able to contribute to get this done?
Hi @erik.sundvall I don’t see any issues on working on the tech side to build frameworks, SDKs, libraries and tools to make things easier, I did that myself.
What I tried to tell, and might be misunderstood, is my own experience with openEHR and it’s learning curve, and based on that experience, my own opinion on why some companies run away from openEHR, since I don’t think the main issue is complexity of the specs or the lack of tooling available. Though I see more issues in the tooling side than in the spec complexity side. That is also why I created my own tools (https://toolkit.cabolabs.com/).
Another thing is what was proposed here about separating the RM from the AOM just doesn’t work since AOM depends on a RM. My point was that the AOM is already abstracted from the RM since it can be ANY RM, even a custom one, but at design time the RM should be defined so archetypes and templates could be created. The key think to get clear is: this is the core design of openEHR, it is not right or wrong, is the design, so any change at that core area is basically not going in the openEHR way.
That is totally fine, I guess they have a list of core requirements / problems to solve, and some knowledge about what openEHR is for, and openEHR wasn’t a fit for the project. Though there are other things to consider like hidden business goals and politics. I guess they didn’t share with you a detailed rationale why they are not including openEHR in the architecture.
If a decision is made at a strategic level without having a clear list of requirements and knowledge about the specs that could help tackling those requirements, they are clearly considering other things to decide what goes in or not, despite any logic reason.
I mean, some people see interoperability as a business killer, and they promote vendor lock-in. Bottom line: openEHR is not for everyone and that is OK.
You need to define those “things” so the different programs could take a look, community input is important, but we need details.
For instance, what you mention on your first message of separating the RM from the AOM, is not possible as I already mentioned, but the AOM is not depending on the RM, you can use any RM or define your own. The issue is tools available can’t support multiple models (I think only LinkEHR supports multiple models).
My message is not about a lecture, it’s about my own experience when starting from scratch with openEHR, and my opinion why some companies don’t get into openEHR. I thought that could help giving a sample path for people just starting with openEHR, specially to give an idea of the time required to get proficient in openEHR specs and implementation, which is information you can’t find out there…
Which does a good description of describing the thinking behind OpenEHR that had not jumped out at me from the specs page.
Now, I am used to a single model approach, that not only encapsulates data but business logic in the domain model, as per Eric Evans and DDD, and Fowler in PEAA (domain model and all the design patterns)
OpenEHR seems to have started of as a two-level approach (which I think still holds true for RM and Archetype), and is now a multi-level approach (I think templates are the 3rd level on this stack)
I’m asking can OpenEHR models stored as multi-level (I think I want RM+ArcheType+Template) also be exported as single-level. The multi-level approach suggests this would be doable
It is; just a question of the details. I think between the OpenAPI, TDS (others will explain) and Web template options, you will get a solution. My suspicion is that OpenAPI might do the better job today. This allows us to look at it as a model-to-model transform problem - the output is a kind of custom single level UML equivalent, with the concrete format being OpenAPI. But we could pump out real UML or Java, or… whatever you want.
Fellow propeller-heads - do we have an OpenAPI conversion that compresses useful parts of the RM into the output?
I’ve only just got caught up on openAPI formats but I agree - I think that is a pretty decent start point (GraphQL second?). There are almost certainly limitations and complexities .esp. that (as for every health model standard) much more complex basic datatype classes that need to be included and their constraints represented but I can see how that might be a good target for what Gary has in mind.
Has anyone done any practical work or thinking on openEHR opt (or WebTemplate) to OpenAPI? are the aspects of the JSON Schema work that we can pick up?
@nedap we are specifying all apis (incl their models) as OpenAPI 3.0. We’re working on a project to also offer some openEHR data as OpenAPI. Probably a specific template to a specific OpenAPI endpoint with a url that has the template name and the model a fixed map from the template, with manually mapping mandatory openEHR paths to the OpenAPI model.
So there’s a big interest from Nedap and we’re willing to collaborate.
And as has been shared before, @pieterbos already generated the RM as OpenAPI. There are also ideas to generate OpenAPI endpoints for every openEHR template (version). The main benefit is client apps don’t need to now about openEHR complexity for simple stuff (I named our calendar app before).
Finally I think I heard having models in OpenAPI also helps a lot to do graphql. But not an expert here.
Stupid question: my understanding is that OpenAPI is basically swagger which is a way to document a REST API. Or am I missing something here?
Edit: as mentioned once or twice, our software development kit allows to automatically generates human-friendly, non-abstract classes. The endpoint name is derived from the template id. We have also a demo app for this:
Well, OpenAPI is a successor to swagger and indeed is a way to describe REST APIs. What you’re ‘missing’ is that it’s also a way to describe the model of the data that the api gets/posts.
This is modelled using (something very close to) json schema. And this model has proven powerful enough to express the entire RM (for details see Pieters topic). And the OpenAPI has nice tools to work with those models. Visual modelling tools like stoplight studio. And tools that generate code from those models so that a specific BP measurement result template could be a class in swift (or many other languages). And all the benefits that come with that: IDE auto completion, DDD etc, so that its very easy to work with OpenAPI in your native app, and hopefully also openEHR data gets very easy to work with, without the app having to understand OpenEHR data formats and RM.
(