Virtually Priceless Thoughts

In BC there has been a lot of discussion about setting up an EMR-based primary care research network (PCRN). Or rather, there are talks about different types of research networks. Some existing in other provinces and some being considered to be built in BC.

This will likely be the first in a few posts about PCRNs. Today, types of EMR-based PCRNs.

Types of EMR-PCRNs

1. Contained within the EMR

This is probably the simplest model. All providers are on the same EMR instance and can run queries in their database. Depending on the size of the practice or if they are using a distributed EMR (e.g. multiple practices sharing the same EMR), this can work just fine. With some products, this could even scale up to 100s of clinicians on a single, enterprise wide system. It does require that everyone would be on the same EMR and that someone in the group could run the appropriate queries on the database. It does not require a level of harmonization of the data models as there is only one model.

Data can be analyzed within the EMR and then tools like Excel can help the clinician / researchers set up the reports for reporting / publication (if the EMR does not do what’s needed).

2. Patient Data exported to Central Repository

Here, specific data is routinely (or automatically) extracted from the EMRs involved. The data is at the patient level, although typically de-identified to some degree. A central server collects the data and the queries are completed on the de-identified data. Depending on how, or if, data is de-identified, it could be linked to other data.

CPSSCN in Canada uses this model, although there is an additional layer as de-identified data is aggregated at two levels. CIHI has a Voluntary Reporting System (VRS) that is similar.

Options 1 and 2 are two ends along a spectrum. Between these are some interesting hybrid options.

3. Exported EMR Reports

In BC, there have been discussions around how can one engage multiple groups on different EMRs to engage in a variety of research projects without collecting ANY personal health information (identified, de-identified or otherwise) into a PCRN. Paper practices does this with various tally sheets and anonymized data collection forms. In EMRs, one could develop standardized reports that run in the EMR that generate practice or provider-level information that can then be shared. The reports could be manually shared or (more rationally in the electronic world) developed into a standard format (e.g. XML) that can then auto-populate a central server. The central server is without any patient data, even de-identified data. Instead it has data at the provider / practice level.

The role of the central server can be more on presenting data back to members of the network.

The issue with this model is one of practical scalability and flexibility. The network is directly dependent on each EMR being able to create new queries in time to answer each question. True, some strong products with advanced users could build these queries without direct programmer involvement, but there will likely be some products and some questions that need more technical work. Then there are issues. There are also issues when complex queries slow down an EMR in a large practice. This brings me to the fourth option.

4. The “Edge Server” (aka the Distributed Data Warehouse)

Another way, one which there have been several conversations about is to use a kind of “edge server” that sits at the edge of the clinicians network and are designed to support querying without exposing their data. “Edge server” is a term that can mean many things. In this context, I mean to describe a server that sits on the edge of the clinician’s network and syncs patient data with the EMR on one side and exposes a query engine to the central PCRN server on the other side. The edge servers do not expose patient information to the central server, but they respond with answers to questions. Think of it like a distributed data warehouse (if it isn’t too much of an oxymoron).

The edge server contains a copy of (select) EMR data that has been transformed into structure that (a) is consistent as possible across EMRs and (b) is designed for complex queries. For argument sake, let’s say there is one edge server / practice EMR (and a practice could have many doctors). The PCRN has a single central server that manages the nodes (including security, pushing out updates, pushing out queries, etc.), hub and spoke style.

The interface between the EMR and the Edge Server should be fairly static. By keeping this interface static, the EMR vendors won’t need to be regularly asked to make adjustments. Keeping the components loosely coupled would be preferred (sharing data through a set of CDA or plain XML messages). This way EMRs can be brought on board with a focused effort and less maintenance. To be static, there needs to be a good, up front understanding of the majority of questions that would be asked within the network.

The query engine would allow for the PCRN central server to pose a single question that would then be distributed to all the edge server nodes in the network. The edge servers then query their data stores and can report back answers to potentially very complex queries in near real time back to the central server without exposing patient data.

This is the simple Edge Server model. Additional features that could be considered include:

• Selective Participation – where the members of the PCRN can be selective as to which studies they want to participate in. This is less important for a transparent network and more important if there are features in the PCRN like Realtime Recruitment and Additional Data Collection.
• Realtime Recruitment – for some studies, patients would need to be recruited in realtime (e.g. when they arrive, are checked in, or are seen by a physician). Exposing another service (between the EMR and the Edge Server) would allow the Edge Server to do an initial screening of patients for more prospective type studies. The Edge Server could then return a recruitment alert complete with consent forms.
• Additional Data Collection – for some studies, there would be a need to collect additional data that may not be either routinely collected or collected in a manner than can be consistently processed (e.g. free text). With some careful design work, this could be accomplished. The key issue here is ensuring that the data collected are stored in the patient’s EMR and not just on the edge server (the edge server is not a clinical source of truth). This does mean that there is a greater and greater interdependency between EMRs and the Edge Server in terms of data design.
• Knowledge Translation Service – finally, as knowledge is generated, it should come back to practice. By re-tooling the realtime recruitment service to a KT service, then information can be shared back to clinicians on applicable evidence for patients at the point of care. This can also be important if the findings from a study require that the practices search for specific patients meeting specific criteria (e.g. a recall on a drug in a specific population). Both the KT engine and the recruitment engine are both forms of CDSS and likely could leverage a large number of shared components.

The Edge Server concept has captured the imagination of several of the researchers and faculty in BC.