Over the past 5 years, I worked with HITSP and the HIT Standards Committee to select standards for exchanging clinical summaries. But what exactly is a clinical summary?
There is common agreement about the need to exchange codified, structured data for problem lists, medications, allergies, and labs.
However, what is the role of unstructured clinical documentation text?
Some have suggested that unstructured text is hard to navigate, at times repetitious, and challenging for computers to interpret.
I believe the exchange of free text notes such as operative reports, history&physicals, ED charts, consult notes, and discharge summaries is very important.
Consider this example.
A 40 year male with no family history of heart disease presents to the ED at 3am with a chief complaint of chest pain and left arm numbness. The EKG is normal, a stress test is normal, labs are normal, and a cardiology consult is completed. The patient is discharged on H2 blockers with a diagnosis of gastritis.
A summary which only includes a problem and med list may state a Problem List of Gastritis and a Medication List of Prilosec OTC.
When the patient next visits an Emergency Department, no one will know about the cardiology consult, the differential diagnosis considered, and the thought process that led to the diagnosis of gastritis to explain the chest pain.
An entire workup will be started from scratch.
There is a great article in the March 25, 2010 of the New England Journal of Medicine "Can Electronic Clinical Documentation Help Prevent Diagnostic Errors?" by Gordon D. Schiff, M.D., and David W. Bates, M.D. in which the authors note:
"Free-text narrative will often be superior to point-and-click boilerplate in accurately capturing a patient's history and making assessments, and notes should be designed to include discussion of uncertainties."
I agree.
Notes should be included as part of clinical summaries.
However, we should do all we can to improve the quality of notes.
Over the next year, we hope to try a radically different approach to clinical documentation at BIDMC which we think will leverage all the strengths of the full text note as described by Drs. Schiff and Bates without the repetition and navigation issues.
Today's inpatient charges are a collection of SOAP notes written by the medical student, intern, resident, fellow, attending, and consultants largely for billing and medico-legal purposes.
What if the chart was recast as a communication vehicle for the entire team that summarized the day's events and collective wisdom on next steps?
Our answer - a daily Wiki entry for each patient authored by the entire team and signed/locked by the attending at the end of each day.
How will this work?
Think of it as a private wikipedia build inside our clinical systems and hosted in our data center.
Each member of the care team will use our Team Census application to view the list of patients for whom the team is responsible.
Clicking on any patient name will bring up the daily Wiki. Each member can add documentation, revise existing text, and leverage the work of others on the team until the attending makes the final edits and signs/locks the day's documentation. Just like a wiki, a complete journal shows all all edits/changes/deletes, so no information is lost. Importantly the day's wiki entry has one physical exam, one assessment, and one plan - not 17 repetitive entries saying the same thing that often appears in today's paper charts.
The idea of a daily wiki entry for each patient creates highly readable succinct documentation authored by the entire team with a medical legal record of the process that was used to generate it. It's a perfect single document to share with the referring clinician and the patient/patient's family.
After our initial pilot work, I'm guessing we'll also engage the patient and families to add to the Wiki, reflecting the shared decision making between the team, the patient, and the patient's family.
We're in the design stage now, but I'll report back on how it goes.
A daily patient Wiki as unified clinical documentation, exchanged with the team, other providers, and the patient. I bet even the free-text naysayers will agree that this should be part of the clinical summary!
Dr. Halamka
ReplyDeleteI visited you a few years back with a self designed and self produced EMR. It is most satisfying to me to see you have embraced a major theme of what I was trying to create.
I should also note our discussion about CCHIT certification. Thankfully it has now changed to allow smaller players to have a chance to bring progress to medical documenting. I hope to use the site certification process and am in the last throes of meeting meaningful use requirements.
Having taught medical students for many years, I know if they were allowed to use point and click history taking, I would never know what they did or did not know. I couldn't begin to analyze their ability to organize their thoughts.
I hope your views on this subject becomes a reality for all EMR developers.
I have been thinking about trying to use Googles Wave tool in a very similar fashion when it becomes available as Open Source.
ReplyDeleteIt should be simple enough to use the plugin tools to A. Associate waves/wavelets with patients and implement proper access control B. Freeze waves after "signing"
Waves allow for the best parts of email and wikis to work together and provide a very easy mechanism for displaying who contributed what to the wave, as well as automatically providing functionality for "playing back" changes to the wave...
Really glad to see someone thinking along the same lines.
What wiki engine are you planning to use?
While I have no experience with using wikis in a clinical environment I have worked with several different generations of wiki software and noticed that while the concept of a wiki is excellent, the variations in wiki-markups are significant and moving from one to another can be painful. I would really study which markup to use.
You might take a look at markdown and more importantly WMD which is a What-you-see-is-what-you-mean editor that produces semantically correct html, which should be predictably mung-able to CCR/CCD using mere xslt.
Thanks for exploring these kinds of healthcare IT mashups.
-FT
At Group Health in the Puget Sound area (Seattle) their 580,000 member / patients were able to "write" to their charts (via email) even before the providers were doing CPOE..
ReplyDeleteNo it doesn't replace clinical documentation it simply providers another source of data that they enter. People seem to foget that much of our "clinical documentation" is nothing more then a provider transcribe what the patient tells them each day. (the VA has experimented with patients entering into the clinical chart as well as providers)
Health care starts with the conversation between patient and provider and it is critical that we start the design process with their needs in the forefront..
With CIO's and Providers driving the process we often end up viewing patients as the recipient of the data instead of as a co-creator of it.
Your post brings up some very valid points. As a consultant, I often try to encourage providers to discuss clinical issues arising out of the EMR movement. Recently, in a discussion with a McKesson agent, I asked why clinical documentation had not been properly addressed with the advancing technologies. However, I also caution that as providers, we need to ask, "how am I culpable in this situation?" I feel that providers should be looking for ways to ensure the proper exchange of data when seeing a patient. It would seem counterintuitive to your practice to treat a patient and then not ensure that all data regarding that interaction is not made available for possible follow-up treatment. Providers are the driving force behind "meaningful use." Unstructured text has a definite role in the forwarding of data. As technology evolves, providers must insist that any technology allows them the application of unstructured text. On another note, one I'd like you to address in a future post; discharge summaries need to ensure proper exchange of data. In my work I see way too many errors made on discharge summaries. Medication reconciliation and demographic information are the top errors made by providers as documented by my company. If EMRs are assisted by the utilization of EHRs, why do these issues persist?
ReplyDeleteLove seeing EMR being looked at from this vantage point.
ReplyDeleteIn a perfect world, the wiki is a perfect vehicle for living documents such as medical records. And, as evidenced by Wikipedia, they’re perfectly capable of being indexed in such a way as to provide meaningful (and secure) data back to appropriate stakeholders.
However, I suspect a raw wiki complete with missteps will be derailed as inefficient in our imperfect litigious world.
Under similar pressures, corporate boards have been using a wiki-like application to aggregate financial, resource, and forecast reports in an application that empowers the “publication” of a final draft, complete with sign-offs and appropriate regulatory reviews. After producing a final draft that incorporates the contributing reports in a systematic manner, the pieces are deleted. It’s not perfect, but it does encourage a quick and accurate aggregation of data, an actionable report, accountability, and the opportunity to mitigate risk.
Again, not perfect, but it appears to work in an imperfect world.
The system I am familiar with: http://www.boardbooks.com/diligentbooks/about.shtml
Computers are good at rules.
ReplyDeleteHumans are extremely efficient at scanning, interpreting, and extrapolating.
Leveraging the skills of the humans involved (the patient, as noted by Alliance4Health, and the entire clinical care team) and efficiently capturing their observations with a wiki is a great re-application of technology for a somewhat different purpose.
I'm interested in the assessment criteria you'll apply to decide if the wiki is working?
While these "free text" concepts sound very good, there are a couple of practical problems:
ReplyDelete1. Redundancy: Clinicians tend to repeat information that has already been entered in a structured way. For example test results and prescriptions are often repeated in the text.
2. Inconsistency: When clinicians repeat/describe situations verbally, they will occasionally provide information that is inconsistent with the data in the chart. For example, the CPOE system might show a medication with a certain dose. A resident who is verbally describing what happened to a patient from memory might mention an equivalent medication with a slightly different dose.
We need to remember that these systems are used in a stressful social environment by users who frequently view clinical documentation as an annoying obligation that needs to be rapidly completed.
John, will there be any accommodation made for a dictation/transcription option as a means of getting information into this new form of clinical documentation?
ReplyDeleteThanks John - great idea. How about using the same approach to clinical guidelines?
ReplyDeleteHow will you address the billing issue, which is why I think each provider repetatively enters labs, imaging and, my favorite, the ROS "and all others negative."?
ReplyDeleteThis might be a very useful way to leverage collaborative IT tools to make the document creation easier. I suspect there needs to be major advances in these Web 2.0 tools before the common doctor can handle them, but it is nice to see a bunch of geek-doctors willing to give it a try.
ReplyDeleteBut, it seems to me this is conflating two things: (a) application and workflow used to create and/or view clinical information, and (b) the legal medical record.
The standards based medical documents such as CDA are not intended to be used for document creation or even viewing. They are designed to capture a persistent view of the data in the form of a document. In this context a document has the characteristics of (1) persistence, (2) stewardship, (3) authenticity, (4) context, (5)wholeness, and (6) human readable. (Ok, so CDA doesn't knock #6 out of the park.)
So, I just think that this is could be a good application for for creation, updating, and viewing. But I don't think it is a document.
IHE is working on an augmentation of XDS/XCA that might be very useful here. Given that you want to keep modifying your wiki for your organizations use you likely don't want to force a publication event before others across the NHIN can access the data. This new project is looking at creating a mechanism where your system can publish that it is willing to create a document upon demand. Then when someone else decides that they need that document, likely because your patient is at their facility, they can request that a 'document' be created. Thus the document is created upon demand, and once someone else has used it the document will become persistent.
This topic, I believe, is an important discussion and goes to the route of physician assessment, relationship, and proper care of the patient. Repetition or repeating of aspects of a patient encounter is a hallmark of treatment. By examining many, for example, healthy people in the same way with the same diligence of expression, helps the provider recognize deviance.
ReplyDeleteIt has always remained as a dictum for me when a neurology mentor once said to me, "My exams are always boring and that's the way I like it." There are just some things that ensure a comprehensive thoughtful exam and we can not easily circumvent it for the patient's sake and quite frankly our own.
Health has taken far too long to appreciate the value in simply, ubiquitious, web architectures. Wikis are one excelent way to embrace the problem of complex (perhaps unstructurable) health information. With this architecture the innovation potential is endless because the innovators don't have to come from the health industry. What about using something like Tweetdeck to post Tweets to the patient's wiki. You can even do this from your iPad.
ReplyDeleteA wiki is a very intriguing idea for documenting team care. One issue occurs to me: how do you handle disagreements such as the resident heard a murmur and the fellow did not? Both contributions to the record are valid and important to keep in view; just updating the day's heart exam will obscure the earlier finding.
ReplyDeleteBoth opinions would be reflected in the journal of changes that accompanies the Wiki.
ReplyDeleteThe attending who signs the wiki has the final say - he/she can reflect both opinions, one opinion, or a different opinion when signing and locking the wiki each day.
In terms of differing exams--though the record of all exams would be in the "history" portion, if it's anything like MediaWiki the attribution to different providers will be only accessible to the devoted searcher. As an alternative, you could imagine having exam notes started by the intern, then added on to by others, but with attribution for each change, like:
ReplyDeletePULM: Good air movement, clear except for crackles at right base [Dr. Intern]; crackles clear after cough; [Dr. Resident]
ABD: Distended, soft, non-tender [Dr. Intern]; tender to deep palpation at RUQ; bulging flanks and fluid wave [Dr. Resident]; tenderness approximately equal to when pt seen during last two hospital admissions by me [Dr. Attending]
Whether resident or attending comes third in this chain of exams, they will have a harder time seeing what the intern did and what has been added by the second examiner, without really investigating it specifically--something that would take time and probably wouldn't be done regularly unless they were really specifically working with the intern on a specific aspect of the exam. Most of the time several teaching points and refinements in assessment for the intern (to be taught by the third examiner, in this case the attending) would likely be lost if the changes above were not attributed in the face sheet.
Another approach, not mutually exclusive, would be another kind of cue--for instance, all attending notes defaulting to a blue sans serif font, and all housestaff notes in a black serif font, with font determined by author of change rather than document template. The attending author could change their font to the housestaff black serif font if they wanted to produce a single document (e.g., letter for an employer excusing patient from absence for work while having a rule-out-MI admission, which should have a standard appearance) and were only correcting a typo or something minor. This would end up reading somewhere between a Wiki and a Word "track changes" document.
-Joe (PGY3, BIDMC medicine)
I agree with you, John...this concept of "telling the story" is much better motivated than the current dominant influence on clinical notes, which boils down to billing and defensive medicine. I've advocated in recent years that we should apply Twitter-like length constraints on notes to force clinicians to be succinct and efficient. There are plenty of physicians who still write 2-3 page progress notes-- nobody reads them and the patient suffers as a result.
ReplyDeleteWe played with a prototype of a similar concept at Intermountain in 2002, but it functioned more like a message board for the care team than a wiki.
Peter Rossos MD
ReplyDeleteGreat comments regarding interdisciplinary documentation John.
A number of University of Toronto hospitals developed MD web sign-out tools to augment their EPRs a few years ago.
We are presently upgrading ours at the University Health Network & Mt. Sinai Hospitals to serve multidisciplinary communication including interfaces to patient-centric web paging/messaging & whiteboards.
Kindest regards,
Peter
And now, in 2012 it is very much common ground of many softwares and sharing/ social platforms.
ReplyDeleteThis is reality and I am sure, this is going to be a majoe aspect of care provision. As more and more patients are knolwedgeable and want their role in the fate of their healthcare decisions. So creating such platform will not be a commodity but a necessity. One good day healthcare will wake to this new wave change of disurpption and realize that it is changing the landscape throught collaboration of patients and making it easy for providers to amment already create excellent records by patients using some templates of wonderful doctors and providers which are much more accurate then those of a very experienced doctor but at that point of time he was not at his 100% of work while writing those medical records.
Just imagine, how google documents are becoming more famous, and all those have similar features which are the concept of this post.
We at KPJ Healthcare in Malaysia, have some thing similar but at a much basic for patients. Hope if Dr Halamka can add to this now in 2012.