A Problem is NOT a ….

1. A Problem is NOT a …. Problems / Diagnoses and the RIM Patient Care Committee 9/16/98

2. Mayo CEMR example (1995)

3. Problem specification Diagnosis is one of these

4. Linkage to other elements

5. Relationship to problem lists and “episode”

6. Critical linkages Ability to “relate”to other problems Ability to link toorders and findings Separation of “diagnosis” from problem Ability to aggregatein lists

7. Core thesis • I am less concerned how we define "Problem" than that we not make it and a Diagnosis (or symptom or sign) synonymous. • If we have separate classes for Problem and Diagnosis, AND • if we allow for them to be related, then it is possible to address all of the concepts people espouse.

8. Thesis (cont) • HL7 does not have to define a problem vs a diagnosis, etc. That would be endorsing one of many "theologies. • However, HL7 does have to enable each of the variants to be communicated if it is to support applications from all of the "theologies."

9. Support • Gerard Freriks: • "Problem is a subjective grouping of data items" • Stan Huff: • "A problem has a different life cycle than a diagnosis" • Karen Keeter: • "One of the possible options is to include diagnosis (in the administrative sense) in some relationship to problem, such that a problem can be communicated with or without a 'formal' diagnosis" • Each of these speaks of the differences between problems and diagnoses, and argues that they are not a single class.

10. Current dilemma • Tim noted, when the USAMP proposal was formulated, • "Our group slowly formed the consensus that from a practical inter-application messaging standpoint the distinctions were not very important” • As a consequence of this decision, as Gunther said • "[Woody suggested that] ... diagnosis or observation can be linked to the Problem but is not identified with the Problem itself. I find this a very valid and interesting definition. However, I don't see the current RIM 0.84 or 0.85 definition and attribute set of Problem to reflect this interpretation"

11. Further concerns • The word “problem” connotes illness, whereas there are wellness, or behavioural attributes that clinicians may seek to relate in an identical construct • Alternative names • Health status item • Condition • Focus of care • Focus of health activity (action) • ???? • ????

12. Observations with respect to RIM 0.86 • Administrative diagnosis needs to be removed from the “clinical tree” as it does not result from clinical processes and it is not clinically reliable. It is an artifact of billing requirements and should be identified and isolated as such. • Structurally, the positioning of “Problem” as a specialization of Assessment (which is a specialization of Service_event) is OK, as the Service_event relationship will accommodate the relationships I suggest will be desired • There would appear to be a need to define both a time of instantiation and a responsibility for instantiation of the Service_event relationship to meet needs such as I foresee. (Attributes or associations)of the relationship

13. “Problems” with Problem class • There would appear to be a need for a “diagnosis” class, because- • A review of the Problem class attributes reveal that it started life as a diagnosis, and I believe we have made a case that problem and diagnosis are distinct entities. The attributes which seem to be “diagnostic” (as opposed to “problematic”) include: • confirmation status • institutional sensitivity • nm (“standard code for the problem_diagnosis”) • prefix • probablility_pct • problem_certainty