Encryption & Validation Protection
Capabilities of a Medical Billing Portal & Security
From an architectural perspective, it's difficult to go back and add key functionality that should be part of the core medical billing portal. In other words, if a capability is not already there when the portal is built, it's probably going to be quite challenging to incorporate at a later time.
Key functionalities for HIPAA compliance include the ability to:
- Log and track every single transaction
- Restrict access to certain data by role
- Immediately remove access to data based on removing a role
- Delete any sensitive user data or PHI upon a patient’s request
- Maintain the functionality of the system when the above actions are performed
Additionally, it's necessary to look at the hosting and infrastructure itself to make sure that all of the data is stored in an encrypted fashion at rest. The physical application files are to be saved on an encrypted storage device. In case any of the resources are penetrated or made available through some form of security breach, their independent encryption will preserve data safety.
There are multiple layers of encryption and security to prevent Inadvertent access to patient information. Medical billing portals are typically configured with relatively lightweight information to be able to access the account. Usually this is getting to be a full name, a date of birth, and some form of case number. The above information may vary among medical billing portals, depending on what makes the most sense for the business and the desired customer experience.
However, there are a few standard fields that patients would need to fill in whenever they visit the medical billing portal; that information can be associated with an account for easier access. Upon association, patients will be able to sign up for a user account with a unique username and password. But the usual way of user interaction with the system is by providing certain fields that tie back to a non-PHI key.
This key can be used to look up the PHI data that's in a secure HIPAA API (Application Programming Interface). Essentially, we only deal with a key value whenever we're going through this application. What that key value provides is a patient identifier, which is linked to this particular patient, and can be used to access data that's securely stored in the HIPAA system.
To sum up, whenever that call is going across the wire to the HIPAA compliant system, it's vital to be encrypted and incorporate proper IP blocking restrictions. This ensures that only the IP address of the web application can reach into the HIPAA API server environment, which in turn needs to demand the presence of a valid private key.
We're identifying the patient by a unique identifier while sending a private key that only the web application secretly has stored within it so that it's encrypted. We’re also blocking all IPs from accessing the API endpoint, with exception of the web server itself that's hosting the web application for the medical billing portal. Ultimately, the infrastructure that's used on the HIPAA API needs to be virtually impenetrable because that's what's going to house the actual sensitive data.
By extension, there needs to be an exclusive whitelist or unique hole in that security, reserved for the web application only. Multiple layers intertwine to secure the system:
- A unique patient key
- A private key for the application
- A whitelisted IP address
- Some form of authentication whenever we're making a call to that API endpoint
This combination of layered security features makes it gravely challenging for anyone to penetrate or otherwise breach the integrity of the HIPAA API endpoints. Our site features a number of in-depth articles and detailed content on automated penetration testing tools that we recommend.