Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, April 25, 2012

Footballs, Star Wars, and Dr. Doolittle

What do Footballs, Star Wars, and Dr. Doolittle have in common?  While normally unrelated, they come together in a post from Dirk Stanley over at his Free CMIO Perspecive blog.

Dirk starts out with a discussion of Push and Pull (remember the push-me-pull-you from Dr. Doolittle).  He notes that the lack of a national patient identifier prevents adequate use of pull.  However, push and pull are two sides of the same animal. Even with a national patient identifier, it is still necessary to send enough patient demographics to ensure patient identity when communicating, regardless of whether you are pushing or pulling. And while NwHIN Direct is dealing with the push side, NwHIN Exchange includes specifications for push and pull (see Query for Documents).

The remainder of his discussion is one what one would pull, which he describes as a football.  Dirk suggests that a single summary format be provided for all to use.

There's been some efforts from a few professional societies to move towards a single medical summary format. In fact, most of the documents providers use contain quite similar information:  Problems, Medications and Allergies top the list and are present in just about all of them.  I spent a good bit of time harmonizing the various definitions of the Summary of Care Record specified in the Meaningful Use Stage 2 rules.

Dirk describes his Hand-off note, which he calls the "Football".

It contains:

  • Patient Name and DOB
  • Emergency Contact Information
  • Code Status
  • Handoff Date
  • Handoff From
  • Expected Handoff To
  • Author (who is pushing the football today)
  • Co-authors (who pushed the football in the past)
  • Allergies
  • PMhx/PSurgHX (History including Problems and Surgeries)
  • Significant Studies
  • What I Did
  • Active Medications (at time of Handoff)
  • To Do List

The simplicity of most of his section titles (with the exception of PMhx/PSurgHX) is appealing , especially from a patient perspective.  All of this content is already available in the CCR and CCD and can also be included in any Consolidated CDA document (in other words, "been there, done that").  In fact, those documents include more detail.

So, what other stuff is missing?

  • What about family and social history?  Patients keep getting asked for it, why not provide a record of what each provider knew?
  • What about vaccination history?  This is important for ongoing health maintenance.
  • What about a section on "What I decided or recommended?" to show the clinical judgments made during the encounter? 
  • What about a section on "What I discovered?" that describes what information went into decisions or recommendations (e.g., significant physical examination findings). 

Those would make for a more interesting and complete football, but we are still back to what CCR and CCD already provided.

Clinical documentation serves several purposes.  It provides a legal and medical record of what was done during an encounter.  It communicates to other providers, or acts a reminder to the same provider in the future.  It acts as evidence that appropriate procedures were followed (e.g., for accreditation or billing purposes).  Healthcare providers in different settings need to record different information because the documentation serves these different purposes.

I think Dirk's idea that we can create a summary document that serves one purpose is laudible, but, I'm also certain that providers will never agree to adopt any one particular format that doesn't address their workflows.

At one point in time I knew of a site where two providers each had their own documentation format for what they did in a visit, duplicated with slight variations to deal with different state rules.  Neither would agree to use the other's format, nor did they desire to consolidate that two different state variants, even though the documented the same things even in the same order.  Unbeknownst to them, it was possible to encode the headings they used identically to a particular vocabulary (LOINC), and that is what the software I was deploying at the time did. So as far as the software was concerned, the data was similarly encoded and could be compared in meaningful ways in the application, even though the providers saw it differently.  This becomes very important.

Healthcare providers are very jealous of their processes.  I'm not sure I'd go so far as to introduce a new process, or a new document format to them.  Instead, I'd develop a better way to classify the information they already provide.  LOINC provides a great list of codes for document sections, but doesn't connect it well into an ontology.  Consider the following different ways that one can represent a reason for care:

  • Admission Diagnosis
  • Reason for Visit
  • Chief Complaint
  • Reason for Referral
  • Pre-operative Diagnosis
  • Pre-procedure Diagnosis

Each of these is used in different contexts, and some contexts even use several of the above.  Yet I see little in medical ontology that describe these different data points as describing reasons for care.  I don't see a need to harmonize the different contexts to say "Reason for Care", but I do see a great deal of utility in developing an ontology that links these different kinds of "reasons for care" to a single code so that systems can reason across these contexts.

While Dirk asserts that we need a new document to harmonize care, I think a better way to handle the challenge would be to codify and relate the contextual knowledge across the different kinds of clinical documents.  That way, we could enhance existing processes and workflows, rather than replacing them.


  1. Keith - Thanks! Actually, you're not the first to point out the similarity to CCD. (John Lynn also pointed that out.) And I agree with both of you - No need to replace CCD if it already exists. My issue is that from the clinical side, there are surprisingly few good, hard clinical documentation standards. In addition to the "standard buffet", I see a lot of docs creating their own notes for various purposes. While this may have made sense in the old paper days, it makes less sense when trying to exchange information across a care system.
    And in the absence of good, solid clinical governance, nobody seems to be stepping up to build this standard, again, from the clinician's side. (I know you and John and a lot of really talented people have worked on the technical details - Now we need the docs to use your ideas properly.)
    My idea was to push forward a concept - Call it a "brand", if you will - that will get docs to 1. Use the clinical documentation standard, and 2. Know what to do with it.
    You're absolutely correct, CCD contains space for pretty much all of this data, but I was hoping to help package it in a way that docs will understand what to do with it, and when to "hand it off" to someone across the exchange, will help the success of the project.
    Thanks to you and John for the excellent analysis and discussion. I'm lucky to learn from such talent. :)

  2. (By the way, I'm still kind of shocked and flattered that anyone reads my site!) :)

  3. While I doubt that "ALL" doctors will ever agree on every detail, at least CCR/CCD (which is represented by CCD 1.1 in Consolidated CDA) had many medical societies endorsing the DATA contents, e.g., the Massachusetts Medical Association, American Academy of Pediatrics, and American Academy of Family Practice, and American Medical Association. I think other medical associations also endorsed it, though I don't have proof in hand. That doesn't mean any of these groups thinks that CCD is all that they ever need, but I think it means that they agree upon it as the common "football" that Dr. Stanley spoke of.


  4. why cant you use the standard documents and extract the "real" information (football) on the receiving end? The problem with the standard documents (true of many EMR generated notes) is they contain a ton of gibberish and wont be looked at by doctors. The solution is to extract the information doctors really want to see.