t’s been more than five years since FDA issued its first regulatory approval using real-world evidence (RWE), a new indication for a medical device approved exclusively based on data from the electronic health records (EHRs) of patients who actually used the product in “real life” instead of data from randomized clinical trials. This approval was heralded as the onset of a new era in drug and medical device development and regulation: the systematic use of RWE based on data (real-world data, or RWD) from actual use.

For starters:

1. Most EHRs were not designed and built to support clinical trials or medical research but rather for patient care, diagnosis coding, and billing purposes. This often requires trying to fit the proverbial square peg into a round hole.
2. Many technology frameworks that support EHRs are nearly six decades old and often not agile enough for today’s data collection and data management needs.
3. Many healthcare providers customize their EHRs and EHR systems so that even the same systems/brands are not interoperable among different providers, making it difficult to collect data in a harmonized, automated manner that does not require time-consuming and labor-intensive manual intervention.

DIA GCP & QA Community Chair Terry Katz (Daiichi Sankyo, Inc.) hosted a DIA Global Annual Meeting 2022 Community Roundtable on Technology-Enabled Clinical Trials Using Electronic Health Record (EHR)-Derived Real-World Data: Opportunities and Limitations and continues this discussion in the following Q&A.

Terry Katz: Let’s focus on two policies: The General Data Protection Regulation (GDPR) in the EU and the Health Insurance Portability and Accountability Act (HIPAA) in the US. Both allow portability of data: If the patient leaves one doctor and goes to another doctor, they can bring their records with them. It’s not owned by the doctor; it’s owned by the patient. In the EU, GDPR goes even further: Once they’re a patient, their data is not to be used for certain purposes, including the hospital’s research. The patient must be told who would process their data and for what purpose, and they can choose to opt in or opt out. The hospital cannot say, “You are our patient, we will use your data.” They have the right to say no. They have the final say. They own the data.

DIA: Do the facilities that hold these records understand the value in connecting them to research?

TK: Hospitals get a lot of value from using patient data for their facility’s standard of care, so they can treat other patients with the same condition. They often conduct research to have their approach become standard of care in other hospital networks; it’s very prestigious to use your patients’ data to come to new conclusions. Most of that data must be anonymized, with no traceability back to the patient for patient privacy as stipulated definitively in the GDPR. This way, hospitals can provide the best care for that patient and leverage that learning for other patients.

During our discussion, one attendee raised the perspective that hospital records are structured for convenience within that hospital system. The US virtually mandated use of electronic health records going back to President Bush in 2004. A lot of that was for ICD (International Classification of Diseases) coding and for common billing coding, which helps interoperability. It made it more standard across the industry, but the configurations are not standard.

Each proprietary EHR has its own advantages and disadvantages. Each hospital, even each physician’s office, can flip certain switches to make it more usable for them. But what makes things more convenient may make things less interoperable, and that’s where a lot of the conflict has occurred: lack of interoperability. Which is a shame because the main benefit of EHRs is interoperability. If I go from one doctor to another doctor, the structures should be the same. If I go to a medical emergency room, it should be the same as the doctor. It’s both portable and stored in the central repository of my record. But a lot of places don’t have that. If you want continued care, you might have to keep going back to the same facility because your EHR is not transportable to another facility.

DIA: So, interoperability was already important, without even considering research objectives, for the purpose that these records and these systems were created?

TK: Most definitely. These systems were not created for research but for medical tracking of a patient. The idea of interoperability in this context allows you to see not just different physicians or specialists that might be recommended for a patient but also pharmacies and even potentially the paramedics and EMTs (emergency medical technicians) that come to their rescue. Conceptually, if a paramedic or EMT was able to tap into this system, they could see that you have a medical condition that would dictate use of certain emergency procedures and not others—contraindicated rescue medicines, for example. It has not gotten to that level yet. It’s still mainly at the hospital level.

DIA: These two words—standardization and interoperability—sound very similar, but would you explain the difference between them?

TK: Standardization: You predefine one strong structure and everybody follows that structure. Examples would be data submission to the government in SDTM, the CDISC standard data tabulation model that everybody must use—the same format, the same definitions, the same structure. That’s standardization.

Interoperable: I create my standard that works for me and my system. You create the standard that works for you and your system. But they are mapped, so they talk to each other, like a language translator. They’re not standardized but they allow each other to talk, understand, and convert.

DIA: How and where is lack of standardization impeding the translation of EHR data into RWD actionable for research?

TK: EHRs are built on HL7 standards for exchanging information between medical information systems. HL7 standards are produced by Health Level Seven International, an international standards organization, and are adopted by other standards-issuing bodies such as the American National Standards Institute and International Organization for Standardization.

When we submit data for research, we use CDISC standards such as SDTM. There’s also the Clinical Data Acquisition Standards Harmonization (CDASH) for data collection. So EHRs, which contain this information, and Electronic Data Capture systems (EDCs), which collect and capture this information, are not built on the same platform or to meet the same standards.

There are some conversion tools. FHIR is trying to make things interchangeable and predefine mapping. It’s not the same as being standardized by design and having a common platform, but FHIR is a good bridge to get from one part to another.

What we’d ultimately like to do in clinical research is to take these EHRs, since the data is already collected, and with the patient’s permission (because of those privacy requirements), pass the appropriate and only those appropriate variables to the EDCs. Then you have absolute transfer of data. Today, there is still a lot of manual transcription, which sometimes takes one to two weeks. You still have transcription errors. You have the effort to review the transcription, to question if the data it contains falls within or outside of the expected range, to go back to the physician with queries, and to monitor that the transcription was done correctly. All that could be accomplished seamlessly behind the scenes, and basically remove all that overhead and manual labor by transmitting data cleanly from the EHR to the EDC.

Let’s take a simple variable such as yes/no. That’s simple: It’s a yes or a no. Or is it a Y and an N? Or is it a 0 and a 1, or is it a 1 and a 2? If someone uses a 1 and a 2 but someone else uses a 0 and a 1, how do you map that data when you pull it together? Even if you have a standard approach to interoperability, the definitions of how those are structured, per hospital and per clinical research sponsor, mean that there are no absolutes. There’s a lot of programming involved.

DIA: If this “simple” yes/no” is so complex, other variables must be even more complicated?

TK: Gender, or sex, for example. The classic CDISC definition of sex (gender) is male or female. There are intersex—not countable. There are different orientations—not countable. In this respect, our current standard for clinical research does not cover our population completely and fully.

Race is an even more complex matter. The US has a guideline that encourages researchers and clinical trial sponsors to actively ensure diversity. Europe’s GDPR says that race is protected data and you should not even ask about it. We have an absolute contrast between these standards. A few years back, a cardiovascular product was approved in the US for patients of Black or African-American heritage. This concept doesn’t exist in Europe because that data is protected in their GDPR environment. They’re not looking for therapies that could benefit (or harm) a particular race because they don’t ask that question. So, you lose the advantage of tailoring the product, but you protect the patient from improper handling of their data. It becomes very hard to address these types of issues.

DIA: Are there pilots or other projects working on them?

TK: A lot of firms have small-scale methods within certain hospital networks to transfer data from the EHR to the EDC. They’ve essentially worked out a mapping pattern in the background to pull just the right data and convert it to that CDISC format to populate the EDC. But we work with hospitals all over the United States, Europe, Africa, Asia, and South America. They don’t all have these tools.

Is there any approach that will pull the data from generic EHRs into an EDC? There’s a lot of interest in and work on this. One vendor has created a little text box that you can use to cut and paste the data from one system to the other system. You go into the EHR, highlight the data, then cut and paste it to the EDC, and it maps your data in the background. It takes the entire record as is and puts it into another system verbatim, so there’s still opportunity for refinement down the road. But the concept of being able to go to any system, any place, is excellent. The challenge is that it must be done by the principal investigator’s office staff because there are a lot of personal identifiers and protected health information in an EHR that the sponsor should never see. The site which manages that patient does the cut and paste; this way, they control the accuracy of the transfer and what data is being seen. The sponsor or CRO only sees the populated result in the EDC and it’s still a one-to-one translation.

DIA: Copy and paste seems reasonably straightforward. Most of the work would be in preparing the EDC to receive that data?

TK: It’s a big incremental step. It’s better than typing in some respects, and it preserves the data, so it doesn’t have to be monitored at the data-to-data level. There’s still the possibility of cutting and pasting the wrong field to the wrong spots, so monitoring is still necessary. The ultimate EHR transfer, transferring just the right data directly into the EDC with mapping files, with identical standards, would eliminate the need for monitoring because it would be seamless by design. This new advance is not yet seamless, but it’s certainly a big step in the right direction.

DIA: Is there still a significant amount of data locked in paper around the world?

TK: The US has had the mandate to have the Medicare coding, structured ICD coding, since 2004. Yet we know that some areas are not fully electronic, and some of these might be certain communities. I don’t know if Native American nations have electronic health, but there are certainly questions about whether they’re getting healthcare support. Parts of the US still have limited electricity or computer networks. It’s a small proportion of the US, but if we look at other places in South America, in Africa, in Asia, these limitations are more prevalent.

Some countries have a different vision, and it may work very well for them. I worked in a fellowship in Africa where they have set up many billing systems more by phone, where you load money into your phone company account and then transfer your payment to the vendor, instead of by credit cards or cash. They have a very effective system, but it’s different than what Europe and the US do. How much of that has implications for electronic health records and health data? We do not know.

DIA: Has the emergence of decentralized trials helped advance these EHR-to-EDC conversations and solutions, or has it made clinical trials so complicated that now we’re stuck?

TK: We are not stuck. Industry has come up with some interesting innovations to ensure that clinical trials can continue, some of which could potentially lead back to routine patient care. Remote technology has been used for remote monitoring because monitors and clinical research associates could not travel to the sites during the pandemic. Sites would not let them in because there was exposure potential, so monitors had to become more innovative in how they approached places and used remote technology to do a thorough monitoring visit. There have been instances when the medical record, electronic or on paper, was held up to a computer screen and shown to the monitor as the source where the data originated. CRAs could still monitor but it was awkward. Transferring data by electronic means would be so much better because it would minimize the need for this type of monitoring.

The decentralized trial environment is good because it brings the trial to the patient. But if a physician or nurse comes to a patient’s house to administer their medicines for the trial or to record their vital signs, what do they collect that on, paper or a tablet? You can have a remote visit to a rural area and collect data on a pre-made paper form or on an electronic tablet that uploads the data to the electronic data capture system. A few EDC firms (very few) have an integrated tablet that collects information, some that work with the internet and some that work offline. These offline (noninternet) systems help in rural areas and even shielded medical wings (such as radiography bunkers) and other locations lacking internet. Data is uploaded into the EDC later. But there have been so few of these systems that they have not been used much yet.

I assisted in developing one of those systems, so I know they work very well and can become part of this technology solution. There has been a great discussion on support for using this technology among our DIA GCP & QA (Good Clinical Practice and Quality Assurance) Community. What are the challenges from the GCP perspective? Can we control data privacy? Can we make sure that the system works to meet all the GCP system validations? Our Community is working on these areas right now, with the goal of presenting our findings through a presentation or publication.

DIA: What would make the most short-term difference in this EHR-to-EDC space?

TK: I would love for the FHIR bridge to be very active and usable. As a user from the sponsor side, I’m looking for a way to move that permitted data, whatever the patient agrees to allow to be transferred, to that EDC seamlessly. It needs to work in every country around the world. We run clinical trials on six continents. We need all six continents, whether urban or rural, to be able to move these critical data. You want the data to come across smoothly. Japan, a member of ICH, has implemented its own EHRs. In Africa, Kenya is working to back-populate EHRs from its paper record systems. We hope that some of this manual process can be taken away, or reduced to a minimum, so we can focus on patient safety, patient efficacy, and data integrity.