With the announcement of Comprehensive Primary Care Plus (CPC+), the Centers for Medicare and Medicaid Services (CMS) has started a program that may influence EHR design as much as MU has impacted EHR adoption. CPC+ has two tracks, and both require use of certified EHR technology along with reporting of clinical quality measures. Track 2 offers higher payments, but with an interesting twist – Track 2 practices must use EHR systems with specific CMS-defined features. The required features provide support for clinical work typical of primary care practices and go far beyond MU certification requirements.
Having learned from experience, CMS is requiring Track 2 practices to secure letters of support from EHR vendors who promise to provide the required features. In addition, EHR vendors are required to file a Memorandum of Understanding with CMS. The existence of Track 2 EHR requirements is an acknowledgement of lessons learned from past CPC efforts as well as MU: EHR systems have been designed to replace paper charts, not to support clinical work (see Is the Electronic Health Record Defunct?). CMS has jumped into the EHR design business in a big way!
One misconception about clinical work that seems ensconced in EHR designs and payment modalities is that direct patient encounters are when most clinical work occurs. Clinical care requires not only face-to-face encounters, but also time speaking with families, reading guidelines, reviewing labs, care planning, speaking with consultants, doing literature searches, and other unseen actions that contribute to quality care. Paper charts and, by extension, electronic charts designed to replace them, do not assist with these activities. Fortunately, CMS sees the light and is mandating EHR systems that are capable of supporting the wide range of activities that comprise clinical work.
While I am delighted by the feature-set CMS is requiring, I am also a realist. Adding these features to current data-centric EHR systems will be much more challenging than anything required by MU, interoperability being the exception. Let’s look at two enhancements requested by CMS (see Appendix C) that exceed MU 2014 certification requirements. Remember how much trouble vendors had getting products ready for 2014 criteria?
Requested Enhancement: Document and track patient reported outcomes
CPC+ Objectives for use of HIT – CMS is evaluating a patient reported outcome survey instrument that will be sent to CPC+ Track 2 patients to identify specific care needs requiring intervention/management by the CPC+ practice site team. CMS plans to use the data collected from the patient-reported outcome survey to develop a patient-reported outcome performance measure that may be included in CPC+ measure set in the later years of the model. The modes of administration are yet to be determined.
The health IT tool should provide the care team with the ability to administer the survey, store and track patient responses, and score results longitudinally for each patient surveyed.
The practice should be able to review the patient responses/results in their EHR or other health IT tool and, as appropriate, establish care plans /interventions for positive findings.
Outcomes are important for understanding and assessing care quality. Here CMS is endeavoring to make outcomes an ongoing management tool for practices. An EHR that can administer surveys, store the results, and integrate those results into a clinician-friendly interface is a tall order. There are so many workflow challenges here: tracking survey status, tracking patients over time, triggering interventions based on results, and linking results to care plans to name just a few. A sophisticated analytical/reporting component is also required. Though CMS allows for “HIT tools” alongside an EHR, I can imagine huge integration nightmares in trying to share process and patient data from an external tool to an EHR. Having recently used the patient portal of a major vendor to communicate with my PCP, I would say current patient portals are not the answer. Similarly, managing so many processes without workflow technology will require a huge programming effort. Essentially, vendors will have to build some level of workflow capability into current systems. Again, I would like to point out the problems that occurred in trying to meet 2014 MU certification criteria.
Requested Enhancement: Establish a patient focused care plan to guide care management
CPC+ Objectives for use of HIT – CPC+ practices should utilize an IT-enabled, patient-centered care planning tool in order to support holistic care and a focus on beneficiary goals and preferences.
Enable providers to electronically capture the following care plan elements:
Advance directives and preferences for care b. Patient health concerns, goals and self-management plans c. Action plans for specific conditions d. Interventions and health status evaluations and outcomes e. Identified care gaps
The practice should have the ability to customize which of these elements are included within the care plan and how these elements are displayed.
Providers should be able to incorporate relevant triggers (e.g. a risk score or event) that indicate different care management actions.
The care plan tool should facilitate version control across care team members by capturing the date of the last review or change in plan and generating a scheduled date for reviewing and updating the plan.
Practices should be able to populate the care plan using data entered in the patient’s record (e.g. without duplicative data entry).
The care plan should be available to the patient on paper and electronically, and available in electronic format to care team members outside of the practice that are involved in the patient’s care. Care plan information should also be remotely accessible to practice team members delivering care outside of normal business hours.
To support this objective, practices must adopt certified health IT that meets the 2015 Edition “Care Plan” criterion found at 45 CFR 170.315(b)(9), within the first two years of the program.
The 2015 certification requirement’s focus on care planning is, conceptually speaking, a great idea. However, looking over the actual criteria, I see a huge problem: care Plan capabilities are built on CDA documents. Care plans are workflows; CDA documents are data. Creating data types or documents to hold care plans is not the same as providing process support to manage those documents. It is data-centric thinking all over again (my apologies to Yogi).
Care planning should be a central, if not THE central, clinical work support feature of a clinical care system. As things now stand, EHR systems are organized like paper charts – by information type: problems, labs, radiology, notes, and medications. Clinicians are then given the task of integrating the information as an ongoing mental exercise. Finding the information needed to make decisions or to get a picture of the patient’s state requires numerous clicks and screen jumps. Current EHR systems are organized to present and store data, not to intimately support clinical work, which is the ultimate goal of CMS. Achieving the objectives set by CMS requires a process-based approach. For example, CMS states that practices should be able to set triggers, and have some type of version control capability for care plans. Designing a system to meet CMS requirements necessitates leveraging at least three kinds of information: patient, process, and logic (or rules).
Patient information is what is traditionally stored in EHR systems—labs, medications, notes, etc. Tracking patients across care transitions requires process information — data about where the patient is located physically and within the process. For example, a patient sent for a referral can be monitored by simple binary data (i.e., did or did not keep referral appointment). Alternatively, the patient could be actively tracked with a system that performs the following actions:
- Contacts the consultant to alert them a patient is on the way
- Emails reminders to the patient one week and 48 hours before the appointment
- Allows the patient to send feedback to the practice about intent to keep the appointment
- Contacts the consultant practice 24 hours after the appointment to ask for his/her findings and conclusion.
Binary monitoring is data-centric, whereas active tracking is process-centric.
Logic information keeps track of preferences and clinical rules. Triggers are a type of logic information. Clinical care systems that intimately support clinical work necessarily use all three types of information and treat them as equal partners. Ideally, each type of information should be housed and managed independently so that each can be updated or changed without directly affecting the others—basic loose-coupling and high-cohesion principles.
The features CMS desires are best realized in a system that is made of components where each component houses specific functions and communicates with others via APIs. For primary care, the clinical components might be: patient outcomes, care planner, results management, referrals, documentation, analytics, mental health, and quality reporting. These modules would rest on top of an infrastructure that had logic/rules management, workflow management (engine and visual programming tools), record functions (patient data and semantic controls).
Comprehensive Primary Care Plus is a bold policy step, especially in terms of HIT expectations. The CMS requested HIT enhancements tacitly acknowledge the importance of task support in clinical work. The question is whether vendors will acknowledge the process-based nature of these features or try to kludge them onto data-centric EHR systems (see Data and/or Processes: The Designer’s Dilemma—prn: CIM-OnCall, II and Clinical Software Design Principles). The transition from 2011 to 2014 certification criteria tripped up a lot of EHR vendors even though the requested changes were not onerous. Well-designed data-centric systems made the 2014 certification cut because the criteria were mostly about adding new data capabilities. However, CMS has upped the ante with its feature requests. Now, the game is process support, and even well-designed data-centric systems will have trouble adding the required level of process and analytic support without extensive and costly programming changes.
It will be interesting to see which companies decide to sign-up for the program. However, in the end, it doesn’t matter how many participate — intimate support for clinical processes is becoming a thing. Enough clinicians have experienced EHR systems and are learning how to choose between systems that make them more productive and those that them miserable. When the former appears they will be welcomed and CMS is, unwittingly or not, stirring the pot.
Recently, someone asked me how entrenched vendors could ever be displaced. We are seeing how it will happen with this policy initiative (see The Future of HIT Innovation is Ambulatory). As process support becomes more wished for and wondered at, it will be increasingly difficult for data-centric systems to keep up. At some point, the data-centric way of doing things will be obviously worse than process-centric approaches, and clinicians will vote with their pocketbooks and according to their misery.