Most provider organizations have also implemented a collection of clinical ancillary departmental systems for such functions as laboratory, pharmacy administration, operating room management, radiology, cardiac catheterization laboratory, etc. Many large provider organizations have implemented some type of “clinical data repository” and associated applications that offer clinical staff access to integrated data regarding test results, profiles (including problems, family history, medications, and allergies), clinic scheduling, and practice guidelines or other clinical or policy reference materials. Such systems may be described as “electronic medical records”, “electronic health records”, “computerized patient records”, “lifetime medical records”, or other such names.
A smaller percentage of health care providers has implemented online applications for use by patients. Such applications may offer patients access to lab results, medication list, medication refill requests, health risk appraisal, and in some cases patient educational modules. Such patient-facing applications are commonly described as “personal health records”, “payer-based health records” or “member health records”, depending on what data is used to feed it and whether the patient is considered to be in control of the data and who has access to it. In rare cases, provider organizations have implemented tele-medicine capabilities that allow them to remotely monitor patients’ blood pressure, body mass, pulmonary function, blood glucose, and other physiologic variables, and to communicate with patients in their homes.
The Reward System Framework (described in greater detail here), involves the use of “care planning” technology, for use by clinicians to document the relationships between problems and orders, and to coordinate the inter-disciplinary review and input on draft care plans. Then, the execution of the care plan is orchestrated by a “clinical process management” component that utilizes workflow automation technology (also described as business process management, or BPM, technology). This sub-system includes the capability to support the prospective design of clinical processes, simulating the performance of clinical process designs (such as identifying likely bottlenecks), and monitoring the status and performance of care processes that are up and running in production clinical operations. This sub-system also includes the capability to define and administer a questionnaire, such as to capture a structured health risk appraisal, a functional outcomes survey, or a patient satisfaction survey. The clinical process management component is designed to handle a variety of clinical processes, including simple tracking of a single order through the steps of delivery, documentation and results communication, with provisions for escalation if orders are not completed in a specified time frame. The component is also intended to manage complex, long-running clinical protocols that involve coordinating different members of the care team across settings and time. As with the use of workflow automation or BPM technology in other industries, a clinical process management component is intended to include integration to call centers, e-mail, text messaging, instant messaging, interactive voice response, snail mail, and other inbound and outbound communications media.
Framework for Analytic Data Repositories
As noted above, an essential information technology capability of successful ACOs is an analytic data repository and associated reporting applications. There are a number of different design patterns that have been successfully used across many industries for analytic systems. However, in our experience, health care data is a particularly difficult type of data to work with for analytics, partly because it is not captured with analysis in mind, and partly because of the tremendous variation in the data due to variation in human characteristics, variation in care processes, and variation in the systems used to support health care organizations and health plans. The following framework is offered based on experience with what tends to work and not work across many settings.
According to this framework, data from numerous source systems are first brought into the analytic repository environment in a raw, versioned manner. This means that the data translations done as part of the interfaces that extract data from source systems and load it into the analytic data repository environment are kept to a bare minimum. Table names, field names, and coded values are maintained to match or closely align with those in the source systems. The raw data includes multiple copies of the same record, corresponding to different versions of the record as it changed in the source system over time. This raw, versioned set of tables is not just a “staging” area, to be used as a temporary “scratch pad” while loading data into more normalized tables, and then deleted or hidden from view by the data analysts that constitute the “users” of the analyzable database. Rather, it is made available to analysts on an ongoing basis. As analysts discover surprising, suspicious findings, the raw versioned data is available to them to support their “forensic” analysis to determine if there is some problem with the data or the transformations that were done along the way that accounts for their surprising findings.
Then, the framework calls for a set of “analyzable data” tables that are designed to represent the data in the most natural way, meaning that it is largely normalized, and it includes derived data entities needed to make the data accessible to analysts and clinical and business users. To create this derived data, a collection of “data derivation engines and services” are used. The most commonly used such engines or services involve logic to identify patients with a disease, logic to identify patients who needed certain evidenced-based services and whether or not they received the service (or whether instead there was a “gap in care”), logic to identify the beginning and ending dates of “episodes of care”, and “risk scores” that correspond with current severity of illness, the current burden of comorbid conditions, or predicted future outcomes such as total claims cost in the following year. Additional derivations that are less common but particularly relevant to the work of creating successful ACOs include logic to derive care relationships, logic to derive medical or surgical sub-specialties, and logic to characterize referral relationships.
According to this framework, the entire collection of derivation engines or services is supplied with input data obtained from the normalized “analyzable data” tables, and the resulting derived data is loaded back into that same database.
The “analyzable data” tables are then used as the source of data to create various summary data structures, including online analytical processing (OLAP) cubes. These summary structures, together with the “analyzable data” tables, are used to support ad hoc and routine reporting and reporting applications. In addition, some derived data is fed back from the analytic data repository environment to the “clinical data repository” to the degree that such derived data is needed to support health care operations. For example, a risk score may be derived in the analytic data repository environment, but may be used to select patients for outreach for a care management intervention. The outreach process is considered to be a production clinical process, so the source data for such a process should be the clinical data repository.
It is undoubtedly true that analytic data repository designs not consistent with this framework could also be successful. However, it is our view that adherence to this general approach will help more people to understand the data, decreasing the risk inherent in confusion by members of the teams building or using analytical data resources.