Wikipedia and Facebook for Clinical Documentation

John D. HalamkaOver the past several years I’ve written about the inadequate state of clinical documentation, which is largely unchanged since the days of Osler, (except for a bit more structure introduced by Larry Weed in the 1970s) and was created for billing/legal purposes not for care coordination.

One of the most frequent complaints in my email box these days is a sense that the current record is filled with data, but little knowledge and wisdom.  It’s hard to understand each patient’s individual story. Notes are filled with cutting/pasting, inaccuracies, and redundancy. Sometimes among the dozen notes written each day by the medical student, resident, fellow, attending, and consultants there is inconsistency.

The era of Ebola has accelerated the urgency for us to rethink the way we document.

In recent lectures, I’ve called on the country to adopt Wikipedia and Facebook for clinical documentation.

I don’t really mean that we should use those products, but we should embrace their principles.

Imagine if the team at Texas Health Presbyterian jointly authored a single note each day, forcing them to read and consider all the observations made by each clinician involved in a patient’s care. There would be no cut/paste, multiple eyes would confirm the facts, and redundancy would be eliminated. As team members jointly crafted a common set of observations and a single care plan, the note would evolve into a refined consensus.   There would be a single daily narrative that told the patient story. The accountable attending (there must be someone named as the team captain for treatment) would sign the jointly authored “Wikipedia” entry, attesting that is accurate and applying a time/date stamp for it to be added to the legal record.

After that note is authored each day, there will be key events - lab results, variation in vital signs, new patient/family care preferences, decision support alerts/reminders, and changes in condition.

Those will appear on the “Facebook” wall for each patient each day, showing the salient issues that occurred after the jointly authored note was signed.

With such an approach, every member of the Texas care team would have known that the patient traveled to Dallas from West Africa. Every member of the care team would understand the alerts/reminders that appeared when CDC or hospital guidelines evolved. Everyone would know the protocols for isolation and adhere to them. Of course, the patient would be a part of the “Wikipedia” and “Facebook” process, adding their own entries in real time.

Yes, there are regulations from CMS enforcing the integrity of the medical record.    I’ve had preliminary discussions with folks in government who have signaled that as long as the “Wikipedia” authorship takes place outside of the medical record and then is posted/signed/timed/dated by a single accountable clinician, regulatory requirements will be met.  Once posted, the entry cannot be edited/changed, just amended, preserving data integrity.

It’s likely that the “Facebook” portion of the display would not be regulated,  but would require the same kind of validation we already do for lab result workflow. The "wall" could also be certified for the Meaningful Use provisions that require viewing of the Meaningful Use Common Data Set.

Once there is a single place for all care team members to look when treating a patient, decision support based on analysis of structured and unstructured data will be easier to engineer.

Although I believe that the medical record coding we do today will become less relevant as we evolve from fee for service medicine to global capitated risk, the use of computer assisted coding and clinical documentation improvement tools will be easier with the “Wikipedia” plus “Facebook” approach.

I can even imagine that emerging Fast Healthcare Interoperability Resources (FHIR) work could represent the “Wikipedia” entry as part of document retrieval standards and the Facebook wall could be part of discrete data query/response, providing a timeline for the key events in a patient’s treatment. I’ve already discussed the need for such timeline data with key FHIR architects.

A team at BIDMC is working on clinical documentation, structured and unstructured, in FY15. We’ll proceed incrementally, learning from each phase, and begin our journey toward an inpatient record that looks more like Wikipedia and Facebook than Osler’s notebook. As Ebola and the tide of EHR dissatisfaction drive innovative documentation thinking, we'll need to move deliberatively.

And if we’re lucky, care team members will rekindle the spirit of working and talking together instead of starting at a screen, checking boxes for Meaningful Use.

Wikipedia and Facebook for Clinical Documentation was authored by Dr. John D. Halamka and published in his blog, Life as a Healthcare CIO and it is reprinted by Open Health News under the terms of the Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License. The original post can be found here.

 

Comments

Discussing the way we document patient cases

I appreciate your sharing your thoughts regarding a different approach to building a daily entry into the EHR. However, I think this doesn't push the envelop far enough.

What about instead of needing an arbiter to determine the consensus 'daily note', we use a more inclusive approach by building in a better way to 'listen' to the medical opinion of every attending involved? With advances in handling unstructured content, the team could make sure that all perspectives are considered in their context, rather than pre-filtering by the team lead. It could even take into account the testimony by the patient (and witnesses or bystanders) to form an opinion in context and consider all options for treatment.

This is just one of the opportunities we see for organizations that are interested in truly adopting the possibilities of unstructured content processing. My company would be interested in collaborating on developing trial solutions with institutions such as BIDMC to develop .