One of the challenges with Meaningful Use has to do with the way that it started; first with one kind of document, the CCD (using the HITSP C32 specification), later migrating to CCDA which supported multiple document types. Meaningful Use never gave any guidance on which CCDA document types to use for different purposes, and in fact, defined content based on a combination of document types found in CCDA. As a result, most folks are still using CCD, which really is designed to be a general summary of care. But physicians generate other kinds of documents during routine care, such as a history and physical note, or a consult note, or an imaging report.
Because the 2011 edition required use of CCD, but these weren't related to what physicians were generating, the documents were automatically generated. And since they were automatically generated, there's no physician in the loop to determine what is relevant and pertinent. Vendors have built interfaces to make it possible for them to select relevant and pertinent, but that takes time in the physician workflow. So vendors get told to automate the generation process, and depending on how they do that, the result is often less than ideal.
By about 65 pages.
I've talked about this problem previously, and at the time, it seemed to me that the solution should have been obvious: Use the physician's existing documentation process to select what is pertinent and relevant.
But the evolution of Meaningful Use from a document that physicians don't generate to a collection of documents which they might use assumed a level of integration with physician workflows that simply wasn't allowed for by Meaningful Use timelines. Basically the setup of clinical documentation workflows is something that is usually done during an initial EHR installation. It isn't redone when the system gets upgraded, because that is usually a non-essential disruption for the provider. But that is what it would take to use the new document types. Now, that process will likely occur over time as hospitals and providers update their systems to improve their workflows, but in the interim, it leaves automatically generated CCD 1.1 as the documents that get exchanged for Meaningful Use.
Now we get into the disconnect. Most EHR developers that I've talked to know that clinicians are the best judge of what is pertinent and relevant content to be exchanged. This results in the choice of what is relevant to be set up as system configuration parameters. Lawyers and HIT administrators (and sometimes physicians), tend to err on the side of caution when trying to figure out what should be sent to a receiving system in this configuration.
Which results in a 70 page "summary" of the patient data, which is at least 65 pages too long for anyone to read (and probably closer to 68 pages too long for the average physician). As a result, when these documents get created and sent, a physician will look at them once or twice, and then decide they aren't useful and never look at them again.
How do we fix this? I ran into a similar challenge over the last year and the answer that I came up with then was to talk to clinicians about what the right rules were for limiting the data that would be provided. There were three sets of limits, time based, event based, and state based limits.
Information about active issues needs to presented regardless of time (assuming appropriate management of active and resolved in the provider's workflow). This would include problems (conditions), allergies, and any current (active) medication.
Event based limits are based on recent care, e.g., activities done in the last encounter. So any problem or allergy marked as resolved in the last encounter would also show up so that you could see recent changes in patient state. Additionally, any diagnostic tests and/or results related to that last ambulatory visit would also be included (inpatient stays need a slightly different approach because of volume). Finally, the most recent vital signs from the encounter should be reported.
Time based limits include dealing with stuff that has happened in recent history. For this, for an adult patient, you probably want the last year's immunization history. You likely want to know about any problems whether they were active or resolved in the patient's recent history (we wound up equating recent history to the last month).
There are certain exceptions that may need to be added, for example, for pediatric immunizations you might extend history to a longer period, but in an age dependent way.
HL7 Structured documents has agreed to begin working on a project in which we will work with clinicians, and reach out to various medical professional societies to help define what constitutes a reasonable set of limits for filtering relevant data. I'm thinking this would be an informative document which HL7 would publish and which we would also promote through the various professional societies collaborating on this project.
So, I think I was both wrong and right in my original post on this topic. It is impertinent for a developer or a system to decide what is relevant, but, it is possible, with the participation of clinicians, to develop guidance that system implementers could use to configure the filter of what should be considered relevant. And my advice to system designers is that while you might want to supply a good set of defaults, you should always let the clinician override what the system selects.
Because the 2011 edition required use of CCD, but these weren't related to what physicians were generating, the documents were automatically generated. And since they were automatically generated, there's no physician in the loop to determine what is relevant and pertinent. Vendors have built interfaces to make it possible for them to select relevant and pertinent, but that takes time in the physician workflow. So vendors get told to automate the generation process, and depending on how they do that, the result is often less than ideal.
By about 65 pages.
I've talked about this problem previously, and at the time, it seemed to me that the solution should have been obvious: Use the physician's existing documentation process to select what is pertinent and relevant.
But the evolution of Meaningful Use from a document that physicians don't generate to a collection of documents which they might use assumed a level of integration with physician workflows that simply wasn't allowed for by Meaningful Use timelines. Basically the setup of clinical documentation workflows is something that is usually done during an initial EHR installation. It isn't redone when the system gets upgraded, because that is usually a non-essential disruption for the provider. But that is what it would take to use the new document types. Now, that process will likely occur over time as hospitals and providers update their systems to improve their workflows, but in the interim, it leaves automatically generated CCD 1.1 as the documents that get exchanged for Meaningful Use.
Now we get into the disconnect. Most EHR developers that I've talked to know that clinicians are the best judge of what is pertinent and relevant content to be exchanged. This results in the choice of what is relevant to be set up as system configuration parameters. Lawyers and HIT administrators (and sometimes physicians), tend to err on the side of caution when trying to figure out what should be sent to a receiving system in this configuration.
Which results in a 70 page "summary" of the patient data, which is at least 65 pages too long for anyone to read (and probably closer to 68 pages too long for the average physician). As a result, when these documents get created and sent, a physician will look at them once or twice, and then decide they aren't useful and never look at them again.
How do we fix this? I ran into a similar challenge over the last year and the answer that I came up with then was to talk to clinicians about what the right rules were for limiting the data that would be provided. There were three sets of limits, time based, event based, and state based limits.
Information about active issues needs to presented regardless of time (assuming appropriate management of active and resolved in the provider's workflow). This would include problems (conditions), allergies, and any current (active) medication.
Event based limits are based on recent care, e.g., activities done in the last encounter. So any problem or allergy marked as resolved in the last encounter would also show up so that you could see recent changes in patient state. Additionally, any diagnostic tests and/or results related to that last ambulatory visit would also be included (inpatient stays need a slightly different approach because of volume). Finally, the most recent vital signs from the encounter should be reported.
Time based limits include dealing with stuff that has happened in recent history. For this, for an adult patient, you probably want the last year's immunization history. You likely want to know about any problems whether they were active or resolved in the patient's recent history (we wound up equating recent history to the last month).
There are certain exceptions that may need to be added, for example, for pediatric immunizations you might extend history to a longer period, but in an age dependent way.
HL7 Structured documents has agreed to begin working on a project in which we will work with clinicians, and reach out to various medical professional societies to help define what constitutes a reasonable set of limits for filtering relevant data. I'm thinking this would be an informative document which HL7 would publish and which we would also promote through the various professional societies collaborating on this project.
So, I think I was both wrong and right in my original post on this topic. It is impertinent for a developer or a system to decide what is relevant, but, it is possible, with the participation of clinicians, to develop guidance that system implementers could use to configure the filter of what should be considered relevant. And my advice to system designers is that while you might want to supply a good set of defaults, you should always let the clinician override what the system selects.
I call this the Goldilocks syndrome.
ReplyDeleteWe have been receiving CDA based documents (e.g. C32, CCD, HL7 Unstructured documents, and now C-CDA document templates) for a number of years from many different sources using date range (service start and stop timeframes) as the requesting criteria.
Some of our folks will say they get too little information, others say they get too much information, and others say they get just the right amount of information. I cannot keep anybody happy.
We see C32/CCD documents with everything stuffed in them. Discharge summaries in the text element of an encounter. We see episodic, encounter and full summaries. Other cases, we see limited information in the encounter section of the summary document with separate documents for discharge, progress and procedure notes. All of these documents validate just fine. The specifications are flexible to handle these situations, but as a receiver of information I have to be prepared for all scenarios. I would love to have policy guidance here from ONC.
I agree that the clinician may know best what should be released, but in doing so you may be putting a person in the middle of automation.
So I realize that I will have three beds to sleep in and most of the time never get a full night’s sleep.
So in this fairy tale, everybody does not live happily ever after.
Somewhat related is the recently inaugurated "FHIR Clinical Connecthons" (happening today as a matter of fact). This is focused on testing fitness for use of FHIR clinical resources with clinicians in the PC work group.
ReplyDelete