Difference between revisions of "DanRussler Dan Russler - McKesson"

From HL7Wiki
Jump to navigation Jump to search
Line 89: Line 89:
 
If I can summarize,
 
If I can summarize,
 
   
 
   
1) Current tooling certainly supports the creation of domains and value sets
+
# Current tooling certainly supports the creation of domains and value sets
2) templates will both:
+
# templates will both:
2a) record the dependancies and other relationship between a domain and a value in another domain value set
+
## record the dependancies and other relationship between a domain and a value in another domain value set
2b) offer constraint models for specific implementations of these dependent domains and values across attributes in a RIM class instance
+
## offer constraint models for specific implementations of these dependent domains and values across attributes in a RIM class instance

Revision as of 23:23, 24 March 2005

[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.

    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.


    >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.

    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.


    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