Hi, As an engineer, I prefer the new proposal. A code without its terminology is like a number without its unit - and engineers have been trained to hate that ;-) So imho : the closer both concept are one from another, the best is the model.
Cheers, Philippe Hugh Grady a ?crit : >Hi Tom > >I prefer the original structure, mainly from a general dislike of aggregate >attributes (such as the new one combining the terminology and the code id). >I can see the need to decompose the attribute to talk to the right >terminology being a nuisance and it could make some sensible operations >difficult when dealing with CODE_PHRASEs from multiple terminologies. > >Cheers, >Hugh > >-----Original Message----- >From: owner-openehr-technical at openehr.org >[mailto:owner-openehr-technical at openehr.org] On Behalf Of Thomas Beale >Sent: Sunday, 15 January 2006 2:19 PM >To: Openehr-Technical >Subject: Proposed slightly radical change to CODE_PHRASE in Text package in >openEHR > > >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 > > >
