Dear all,
we just came across a "feature" of the current openEHR Reference Model
which, in the light of current implementations (particularly XML), it
seems would be good to alter slightly. The change has no semantic
effect, only affecting how data are persisted. We are too close to the
Release 1.0 release date to be making such changes for my liking at
least, but on the other hand I suspect that this change would be of
universal benefit.
The class concerned from the current model is as follows:
class CODE_PHRASE
terminology_id: TERMINOLOGY_ID
-- Identifier of the distinct terminology from which the
code_string (or its elements) was extracted.
code_string: String
-- The key used by the terminology service to identify a concept
or coordination of concepts.
-- This string is most likely parsable inside the terminology
service, but nothing can be assumed
-- about its syntax outside that context.
end
The effect of this in XML data is to have to store:
<name xsi:type="DV_CODED_TEXT">
<value>clinical finding</value>
<defining_code>
<code_string>404684003</code_string>
<terminology_id>
<value>SNOMED-CT</value>
</terminology_id>
</defining_code>
</name>
The PROPOSED CHANGE to the class is as follows:
class CODE_PHRASE
value: String
-- the string concatenation form of the term, in the form
-- "terminology_id::code_string", e.g. "SNOMED-CT::404684003"
terminology_id(): TERMINOLOGY_ID {}
-- NOW A FUNCTION
-- Identifier of the distinct terminology from which the
code_string (or its elements) was extracted.
code_string(): String {}
-- NOW A FUNCTION
-- The key used by the terminology service to identify a concept
or coordination of concepts.
-- This string is most likely parsable inside the terminology
service, but nothing can be assumed
-- about its syntax outside that context.
end
The effect of this in XML data is to have to store:
<name xsi:type="DV_CODED_TEXT">
<value>clinical finding</value>
<defining_code>
<value>SNOMED-CT::404684003</value>
</defining_code>
</name>
We believe this will also enable more powerful path expressions using
the syntax form of coded terms, since the whole coded term code is now
just one attribute, e.g. "SNOMED-CT::404684003".
openEHR already uses "micro-syntaxes" for various kinds of identifiers,
such as archetype id, and a few other things, like units, so we see this
proposed change as compatible with the existing state of affairs. It
also has no semantic effect on the object-oriented view of CODE_PHRASE,
since terminology_id and code_string hoth return the same values as
before (it is just that now they are computed).
The only downside to this change we can see is that some current
implementors will need to change their softare and schemas.
In the balance of considerations, I would prefer to impose the nuisance
value now, and have a better reference model to live with for the next
5-10 years.
Do others agree?
Are their violent objertions?
Does anyone see a flaw in the proposal?
thanks,
- thomas beale
--
___________________________________________________________________________________
CTO Ocean Informatics (http://www.OceanInformatics.biz)
Research Fellow, University College London (http://www.chime.ucl.ac.uk)
Chair Architectural Review Board, openEHR (http://www.openEHR.org)
