You know your technology can make a big impact in healthcare, but there is just one problem: those who would benefit from your technology don’t want it unless it’s integrated into their daily workflow. Your engineers can make these EHR and CRM connections, but their time could be better spent making your product better. What now?
To choose the right interoperability solution, healthcare tech companies, also known as digital health vendors, must first create a plan of action for evaluating interoperability solutions. As the old adage says, “A goal without a plan is just a wish” — and wishing alone certainly never helped any business scale. Make your goals to grow your healthcare tech business a reality with these with three tips for vetting interoperability solutions.
The first step in vetting interoperability solutions is to evaluate project goals and prioritize needs. These goals and priorities should serve as the guiding forces behind your integration project. Of course, goals and priorities should be set relative to the three key parties in healthcare tech: the patient, the provider, and of course, the healthcare tech company itself. At the bare minimum, what do each of these parties need the integration project to accomplish? What would be nice to have? Let’s take a look.
Healthcare Tech Company Data Integration Needs: Naturally, healthcare tech companies must consider internal business needs when choosing between interoperability solutions. Start by taking a look at current workflows — what is the ideal way patient data could move between the device, the provider, and the patient?
Given the complexity of healthcare integrations, many digital health vendors are accustomed to the words “no” and “but,” forcing them to find workarounds or time-consuming solutions for getting data where it needs to go. The interoperability solution selection process is a prime time to question data workflow efficiency. Is there a more direct way to get actionable patient data where it needs to be … without those pesky two words? Oftentimes, the answer is yes.
Provider Data Integration Needs: The most effective product development plans — integration projects included — address the needs and pain points of the customer (the provider) and the end-user (the patient). So, what do providers look for when it comes to integrations?
When shopping digital health solutions, providers look at three key factors: cost, return, and convenience. Providers want to know how much it will cost to purchase the technology, how much the technology will save them, the ease of implementation, and the convenience of streamlined data. Moreover, providers want technology that doesn’t just improve patient care, but also keeps the administrative burden to a minimum.
Patient Data Integration Needs: Patients want convenient care and fully-informed treatment plans. When selecting an integration partner, consider the partner’s ability to give patients the streamlined, hassle-free care experience they deserve — an experience informed by accurate, up-to-date medical records and not limited by disconnected data.
Patients also want to know that physicians are handling their information securely and confidentially — that only authorized personnel are privy to private medical records. In order to address this specific patient need, make sure each vendor you’re considering has checked all of the boxes to meet the latest encryption, security, and compliance standards.
When vetting interoperability solutions, asking about data formats may seem complicated, but a good integration partner should have an expert team to lead you through the information you need to know. Ensuring that an integration partner will be able to connect with any of your customers, regardless of the data formats or vendors they use, will save time, energy, and money in the long haul.
Some healthcare integration companies require clients to conform to a particular data standard in order to make the integration functional. What does this mean for the clients? It means that the client must expend significant effort getting data up-to-par with the integration company’s prescribed data standard before ever starting to build the integration itself.
Consider having to translate patient records from English to Spanish — a tedious task that requires high-level command over both English and Spanish. Similar to this English-to-Spanish translation process, aligning with a particular data standard requires vendors to become “translators” before the integration project ever takes off.
Now, imagine your digital health device connects with three different EHRs, and each EHR has a different data standard — API, HL7, FHIR, SOAP XML, or REST JSON just to name a few. In order to meet the workflow needs of customers, the tech vendor must have engineers that understand all three EHR data standards and use their time to build those integrations.
Circling back to our language comparison, a project of this sort would be like translating patient records written in English, French, and German into Spanish. Combined with strict privacy laws such as HIPAA, these sorts of “interoperability solutions” create more work for the tech vendor in addition to the up-front cost discussed in the sales cycle.
As with most large purchase decisions, when choosing an integration partner, you must thoroughly understand pricing models, maintenance options, time-to-value, and the amount of time it will take to see a return on investment. If you have a great engineering team, you’ve probably asked yourself the question, “Should we buy it, or should we build it?” Let’s dive into what those two options look like when it comes to integrations.
Buy vs. Build
When it comes to healthcare integrations, digital health vendors can take one of two routes: buy or build.
Of course, building an integration in-house affects cost. When building an integration internally, healthcare tech vendors must consider the cost of human capital — how much does it cost to employ a team of highly-skilled developers? To answer quickly: a lot.
Not to mention the fact that integrations take a tremendous amount of time, energy, and labor to build and maintain, leaving little room for these developers to focus on much else. For digital health companies, divided attention means less attention to the digital health solution itself, giving the company less bandwidth to grow to its full potential. Put simply, an in-house integration approach makes it difficult for healthcare tech companies to successfully improve their product and scale their business.
Next, we’ll take a look at the “buy” option. When it comes to buying or outsourcing an interoperability solution, cost becomes a little trickier to decipher, as many healthcare integration companies and consultancies use different pricing models — cost-per-project pricing and subscription-based pricing are the most common. While both pricing models are certainly acceptable cost structures, digital health vendors should understand the implications of each model.
As the name suggests, per-project pricing is set based on the scope of each project — no more, no less. For digital health vendors who know exactly what they want, don’t require a large amount of assistance managing the integration, and have a flexible budget that allows for separate implementation and maintenance fees as needed, this cost structure may be the right fit.
However, for those looking to have a little wiggle room without getting nickel-and-dimed, subscription-based pricing may be the best bet. Why? With subscription-based pricing, digital health vendors are charged on an all-inclusive and predictable fee on a recurring basis. Once the integration has been built out, digital health vendors can opt to renew the contract, pause the contract, or discontinue the contract as needed.
Maintenance & Service Offerings
It’s easy to get tunnel vision when it comes to integration as a deliverable, but don’t forget to consider what should be one of the biggest differentiators among integration platform as a service vendors — the service. Be sure to ask which services are included in your chosen integration partner’s pricing structure, as a curveball here could derail any team from reaching its goals to achieve interoperability.
For instance, some pricing models do not factor maintenance and upkeep into the integration project, which leaves two options when something breaks: fix it internally, or pay more to get it fixed. With staff operating at full-throttle already, that extra time to maintain an integration is often out of reach, forcing digital health vendors to continuously pay add-on fees for services presumed to be part of the original contract.
Not to mention the fact that many digital health vendors run multiple connectors to accommodate the needs of different clients — each connector typically requiring an update about once every quarter. With even a small portfolio of integrations, maintaining this cadence of updates calls for a massive amount of billable hours and could get in the way of business growth.
At the end of the day, the interoperability vetting process serves one core purpose: to empower digital health vendors to make fully-informed purchase decisions. These decisions, then, allow digital health vendors to stay clear of roadblocks so that when the rubber meets the road, nothing stands in the way of reaching business development goals.