Archive for the ‘Uncategorized’ Category
I have been thinking about the goals of primary care research networks. One of them is to engage members. In a recent discussion at the CFPC section of researchers, we named three roles in a network:
researchers – people developing the grants, studies, running the analyses, writing the papers.
collaborators – practitioners and patients who are involved in setting priorities, engaging in performing the research and providing access to information to help answer the questions.
users – people who consume the information generated from the network. These can be people in the network and outside the network.
An individual could play all three roles, of course. It could be that I am researcher in one project, collaborating on two more that interest me (by contributing questions, parts of answers), and being a user of findings from all the other research.
Most providers today are knowledge users. Members of research networks are collaborators.
How to increase the number of collaborators?
Networks are one – intel decrease the barriers to contributing and they can help to shift the culture to collaborative research. I am interested in this space as well as supporting people becoming contributors.
Restructuring medical practices so that the environment facilitates the collaborator role. The medical home concept can provide the structure and space for groups to act as collaborators in generating and validating knowledge. In Canada, the medical home is becoming a bigger push and it has a clear goal related to research: ([from the CFPC](http://www.cfpc.ca/uploadedFiles/Resources/Resource_Items/PMH_A_Vision_for_Canada.pdf))
Goal 8: Patients’ Medical Homes will serve as ideal sites for training medical students, family medicine residents, and those in other health professions, as well as for carrying out family practice and primary care research.
How do we support (and evaluate) this goal? How to include PBRN connectivity into this goal? It would be interesting to have requirements for medical homes to include engagement in a network. Further, aligning QI activities and leveraging action research methods that directly improve the lives of the collaborators are also helpful in engaging.
I was in an pan-Canadian EMR Benefits Evaluation meeting today hosted by Canada Health Infoway. A little heated debate came up around the value of coding data. Some fell on the side of don’t bother coding, use free text and fix it later”. I fall on the other side of trying to do it right the first time. Clinicians can code and I think they should, so they can get some of the advanced feedback and functions of EMRs
I am a supporter of free text -d on’t get me wrong. Narrative is very important to our current recording practice. However, selective coding does have value in places like medications, allergies, problem lists (labs should have attached codes from the lab automatically).
However, if it takes the physician 30 seconds to properly code an item on the problem or if a user needs to memorize SNOMED CT codes likethen we are designing our EMRs wrong.
Rather than saying don’t bother coding, I suggest we should be asking:
How can we make the User Experience so elegant that coding is seamless?
The FutureMed conference ended on Saturday (Feb 11) at the NASA Research Park. Successful conference? I definitely feel like it has been an amazingly successful week. How to think about success for a conference like this? How about three ways:
- New Ideas and Actions
We were presented with huge amounts of data and information. Big Data was topic, but it really was how the sessions were arranged as well. I enjoyed the range of what was covered and glimpsed into some cutting edge areas. The closeness of genomics to practice was a key take away.
The working session with IDEO was a highlight for me as was the site visit to Kaiser’s Garfield Innovation Centre. IDEO was a highlight as, first, I’m a big fan of their work, but also it was a good chance to apply thinking and learning.
A lunch conversation with Alex Jadad was also a highlight. I appreciated that he did not know anything either (and that’s a good thing, right Alex?).
A lot of discussion on application of what was presented occurred in the breaks and meals between participants and that was great.
Amazing participants throughout the week – this includes faculty and students. The networking was in full force. Many amazing and energized people in so many areas of medicine, tech and beyond. I was quieter than I expected through the large lecture sessions (my gears were churning through ideas). Still, I found excellent collaborators and many like minded people in our group – I enjoyed all our interactions.
The twitter feed #futuremed was flowing fast and furious by a few participants and that was great. There were several keen start ups looking for feedback, and I hope I helped them a little.
Ideas and Actions
So it’s only good if it spurs new ideas that translate into action.
I filled my notebook with ideas and bad sketches of products from information applications to devices. That ideas were pouring out throughout the week was a good sign of success. Many quickly were shared with new friends, micro-incubated, and revised. One idea bubbled up as a fantastic idea with what we felt was real potential. To use a favourite Silicon Valley term it’s a “startup in stealth mode”. So if that takes off and does half of what it could to change research, this would be a week well spent.
I’ll have to wait and see how much of this week translates into real action, but I suspect that there will be many actions that are triggered or changed from this week for many of us.
So this last week has been a successful week and definitely it is certainly memorable.
I’m glad to be a part of the Singularity University Alumni.
There is a lot of buzz about Big Data. Healthcare is an interesting area for big data. Privacy issues aside for the moment.
I have seen some significant improvements in care delivery when people use “small data” to inform decisions rapidly. IHI.org is built on this. Use data to monitor change. Change based on data. Keep what is an improvement. Stop what is not. Rinse and repeat until it is part of your culture.
Some of us imagine the potential improvements if there were big data to use rapidly in exploring questions and testing hypotheses.
But of course privacy issues cannot be put aside. Two ways to begin to address this (to get to big data) are engaging people directly (e.g. sharing my own data into the pool — you see this with 23andMe, etc) and finding novel ways to access the information gleaned from the data without needing to own the data. Perhaps the term for this is “Big Information” not Big Data.
Thank you all for offering up example questions for a potential research network – these are an interesting set of wide ranging questions. I really appreciate the time each of you has taken to provide some thoughts. These will be helpful as our discussions move forward.
Some interesting themes already jump out from this non-scientific sample, such as:
- Need to link to health system data (costs, general outcomes)
- Need to link to other patient specific data sources to answer questions or link to the same patient data across nodes in the network
- Clinical / interventional studies of EMR function and use, including CDSS.
- Workflow studies
- Evaluation of Complex Interventions
This is a great starting point and, of course, if any other readers want to share a question, that would be great.
Amongst my work friends, we like to “fail fast” – that is to put up something for feedback quickly so that it can rapidly evolve with group input rather than polishing something on your own until you think it is “done” only to find out your second step led you in a direction you didn’t need to go.
So here is an early version of a goal map for a PCRN – this is based on the i* notation and does take a few sentences to describe. First, there are actors, represented by circles. These actors have goals, the pill shaped icons. Actors in a network are typically dependent on others to achieve certain goals. The arrows represent the dependencies. You can read it like this:
“ACTOR X wants to achieve GOAL A and is dependent on ACTOR B to achieve GOAL A”
or less abstractly:
“A PATIENT wants to have GOOD QUALITY CARE and is dependent on a FAMILY DOCTOR to receive GOOD QUALITY CARE.”
Hopefully that helps understand the image below (click for a larger version) and do provide comments – I would like to use this post to solicit public feedback and revise the map to help support our local design thinking.
(click for larger version)
There is an expectation that as we develop and use electronic systems (e.g. EMRs, PHRs etc) that this “will yield a wealth of available data that we can exploit meaningfully to strengthen knowledge building and evidence creation, and ultimately improve clinical and preventive care.”
Leveraging data that is in EMRs makes sense for a PCRN at this point in time. The question of this point is would a PCRN rely only on data that is routinely collected as part of care vs. using both data that is routinely collected as well as specific information that is collected for a given study.
Paper networks would send out specific questionnaires or data collection forms. These could be easily “integrated” into the paper chart (by photocopying). As long as the pages were 8 1/2″ x 11″ (in North America at least), then they fit all the standards they needed to fit.
In the EMR world, it is more complex.
Here are some pros and cons to each approach:
Routinely collected data
- May be more variable (I may document less than you routinely or I may be in the habit of documenting elements as text rather than using existing templates
- May be structured differently between EMRs
- Could have evolved over time
- May not capture what a study needs to know
- Typically is not sufficient for interventional studies
- May have ethical considerations if retrospective data is used for research.
Specifically Collected Data
- Requires more of the EMRs in the network to be able to at the least provide specific templates to record additional data
- Cost could be more if EMR vendors are required to build in custom features to handle the display of these study questions.
- Data models for the study may conflict with the data model in the EMR (e.g. smoking — the study might require a detailed description in pack years where as the EMR might have taken a different approach. How are these data reconciled in the EMR?)
- Requires more from the end user — they have to be keen enough to record some amount of extra data. While it might be minimal, even minimal can add up.
- Requires a change in work flow (e.g. the clinician now documents additional information, may have to ask different questions, etc.)
- The data is better suited to the study question
- The data is potentially more consistent across EMRs
- It is easier to assess data quality for specific data
- Requires more of the EMRs in the network to be able to at the least provide specific templates to record additional data
There are several things that need to be worked out if one wants to start collecting specific study data. It is an important part of the overall design of a network and depends on the kinds of questions the network wants to ask.
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.