Simplifying Pressure Ulcer Templates for CCDA

The reason that Consolidated CDA went back to ballot was to fill out some missing detail in the assessments section.  When the ballot came out, there were three templates to report on pressure ulcers.  I submitted several ballot comments, asking in essence "Why so many templates to support pressure ulcers".  The response I got was that:

1. This was a high priority area for CMS
2. Pressure Ulcers are different from other things and need special attention.
3. We didn't have time to come up with a generalized mechanism.

I argued against the latter two, and proposed that I'd come up with an alternative solution.  Looking over the document, we see these three templates:

Highest Pressure Ulcer Stage

This observation contains a description of the wound tissue of the most severe or highest staged pressure ulcer observed on a patient.

Number of Pressure Ulcers

This clinical statement enumerates the number of pressure ulcers observed in a particular stage.

Pressure Ulcer Observation

The pressure ulcer observation contains details about the pressure ulcer such as the stage of the ulcer, location and dimensions. If the pressure ulcer is a diagnosis, you may find this on the problem list. The Problem Section shows a usage example.

The first two are observations about the patient.  The last one contains observations about a specific pressure ulcer (and in fact is an observation about a specific ulcer, with sub-observations).

The first two observations can be inferred from a a set of the third which are complete (in which all pressure ulcers for a patient are described).  

The middle template is misnamed, because it is not "Number of Pressure Ulcers", but rather "Number of Pressure Ulcers by Stage".  You cannot make the observation about all pressure ulcers for a patient, you must make it by number of ulcers at each stage.

The pressure ulcer observation template is a bit bogus because it includes only wound size (length, width and depth), and stage, and includes nothing else I've seen in descriptions of a pressure ulcer assessment.  Arguably, there are a number of observable entities about a pressure ulcer that you might want to capture, and each is part of an assessment for a given disease.  The "state" assessment that is currently the "chief" observation in Pressure Ulcer Observation is just one more attribute, it might actually represent the overall interpretation of the other attributes of the assessment.  Given what I've seen, actually I think this is just another attribute, at least for pressure ulcers.

So what I'm seeing is are two design patterns here:

One is a site-specified problem assessment in which findings related to a specific problem and site are gathered somehow.  These can include observations from a particular value set, with constraints on type or value associated with each type of observation.

The other design pattern is a patient assessment with respect to a condition, in which you'd have a similar set of codes and constraints on type/value associated, but these observations need not be gathered together in any way.

The latter (patient assessment) is pretty easy to deal with.  It really turns out to be a specialization of result, with constraints on codes and values.  In tabular form, we could put together the set of legal code values, associating each code with a data type or value set to apply to the value element.  These turn into "co-occurence" constraints inside the template.  


Fully expressed:


A patient problem assessment observation: 

1. SHALL contain exactly one [1..1] @classCode="OBS" (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6)
2. SHALL contain exactly one [1..1] @moodCode="EVN" (CodeSystem: ActMood 2.16.840.1.113883.5.1001)
3. SHALL contain exactly one [1..1] templateId (CONF:14728) such that it
1. SHALL contain zero or one [0..1] @root="templateId"
4. SHALL contain at least one [1..*] id
5. SHALL contain exactly one [1..1] code
1. This code SHOULD be selected from ValueSet ValueSetName ValueSetOID.
6. SHALL contain exactly one [1..1] value
1. when code/@code is X1, value/@value shall be of type v3:PQ 
2. when code/@code is X1, value/@unit shall be from ValueSet UnitValueSetName UnitValueSetOID
3. ...
7. MAY contain a reference to a specific problem observation (OK, not quite fully expressed, but you get the idea).

The former seemed a bit more challenging to model.  What I'd like to define is a template called an Assessed Site Organizer, which has an identifier, a code describing the kind of condition being assessed (i.e., The topic of the assessment: pressure ulcer), the effectiveTime, author, and the targetSiteCode identifying the site associated with the condition.  This won't work for a number of reasons.   While TOPIC is a type of organizer, isn't available in CDA R2.  An organizer should also have a required targetSiteCode which identifies the site being assessed, but organizer doesn't include a targetSiteCode attribute.


In CDA R2 (and in the RIM in general), any act can have components, so the need to use organizer is perhaps too much modeling in this case anyway.  What is being assessed is a disease or condition, and so we could just attach these observations to the assessed problem, or perhaps using the subject of relationship. The nice possibility here is that these assessments could be attached to the Problem Observation directly.


So, I did some rework, and realized that I could reuse a lot of the material listed above.


So, an assessed problem observation:

1. Is a problem observation
2. SHALL identify the problem assessed in the value element.
3. SHALL contain targetSiteCode
1. targetSiteCode/@code SHOULD come from the SNOMED Body Site Hierarchy
4. SHALL contains at least one [1..*] entryRelationship such that
1. SHALL @inversionInd='true'
2. SHALL @typeCode='SUBJ'
3. Contains a patient problem assessment observation relevant to observation/value.

Now, patient problem assessment and assessed problem observations themselves are abstract patterns. To instantiate them for Pressure Ulcers, we need to supply a few things:

1. A value set and constraints on type/value to apply to the code/value appearing in the observations.
2. A value set for the problem observation to restrict applicability.

From a coding perspective, what we are defining is a generalized "assessment" interface to a problem, and then specializing it for pressure ulcers by supplying a couple of related value sets and value constraints.

  -- Keith

P.S.  I hope you have a Happy Fourth of July