Tom,
My only comments is related to the resulting XML schema. Any reason we
couldn't simplify the XML further to the following:
<name xsi:type="DV_CODED_TEXT">
<value>clinical finding</value>
<defining_code>SNOMED-CT::404684003</defining_code>
</name>
Having data enclosed within the defining_code element indicates that this is
the value anyway so we don't need the additional value child element. The
only potential downside of this is if there are additional attributes or
associations added to code_phrase later which would need to then be
represented as follows:
<name xsi:type="DV_CODED_TEXT">
<value>clinical finding</value>
<defining_code>SNOMED-CT::404684003
<some_other_attribute>some
data</some_other_attribute>
</defining_code>
</name>
Even though the result is still valid XML it is not the normal
representation in XML. We would then need to change the schema to
include the value element again. What is the likelihood of additional
attributes to Code_Phrase?
Sorry for the discussion of what the XML looks like, but you started it :>.
Heath
> -----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 15:19
> 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)
>
>
