In most cases, B2B data transfer solutions are bloated, insecure, and lacking in prompt feedback. This is especially true in the insurance industry. At Beam®, we have concentrated on solving these issues to the benefit of both our partners and our members.
In the healthcare world, a primary example of the existing B2B data transfer landscape is the enrollment and maintenance file format version 5010. Because businesses love arbitrary numbers and acronyms, this is typically called an 834 file.
What is an 834?
This file communicates health insurance enrollment between companies and government entities, as dictated by HIPAA, and further expanded upon in the ACA.
Got it. What’s wrong with an 834?
While Beam® does use 834s to communicate enrollment data in many situations, we also recognize that there are better ways to handle this data. Back in the early-to-mid 2000’s when the internet got really excited about web services and more generally service oriented architecture, in many cases, B2B communications got left behind. This happened for mostly obvious enterprise-driven reasons. In a standard EDI situation, you’re probably communicating data over a protocol like SFTP and using some type of fixed-width file format, or perhaps CSV if you’re lucky. If you’re not lucky, it could even be PDFs, which need to be parsed using OCR or manually (eek!).
Ok, but what would be better?
While those formats and transfer protocols are functional, at Beam® we’d like to move enrollment data transfers into the 21st century. Our interpretation of this involves using a transactional HTTPS-based API using JSON as the data structure. By choosing these standards, we can gain a number of advantages over the typical SFTP based 834 transfer:
- Expressiveness – I’ll explain this one by example. The below comparison shows a JSON data body on the left, with the same data conveyed on the right in a flavor of the 834 standard. If you’re an 834 expert, perhaps you can read both equally quickly, which is great for the twelve of you. For everybody else, including non-software folks, I bet you can tell what’s going on in the left side pretty quickly. Right side? Not so much.
- Faster, more granular feedback – Not only can you read the contents of the body on the left above without documentation open in a second window, but you can communicate errors more easily. We build our API’s to be atomic and idempotent, so if there’s a problem with anything you sent, we can halt the whole transaction and tell our exchange partner what went wrong. This, through a proxy, means better feedback to the user signing up for insurance, in the case of a problem. Instant enrollment, instant feedback on issues!
- Security - Compared to SFTP, which can mean exposing a Unix box to some portion of the internet, we can operate on the application layer, which can limit our areas of concern security-wise. We can use internet standards like TLS 1.2 for transfers, and AES 256 for more granular security on sensitive PHI.
- Ease of use – Not a lot of developers are readily familiar with the HIPAA / health care domain. However, a huge amount of them are familiar with web service standards, JSON, and how to scale a RESTful API. By using protocols and techniques that are familiar to the experts, we can democratize the process, bringing in speed and affordability.
If the ACA was put in place to bring access and affordability to healthcare, let’s expand on that. At Beam®, we believe we can do better, using already established internet standards, while still preserving the security of the patients that we serve.