Focused Care Management

From IHE Wiki
Revision as of 09:14, 5 November 2007 by Wendy scharber (talk | contribs) (→‎Support)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


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 patients with respect to diverse conditions, including chronic disease such as 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 and public health activities.

The purpose of this profile is to 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 such as cancer, immunization, et cetera and to monitor the health of the population as a whole. Information can be provided to these special purpose systems from a wide variety of information sources, including:

  • Physician Offices
  • Imaging Centers
  • Laboratories
  • Surgery Centers
  • Inpatient Settings
  • Insurance Providers

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 of the patient using 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 for Healthcare IT systems to accurately and efficiently identify the patients to which management protocols apply, and who might benefit from 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 data/statistics to the management and public health 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, 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 Inclusion in the Program
  3. Patients are Included in the Program
    • Patient Consent is obtained for Enrollment [optional]
  4. Data that was obtained from patients is Gathered 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, recommend other actions to support the care of the patient, and transmit information according to public health requirements.

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 and requirements of the program or public health reporting system.

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 data using "unsolicited" messages). Others may want to operate in a query/response model (e.g., HL7 V2 Query Message, or V3 Queries).

Standards & Systems

Systems

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

- Focused Care Management is the "ultimate user of EHR"

Standards

http://www.cdc.gov/vaccines/programs/iis/stds/downloads/hl7guide.pdf

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.

Reporting/Enrollment

Reporting/Enrollment is potentially a several step process.

  1. Where Required, 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.
  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. Alternately, stratification may occur based on federal, state, or local reporting requriements. 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.
  4. 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 Canada, where V3 support is paramount, and part from the US, where a wide variety of V2.x messages are presently utilized).
  5. Once initialized, the data gathering system would need to be able to 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 receiver" actors, which support the receipt 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., Cancer, 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 configurable 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. Cancer Domain: Sandy Thames, Wendy Scharber, and potentially other cancer community experts.

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

This profile also has the support of AHIC and HITSP. "Public Health Case Reporting" has been identified as a possible 2008 Use Case and there are several projects in the US that are also addressing this area.

A portion of 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. Chronic Disease Management has been identified as a high priority by every Province in Canada.

Retrieved from "http://wiki.ihe.net/index.php?title=Focused_Care_Management&oldid=11175"