Calling all tech leaders – especially those who work in specialty pharma:
Amidst a polarized world of dissension and strife, there’s one belief that unites us all…
Tech integrations are a nightmare.
Can I hear a “hallelujah!?”
You can skip this article if your business orbits in a fantasyland as homogenous as The Truman Show. Or if you work with fellow tech wizards who adore change and warmly embrace new technologies.
As for the rest of us, we exist on a different planet, where business colleagues are often technophobe dinosaurs and change is usually avoided like a salad bar during Covid. How do you manage integrations to new systems and processes amidst the professional equivalent of Jurassic Park?
It just so happens that I know a thing or a thousand about this quandary. And I have the scars on my back to show for it.
I work with HelpAround, a company that simplifies the lives of patients for specialty medications by providing the full package of relevant solutions for their needs. To do this, we need to connect to a variety of actors in the healthcare industry.
In this industry, the actors not only play different roles – their parts are highly regulated. In other words, even if a healthcare actor actually wants to be more tech-oriented, the status quo is stacked heavily against them. As such, you rarely, if ever, find two partners with similar APIs.
Horrors! What to do? Well, Toto, follow me through our journey along the yellow brick road to integration salvation.
In the early days, we at Helparound thought: “Integrations? No prob! We’ll provide our own set of generic APIs to any partner that wants to easily use our services.” Genius, right? We would set the standards of our own in an industry that is technophobic.
Ummmmmmm….not so fast. That “brilliant” move turned out to be a great marketing feature…and nothing else.
Healthcare partners are frequently not tech savvy (I say this with all the respect in the world! We can’t do what they do!) And being set in your tech ways isn’t an ideal quality to foster digital evolution. If the best we can hope for from partners are faxes, forms that require filling out with real pens, manual scans, and right clicking to compress a folder and attaching it to an email….well, we’re not defining progress the same way.
Pardon my eyeroll, but this is all very 2005.
For those partners who want to be tech retro, great! Maybe that works splendidly for you. The “a-ha” that we experienced on our way to Oz is that every partner’s approach to technology and managing their business is unique, and given all of these differences, integration can be a serious challenge. To say the least.
But integration is a crucial step in simplifying the journey for your patients. So how do you adapt?
First, your architecture must be designed to handle the challenges of integration. Alas, this is far easier said than done. You need creativity, resourcefulness, flexibility, a strong jug of espresso, and probably some light therapy to manage this process.
Ready? Here are 5 helpful tips to guide you through the integration wilderness:
1) Spend time on preparing API documentation as a showcase. Lead by example: when you send this link to a vendor during the discovery phase, it will be clear to everyone that this is the standard you expect. This includes documenting major milestones so the timing of developers on both sides are coordinated, with ample room left for testing.
2) Configurations, configurations, configurations. When you talk about developing in an evergreen, generic way, the first thing that comes to mind is to take everything you can to a configuration file. This idea holds its own problems in maintenance, but it’s a straightforward approach to avoid “special deliveries” in versions for every partner’s demand. The solution includes the usage of feature flags because it simply gives you more control.
3) Don’t be afraid of hard-coded features. Yes, we all know that hard coding seems like a bad thing. But you know what? Sometimes you might find yourself trying so strenuously to be generic that it feels like overkill. What if the requested feature is SO specific that the chances of having a similar use case with another partner are remote to never?
Look, hard coding is not popular advice; but it’s very practical. Don’t be afraid to take this step…. (just go easy and don’t make it a habit)
Wait a second; hold the phone. Aren’t I recommending two contrary things here? On one hand it’s all about generic implementation and exporting everything to a configuration file…But on the other hand, it’s ok to hard code requirement specifications? What gives?!
Relax: yes, this all may seem contradictory, but we need to keep in mind that R&D doesn’t live in a vacuum. We need to move fast in order to scale and help as many patients as possible. I’d recommend that in cases where you have to create this technical debt, make sure to close it in parallel. In other words, develop and improve the second version of your app at the same time. Not tomorrow, not in the next sprint, and not the next time someone would like this feature. In parallel.
Back to the list…
4) Spend time on integration tests – as many sessions as possible. The big BUT is to make it useful and not spend too much time on exhaustive tests. Pre-define the test cases in advance (exactly 2 tests per API: a “happy day, let’s dance” scenario and a failed one.) The rest of the tests can be executed separately.
5) Define the KPIs of this integration with the vendor. You’d be surprised to learn that not everyone is actually familiar with the purpose of KPIs. You have to make sure these are described empirically and measurably. By doing so, both sides know what to focus on during implementation and are aware of their liabilities in this project.
And there you have it – your Cliff’s Notes survival guide to integrations!
Remember: integrations are an unavoidable reality of the digital specialization that we face today, where everyone has their own system and app and somehow they all have to play together nicely. In the specialty pharma world, we need to do whatever we can to simplify the onboarding experience for patients, and that means integration.
So good luck, and let’s keep working to make the digi-verse saner for patients (and for the rest of us while we’re at it.)