Focused Care Management

1. 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

2. The Problem

Managing the care of patients with chronic illness is recieving a great deal of attention in national and regional projects. In part this is because these patient's healthcare providers see this as an area where care and outcomes can be greatly improved, and healthcare costs substantially reduced. In order to manage the care of these patients, 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 chronic disease management system, either on an ad hoc, or scheduled basis. There is also a need in Healthcare IT systems to easily identify the patients to which chronic disease management protocols apply, and who might benefit from enrollment in such programs.

There are two different levels for automation of chronic disease management. At the first, or entry level, is simply the collection of, and reporting of various statistics to disease 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 the current disease state recorded in the chronic disease 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.

3. Key Use Case

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.

4. Standards & Systems

<List existing systems that are/could be involved in the problem/solution.>

• EHR Systems
• PHR Systems
• Lab Information Systems
• Radiology Information Systems
• PACS Systems
• Cardiology Information Systems
• Registration Systems
• Practice Management Systems
• Registries and Repositories
• Decision Support Systems

ALL: Practice management, EHR, Pharmacy, Cardioligy information system, RIS, PACs, ADTs, PIX managers, XDS repository - CDM is the "ultimate user of EHR"

<If known, list standards which might be relevant to the solution>

• HL7 CDA Release 2.0
• HL7 Version 3
• HL7 Arden Syntax
• SNOMED CT
• LOINC
• ICD9/ICD10
• DICOM / WADO
• HL7 CTS

5. Discussion

Enrollement

Enrollment is 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.
3. 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.
4. A data gathering system is then initialized with information about those patients for whom the chronic disease management protocol applies. The initial data will include some patient demographics, and may also include CDM 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 proposal originates from Candada, where V3 support is paramount).
5. 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 CDM activities related to Disease X for patient Z. A wee

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 CDM by various staff, to gather additional data during followup activities.

One or more PCD profiles might be usefull to support gathering of CDM 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 and Steve Maher

Comments and Disccions 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.