In 2013, I'm focusing on 5 major work streams:
*Meaningful Use Stage 2, including Electronic Medication Administration Records
*ICD10, including clinical documentation improvement and computer assisted coding
*Replacement of all Laboratory Information Systems
*Compliance/Regulatory priorities, including security program maturity
*Supporting the IT needs of our evolving Accountable Care Organization including analytics for care management
I've written about some of these themes in previous posts and each has their uncharted territory.
One component that crosses several of my goals is how electronic documentation should support structured data capture for ICD10 and ACO quality metrics.
How are most inpatient progress notes documented in hospitals today? The intern writes a note that is often copied by the resident which is often copied by the attending which informs the consultants who may not agree with content. The chart is a largely unreadable and sometimes questionably useful document created via individual contributions and not by the consensus of the care team. The content is sometimes typed, sometimes dictated, sometimes templated, and sometimes cut/pasted. There must be a better way.
I recently attended a two day retreat to brainstorm about novel approaches to clinical documentation.
Imagine the following - the entire care team jointly authors a daily note for each patient using a novel application inspired by Wikipedia editing and Facebook communication. Data is captured using disease specific templates to ensure appropriate quality indicators are recorded. At the end of each day, the primary physician responsible for the patient's care signs the note on behalf of the care team and the note is locked. Gone are the "chart wars", redundant statements, and miscommunication among team members. As the note is signed, key concepts described in the note are codified in SNOMED-CT. The SNOMED-CT concepts are reduced to a selection of suggested ICD-10 billing codes. A rules engine reports back to the clinician where additional detail is needed to justify each ICD-10 code i.e. a fracture must have the specifics of right/left, distal/proximal, open/closed, simple/comminuted.
You can imagine that the moving parts I've described are modular components provided by different companies via cloud hosted web services (similar to the decision support service provider idea)
Module 1 - disease specific templates
Module 2 - technology to capture free text and populate the templates i.e. my Wikipedia/Facebook concept describe above.
Module 3 - natural language processing to codify SNOMED-CT concepts
Module 4 - mapping of SNOMED-CT concepts to ICD10 codes
Module 5 - rules to ensure documentation is complete enough to justify the ICD10 codes
We've been speaking industry leaders such as m*modal, 3M, and Optum about these ideas.
Early adopters including Kaiser, Geisinger and Mayo are already working on elements of this approach.
However, there are challenges.
1. Clinicians are not broadly trained in the use of SNOMED-CT. It may be that SNOMED-CT should be used for internal storage of structured data but only friendly plain text descriptions are displayed to users.
2. Will CMS, the Joint Commission, and malpractice insurers accept the concept of jointly authored care team notes?
3. Implementing all 5 applications/modules at once may be too much change too quickly, making the overall project high risk
4. Will SNOMED-CT map to ICD-10 cleanly enough to ensure neither upcoding nor downcoding, but "right coding"
5. Will companies be willing to create such modules/services at a time when few EHRs are likely to interface to them? As Meaningful Use Stage 3 is finalized, I expect some of this functionality to be required
We have 22 months before ICD-10 compliance is required and complete documentation in support of the new codes must be available. We need to work fast. Tomorrow we have an internal conference call to plan next steps - what module or modules do we work on first? We have companies interested in partnering with us on Modules 2 and 3. The National Library of Medicine's VSAC is developing module 4.
I welcome your advice - have you discovered emerging products that might be useful for our exploration?
Have you considered how to take your clinical documentation to the next level?
I look forward to the adventure ahead.
Re Replacement of all Laboratory Information Systems John, is there a link to a listing of those LISs?
ReplyDeleteSparrow EDIS uses speech recognition and tappable templates, combining input from multiple users into a visit summary. All done using iPads. It doesn't do the Wikipedia-type editing of others' notes though. I would think it could be modified for module number 2—you could have the primary author make changes, which are then routed to original authors on their devices for approval or comment. And since Nuance is the speech engine, there is some movement toward clinical language understanding, which could accomplish #3.
ReplyDeleteLove the re-engineering of clinical documentation to leverage the data and collaboration potential of HIT. Both the process and the output can and should be simpler and more effective than what our EHRs support today. I'm sure the brainstorming sessions discussed the role of the Patient and their family as contributors to the record and an important audience for the documentation produced. Where did the group land on this consideration?
ReplyDeleteAnd the corollary question of how the inpatient progress note "wiki" becomes or integrates with the patient-centered record for the ambulatory clinic, specialists office, care manager, home health team and patient/family self-care.
Thanks for taking on this important work. There are many technical, cultural and regulatory challenges along the way, but it's a path we must travel.
Greg
As always, thanks for an interesting post. It reminds me of a concept I touched upon a few years back,
ReplyDeleteWhy Facebook should be a template for electronic medical records. Also, your post from 2010, "Rethinking Clinical Documentation," was along a similar vein to a blog I wrote around the same time, Clinical documentation is at the core of healthcare reform.
Today, the narrative remains essential but the copy forward capability is problematic at best. In fact, I heard recent guidance that suggests this capability should be switched off. Going digital with our existing infrastructure does not mean losing the narrative, nor the meaning of clinical thinking. Technology, in particular Clinical Language Understanding (aka NLP), is the “Rosetta Stone” for medical notes. CLU unlocks the data in the narrative and makes it available in SNOMED-CT & ICD-10 tagged format – amongst many other coding systems. Still, while technologies like CLU and computer-assisted coding can help ensure the specificity of the clinical documentation created by the care team in line with ICD-10, we need to focus first and foremost on improving physician documentation at the point-of-care. While physicians don’t need to be trained on the intricacies of coding, they do need to have a basic understanding of requirements specific to their area of practice to ensure “right coding” (and this is based on having the right medical information in the documentation) the first time around. In Module 5 you briefly touch upon this but I’d actually move Module 5 to Module 1 because instilling documentation “rules” or CDI insight with physicians must be the first step in this process. Regardless of how advanced technology may become, if you put garbage into this system, you’re going to continue to get garbage out. In the coming year, I think the overall demand to draw data out of physicians' heads and into computerized form will elevate the need for CDI as step-one in an intelligent, streamlined clinical documentation strategy that will support value-based purchasing and quality-of-care measurement, as well as ICD-10.
RE: Module 1 - disease specific templates. Since there are thousands of diseases, how does one expect to generate the entire SNOMED-CT vocabulary list of such and to include the required quality indicators?
ReplyDeleteRE: Module 2 - I have blogged often about, and agree with Commenter Nick that a Facebook-type user interface be standard for the next generation of all EMRs. Highly unlikely that will occur due to having to rewrite all the code (but all the code had to be re-written with the introduction of the WWW). After all, the medical record is THE most collaborative tool in healthcare!
RE: Module 3 - A good NLP or NLU engine should be able to codify SNOMED-CT concepts, and your team is working with a few companies that have good engines. (There are others, BTW.) But most of the current NLP/NLU engines work best using I-9! Seversal years ago, AMIA and AHIMA proposed solutions to this challenge, and currently a group of HIM professionals (including yours truly) is working to resurrect this proposal. In addition, to answer your Challenge #1, you are correct, Dr. H, that SNOMED-CT MUST be embedded underneath EMR plain text descriptions so that no clinicians become coders.
RE: Module 4 - Yes, the NLM's mapping of SNOMED-CT to ICD-10 should assist with this. However, your challenge #4 is the big unknown at this time. Because today all clinical coding is performed using I-9 (for billing, reimbursement) and few EMRS embed SNOMED-CT, we don't know.
RE: Module 5 - Ensuring documentation is complete and of excellent quality to justify I-10 codes should be realized by "sister" Clinical Documentation Improvement (CDI) systems to Computer-Assisted Coding (CAC) systems. Several CAC vendors are beginning to introduce and / or interface to existing CDI systems. It is unclear from your post if you have considered CDI systems, too.
RE: How clinical documentation could be performed by the rounding teams at academic medical centers - it would behoove EMR vendors to explore Electronic Content Management System features and functions, such as document check-in and check-out. This valuable function has been around for a long time and fits into your scenario perfectly.
Have you detailed an ROI on all this? Including activity costs?
ReplyDelete