Focused Care Management

Proposed Profile: Focused Care Management

• Proposal Editor: Kboone
• Profile Editor: TBD
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: PCC

The Problem

A variety of special purpose health management systems have been developed to manage the care of patient with respect to diverse conditions, including chronic disease, cancer, immunization, et cetera. These systems utilize ad hoc data gathering to collect data from diverse health IT systems to populate data repositories, which are then used to support health management activities.

The purpose of this profile is systematically define the data gathering requirements of these systems in a way that supports existing and future system deployments, without the need for special purpose data gathering interfaces to be developed.

Special purpose health management systems can be used to manage the care of patients with respect to a wide variety of conditions, including chronic diseases, cancer, immunization, et cetera. Information can be provided to these special purpose systems from a wide variety of information sources, including:

• Physician Offices
• Imaging Centers
• Laboratories
• Inpatient Settings

The collection of this data that is increasingly available through health care IT settings can greatly improve outcomes by supporting health management, substantially reducing healthcare costs. This information can also be used to support wellness programs, public health monitoring and disease specific research.

In order to manage the care for these special purpose health management systems, several data points need to be routinely gathered that vary based upon the condition being managed. There is a need to be able to easily configure healthcare IT systems to gather these data points and submit them to a registry, either on an ad hoc, or scheduled basis. There is also a need in Healthcare IT systems to easily identify the patients to which management protocols apply, and who might benefit from enrollment in such programs.

There are two different levels for automation of this management. At the first, or entry level, is simply the collection of, and reporting of various statistics to the management systems. This is very similar to quality reporting profiles. The next level is a more active approach, which includes enabling decision support systems to actively alert providers, patients, or other interested parties to actively perform care activities, triggered by information currently captured in the special purpose health management system.

Such actions may include alerting providers or case managers to recent changes in various measures for a patient, automatically contacting patients to remind them of new visits or other scheduled activities to perform, et cetera.

Key Use Cases

Public Health Registries

1. Care Providers Define a protocol for Data to Gather
2. Patients are Identified for Enrollment in the Program
3. Patients are Enrolled in the Program
   • Patient Consent is obtained for Enrollment
4. Registry Data is Gathered from patients during routine healthcare
   • Decision Support Systems review and validate inputs
5. Additional data is gathered on patients based on information in the disease management protocol, and potentially on decision support feedback.
6. Decision support systems track changes and information provided during healthcare activities, and recommend other actions to support the care of the patient.

Chronic Disease Management

1. Care providers define a protocol for disease management.
2. Patients are identified for potential enrollment in a disease management program.
   • Patient Consent is obtained for evaluatioon
3. Patient demographics and clinical data are collected for stratification.
4. Patients are identified for enrollement.
5. Patients are enrolled in a disease management program.
   • Patient Consent is obtained for enrollment.
6. Disease management data is gathered from healthcare IT systems on patients during routine patient care.
7. Additional data is gathered on patients based on information in the disease management protocol.
8. Decision support systems track changes and information provided during healthcare activities, and recommend other actions to support the care of the patient.

Variations =

Support for Delayed Reporting

Reporting of information may occur at the end of a specific encounter, or at the end of a particular reporting period (day, week, month), depending upon the focus of the program.

Gathering Additional Information

The profile should support gathering of information that might not be tracked during a normal clinical encounters. In this case, as much data as can be gathered from traditional systems should be provided, and a mechanism to gather additional data should be provided.

Publish/Subscribe or Query/Response

Some systems may want to operate in a publish/subscribe model (e.g., publishing the subscribed to data using "unsolicited" messages). Others may want to operate in a query/repsonse model (e.g., HL7 V2 Query Message, or V3 Queries).

Standards & Systems

Systems

• EHR Systems
• PHR Systems
• Lab Information Systems
• Radiology Information Systems
• Cardioligy Information System
• PACS Systems
• Pharmacy
• Cardiology Information Systems
• Registration Systems
• Practice Management Systems
• Data Repositories
• Document Registries
• Public Health Registries
• Decision Support Systems

- FCM is the "ultimate user of EHR"

Standards

• HL7 V2 Unsolicited Observation, Control Query
• HL7 V3 Care Record
• HL7 V3 Care Record Query
• HL7 CDA Release 2.0
• ASTM/HL7 Continuity of Care Document
• HL7 Version 3
• HL7 Arden Syntax
• SNOMED CT
• LOINC
• ICD9/ICD10
• DICOM / WADO
• HL7 CTS
• HSSP RLUS
• IHE PIX/PDQ
• IHE RFD
• IHE XD*
• IHE QED
• NAACCR Standards for Cancer Registries, Volume I: Data Exchange Standards and Record Descriptions, Version 11.2. See:http://www.naaccr.org/filesystem/pdf/Standards%20Volume%20I%20Versoin%2011.2.pdf
• NAACCR Standards for Cancer Registries, Volume II: Data Standards and Data Dictionary, Version 11.2. See:http://www.naaccr.org/filesystem/pdf/Vol_II_draft_board%20-%20Fix%20Pg%2098.pdf
• NAACCR Implementation Guide for Pathology Laboratory Electronic Reporting Using v 2.3.1 of the Health Level Seven (HL7) Standard Protocol. See:http://www.naaccr.org/filesystem/pdf/Standards%20Volume%20V%20Final%20PDF%201-24-06.pdf(7) * HL7 Version 2.3.1 and HL7 Version 2.5.
• Implementation Guide for Immunization Data Transactions Using V 2.3.1 of the Health Level Seven (HL7) Standard Protocol. See:http://www.immregistries.org/pubs/index.phtmlhttp://www.cdc.gov/vaccines/programs/iis/stds/downloads/hl7guide.pdf
• HSSP Retrieve, Locate and Update Service: - Service Functional Model (SFM), balloted HL7 Draft Standard for Trial Use (DSTU),. See:http://hssp-rlus.wikispaces.com/September2006BallotedSFM-

Initial submission to OMG includes a profile that demonstrates immunization data retrieval and update in conformance to (2) above. See:http://www.omg.org/cgi-bin/doc?health/2007-09-01

• HL7 Version 2.3.1 and HL7 Version 2.5.

Discussion

Current Systems

It is highly desirable that the profile support the current installed base, which uses HL7 Version 2.X messages to convey information, but also support a migration path for forward development.

Enrollement

Enrollment is potentially a several step process.

1. Consents are [optionally?] obtained from patients prior to enrollment and/or stratification.
2. Qualifying patients are identified by examining clinical data. This is often done on an ad hoc basis. Ideally, this profile would provide a mechanism to define the clinical data that needs to be gathered in a way that the diverse health IT systems could provide the data without substantial configuration.

1. A second step might include stratification of the collection of patients based upon their risks, and application of different protocols based upon the degree of risk. The clinical data gathered is normally customized for each disease management program, as is the risk stratification process. Due to the diverse algorithms used to stratify and identify patients, no specific stratification algorithms should be defined by this profile. Instead, the outputs of the stratification process should be defined to support subsequent enrollment and data gathering activities.

1. A data gathering system is then initialized with information about those patients for whom the data gathering protocol applies. The initial data will include some patient demographics, and may also include specific clinical data. This might make use of the existing PIX Patient Demographic Source actor and Patient Identify Feed transaction (there is a need to support both V2.X and V3 messages, given that this part of this proposal originates from Candada, where V3 support is paramount, and part from the US, where a wide variety of V2.x messages are presently utilized).

1. Once initialized, the data gathering system would need to be accept clinical information from a variety of sources, including clinical documents, or various messages about healthcare events that are communicated to it. There may need to be a number of "data reciever" actors, which support the reciept of information from ADT feeds, XDS Document Registries, queries (see discussion on QED below), et cetera.

Data Collection

The QED Profile supports a query parameter (careProvisionReason) that could be used to identify clinical data appropriate to a disease management protocol. Thus, the reason for care provision in the query would identify the particular chronic condition being managed, e.g., Diabetes, Hypertension, Chronic Heart Failure, et cetera. The "Affinity Domain" would define the vocabulary used to manage it's CDM programs, and the various systems supporting the CDM program would need to be able to be configured to recognize this vocabulary. A QED query could then be issued which basically said: Give me all management activities related to Disease X for patient Z.

An extension and/or modification of QED would allow the query to be used through a publish/subscribe paradigm, using standard HL7 Version 3 Web Services messages, with the appropriate communication pattern. The present QED integration profile specifies the sending of a query with an immediate response. In the scenario where QED is revised to support this proposal, the same set of messages would be used, but the communication pattern would be one where an immediate acknowledgement is expected, and deferred responses are provided that are based on current patient activity.

Another paradigm to consider would be query management using QED, with responses being sent via other more traditional messaging systems, so that QED in effect supports a consistent way to manage and configure the parts of the system that gather and forward the messages, without necessarily describing a full web services based messaging architecture. This could be particularly helpful when dealing with legacy systems that do not support web service based messaging protocols. Since the configuration messages are essentially a new space, these would not necessarily be prevented from using HL7 V3 messaging.

The RFD profile might be utilized to support additional data gathering activities necessary. In some CDM protocols, it may be necessary to gather additional input not normally tracked by the EMR with respect to how various care provision activities are performed.

That profile might also be utilized during management by various staff, to gather additional data during followup activities.

One or more PCD profiles might be usefull to support gathering of data points from home monitoring devices.

Other Stuff

Additional transactions that might be helpful include alerts (see also Critical Results - Detailed Proposal and Patient Care Workflow), and Worklist support (see also Patient Care Workflow).

A key gap includes the specification of data points to gather, and how to configure systems to gather that data.

There is a great deal of overlap in this profile with current work in the quality space. That does not necessarily make this a quality domain profile. We do need to review this with Quality Domain membership, because they will have great interest.

Resources

Resources willing to commit to attending some days of some IHE working group sessions to help document the profile: Dave Heaney, Some interest from Jose Mussi, and Steve Maher

Comments and Discussions Points

Maher: How to track recommended treatment for diabetes, HBP, CHF, kidney tests, etc to form a data set. We also want to track patients who do not yet have the chronic disease, but may be at risk of developing it. Data sources are important: lab tests, patients wearing monitoring devices, etc

eg Vermont: 110 data elements that they want to monitor across different systems Problem: How do you specify what that looks like in a way that an electronic system can recognize it and start collecting the data?

eg: Arden syntax (HL7) has some mlm modules. They can take the inputs from a series of tests over a period of time and collect the tests and do a push to your inbox/screen/etc. (See Allie for more) (- may tie in with Quality domain acute and ambulatory quality measures)

Generalize this to a more general protocol, not just data gathering. FHTs (family health teams) get bonuses for following predefined steps.

See: protocol insertion proposal from last year

Support

Chronic Disease Management has been identified as a high priority by every Province in Canada, and there are several projects in the US that are also addressing this area.

This profile was developed as part of the IHE Workshop in Canada, in a session where a number (about 12) of IHE Canada members participated in the development of several proposals, and wherin this proposal was overwhelmingly accepted as the one to move forward to support at the PCC Planning meeting this week.