In the process of getting the openEHR specifications upgraded, a number of Change Requests are being processed before the declaration of the 0.9 Release. This release is intended to be more or less what is there now, with errors corrected, and a couple of desirable changes made.
One change which is quite basic, and is supported by all reviewers so far is as follows: In the Text cluster of the Data Types specification (a draft is here http://www.deepthought.com.au/health/openEHR/data_types/data_types_rm-1_7_7.pdf), there is a class called COORDINATED_TERM. This class represents the idea of a terminology id + a code, e.g. ICD10::F43. Another class DV_CODED_TEXT represents a text item with a string value, which happens to be coded, and has an attribute 'definition' of type COORDINATED_TERM. The proposed change is to rename COORDINATED_TERM to CODE_PHRASE, which more accurately reflects the purpose of the class, and to rename DV_CODED_TEXT.definition to DV_CODED_TEXT.code. These two name changes make the model more comprehensible, and correspond more closely with accepted nomenclature in medical informatics as well as being closer to emerging HL7 and CEN data types standards. The change has no effect other than a change in name, however, for developers who have built XML schemas and code, this change will have some impact. A second related change is to make CODE_PHRASE a DATA_VALUE inheritor, meaning it can be used on its own as a data value (i.e. a code with no rubric can appear in data. This is useful for attributes like 'language', where the ISO code itself is meaningful - 'en', 'fr', 'kr' etc). This would mean renaming CODE_PHRASE as DV_CODE_PHRASE and adding an inheritance relation between it and DATA_VALUE. The question is: which release should the changes be included in: * release 0.9, to be declared next week. Advantage: the change is done, and this is a change which would be better being propagated as early as possible, since the coded text types are ubiquitous in the openEHR models. * release 1.0, probably to be declared in 6-8 weeks. Advantage: allows procrastination; disadvantage - continues to promulgate a suboptimal model of coded text types for even longer. My own feeling is that we should put the changes in 0.9, but I would like to get some idea from implementors. For those implementors who do not want to publicise their activities, a private reply to me will be fine (this will not be publicised in any way). One thing to contemplate: once release 0.9 is declared, the new openEHR website will be put into production, and the entire of openEHR specifications and code will be visible for easy download on the basis of release; it seems a pity to provide open access to the specs without these changes. The balancing argument is stability for current implementors. Thoughts from the community? - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
