CSCR-070 Expand Clinical Statement Scope for Public Health

Editing of Change Requests is restricted to the submitter and the co-chairs of the Clinical Statement Project. Other changes will be undone. Please add comments to the "discussion" page associated with this Change Request.

Back to Clinical Statement Change Requests page.

Submitted by: <<Austin Kreisler>>	Revision date: <<Revision Date>>
Submitted date: <<4/11/2007>>	Change request ID: <<CSCR-070>>

Issue

The scope of Clinical Statement is to narrow to be of full use for Public Health information exchanges.

Recommendation

Expand the scope of Clinical Statement so that it addresses needs of Public Health information exchanges. To be of real use to public health it must include entities such as populations, herds, locations, things of all sorts. This can be achieved either by expanding the definition of “patient” or by removing the limitation made by restricting Clinical Statement to the care of a patient.

Rationale

Expanding the scope of Clinical Statement will allow its re-use in areas that are not focused on the care of individual patients. Expanding the scope will avoid the creation of a second similar pattern that can be used for public health.

Discussion

In public health, we have been looking carefully at how to reuse the Clinical Statement pattern. With the current limitation on the scope of Clinical Statement, we have felt obligated to create a separate pattern call Public Health Statement that incorporates many of the features of Clinical Statement, but extends it in a fashion that makes it suitable for use in public health information exchanges. The current Clinical Statement is limited in that it only addresses care of patients. Although public health is concerned with the care of individual patients, it is also concerned with care of populations, places, things, etc. The limitation of Clinical Statement to care of patients is reflected in the pattern itself where the record target is limited to a person or animal in the role of a patient. In public health, virtually any sort of entity may be the record target of a public health investigation and the target of “care”.

There are far more things similar than different between what public health needs from a Clinical Statement like pattern than what exists today. Unfortunately, the current scope of Clinical Statement seems to preclude inclusion of those things that Public Health really needs to use.

Recommended Action Items

Prior Clinical Statement Scope

The model described in this document is a 'pattern' designed to be used within multiple HL7 Version 3 domain models. This pattern is intended to facilitate the consistent design of communications that convey clinical information to meet specific use cases. It is not intended that the 'pattern' itself is ever used in a communication, accordingly the information in this document is necessarily at a high level with a minimum of constraints applied. The pattern does not represent a Record Architecture or a physical structure for storing data on an EHR database, although it does cover many of the types of clinical information that should be part of an Electronic Health Record. The Clinical Statement ballot will include ballot topics (over time - common patterns such as Lab, Allergy, etc.) where those topics will be written such that they are as much as possible isomorphic with the domain models to which they correspond.

The formal definition of a clinical statement for the care of patients is:

"An expression of a discrete item of clinical (or clinically related) information that is recorded because of its relevance to the care of a patient. Clinical information can be expressed with different levels of granularity and therefore the extent and detail conveyed in a single statement may vary. To be regarded as a clinical statement, a concept must be associated with a patient in a manner which makes clear:

• Its temporal context
• Its relationship to the patient
• In the case of an observation, its mood and presence, absence or value
• In the case of a procedure, its mood and status

This clarity may be achieved by:

• Explicit representation; or
• Implicit application of defaults ONLY where explicitly modeled rules state the appropriate defaults."

Proposed Clinical Statement Scope

The model described in this document is a 'pattern' designed to be used within multiple HL7 Version 3 domain models. This pattern is intended to facilitate the consistent design of communications that convey clinical information to meet specific use cases. It is not intended that the 'pattern' itself is ever used in a communication, accordingly the information in this document is necessarily at a high level with a minimum of constraints applied. The pattern does not represent a Record Architecture or a physical structure for storing data on an EHR database, although it does cover many of the types of clinical information that should be part of an Electronic Health Record. The Clinical Statement ballot will include ballot topics (over time - common patterns such as Lab, Allergy, etc.) where those topics will be written such that they are as much as possible isomorphic with the domain models to which they correspond.

The formal definition of clinical statement is:

"An expression of a discrete item of clinical, clinically related or public health related information that is recorded because of its relevance to the care or investigation of patients or other entities. Clinical or public health related information can be expressed with different levels of granularity and therefore the extent and detail conveyed in a single statement may vary. To be regarded as a clinical statement, a concept must be associated with a entities in a manner which makes clear:

• Its temporal context
• Its relationship to the entity or entities
• In the case of an observation, its mood and presence, absence or value
• In the case of a procedure, its mood and status

This clarity may be achieved by

• Explicit representation; or
• Implicit application of defaults ONLY where explicitly modeled rules state the appropriate defaults."

Additional Changes

If this Change Request is accepted then further change requests will be submitted for the following changes:

1. Substitute the new R_Subject CMET for the existing R_Patient CMET in the Clinical Statement. This will allow entities of interest to public health to be the record target or subject of clinical statements. The R_Subject CMET is structured such that it is easy to constrain it back to R_Patient for non-public health related implementations. This proposed change is the one that really requires the change in scope for Clinical Statement. Without it, Clinical Statements will only apply to patients (persons and animals). With it, Clinical Statements can apply to virtually any "thing".
2. Add the Exposure Act (EXPOS) to the ActChoice structure along with the appropriate attributes. The details of the participations associated with Exposure are still being ironed out through MnM harmonization.
3. Add Public Health Case (CASE) to the ActChoice structure along with the appropriate attributes.
4. Need to generalize the location associated with a clinical statement. Currently location is limited to a service delivery location. From a public health perspective, any location, not just service deliver locations may be associated with a clinical statement. Add an Identified Location role scoped by the organization issuing the id for the location and played by the E_Place CMET. Also associate the A_SpatialCoordinate CMET with the Identified Location via a LOC participation. This will allow communication of any sort of location coordinates (GPS, Cartesian coordinates, Loran C, etc.).
5. Need to carefully consider how Role based identifiers are handled in Clinical Statement. In public health we need to be able to associate full scoper information with all identifiers used in roles. Not all roles allow the scoper to be the issuer of the id’s. Normally these problems arise with roles from the Partitive Role domain, but can also be found in the RoleClassPassive and RoleClassOntological domains. This means we need to include identified roles (IDENT) where the scoper is the identifier issuer associated with the other role via a role link.