DanRussler Dan Russler - McKesson

From: Russler, Dan
Sent: Wednesday, December 15, 2004 12:04 PM

[snip]

The situation is this...

In an instance of observation, act.observation.code may be specified as a domain with, for example, 3 values...

Domain = "Skin Exam"

Skin Exam Values = ("Skin color"; "Presence of rash"; "Edema")

If act.observation.code = "Skin color", then a value set for act.observation.value might be ("red"; "white"; "blue")

If act.observation.code = "Presence of rash", then a value set for act.observation.value might be ("present"; "not present")

If act.observation.code = "Edema", then a value set for act.observation.value might be ("not present"; "1+"; "2+"; "3+"; "4+")

Therefore, there seems to be several potential domains for act.observation.value

Domain = "Skin color"

Skin color Values = ("red"; "white"; "blue")

Domain = "Presence of rash"

Presence of rash Values = ("present"; "not present")

Domain = "Edema"

Edema Values = ("not present"; "1+"; "2+"; "3+"; "4+")

Is there a mechanism in our current tooling to:

1. record these domain relationships
2. constrain the domain of act.observation.value to be used only when a specific value is selected in the domain value set in act.observation.code

---

---

From: Solbrig, Harold R.
Sent: Wednesday, December 15, 2004 1:45 PM

As mentioned in the discussion, my take is that specifying these sorts of relationships is one of the roles of templates (Russ - do you agree?). The ability to access such information, however, is something that definitely needs discussing under the CTS II umbrella.

---

---

From: Hamm, Russell A.
Sent: Wednesday, December 15, 2004 3:25 PM

>Is there a mechanism in our current tooling to:

>1) record these domain relationships This is certainly an area where templates can be applied. From the HL7 Template and Architecture - Atlanta Draft, a template "can be used to guide and direct information input. Templates define which fields are required, which are optional and which cannot be entered along with the permissible value sets that may populate each field. "What information is necessary to fill in a CBC? What are the data types, values and selection lists for each of the fields?" Templates are object oriented and can be constructed with strict inheritance of constraint models."

Once defined, the template itself will be the structure that records the domain relationships.

>2) constrain the domain of act.observation.value to be used only when a specific value is selected in the domain value set in act.observation.code

Using the same statement above templates can be used (as above) to constrain the domain of act.observation.value to what you require.

As for tooling....

The openEHR Archetype Editor is an openEHR (open source) tool that enables an expert clinician to build archetypes ( read templates ). There are some archetypes modeled off the openEHR model that do pretty much the same type of constraining you desire. They also have some archetypes modeled off the HL7 rmim observation. If it is helpful/useful I am happy to dig up some examples.

Ramsey Systems (Charlie McCay) also has the rsMIF editor. I will have to defer to Charlie or Mat's expertise on where/how it can be applied to this specific case, or just do a little more investigation myself.....

---

---

From: Solbrig, Harold R.
Sent: Wednesday, December 15, 2004 4:33 PM

Thanks. It was much as I suspected. Regarding #2 - presuming we have the sort of assertion that Dan needs in ADL, what more do we need to do to get it into a toolable, distributable and ballotable format? Does the rsMIF editor record the information in 'native' HL7 format (whatever that may be...) or are there further digestions, transforms and the like that are needed to get it into a processable format?

Also, since this is a CTS II thread - what sort of tooling needs to be in place to allow an application developer to:

1. verify that a message fits a template and
2. guide the user via. pick lists and the like in filling out a specific template.

---

---

From: Russler, Dan
Sent: Wednesday, December 15 2004 3:53 PM If I can summarize,

1. Current tooling certainly supports the creation of domains and value sets
2. templates will both:
   1. record the dependancies and other relationship between a domain and a value in another domain value set
   2. offer constraint models for specific implementations of these dependent domains and values across attributes in a RIM class instance

---

---

From: Jane Curry
Sent: 12/16/2004 7:51 PM

Templates are intended to be able to do what was described below, at least as far as statements about the relationship between a valid value set for one attribute associated with the value of another attribute, especially in complex patterns. But the terminology services capability of linking two vocabulary domains is also required. Think of the relationship between vocabulary domains for the “Class” attributes and the corresponding “Code” attributes. That same kind of linkage could apply to value sets and values, I think. The ability to make those linkages explicit would be valuable, if only because known relationships could be stated once and then be “looked up” rather than “filtered with an expression” every time validation was required. It also increases the reuse of known vocabulary domain relationships across multiple template patterns. I think of templates as use case specific applications and the terminology services as “precompiled” terminology expressions, so to speak.