William,
I follow most of your posting, and I agree that much of the modelling of the
concepts you describe can be done independently of an implementation context.
[There is, of course, the question of tools that best help with this.] I
think, in many instances, you are seeking agreement on your
"mini-vocabularies", and help in defining them, in the first place? I've seen a
number of variants of just Barthel index from country to country. Variations
include the number of values for each component data element; the weighting
that should be applied to those values; the phrases that describe each value of
each activity of daily functions. And you would like some efficient way for
these to be edited, shared, stored and ultimately processable into systems. You
would also, I assume want an efficient way for these to be translatable from
language to language and become truly international standards?
Without going into a broader discussion on Detailed Clinical Models, I'd like
to just tease out the specific ISO21090 issue around CO (Coded Ordinal).
You imply that the enumerations can be associated with an OID, and therefore
made available to receiving systems for processing. I don't see how this is
possible, given the inheritance model for CO, which from my understanding goes
something like this:-
ANY
+ nullFlavor
+ flavorId
+ updateMode
QTY
+ expression
+ originalText
+ uncertainty
+ uncertaintyType
CO
+ code : CD [ 0..1]
+ value: Real [ 0..1]
Now are you actually implying that an OID associated with the code in the CO
not only constrains the vocabulary in the code:CD, but also constrains the
numerical value? In other words, we could have two vocabularies
[ {0, "unable"},
{5, "needs help (verbal, physical, carrying aid" },
{10, "independent"} ]
and
[ {1, "unable"},
{3, "needs help (verbal, physical, carrying aid" },
{7, "independent"} ]
and that these could be differentiated by different OIDs ?? How would that
work in practice? How would systems know that little trick? What terminology
servers know that under some circumstances they may not only have to return a
set of term descriptions, in response to an OID query, but some other
associated (numeric) data as well? Have the CTS/CTS 2 projects considered this
requirement?
Beyond this specific issue, there's a broader catch 22 here. Without doing more
clinical modelling, it is difficult to determine the implementation
requirements of datatypes and more complex data structures. Yet without
implementable datatypes and data structures and tools, it is hard to do, and
engender clinician's enthusiasm to do a great deal of clinical modelling.
That's why I think it so important to get behind and support the good work
already done with the openEHR Clinical Knowledge Manager. It seems such an
excellent vehicle for collaborative clinical modelling - irrespective of the
deployment environment. And certainly a tremendous step up from spreadsheets,
Word documents or pieces of paper! I and my colleagues wasted years in NEHTA
and in a clinical information project prior to that, trying with those archaic
tools to undertake a modest amount of modelling and share it with state
government health departments, clinical colleges etc. Not something I would
wish on anyone.
- eric
On 2010-11-08, at 5:36 PM, Williamtfgoossen at cs.com wrote:
> 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.
> 1. 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).
> 2. 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
> 3. 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 at
> 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 at results4care.nl
> telefoon +31 (0)654614458
>
> fax +31 (0)33 2570169
> Kamer van Koophandel nummer: 32133713
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
