lessons from Intermountain Health, and starting work on openEHR 2.x
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical