To illustrate this point, my development team recently worked with a group that was looking to create a system for monitoring immunosuppressant medication adherence in patients with a kidney transplant.8
As inputs, the system took the SD of previous immunosuppressant laboratory values, self-reported medication adherence information collected via a web-based system, and medication adherence as reported by pill bottles that track when they are opened and closed.9
These data were combined into an adherence score and presented in a report, along with the patient's risk stratification and recommended course of action. The total budget for the entire project, which was supported by an institutional grant, was US$100 000. As long as it was stand-alone, creating a similar system for other transplant types or to spread it to other institutions required minimal effort. Integrating such a tool into the EHR, however, proved to be almost impossible. There was no way to recreate the dynamic, self-reported survey tool or import the results, the EHR was not capable of computing SDs for the laboratory values, and it lacked functionality for integrating the adherence data. In the end, most of the decision support and risk stratification was jettisoned, leaving only the calculation of the adherence score, which had to be manually entered into the EHR.
As another example, my development team is halfway through a federal grant where we are working in collaboration with ImproveCareNow,10
a network of 36 centers focused on pediatric inflammatory bowel disease (IBD) that is aiming to build an ‘EHR-linked’ registry. Data are collected in discrete fields within the EHR during the clinic visit, extracted, and then uploaded into the registry. They could then be used for research, quality improvement, and clinical purposes such as pre-visit planning, population management, and patient engagement. An EHR-linked registry would achieve the long-cherished clinician goal of ‘data in once,’ that is, data initially collected for clinical care and then reused for other purposes. The ImproveCareNow network is a particularly good candidate for such a project as their registry data are the same elements that should be collected as part of model IBD care.
When we started the project, we approached the various EHR vendors represented in the network to ask them about creating and supporting a form that could be used by all of their customers. Aside from Epic, which quickly agreed to participate, the other EHR vendors have been very slow to respond. As a result, all of the non-Epic centers are likely to have to build and support their own data collection forms and create their own custom extracts, which poses a barrier to adoption. Since few institutions have EHR staff dedicated to handling research requests, this project must compete for priority against initiatives like the ICD-10 conversion and Phase 1 of Meaningful Use or the implementation of the EHR itself. Once we do have the attention of the EHR staff, we must ensure that the form is built so that it: (a) easily integrates into the clinical workflow (something frequently ignored by researchers); (b) can be completed quickly; (c) can, once completed, be pulled into a progress note or referral letter (also overlooked); and (d) has elements that are easily queried/extracted. If criteria a, b, and c are not met, then the clinicians will not use the form. If criterion d is unsatisfied, the enterprise reporting team will have trouble generating an extract. With EHRs, the easiest method of data collection is to typically create a text-based template where a clinician can fill in certain keywords. This leads most clinicians to believe they are capturing data discretely, but unless a significant amount of effort is undertaken to tag those keywords with a unique identifier, the result is stored as a blob of text. Other data collection methods may store data discretely, but do not integrate into the clinical workflow. The design of EHRs should be such that making the ‘right’ choice in terms of designing data collection forms is the easy choice.
Getting data into the health record is only half the challenge. After the forms are created, we face a second set of issues in transferring the data back out. In this project, we have taken the decidedly low-tech approach of having each center work with their enterprise reporting team to generate a report, which will then be uploaded to the registry. Two of the more sophisticated approaches to this problem, data transfer using the Health Level 7 (HL7) Continuity of Care Document (CCD)11
or the Integrating the Healthcare Enterprise (IHE) Retrieve Form for Data Capture (RFD) protocol,12
while appealing, are not suitable for our purposes. With the HL7 CCD, none of the condition-specific variables needed by ImproveCareNow are included in the specification. With RFD, an emerging standard that allows clinical trial forms to be embedded in the EHR and pre-populated with certain data, the data in the form are sent to a remote server. No data are retained in the EHR, however, which is a significant drawback when the data needed for research are also utilized for clinical care. In the end, far too much effort is spent working around the limitations of the EHR instead of developing better tools and interventions.