I had a post by Dirk Stanley, MD recently pointed out to me where Dirk discusses the challenge of deciding which information an HIE should pass. Dirk is the CMIO at a hospital and also a genuinely nice guy. He frames the answer to the HIE data passing question really well:
And after a rousing discussion, the answer I heard was this :Everyone has a different opinion.
I guess it’s entirely understandable… ICU docs, PCPs, surgeons, specialists, hospitalists, and everyone else has a common goal – making the patient healthier – but they have different training and thus they all have different needs. This is why when I hear docs say “I just need the important information!“, I smile because ultimately, all of the information in a chart is important – It just depends on your context and clinical needs.
So I’m left with the ultimate Informatics challenge – How can we get the right information to the right person in the right place in the right time in the right way? Especially when everyone has a different opinion on what the right information is?
He then offers this zinger which describes the real core of the problem: “Looking at the current buffet table of documentation, it’s no wonder that every doctor has a differrent opinion of what they need. There aren’t really any hard standards for clinical documentation.”
Dirk then goes on to describe his solution to the problem which essentially revolves around the idea of a new type of note that can be transferred. You can read all the details in his post.
Reading through Dirk’s thoughts on the subject I’m reminded of the conversations that surrounded the creation of CCR back in the day. They seem to have taken a very similar approach to what Dirk describes. I wonder what Dirk thinks of the CCR (now basically merged with CCD) standards that are already out there. Do they not cover what he has in mind? Are their gaps in the CCD standard that don’t cover his “new note?” Could we just improve the CCD standard to cover those gaps? I’ll ping Dirk and hopefully he’ll join the conversation.
The real challenge when looking at what data should an HIE pass is that computers aren’t very good at understanding context. I’d be interested to hear people’s thoughts about this and how we’ll solve this problem going forward. My gut feeling is that we need to start with something that will solve a lot of problems for a lot of people. We don’t need something that will solve all things for everyone from day one. We can incrementally improve the exchange of data as we go forward.
I would first suggest a different question.
Right now, there is no centralized source of information about the different types of functionality that care providers would like to see in a HIT application. HIT vendors have to figure that out on their own – to varying degrees of success. The first question to ask is, “What information, under what circumstances will satisfy the care provider?
It is the HIT application – not the HIE — that should provide the care provider with the information she wants in the manner she wants it. It should know that by understanding the context in which the information is being requested.
The issue isn’t what information the HIE should pass, the issue is how much info the care provider wants. And that ALWAYS depends on the circumstances. What is the Pt issue? What is the care provider’s role in this situation? Within what institutional setting is the care provider working — home, her office, one of the hospitals at which she is accredited? Is the care provideer rushed or does she have the time to thoroughly review the data?
Find out what the care provider wants and needs and then think about what information the HIE should pass to the HIT application. Different care providers will want different types and amounts of information from the same HIT application at different times and at different places.
Bob,
Some interesting food for thought. Yes, that is likely a better way to phrase it that the HIT system should be where it’s decided what a physician needs or doesn’t need and then makes the request of the HIE.
Would you then just suggest that the HIE is a big repository of all the information and the HIT application would decide which components of the repository it should query on an as needed basis? Seems like trying to create the HIE as the repository of ALL the information will be a challenge as opposed to some smaller defined set of information, no?
I think both of you are on the right track. John’s approach to start with the basics makes much sense. For example, this would include vitals, history of the present illness, meds, allergies, etc.
This will give most practitioners a good knowledge of the patient. Next, I’d include labs, and radiology reports, consult reports, etc.
It’s the third level that is going to be the most problematical, specialist data. Oncologists, surgeons, ophthalmologists, etc., need to pass and receive data for their specialties. I think the way to handle this is on a push/pull basis. That is, the system should have a capacity to convey specialist information, but it should not be routinely passed. That is it would have to be asked for, or sent to a particular recipient, rather than kept as SOP.
Wow, first, I’m flattered to make a guest appearance on your blog – I feel like I’ve made it to the big time!
As for the standards of clinical documentation – You’re right, CCD provides a lot of the framework for transferring that data. It’s a nice mini-chart, for sure, kinda like the “chart-of-life” some people carry around in their wallet, only electronic and much more robust.
The problem, to me, is that most doctors have a hard time integrating such a document into their current buffet table of “Admission H&P”, “Daily Progress Note”, “Discharge Summary”, “Procedure Note”, “Encounter Note”, “Consult Note”, “Death Note”, and whatever other things the docs are used to writing. (Note : This is where it gets complicated, because while things like the Admission H&P are *RELATIVELY* standard, there are no actual standards for any of this stuff – The closest thing we have to a standard for clinical documentation is Larry Week’s SOAP (Subjective, Objective, Assessment, and Plan) framework which guides the thinking and organization of virtually all physician notes. (For more, I have a blog about that too : http://dirkmd.blogspot.com/2011/11/can-we-do-better-than-soap.html
In any case, with the push-only model that NHIN is going to offer us (at least to start, I hope?), I’m trying to think of a way that we can :
1. Simplify all of our documentation
2. Make a note docs will BEG for (although admittedly the CCD document would do that too)
3. Make a note that’s fairly intuitive and easy to teach
4. Make a note that’s pretty easy to build into clinical workflows
I looked at the best sample CCD document I could find :http://services.bidmc.org/geekdoctor/johnhalamkaccddocument.xml#idp52888704
… and while it’s very good, I would recommend the addition of the co-authors – Since a key feature of “making it delicious like French Fries” is that it would be nice if you could PULL this note, then, into your daily documentation, to review and help flesh out your note. By adding the “co-authors”, it legally helps establish that “I’m depending on the words of all of these other docs before me”, and it makes a handy list of “who’s seen this patient before me”.
I also think branding the note can be really helpful in educating it – By naming it the “football” it would easily help docs to understand, in a push-only world, who they should push it to and when.
Excellent post, as always… Will keep thinking about the issue! Thanks for your excellent analysis, as always! 🙂
Oops – Misspelling alert – I meant Larry WEED, not Larry Week. (You should read the original post from the 1968 New England Journal of Medicine! I think he deserves a Nobel Prize for getting us all this far!) 🙂
Dirk,
You’ve always been in the big time.
I think what you describe is that the branding of the CCD isn’t right for doctors. Instead of saying that they can get a CCD document from a doctor which sounds technical and scary they need to hear that they’re going to get an “Electronic Note” transferred from a doctor. If in reality that’s a CCD document that gets converted into a beautifully displayed “note” for the doctor, they don’t really care. That’s semantics which don’t matter to them. Your “football” naming goes towards these same lines, but I think that actually naming it that will confuse doctors more. It works great as a way to describe what’s happening, but they’d get lost wondering how football had to do with a note. I actually think this is an important point that’s worthy of its own blog post.
Of course, as you mention, things could be added to the CCD that could make it more useful (like you mention the list of doctors who contributed to the note). However, those incremental changes could be done over time rather than starting a new standards that competes with CCD and yet contains the majority of the same information.
I’m definitely not looking to start a new standard – The issue is that from a workflow perspective, I’m not sure how CCD would be incorporated. It’s more than just brand – It’s actually, “How will the docs get information into the CCD document?” – Writing notes is something docs do very well – Updating several separate database tables in an EMR, while some docs might get it, adds a layer of complexity. What you want is a nice smooth workflow where :
1. Doc sees all of the important tables in a natural, logical progression
2. Doc updates all of the tables in a natural, logical progression.
That’s why I’m suggesting that the CCD document, while helpful in transmitting a patient’s “summary record”, is not enough – It’s a good transport, but we’ll need a good workflow that ensures the doc has reviewed and updated all of the important tables in a smooth, logical progression.
There is also the issue of med reconciliation and patient handoff – The “to-do” list is kind of key for a lot of docs, especially when continuity of care gets stretched thin (e.g. rotating hospitalists, rotating residents, etc.) and med reconciliation, especially between disparate systems – Who will have the “master record”? If a patient goes between various different medical systems (as a fair number do), who will have the “master record”? That’s why the “football” analogy is helpful – Docs and systems need to think of it as the “record you hand off to the next provider”.
Again, I certainly don’t want to create any new standards – We have a lot of good ones, and I agree 100% with your philosophy of incremental changes. But incorporating the CCD document into daily clinical workflows will take some creativity.
Thanks again for even including me in your blog! I feel like I’m on Leno or Jon Stewart! 🙂
Dirk,
I prefer Letterman;-) Although Jon Stewart is pretty amazing too.
What you describe is really what an EHR vendor should be doing to incorporate the CCD data into the workflow. You’re right that will take some creativity and good planning to make it useful and fit well into the clinical workflow.
And this is why I developed the “football” – Because vendors usually build systems according to “what the doc wants” – Our current buffet table of “common notes” will not support this workflow. In other words, the CCD is a good-looking document, but it doesn’t match any of our common physician notes. To seed and update the CCD will require some rethinking of our current structure.
(Wow, this is an unbelievable discussion… There are amazing minds at work on this blog…!)
I guess I think the football is a bad example. I think the CCD is more like the cooler that you take to a football game. One doc fills the “cooler” with ingredients (data) and then the next doc (or EHR) can take out the ingredients that they want from the cooler and use it the way they see fit.
The key here is to just get the first doc to put in the cooler all the ingredients he has available in a form that the next doctor knows how to retrieve them out of the cooler.
[…] really interesting point came out of the discussion in the comments of my post titled “What Information an HIE Should Pass?” Here’s one of my responses: I think what you describe is that the branding of the CCD […]