Posted by:Boston Technology Corporation September 27th, 2018

Interoperability in healthcare, or the ability for distinct healthcare information systems and devices to seamlessly exchange and interpret health-related data, has been a top buzzword in the industry for a while now. This techno-functional enabler for the healthcare ecosystem, is being advocated for its potential to help solve pressing health data availability issues, and thereby pave the way for better delivery of care and patient outcomes.

Along with EMR/EHR records that carry the patient’s health records including diagnoses, tests, prescriptions and the like; health insurance or claims data is also hugely valuable in healthcare’s interoperability endeavor. The combined data could provide additional insight and information surrounding a patient’s medical history in terms of appointments, procedures and treatments availed and aspects such as number of readmissions or expenses incurred on a patient or on addressing specific health conditions.

The use-cases for health insurance data in healthcare and research are many, and there is a handy tool that can help application developers or healthcare interoperability implementers access a reliable data warehouse of claims data, with due permission from the beneficiary. Read on to know more…

Called BlueButton 2.0, this tool is an Application Programming Interface (API) that allows Medicare beneficiaries to share their claims data with 3rd-party apps. It uses HL7’s FHIR and OAuth2.0 standards for beneficiary data and authorization respectively. The API allows developers to build in integration mechanisms for their applications to access more than 4 years of Medicare Part A, B and D data for 53 million+ Medicare beneficiaries. An open-source initiative by CMS (Centers for Medicare and Medicaid Services), Blue Button is a secure interoperability tool to fetch and use claims data for a number of healthcare and health application use-cases.

In order for data to be accessed via this API, the beneficiary must provide explicit authorization to the requesting system/application. All beneficiary identification and authorization, is controlled by MyMedicare.gov.

Providers and caregivers, researchers, payors, or beneficiaries; nearly every type of stakeholder or player in the healthcare and medical research space, stand to derive value from the Bluebutton API when integrated with applications for use-cases of relevance. Given below are some interesting notes about this API that could give you ideas on how to leverage it for your next interoperability or healthcare project:

  • The data provided by the API includes a variety of information about a beneficiary’s health, including the type of Medicare plan, prescriptions, primary care treatments and cost. Nearly 1300 fields from the CMS claims data warehouse have been mapped into FHIR and these are across the core FHIR resources called Patient, Coverage and Explanation of Benefits.

  • The mapped records include Beneficiary Enrollment Record, Carrier Claims, Durable Medical Equipment, Home Health Agency Claims, Hospice Claims, Inpatient and Outpatient Claims, Part D Events and Skilled Nursing Facility Claims. The API leverages coding systems specific to Medicare billing and/or other standard and recognized coding systems.

  • The Explanation of Benefits (also called as Episode of Care) resource carries the bulk of the beneficiary data that can run into several thousands of lines in the API response. The Patient resource contains the beneficiary’s demographics and other administrative, non-medical information including contact information, while the Coverage resource contains the beneficiary’s insurance plan information.

  • CMS says it updates the Medicare Part A and B claims data in its data warehouse on a weekly basis while the Part D data is refreshed monthly. Developers are encouraged to have their applications run jobs to refresh the data they use on a daily basis, while also adhering to the usage limits defined in the API’s Terms of Use.

  • It is important to note that the API does not share information such as the date of birth, SSN and HICN. Security measures such as this would help beneficiaries be less wary of authorizing applications to access their claims data. The applications should therefore have adequate verbiage that lets patient clearly understand what data of theirs will be accessed and how it will be used.

  • Many a time, the system requesting the claims information might be trying to access large volumes of data via the API. To improve performance in such cases, developers are given the option to turn on compression for specific content types. When turned on, the compression is applied when the payload exceeds 1kB in size. This is a very thoughtful feature provided by the API and can lessen the chances of your system being plagued by issues of slow responses or bad user experiences.

  • To help developers with testing their applications that have the API integrated, CMS offers a synthetic data set to test against. All API calls thus return near-real-world values helping you get a fair idea of whether the application is able to meet the objectives it has been designed for. Developers can also access the full synthetic data set – another useful feature if you wish to understand the types of data available, their co-relations and how you can better design your application based on that.

  • It is possible that beneficiaries could initially grant and later choose to revoke access to their claims data. This can be done via the MyMedicare.gov website. In such cases, application behavior must display cognizance of access being revoked and handle the user interface to reiterate to the beneficiary, the specifics of how the application uses their data.

  • All Blue Button API applications must be approved by CMS prior to going live. CMS requires certain conditions to be met by the organization launching the app, as well as information about and demonstration of the developed app. The process usually lasts a couple of weeks and could involve calls and meetings with the CMS Blue Button API Team. It also involves agreeing to Terms of Use, and acceptance to be subject to future audit as part of a Production API access renewal process either for app versions updates and or to keep in sync with the evolution of the Blue Button API itself.

That was a quick overview of the API and its features. Whether it is making your app easier for patients to use by pre-filling data that is relevant to them or giving them a consolidated, unified view of their health history or even spinning up interesting and insightful health dashboards for them to remain engaged in the process of their health care, there is a lot that can be done with a useful interoperability tool like the Blue Button 2.0 API. Researchers can also use the wealth of the CMS claims data warehouse to fetch and gather insights from datasets of interest.

Get started on your Blue Button 2.0 project today and reap the benefits of using this super-useful API! Get in touch with us to learn more or explore deeper aspects of implementation as required for the unique needs of your project or organization.