This week I attended the #ONC2015 Annual meeting. It was a great event with a lot of buzz and plenty of people passionate to make health care better through the application of technology. Interoperability was at the top of the agenda and infused every aspect of the meeting. After an intense two days it is time to get back to work at CMS and focus on the “coal face” of interoperability: Updating BlueButton for Medicare beneficiaries.
BlueButton Claims Data
I am taking a look at Medicare BlueButton data as it is formatted in plain ASCIII text files. I have also been looking at Consolidated Clinical Document Architecture (C-CDA) Standards Documents which are the basis of BlueButton Plus structured text documents. After delving in to the intricacies of the standard and of NIST test documents I feel the need to confirm my understanding with the BlueButton community at large. The clarification I am looking for originates from the very name of the core document – Consolidated CLINICAL Document Architecture. The CMS BlueButton data also includes CLAIMS data and if you search the CCDA standards there appears to be no mention of Claims information in the document. After looking through some of the parsing libraries that have been built my suspicion seems to be confirmed. Amida-tech’s CMS Parser for Blue Button identifies sections that do not have a data model. it also identifies self-entered data sections that can be mapped to existing clinical sections. However many of those sections are generated from self-entered data and should not be allocated the same level of provenance as data entered from clinical sources. An example here might be self-reported implantable devices or self-reported immunizations.
The HL7 standards do have documentation for a Claims Attachment XML Package. However, these are not part of the core standard.
Josh Mandel has a repository of sample C-CDA documents. These typically cover EHR vendors and not payer organizations and their claims data.
As I look to creating a Data-as-a-Service for BlueButton data at CMS I need to adopt a structured data format. In doing this I want to minimize re-work out in the community. I also want to avoid getting bogged down in protracted standards definition work. I am therefore reaching out to the BlueButton and FHIR development community to gather your views, guidance and sage advice.
My thinking is this…
In upgrading from text and pdf file formats to offer XML and JSON as additional formats I should do the following:
- Where sections of the CMS BlueButton data directly map to established data models in the CCDA standard the CMS structure will adopt the same coding standard and naming conventions.
Examples of these sections include:
– demographics
– providers
- Where data can be directly mapped to established clinical sections we should use the same coding and naming conventions, as per item 1. However, where those sections identify a source we will add a “source” identifier to the section. Eg. Self-entered. This should help to maintain data provenance.
Examples of these sections include:
– implantable devices mapped to medical devices with a source of “self-entered”
- Where sections are not mapped to an established CCDA section we will:
– identify the data source. Eg. Medicare Part A etc.
– use fields names that carry through the grammar, simplifying and avoid internal acronyms wherever possible based on the original source field names. Eg. Cost, Allowed, Paid, Diagnostic Code 1 etc.
- Once we have an XML format we will take the format and use it as a basis for a JSON data format.
My questions to the community:
- is this a sensible approach?
- am I missing any critical document standards that I should be applying?
- is there a better way to do this?
You can submit a comment to this post, or email me at mscrimshire AT gmail DOT com.
[category News, Health]
[tag health cloud, ONC2015, BlueButton]
Mark Scrimshire
Health & Cloud Technology Consultant
Mark is available for challenging assignments at the intersection of Health and Technology using Big Data, Mobile and Cloud Technologies. If you need help to move, or create, your health applications in the cloud let’s talk.
Blog: http://2.healthca.mp/1b61Q7M
email: mark
Stay up-to-date: Twitter @ekivemark
Disclosure:
I am currently HHS Entrepreneur-in-Residence working on an assignment to update BlueButton for Medicare Beneficiaries. The views expressed on this blog are my own.
I am also a Patient Engagement Advisor, CTO and Co-Founder to Medyear.com. Medyear is a powerful free tool that helps you collect, organize and securely share health information, however you want. Manage your own health records today.
Medyear: Less hassle. Better care.
B
Regards
Mark Scrimshire
Health & Cloud Technology Consultant
Blog: http://2.healthca.mp/1b61Q7M
email: mark@ekivemark.comStay up-to-date: Twitter @ekivemark
My Card: http://2.healthca.mp/1eyWCqn
via WordPress http://2.healthca.mp/1CvW7b4
