← Back to team overview

oship-dev team mailing list archive

RES: RES: RES: openEHR Terminology source file

 

Hi Tim,

I think we are saying the same thing regarding the RM. What I meant to say
by beyond the scope was that how to access different versions of a
terminology is implementation specific, not that the RM specification should
not account for terminology versions.

In the present situation, maybe your approach (to keep several versions of a
terminology in the environment) is the only one possible. But a terminology
server may offer other services beyond the access to several versions,
specially for more sophisticated terminologies. These services can include:
full version control, including mappings from one version to another,
mappings to other terminologies, inference engines that could be helpful to
decision support systems, post-coordination checking, navigation, etc. Maybe
in the future (how far?) we could have these services provided by
terminology servers around the world. In this context, I think it makes
sense to have terminology servers outside OSHIP with an agreed API. 

Although a standardized API for dealing with this full range of services may
be not possible, there are some things in common with terminologies that
could be the subject of a standardization: how to get subsets of terms, get
a code, etc. ISO-HL7 are working in one such standard, also there is a
Terminology Subset Syntax specification in the openEHR roadmap. 

All these things may not be of immediate concern for the present OSHIP
implementation and may look like a red herring, but I prefer to be open to
other possibilities.

Cheers,

Sergio

...
> The problem you pose now is beyond the scope of the rm specification. 

It really isn't beyond the scope of the RM.  In the Support IM Terminology
Overview the last sentence indicates that this is implementation specific.

Also if you review the example table in section 5.3.2 you will see that many
of the terminologies do carry version identifiers.  This is because there
are changes between versions.  

> In the datatypes.text package there are classes that allow one to 
> store for one entry into a specific terminology the terminology Id 
> (with its version), the code and its rubric, and eventually a one to 
> many mapping from this terminology to others. So could you give 
> reasons why we need to keep several versions of a terminological system in
OSHIP?

Certainly.  Over time, terminologies change (and sometimes very badly) if
you look at ICD over the years there are codes that mean one thing in one
version and something else in another.  If you record real patient data at a
point in time then you need to be able to look at the terminology and
medical knowledge "at that point in time".  This is not only crucial to
medico-legal issues but to research as well.

The one-to-one mapping should be TO A SPECIFIC VERSION we have had and still
have ongoing discussions about this on the various openEHR lists.

Often the code and it's rubric is not sufficient to give full details from a
terminology without referring to a printed guide of some sort, if you happen
to have; let us say that ICD9CM manual from 1991 lying around.

That is why I believe the prudent thing to do is include the entire
terminology.  Disk space is cheap.




Follow ups

References