Integrations enable data exchange between two separate systems. For WeInfuse, integrations are a tool that allows us to pass patient and billing information instantaneously between our software and client EHRs in a way that eliminates the need for manual data entry and reduces human error.
In this post, we’ll explore the scope of our current WeInfuse integrations and what you can expect for your office when integrating with WeInfuse.
Live Integrations
At the time that this blog post was written, WeInfuse was live integrations with AdvancedMD, Kareo, R2, NextGen Office, Centricity, CareCloud, and eClinicalWorks and we have many more in development. Of these existing live integrations, about half are HL7 connections and the rest are API connections.
Definitions
The technology world and the world of integrations specifically can be a bit confusing so we will do our best to simplify and explain these concepts as we go along. Before diving too far into our current integrations, it may be helpful to go over a couple of key terms and concepts below.
Scope of Integrations
The term “scope” is used in the industry as a way to define where the integration starts and stops between two systems. You might also think of scope as “the plan” for the integration. Scope describes which application will be doing what, when, and how. Right now, WeInfuse is set up to accommodate two main scopes of integration to account for the different workflows seen at standalone infusion centers versus larger practice groups and larger health systems.
Scope: Stand Alone Infusion Center
For clients using WeInfuse as their primary workflow solution, WeInfuse is the system of record for patient demographics and insurance information. Because WeInfuse acts as their EHR, these clients only need the Practice Management (PM) portion or billing portion of another platform to act as, what we call, their Revenue Cycle Management (RCM) system. In these cases, data is exchanged bi-directionally between WeInfuse and the infusion center’s RCM system. When a new patient is referred to the infusion center, their profile can be created in either WeInfuse or the RCM system, and demographic and insurance information will be sent, almost instantaneously, to the other platform. After treatment is completed in WeInfuse, users send a financial message from WeInfuse to their RCM system, where they will review and submit the claim that WeInfuse has created. This is the live setup we have for most of our clients using AdvancedMD, Kareo, NextGen Office, and R2 today.
Scope: Provider “Office-based”
For provider offices across all specialties, we have what we call our “EHR scope” of integration. For practices with a large patient population, where only a subset of those patients are infusion patients, there is no need to have the full practice patient list in WeInfuse. Instead, users import patients into WeInfuse from their EHR. Depending on the integration, by searching for either a patient’s name or MRN, clients can control which patients are pulled into WeInfuse. In this scope, the practice EHR serves as the system of record or “source of truth” for patient demographic and insurance information. Updates to demographics and insurance are blocked in WeInfuse and in most cases, each time an update is made to a patient’s profile in your EHR, WeInfuse automatically accepts that update. In this scope, WeInfuse can also send billing messages from WeInfuse to the EHR. Our integrations that fit this model currently include Centricity, CareCloud, and eClinicalWorks. In some cases, depending on an EHR’s capabilities, WeInfuse can accept integration messages for infusion patients only, ignoring messages for other non-infusion patients in your EHR, without setting up a Patient Search.
Connection Types
In order for WeInfuse to integrate with another EHR system, we need to be speaking on the same channel and in the same language. In terms of channels that we communicate over, we need to establish either a VPN and/or User Authorization setup, which we will discuss further below. For the language, we use either API or HL7 to communicate from one app to the other. We call these “Connection Types.”
VPN
VPN stands for “Virtual Private Network.” Think of a VPN as connecting a virtual cable between WeInfuse and your EHR application. Sometimes commonly referred to as a VPN Tunnel, this connectivity is a way of securely connecting two applications across the internet so information can be sent and received safely and efficiently. VPNs are most commonly needed to establish HL7 connections.
For API integrations, connections happen more like the way you log in to any web application on the internet. Each time an API message is sent, the message itself is authorized to be delivered to the receiving application. For API connection types, there typically is no need for a VPN setup.
API
API stands for Application Programming Interface. APIs are a newer, more modern connection and tend to be more accessible. Some EHRs have fairly open APIs that lay out the data that can be sent into or received from their system. Setting up an integration via API does not typically require a VPN and generally setting these integrations up requires little to no involvement from the EHR vendor side. API connections are also typically more economical in terms of per month per connection pricing.
HL7: or Health Level 7, is an international integration standard. It’s not necessary for our clients to understand the particular details of HL7 as an organization or what this standard entails. For our purposes, it is important to note that HL7 is a legacy standard for integrations and HL7 connections are more common with older EHRs where the data may be hosted on-premise. For most HL7 integrations we need to set up a VPN connection. The cost for an HL7 integration is typically higher than the API connection as HL7 requires more development resources to establish and maintain.
Interfaces
The term “interface” is mostly used when discussing HL7 type connections, but the industry commonly borrows the term when discussing other connection types as well. HL7 integrations generally require interfaces that need to be purchased individually. Think of interfaces as the different parts of the integration that allow for specific kinds of data to be exchanged. For example, you might need one interface to exchange patient demographic and insurance information and a separate interface to send charges into your EHR. For WeInfuse connections, the most common HL7 interfaces you will hear about are ADT and DFT interfaces.
ADT (Admissions, Discharge, and Transfer) or Patient Admin: These are the messages that help WeInfuse exchange patient demographic information like name, phone number, and address as well as insurance information and MRN (Patient ID) information.
DFT (Detailed Financial Transaction) or Financial Messages: These are the messages that allow WeInfuse to send Procedure and Medication Billing codes into your EHR after a patient treatment has been completed.
SIU (Scheduling Information Unsolicited) or Scheduling: This kind of feed allows WeInfuse to pass information about scheduled appointments into your EHR, including information about the date and time of a scheduled appointment and the duration of that appointment. Subsequent updates about Rescheduled or Cancelled appointments can also be passed back into your EHR.
MDM or Media: This interface allows us to pass completed treatment information, typically documents in PDF form, from WeInfuse to a client EHR. As an alternative to an HL7 MDM interface, Direct Messaging may also be available as a way to allow users to get clinical treatment information from WeInfuse to their EHR. In order to keep client integration costs down, we are exploring the possibility of offering Direct Messaging, as most EHRs include Direct Messaging services for free or at a reduced cost.
Redox Engine
We couldn’t talk about WeInfuse integrations without mentioning our integration partners at Redox. With one connection to their platform, Redox helps us set up integrations with a number of client EHRs. By conforming to the specifications of client EHRs and translating the information we send them into a format that allows for both HL7 and API connections, Redox greatly reduces the technological barriers to integration. With Redox, we don’t need an API or dedicated WeInfuse developers whose sole role is to set up integrations. Instead, Redox helps us set up and manage integration connections once they are live, ensuring that our own developers can focus on new features and app improvements for our current clients.
WeInfuse Integration Setup
Now that you have a basic understanding of the terms and concepts for WeInfuse Integrations, we will discuss what to expect if your provider group or stand-alone infusion center decides to integrate with WeInfuse. Below is a brief outline of integration setup steps:
- Contact WeInfuse
Let us know what EHR you use, your desired scope of integration (ADT, DFT, SIU, and/or MDM), and your integration timeline. If you haven’t already, reach out to your EHR vendor to confirm integration scope and pricing with them and check in about whether they will be assigning any integration resources to the project.
- Kickoff Call
WeInfuse will help organize a kickoff call with Redox and any relevant contacts from your EHR’s team. During the kickoff call we will confirm the integration connection type, review the proposed scope of integration, and confirm that it is technically possible. We will also discuss VPN set up and exchange VPN specs (if applicable) and review which interfaces will need to be set up.
- Setup & Testing
After the kickoff call, Redox and your EHR vendor will work on getting the necessary interfaces set up. Once the preliminary setup is complete, we can work on exchanging test messages to confirm that messages are formatted in a way that can be internalized by the receiving system. Redox can make changes to message formatting to confirm that messages conform to your EHR’s specifications.
If a testing environment is available, we will conduct testing in our Staging environment. Otherwise, testing will be done in Production.
- Data cleanup
If you are a new WeInfuse client and there is no existing insurance or patient data in your WeInfuse instance, there will not be any data cleanup involved in the integration setup process.
For existing WeInfuse clients, we need to ensure that existing payer and patient data is aligned. For instance, if patient A exists in WeInfuse and also in your EHR, we want to make sure that the integration knows that the profiles in these two systems represent the same patient. We link patient profiles based on their unique WeInfuse ID and their unique ID, chart number, or MRN/Patient ID from your EHR. Marking a patient linked means that if an update is made to that patient’s profile in your EHR, we know to make that same update to demographics or insurance information on that patient’s profile in WeInfuse.
For insurance, the data cleanup process is similar. We need to know that if an insurance plan exists in WeInfuse, there is a corresponding plan that exists in your EHR. Insurance linking is done based on an insurance plan’s unique ID in WeInfuse and the unique ID of its corresponding plan in your EHR. For any insurance plan that gets sent to WeInfuse once the integration is live, if its plan ID does not match that of a linked policy in WeInfuse, we know to create that new plan in your Payers list in WeInfuse so that it can be assigned as an insurance plan at the individual patient level going forward.
- Go-Live
Once setup, testing, and data cleanup are complete, our development team will complete any linking of payer and patient data that needs to take place and will turn the integration on for you. Once you are live, you can always reach out to support@weinfuse.com with any questions.
Closing
Based on your specific integration needs, we can work with you to define the right scope of integration and discuss what the setup process will look like in more detail. If you are interested in an integration or have any specific questions, feel free to reach us at support@weinfuse.com.
