I see a kind of cooperation emerging here, which is fine and what I like most.
Eric points at one are that has my particular interest since I started to represent such assessment scales in HL7 v3 space in 2002. We where using the existing HL7 R1 datatypes then and found that for the calculation of the sumscore the INT could do all counting, but, the specification of each single score needed to be done with a CO that at that time did not “allow” for the calculation. It dit allow Eric’s example for Barthel to be expressed.
[ { 0 , “unable”},
{ 5, “needs help (verbal, physical, carrying aid” },
{10, “independent”}]
However, the CO in science is a number and in statistics it is used differently, namely it has an order, a code and can be calculated upon. (Although of course there is discussion again on the yes and no’s of calculating averages, there is no science without debate, but that is for me out of scope for what I am asked to discuss).
Eric is very right that we do need more than just data types. We need vocabulary, we need units, we need relationships and we need the clinical knowledge around it, and proof that the persons doing the work can be trusted.
How I see it from a clinical point of view with in mind the many reuses of clinical data is the following:
bottom line are the atoms of data elements.
This is the minimum level of information that can bring semantics.
the number 38 does not say anything. However, if we define the data type as being a PQ, more or less equivalent with interval / ratio in statistics), it becomes more understandable. but we need a unit to go with it, e.g. UCUM that can specify 38 degrees Celcius. The moment we want to refer to this number as a value of body temperature, we can assign a code from any kind of terminology, classification, vocabulary, codings system.
This is universal between UML, XML, CEN, ISO, (13606 in particular) HL7v2, HL7 CDA, HL7 V3, OpenEHR
Example: http://icnp.clinicaltemplates.org/icnp/10003507/?t= Body Temperature description: Temperature: Internal body heat related to body metabolism. type: focus code: 10003507
Hence the atomic node does need some particles, like a name, a unique code, a value, a datatype for the value.
Barthels differs in three ways from this basic principle of one data element.
- it has more than one data element, related to each other, making it a molecular “thing” which essentially is an artifact of something seen in the real world, but with hundreds of scientific studies supporting that the validity and reliability of this instrument is good for individual use (changes in time) and pupulation use (outcome measure).
- each data element has a set of allowed values. This set must be enumerated, and the code assigned to each value. In fact this creates a mini vocabulary. In the ISO 21090, ISO 13972 and HL7 space, we can use OIDs (unique object identifier) to mark such a vocabulary.
Barthel data elements have different value sets, hence creating roughly one vocab per data element.
This is universal between UML, XML, CEN, ISO, (13606 in particular) HL7v2, HL7 CDA, HL7 V3, OpenEHR - such assessments / score systems / scales, allow for computations based on the individual scores.
The computations can be simple count up, a but difficult like the calculation for the body mass index, or complex following decision rules.
As long as we stay on these levels, I see no differences in the standards. Hence, the detailed clinical models, that basically use these patterns.
If we add clinical / scientific knowledge on what is the purpose of the data elements (collection), literature, method to get reliable data in the EHR and out of the EHR (clinically speaking), references and
If we add meta information on who created this specification, we deal with the detailed clinical modelling as it is intended and proven feasible to be used in HL7 space and in archetype space.
See: Bridging the HL7 template - 13606 archetype gap with detailed clinical models.Goossen WT, Goossen-Baremans A.Stud Health Technol Inform. 2010;160(Pt 2):932-6. (Medinfo 2010 paper).
There might be ten to hundred thousand of clinical relevant elements that we need to standardize. But how do you eat the elephant? OK.
We (us and others, so the health informatics community with interest in this space) are currently working on a set of about 3000 - 5000 that are clinically, research, quality relevant. They are in different spaces. How many archetypes in the CKM would be ready for use at the moment? validated by clinicians and in practice?
Intermountain has about 3000 clinically driven, decision support, exchange, system etc.
Korea has about 500
NHS has about 300??
Netherlands has about 250 Use cases for this work have only been clinically driven, based on about a 10 clinical domains, and research driven.
OpenEHR has about XXXX
If we break these down to the core, we do see some differences in coding, in datatyping, etc. However, this is the level we talk about and it is indeed beyond the datatype.
The only hope I have is in cooperation and sharing and not blocking such work with copyright matters.
And, the hope that from this fine grained level of dcm creation we can move up into the larger modeling efforts e.g. in OpenEHR to represent an entry, in HL7 to represent a clinical statement and in UML to represent a small logical model in a larger architectural picture.
William
In a message dated 8-11-2010 4:05:33 W. Europe Standard Time, eric.browne@montagesystems.com.au writes:
This leads on to one of William Goosen’s favourite topics - that of Coded Ordinals. These have been introduced in ISO 21090 to meet the needs, often encountered in patient assessment forms, whereby weights are given to descriptive phrases to indicate the scope of functionality a patient has to perform, say, activities of daily living (e.g. Barthel Index). The weights can be used to derive an accumulated score for a collection of individual activities. Unfortunately, ISO 21090 can’t actually provide for this use case via the CO ( that’s code for Coded Ordinal ) datatype, because it has no way of denoting the set of allowed values. Such a set might look like
[ { 0 , “unable”}, { 5, “needs help (verbal, physical, carrying aid” }, {10, “independent”}]
i.e. a set of pairs of weights and phrases. A coded ordinal only describes one value, not the set of permissable values! Now, of course it would be possible to specify these sorts of sets, and to publish them for use in clinical systems and information exchange. My point is that ISO 21090 doesn’t support such a type and there currently is not a mechanism for this within HL7 - the primary standard for communicating clinical information. Even after all these years! I’d like to know how William, for one, hopes to solve this problem? Perhaps Ed Hammond has a solution in mind?
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen@results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713