Thursday, April 26, 2012

Because We Can

I've been having and reading discussions about standardizing Advance Directives with a number of different groups.  There is a suggestion out there that it is time to create a standard format for conveying information about an Advance Directive, perhaps using CDA.  Others, coming from the US HIT Standards Committee Power Team seem to suggest that current mechanisms for recording Advance Directives in the Consolidated CDA need to be extended (see page 7).

The point made in the latter document is that it isn't enough to know that one exists, but that one must also know where to get it and how to access it easily, that it should (in stage 2) have information about CPR and Intubation, and in stage 3, it contain more detailed information and support versioning.

I don't support an effort to standardize the format of Advance Directives at this time.  While standardizing the information is necessary, the US policy environment is such that much more is needed before that can even be useful.  I'd rather not expend effort on it from a pool of limited resources without first ensuring that the end result will be useful.

One of the suggestions is that the document record information about whether a patient should be intubated or resuscitated.  This is challenged by the fact that orders for DNR and/or Intubation are Physician written orders, and have different standings in different states.  They may also be conditional based on a particular hospital stay or procedure, may be time limited, et cetera.  The first step, before "standardizing" such information would be to first understand the policy environment, and to make sure that all policy variations that need to be encoded are understood.  We don't yet have that information readily available in the US, and until we do, deciding how to "standardize" the format is kind of beside the point.  We can tell you how to transmit the information, but we cannot tell you how to interpret it.  How useful is that?

Some work has been done by Aging with Dignity to develop a "standard form", known as Five Wishes.  Even that widely accessible and broadly funded activity has run into policy challenges in developing a form that could be readily used in all 50 states of this country (right now, it only works by itself in 42 states, 8 others require "workarounds").

The next challenge is deep.  An advance directive can be subsequently overridden by a later version (as noted in the first link).  How would you ensure that you had the latest version?  To do so would require policy with regard to registration of such documents, combined with a technical infrastructure to support it.

Don't get me wrong.  I believe that it will be useful at some point to support standardizing the format of an advance directive, but there are certainly bigger fish to fry right now.  I'd rather see the limited resources we have applied to more critical issues.  We need more than "because we can do it" as a reason to create a standard.  The environment has to be right as well.  If the standard exists, but nobody can use it because the policy environment won't support it, we're just wasting time.



4 comments:

  1. Sounds like the situation 6 years ago when we started on Privacy Consent. I might suggest a similar pathway of stepping stones. Start with capturing unstructured patient centered preferences in a way that is consistent with the paper world, while adding minimum codeability to it so that it can be detected that something exists. This doesn't help with automation, but does help with knowledge-about the existence of a patient centric advance directive. Most importantly it allows for a pathway to advanced encoding of ... advance directives.

    ReplyDelete
  2. Re finding the most current version - if each patient has a single cloud-based consent and advanced directive profile, then this is not an issue. All you need is the URI for that directive. If the patient chooses to provide the URI, problem solved. If not, then that is their choice and we are back to scrambling for the documentation.

    ReplyDelete
  3. This comment has been removed by the author.

    ReplyDelete