"Alvin B. Marcelo" wrote:
> I would like to make a proposal to the alliance:
>
> Given that:
>
> we can't agree on data models
> we can't agree on prgramming language
> we can't agree on platforms for interoperability...
>
> (and this is all fine because the technology is not that mature) [read as:
> no randomized trial to support any of them :) ]
>
> My proposal is that we agree _simply_ on data element _semantics_.
I think we need to agree on more than this: all the major models make statements
about:
- structure
- types
- behaviour (functional interfaces)
- constraints (or contracts)
- clinical semantics, e.g. allowed terms in certain contexts, but also other
statements about values, and more involved statements in terms of state machines
representing e.g. a course of treatment.
We don't need to agree on any of what you mentioned above to agree on these
things. The problem is a) to describe a model in a formalism that people are at
least prepared to discuss it in, and b) to express it to formalisms that can be
used by systems.
There are two formalisms required: one for the concrete information model (like
the GEHR object model, the RIM, the CORBAmed interfaces, and the CEN models) and
one for clinical meta-models/constraint definitions.
Appropriate formalisms for concrete models: most people seem to be happy with
UML. For clinical constraint definitions, an XML-based "formalism" seems to be
the way to go, given the need to satisfy accessibility, readability,
processability by systems etc. We have proposed the use of XML-schema, even
though its technical definition is weak (as if UML's were not...). XML-schema
documents are reasonably standalone; tool support is emerging; they are
independent of language, platform etc.
The concrete models of all the major standards have been available in UML form
for a long time now. We are all trying to collaborate to ensure these models
converge, or at least become as compatible as possible.
The new (and more important area) is that of clinical constraint definitions. We
will soon be publishing a complete archetype schema in XML-schema, defining the
GEHR approach to this, based directly on the GOM, as well as 50 or so basic
archetypes. We have already published the GOM in XML-schema and current
archetypes as specialisations of that. The new approach will improve the
semantic power significantly.
Now the point of this is not to insist everyone agree with our archetypes.
Rather we want others to consider the approach (we think there will be broad
agreement on something like it), and to learn enough about the archetypes to
understand their power.
In answer to the original post, we think there is scope for thinking about and
agreeing upon far more than just terms (even structured termsets); UML and
XML-schema are both language- and platform-neutral formalisms which can be used
for both human consumption, and as artefacts for processing by development and
runtime tools.
As far as LOINC and UMLS go, we don't believe there is any immediate need to
mandate these two in the name/value roles. It is more important to get people
familiar with how archetypes/meta-models work, and to explore their use. It may
well be that in the future, the best term-sets for name/values in archetypes may
differ depending on the medical specialisation, on the openness of the termset,
on the availability of free software to view them and so on. All that is really
needed in an archetype is to indicate for any term that appears, what its
expansion (i.e value) is. Sometimes, the author may want to mandate, a
particular termset, but not all the time. The author might also want to allow
any term matching a pattern (expressed as a regular expression for example).
(UMLS is a special case of course, being a meta-thesaurus, and it may indeed be
the case one day that absolutely every term anyone every wants to use will be
found in it).
- thomas beale
