Dear All
There has been an intense discussion - mainly Tom Beale and Matthew Darlison
going on off line. I want to share some of my views with others on the
approach to terminologies. I will deal with them one at a time.
1. Language and terminologies.
It is clear that we need to know what language we are working in to ensure
that the rubric or phrase returned by the terminology service is
appropriate. I have proposed in our GEHR work that this is kept at the level
of a transaction (a transaction can only be in one language). The issue is
that some words in different languages are lexically identical but their
meaning is different. SO - if we allow different language rubrics in the
same transaction - we will get an error one day as someone will read
something erroneous. For this reason - safety - I propose that transactions
are consistent in language. I am sure that it has huge pragmatic advantages
as well. A transaction in a language different from that of the workspace
can be displayed in a different format and possibly be translated (as
required).
If people accept this - and I will need a lot of persuading that it is not a
sensible restriction - it follows that terminology references - called
coordinated terms in the present model though I do not believe they have a
rubric so it may not be the best name - do not need a language associated
with them. This can be drawn from the present transaction, workspace or
whatever.
When querying a record via a terminology service, language will only be
relevant for the display - if you require translation (or if it is
available). So, if we have a term in ICD10 english, if there is a
translation of this then it should be the same concept - not a linguistic
translation. Stan Shepherd can help us with this as he translated ICPC into
12 languages and learned a great deal.
2. Terminology ID and versions
When sharing the EHR we will need to keep tight control over the expression
of the terminology in use. For this reason I would favour that we work with
HL7 & CEN to have a table of terminologies used in openEHR and that versions
of different terminologies are given different IDs. Every clinical system
will have a set of terminologies that it can deal with and will require
mappings to be created with termsets that it does not process. It is infact
likely that the shared parts of the record will have mappings to many
different terms sets - problem lists and medications for example.
The advantage is that we keep control over terminologies and understand when
they are different or the same - a translation might be identical - or might
involve modification. Whatever the realities - it is unlikely that much will
be gained in automatic processing until there is more convergence in the
world of terminologies than there is at the moment.
3. Domain termlists
It is very likely that some entries will require national or local domain
term lists - of the type that is in HL7. For this reason, I would propose
that we deal with this at two levels:
A. When the domain termlist is available internationally - use the authority
and the domain term list via the terminology service. For example
HL7:SpecimenType will give us the table of Specimen Types for laboratory
specimens. We may need some EHR specifics such as which terminologies are
allowed in openEHR for formal translation??
B. A term list that is very specific for a particular archetype or a
particular location. I would propose that this will be a set of
DV_PLAIN_TEXTs or DV_TERM_TEXT (if they are from a known terminology that
does not provide the means of displaying a subset).
Summary
All approaches have problems and only time will tell what is the most
appropriate response for a particular situation. For a fixed termset -
perhaps the patient position when a blood pressure is measured - an
identifier to a terminology (eg Children of Patient_Position),
HL7:PatientPosition or {sitting|lying|reclining|standing} are all
possibilities.
I am sure all need to be available from the start and standardisation needs
to unfold in the best manner for interoperability.
I look forward to hearing from you - Cheers, Sam
____________________________________________
Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-2, Standards Australia
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard at bigpond.com
www.openEHR.org
www.HL7.org
__________________________________________
____________________________________________
Dr Sam Heard
Ocean Informatics, openEHR
Co-Chair, EHR-SIG, HL7
Chair EHR IT-14-2, Standards Australia
105 Rapid Creek Rd
Rapid Creek NT 0810
Ph: +61 417 838 808
sam.heard at bigpond.com
www.openEHR.org
www.HL7.org
__________________________________________
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
