# Separating Models from Implementation **Category:** [New to openEHR?](https://discourse.openehr.org/c/new-to-openehr/13) **Created:** 2021-11-22 13:56 UTC **Views:** 5598 **Replies:** 107 **URL:** https://discourse.openehr.org/t/separating-models-from-implementation/2093 --- ## Post #1 by @ToStupidForOpenEHR Although OpenEHR is now getting more traction there is a still a considerable learning curve and barrier to adoption. I quick review of other posts suggest it takes at least a year of continual study to gain a good understanding of OpenEHR. We would all benefit if the models produced by the CKM were much more widely used across the industry. (they should be ubiquitous). I know first hand from talking to a number of companies and investors that this learning curve is just too steep, and they walk away from OpenEHR. 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. Essentially an export to XML, JSON or similar, with no dependency on the RM, the model exported a concrete rather than meta-model. --- ## Post #2 by @thomas.beale [quote="ToStupidForOpenEHR, post:1, topic:2093"] We would all benefit if the models produced by the CKM were much more widely used across the industry. (they should be ubiquitous). [/quote] I would say it is almost a moral imperative to realise the value of the thousands of hours of clinical time and governance that have gone into the archetypes & subsets. [quote="ToStupidForOpenEHR, post:1, topic:2093"] 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 [/quote] As has been discussed elsewhere, the technical side of this is relatively trivial, and indeed has been available in tools for some years. New exports can fairly quickly be coded up. There is sometimes a misconception that the openEHR RM is a data schema or data model. It can be used as the basis of such, but really the core of the RM (the part that is archetyped) is a small ontology of common clinical information types and context data items. If the RM is removed, you lose: * types like `COMPOSITION`, `SECTION`, `OBSERVATION`, `ACTION`, `INSTRUCTION` etc * the clinical data types, i.e. `DV_TEXT`, `DV_CODED_TEXT`, `DV_ORDINAL`, `DV_QUANTITY`, etc * attributes like `ENTRY.subject`, `ENTRY.provider`, `COMPOSITION.context.start_time` etc Every health information model I know of contains types and attributes with the same meanings - they are essentially standard. If they are not defined in a standard way (i.e. names and types), everyone has to recreate all these necessary attributes directly in the archetypes - and they will do it with different names - which will decrease interoperability, not improve it. So it is a point of curiosity for me at least what is gained by removing the RM entirely. Or maybe you are thinking of retaining these standard attributes, but somehow converted to just more data items in a large tree? This seems to me more useful, although any variation is technically possible. --- ## Post #3 by @borut.jures [quote="ToStupidForOpenEHR, post:1, topic:2093"] Essentially an export to XML, JSON or similar, with no dependency on the RM, the model exported a concrete rather than meta-model. [/quote] The tools export archetypes in XML and JSON. I have attached a shortened version of the blood pressure observation template in JSON. Would this be useful for your approach? If not please show an example of XML/JSON that would be a useful export from the openEHR archetype modeler. Maybe it can be done. Combinations of properties like e.g. "@type" : "C_COMPLEX_OBJECT" and "rm_type_name" : "OBSERVATION" could be entities in an E/R model. Properties like "@type" : "C_ATTRIBUTE" and "rm_attribute_name" : "units" could be attributes in the entities. And many of the properties in the attached JSON can probably be omitted. [openEHR-EHR-OBSERVATION.blood_pressure.v2.0.8_opt-short.json|attachment](upload://tEx3VYMRee3yAxjmrMBwATALNkW.json) (163.4 KB) --- ## Post #4 by @ToStupidForOpenEHR Just looked at a few archetypes again... if I look at the mindmaps of say bloodpressure or news2 then I can understand them, the mindmap view is much more of a concrete view of things. Also, if I look at the printed versions of above, again I can understand them. However, the only representation I can get from the CKM is an export of the ADL...which requires quite a bit of tooling to be able to parse etc Can we not do an export of the mindmap or the printable version as XML or JSON ? --- ## Post #5 by @borut.jures Now that I'm thinking about this... Maybe openEHR tools could export DDL for SQL databases. Or formats supported by tools like [Liquibase](https://www.liquibase.org/) that will ease the constant schema changes. Or directly source code models for popular ORMs. p.s. All of the above formats may use already supported XML/JSON as their starting point. --- ## Post #6 by @borut.jures [quote="ToStupidForOpenEHR, post:4, topic:2093"] Can we not do an export of the mindmap or the printable version as XML or JSON ? [/quote] 3rd icon right of the MInd Map icon: ![Screenshot 2021-11-22 at 16.58.50|690x248](upload://nimiyMjeQzTx6IySTr85mVxMYAX.png) Edit: Oh, you mean to only export what is shown in the Mind Map as XML/JSON? --- ## Post #7 by @ToStupidForOpenEHR I think it should be the CKM that supports the export. --- ## Post #8 by @borut.jures [quote="ToStupidForOpenEHR, post:7, topic:2093, full:true"] I think it should be the CKM that supports the export. [/quote] Yes, the CKM could support the format you need (up to the CKM vendors) or an online tool could convert the files exported from the CKM into the one you need (this is independent of the CKM vendors who might not have time to support such a format). At the moment I'm curious what format would help you achieve your goals? --- ## Post #9 by @ToStupidForOpenEHR yes, the current XML export look like an XML version of the ADL --- ## Post #10 by @ToStupidForOpenEHR Something I can parse more easily....without having to use archie, or muck around with ANTLR etc Was thinking http://json-schema.org/ --- ## Post #11 by @borut.jures [quote="ToStupidForOpenEHR, post:10, topic:2093"] Was thinking http://json-schema.org/ [/quote] So once you have a Blood pressure archetype (or template - which do you plan to use?) in a JSON file, how would you use it? For the backend, frontend, ETL,...? --- You probably already found these (and other posts): https://discourse.openehr.org/t/json-schema-and-openapi-current-state-and-how-to-progress/1385 https://discourse.openehr.org/t/did-anybody-use-the-json-schema-for-code-generation/1046 --- ## Post #12 by @erik.sundvall First, I love your ironical nickname! [quote="ToStupidForOpenEHR, post:10, topic:2093, full:true"] Something I can parse more easily…without having to use archie, or muck around with ANTLR etc [/quote] The "web template" format could be described as a kind of pre-parsed version of OPT (operational template), would that work? It can be exported from [Archetype Designer](https://tools.openehr.org/designer/): ![image|690x301](upload://jTb8k3y7eZrJRo2sxZFlZXNQumm.png) [quote="ToStupidForOpenEHR, post:10, topic:2093, full:true"] Was thinking [http://json-schema.org/ ](http://json-schema.org/) [/quote] Yes, for example auto-generation of a template-specific JSON-schema for the simplified "structured" format (that is a tree- version of the [same sematics as "flat format"](https://ehrbase.readthedocs.io/en/latest/02_getting_started/05_load_data/index.html#flat-format)) would be wonderful. I'd guess somebody with less rusty programming skills than me could easily make a generator that consumes a web template file and spits out a template-specific JSON schema... Here is a piece of an instance example that should adhere to such a schema: ``` "vital_signs": { "context": [ { "context_detail": [ { "tags": [ "Example Tag 123" ] } ] } ], "body_temperature": [ { "any_event": [ { "temperature": [ { "|magnitude": 38.8, "|unit": "°C" } ], "body_exposure": [ { "|code": "at0033" } ], "description_of_thermal_stress": [ "Description of thermal stress 51" ] } ], "site_of_measurement": [ { "|code": "at0022" } ] } ], "blood_pressure": [ { ... and so on ``` Probably the schema should include the name of the at00XX-codes (at least as comments) to be readable, not only the codes. --- ## Post #13 by @erik.sundvall Also, generating a readable template-specific [GraphQL schema](https://graphql.org/learn/schema/) might be just as useful as a JSON schema. It could be used with a potential future [Contribution builder API](https://discourse.openehr.org/t/contribution-builder-supporting-collaborative-multi-user-multi-device-editing-graphql-operational-transformation/2071). --- ## Post #14 by @joostholslag [quote="ToStupidForOpenEHR, post:1, topic:2093"] I quick review of other posts suggest it takes at least a year of continual study to gain a good understanding of OpenEHR. We would all benefit if the models produced by the CKM were much more widely used across the industry. (they should be ubiquitous). I know first hand from talking to a number of companies and investors that this learning curve is just too steep, and they walk away from OpenEHR. [/quote] Thank you for sharing your experience here. I’m sure most agree the learning curve for openEHR is way too steep. And the investors walking away is a new perspective that adds to the information around this discussion. I do feel that one of the reasons the learning curve is too steep is that it’s the most comprehensive list of requirements for storing clinical data I know of. (Almost a handbook on health IT). And since this knowledge is not readily available elsewhere and should be common knowledge for people in the field. It adds to the learning curve, while it should be a prerequisite. And my view is these requirements (E.g. always recording context, full version history with audit trail etc.) can’t be simplified without violating medico legal and clinical safety rules. And that should never be an option. If someone is unaware of these requirements or judges there importance difficulty (as happens often), this is very distressing to people who do see those risks, or even experienced themselves how badly health IT is if stuff goes wrong. And this leads to heated debate that can be hurtful and unproductive. The other part of the learning curve is in openEHR trying to boil the ocean e.g. do everything perfectly flexible (item_tree and many variants on it) and the decision to let clinicians do the modelling in a computable way (ADL) and the design choice of a RM meta model comes from this. I like this a lot about openEHR, because in the words of @bna [‘I know I can handle any clinical (modelling) problem’](https://www.highmed-symposium.de/) . But it’s a valid choice to simplify many things at the cost of flexibility, if you don’t need it. I’m really curious about what parts of openEHR you want to simplify. But maybe that’s better for a separate discourse topics. The third part where we should improve is education. How do we teach people about openEHR instead of our current approach of referring them to hundreds of pages of documentation. (Your words, right?). There are efforts here but they are constrained by resources. All help welcome here I guess. The fourth part is abstracting away most of the complexity. This is where open source software (ehrbase) libraries (Archie) and tools (ckm, archetype designer, medblocks ui components, OpenAPI generator etc). There has been great progress in this area, we’re almost at a point where if you develop a simple app or create a clinical form, you don’t need to know technical details of openEHR and work in your preferred stack, while retaining the comprehensive requirements of openEHR and strongly increasing the speed of development compared to starting from scratch or smart on fhir. Where before it was a huge challenge to first engineer a Clinical Data Repository, and openEHR front-end. This is still where I believe the openEHR community should focus it’s efforts. With generating OpenAPI models (JSON schema variant) from openEHR templates, that allow generating code (as first class citizens in your words) in many languages, without knowing much about openEHR as my desired next step. But you, as an enterprise architect are not directly the target audience here. You *should* know what’s under the hood. As you’ve repeatedly expressed and as shown by you detailed questions about ADL, Odin etc. And I understand your company to work on an ‘openEHR compliant’ EHR platform. But the availability of open source CDRs should help greatly in the speed of getting familiar with openEHR. To start I’d recommend the videos by @pablo, they explain how to get data and how to work with it. A lot better way to get started on openEHR then to implement a new CDR by reading the specs, which used to be the only option to get started. As a final part, now that I mention Odin, there’s also the part of domain (openEHR) specific languages. This also is a barrier to understanding compared to reusing similar languages that are familiar to many people. This is also something I heard you complain about repeatedly. And I agree with you here, as many people in the openEHR community do. I shared before the openEHR confluence/jira issue where there’s talk about replacing odin with json. The other side of this discussion is twofold: 1 are they as fit for purpose (I’m not an engineer and hardly qualified to answer this, but I’m curious for your opinion), 2: openEHR is old, which means when it was developed there was no json as a clear standard, this is only a question of resources to update it. But mostly this is about it’s designed to be used to store lifetime health records. So for the life of the people being (about to be) born. The standard should exist, since most tech is designed to be obsolete in a few decades, this means openEHR should be (and is) tech neutral and it makes us reluctant to create dependencies on other tech to interpret the data. There’s a lot of room to debate specific choices e.g. Odin vs json, ADL vs OpenAPI, GDL vs drools, openEHR DL vs BPMN etc etc. But since you’ve clearly stated you’ve made up your mind let’s now focus on your request of having the CKM models as json schema without RM as a meta model. I have to say once (I’ll try to make it the last time): I strongly believe this is only going to be useful for very simple use cases (e.g. a patient self measurement app for blood pressure) where not all openEHR requirements are relevant. And in integration scenarios in conjunction with a full openEHR CDR. Uses like this have been described by Patrik from Karolinka in the present ion slides I tweets to you recently. For other: slide 7 https://www.highmed-symposium.de/ The next thing to state (hopefully for the last time as well) the reference model is an integral part of the CKM archetypes, so you can’t seperate the two. E.g. every blood pressure measurement needs to record the time and setting of that measurement, that is not in the ADL of the CKM archetype, it’s inherited from the RM by statements (in the ADL) like OBSERVATION. What we can do however is flatten out those inheritances, so that if you export the BP ADL as json (schema)/ OpenAPI that file does contain the relevant inherited datapoints like a time and setting. So that you don’t need to know anything about the RM (nor need an openEHR CDR to use it). Would that be what you’re after? And finally I believe we should maybe focus on exporting templates on COMPOSITIONs: models for a specific purpose. E.g recording the result of a BP measurement (instead of a generic BP observation) since many relevant data points (e.g the start time) actually inherit from compositions instead of observation and it’s valuable to have that standardised. Since the modellers of the CKM assumed all archetypes would be used in templates on compositions. So I’d argue the model is (unsafely) incomplete without it. Would that be ok for you? It would help me a lot of you would be willing to share a bit more of what your trying to achieve with the models. E.g. what kind of applications/platform for which markets, why usecases etc etc. --- ## Post #15 by @thomas.beale [quote="joostholslag, post:14, topic:2093"] What we can do however is flatten out those inheritances, so that if you export the BP ADL as json (schema)/ OpenAPI that files does have the relevant inherited datapoints like a time and setting. So that you don’t need to know anything about the RM (nor need an openEHR CDR to use it). Would that be what you’re after? [/quote] That is also my suggestion for the simplest export that is still actually useful. --- ## Post #16 by @pablo [quote="ToStupidForOpenEHR, post:1, topic:2093"] I quick review of other posts suggest it takes at least a year of continual study to gain a good understanding of OpenEHR. [/quote] 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. [quote="ToStupidForOpenEHR, post:1, topic:2093"] I know first hand from talking to a number of companies and investors that this learning curve is just too steep, and they walk away from OpenEHR. [/quote] 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. [quote="ToStupidForOpenEHR, post:1, topic:2093"] 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. [/quote] 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: 1. understand your problem(s) 2. contact an expert with real world implementation experience 3. 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. --- ## Post #17 by @borut.jures 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: [quote="joostholslag, post:14, topic:2093"] It would help me a lot of you would be willing to share a bit more of what your trying to achieve with the models. E.g. what kind of applications/platform for which markets, why usecases etc etc. [/quote] [quote="borut.jures, post:11, topic:2093"] So once you have a Blood pressure archetype (or template - which do you plan to use?) in a JSON file, how would you use it? For the backend, frontend, ETL,…? [/quote] --- ## Post #18 by @erik.sundvall @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. --- ## Post #19 by @yampeku 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) --- ## Post #20 by @ian.mcnicoll Here is the blood pressure archetype in Web Template format (stripped out from the parent composition wrapper https://gist.github.com/freshehr/4e31a004b6e5b6a09dd2f648c1c93bfb I think this is currently the easiest approach. The full template, which has to include the parent composition is at https://gist.github.com/freshehr/940e1eb64af0f3c1af16660866429715 and example of how to parse it to an Asciidoc Thx @bna is at https://github.com/freshehr/wt2doc 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. --- ## Post #21 by @ian.mcnicoll 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. --- ## Post #22 by @ToStupidForOpenEHR 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. --- ## Post #23 by @ToStupidForOpenEHR 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) --- ## Post #24 by @ian.mcnicoll [quote="ToStupidForOpenEHR, post:23, topic:2093"] 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) [/quote] That's a perfectly reasonable perspective and doable by all of the CDR products on the market. None are tied to UI generation. --- ## Post #25 by @borut.jures [quote="ToStupidForOpenEHR, post:22, topic:2093"] 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. [/quote] 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](https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html). 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](https://discourse.openehr.org/t/which-aom2-release-are-awb-nedap-using-for-exporting-opt2-to-json/2084/7?u=neoehr) how to approach what you describe: [quote="borut.jures, post:7, topic:2084"] I can read my first OPT2 JSON :partying_face: …and I have to write only a single line of code to do it: ![fromjson-convert](upload://4h7mNyqFmpU8nrxuruPRBy953TS) …everything else is generated from the BMM files. When I started working with openEHR I hoped this could be done. 40 days later I know it can be done. All thanks to the computable specifications. [/quote] 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. --- ## Post #26 by @thomas.beale [quote="ToStupidForOpenEHR, post:22, topic:2093"] 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. [/quote] 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). [quote="ToStupidForOpenEHR, post:22, topic:2093"] If you want to be successful you need to make things easier. [/quote] 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... [quote="ToStupidForOpenEHR, post:23, topic:2093"] This I think is the future, and something OpenEHR could support if it was easier to consume. [/quote] Well, I'd say the CDR API is easier and more standard than the FHIR one (there is no standard FHIR API). [quote="ToStupidForOpenEHR, post:23, topic:2093"] 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 [/quote] 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. --- ## Post #27 by @borut.jures [quote="ToStupidForOpenEHR, post:22, topic:2093"] The budget is decent, around £100m. [/quote] 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. --- ## Post #28 by @ToStupidForOpenEHR They opted for Cerner instead I believe. Was a past client. --- ## Post #29 by @ToStupidForOpenEHR 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." --- ## Post #30 by @borut.jures [quote="ToStupidForOpenEHR, post:29, topic:2093, full:true"] 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.” [/quote] I try to direct this thread in your direction Gary: [quote="borut.jures, post:17, topic:2093"] 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. [/quote] 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. --- ## Post #31 by @ToStupidForOpenEHR 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 ? --- ## Post #32 by @borut.jures [quote="ToStupidForOpenEHR, post:31, topic:2093"] I think follow more of a DDD approach rather than meta-model. [/quote] 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? --- ## Post #33 by @ToStupidForOpenEHR 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#. --- ## Post #34 by @ian.mcnicoll 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. --- ## Post #35 by @borut.jures [quote="ToStupidForOpenEHR, post:33, topic:2093, full:true"] 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#. [/quote] I'm one of the folks that is generating my own "ORM", classes etc. I offered to generate the same for you. In .NET or whichever language you prefer. I took what openEHR offers and did it. It took me 40 days after first finding out that the openEHR exists. I could spend those 40 days complaining it is too hard and complicated and would be where you are today. Stop complaining. Start doing. Ask for help. --- ## Post #36 by @erik.sundvall [quote="ToStupidForOpenEHR, post:28, topic:2093, full:true"] They opted for Cerner instead I believe. Was a past client. [/quote] In that particular case I think the (quite reasonable) question could then be formulated as - should we go for: 1. 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 2. 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. Most other Swedish regions have Cambio Cosmic that used to be of type #1 but is now [piece by piece moving over to #2(b) using openEHR](https://www.cambiogroup.com/digital-technology-can-transform-the-way-that-health-and-care-is-delivered/). (The Cambio case has similarities with what [DIPS](https://www.dips.com/uk/ehealth) in Norway has done and what [TietoEVRY is doing](https://www.tietoevry.com/en/industries/healthcare-and-welfare/healthcare/openehr/).) @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? --- ## Post #37 by @thomas.beale [quote="ToStupidForOpenEHR, post:31, topic:2093"] 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. [/quote] 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. --- ## Post #38 by @ToStupidForOpenEHR The decision is never mine. I'm an independent Enterprise Architect trying to help clients define their target architecture. I have been promoting OpenEHR for 4+ years, trying to help increase the uptake. --- ## Post #39 by @joostholslag 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. --- ## Post #40 by @thomas.beale [quote="joostholslag, post:39, topic:2093"] I’d suggest the opposite, the intend of the author of the topic is to discuss ADL export options [/quote] Either fine - but what we need to work out is: * 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. --- ## Post #41 by @erik.sundvall @ToStupidForOpenEHR Now I found the [thread on Twitter](https://twitter.com/ErikSundvall/status/1463162006291238935), I started in the Discourse end. sorry about possible confusion/sidetracking added. 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](https://discourse.openehr.org/t/separating-models-from-implementation/2093/12) 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.](https://discourse.openehr.org/t/graphical-data-mapping-tools-supporting-openehr/2096) 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. --- ## Post #42 by @ToStupidForOpenEHR Thanks for taking the time to look at this. 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. --- ## Post #43 by @ToStupidForOpenEHR where can I read more on TDS/TSS ? --- ## Post #44 by @joostholslag 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’ https://ckm.openehr.org/ckm/archetypes/1013.1.3574 ![image|467x499](upload://tNgqwvjBkSuMQzkY8u6ZECn1e5t.jpeg) 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? --- ## Post #45 by @pablo 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. --- ## Post #46 by @pablo [quote="ToStupidForOpenEHR, post:22, topic:2093"] 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. [/quote] 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. [quote="ToStupidForOpenEHR, post:22, topic:2093"] If you want to be successful you need to make things easier. [/quote] 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). --- ## Post #47 by @pablo [quote="borut.jures, post:17, topic:2093"] I’m not sure Gary came here for the lectures. [/quote] 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... --- ## Post #48 by @ToStupidForOpenEHR I just read this paper from @thomas.beale https://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf 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 --- ## Post #49 by @thomas.beale [quote="ToStupidForOpenEHR, post:48, topic:2093"] 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) [/quote] Correct. [quote="ToStupidForOpenEHR, post:48, topic:2093"] 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 [/quote] 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? --- ## Post #50 by @yampeku [quote="ToStupidForOpenEHR, post:4, topic:2093"] However, the only representation I can get from the CKM is an export of the ADL…which requires quite a bit of tooling to be able to parse etc [/quote] BTW, just remembered that CKM Rest API actually allows you to get the mindmap directly just by knowing the id For example, for Blood pressure this is the link to the mindmap https://ckm.openehr.org/ckm/rest/v1/archetypes/1013.1.3574/mindmap --- ## Post #51 by @pablo [quote="ToStupidForOpenEHR, post:4, topic:2093"] the only representation I can get from the CKM is an export of the ADL…which requires quite a bit of tooling to be able to parse etc [/quote] As XML or JSON have their parsers, ADL also has it's parsers. The one I use is the Java Ref Impl one (https://github.com/openEHR/java-libs/tree/master/adl-parser), the whole code it's about 10 lines of code, which IMO doesn't classify as "quite a bit of tooling" https://github.com/ppazos/openEHR-ADL/blob/master/src/com/cabolabs/openehr/adl/ArchetypeManager.groovy#L94-L116 I guess your are trying to do something I don't fully understand. --- ## Post #52 by @ian.mcnicoll 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? Ian --- ## Post #53 by @joostholslag @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. --- ## Post #54 by @birger.haarbrandt 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: ![](upload://veJ0JoxBC6xj57BCSAHsjQB7dnI.png) We might think about adding JSON schema in the future if people find it useful --- ## Post #55 by @joostholslag [quote="birger.haarbrandt, post:54, topic:2093"] 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? [/quote] 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. --- ## Post #56 by @birger.haarbrandt Ah, thanks for explaining, this sounds very useful indeed! --- ## Post #57 by @ToStupidForOpenEHR I am happy to collaborate and help where I can in defining what the flattened model should look like. (we need to find a better term than flattened !!) I think we should look to flatten both the two-level (archetype) and three-level (template) models. --- ## Post #58 by @siljelb There probably needs to be some kind of mechanism to specify how much of the optional parts of the RM should be included. For example, reference ranges are very useful for lab results, but maybe not for medication dosages. --- ## Post #59 by @ToStupidForOpenEHR If we take the API approach this should be doable. I think it's important that the clinical modellers review the output, don't want to lose important aspects of the model --- ## Post #60 by @erik.sundvall [quote="ToStupidForOpenEHR, post:57, topic:2093"] I think we should look to flatten both the two-level (archetype) and three-level (template) models. [/quote] Not sure what you mean. * If you mean we'd flatten archetypes+RM without having a containing template things may get pretty confused when implementing since most concrete use cases will need a combination of archetypes (+often template level terminology binding) and when comitting data at least be contained in a COMPOSITION. * If you mean we'd flatten all three levels together then I am with you. The simplest free-statnding and comittable thing would be templates where the root is a COMPOSITION. * A third option - that might be the real modular use case you might be looking for - may be to flatten templates for reusable sub-parts of a COMPOSITION, similar to the [(Glucose/HbA1c) LABORATORY TEST RESULT EXAMPLE](https://ckm.openehr.org/ckm/templates/1013.26.383) template that is made up of several, partly terminology bound, archetypes - in this case rooted in an OBSERVATION. See image below. Perhaps we should then also offer a list with a set of commonly used pre-packaged flattened templates with user guides, e.g. vital signs. ![image|606x500](upload://lP77O6z2TGPvQsbuZabqJjJRota.png) --- ## Post #61 by @erik.sundvall When creating a generator that parses an operational template definition (in OPT, webtemplate or other format) it would likely not be too hard to create both JSON schema and OpenAPI outputs in the process (they have a lot of similarities). Some tools like Altova Mapforce (and perhaps Mirth?) support Json schema and many code generators support openAPI. A quick dirty hack POC version of schema+OpenAPI generator might be drummed up basing code on @bna's web template --> Asciidoc script that @ian.mcnicoll has continued on at [https://github.com/freshehr/wt2doc](https://github.com/freshehr/wt2doc) (mentioned in [post 20 above](https://discourse.openehr.org/t/separating-models-from-implementation/2093/20)) and replace the DocBuilder.ts class etc. A better more properly model based converter may could likely be done fairly quickly by @borut.jures and his nice builder code or by something from @pieterbos & Co at Nedap or somebody else. There could of course be many improved JSON structures to target, but to start with the simplified "structured" JSON that Better, EHRbase and others are using would be good to hav for integration tools that may want to loop over a structure. It's called *structSDT* in [Simplified Data Template (SDT) specification](https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html#_json_formats) and COMPOSITION data instances can be both imported and exported in platforms like Ehrscape, see images below of the non-standardized way: ![image|494x500, 50%](upload://6Ygv1makLjOl2R7Ir1Ff3eOhsY5.png) ![image|400x500, 50%](upload://6ECUaAd2aBBOX7PiIpPQ9x3Agt2.png) If using t[he standardised openEHR REST API](https://specifications.openehr.org/releases/ITS-REST/Release-1.0.2) I hope the same could be accomplished using the string `application/openehr.wt.structured+json` in the http-header `Content-Type` in the requests as described in the [Alternative data formats](https://specifications.openehr.org/releases/ITS-REST/Release-1.0.2/overview.html#header-alternative-data-formats) section of the REST spec overview, when [POSTing and GETting COMPOSITIONS](https://specifications.openehr.org/releases/ITS-REST/Release-1.0.2/ehr.html#composition). How many openEHR implementations support this already - ping @birger.haarbrandt @bna @pieterbos @borut.fabjan @stoffe @Seref and others? --- ## Post #62 by @damoca [quote="ToStupidForOpenEHR, post:57, topic:2093"] we need to find a better term than flattened !! [/quote] Streamlined? [quote="siljelb, post:58, topic:2093, full:true"] There probably needs to be some kind of mechanism to specify how much of the optional parts of the RM should be included. For example, reference ranges are very useful for lab results, but maybe not for medication dosages. [/quote] Existing technology is enough for doing this. GraphQL is a kind of query language for a data exchange API. If we are able to define a streamlined data model that includes every bit of information of the RM, it would be a responsibility of the data consumer to ask for the information or data points they want. I think it is the most flexible approach to deal with the RM extensive metadata plus the variability of archetypes and templates. --- ## Post #63 by @erik.sundvall [quote="damoca, post:62, topic:2093"] GraphQL ... query language ... includes every bit of information of the RM, it would be a responsibility of the data consumer to ask for the information or data points they want. I think it is the most flexible approach. [/quote] I agree that GraphQL would be interesting, but to live up to developer's mental models of it, they (at least the ones here at Karolinska) would likely want to be able to think that there is an active data store behind the scenes where you can pull up a composition and interact with it read+write on a specific field, or on a subtree in chunks, via GraphQL using "simplified" template-specific names + whatever other RM things that are unconstrained/unmentioned by the template. To do that I think a [contribution builder approach](https://discourse.openehr.org/t/contribution-builder-supporting-collaborative-multi-user-multi-device-editing-graphql-operational-transformation/2071) would be good, where either an existing or new blank COMPOSITONs could be instantiated, read and modified and then, when finished, written back. Can we continue GraqphQL-discussion [in that thread](https://discourse.openehr.org/t/contribution-builder-supporting-collaborative-multi-user-multi-device-editing-graphql-operational-transformation/2071)? --- ## Post #64 by @ToStupidForOpenEHR Would that not require the consumer to have some detailed knowledge about how the RM works ? Which is one of the things I am trying to avoid.....just want a concrete (flattened) representation like the Mindmap or Printable version from the ckm --- ## Post #65 by @yampeku You could have predefined queries for specific use cases or roles (e.g. what data is useful for research purposes), as @siljelb, @heather.leslie and @ian.mcnicoll have commented in the past --- ## Post #66 by @joostholslag [quote="ToStupidForOpenEHR, post:64, topic:2093"] Would that not require the consumer to have some detailed knowledge about how the RM works ? Which is one of the things I am trying to avoid [/quote] I think we all share that the export would need to be usable without detailed knowledge of the rm. But anyways there’s the question of how to handle mandatory and optional datapoints. The mandatory datapoint in *archetypes* are used sparsely and should also be hard requirements for the exported model (e.g. a diagnosis without the mandatory name makes no sense and shouldn’t be considered a diagnosis). On the other hand archetypes and the inherited rm attributes can be overwhelming. Could be going to a hundred optional data ‘attributes’ that would make a developer overwhelmed I assume. Templates and/or Graphql could help handle that problem. --- ## Post #67 by @ian.mcnicoll This is the big challenge and applies to FHIR and other info models just as for openEHR. You can't ignore that at some level there is going to have to be some common underlying infrastructure, and enough flexibility on the data models to allow them to be 'finished' differently in differing contexts, including the impact of whether you are using SNOMED CT. So the basic models (archetypes/ resources) simply cannot be locked down at international level. they need to be adaptable and that inevitably means that 'someone' has to take the responsibility of applying the maximum degree of 'interop/coherence' at a more local level., and hiding the more obscure parts of the models, or indeed the sub-structure where they do not apply to a specific local context. And those decisions are what clinician informaticians need to do This is where the flattening process can be very helpful, it allows people like me to use tooling to generate simpler structures that both hide parts of the archetype that need not be visible to the dev, and to make those important parts of the substructure that are not in the archetype, visible to the devs. We can probably come up with a best-guess at what these might be for 'most scenarios' and would give Gary what he wants . To some extent that is exactly what the Ehrscape composition example API call does - it exposes a few RM end-points that are either mandatory or commonly required e.g. participations, subject. So yes, I agree to get maximum benefit this needs to work at template-level and fold in the three layers - if you just want a 'raw archetype' , just create a very simple template with a basic composition, and an unconstrained e.g Blood pressure archetype - export the Web template and use that to generate what ever downstream artefact you want, ignoring the top-level Composition. --- ## Post #68 by @borut.jures [quote="erik.sundvall, post:61, topic:2093"] A better more properly model based converter may could likely be done fairly quickly by @borut.jures and his nice builder code or by something from @pieterbos & Co at Nedap or somebody else. [/quote] Thank you for the kind words about my generator @erik.sundvall . I’ve spent the past few hours writing a generator of OpenAPI schemas. Here is a separate topic with a download link and source code: https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116 --- ## Post #69 by @joostholslag [quote="ian.mcnicoll, post:67, topic:2093"] So yes, I agree to get maximum benefit this needs to work at template-level and fold in the three layers - if you just want a ‘raw archetype’ , just create a very simple template with a basic composition, and an unconstrained e.g Blood pressure archetype - export the Web template and use that to generate what ever downstream artefact you want, ignoring the top-level Composition. [/quote] I'm not in favour of obfuscating the archetype/template distinction with exports. I think it doesn't make sense to offer a very simple template with a basic composition. I think it does however make sense to offer some common usecase e.g. result of a BP measurement as a template (bp observation, result-report composition). And export that as OpenAPI (or json-schema, XML, or webtemplate). But the implementer has to be aware that his implementation has to match the context (actual measured bp of the subject of the 'ehr', not e.g. a target bp) of the template, or stuff will go horribly wrong for that patient. It is fine to not constrain out many of the elements in the bp observation archetype, as we'd normally do, and leave that up to the implementer. But mandatory elements should at least stay mandatory (shouldn't be a problem, BP archetype has none, report-result composition has only very straightforward stuff: e.g. start-time: who would want to record a BP without recording the time of the measurement, that has no value). This would even be very valuable to many openEHR implementers. We all don't think it makes much sense to export only archetypes. Since the implementer will have to supply the context information and this will bring back all the complexity of openEHR. And will realistically never be interoperable with native openEHR. But I also think it's not up to us to keep people from trying. Maybe they come up with something simpler, better, cheaper, faster than openEHR and I'd be all for that. So we should not *block* export of archetypes. But realistic, it is not. So I wouldn't enjoy spending time on helping people, who don't understand the complexity to do this. And I wouldn't want to be responsible for contributing to another ehealth related clinical disaster. --- ## Post #70 by @damoca [quote="ToStupidForOpenEHR, post:64, topic:2093"] Would that not require the consumer to have some detailed knowledge about how the RM works ? [/quote] Not exactly, what I said assumes that we have already solved how to generate that streamlined format (a data structure which directly uses readable data element names extracted from the archetype/template). The only documentation needed to know what it contains would be approximately the one you find in the CKM: ![image|690x413](upload://j1B2JSbZaDMjCC6EgSEWVU4t7va.png) ![image|632x500](upload://fj3erPvC6XnQgJg0dZQqepvEMDd.png) --- ## Post #71 by @ian.mcnicoll Yes - Heather, Sebastian and myself worked to create that list of 'clinically-relevant parts of the RM and would be a good candidate 'defaults' to be folded into the flattened model, although like Silje I would like to be able to override those defaults for a particular use-cases. We do actually have the tags to be able to do that in AOM2/ADL2 - just nor implemented in AD / .opt yet. --- ## Post #72 by @joostholslag I’m curious for that list. --- ## Post #73 by @ian.mcnicoll Each CKM archetype and Element has a Reference model tab with a short list of 'clinical' RM attributes - a bit arbitrary but probably close enough. @sebastian.garde - are you able to share the underlying XML file? --- ## Post #74 by @thomas.beale [quote="ian.mcnicoll, post:71, topic:2093"] Yes - Heather, Sebastian and myself worked to create that list of 'clinically-relevant parts of the RM and would be a good candidate ‘defaults’ to be folded into the flattened model, although like Silje I would like to be able to override those defaults for a particular use-cases. We do actually have the tags to be able to do that in AOM2/ADL2 - just nor implemented in AD / .opt yet [/quote] There are even markers in the RM BMM to indicate which RM attributes are interesting and which really are not - ADL Workbench filters using these and can generate any variant of RM flattening onto a template or archetype. It's easy to put more classifiers like that in BMMs generally. [Example here](https://github.com/openEHR/specifications-ITS-BMM/blob/master/components/RM/Release-1.1.0/openehr_rm_ehr_110.bmm#L332). --- ## Post #75 by @erik.sundvall [quote="ToStupidForOpenEHR, post:43, topic:2093, full:true"] where can I read more on TDS/TSS? [/quote] They are all template-specific "streamlined" things, I belive TD... = Template Data... * TDS ...Schema (XML schema) * TDD ...Document (xml instances adhering to a TDS) * TDO ...Object(s) (Class definitions, used for simplifying programming applications & integrations) The template specific "streamlined" OpenAPI descriptions discussed in this thread could be used to produce the equivalent of TDO in any programming language (I believe TDO from the back then was usually in some .NET format) @heath.frankel is likely the main guru on the topic and was involved in creating TDS/TDD/TDO formats many years ago at Ocean Informatics (now called https://oceanhealthsystems.com/). I believe many of the reasons for their creation were basically the same as the ones @ToStupidForOpenEHR brought up and that started this thread - to make it easier for developers and others to, for a specific use case, integrate/interact with openEHR systems - using familiar tools and without a learing too much about openEHR or openEHR specific tools. When [searching for TDS in the old openEHR mailing list archives](https://www.mail-archive.com/search?q=TDS&l=openehr-technical%40lists.openehr.org) you'll find a lot of the same thoughts as in the current discussion, e.g. in [2008](https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg03394.html) and [2013](https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg07758.html). I believe the main problem regarding adoption was that the TDS/TDD approach was never published as an official specification back then - it was used by Ocean and some of their customers (including Better/Marand for example). In 2016-2017 things had changed and there was a willingness from Ocean to share/publish the approach and create a specification, work was started, see the wiki page https://openehr.atlassian.net/wiki/spaces/spec/pages/30408770/Template+Data+Schema+TDS+Specification+and+associated+Template+Data+Document+TDD but never finished because of peoples' busy schedules. Heath (who was very busy then) sent me some files that I (also busy) never got around to analyze and publish on that wiki page as a basis for further standardisation work. Perhaps it is time to pick that up again and let anybody interested help documenting the approach? @heath.frankel could you attach any files/descriptions for curious people to look at - on that wikipage or in this thread? Others may have more information and links about TDS/TDD/TDO, please share. @Seref may know of current use at Ocean. --- ## Post #76 by @ToStupidForOpenEHR Thanks @erik.sundvall TDS/TDD does look fairly close to what I am suggesting. --- ## Post #77 by @erik.sundvall In order to not kidnap [the thread about @borut.jures's cool generators](https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116) I'll clarify some thoughts here instead, where I believe the core of this discussion fits better. @borut.jures and @thomas.beale I am not sure I explained my point well enough in https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116/9 when refering to @heath.frankel's comment from 2012 on the wiki page https://openehr.atlassian.net/wiki/spaces/spec/pages/4915205/Ocean+EhrGate+-+Composition+Builder+programming+example Yes developers/integrators need to learn *a little bit* about openEHR basics (but not much) if they e.g. have a template-specific use-case that is one of their first tasks to interact with an openEHR system. However it would be great if they did NOT have to switch tooling or start using openEHR-specific path-based ways of interacting with components like the one suggested in the 2012 wiki page or the more elegant/compact `toJson()` method described by @borut.jures in https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116/10 By tools/methods they are already used to, I mean... 1. for **integrators/informaticians** creating and maintaining integrations: low code tools like Altova MapForce or Mirth as described in https://discourse.openehr.org/t/graphical-data-mapping-tools-supporting-openehr/2096 (these tools work best if supplied with a template specific schema with user friendly node names derived from the template labels - TDS is one such approach, a similar way to do JSON schema for the "structured" (JSON tree) simplified format [described as *structSDT* in the end of section 3.2 of a spec](https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html#_json_formats) would also be a great option for such tools 2. for **software developers**: a template-specific litte library of classes with names derived from the template labels. TDO is/was such an approach, template specific openAPI definitions would do the same job in a more modern and programming language-neutral approach. Then they can just generate and import the library/classes and keep using their favourite editor/IDE and get syntax higlighting, auto completion, validation etc based on the template (Instead of string based path/key approaches where errors often are only found at runtime). So it's not that we would try to "hide" everything in openEHR, it's about making the integrator and developer experience more efficient and less error prone. Edit: @Seref pointed out in a recent SEC-meeting that the simplifications in TDOs etc stopped somewhere around the openEHR data-type lower levels, and there reused a generic part for different use-cases/templates. Perhaps @seref or somebody else that is used to working with this could explain further in a few sentences? --- ## Post #78 by @ToStupidForOpenEHR You also have to consider the case that HealthCare providers that I work with e.g. NHS Scotland, NSS, Boards, Trusts across England, NHSx, NHS Wales, eHealth Ireland do not have particularly big or strong development teams, and almost universally work with .NET. So trying to uplift OpenEHR in a primarily JVM based world is a real challenge. It's also very rare for a developer to be allowed to spend time learning a technology without this being part of the strategic roadmap for the provider. This goes right back to my initial point, I want OpenEHR and in particular the models to be widely adopted, but HealthCare providers (boards, trusts etc) are put off by the complexity of OpenEHR, so are not including OpenEHR in their strategic roadmap. I've taken a fair amount of abuse trying to get this point across. It's nothing about me learning OpenEHR that **would not change a thing**. It's about getting someone like NHSx to adopt it strategically across NHS England. Myself and colleagues are pushing OpenEHR on the policy front not only in the UK, but across EMEA and in Australia and NZ. We are trying our best to get OpenEHR adopted. Joost and I had a chat, and we think that OpenAPI is a good way to go. If you want to help then please let us know. Gary --- ## Post #79 by @Seref I'll respond carefully and in case I fail to reflect the history/motivation accurately, @heath.frankel is welcome to correct me. Both the TDS/TDD and TDO approaches were Heath's babies. He's the one who came up with the idea, and the aims were at some level overlapping with what's being discussed here: make it easy for non-openEHR systems/actors to talk to openEHR, make it easy to work with templates for a developer. In case of TDS/TDD, Ocean's template designer produces an XSD from a template, called TDS, and if you can produce an XML file (called TDD) that is valid according to that XSD (schema). This approach dealt with the interoperability requirements of the time neatly. Back then, XML was the dominant ITS for exchange, and an XSD and an XML file did not take much explaining. Sure, XSD could not express all the constraints expressed by a template, but it was a good balance between stopping openEHR leaking to non-openEHR world and validation at source. When TDD(XML) arrives at Ocean land, it is transformed to a canonical Composition XML, then deserialised to RM and validated. Ocean template designer is still freely available after all these years, so you can play with it. The transformation to canonical XML is done via XSLT but I'm not sure if we made that available publicly. The slight problem with TDSs is, they're fully self contained. As in, each XSD creates its own little type universe, and with xml namespacing etc, two DV_TEXTs in two XML files end up having different XML types from two different schemas. Not a real problem because a TDS is meant to be a messaging artefact, but in the context of conversation going on here, it is something to keep in mind. Actually, the openEHR SDK from EhrBase had the same behaviour (or I think it did): it generates a set of Java artefacts from models and same RM types end up with duplicate, yet technically different representations in generated code, because they're based on different opts. Again, corrections are welcome. A TDO is actual C# source code, generated from templates, and it allows a developer to populate data using the names/concepts as they're used in the template. This makes a big difference in terms of productivity, but Heath was concerned about various software engineering aspects of using TDOs so he was not entirely enthusiastic about using them, and I disagreed :) If my memory is correct, when they started using openEHR based on the Ocean platform, Marand (Better now) even produced Java TDOs and used them for a while. Happy to be corrected on this if my memory is wrong. The tricky bit with TDOs was that they required code to go from the TDO type to a canonical RM composition, which is what's done with XSLT in TDS scenario, and that functionality was not convenient for us to distribute as a library, though at some point around 2014 or so I remember doing it for a partner in an Australian project. As of today, we have TDOs in our production code, I'm pretty sure of that, and one or more of our integration endpoints may be using TDSs; this I'd need to ask Chunlan Ma, who's the queen of openEHR implementation :) So as you can see, the idea of isolating (which I prefer to separating as a term) openEHR from the non-specialised developers is something we've been experimenting with and doing in different ways for some time. I personally think it is a very good idea, and the eco-system of today provides a lot more options than the time Ocean did TDS/TDD: that's the thing with arriving too early, there's nothing around for you to leverage... This thread has enough disagreements without me pouring gasoline over it, so I'll keep my specific opinions to myself, but as someone who does this for a living, I see a worrying gap between off the shelf developers and their practices and what we're doing. Yes, we're taking steps, but there's a long way to go and I see lots of good ideas being exchanged, so hopefully we'll do better come this time next year. --- ## Post #80 by @thomas.beale [quote="ToStupidForOpenEHR, post:78, topic:2093"] This goes right back to my initial point, I want OpenEHR and in particular the models to be widely adopted, but HealthCare providers (boards, trusts etc) are put off by the complexity of OpenEHR, so are not including OpenEHR in their strategic roadmap [/quote] Right - but one has to ask - do they even realise the problem they need to solve is fundamentally complex? If they don't, then there's nothing to say, they will fail, guaranteed. But if they do, really, they need to hire proper engineers and developers to do some core work, e.g. deploy the platform, learn the platform API, and how to do a few things with templates. If they don't want to even do this, and the current employees simply want an easy ride with everything so 'simple' they don't have to do any work, well then I am afraid there is no path to success. They will continue to fail as they have been for decades, apart from a couple of centres of excellence like Marsden (Jo Milan). I hate to re-iterate the question of complexity, but it will not go away by complaining about it. If NHS trusts cannot realise what kind of problem they are solving, they have *no route to success. None*. Now, there is no doubt that we have not quite arrived at the optimal point of application development today - the things that @erik.sundvall and others are talking about (and web templates, created by Better, TDS etc by Ocean in the past) are needed, in an updated form. (As you can see, there is furious activity in this area). BUT. If the NHS wants to be serious, it needs to invest in this phase of technology development. Unlike the millions they waste on closed source EMR systems that don't work, every penny they spend on openEHR is public IP and costs nothing once developed (other than the cost of maintenance obviously). The central question is: **are they serious?** It's not a technology question. It's an organisational question. --- ## Post #81 by @thomas.beale [quote="ToStupidForOpenEHR, post:78, topic:2093"] We are trying our best to get OpenEHR adopted. Joost and I had a chat, and we think that OpenAPI is a good way to go. If you want to help then please let us know. [/quote] 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. --- ## Post #82 by @ToStupidForOpenEHR 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) --- ## Post #83 by @erik.sundvall Thanks for a wonderfully informative post @seref. [quote="thomas.beale, post:80, topic:2093"] they need to hire proper engineers and developers to do some core work, e.g. deploy the platform, learn the platform API [...] BUT. If the NHS wants to be serious, it needs to invest in this phase of technology development. Unlike the millions they waste on closed source EMR systems that don’t work [/quote] @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: 1. true success stories of openEHR adoption in similar/peer organisations 2. 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. 3. 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. --- ## Post #84 by @erik.sundvall Edit: Moved this post here from the thread https://discourse.openehr.org/t/openapi-schemas-generated-from-bmm-files/2116/21 [quote="ToStupidForOpenEHR, post:20, topic:2116"] We think the future is going to see EPR’s broken up into several specialised app’s working across fairly fixed domains. An app for dementia, and app for joint replacements. Ecosystem is the buzz word they usually use. [/quote] [quote="thomas.beale, post:21, topic:2116"] I’ll just go out on a limb and say there are no fixed domains :wink: [...] Everything changes, all the time… [/quote] @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](https://www.highmed.org/) 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: ![image|690x301](upload://fK2njrrtLtcKNVlvK9u9WuYEd5e.png) and ![image|690x369](upload://2O3BWtPhCUSRhFnmI5aJAF7tb5U.png) 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. --- ## Post #85 by @birger.haarbrandt [quote="erik.sundvall, post:84, topic:2093"] 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](https://www.highmed.org/) has procured openEHR based CDRs and informatics work (right @birger.haarbrandt?). [/quote] 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. --- ## Post #86 by @DavidIngram 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! --- ## Post #87 by @ToStupidForOpenEHR [quote="erik.sundvall, post:83, topic:2093"] @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 [/quote] 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. --- ## Post #88 by @ToStupidForOpenEHR [quote="erik.sundvall, post:83, topic:2093"] 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. [/quote] Correct. I am now of the opinion after talking to some of our prominent modellers that the multi-level approach is correct for designing models. --- ## Post #89 by @Seref [quote="erik.sundvall, post:83, topic:2093"] 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. [/quote] 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. --- ## Post #90 by @birger.haarbrandt 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 --- ## Post #91 by @yampeku [quote="birger.haarbrandt, post:90, topic:2093"] this as an onion model [/quote] I'm assuming it is also in the sense that you cry more for each layer you remove :rofl: --- ## Post #92 by @ian.mcnicoll >> 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. --- ## Post #93 by @erik.sundvall [quote="ToStupidForOpenEHR, post:87, topic:2093"] [quote="erik.sundvall, post:83, topic:2093"] ...decision makers and their advisors, architects etc. want to feel **safe** ... [/quote] 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. [/quote] And this is where I wish the CIO would also have called experienced openEHR provider(group)s as I explained in post 36: https://discourse.openehr.org/t/separating-models-from-implementation/2093/36 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.) --- ## Post #94 by @thomas.beale [quote="erik.sundvall, post:83, topic:2093"] 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 [/quote] 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... [quote="erik.sundvall, post:83, topic:2093"] 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 [/quote] 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. [quote="erik.sundvall, post:84, topic:2093"] @martin.grundberg at Cambio (Karolinska’s current main openEHR CDR provider) expressed this in a good way in two pictures: [/quote] 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. [quote="ToStupidForOpenEHR, post:87, topic:2093"] 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. [/quote] 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. [quote="Seref, post:89, topic:2093"] 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 [/quote] 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. [quote="erik.sundvall, post:93, topic:2093"] 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. [/quote] Unfortunately that is unlikely, just for reasons of market psychology, though not impossible. [quote="erik.sundvall, post:93, topic:2093"] That would likely be more convincing than telling the trusts/regions to staff up and take full responsibility themselves [/quote] Which is why we shouldn't do that. --- ## Post #95 by @ian.mcnicoll [quote="thomas.beale, post:94, topic:2093"] THat’s why the solution isn’t to actually try to do this new kind of work *initially* in trusts [/quote] 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. --- ## Post #96 by @ian.mcnicoll 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' ![image|690x393](upload://hHQzWyKmfujj55qytNM5ndJhgTk.jpeg) 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. --- ## Post #97 by @DavidIngram [quote="yampeku, post:91, topic:2093, full:true"] [quote="birger.haarbrandt, post:90, topic:2093"] this as an onion model [/quote] I’m assuming it is also in the sense that you cry more for each layer you remove :rofl: [/quote] https://discourse.openehr.org/t/separating-models-from-implementation/2093/89#:~:text=birger.haarbrandt%3A-,this%20as%20an%20onion%20model,sense%20that%20you%20cry%20more%20for%20each%20layer%20you%20remove,-4 https://en.wikipedia.org/wiki/Tower_of_Babel_(M._C._Escher) 😅 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. --- ## Post #98 by @thomas.beale [quote="ian.mcnicoll, post:95, topic:2093"] 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). [/quote] 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. [quote="ian.mcnicoll, post:95, topic:2093"] 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. [/quote] 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... [quote="ian.mcnicoll, post:95, topic:2093"] So oddly, it is really the Trusts who are leading, not the centre, at least in England [/quote] 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. [quote="ian.mcnicoll, post:96, topic:2093"] and BTW - the very worst place to start with openEHR (IMO) is in competing with a Cerner or Epic, in the megasuite EPR space [/quote] Could not agree more. --- ## Post #99 by @DavidIngram [quote="thomas.beale, post:94, topic:2093"] 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. [/quote] 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! --- ## Post #100 by @borut.jures 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](https://neoehr.com/openehr/graphql): - 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". https://discourse.openehr.org/t/generating-graphql-from-opts/2144 --- ## Post #101 by @erik.sundvall [quote="borut.jures, post:100, topic:2093"] 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. [/quote] 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](https://discourse.openehr.org/t/graphical-data-mapping-tools-supporting-openehr/2096/5)) 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](https://discourse.openehr.org/t/generating-graphql-from-opts/2144/2). *) 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. --- ## Post #102 by @borut.jures [quote="erik.sundvall, post:101, topic:2093"] 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. [/quote] Nothing scales as good as computers generating the converters/code/applications :blush: --- ## Post #103 by @borut.jures Here is a sample of simplified code working with blood pressure template: ![750d28d8c7b2ff1b9fb8931f71a06b42eb341912_2_1380x914|690x457](upload://oc3SfZpvbRxJQnlG8FavvsSSt8z.png) More in [this answer](https://discourse.openehr.org/t/contribution-builder-supporting-collaborative-multi-user-multi-device-editing-graphql-operational-transformation/2071/4). More about the generator's code in [this answer](https://discourse.openehr.org/t/generating-graphql-from-opts/2144/5). It takes only a few lines and the generator can output code in TypeScript, C#, Kotlin,… --- ## Post #104 by @bna [quote="erik.sundvall, post:101, topic:2093"] 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](https://discourse.openehr.org/t/graphical-data-mapping-tools-supporting-openehr/2096/5)) and corresponding bi-directional format-converters (converting data instances bidirectionally between simplified and canonical openEHR formats). [/quote] 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 : https://github.com/bjornna/kremt-examples/tree/main/xslt They are not using this. They map the canonical xml using Altova. --- ## Post #105 by @birger.haarbrandt [quote="bna, post:104, topic:2093"] They are not using this. They map the canonical xml using Altova. [/quote] Sounds painful --- ## Post #106 by @bna [quote="birger.haarbrandt, post:105, topic:2093"] Sounds painful [/quote] 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. --- ## Post #107 by @thomas.beale Just out of curiosity: I guess the notation `..data = ...` is a kind of builder pattern in Dart? Why the double dots? --- ## Post #108 by @borut.jures Yes. It is called "Cascade notation". Since I had to look-up the name, here is the link with explanation and examples: [cascade notation](https://dart.dev/guides/language/language-tour#cascade-notation) The main difference in my example is for "data" and "protocol". With double dots I didn't have to repeat "bloodPressure" twice: ```Dart var bloodPressure = BloodPressure(); <= there is an implicit "new" bloodPressure.data = BloodPressureData(); bloodPressure.data.history = BloorPressureDataHistory(); bloodPressure.data.history.events = [BloorPressureDataHistoryEvent()]; ... bloodPressure.protocol = BloodPressureProtocol(); ``` --- **Canonical:** https://discourse.openehr.org/t/separating-models-from-implementation/2093 **Original content:** https://discourse.openehr.org/t/separating-models-from-implementation/2093