A decentralized health insurance co-op could be setup with the mission of providing health coverage to its members. It would operate similar to a non-profit where the focus is on the members and not shareholders. The co-op would use a blockchain as its data structure and each user would run a node with software that would allow then to submit claims, payments and vote. A block would be created on average every 24 hours with a term period being every 30 blocks, or roughly a month.
Users could opt into different coverage types and terms. If a user opted into a longer term, they would be guaranteed that rate for each term. If they went term by term or if their contract expired they would be subject to the current rate. In addition, participants could choose what level of coverage they need. Different plans would include different copays and different procedures covered or different prescription costs.
Premium’s would be reevaluated every term and would not increase or decrease by more than 10%. In the United States most insurance companies require 8-12% held in reserves[i], this co-op would be conservative with its holds and keep 15% in the beginning.
In the United States, the Healthcare Common Procedure Coding System has codes for almost every healthcare procedure[ii]. In the beginning of the co-op the participants would decide what would be covered as a standard claim and what would be non-standard.
A patient would use their public key to sign documents from their doctor and submit them to the blockchain. If the procedure was recognized as a standard procedure it would be accepted and payout via the blockchain would happen in the next block. For most procedures submitting and paying a claim would be easy. In some cases, where a user submits multiple claims, or fails to pay a payout, or is suspected of fraud, users on the network could audit the documents.
Non-standard claims would require a consensus from active participants to be paid. When a non-standard claim is submitted to the blockchain, users on the chain would have 60 blocks to accept or deny the claim. The claim would be submitted with relevant documents signed by that user’s private key. A user would need 50% consensus from the voting users over a 15 block period for a non-standard claim to be paid. Voting would be by the users who want to participate in the voting process. A user could setup their node to automatically accept certain non-standard claims so they don’t have to be as active in the voting process. Other users may wish to review every claim and be active in the system.
To prevent users from denying everything to have lower premiums, a user would need a higher consensus to be paid non-standard claims if they have denied over 65% of claims. Anyone with a 95% or higher deny rate over the course of 12 terms would be asked to leave the program once their term is up as this does behavior not align with the mission of the co-op. This would all handled by smart contracts on the blockchain.
| User’s Voting Record | User’s Threshold for Non-Standard Claim Payout |
|---|---|
| 0-64% deny | 50% |
| 65% | 75% |
| 70% | 80% |
| 75% | 85% |
| 80% | 90% |
| 85% -94% | 95% |
| 95%-100% | 100% and not allowed to renew |
To incentivize users, the threshold for non-standard payout could decline for the number of years they are in the program. For every year they are in the program, 1% would be deducted from the payout threshold, after voting, up to 10%.
If a non-standard claim were paid out over 75% of the time over the course of 12 terms, it would be converted to a standard claim in the next term. To downgrade items from standard to non-standard majority consensus would be needed via the voting mechanism in the software.
The co-op needs to make sure that someone couldn’t reverse engineer a payment to identify a patient or their condition/illness. A payout claim would be paid via bitcoin to a patient via multiple outputs. The core software could keep a bitcoin wallet and would create multiple addresses for a single payment. The payment would be divided between multiple addresses to help keep anonymity to the patient.
The next step is to use the public MLR Rebate data[iii] to determine premiums, coverage and minimum number of participants needed. If this idea was economically viable a non-profit could be setup to start recruiting members and build the software. Once enough participants are recruited, a year test should be conducted to see if this plan works for the individuals that are covered.