Archive for the ‘Health Informatics’ tag
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?
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.
Electronic Healthcare just published one of our papers on EMR Adoption
Great to see it in print!
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.
Jess McMullin has a good slide deck where he describes (slide 9) five levels of Design Maturity. (1)
Those levels are (paraphrased):
- Default – Status quo determines design.
- Style – Changes to look and feel
- Function – Design improves use
- Problem Solving – Seeks current problems and changes
- Framing – Redefinition of the problem itself.
This is a good list to remember in healthcare.
The potential for improvement (and some types of risk) increase as you move from default to framing. Also, it is harder for users to conceptualize the changes as you move through. It’s easy for people to visualize “we are going to put this paper form on the computer”. It’s harder for them to consistently visualize “where we’re going you won’t need to document”, or large lists of requirements… As you move along the levels of design you need to rely on more iterative and visual tools to support shared and common understandings of the changes that are being considered.
1. I found a similarity to a list of maturity for Business Analysts that was on Better Projects. If you are a BA or work with BA, think about where you fit in this list of maturity for the various kinds of activities / projects you work on.
A colleague asked me how do I categorize structured information today and, as I happened to be drafting another post on the importance of standardized health information (coming soon), I thought it might be good to post a response online rather than just in an email. The question went something like this:
What does discrete data capture mean to you as a physician? Is this different than structured text? And the difference from free text?
For me, discrete data means that information is being stored in a way that is predefined and has computable meaning. Discrete data could have a terminology behind it, such as a problem list with SNOMED codes or it could be data elements, such as birthdate, that have a singular value. Both of these can be acted on in a consistent manner using decision support engines, used to run practice level reports (how many diabetics over the age of 50 are in my practice?), etc.
Structured text is a way of standardizing and speeding up text entry by using some form of macro-like functionality. Type “_RESPN” and you get a long blob of text that outlines what you do in a respiratory physical exam, all with normal findings. (“…Breath sounds normal, no crackles or wheezes heard on auscultation…”). This text is not interpretable (with the exception of natural language processing) by the computer.
Free text is just ASCII or rich text that is typed / dictated / input by the user using phrases and sequencing that is up to the user.
So yes, the three are different — structured text is a quick input method for free text, but it also triggers some standardization in verbage and action (you cannot say what you did not do).
That would answer the question. There are some other aspects to talk about – and some of these might be relevant.
First, discrete data does not mean standardized data. A common EMR feature (and HIS feature) is the ability to locally define data elements – nicely formed discrete data. Data that does not have to conform to any standard. Thus, there are many discrete data elements that cannot be shared, even between users of the same EMR.
Also, one could have another definition of structured text – that would be text that is marked up. Mark up provides some discrete data, if the EMR supported it. Think of how XML works. Readable text can be marked up with meaning. A sentence like:
“The blood pressure is 130/80.”
could actually be marked up behind the scenes like this:
The blood pressure is <systolic blood pressure>130</systolic blood pressure> / <diastolic blood pressure>80</diastolic blood pressure>
The user may not be aware of the mark up or they may do it with key phrases, but the data is then available elsewhere for graphing, trending, etc. and it seems like free text mark up. (NOTE: this may be what some people talk about when they talk about structured text, I am not sure.)
Finally, these categories, no doubt, are somewhat arbitrary and people will either say “what about X” which doesn’t fit into the boxes above or present another way of breaking down types of information. And that, friends, is exactly why I have comments enabled.
Hope this helps.
NOTE: This post is a follow up from the overall post on what does a clinical architect need to know.
Usability of systems in an important issue. Although it is not one that is first thought of when one thinks of architecture, which is a shame. User Centredness really should be a large part of what a Clinical Architect considers during design.
Of course, detailed user centred design work is not something that the clinical architect can do single handedly, especially in large organizations. Keeping the mantra in the forefront is important to making workable systems and that is something the Clinical Architect should do.
I think about user centredness at a few levels:
- The single user interacting with one information system
- How do the screens flow, does that support the work, is the right information where it is needed, are movements from keyboard to mouse and back streamlined, etc.
- The single user interacting with systemS (plural) or the greater system -
- Where does a user need to go to get information, what does their day look like, etc. Are they interfacing witn 3 systems to do one job, what are the greater outputs, are they hand modifying those outputs and why.
- The multi-user system -
- How does the CIS impact provider – patient interactions and how does it impact provider-provider interactions? What intentional changes are occurring and what UNintentional changes are occurring (or could occur) with the implementation.
Together these views can give an Architect a good view into how the systems work as a whole for a user in their day to day work. Typically, one would consider
I’ve written about the bio-psycho-social approach to usability before and it is a useful framework to consider usability as well as user centred design.
In healthcare, there is also the idea of being patient centred as well. This is an extremely important perspective to consider. My recent research has shown how fragmented a patient’s care is and how they information can be scattered across literally dozens of records (see broken records).
As a final note, here is a recently ISO / IEC 62366 summary from User Focus that discusses usability of medical devices.