What follows is a real story. I have changed the names and some of the particulars involved for the sake of the companies and people mentioned below.
What I remember the most was the goosebumps.
Even I, a decades-long veteran in the health IT landscape, had no frickin’ idea what the right answer was. And worse, my users and customers didn’t either.
We were four months into building out Cerberus, our codename for the integration service at The Venture-Backed Startup (all our services were Greek-mythology themed). We’d already solved the gordian knots of field mapping, secure connectivity, and just how exactly we were going to build one service to speak to multiple system endpoints. But we’ll get to those Odysseys later.
The decision on the table right now was a temporal one: our platform allowed for secure communication between patients and their care team, within the context of the patients’ care plan. But these comms needed to be stored in a single “source of truth” system.
While we would have loved for it to be us, we weren’t naïve; we knew we had to get these messages into a system of record. So we built a mechanism for care team members to send sets of messages “across the wire” from our system into the source of truth.
But a dilemma emerged: what if the time the user sent the message over was different from the time the message was exchanged? At what “time” should the system of truth perceive the message as having taken place?
There was a lot riding on this decision.
These clients would get audited and explain and justify the choice I made. How could something as banal and routine as a timestamp be causing this much stress?
I did what any good product manager would do in this instance. I went and talked to my customers.
And as good customers are wont to do, their answers ranged from “all over the map” to “we’re not sure. What do you think it should be?”
Push came to shove.
I clung to the classic product management trope of making what I thought was the best decision I could with the data I had in hand at the time we had to choose.
No one likes to go to their CTO, tail between their legs, and confess to having misread the market—and as a result, be the bearer of a lot of crunch for the engineering group.
But it’s especially brutal when, from your days as a developer, you’ve got your own Kratos-sized scars from all the crunch you had to endure because of others’ misreads of the market.
Sure, take-out Pad Thai tastes good, but you know what’s better? Not working the weekend. And not being the reason others have to.
The experience I’ve shared here is just one example of the pitfalls of building out an integration capability for a digital health solution. It’s why we created Rhapsody health solutions, and why we’re building Envoy.
Data integration in digital health has a functionally endless supply of stories like this one, and we believe that by combining the heartiest and most experienced tools and people in healthcare interoperability, we can save intrepid product managers, who are just trying to solve a tough problem, from having their livers eaten.
Download our free guide Slay the interoperability dragons that block your go-live. It’s a handy guide for building healthcare connections that won’t leave you burnt out.
