Not long ago, we lost a deal. Or we thought we did.
A multi-location urgent care group had built its own clinical platform and needed to add e-prescribing. Its team began evaluating integration partners, looking for a way to bring prescribing into the software its providers already used.
We had good conversations. Then they chose another vendor.
One feature helped that vendor stand out: an open sandbox API. Sign up, grab a key, start building.
For a product team ready to move, the appeal was easy to understand. Developers could get into the environment, explore the API and start testing without waiting for a commercial agreement or an implementation kickoff.
Then the group went quiet.
Six weeks later, they called us back.
Six weeks into the build
The team described an experience that had fallen short of its expectations. According to the group, developers had encountered outages and downtime during the build. They also raised concerns about the product’s maturity and the support available to help them move forward.
They had started with access to an API. Six weeks later, they were back to evaluating an integration partner.
The sandbox had made it easy to begin. What followed had made them reconsider the choice.
That was the point at which our conversation resumed. Their experience brought a different set of questions to the discussion: How dependable was the environment? Who would help when something failed? What would it take to get providers prescribing inside their platform?
The appeal of getting started
An open sandbox gives developers something useful: a chance to explore how an API works before making a larger commitment. Teams can review the structure, test sample requests and begin assessing how an integration might fit their product.
We understand why that matters. Product teams have roadmaps to deliver, and engineers want enough access to make informed decisions.
But a sandbox answers only some of the questions involved in choosing an e-prescribing partner. Teams also need to understand the workflows, dependencies and support required to take that integration into production.
Can providers complete the prescribing tasks the platform needs to support? What happens when a prescription cannot be routed? How are identity verification and controlled substance prescribing handled? Who helps resolve an issue during implementation, and who supports providers after launch?
Those questions deserve attention while teams are evaluating the API, before the build gathers momentum.
What has to work beyond the API
Prescribing connects a platform to providers, pharmacies and the workflows that move a medication order between them.
A successful demonstration is an early milestone. The integration also needs to support the less convenient moments: an incomplete setup, an unexpected response, a failed transaction or a provider who needs help completing a task.
For the urgent care group, reliability and implementation support became immediate concerns. For another platform, the deciding factor might be the scope of prescribing workflows, the division of implementation responsibilities or the work required before launch.
This is where a partner’s experience becomes easier to assess. Ask for examples of comparable integrations. Walk through an exception alongside the standard workflow. Find out who owns the next step when a problem crosses between your platform and the prescribing service.
The answers will tell your team more about the build ahead than access alone can.
The open sandbox was free. The six weeks weren’t.
By the time the group returned, its team had already spent six weeks on the initial approach.
That time represented engineering effort, product attention and a prescribing capability that still needed to be delivered. Reconsidering a vendor also meant another round of evaluation and decisions about which parts of the work could carry forward.
The lesson is useful for any team comparing integration options: include your own implementation effort in the cost discussion.
A free test environment may be valuable. So are clear documentation, dependable support and a realistic plan for getting providers live. Your team needs enough information about each to compare the full commitment.
Three questions to ask before the build
Before your developers invest significant time, make room for these questions in the evaluation:
1. What does the path from sandbox to production actually involve?
Ask the partner to walk through the milestones, responsibilities, agreements, testing and approvals that apply to your integration. Get specific about what your team must provide and what could affect the timeline.
2. What experience can you show with platforms like ours?
Look for relevant examples, a clear explanation of supported workflows and evidence of how the partner handles implementation challenges. Ask to see how an exception is resolved as well as how a successful transaction works.
3. Who supports us during the build and after launch?
Identify the people and processes your developers and providers will rely on. Understand how issues are escalated, how service disruptions are communicated and who owns resolution.
The answers should be concrete enough to help your team plan its work.
A more informed starting point
When the urgent care group called us back, the conversation picked up with six weeks of experience behind it. The team had a clearer view of what it needed from an integration partner and what it wanted to examine before moving ahead.
Other teams can bring those questions into their evaluation from the beginning.
At DAW Systems, we work with platform teams evaluating ScriptSure Cloud E-Prescribing (eRx) to understand the workflows they need to support and the implementation approach that fits their product. That discussion helps establish the scope, responsibilities and support needed for the work ahead.
Evaluating e-prescribing partners? Download From Open Sandbox to Go-Live: An E-Prescribing Integration Evaluation Guide for seven vendor questions, a comparison worksheet and a checklist to help plan your path to production.
Ready to discuss ScriptSure eRx for your platform? Contact the DAW Systems team.