Hi Gerard!
This will be an interesting process...
I think you will need to clarify several of your technical/modeling
statements and motivations during the process, I find several of them
a bit hard to understand.
Gerard wrote:
We need to reduce the number of degrees of freedom producing archetypes.
If you in the RM predefine ways to model certain things (e.g. timing
in observations by introducing an OBSERVATION class) then you are in
practice _reducing_ the degrees of freedom compared to leaving it
completely open for free form modeling using clusters in an unspecific
generic ENTRY. Remember that an unrestricted cluster has unlimited
degrees of freedom.
Gerard wrote:
We need to be able to use specialisations of the Entry class.
My thinking is that these health specific specialisations ( Observation,
Evaluation, Instruction, Action, etc.) must not play a role in the RM.
We are working on an addition to the 13606 standard that defines how
semantic interoperability artefacts are structured, used in other semantic
artefacts, how standardised modeling patterns are used, etc.
In this scheme all these things define a standard for the semantic layer on
top of the present technical 13606 layer.
I foresee a strict separation between the technical 13606 standard (as we
know it) and a semantic artefact layer (that we will need to wok on)
The technical layer is very generic, healthcare a-specific.
The Semantic artefact layer will have some health specific items
incorporated: e.g. Observation, etc. but even then contain many health
a-specific constructs that can be used outside of healthcare.
This thinking will have consequences for the present 13606 parts 1, 2 and 3.
I assume "healthcare a-specific" means something like "more general
and not specific to healthcare", is that a correct interpretation of
your words?
If so, why do you want to turn the 13606/openEHR into something
"healthcare a-specific"? Wouldn't that be an enormous deviation from
the current 13606 thinking and purpose? Was not 13606 intended exactly
for healthcare?
If you want a completely generic RM with the possibility of an
infinite number of meta-layers on top then something like RDF (as RM)
with OWL (as meta) on top seems to be what you are looking for. The
RDF+OWL approach definitely has both good use-cases and good
implementations but it is a very different approach than having a
healthcare specific 13606/openEHR RM in the bottom layer.
I think the approaches can co-exist perfectly and sometimes meet and
data/models partly be translated between them for specific purposes.
But if you try to completely morph one approach into the other you'll
likely run into trouble.
And what would a "healthcare a-specific" 13606 RM bring to the
"healthcare a-specific" scene that is not already there in one form or
another? What is the purpose of going "healthcare a-specific"?
The base classes of the HL7 v3 RIM (ACT etc) are sometimes said to be
"healthcare a-specific" and reusable in other contexts. But have they
really been extensively adopted outside healthcare? Why would 13606
want to go there? Can't we leave that exploration to HL7?
Another basic thing to explain is why things would get better or
easier by introducing even more (meta?) layers of modeling. I think
the levels of openEHR are many already, but they at least have been
tested in real systems and real modeling work and have somewhat clear
motivations for existing:
1. RM (for real software-implementable recurring stuff that you can
optimize storage and query for in order to get fast usable EHR
systems)
2. Archetypes (for finding/defining "maximal" datasets for closely
related documentation needs, this provides shared queryable search
paths)
3. Templates (for aggregating pieces and narrowing scope again to fit use cases)
(Also add management of the interaction with terminology systems to
all of the above before considering adding layers.)
Erik wrote:
A great thing would be to actually have at least two independent
_implementations_ of change suggestions (both AM and RM) after initial
discussions but before any revisions to the standard are made. That is
how some other SDOs work with technical artefacts and it could avoid
some of the previous suboptimal approaches.
Gerard wrote:
So you agree with my NO.
What NO? Please clarify.
Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
