Integration Options for Medical Billing

Medical billing portals can be connected to one or many EMR or EHR systems in order to provide a synchronization with various types of information. Those include account information, appointments, billing information, and other relevant content from a patient and care provider perspective. One of the major benefits of a medical billing portal is that it's capable of being dynamic and pull in content from multiple different sources. Specifically, the portal can draw from already existing systems that are either populating billing information or recording appointments and care that's provided in general.

One of the challenges with a medical billing portal is actually getting secure information into the system. That data isn’t just highly sensitive in nature but may also be constantly changing, growing and adjusting, based on what's occurring in the real world. The medical billing portal itself is a very capable platform from a customer experience and satisfaction perspective, but it's only able to go as far as data allows.

In other words, if the information itself is not available and someone has to manually enter data, either on a record by record or in a mass import basis, then it can be really challenging for the end user to get the kind of support and service they actually need. This is where integration to an EHR, EMR, or other line of business application becomes eminently helpful.

The general concept is that it's possible to use a version of FHIR, as well as HL7 v2, HL7 v3, or other data formats like SOAP, REST and EDI. Effectively, the idea is that whenever an occurring event might be associated with some form of billing, the medical billing portal can import that data into its system securely. There are plenty of ways to set up scheduled jobs or tasks that run and pull that data from an EMR, EHR system or other line of business application.

Security Considerations for Data Exchange

To securely take advantage of integration capabilities with a medical billing portal, a few key pieces must be in place. To begin with, most of the information in the EMR, EHR or other line of business application is highly sensitive. Then an application will be doing the connections, actually tying the data together, pushing it and pulling it between the systems. Therefore, it's usually best practice to set up the system so that it's sitting behind a firewall and remains secure.

This can be a traditional physical firewall that's inside of a physical network, but another option would be to have it inside of a cloud firewall in a cloud network, or some other form of firewall that’s separating the connector itself from external access. The firewall may be virtualized or physical, but the concept is that the connector application itself uses several key tenants to ensure the data is as encrypted and secure as possible.

The connector application would need to run all of its communication over SSL and ensure that IP addresses are blocked and only the whitelisted IPs can get through. Typically the EMR or EHR system and the medical billing portal application host have static IPs, so it's applicable to block all other IPs other than those few whitelisted ones. These measures would allow the connector to safely communicate with the medical billing portal and the EMR, EHR or line of business application.

As mentioned above, it's critical that all systems communicate exclusively over SSL, including the application for the medical billing portal, and the EMR, EHR or line of business application. The data points must use some form of authentication to verify the user before granting access to those APIs.

Furthermore, it's also important for the data to be recorded from a logging perspective. The log features information like what user is accessing which data and when, or what changes were made, to what and by whom. This is a crucial concept from a HIPAA compliance perspective and the connector needs to abide by the requirements.

Another thing to consider relates to the connector and how it shouldn’t save anything but simply pass data across the wire. The idea is that we want to queue data up for transfer but not store it anywhere. A typical way to achieve this is to always cue tasks but never queue actual data. Then, once the tasks are successfully completed, they are marked accordingly in the system.

It’s obvious that the connector is a non-intelligent interface, or -more specifically- a non-PHI knowledgeable interface. The connector’s literal function revolves around:

• Encrypting data from an endpoint
• Pushing data over the wire
• Decrypting data
• Sending data into an application
• Not storing data anywhere

Another key component for the connector is that all of the infrastructure and sensitive information that it contains, from a connectivity perspective, needs to be encrypted. Whenever data is sitting on the hard drive where it's stored, it needs to be encrypted because it contains sensitive connections and application keys.

Ideally, the physical infrastructure that data is on needs to be significantly locked down so that it can’t be easily penetrated. In the unfortunate event of a successful penetration or security breach, the multiple layers of physical encryption -as applied to the sensitive API information- will safeguard the integrity of the system.

• Medical Billing Portal Overview
• Medical Billing HIPAA Compliance & Regulations
• Meet PHI Data Regulations with Data Tokenization
• HIPAA-Compliant Billing Software
• Portal Security and Penetration Testing Best Practices
• HIPAA-Compliant Database Software
• Sensitive Information Access Levels & Protection
• Administrative Security Measures Best Practices
• HIPAA-Compliant Web Hosting
• EMR Integration Solutions
• Secure Email Communication and Data Privacy
• Including Patient Insurance Providers and Physicians
• Integration Options for Medical Billing Portals