Archive for the ‘Medicine’ Category
This week I am at FutureMed at Singularity U. Starting off as a great conference with an amazing group of attendees from all over the world (especially Brazil).
Dr. Peter Diamandis gave the keynote — a positive speaker with his new book, Abundance, about to come out. Very future focused and inspiring.
Some themes and thoughts from today:
- Capacity – we have seen a lot of growth in capacity in many areas. How do we develop huge amounts of capacity for health? The current models do not seem able to scale. We need to really innovate in models of care.
- Challenges of mis-alignment between regulation / payment vs innovation – there needs to be ways to foster innovation and adoption.
- Analytics and feedback are going to be key to the future acceleration. Particularly passive capture with quick feedback loops. For both providers and patients appear to be effective. Asthmapolis is an interesting example.
- GIS could help us better understand patterns of illness and its environmental causes
- Cracking the behaviour change problems – a lot of what we struggle with in health isn’t the need for synthetic, 3D printed organs, it’s the need to get people moving, eating, and taking care of themselves. I am looking forward to more discussion on this as this is where I hope we can see major changes supported through consumer social health.
- Integration across the silos. Generalism or working across the “ologies” (endocrinology, ophthalmology etc.).
- Incubators – there are a lot of them around here in Silicon Valley. I have not seen similar support / interest in Canada.
- Big and Small: Global and Mobile Health.
- And of course, exponentials. Personalized medicine – genomics as an example.
These are just some quick thoughts, not capturing everything.
Here’s the question:
What would your question be of a practice based primary care research network?
Consider that you are involved in establishing some of the first research questions that would be answered by a group of engaged, networked, and interested primary care practices – what would those questions be?
For this thought experiment, you could be a funder or a participant (clinician or patient) or an outside researcher.
Assume the network could collect whatever kinds of data you would need to answer your question.
Assume, also, for your quantitative types, that the network has 80 primary care providers (mostly family doctors, some nurse practictioners) across multiple sites both rural and urban and that these were full service primary care practices. Amazingly, all patients consent to participate and there are 120,000 patients. All practices are using an EMR and data from the charts would be encoded to support your question(s).
I will start with one of my questions:
What is the impact on overall capacity* of practices where patients with mental illness (mood disorders such as depression and anxiety) are given a proactive program and the tools to self manage their condition through a Personal Health Record (PHR)? Is there a difference if the PHR is integrated with their primary care provider’s practice EMR? Does self management also change quality of care (perceived and objective) for the patients involved?
* capacity should be examined both in terms of financial cost to the practice to run the program and changes in number of patients seen by providers over time compared to matched controls.
If this is interesting to you, add your own question as a comment or join the discussion by supporting / adding to other questions.
My goal here is to collect the types of questions people want answered not to focus on how to answer them (that comes later).
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.
This is a follow on the last post on health information. I actually started this one before I got the question, so maybe this is a prequel blog post…?
I have been thinking about the challenges that are going to face us in Canada as we move forward and start interconnecting EMRs (Electronic Medical Records) and sharing data. I am wondering:
What happens to health information when the EMRs of today are no longer “islands”(1) unto themselves?
Right now many EMRs are being used in relative digital isolation. Often EMRs have a laboratory results feed in to the practice, but very little comes out of the practice in digital form. Printing of referral letters and consult letters and patient summaries and prescriptions is the norm.
Many clinicians, from what I have observed, still think of their EMRs as “EPRs” – Electronic Paper Records. They use them as legible, remotely accessible paper charts and work around limitations as they would in paper. For example:
- Prescription writer or lab form is too complex?
No problem, write it in free text and use the paper forms still in your office.
- EMR have a problem with not putting significant past medical and surgical history on your referral note?
No problem, just put it in the problem list. The problem list prints on the referral note automatically.
- Not able to code procedures correctly (because you are using the problem list as in #2)?
No problem, do not worry about the code, just pick something close and edit the display name so it is accurate to what you are trying to say.
- Do not have a place to document housing issues? No problem, just create a new data element in the problem table for “unstable huosing – living under Main St Brige”(2)
- Problem list not specific enough for you?
No problem, create a new value in your code set that is more specific.
- Difficult to write that complex dosing regime of one pill twice a day and two pills at night?
No problem, put anything in the main field but make sure you use the comments field to say what you really want, the pharmacist will figure it out when she reads the printed prescription.
- Want to speed up your new patient visit? No problem, the EMR makes it easy to make your own templates. Just make a new template with tick boxes for “All immunizations up to date”, “NKDA” and others. OR you can just make a text macro that gives you a nicely formatted few paragraphs that you can edit only where you need to.
You can see where things are going, right? All of those are real examples and all of these are uniquely solved in each practice. Oftentimes they are uniquely solved many different ways in one practice.
Now fast forward a few years and start linking up EMRs, through Infoway’s EHR or through a standardized referral system or even through a custom interface from the vendor (it doesn’t really matter) and what happens?
As patients move around, EMR data in each practice becomes a mosaic. Local fixes are copied from one system to another. Each one different, just like the old paper charts. Specialists will have a worse time of it as they will be getting referrals from many sources, each one customized.
Clinical decision support will fall apart — how many people are missing their H1N1 vaccination? Don’t know, some of these records are using this field “immsuptodate” and others code it in the problem list as “053, injection, other” with a display name of “H1N1″, another few have this field called “immunizations_UTD_2009″…
The default approach would be to leave free text alone and only consider coded values, but this does not help when clinicians have co-opted terms for their own use.
This scares me. I do not think we have thought deeply enough yet on how to manage this issue.
It is going to be a huge clean up activity to get existing information standards compliant. To be fair to the EMR vendors and clinicians, there is not a supported “right” way to store health information in EMRs yet. We have some standards in Canada, but the bulk of the clinical information has been recorded without those standards in mind. The local “work arounds” were/are required to get the job of providing care done.
What tools should we start seriously considering in order to improve our health information as it moves off the isolated islands? Maybe we just need more duct tape?
Harmonizing our standards and redesigning EMRs to be standards compliant are only part of the process.
1. This is a popular term here in BC and likely elsewhere – a standalone EMR with few electronic connections to the outside world would be an island. Much of the data coming in and out is via paper (printing and scanning). It is an appropriate analogy as information is evolving more rapidly on islands.
2. Typos intentional to prove a point. Note also that there could be no code associated with this if the EMR allowed for codeless terms.
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.
Some months ago now I posted on the idea of creating patterns for EMRs akin to the work that others have done in User Interface design and other areas, all based on Christopher Alexander’s work. We are close to embarking on attempting to build some specific documentation patterns now at the Health Authority. Not the full blown vision with breadth and depth of Alexandrian patterns, but specific, fairly uniform sections of reusable electronic clinical documentation.
These are sitting somewhere in between openEHR archetypes and templates in terms of scope and size. The hope and plan is that these can be designed in a way that they will form the building blocks for the various e-Forms in the multiple clinical information systems, increasing interoperability and care standardization while decreasing rethink for common items. Each pattern will be designed to be a clinical cluster of content that is part of a reusable assessment.
These documentation patterns can managed by a central group (in this case the CARB – Clinical Architecture Review Board) and used, with simpler guidelines, by documentation teams in each application design team. Request for new patterns would come back to the CARB so they can be reviewed and ensure that they are consistent.
Some example patterns include:
- Problem List
- Past Medical History
- Glasgow Coma Scale
- Vital Signs
Some patterns will likely have multiple versions. This could be for a few reasons: evolution of the pattern or there are needs to have different levels of detail in different settings. Patterns evolve over time with improved design: initial design included minimal structure, now it should be more structured and we know how better to structure it. Patterns in different context may need more or less information. Vital Signs is a good example of this – vitals in an ambulatory clinic are much simpler than they are in the ICU. Still the information that does overlap should be the same (e.g. weight, BP, etc). These would be multiple versions of the pattern. Neurovitals will likely be a separate pattern to complement vital signs.
We are early days now, just starting to ramp up the necessary clinical and informatics skills to do this work. The two daunting aspects are: can we crack the clinical content into a sufficient number of truly reusable patterns to make this useful? (and related) how are we going to standardize clinical documentation across a large region that is actively using multiple documentation standards (including many ‘local’ standards) across several care settings and professions.
Yesterday I was lucky enough to be invited to give the opening Keynote for the Software Engineering in Health Care Workshop at ICSE 2009 and spend the whole day with a very thoughtful group of software engineers from around the world as we discussed issues related to designing software for healthcare. It was a very refreshing conversation with a slightly different perspective from the group. Some interesting activities and good people.
One of the topics that came back through the day was the issue of leveraging the context of data. This seemed to resonate in our discussions as a way to enhance current systems in new ways. The challenge is to define what those context could be and how they would support activities. The 5 W’s and 1 H are all important (who, what, when, where, why, and how). I’ve illustrated a few more specific elements in the diagram, but there are certainly more. Also important to consider which context we are talking about. So far, there are at least two distinct contexts that need to be considered:
- Point of Capture – where the datum was documented. The context of that point in time is obviously important.
- Point of (re)use – where the datum is being accessed. This might be future point of care activities, or it might be point of reflection activities (such as quality improvement or health planning, etc).
Model driven design and the overall socio-technical complexity of healthcare were also two additional resonating themes for me today. The challenge of the combination of these two (and our relative rates of failures of systems in healthcare in general) does lead one to look for new methodologies for system design and implementation. More explicit modeling of context into systems to provide more reusable information (as opposed to data) might be part of the answer.
A great workshop and I wished I could stay for the two days.
This is a follow on to my previous post on forms. I am working with a group now to design some clinical documentation and the information captured will be used in several very different environments. These locations are “hybrid” in that some information is electronic and other information is still on paper. A further wrinkle is that the evolution from paper to digital is not going to happen across the entire organization at the same rate, so we need to design a solution that will support various modalities as patients move in their journey.
Right now, the current practice for pre-admission work for elective surgeries is: store electronic results and transcribed documents electronically in a regional system that is accessible in multiple environments. The paper workflow is a little different. There is one paper chart – designed for inpatient care – and it is moved (or bits of it are moved) around to the various locations where a patient will be assessed over the up to 8 months prior to entering the hospital and the collect it all, make sure it is in the right order, and send it to the hospital just before the patient is scheduled to be admitted.
Many challenges here, not the least of which is the workflow associated with completing forms that are not designed for you to do your assessment, but are designed to support inpatient workflows pre and post operatively.
What we are looking at now is how to support two very different workflows in a manner that allows for standardization and flexibility at the same time. Flexibility in the sense that each workflow needs to be supported. Standardization in that the data needs to be captured in a way that allows logical reuse throughout the care process. With the wrinkle that some of that reuse will have to be that the data captured electronically needs to be able to recreate the inpatient PAPER chart through a report writer as the inpatient world will not be changing to electronic documentation at the same time as our pilot sites in the outpatient world.
Interesting times! I will post more on our approaches as we move forward.