This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Product CS

From HL7Wiki
Revision as of 18:34, 10 December 2009 by Llaakso (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Product Brief - Clinical Statement Pattern

back to Main_Page

Product Name

HL7 V3: Clinical Statement Pattern, R1

Topics

  • Common clinical data in the Pharmacy, Laboratory, Patient Care, Public Health, Clinical Genomics, Orders, Observations, Documents, Allergies, and other domains

Standard Category

  • Health Information Exchange Standards

Integration Paradigm

Type

DSTU exp Dec 2009

Releases

HL7 V3 CS, R1: HL7 Version 3 Standard: Clinical Statement Pattern, Release 1 - November 2007

Summary

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. In most cases the pattern will be refined for use within the model using the clinical statement.

Description

The Clinical Statement pattern has been under development since January 2004 as part of a joint initiative of the following Technical Committees: Orders and Observations; Patient Care; and Structured Documents. A DSTU version has been available since September 2007 while work is in progress to create a new version (targeted for 2010).

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. In most cases the pattern will be refined for use within the model using the clinical statement. There are two CMETs based on the pattern - COCT_MT530000 A_SupportingClinicalStatement universal and COCT_MT530004 A_SupportingClinicalStatement minimal.

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 Clinical Statement model is deliberately broad and encompassing. As a result, it would be possible to represent a particular statement in more than one way. Further guidelines to ensure consistent use must be developed in concert with the domains using Clinical Statement.

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.

Business Case (Intended Use, Customers)

HL7 Work Groups are the primary customers of this pattern.

Benefits

The Clinical Statement pattern represents a standard, high-level structure for the inclusion of clinical information in communications intended to support specific business functions. Although not capable of being implemented 'as is', the Clinical Statement pattern can be constrained to meet the requirements of many specific communications regarding clinical information. The process of modification will involve either pattern constraint or extension (or sometimes both) in order to achieve the needs of a particular domain.

Implementations/ Case Studies (Actual Users)

CDA R2, Orders, Medication, Lab Results, Clinical Genomics, Family History, Patient Care - Care Summary, Observations, Blood Bank, Public Health Statement

Resources

Work Groups

Education

Certification Available
  • none

Presentations

Relationship to/ Dependencies on, other standards

  • RIM and various CMETs from other work groups.

Links to current projects in development