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.

Thursday, September 30, 2010

Provider Directories

This isn't a topic I would usually write on, but given other absences, I got tapped to sit in on the HIT Policy Committee Information Exchange Workgroup deliberations and testimony on Provider Directories.  I missed the first panel's testimony because my flight was delayed for policy reasons (the crew needed sleep, a good policy).  Of course that delay due to policy also put me in the middle of rush-hour DC traffic and rain, so a 40 minute drive from Dulles took an hour and 40 minutes. 

There was quite a bit of lively discussion, and you can access all the written testimony here, including mine.  [Note:  That link will get stale, so if you are looking at this after October 2, look here under September 30th, and at that point you should also get the oral testimony and Q&A].  I spent three hours carving up my written testimony down to 4.5 minutes of oral remarks which I rehearsed 3 times yesterday, and then just wound up using that as notes for what I wound up saying unrehearsed because of what I'd heard during the day.

Now, for my OWN thoughts on this meeting, and I do mean my own, because as always, the comments on this blog represent my own opinions and not those of my employer or the standards organizations that I may represent.

There are two orthoganal axes by which I could characterized the MANY different kinds of directories discussed:

1.  Who/What is using the Directory to Communicate
2.  What purpose the communication is used for.

On the who/what:  It's mostly either human-to-human, or computer-to-computer.  Very different use cases, with very different requirements.

On the purpose, it's either for treatment (e.g., ePrescribing, referral, results delivery, or other communication of clinical data to providers), payment (another very big swath), or for operations (quality management...) [which also was not discussed very much at all, although I did allude to it briefly].

Doing this math, this is a 2x3 grid, so I can identify at least 6 different kinds of directories.  For the most part, the testimony used two different terms:  Yellow Pages, and routing.  By the end of the meeting, both terms had been questioned as to what they were, and in part because sometimes they referred to one of the 6 I identified, and other times, a different one.  MOSTLY, but not always, yellow pages fell into the human-to-human category, and were principally addressed in payment.  CAQH's work on the Uniform Provider Directory (did I get that right), or UPD was mentioned numerous times throughout the day, as were several directories used by CMS.  The "Routing" directory fell into the computer-to-computer column, about 50/50 split in treatment/payment.

CDC had a very interesting use case for directories, which was communications of information TO providers, like a public address system used to let everyone know about public health alerts.  I've been working with some folks to TRY to turn that sort of use on it's head, because the number of sources (and thus need for directory updates), for alerts much smaller than the consumer audience for them.  That use case was interesting because they need good recall (as many provider addresses as they can get), but precision is not as vital.

I also heard repeatedly that the need was for "ROUTING" directories, and not yellow pages.  Since I was at the very end of the line, I couldn't correct that terminology soon enough.  It's not about routing.  It IS about getting access to the services needed to support computer-to-computer communciation, which includes authentication, policy support (certifcates), and end-point discovery.  All this talk about Web 2.0 and we are still thinking about policy for routing messages.  That really needs to change.

I heard a number of dings on HL7, but in reality, most I heard were due to the fact some in the room didn't understand it (e.g., OBX structures), and others HAVE not chosen to implement or contstrain it appropriately.

At least one thing everyone agreed on was that we need standards for core directory content.  That's actually pretty easy, because you can just examine key fields in standards like HL7, NCPDP, and X12, and requirements of them in selected guides (e.g., CAQH/CORE or HL7 V2 guides for ELR, Immuniziation, or CCD) to see what that common set should be.  To avoid argument about whether it is core or not, I propose a very simple rule.  If a non-technical person can recognize the content as being the same thing in two or more of the standards, then it is a candidate for the core set.  If it appears in all, then it is certainly a core component.  A lot of stuff won't show up, but that should be OK, because this SHOULD be an Iterative process.  How do begin a journey of a million steps?  By taking the first one.

I was amazed by the continual references to the Internet as if that appeared by magic overnight, rather than being developed over the course of the last 5 decades, and in commerce, really only the last two. The web didn't happen overnight, and not all of these problems will be solved overnight either. Most of those Internet standards we laud are on their 4th and 5th iteration.

A number of commenters reported that there WERE NO standards for this. I pointed out that in fact there are, and by the way, this problem is not one experienced just in healthcare.

The other part that folks seem to agree upon is that this cannot be centrally controlled, and that the technology should support federation (Hey, look at what those internet guys came up with!). 

Walter Suarez summed it up very well.  There is a LOT to take in, and we need to be focused.  I'd go even further, use the 2 axes I described, and prioritize the bunch, then pick the two with the biggest ROI.  Because, as I pointed out over lunch, good policy has to be implementable, and implementable also means sustainable.  We cannot afford to execute on every good idea without understanding both the benfits and costs. 

Oh, and by the way, if this is focused on meaningful use, I'd tend towards treatment and operations (quality), rather than payment, and computer-to-computer, but you know, that is just MY reading of the policies behind Meaningful Use.

So much for not writing today, I'm exhausted but have another 25 minutes before my flight boards.  Next up, an analysis of the ISDS work I posted on between tweets and panels.