# What happens once the Pulse/Heart beat archetype is replaced? **Category:** [Platform](https://discourse.openehr.org/c/platform-implem/7) **Created:** 2025-09-26 16:36 UTC **Views:** 352 **Replies:** 48 **URL:** https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434 --- ## Post #1 by @borut.jures Today @siljelb commented on the Pulse/heart beat archetype: [quote="siljelb, post:2, topic:11431"] The Pulse/heart beat archetype has a long and painful history, and there is a certain reluctance to touch it at all for fear of opening new cans of worms [/quote] And previous discussion: https://discourse.openehr.org/t/pulse-and-heart-beat-conundrum/4692 Can we use this as an example to prepare for similar breaking changes when an archetype is significantly refactored including cases when a single archetype is replaced by two or more archetypes? - Is there a written protocol for such a change? - Do the existing CDRs support such a change? - Are there tools for automating such a change in the existing AQL queries? - Are there recommendations for handling such changes outside the CDRs? For example forms, mappings, analytics,... - Anybody has experience performing such a change? And the changes don’t come from the clinical modelers only: - A similar scenario can be a result of somebody who is still in kindergarten today and will some day implement new (breaking) RM ideas. The data stored today, is supposed to be migrated to the new RM version. - I expected that openEHR would be able to handle a change from `at-codes` to `id-codes` introduced with ADL2, but it was decided not to open that can of worms either. These scenarios could be a good exercise for big breaking changes expected in the future which involve a lot of data and related AQL queries. The reasoning for not updating the existing data upfront was the time it would take in production CDRs (something confirmed by @Sidharth_Ramesh in another thread). It would also require custom migration code for each CDR. More data is stored on a daily basis. Can we proactively address the bottlenecks that forced us to make compromises in the past? Please don't read this as a critique of the existing CDRs. They are all huge achievements by a very smart group of early adopters. Given enough time, they will easily implement the necessary features. I would just like to see that we prepare in advance. --- ## Post #2 by @Sidharth_Ramesh [quote="borut.jures, post:1, topic:11434"] * I expected that openEHR would be able to handle a change from `at-codes` to `id-codes` introduced with ADL2, but it was decided not to open that can of worms either. [/quote] I remember there being a lot of pushback from the implementors because the change was really hard to accommodate with the existing data (with `at-codes`) in their databases. And all existing AQL would not function correctly. This pattern seems to be consistent with archetype and template upgrades, but is moved to the “user space”. @Bostjan_Lah @birger.haarbrandt might be the right people to also include here. --- ## Post #3 by @birger.haarbrandt Hi Borut, I won’t comment too much on the breaking changes on archetype level. We have clear semantic versioning approach and then it’s always the decision to migrate data or treat new data differently. We do this as part of SLAs as any other vendor. What make me curious is why some people in the community are so keen on introducing breaking changes to the RM. Just look at the HUGE problems FHIR has by introducing breaking changes across versions. As a consequence, whole countries are stuck on different FHIR versions. The promise of the RM is to be stable. Backward-compatibility is a huge value when we talk about **data for life**. That’s a big plus for technologies like Java. There is beauty in the fact that I can run my 20 years old java program on a recent JVM version and that I can still upload a template I did in 2013 into my openEHR server and tools, and everything just works. In my opinion, there is so much opportunity to improve the ecosystem, also with new specs (e.g. expanding the use of archetypes to ERP data as proposed by @thomas.beale ), without breaking stuff that is not supposed to break. While there are aspects to the RM that is are a bit clunky, like the at-codes, it would not justify in my opinion introducing such breaking changes. And of course there would be migration paths, but that would be a high price to pay for anyone doing real-world systems and the improvement must be so substantial that it’s hard to argue against it. --- ## Post #4 by @borut.jures In my experience from the ERP world the SLAs also included the promise of migrating data. However the catch was that this would be done for a fee. When clients asked for the migration, the vendors quoted such a high fee, that they never needed to implement the migration (which was their goal). Customers weren’t happy. Are there documented protocols what must be done if the customers decide to “treat the data differently”? I remember Joost explaining how dangerous it is to forget to update all the AQL queries to also include the new major versions of the archetypes. The required AQL changes must also be communicated to the outside users of the data. Is there a checklist for such scenarios? I’m sure the current RM is the best possible one based on the ideas Thomas and others had during the 15 years (2005-2020). We also know that Thomas created an improved version of RM based on further input and an opportunity to make braking changes. Are we OK that any similar attempts to improve RM will not be accepted? I’m afraid that a small group of (technical) people could always provide arguments that migrating data is not the best option. This might not be in the best interest of the customers. They might end up in a similar situation as with the current large EMRs where their requests are not implemented by the vendor. I believe that openEHR should specify the protocols for migrating data in case of new major versions of archetypes. It should also document how to handle any changes to the AQL queries and related systems. I propose that we take an archetype like Pulse/Heart beat and work through a migration as a test. The experience would then be used to document the findings. --- ## Post #5 by @pablo I really don't understand the issue with breaking changes. Data will always comply with a version of the archetype, and what's important is that: having data that complies with an archetype, and not that the data should comply with the last version of the archetype. My take is: make the changes if they are needed and fundamented by a requirement, though keep track of what was changed and provide, if possible, mappings between previous and new version. Apps, CDRs, etc. don't need to do anything if that happens, we will need to do something if , and only if, we want to migrate the data to the new archetype, while, in the mean time, we continue to work with the previous archetypes normality. This is a fear I see everywhere in openEHR, in the archetypes, in the RM and AOM models, in the serialization formats, etc. and it doesn't need to be that way: your software and data will always be compliant with some version of those elements and that's ok! --- ## Post #6 by @borut.jures Clinical modelers were discussing how a “small” change to an archetype can require changing its major version. I understood that there is no significant change to the data so migrating data from v1 to v2 archetype would be “easy”. I’m asking what needs to happen from a CDR perspective, to enable such migration for the customer? * Does a CDR vendor write a case-by-case migration script? * Can a vendor promise such a migration but demand a high fee for it? I understand that the data can be left using different major versions of an archetype in the CDR. However this means a significant effort to update the AQLs. For the “small” change to the data from the previous paragraph it would be better to do the migration of the “old” archetype data to the “new” one and keep the AQL queries the same. Maybe even this will require a change in the archetype version used by the AQL queries (but at least if they are not updated, they will return empty results since there will be no data for the “old” archetype anymore). Do we have tools to enable such changes to the AQL queries? [quote="pablo, post:5, topic:11434"] your software and data will always be compliant with some version of those elements and that’s ok! [/quote] That is technically true, but it might not be what the customers want. What I’m saying is that the decision whether to migrate data upfront or not should be made by each customer and CDRs would have to offer that option to be considered openEHR compliant. --- ## Post #7 by @borut.jures [quote="Sidharth_Ramesh, post:2, topic:11434"] This pattern seems to be consistent with archetype and template upgrades, but is moved to the “user space”. [/quote] This means that clinical modelers will try not to upgrade the archetypes even when they know they are not “optimal” and that they could provide a better one. --- ## Post #8 by @ian.mcnicoll Not at all. Where we are helping manage CDR content on behalf of a client, and generally at the start of a new phase of development, we would always advise where the may be an opportunity to update to the latest revision of an archetype, with an estimate of the impact/value of making the change, including probably some cost/potential downtime from the CDR supplier to do some sort of conversion of archetype breaking changes. In many cases, there is not a compelling case for an immediate update, especially for breaking changes, and we think it is perfectly reasonable for clients to delay those changes until the case of change is compelling - a good example would be that I suspect most people are still using the V1 allergy archetype but before long the commitment to IPS and DHI-Connect being built against the v2 archetype, makes that change much more valuable. I would love to have tooling that would help make those decisions, and for the ‘conversion scripts’ to be more self-service e.g via an API service call - at a very dumb level that could just work against the current REST API at logical level, but I can imagine that some CDR vendors might be able to make it work more directly at the physical DB level under the hood. I think the main message is that commitment to the most recent version of any archetype needs to be very fluid for any given implementation - even minor revisions can have a very significant clinical safety impact, esp. if valuesets change, and none of this is unique to openEHR - it is simply a facet of standards-based system development. --- ## Post #9 by @ian.mcnicoll [quote="borut.jures, post:6, topic:11434"] What I’m saying is that the decision whether to migrate data upfront or not should be made by each customer and CDRs would have to offer that option to be considered openEHR compliant. [/quote] Completely agree and certainly in the projects we are working with, that is the case. As I said, I think it would help to put migration behind a service layer, preferably with self-service mapping, even if there is still some cost from the vendor, and possibly some down time. Vendors can compete on cost/down-time. --- ## Post #10 by @ian.mcnicoll [quote="Sidharth_Ramesh, post:2, topic:11434"] I remember there being a lot of pushback from the implementors because the change was really hard to accommodate with the existing data (with `at-codes`) in their databases. And all existing AQL would not function correctly. [/quote] Without wishing to re-visit ‘ADL2 wars!’, it was a little more complex than just atCodes being re-labelled as idCodes - the numbering mechanism changed in quite a tricky way. A lot of us had real concerns about potential safety issues/ The impact would have been to require not just a massive bulk rewrite of all compositions but to check and change every AQL statement or other path reference. CDR vendors would have faced pushback from clients, asking why do we need this potential disruption. And, most importantly , this would all have held up ADL2 adoption and all the really nice improvements that ADL2 brings. I suspect most CDR vendors would have stuck with ADL1.4 idCodes were ‘better’ from clean-room prespective but not criitcla tothe way ADL2 works and atCodes were not really causing an issue. So this was a pragmatic decision - drop a ‘nice’ but hugely disruptive change, so that we can get ADL2 over the line. I should also give credit to SEC colleagues and, in particular the CDR implementers for figuring out the way forward --- ## Post #11 by @borut.jures [quote="ian.mcnicoll, post:8, topic:11434"] I would love to have tooling that would help make those decisions, and for the ‘conversion scripts’ to be more self-service e.g via an API service call - at a very dumb level that could just work against the current REST API at logical level [/quote] I expect we need 3 tools: 1. `FHIR` to `openEHR` converters could be used for migrating archetype data to a newer version (adding support for **openEHR** to **openEHR** mapping). Mapping rules would be CDR independent. Ideally mapping would be automated via a diff algorithm. 2. Updating AQL should also be possible and would be CDR independent. 3. @thomas.beale has experience with RM1 to RM2 conversion at the archetype level. Technically archetype conversion to an RM with breaking changes is already solved and tested in practice. The first 2 are something that would be useful today. I have the tools for #1 and #3. I’ll look into #2. Tools for migrating data could be CDR independent by using openEHR API. However this might not be an option based on Sidharth's comment in another thread (due to the long time it would take). --- ## Post #13 by @siljelb [quote="borut.jures, post:7, topic:11434"] This means that clinical modelers will try not to upgrade the archetypes even when they know they are not “optimal” and that they could provide a better one. [/quote] While we do think twice before performing a breaking change, we certainly do it when it’s warranted. Otherwise we’d have zero archetypes >v1, while in reality about 10% of published archetypes are v2 (24) or v3 (1). Edit: Specifically about the Pulse/Heart beat archetype though: The reason why we’re reluctant to touch it is that it’s an extremely finicky concept, and most of proposed changes over several years have turned out to be wrong. Not because of potential breaking changes, but because it hurts my brain 🧠⚡😵‍💫 --- ## Post #14 by @borut.jures @siljelb Do you know how those 24 changes to v2 were handled? - Was v1 data migrated? Why or why not? In case the v1 data was migrated: - How long did it take? - Was there any downtime? - Was it done via API or did the vendor use internal tools/scripts? - How were AQL queries affected/changed? - Was there a tool to list all the affected queries related to v1 to v2 change? - Was there a tool to update AQL queries? - Did the changes need the involvement of the vendor or was the customer able to perform changes independently? It would be great to document such changes. --- ## Post #15 by @siljelb No idea, that’s up to implementers and not part of archetype governance :woman_shrugging: From my point of view as a lowcode developer though, we live well with multiple versions of an archetype in the same CDR. We do have to make sure AQL queries take this into account though. --- ## Post #16 by @thomas.beale that's correct. It's just that AQL queries are brittle over these changes, if some data point moves in the path structure from v1 to v2. The future of dealing with that is coding all archetype nodes with an 'is-about' code, which will not change for the same data point, no matter where it moves over major version upgrades. These 'is-about' codes come from an ontology that needs to be created. It's actually two levels; an information ontology and regular real world ontologies like FMA. AQL queries using them will no longer break for that reason. THere could always be breaks for some other reason of course. This is-about coding is a major necessity for the next generation of openEHR and similar technologies. --- ## Post #17 by @birger.haarbrandt From my understanding, the nice thing is that this is likely mostly a governance topic. We can already query on element level inside AQL but we miss this consistent use of terminologies for element names. Of course we can always argue if this metadata needs to be available within each single data instance. Overall, I believe this would be a very good next step for openEHR. --- ## Post #18 by @pablo [quote="borut.jures, post:6, topic:11434"] [quote="pablo, post:5, topic:11434"] your software and data will always be compliant with some version of those elements and that’s ok! [/quote] That is technically true, but it might not be what the customers want. What I’m saying is that the decision whether to migrate data upfront or not should be made by each customer and CDRs would have to offer that option to be considered openEHR compliant. [/quote] The decision should be really part of a contract, and vendors should do whatever the signed to do. Signing that doesn’t mean the system is not openEHR compliant, since compliance/conformance doesn’t have anything to do with data migration, so in this case is about compliance with the contract, not with the specs. In terms of compliance/conformance with the specs, including RM, AOM, archetypes, templates and term sets, as long as a spec is “active”, the implementation is compliant, even if the implementation doesn’t have the latest versions of everything, which practically is impossible: implementations will always have some inertia related to updating to the last versions of those items. My point is that we might be dragging a lot of things that can be fixed, improved and make simpler just because we fear breaking stuff. Consider a really dumb case: ITEM_STRUCTURE. Today we know almost nobody us using LIST, TABLE and SINGLE, from modelers to implementers most just focus on ITEM_TREE, though we have the other types there, making the RM more complex without adding any value (all structures can be just a mix of CLUSTER and ELEMENT), but nobody is touching the RM, though a clear migration path is really simple in that case. [quote="birger.haarbrandt, post:3, topic:11434"] What make me curious is why some people in the community are so keen on introducing breaking changes to the RM. Just look at the HUGE problems FHIR has by introducing breaking changes across versions. As a consequence, whole countries are stuck on different FHIR versions. [/quote] That made me think a lot. IMHO the only case where a breaking change should be introduced is if there is really value on it, like fixing an issue, improving some aspect or simplifying things. If all the formal processes of reviewing requirements make sense and the SEC is in agreement, then I don’t see why a breaking change shouldn’t be introduced. That’s not being keen to introduce breaking changes, is just doing it when it makes sense (like simplifying the ITEM_STRUCTURE model). On the other hand the FHIR example I think it has more to it. I totally agree on some implementations being stuck in some FHIR version, though I don’t think it’s completely because of breaking changes. There is also the miscalculation of the effort to implement FHIR and that the investment done didn’t have the expected ROI. I mean: the promise is the 80/20 but with extensions, profiling, custom operations, etc. the result is 20/80 (80% done by the vendor), so if after all the effort, time and money invested there is a new version of FHIR, even if the version would have been completely backwards compatible, I doubt a company would embark in a major update without some return of the initial investment. Then I think not being backwards compatible makes the update less attractive, because companies are more cautious once they know the real cost of implementing FHIR. On the other hand if tomorrow we have, let’s say, a RM v2.0 that shouldn’t be an issue for current vendors, but it’s an opportunity for new vendors that can get a simpler/better RM, though there should be a clear migration path in place, without a migration path we can cause a lot of problems for vendors. --- ## Post #19 by @thomas.beale [quote="pablo, post:18, topic:11434"] [quote="birger.haarbrandt, post:3, topic:11434"] What make me curious is why some people in the community are so keen on introducing breaking changes to the RM. Just look at the HUGE problems FHIR has by introducing breaking changes across versions. As a consequence, whole countries are stuck on different FHIR versions. [/quote] [/quote] Well, we have a list of things that need to be fixed, that can only be made via breaking changes. Doing an openEHRv2 should be considered a once in 20 event, not the continual rollout of breakages in FHIR. In openEHR (as you know;) the RM is carefully *designed*, not ad hoc committee produced, and the v1 form (i.e. today’s RM) has withstood needs for 15 years. The next generation (with which I and @borut.jures have some experience in an experimental form, during my time in the US) really does bring worthwhile improvements. Actually engineering it requires an openEHRv1 to v2 data bridge, and to do that, v1 → v2 archetype conversion. We proved that that could work, and it enables reliable data conversion. Even with the best of designs, there will be the need to migrate the data. --- ## Post #20 by @damoca [quote="thomas.beale, post:16, topic:11434"] The future of dealing with that is coding all archetype nodes with an ‘is-about’ code, which will not change for the same data point, no matter where it moves over major version upgrades. [/quote] This. I have been saying this for years. Real semantic interoperability (both within and across systems) will come when we stop searching or filtering by paths and start searching for concepts. And we need to pay more attention to the semantic bindings of the archetypes to do so. --- ## Post #21 by @borut.jures Thomas and the rest of the team at Graphite showed me the beauty of full semantic bindings of the archetypes. I remember that 100s (or was it 1000s?) of new LOINC codes needed to be created but the end result was worth it. Mapping data and generating synthetic data was completely path-less. I cannot bring myself to publish openEHR synthetic data generator since it would need to use AQL paths. Consider how a formula for clinically relevant data looks like when using semantic bindings: ```js # Formulas rules: # LOINC based formulas loinc: # Heart rate 8867-4: uri: http://loinc.org/8867-4 name: Heart rate set: - attribute: value element: value_interval: 40..130 ``` The formula is picked up and used for any element in any archetype with heart rate. More complex formulas can be viewed at https://mapehr.com/docs/synthetic-data/ An even better consequence of using semantic bindings in the archetypes would be when interoperability is needed. I would expect that most data exchange would be seamless without manually writing mapping files. FHIR is already [using them](https://mapehr.com/docs/introduction/#fhir-source-file): ``` systolic_loinc: http://loinc.org/8480-6 diastolic_loinc: http://loinc.org/8462-4 systolic_snomed: http://snomed.info/id/271649006 diastolic_snomed: http://snomed.info/id/271650006 ``` openEHR archetype without term mappings to the same codes prevents the automated data mapping. If the blood pressure archetype was LOINC/SNOMED coded then all the mappings below could be automated: ```js - path: /data[id2|History|]/events[id7|Any event|]/data[id4|Data|]/items elements: systolic: value_type: DV_QUANTITY diastolic: value_type: DV_QUANTITY clinical_interpretation: value_type: DV_CODED_TEXT formats: fhir: - attribute: component path: code.coding.code elements: systolic: one_of: - systolic_loinc - systolic_snomed diastolic: one_of: - diastolic_loinc - attribute: interpretation path: coding.system elements: clinical_interpretation: one_of: - clinical_interpretation_hl7 define: systolic: id5|Systolic| diastolic: id6|Diastolic| clinical_interpretation: id1060|Clinical interpretation| systolic_loinc: http://loinc.org/8480-6 diastolic_loinc: http://loinc.org/8462-4 systolic_snomed: http://snomed.info/id/271649006 diastolic_snomed: http://snomed.info/id/271650006 clinical_interpretation_hl7: http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation ``` Current version of ADL already supports this. Licensing prevented adding term mappings but I believe this is now solved. We just need to add them to the archetypes ( which is a huge effort involving terminology specialists working with clinical modelers). --- ## Post #22 by @linforest @borut.jures Awesome! And how to deal with [Observation.referenceRange](https://hl7.org/fhir/R4/observation-definitions.html#Observation.referenceRange) with Cardinality 0..\* and its various subelements? For example, lab-specific reference ranges rather than generic ones. ![image|690x147](upload://tgil7qFKhlLTmgJ5xOxT8V6yq2x.png) --- ## Post #23 by @borut.jures Thank you @linforest ! The US project had some 3000 lab archetypes. Synthetic data was generated using [relevant reference ranges](https://mapehr.com/docs/synthetic-data/#set-a-value-for-elementvalue---multiple-units) (see `interpretation_intervals` below): ```js # Formulas rules: # LOINC based formulas loinc: # Body temperature 8310-5: uri: http://loinc.org/8310-5 name: Body temperature set: - attribute: value element: value_intervals: deg_C_snomed: 35.0..38.9 deg_F_snomed: 90.0..102.0 interpretation_intervals: deg_C_snomed: low: 36.1 high: 38.0 deg_F_snomed: low: 96.98 high: 100.4 ``` --- ## Post #24 by @linforest BTW, this yaml syntax reminds me of the [FSH language](https://hl7.org/fhir/uv/shorthand/) for FHIR. --- ## Post #25 by @siljelb The “is-about” mappings per leaf node as mentioned by @thomas.beale and exemplified by @borut.jures make a lot of sense, and I agree they could help future-proof some AQL queries where the full intra-template context isn’t relevant. But there’s also the risk of making modelling completely untenable, if it’s dependent on some external terminology over which modellers have little or no direct control. I’ve taken part in some efforts to map archetype nodes to SNOMED CT terms. Even when you’d think mapping should be easy, such as the main quantity nodes of vital signs, there are nuances between the intended semantics of the archetype nodes and the semantics of the SNOMED terms. This leads to year long discussions and endless processes to introduce new terms, and it’s a complete and utter nightmare. --- ## Post #26 by @borut.jures [quote="siljelb, post:25, topic:11434"] This leads to year long discussions and endless processes to introduce new terms, and it’s a complete and utter nightmare. [/quote] I completely agree about the nightmare part, but it would make the data truly interoperable. Imagine openEHR archetypes with “is-about”. Archetypes would be a gold standard even if openEHR is not used. --- ## Post #27 by @siljelb [quote="borut.jures, post:26, topic:11434"] Imagine openEHR archetypes with “is-about”. Archetypes would be a gold standard even if openEHR is not used. [/quote] Maybe? But I’m not sure anyone would want to model them? I certainly wouldn’t, after my previous experiences. --- ## Post #28 by @ian.mcnicoll I share your views on this @siljelb There is most certainly added value in adding external reference bindings to key archetype nodes, but there are indeed real challenges in selecting/agreeing the correct terminology, especially when the context can change subtly depending on both the parent archetype and the template. Trying to invest all of that complexity in terminology (post-coordination) ends up being impossible to manage. So yes, let’s take advantage of the developments in LOINC/SNOMED but it is absolutely not a panacea - path-based querying remains very, very helpful IMO. --- ## Post #29 by @linforest [quote="siljelb, post:25, topic:11434"] the main quantity nodes of vital signs [/quote] For various observations, IMO, LOINC codes would be better than SNOMED CT codes. The practice/approach of fully controlling semantics might be an impossible task for our openEHR community (esp. Clinical community ), and it would be also not very welcoming/friendly to adopters and implementers, even though it may seem perfect. --- ## Post #30 by @damoca [quote="ian.mcnicoll, post:28, topic:11434"] So yes, let’s take advantage of the developments in LOINC/SNOMED but it is absolutely not a panacea - path-based querying remains very, very helpful IMO. [/quote] Absolutely. This is not about choosing one approach or the other, it is about finding the right balance between creating meaningful information structures and defining their semantics. Both are important things to address. --- ## Post #31 by @borut.jures I understand that I’m wishing for (almost?) impossible to have the archetypes “is-about” coded, but it just doesn’t seem right that **systolic** is `at0004` instead of `http://loinc.org/8480-6` :person_shrugging: --- ## Post #32 by @linforest Another issue is that any external terminologies like LOINC and SNOMED CT are unlikely always to meet the standard code requirements of openEHR in real-time or very promptly, for various reasons. --- ## Post #33 by @siljelb [quote="borut.jures, post:31, topic:11434"] it just doesn’t seem right that **systolic** is `at0004` instead of `http://loinc.org/8480-6` :person_shrugging: [/quote] It’s not `at0004`, it’s “Peak systemic arterial blood pressure - measured in systolic or contraction phase of the heart cycle”. And that LOINC code (like its corresponding SNOMED CT term) isn’t specific enough: according to its name and definition “System: Arterial system” it could just as well be the systolic pulmonary blood pressure. --- ## Post #34 by @linforest But overly specific conceptual codes may also cause problems for the integration of multi-source data and semantic interoperability. If a more specific code are indeed needed, it may be necessary to apply to the LOINC committee for a new term. ![image|690x389](upload://4FHSZcgb73uOYhaYhdpg053Fs09.png) --- ## Post #35 by @siljelb [quote="linforest, post:34, topic:11434"] If a more specific code are indeed needed, it may be necessary to apply to the LOINC committee for a new term. [/quote] :bullseye: this is exactly why it’s a nightmare to base archetype element semantics on standardised terminologies. --- ## Post #36 by @borut.jures I understand that working with the standardizing committees is no fun and in practice (almost) impossible. It is sad that this is a reason for not coding the archetypes (this is a critique of the committees not modelers). However, without the coded archetypes, aren't the same discussions just postponed until somebody wants to figure out what an element represents (e.g. data mapping between systems)? The decision is then made by a technical person who usually doesn’t know about the subtle differences in healthcare data/concepts (even systolic can be many different things). And they are tasked to produce results “immediately”. I still hope one day all the knowledgeable humans will be able to work together to produce “The Models”. openEHR models are an important part of this effort and I :clap: to the modelers. --- ## Post #37 by @thomas.beale [quote="birger.haarbrandt, post:3, topic:11434"] What make me curious is why some people in the community are so keen on introducing breaking changes to the RM. Just look at the HUGE problems FHIR has by introducing breaking changes across versions. As a consequence, whole countries are stuck on different FHIR versions. [/quote] [Some answers to that here](https://discourse.openehr.org/t/looking-ahead-to-openehrv2/11448). Needless to say, if we went to openEHRv2, it would be for the next 20y, not an endless rollout of breakages each 2 years… [quote="birger.haarbrandt, post:3, topic:11434"] The promise of the RM is to be stable. Backward-compatibility is a huge value when we talk about **data for life**. That’s a big plus for technologies like Java. There is beauty in the fact that I can run my 20 years old java program on a recent JVM version and that I can still upload a template I did in 2013 into my openEHR server and tools, and everything just works. [/quote] That would work in an openEHRv2 system of course. Data migration from openEHRv1 to v2 would be needed for those systems and vendors that wanted to do it. But the improvements (having build quite a few of them) are definitely worth it. And it would be one of the easiest data migrations ever. People get worried about breaking changes to openEHR (and that’s reasonable, don’t get me wrong), but *routinely* don’t think twice about endless data conversion in and out of openEHR, HL7v2, FHIR, OMOP, IHE, X12, and more - and these are not the same RM with breaking changes, but **different paradigms, generally with difficult to reconcile semantics**. Those conversions are creating errors and omissions in data all the time. So we need to be realistic. [quote="birger.haarbrandt, post:3, topic:11434"] In my opinion, there is so much opportunity to improve the ecosystem, also with new specs (e.g. expanding the use of archetypes to ERP data as proposed by @thomas.beale ), without breaking stuff that is not supposed to break. [/quote] We should definitely take note of this. However there are some changes so central that they change everything. So it’s worth considering whether we hang on to openEHRv1 longer and keep grafting non-breaking improvements, and bite the bullet later (more data, larger models deployed) or do it sooner. Both paths are possible, and probably both are reasonable, but the costs and consequences need to be understood. Breaking changes can be managed well, or badly. We need to do it well. We have coherent architectures and a good community approach to change management. --- ## Post #38 by @thomas.beale [quote="damoca, post:20, topic:11434"] This. I have been saying this for years. Real semantic interoperability (both within and across systems) will come when we stop searching or filtering by paths and start searching for concepts. And we need to pay more attention to the semantic bindings of the archetypes to do so. [/quote] @damoca as an aside, you and your pro team should think about what actual coding could be used. In our experiments at Graphite, we used LOINC, because Stan Huff was able to get an agreement for them to add new codes. But (as we all know), LOINC is not naturally a taxonomy-based terminology - it’s a multi-axial one identifying vectors in an N-space. Theoretically Snomed might work, but it’s full of precoordinated junk and too many errors (despite best efforts) for my taste. I’d rather build a terminology that covers the space properly, and parsimoniously (I once asked Alan Rector: if he had the chance, would he ditch Snomed and start again? He said yes, you only need about 100k terms and relationships to do it cleanly). There are two kinds of terms needed to do is-about coding: * terms to code epistemic elements, e.g. data points in the medication order archetype * we have to build this, it doesn’t really exist properly * terms to code ontic elements, e.g. anatomy, heart rate/rhythm and so on * we need to consider re-use, adaptation, development of things like OGMS, FMA, other OBO ontologies etc. If we do this again, I don’t want to use LOINC, let’s do it properly. You expert input will be essential in that exercise ;) --- ## Post #39 by @thomas.beale [quote="borut.jures, post:23, topic:11434"] The US project had some 3000 lab archetypes. Synthetic data was generated using [relevant reference ranges](https://mapehr.com/docs/synthetic-data/#set-a-value-for-elementvalue---multiple-units) (see `interpretation_intervals` below): ``` ``` [/quote] We also had an improved model of Reference range, which included some of those other meta-data items. [quote="siljelb, post:25, topic:11434"] The “is-about” mappings per leaf node as mentioned by @thomas.beale and exemplified by @borut.jures make a lot of sense, and I agree they could help future-proof some AQL queries where the full intra-template context isn’t relevant. But there’s also the risk of making modelling completely untenable, if it’s dependent on some external terminology over which modellers have little or no direct control. [/quote] Not if we take control and build our own (as well as use applicable existing resources like BFO, FMA etc). People wildly under-estimate the difficulty of continually compensating for all the errors and pre-coord terms in SNOMED (and I’m not trying to be critical here, it’s just an objective fact, and the result of endless organic growth on a foundation built by people who knew nothing about ontology), and they wildly over-estimate the difficulty of building good detailed ontologies. [quote="siljelb, post:25, topic:11434"] I’ve taken part in some efforts to map archetype nodes to SNOMED CT terms. Even when you’d think mapping should be easy, such as the main quantity nodes of vital signs, there are nuances between the intended semantics of the archetype nodes and the semantics of the SNOMED terms. This leads to year long discussions and endless processes to introduce new terms, and it’s a complete and utter nightmare. [/quote] It’s because SNOMED doesn’t distinguish between epistemic entities (observed x, measured x, predicted x) and ontic entities (x). And openEHR doesn’t distinguish that cleanly either, although it is intended as a fully epistemic information ecosystem, i.e. openEHR is a ‘recording’ concept, not a describing-reality concept (that’s the business of things like FMA). [quote="siljelb, post:27, topic:11434"] Maybe? But I’m not sure anyone would want to model them? I certainly wouldn’t, after my previous experiences. [/quote] I think we could show some things that would make this look less daunting. Avoiding Snomed as the primary terminology would be one. We’d provide secondary mappings into it, but for reliable computation, we wouldn’t use it. I know, total heresy, but we need to be much more objective about how things are really going to work for the next 50+ years. We are going to need much better semantic architectures than we have today. [quote="ian.mcnicoll, post:28, topic:11434"] So yes, let’s take advantage of the developments in LOINC/SNOMED but it is absolutely not a panacea - path-based querying remains very, very helpful IMO. [/quote] One of the other things we did was significantly flatter paths (the subtyped Observation helps a lot with this). The paths we ended up with were much more comprehensible. Query evolution with such paths would be easier than it is today. But the gold standard of interop in the future will be ontology codes (which might be human comprehensible, like they used in OBO-land) not model paths. That has to be the case, because many / most of the paths we use correspond to ad hoc epistemic structures that help our human minds understand the data more easily (e.g. separating ‘data’ from ‘state’), but which don’t really exist in reality. [quote="linforest, post:29, topic:11434"] For various observations, IMO, LOINC codes would be better than SNOMED CT codes. [/quote] It’s one reason we used it in the US experiment, LOINC is oriented to naming observations. But it has no taxonomic hierarchy, i.e. no IS-A relation. The recent LOINC/SNOMED agreement allows the IS-A relation in SNOMED to be used to assert IS-A relationships between LOINC terms. But it’s very clunky in my view. [quote="borut.jures, post:31, topic:11434"] I understand that I’m wishing for (almost?) impossible to have the archetypes “is-about” coded, but it just doesn’t seem right that **systolic** is `at0004` instead of `http://loinc.org/8480-6` :person_shrugging: [/quote] Exactly ;) [quote="linforest, post:32, topic:11434"] Another issue is that any external terminologies like LOINC and SNOMED CT are unlikely always to meet the standard code requirements of openEHR in real-time or very promptly, for various reasons. [/quote] It’s why we need our own. We can stand on the decades of learning from those and other terminologies, but just like with openEHR itself, sometimes you need to start clean. [quote="siljelb, post:35, topic:11434"] :bullseye: this is exactly why it’s a nightmare to base archetype element semantics on standardised terminologies. [/quote] Far from a nightmare, even with LOINC. We actually obtained close to 1000 net new codes over a 18 month period. They were very cooperative. People really want this to happen. People like Stan have been thinking about this forever. It was very useful to actually do a trial run. [quote="borut.jures, post:36, topic:11434"] However, without the coded archetypes, aren’t the same discussions just postponed until somebody wants to figure out what an element represents (e.g. data mapping between systems)? The decision is then made by a technical person who usually doesn’t know about the subtle differences in healthcare data/concepts (even systolic can be many different things). And they are tasked to produce results “immediately”. [/quote] Indeed. --- ## Post #40 by @pablo [quote="damoca, post:20, topic:11434"] [quote="thomas.beale, post:16, topic:11434"] The future of dealing with that is coding all archetype nodes with an ‘is-about’ code, which will not change for the same data point, no matter where it moves over major version upgrades. [/quote] This. I have been saying this for years. Real semantic interoperability (both within and across systems) will come when we stop searching or filtering by paths and start searching for concepts. And we need to pay more attention to the semantic bindings of the archetypes to do so. [/quote] I totally get the point, though for systems to deal with concepts you will end up with some type of code. You can pick X or Y, but at the end you need to pick one. The alternative to codes is to have a full dictionary entry as the definition of the concept, which can include a code, but is more complete. On the other side, you might need to have complex concepts, which have different attributes and data structures. So at the end, you might have a whole archetype as the concept definition, and IMHO paths are just codes to reference subconcepts inside the parent concept. So if you don’t filter by archetypes and paths, you will filter by codes or something that is like an archetype and path. Then the discussion about the codes is if the codes are expressive enough to represent the concepts that you have as archetypes and the subconcepts/elements inside them. If you can’t find the same granularity inside the terminology/code system, then the alternative is to construct one yourself. At the end you will end up with a huge terminology that is just a representation in a different model of what you already have in archetypes with paths. I think this is just doing the same thing with a different representation. (as we say in Spanish: same dog, different collar). Under the microscope, what you need is enough bits to represent a unique concept in detail, and how you organize the bits might not be so important: codes vs. archetype+path vs. .... you always need those bits. Though my view might be biased by my own experience. If there is a way of storing, managing and querying that really that is more semantic-based and has advantages over archetype+path, please show me :) --- ## Post #41 by @thomas.beale [quote="pablo, post:40, topic:11434"] I totally get the point, though for systems to deal with concepts you will end up with some type of code. You can pick X or Y, but at the end you need to pick one. The alternative to codes is to have a full dictionary entry as the definition of the concept, which can include a code, but is more complete [/quote] When we say ‘code’ that’s just shorthand for an identifier that is a key to such an entry, although it will be in an ontology with at least IS-A relationships asserted, and potentially other relationships as well (e.g. relationships from BFO / RO ontologies). So there’s no alternatives here - we’re talking full ontology. [quote="pablo, post:40, topic:11434"] At the end you will end up with a huge terminology that is just a representation in a different model of what you already have in archetypes [/quote] Not if it’s done correctly; the ontology establishes what each data item ‘is about’, i.e. it establishes the description of what things in the real world any information can report on. It doesn’t need to replicate informational structures of archetypes. It may be that there are different archetypes, e.g. in obstetrics, that refer to the same thing (e.g. in detailed and non-detailed summaries). THe ontology will include this entity only once, and all using archetypes will use that one code to connect the archetype data point to the same ontology entity. --- ## Post #42 by @birger.haarbrandt [quote="thomas.beale, post:37, topic:11434"] but *routinely* don’t think twice about endless data conversion in and out of openEHR, HL7v2, FHIR, OMOP, IHE, X12, and more [/quote] I think of this all the time, its existential dread. --- ## Post #43 by @pablo [quote="thomas.beale, post:41, topic:11434"] When we say ‘code’ that’s just shorthand for an identifier that is a key to such an entry, although it will be in an ontology with at least IS-A relationships asserted, and potentially other relationships as well (e.g. relationships from BFO / RO ontologies). So there’s no alternatives here - we’re talking full ontology. [/quote] Call it code, id, key, it’s a reference to a definition of something, and that definition is a mix of human readable things, links to other definitions, context, etc, etc. Those definitions need to have some kind of representation, it doesn’t matter if it’s a graph, object oriented, or free text, you just need enough bits to describe the `thing`, how you sort those bits and how those bits and encoded/decoded is meaningless. The semantics is in the bits themselves. It’s like DNA being described by long strings of 4 symbols, you just need enough of those to represent something with enough semantics that it allows to understand the concept exactly, but be practical enough so that can be used in software (it’s impractical to describe each `thing` by a representation of all its atoms). For instance, it would be possible to have an RM that represents the base ontology we need to base all the clinical concepts on, and use ADL to represent higher level concepts by constraining/extending/specializing the base RM. Though if we use the same formalism, let’s say ADL, to also represent the base RM (I commented about that in other thread recently), you can construct all your semantic layers with one formalism. Then how you reference or identify each component of a `thing` represented by the formalism, be an id, a code, a path, it doesn’t matter much, what you care about is that the reference is exact, unique, processable, etc. [quote="thomas.beale, post:41, topic:11434"] [quote="pablo, post:40, topic:11434"] At the end you will end up with a huge terminology that is just a representation in a different model of what you already have in archetypes [/quote] Not if it’s done correctly; the ontology establishes what each data item ‘is about’, i.e. it establishes the description of what things in the real world any information can report on. It doesn’t need to replicate informational structures of archetypes. [/quote] I think we have different mental models about this. The comment by @damoca was about not using paths at all, which is the structural part, so if you don’t use that part, you need the semantics of the structure also in the terminology or in the ontology that defines the base semantics. My point is that the semantics should be somewhere and I see the structure as part of those semantics. So you can change the paths for other things, but at the end everything is connected, you just changed the reference to the `entry point` to get to the `thing`. On the other hand, what you say is to create yet another element in the specs, with bindings to other artifacts. I can’t imagine the kind of effort required for such feat. Anyway, I would like to see a practical example of all this before discussing further since I think there is something I don’t get here :) --- ## Post #44 by @thomas.beale [quote="birger.haarbrandt, post:42, topic:11434"] [quote="thomas.beale, post:37, topic:11434"] but *routinely* don’t think twice about endless data conversion in and out of openEHR, HL7v2, FHIR, OMOP, IHE, X12, and more [/quote] I think of this all the time, its existential dread. [/quote] That is the correct attitude :wink: More people should have it… [quote="pablo, post:43, topic:11434"] Those definitions need to have some kind of representation, it doesn’t matter if it’s a graph, object oriented, or free text, you just need enough bits to describe the `thing`, how you sort those bits and how those bits and encoded/decoded is meaningless [/quote] To be useful and usable, this needs to be a controlled ontology, and representation of that is quite important. [quote="pablo, post:43, topic:11434"] you need the semantics of the structure also in the terminology or in the ontology that defines the base semantics. [/quote] Some of the informational semantics are not needed (and have no place) in the ontology. For example heart rate and exertion level are just two observables in an ontology; there’s no data / state distinction. We overlay that in the information layer to separate out what is the focus of our enquiry (the heart rate) and factors the modify the interpretation (body exertion level etc). In the Intermountain Healthcare CEM models (archetype equivalents) they don’t have data/state separation. It makes their models harder to understand and even a bit harder to compute with, since you can’t easily loop through the meaning-modifying observable elements, but it doesn’t make their models wrong. The ontology is just about reality, not about analytic views of reality. That means it is pretty lean. --- ## Post #45 by @pablo [quote="thomas.beale, post:44, topic:11434"] Some of the informational semantics are not needed (and have no place) in the ontology. [/quote] I understand the ontology is not the place for the structure. What I’m saying is to have the **full semantics about something**, specially if we are talking about recording, exchanging, querying, analyzing and visualizing information, you need ontologies, taxonomies, dictionaries, data structures, terminologies, constraints, mappings, etc. and all of those linked together, that’s the only way you can use all the models from a fully semantic point of view. If we work just with some of those, we will always have partial semantics. Though I’m open to other ideas, but I need to see something actually working that way to be convinced. If you have such thing, please share it. --- ## Post #46 by @damoca [quote="pablo, post:43, topic:11434"] The comment by @damoca was about not using paths at all, which is the structural part, so if you don’t use that part, you need the semantics of the structure also in the terminology or in the ontology that defines the base semantics. My point is that the semantics should be somewhere and I see the structure as part of those semantics. [/quote] I don’t think I said that anywhere :sweat_smile: I fact, I believe we totally agree. What I said is that both the information structures and their semantics are important. I agree with the comments saying that it will be probably impossible to put a code to everything, that would be unmanageable. But it is also wrong to think that everything is about the structure (which is, by the way, the initial question, what happens when that structure changes in an archetype). Dual modelling is greatly based on semantics. The fact that we use a reference model already provides some basic semantics or a reference ontology. When an archetype is created, we are constraining those semantics. When an archetype is named, we are also defining semantics. If we call an archetype `OBSERVATION.pulse` we are somehow assigning a code, a meaning, to it. When we filter by an archetype_id in an AQL it is not something structural, it is semantic! So, the point is that structure is essential, because it helps to organize data. But its combination with a semantic definition is what should help us to find the right data. This combination is especially true when we work with data values. A code can help us to find an ELEMENT that represents the systolic blood pressure. Its location in the archetype can provide a context for the meaning of that information. And then we will see that it is a DV_QUANTITY and we will be able to find its units by navigating to the specific attribute of the data type We won’t need further codes here. I’d like to conclude by saying that everything we are discussing is about the vision for openEHR/dual model systems. Maybe the technology is not yet there. Maybe developers of openEHR systems and modelers still have to learn about the best way to proceed and how to create efficient solutions. If we have been working on this for +20 years is because nobody said it was easy. --- ## Post #47 by @thomas.beale [quote="pablo, post:45, topic:11434"] If we work just with some of those, we will always have partial semantics [/quote] Right. I’m just saying that there are important semantics not currently in many archetypes, primarily markers to indicate what each data item reports on (aka ‘is-about’ - see this [foundational paper](chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/https://ceur-ws.org/Vol-1515/regular10.pdf)). These markers, to be of any use computationally must necessarily be entities in an ontology. That ontology could either be assumed to be SNOMED CT, things like [OGMS](https://www.bioportal.bioontology.org/ontologies/OGMS), [FMA](https://bioportal.bioontology.org/ontologies/FMA), etc, or something created *de novo*. Our ‘experiment’ in the US actually used LOINC, for convenience rather than any technical suitability. You were worried that such an ontology would replicate the contents of archetypes. I am saying it won’t; it establishes the *target* of the is-about relation for each archetype data point. For example in the Pulse / heart beat archetype, the data point `/data[Rate]` reports (= is-about) heart rate, but computationally there’s no way to know what ‘heart rate’ is - i.e. the right side of the relation is absent. So CDS or other components can’t easily: * know that the rate is comparable to the same thing called differently in e.g. FHIR, inside Cerner or other EMR etc * know that it is a ‘vital sign’ and that it needs to be in a certain range to be alive and not in an emergency situation; The first thing is obtained by the use of the same is-about code in different health data models from which data are created; the second is achieved by locating the code within its ontology and following various relations (is-a and others). So the addition of this ontology won’t replicate the informational semantics (consisting of the structures of elements on the left side of the is-about relation); *au contraire*, it provides the ontological meaning. Some might think (as many have over the decades) that the ontologies or terminologies such as SNOMED CT are all that is needed. But they aren’t; it should be clear from the above that they can only provide an ontological underpinning to the structures of information that people actually want to record. The information structures have their own semantics: why is a certain collection of data points used to characterise a certain phenomenon? There are many reasons, nearly all contingent, e.g. medical history / culture, cost-related, and so on. Physicians do initial exams using cheap, non-invasive methods; they only do MRIs and similar when they are really needed. So physical exam archetypes will contain certain data points, and not others. Docs don’t record what the patient ate when recording heart rate, unless they suspect something ingested is actually causal; and so on. Ontologies of reality thus capture invariant truths (as best we know them), while ontologies of information capture contingent rules / structures and so on. The latter are what HCPs record to do medicine; the former tells us what the data mean. [More on this here](https://wolandscat.net/does-anyone-actually-understand-what-terminology-is-for/). I believe we are at a point where we (the HIT domain) needs to do this properly and we are best placed to realise it in openEHR. --- ## Post #48 by @mikael [quote="siljelb, post:25, topic:11434"] This leads to year long discussions and endless processes to introduce new terms, and it’s a complete and utter nightmare. [/quote] This is something that we need to work on to improve. --- ## Post #49 by @mikael [quote="linforest, post:29, topic:11434"] For various observations, IMO, LOINC codes would be better than SNOMED CT codes. [/quote] There are work going on to bring SNOMED CT and LOINC closer together. [LOINC / SNOMED CT – Regenstrief Institute, Inc. and SNOMED International](https://loincsnomed.org/) --- ## Post #50 by @mikael [quote="linforest, post:32, topic:11434"] Another issue is that any external terminologies like LOINC and SNOMED CT are unlikely always to meet the standard code requirements of openEHR in real-time or very promptly, for various reasons. [/quote] It depends on what you mean by “external terminologies”. In the same way as it is possible for everyone with the right knowledge to extend openEHR with a new archetype, it is possible for everyone with the right knowledge (and a SNOMED CT license) to extend SNOMED CT with new concepts within the SNOMED CT relationship structure. In the future, openEHR and SNOMED CT modelling might be more integrated than today, if we believe that is a good idea. (The drawback of extending SNOMED CT with your own content is about the same as extending openEHR with archetypes outside the international CKM.) --- **Canonical:** https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434 **Original content:** https://discourse.openehr.org/t/what-happens-once-the-pulse-heart-beat-archetype-is-replaced/11434