Hi All,
I do not recall who said it or even which openEHR mailing list it
appeared on but I would like to get feedback from implementers.
I recently read a comment that seemed to me to be counter to a core
philosophy of openEHR. The comment was regarding how to handle
different versions of an archetype and it basically posited that there
should be some automated intervention that would migrate data from one
archetype version to another.
In my mind, this is a TOTALLY wrong approach. While it is common
practice in the general world of IT we all know that healthcare is
different. Even if there was a mistake in the archetype or the
information technology has changed. Isn't it more important to maintain
the integrity of how, where and when the information was recorded? IANAL
but it seems that from at least a medico-legal standpoint, manipulating
information, in ANY way, after the fact could have serious consequences
and compromise the integrity of the information system.
Your Thoughts?
--Tim
I do not recall who said it or even which openEHR mailing list it
appeared on but I would like to get feedback from implementers.
different versions of an archetype and it basically posited that there
should be some automated intervention that would migrate data from one
archetype version to another.
Tim, it was me I think - I mentioned it on one of the wiki pages
I setup. Mea culpa!
I brought it up in relation to the migration of reference models, not
actual archetypes - but it was just an idle thought, not a firm
opinion. I was making the point that it might be nice if 'minor'
changes to reference model schemas could be handled in a way
that meant that the data could be upgraded to the new reference
model. This would depend on the canonical form etc or else as you
point out, the digital signatures etc would be invalid.
I only mentioned it because if we are envisaging a lifelong record for
a person - and my children* are writing openEHR 13.x systems in 50
years time, do we really want to be inflicting upon them the need
to still be dealing with reference model 1.0.1, 1.0.2, 1.0.3a etc
(where the only significant difference is a field that was renamed,
or an extra field was added?).
I am firmly in agreement with you that modifications to existing
data is a general no-no, and would only be done if it was possible to
do in a way that kept all the medico-legal niceties in tact. But I think
the maintenence of future openEHR systems is also a valid
'use' case.
Andrew
* children mentioned in this email are currently fictional
What we have always said is that with a new version there should be an
algorithm published that will transform data from the previous version
to the new version. This algorithm could be used to migrate data (a
once-off operation) or it could be used on the fly every time a query
operation was executed. The main requirement is that data from previous
versions respond to queries in as correct a way as possible - that means
where queries are dependent on some new feature of a new version of an
archetype, e.g. a changed field meaning, then the old data can be made
to respond properly. I am not religous at all about transforming data,
quite the reverse. I think we will have to see how openEHR queries pan
out, and how many really have dependencies on things changed for reasons
of versioning.
- thomas
Tim Cook wrote:
to respond properly. I am not religous at all about transforming data,
quite the reverse. I think we will have to see how openEHR queries pan
out, and how many really have dependencies on things changed for reasons
of versioning.
- thomas
This is an idle thought but it seems to me that if the queries adhere
to the structure of the archetype that is less appealing than using an
identifier for the data element
e.g. select .....blah blah....
where obs/data[at0001]/events[at0006]/data[at0003]/item[at0004]/value/value
= 140
is nasty to type (or copy/paste) and while I understand the purpose of
AQL was to be computer generated based upon archetypes, I thought a
reason for SQL and XML success was its simplicity and the ability to
read and write simple examples (despite computer generated versions
being possible and superior).
If an identifier was assigned to that blood pressure surely that would
be nicer...?
e.g. select...... blah blah.....
where obs.bpsystolic >= 140
or even select...... blah blah.....
where obs.bpsystolic1634 >= 140
With unique identifiers not tied to the structure of the document
perhaps revision versions of the archetypes become less important...
or perhaps not...
Anyway, I am no expert on such things so as I said it is an idle thought.
Greg
Greg,
The first thing I would say is: beware the attraction of hand-built or
directly readable computer formalisms. For many examples, including most
of SQL, XML, and many other languages, only trivial examples can be
built by hand without error, except by computer experts. So we always
build tools to author or look at such things. Clincally trivial queries
can easily be technically complex.
However, we have thought about this identification idea before. It would
necessitate either external terminology support, e.g. if new Snomed
codes could be created for every path, or else it requires the
identifiers to be defined with the archetypes, using more internal
codes, where each such code is equated to a long path. Both approaches
preserve linguistic independence, but it is not obvious at this stage
whether the former is possible or desrable, or the latter is worth the
effort. The latter is certainly doable, but more analysis is needed.
- thomas beale
Greg Caulton wrote: