What happens once the Pulse/Heart beat archetype is replaced?

Implementation Platform
1

Today @siljelb commented on the Pulse/heart beat archetype:

And previous discussion: Pulse and heart beat conundrum

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.

3 Likes
2

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.

1 Like
3

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.

9 Likes
4

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.

2 Likes
5

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!

2 Likes
6

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?

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.

7

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.

8

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.

2 Likes
9

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.

1 Like
10

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

1 Like
11

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).

1 Like
13

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 :brain::high_voltage::face_with_spiral_eyes:

4 Likes
14

@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.

1 Like
15

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.

16

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.

3 Likes
17

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.

1 Like
18

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.

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.

1 Like
19

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.

2 Likes
20

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.

5 Likes
21

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:

# 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 Synthetic Data | MapEHR

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:

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:

- 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).

2 Likes