The past decade has seen radical transformations in many industries due to the application of artificial intelligence to large scale data. Retail, advertising, transportation, and manufacturing are radically different today than they were 10 years ago. Healthcare has been slower to change, and the lack of data integration has been a key roadblock preventing more innovation. Anyone who has received care at multiple organizations knows that every provider has their own records and each doctor you talk to only has visibility to a portion of your overall history.
The Center for Medicare & Medicaid Services (CMS) is trying to change that with their new “Data at the Point of Care” pilot program which promises to give doctors “A 360 degree view of your patients’ history.” This innovative program allows providers to get access to the full claims history for the Medicare patients they treat. Organizations participating in the program get access to an API (Application Programming Interface) that returns the data for all of their patients in electronic format using the FHIR (Fast Healthcare Operability Resources) standard. Because this data comes directly from the CMS database, it includes all Medicare covered services for those individuals. This includes claims under Medicare Part A&B as well as any prescriptions filled under Medicare Part D.
The availability of this level of data will enable healthcare to see the same kinds of progress and transformations that we have seen in other industries. As an example, instead of having to manually record a patient’s medication history and reconcile that against previous prescriptions, providers will have access to all of a patient’s data electronically. Potential gaps, such as a patient stopping a medication without consulting a physician, or a potential drug interaction for a newly prescribed medication, can then be identified automatically. Even more importantly, once these processes are automated instead of being manual, they are no longer constrained to occur only in a traditional physician office visit. A physician could apply this automated monitoring to all of her patients to proactively identify patients who have had a relevant change in their health history and might be in need of care. The model shifts from reactive care of patients when they have a problem to proactive care focused on preventing dangerous and costly medical issues from arising in the first place.
Taking advantage of all of this new data will require providers to beef up their analytics capabilities. While access to data is a necessary precursor to the more advanced care, is it not the final step. Providers will need to be able to ingest this data in a timely manner and abstract and summarize it into useful high level information about their patients. They then will need to employ advanced analytics and artificial intelligence in order to predict who is at risk and who will benefit from preventative care services and when. Our work at ClosedLoop is centered around enabling payers and providers to make that transition.
Data at the Point of Care is part of the overall data strategy being pursued by CMS. This strategy is a multiyear, coordinated effort by CMS to modernize the availability and inoperability of Medicare data. CMS has built a single data warehouse which contains the claims histories for all Medicare beneficiaries. They are then making the data in this warehouse available to different groups for use in improving patient care. This began with giving access to the beneficiaries themselves through the BlueButton 2.0 initiative. Using this API, Medicare beneficiaries can access their own data in an electronic form and authorize apps such as Apple’s Health Kit to get access to their data. This API has been used for research, health coaching, and to improve the onboarding process of new patients. Beneficiaries maintain full control over who can access their data and what they can see, and software developers can build applications that consume this data in a standard way.
In addition to BlueButton, CMS has launched the Beneficiary Claims Data API (BCDA) which allows Accountable Care Organizations (ACOs) to access the data for their assigned beneficiaries. ACOs share financial responsibility for the cost of care of their patients, and having access to the claims data for their beneficiaries allows them the additional information they need to manage those costs. The BCDA is open only to Medicare ACOs, but the Data at the Point of Care initiative will open this same level of access to Medicare Fee For Service providers.
While BlueButton and BCDA are currently operational with live data on actual patients, Data at the Point of Care is only in a pilot phase. Providers who treat Medicare Fee for Service members and who have experience working with claims data are encouraged to apply to be part of the pilot. During the pilot providers will work with simulated data to understand the benefits and potential workflows and to iron out technical issues. Due to the privacy and security concerns associated with healthcare data, all of these initial issues must be worked out and resolved before real patient data is exchanged.
While each of these APIs provides information for a specific purpose to a distinct community, they are all fed by the same underlying data warehouse, and utilize the same FHIR standard for providing access. FHIR replaces older, healthcare specific protocols like HL7 with modern interfaces based on the web standards of HTTP and JSON that are used across industries. In addition to standardizing the technology, FHIR provides data formats for common healthcare resources such as medical and pharmacy claims. This means that the FHIR claims data coming from CMS will look the same as claims data coming from other payers.
Indeed, CMS is actively pushing Medicare Advantage (MA) plans they regulate to follow their lead. The 2020 Interoperability and Patient Access Final Rule includes provisions that require all Medicare Advantage plans and certain Medicaid plans to make available Patient Access APIs that are similar to BlueButton for all of their beneficiaries by 12/31/2020. The rule follows on with additional regulations that require these plans to allow patients to take their claims history with them when they switch plans, and several additional safeguards to maintain patient privacy and data security. No requirement yet exists for plans to share data with providers using something like the Data at the Point of Care API. However, they will all have the infrastructure available to do so and many payers will create these APIs on their own to implement value-based care and reduce medical spend.
There is more work to be done. Ultimately, all of the data being served up by these APIs are just administrative claims. They include the fact that a test was run and how much it costs, but not the final outcome. The actual detailed medical records, lab results, and clinical notes still remain with the provider, and these APIs do not provide a data sharing mechanism for that more detailed data. However, administrative claims have proven to be very valuable in analyzing health risks and identifying gaps in care. Although they don’t have the level of detail available in full medical records, they do provide a comprehensive picture of the care a person receives and contain some information, such as prescription refills, that are not captured in traditional medical records.
We have come to expect a very high level of service and personalization in other industries. As access to data improves, innovative organizations will find ways to bring that same level of service to healthcare, while still respecting the privacy of individual patients. Giving the right people access to the right data at the right time is an essential first step in making this transition. CMS has been leading the way in data interoperability through their BlueButton 2.0 and BCDA initiatives, and the new Data at the Point of Care is another big step in the right direction.
Interested in learning more about changes CMS is pursuing and other data initiatives? Check out these blog posts: