ABBI+Content+Workgroup+Discussion

include component="page" wikiName="siframework" page="ABBI Header"

=Content Sub-workgroup and Strawman=


 * Content: A Blue Button file must be both machine-readable and human-readable.**


 * In Scope**
 * Content needs to connect to meaningful information to explain what it means. [From 08292012 Call]
 * Leverage work done by the ToC S&I Initiative
 * Leverage work done by HL7 and Consolidated CDA
 * Leverage work done by VA in the Current Blue Button Format (version 12)


 * Requirements**
 * 1) File must be both human-readable on multiple platforms: PC, Mac, iOS, and Android.
 * 2) File must be printable.
 * 3) File must be machine-readable.


 * Use Cases**
 * Use Case 1 (UC1) - A patient can download a copy of his/her records and is able to read and print it out.
 * Use Case 2 (UC2) - A patient can point a software or web application to their Blue Button file and it can parse it.


 * Straw Man Proposal for a Content Format - by @aviars**

Here is one proposal for a content format based on the existing Blue Button Format, which makes use of ".ini" file format. [] Here are a few notes.


 * After talking with a doctor I was reminded of the importance of the "MicroPHR" concept. In a nutshell, the idea is to keep the most important information medications, allergies, and a problem list at the top, and keep the rest of the information as extra information. We could think of this information as the key information that can be conveyed on a wallet-sized card.
 * With its section headers, I could easily imagine how one could easily add/transmit just section of a BB, using this ".ini" approach.
 * This is not XML, nor is it an ideal solution for complex, codified information intended for incorporation into HIT systems. This is designed for the patient, and can be read without any transform. It would make sense to me to have a top "MicroPHR" section which contains the information mentioned above and to perhaps give the patient a way to download this data in a pocket sized format and/or embedded in a QR code.

Straw Man Proposal for Content - XHTML
I just don't see anything as good as a CCD for containing the kind of information Blue Button requires. The CCD was designed specifically for this and is a supported and up-to-date standard.

My proposal is to transform a CCD to XHTML and add a twist: **__include the original CCD in the XHTML inside a non-visible element.__** This is, in effect, a hybrid document. The XHTML file is what is made available to the patient. They will be able to view it in any web browser. The patient will not see all the complex XML of the CCD, but it will be in the document.

The CCD can be transformed to an XHTML file using XSL. Many vendors already have this functionality to create HTML from the CCD narrative block. __Only minor changes to the XSL are required to create XHTML and include the original CCD within a hidden element.__ It's not recommended to use stylesheet preprocessing instruction as this is poorly supported. The XHTML should be a standalone file. It's recommended to use a file extension of ".htm" instead of ".xml". Most operating systems will use the default web browser to open ".htm" files while ".xml" is less specific.

Tom Reventas, treventas@e-mds.com

Feedback or comments? Use the discussion form below.

media type="custom" key="20709664"

include component="page" wikiName="siframework" page="ABBI Initiative Contacts" include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"