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: [email protected] [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 -- ____________________________________________________________________________ _______ 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)
