The healthcare industry suffers from an inability to clearly communicate costs in a timely and easy-to-understand format. This problem is a symptom of interoperability issues and complex agreements between providers, patients, health plans/payers and government regulators. These agreements are encoded in legal language with the intent of being defensible in court. However, the focus on legal enforceability, instead of understandability, creates problems resulting in hundreds of billions of dollars spent annually to administer an inefficient, outdated and complex process for adjudicating and paying health plan claims. The process results in errors and often leaves the patient unclear on how much they need to pay. If these agreements were instead translated into computer code (smart contracts) leveraging Blockchain technologies, the claim process would not only be interoperable, but also drive standardization, research and innovation. Transparency and trust can be injected into the process when both the logic and the data driving these decisions is stored permanently and made available to all stakeholders through a peer-topeer distributed database like blockchain. The result will be a paradigm shift toward interoperability and transparency, enhancing the speed and accuracy of cost reporting to patients. This paper discusses how smart contracts, blockchain and other technologies can be combined into a platform that enables drastic improvements to the healthcare experience for all stakeholders.
DISCLAIMER: The opinions and views expressed in this report are those of the author. They do not necessarily reflect the views of Humana, or any other affiliated organization.
The Claims Process
The key financial mechanism for the healthcare system is the health plan claim. The claim process starts with the patient, who is required by law to possess medical coverage backed by a health plan. When a patient needs services from a provider (physician, hospital, pharmacy or nursing home), that provider utilizes the health plan as an intermediary to determine service fees, including member cost share and health plan cost share. In order to determine these cost shares, the health plan must first validate services received from the provider against the agreement they share, as well as any applicable regulatory requirements for that interaction.
The health plan will then communicate the results to
the patient and provider, taking into account various historical data points (deductible, out of
Figure 1. Claims Drive the Health Care System
pocket maximum, etc.) that may factor into those agreements. Even with this simplistic explanation of the claims process, one can begin to understand its complexity. As shown below, the viewpoint of each stakeholder is critical to visualizing the entire process, along with the pervasiveness of the existing issues.
The Provider Lens
Providers negotiate complex agreements (e.g. fee-for-service, pay for performance and capitation) with health plans to be considered “in-network” providers and create demand for the services they offer. The drafting and negotiation of these agreements adds significant overhead to the provider’s administration cost. One large part of this administration cost is associated to Billing and Insurance Related (BIR) activities including: “contracting with insurers and subcontracted providers; maintaining benefits databases; determining patient insurance and cost sharing; collecting copayments, formulary, and prior authorization; coding of services delivered; checking and submitting claims; receiving and depositing payments; appealing denials and underpayments; collecting from patients; negotiating end-of-year resolution of unsettled claims; and paying subcontracted providers.” (Medicine and Yong PL). BIR costs are projected to reach $315 billion dollars by 2018, up over 100% from 2007. “The complexity required to navigate these processes total up to 3.8 hours for the average American physician a week—the equivalent of more than 3 workweeks a year—on interactions with payers” (Medicine and Yong PL). As can be seen in figure 2, BIR cost is estimated to be $254 billion across all providers, adding enormous strain to the overall system. Inefficiencies born out of these activities result in painful waves felt across the entire healthcare system.
The Patient Lens
As of 2014, the Affordable Care Act (ACA) mandates that all individuals have health insurance.
|For the scope of this whitepaper, it is assumed that patients have some agreement with a health|
|plan and that they maintain essential coverage.||Patients depend on the health plan to clearly|
communicate the terms of their agreement. For a number of reasons, the specifics of that agreement are typically not well understood by the patient. “In particular, the complexity of medical billing and the third-party reimbursement processes faced by most patients and their families is a potential source of confusion or misunderstanding between patient, medical provider, and insurer. That complexity could lead some consumers to be unaware of when, to whom, or for what amount they owe a medical bill or even whether payment was the responsibility of the consumer rather than an insurance company” (DiJulio, Firth and Brodie).
Per a recent Kaiser study, one of the top healthcare priorities for the President and Congress is “making information about the price of doctors’ visits, tests, and procedures more available to patients,” with 56% of respondents voicing concern over lacking information (DiJulio, Firth and Brodie). Although the majority of patients reportedly want to discuss out-of-pocket costs during the medical visit, neither the provider nor the patient have the tools available to efficiently drive that conversation (Hunter, Zhang and Hesson). Patients are asked to shoulder the timeconsuming and error-prone process of reconciling cost information they receive from the provider and the health plan.
The patient is also a victim of the glacial speed at which claims move through the existing processes; electronic claims take an average of seven to fourteen days and paper claims range between four and eight weeks (Benton). This lack of responsiveness by the overall system contributes to a patient experience rife with mistrust, frustration and resignation. A number of factors that contribute to unpleasant patient experiences in the healthcare system, and one proven way to push resolution is by incentivizing each stakeholder to improve their contribution to the overall process.
The Health Plan/Payer Lens
The general public expects the health plan to be an effective intermediary in the claims process, and when they experience frustration resulting from the current arduous process, all eyes seemingly focus in that direction. In order to be viable and competitive, health plans have had to expend significant resources to adapt to the many recent changes in the legislative landscape. The changes driven by the Health Insurance Accountability and Portability Act (HIPAA) and ACA, for example, have resulted in additional complexity in both the patient’s insurance coverage, and within provider agreements. Meeting the requirements of these legislative developments can make it difficult for health plans to embrace and take full of advantage of new technologies that have the potential to improve the claims process issues at hand. As set out in figure 3, private insurers account for almost half of all BIR costs totaling 198 billion (Medicine and Yong PL).
Figure 3. BIR Overview
Government Regulators Lens
Due to the requirements of government-sponsored initiatives like Medicare, Medicaid and ACA, regulations must be enforced. Auditing claims data is a key part of that process. Calculating Medical Loss Ratio (MLR) is one regulation that requires health plans to “spend 80 to 85 percent of premium dollars on medical care and health care quality improvement, rather than on administrative costs” (Centers for Medicare & Medicaid Services). Collecting information to audit MLR and improper payments for subsidized programs creates substantial overhead for both providers and health plans. The health plan must produce the requested information for auditors to evaluate. Clearly, regulation is needed. The Health Care Fraud and Abuse Control Program, for example, has returned over $29.4 billion to Medicare over the past decade (Coalition Against Insurance Fraud). However, the auditing process is inefficient, exacerbated by barriers to sharing claims information with regulators in near real-time and in a centralized location.
Blockchain (with the capital B) is a term used today to reference a collection of technologies. The name comes from the distributed database (blockchain with a lowercase b) it utilizes, which implements a chain of transaction blocks or a “block chain” to store information. This chain of information is then replicated across a collection of computers connected as a peer-to-peer network. Every computer participating in the peer-to-peer network is referred to as a node. Public key cryptography allows for the nodes to interact anonymously and securely on the network. In order for a node to add a transaction to the blockchain, a consensus of the networked nodes is required to determine where the transaction should appear, and this consensus occurs when majority of the nodes agree on the next “block” of transactions to add to the chain. There are multiple ways to approach collecting consensus across the network; the most popular include proof of stake (PoS) and proof of work(PoW) algorithms to ensure the integrity of network. Because consensus is needed to add information and every node has a copy of the data, which is “chained together” over time, the integrity of the data is relational to the number of nodes in agreement (Zaninotto).
The most successful implementation of Blockchain technology to date is Bitcoin. Over the past seven years Bitcoin has validated the technology can securely support real world use cases including transferring digital assets—payment for something, in the case of Bitcoin—without an intermediary.
The solution is a platform engineered to leverage both Blockchain technologies and Fast Healthcare Interoperability Resources (FHIR) compliant APIs to increase efficiencies, enable near real-time claim adjudication, transparent agreements between stakeholders and decreased fraud. FHIR was created as an industry standard to format data thereby reducing integration complexity. A key aspect of the solution, due to the cost of adding data to the blockchain, is limiting that data to only what is needed for the smart contracts to execute. Additional details would be formatted to comply with the FHIR standards and stored as a reference URL associated to applicable transaction in the blockchain.
Considering the technical immaturity of Blockchain technologies and the fact that healthcare data is extremely sensitive, the blockchain must be limited to a consortium. A consortium will also allow for the platform to reduce risk while maturing iteratively toward the goal of securely and openly supporting all claims in a public and transparent implementation. Smart Contracts can be developed to support provider and health plan agreements, as well as agreements between patient and health plan. Once these contracts are validated, they can be standardized and reused across the industry, providing a significant decrease in overhead.
Due to Blockchain’s proven strengths in managing digital assets and the significant impacts of health care costs, improving efficiencies in BIR activities was prioritized as the first leap forward. The clinical care details associated to each claim could be stored as a reference URL on the blockchain but made available through FHIR compliant APIs. Storing a link to the clinical information in blockchain, instead of the actual clinical details minimizes the amount of data shared by the nodes while still enabling interoperability and playing to Blockchain’s proven strengths.
Smart contracts allow logic to be executed by nodes on the Blockchain. In the proposed solution, the smart contracts would need to contain the logic necessary to automate the provider and health plan agreements as well as the member and health plan agreements. Due to the complexity of some cases, multi-step and potentially long running contracts will be needed to cover all scenarios. The majority of transactions would not fall into this category, but the proposed platform would provide the capabilities to integrate multi-step contracts with health plan or provider systems. Once the contracts have been deployed to the Blockchain, they are executable, so agreements will be fully transparent to the consortium. Transparency of the agreement will equip stakeholders to have conversations informed by accurate accumulation data, the patient’s agreement with the health plan and the provider’s agreement with the health plan. The blockchain would provide the applicable patient accumulations, i.e., out of pocket cost paid by the patient categorized into groups like deductible, in or out of network and the various medication related services.
Securing this solution to share claim information between organizations in the consortium is worth the investment and risk due to potential benefits provided by Blockchain. There are two processes needed to secure the data and ensure privacy. The first is a cryptographic one-way hash process to “tokenize” the patient, provider and health plan identities. “The cryptographic one-way hash is deterministic, meaning that it produces the same output (digest) given the EXACT same inputs every time regardless of circumstance. Any slight change in the inputs results in a dramatically different output. Anyone can check your token for validity – even on a different computer at a different time – by prompting you for your inputs and validating the resulting hash against the one you established originally. If any of those inputs are not the same…the hash will not match, proving that it is not you or the object in question. These hash algorithms are carefully designed to be one way – making it impossible to determine the original inputs from the output (digest) alone. (Gray)”. An example of the patient inputs would be “Health Plan Company Identifier + Member Id + DOB + First Name + Last Name”. Tokenizing these properties would allow for patients to be uniquely identified by the health plan and provider. Using this design a patient’s token would change as the health plan information changed so one user is not tightly coupled to the same token. Loose coupling reduces the impact of a security breach because a compromised token would be limited to a specific time range. Providers and health plans could agree to the properties they each use for tokenizing during the contract negotiations but they would need to account for all the information to identify the provider (e.g. facility, organization, etc.) and health plan.
Tokenization Example for Illustrative Purposes
Figure 4.One-way Cryptographic hash
Once the identifying information has been tokenized the remaining information needed to execute the smart contract can be stored in plain text. The data stored in plain text would be the minimum amount of information needed to successfully adjudicate the claim and a URL to fetch additional details. These details would be made available by the health plan API as a FHIR resource. Sharing this information across the consortium would allow for an unprecedented level of transparency but would also create a need for a blockchain “salt” process. That is because, even with the patient’s identity being obfuscated by the token, there could theoretically be some scenarios in which privacy could not be fully guaranteed. Although these scenarios occur with little frequency, privacy can be addressed by creating fictional records (salts) along with legitimate ones. The process around adding salts would be driven by both regulators and health plans to ensure that the blockchain had enough data (real and fictional) to ensure privacy. Statistics associated with the salts over a large period of time could be provided to researchers who would then be able to look at the “unsalted” data in aggregate for research purposes. Combing the process of tokenization of identities with blockchain salting will secure the data stored at rest in the blockchain.
Solution Architecture Three stakeholder groups— provider, health plans and government—will form the consortium to enable this solution. Health plans will own the majority of the processing that will enable the providers to submit claims and provide other stakeholders, including the patient, all applicable information. Salting the blockchain will also be a responsibility of the health plan, since they will have visibility to the existing dataset as claims come in. This salting functionality should also be opened up as an API so the government can add salts, should gaps be identified in the auditing process.
Figure 5. Solution Architecture
Health plans will need to store all applicable accumulation data on the blockchain, even if the claim is delivered over an existing channel (paper, fax, existing APIs). The provider will have the ability to interface directly with the Blockchain to execute the agreed upon contracts or view applicable data. Any stakeholder should have the ability to onboard a vendor to enable innovation, research and flexibility while adhering to agreed-upon governance, open and transparent standards. These vendor or third party nodes are represented in black text and outside of the three main stakeholder circles in Figure 5.
Each enroll and dis-enroll should be posted to the blockchain via the execution of a smart contract. After executing the smart contact, a minimum set of enrollment data including consent, product identifier and coverage dates, would be available on the blockchain. This functionality would potentially replace the HIPAA Eligibility Transaction System (HETS) that facilitates this type of request for information. Making enrollment data available would allow for provider systems to validate the smart contracts associated to a patient, so a discussion on cost could occur at any time. Utilizing the blockchain as a near real-time source for patient enrollment information would allow provider systems to streamline the patient intake processes, and open up the potential for health plan integration via FHIR resources to make the process significantly less intensive than the existing paper process. Providing government regulators with this enrollment information in near real-time would allow for more precise reporting, auditing and stakeholder messaging. Depending on the attributes chosen for patient tokens, the government could potentially audit to determine who is covered, and drive focused messaging to non-covered individuals.
on Blockchain technologies. Once Figure 6. Example Flow
a claim has been successfully adjudicated, additional data could be made available as a FHIR resource via the health plan. Existing messaging processes could be leveraged to notify the patient of account balances or provide an explanation of benefits associated with the claim.
In order to support claims that are too complex to be handled in an automated Blockchain process, long running multipart smart contracts that utilize manual checkpoints will be needed. Once the claim has been processed, or is in a state that requires attention, a messaging process will ensure each participant knows both the steps needed and the tasks in the queue. These queued tasks should be monitored, and stakeholders who expedite the claims process should be incentivized so current tendencies do not hinder the future state. With soaring healthcare costs in the United States, reducing administrative costs through the strengths of Blockchain technology provides value to all stakeholders.
Smart contracts are flexible and provide the mechanism for drastic reduction of administrative overhead across the healthcare industry. Once smart contracts can allow for near real-time adjudicating of the majority of claims, overhead will decrease for all stakeholders. In addition, patient outcomes should be positively impacted as resources can be reallocated from administration to care management. As stated earlier, health plans will need to facilitate the blockchain integration for providers so that every claim is persisted to the blockchain. This will enable all claims to be available on the blockchain, even if the provider has not integrated. Having all claims data available and processed in near real-time will allow for regulation and reporting that was not previously feasible. This will also enable provider/patient agreements that result in smart contracts to manage payment schedules and withdrawals from Flexible Spending Accounts (FSAs), Health Savings Accounts (HSAs) or other guaranteed/credited accounts. Enabling this type of guaranteed funding would allow the provider to accept payment schedules or incentivize by providing discounts for upfront or guaranteed payments.
The proposed solution has two main goals: (1) enable the provider and patient to have a conversation around out of pocket cost, and (2) drastically reduce the billing- and insurancerelated administrative costs. Focusing first on the value of the interoperability efforts, as outlined in the nationwide interoperability roadmap (Office of the National Coordinator for Health Information Technology), we must prioritize decreasing the excessive administrative costs over other Blockchain concepts. The ability to remove intermediaries from a process is the capability that sets Blockchain apart from other technologies. This capability will allow the solution to facilitate real-time claims adjudication by replacing the health plan intermediation with transparent Blockchain technologies. Incorporating one-way cryptographic hashes and blockchain salts will provide the foundation to protect privacy and security across all aspects of interoperability. Even with these security measures in place, the performance of claims processing using Blockchain would still be measured in seconds, whereas now it is measured in days.
Bitcoin has proven Blockchain can be trusted to securely transfer digital assets in a completely open and transparent implementation. Targeting claims processing as the first Blockchain goal for health IT will allow the industry to mitigate risk by maximizing the parallels between these financial transaction processes. The focus of the health plans in the transactional claims process would shift from acting as an intermediary to publishing the smart contracts (agreements with the provider and patient) and applicable data (accumulations, product details, etc.) to the blockchain. Health IT interoperability takes a significant step forward when smart contracts and data are available on a consortium-accessible blockchain. Integrated solutions could maintain modularity since the blockchain would allow for shared storage, lower the barrier of entry and enable unprecedented innovation. Scalability and resiliency would also not be a concern due the architecture of the Blockchain solution, given enough nodes are participating in the consortium’s transaction processing. To incentivize transaction processing (mining), the solution would require a small transaction fee paid to the node for processing a block of transactions. This fee could be a fraction of existing fees, and still offset the overhead of processing the block of transactions.
To mitigate risk the solution must take iterative steps toward processing all claims. The proposed solution would first operate in parallel with existing Health Information Exchange (HIE) components. After validation and roll out, existing HIE components would migrate to the consortium blockchain instead of the existing fragmented data sources to maximize current investments. The cost to implement this solution is hard to estimate with confidence due to the immaturity of the technology, but estimate a cost in millions, compared to potential benefits that would be measured in billions.
In addition to BIR cost reduction, the blockchain data would create a foundation for solutions that enable both the patient and provider to have a conversation about the patient’s projected outof-pocket costs. This dialog would be based on near real-time data, so changes to accumulations or benefits would be reflected seconds after any change. If a pending change was waiting on a long running contract, those details would also be made available to inform the discussion. These conversations are crucial to ensure both patient and provider are making informed choices about care.
Benefits from the Stakeholder Viewpoint
Translating agreements between stakeholders into smart contracts replaces ambiguity with clarity, driving down administrative cost and processing time across the healthcare industry. The blockchain data and referenced FHIR complaint details will allow this proposed solution to power future innovations that equip providers to level set expectations for out of pocket costs and view clinical information associated to services previously rendered. Patients will be better informed of projected costs and experience the benefit of providers utilizing historical clinical service information. Health plans have the potential to drive down costs across the industry by shifting processes to use a more open, efficient and transparent Blockchain solution. This openness will empower the government to perform near real-time auditing and fraud prevention without the current overhead of collecting, aggregating and sharing information.
The rising cost of healthcare in the United States is an issue of critical importance to our society. Blockchain has the potential to drastically reduce these costs by enabling a platform though which a consortium would share information and execute smart contracts. This platform would drive standardization, interoperability, research and innovation, as data is made available and stakeholders become more informed. As the banking industry collaborates in R3 CEV, so too should the healthcare industry work together on developing the use of Blockchain for a more efficient claims platform. The benefits of securely sharing information and translating agreements to smart contracts are too large to be ignored. Blockchain is not a silver bullet, and the effort to change existing processes will require hard work, but the tools are now available to start that journey.
Benton, Lindy. BLOG: How Can Healthcare Providers Use Technology to Get Paid Faster? 25 2 2014. 25 7 2016 <http://www.nea-fast.com/blog-how-can-healthcare-providers-use-technology-to-get-paid-faster/>.
Centers for Medicare & Medicaid Services. Medical Loss Ratio: Getting Your Money’s Worth on Health Insurance.
22 10 2010. 25 7 2016 <https://www.cms.gov/CCIIO/Resources/Fact-Sheets-and-FAQs/medical-loss-ratio.html>.
Coalition Against Insurance Fraud. Statistics. 25 7 2016 <http://www.insurancefraud.org/statistics.htm>.
DiJulio, Bianca, Jamie Firth and Mollyann Brodie. “Kaiser Health Tracking Poll: October 2015.” 28 10 2015. Kaiser Family Foundation. 25 7 2016 <http://kff.org/health-costs/poll-finding/kaiser-health-tracking-poll-october-2015/>. Gray, Marley. “Introducing Project “Bletchley”.” 21 6 2016. GitHub. 25 7 2016 <https://github.com/Azure/azureblockchain-projects/blob/master/bletchley/bletchley-whitepaper.md>.
Hunter, Wynn, et al. “What Strategies Do Physicians and Patients Discuss to Reduce Out-of-Pocket Costs? Analysis of Cost-Saving Strategies in 1755 Outpatient Clinic Visits.” 19 1 2016. Sage Journals. 25 7 2016 <http://mdm.sagepub.com/content/early/2016/01/18/0272989X15626384.abstract>.
Medicine, Institute of Medicine (US) Roundtable on Evidence-Based and Saunders RS, Olsen LA, editors. Yong PL. “The Healthcare Imperative: Lowering Costs and Improving Outcomes: Workshop Series Summary.” 2010.
National Center for Biotechnology Information. 25 7 2016 <http://www.ncbi.nlm.nih.gov/books/NBK53942/>.
Office of the National Coordinator for Health Information Technology. “Nationwide Interoperability Roadmap.” 3 4 2015. healthit.gov. 22 7 2016 <https://www.healthit.gov/sites/default/files/nationwide-interoperability-roadmapdraft-version-1.0.pdf>.
Zaninotto, Francois. The Blockchain Explained to Web Developers, Part 1: The Theory. 28 4 2016. 22 7 2016 <http://marmelab.com/blog/2016/04/28/blockchain-for-web-developers-the-theory.html>.