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.

Tuesday, November 6, 2012

Progress Update on ABBI PULL

The ABBI PULL Workgroup met today, after a brief weather inspired hiatus.  We addressed 4 questions which were presented by Pierce and Ryan (ONC Coordinator and Presidential Fellow for this project).
  1. Will the same REST Endpoints and Return Objects be used across the industry?
    The point of this question was to address whether there would be different endpoints and data objects for providers, payers or patient controlled health records.  We agreed that in general, the endpoints would be applicable to everyone, and that you could negotiate what kind of content you'd get back (e.g., C-CDA or EOB statement), and that the end-point would be able to send what it had available, or nothing if it didn't have what you were asking for.  This is similar to the Search API that I prototyped.  Another end-point would give you the most recent document containing what is known about the paitent.
  2. What industries does ABBI need to describe endpoints and objects for?
    The basic API would support providers, payers or PCHR systems.  If you wanted to go deeper, you might get into industry specific end-points (but see the next question).
  3. How specific and deep will the endpoints be?
    We could go into detail, but the basic level of the API should support the "Download" capability and requirements for Meaningful Use Stage 2.  We should keep it simple, but be able to extend to other kinds of end-points consistent with the overall approach.  Keeping it simple will increase adoption, because it will meet provider needs for Stage 2.
  4. How can we encourage consistency?
    A well-documented API, with open source and reference implementation
There were a lot of side-bars and more details in all of these questions, but Pierce and Ryan kept great notes.

Meanwhile, I'm still writing code, but have got the dull-drums.  The next batch of code needs to deal with user and client registrations, and I just don't want to deal with it.  Neither do my customers.  So I'm looking for a different way to address it.  Part of the solution may be related to the next bit we'll be looking at next week.

For that, we'll be examining what I've referred to as the million registrations problem in OAuth, and some possible solutions.

Following that, I hope we can address the XML vs. HTML issue for content.  I think the answer to that problem is content negotiation via end-point API parameters, rather than something like an embedded stylesheet.  That just didn't work when I tried it. After all, content negotiation is what the HTTP Accept header is for.

-- Keith

2 comments:

  1. Keith hi; what's your impression of the approach that EligibleAPI has taken (EligibleAPI.com, with a different but related content set? It looks like they are effectively aiming to become a Yodlee-like API service provider across multiple health data suppliers (in this case health insurers & pharmacy beenfits managers). Thanks. -Henry

    ReplyDelete
    Replies
    1. Looks interesting. In this though, they seem to be acting as an intermediary. If every insurer supported a similar API it would be closer to what we seek with ABBI.

      Delete