Uncategorized

Brainstorming About the Future of Clinical Documentation

In 2013, I’m focused on five 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.

John D. Halamka, MD, MS, is Chief Information Officer of Beth Israel Deaconess Medical Center, Chief Information Officer at Harvard Medical School, Chairman of the New England Healthcare Exchange Network (NEHEN), Co-Chair of the HIT Standards Committee, a full Professor at Harvard Medical School, and a practicing Emergency Physician. He’s also the author of the popular Life as a Healthcare CIO blog.

11 replies »

  1. Dr Halamka, I am a great fan and thank you for your historic leadership on developing HIT standards. From your article and comments it is clear that we are on the cusp of understanding clinical documentation in a new way. One caveat respectfully made: I ask that you consider changing Module 1 to “condition specific templates”. As you know, nursing diagnosis generates care interventions but nursing dx is not “disease” related. This is especially relvant in the context of the “team daily note”. Not every team discipline is oriented toward disease in the same way the physician is. Further, there are preventive measures that are not disease-specific. So, clinical documentation must evolve in all domains, within and outside of the hospital. Ultimately the “team daily note” should morph into a new paradigm, the virtual care plan. Any authorized entity would view or edit the virtual care plan, which would follow the patient across care domains and represent the patient’s full continum of disease, preventive, psychosocial, and spiritual conditions.

  2. Hello Afik, As of yet, there are no publications. Most of my time has been devoted to developing a concrete implementation and thus you won’t find anything by Googling at this stage. I have presented the formalized patient representation system (called NLites) at a number of smaller research conferences to very positive reviews over the last 2 years and believe it is time to ramp up the visibility of this project. My email address is docere@gmail.com if you would like to learn more.

  3. This sounds very interesting and might be one good way of solving these problems.. Have you published anything yet? I’d be happy to learn more and perhaps even help.

  4. We are very much like minded regarding how documentation workflow should take place 🙂

    On the area of text processing, I am exploring a different twist.

    I have designed an early prototype documentation platform that endeavours to capture ontology artifacts within a continuous text authoring environment. I have been using this prototype in my own clinical work as a Hospitalist to great effect over the last year, and am embarking on exploring early adoption patterns within an intermediate sized academic healthcare setting as a research project. We will first explore early adopter experience in addition to dyad collaborators (learner/preceptor, NP or PA / physician) using the documentation workflow you described.

    The twist in is in the text processing. Instead of relying on natural language processing, the new documentation environment leverages context free grammar representations which skirt ambiguity issues inherent with NLP. The thesis here is that the 100% certainty of text interpretation offers a vastly different use case compared to even IBM Watson’s 96-99% certainty in processing.

    I believe we need to transition medical documentation from it’s ad hoc, semi-formalized text representation traditions to the full blooded text formalisms that software languages have used for many years is what our implementation is about. Creating a highly intelligent text editor to allow users to rapidly design these types of formalized text representations is essential. The last piece is user adoption which is our current exploration for 2103.

  5. Those are some great ideas, and it is always interesting when an inevitable change is taken as an opportunity to rethink the old tools and produce even more innovative solutions.

    I wonder if your team also thought about the way we read clinical documentation and how solutions such as these will affect this? The need for full clinical notes include a complete ROS, exam, etc. often makes it time consuming for subsequent clinicians to pick out the pertinent positives and negatives. Will adopting SNOMED-CT and CDS help, or will it simply add more noise?

    Inpatient clinicians at many centers have adopted hand-off solutions that live outside the EHR and do a better job of capturing the patient’s story in the concise format we need. Outpatient clinicians rarely have such tools. I wonder if your Wikipedia-like tool could be further extended to help the authors highlight the pertinent positives and negatives and produce both summarized and detailed versions of the notes. That could allow subsequent readers to choose the level of detail they want when they read it, ensuring that clinical documentation is not only captured effectively, but is also highly readable — and that could significantly improve care transitions.

  6. With October 2014 fast approaching, this article brings up some great points about implementation of ICD-10. New challenges are ahead for physicians and documentation specialists alike. Seeking out clinical documentation improvement and ICD-10 training can help to ease the transition and help maintain more efficient coding.

    See also http://www.healthleadersmedia.com/content/TEC-272931/Havent-Started-ICD10-It-May-Already-Be-Too-Late.html##

    and

    http://www.dcbainc.com/

  7. Excellent set of ideas and questions, as usual!

    I’m not thrilled about the idea of a “joint consensus note”. The chart used to be a place where independent ideas could be expressed and worked through regarding a patient’s care. Dissenting opinions sometimes opened a door to the correct diagnosis.

    I am also fearful of templates. My experience with chart extracts of current EHRs is that they are largely devoid of a narrative or meaningful content that allows one to follow what the provider’s thinking was and what was decided and done for the patient. This results from documentation that is cut/pasted, templated or menu/pick list driven.

    I think it’s essential that we maintain the narrative of patient care (See Rita Charon’s work). This is why I favor voice recognition dictated notes. These have been enthusiastically adopted where they have been implemented.

    All of that said, I also recognize the need for codified data to allow the aggregation and analysis that is needed to do research and measure outcomes and quality. Could this be done by applying natural language processing to the dictated notes to cull Snomed, ICD10 and other codes? Is this something that Watson could be trained to do?

  8. I have been waiting for these types of ideas to surface in the blogosphere for quite a while…great job outlining such a solution. My 2 cents:

    I agree with the challenges mentioned and would add a resistance from the clinical world to it.
    I see the components/modules a bit differently.
    Module 1+3 should be one- i.e. provide analytics/machine learning based dynamic templates( complex version of auto complete) to capture/structure the logic/timeline/relations/constraints in the clinical documentation…

    Unfortunately, NLP is very good for recognizing concepts but that is only small part of the clinical documentation.
    Module 5 is something that should be embedded in the module that I’ve just outlined – as this task is a lot easier to complete in real time than it is after that.
    Happy holidays,
    Afik