lessons from Intermountain Health, and starting work on openEHR 2.x

Thomas Beale thomas.beale at oceaninformatics.com
Wed Sep 12 21:22:15 EDT 2012

On 12/09/2012 17:43, Heath Frankel wrote:
> We need a depreciation scheme that allows us to say that something is 
> no longer recommended for use in a particular release and removed in a 
> subsequent release. This gives implementations time to migrate to the 
> new recommendation. It also means we can get some experience with what 
> the new recommendation is before we remove the deprecated approach.
> Please be careful about backward compatibility of our RM, its core to 
> our foundation.
> Heath
> *
> *

One key approach that we can use for adding breaking fixes to classes is 
to actually add a new class. For example, a new version of 
ARCHETYPE_SLOT is needed in the AOM. The way I would propose to do this 
is not to 'fix' the existing ARCHETYPE_SLOT,  but to add a new class 
ARCHETYPE_SLOT2 or SEMANTIC_SLOT or whatever, and enhance existing 
compilers to handle the new one, and to know how convert between both. 
This is just an example - there are probably similar instances of 
breaking changes in the RM.

Many change requests I am aware of would not break existing data. The 
main ones we need to be careful with are structural changes to Entry 
classes and to the Participations model.

We need of course to analyse all the proposed changes carefully, but by 
now we have a reasonable number of implementers, and they will need to 
be present on the new specifications editorial committee to help assess 
impact of any given change. So... we just need to do good engineering 
thinking on this.

- thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20120912/6dac50e5/attachment.html>

More information about the openEHR-clinical mailing list