Before Ohio’s nineteen 988 contact centers can share one statewide platform, their local knowledge has to become routing logic, permissions, integrations, documentation rules and testable decisions. That translation is engineering.
“Transfer the call” sounds like a complete requirement.
For a statewide crisis platform, that phrase is only the beginning.
Transfer to whom? Based on the caller’s location, the responding team’s coverage area or the center that answered first? What information follows the call? Does the receiving party see it before accepting? What if that party is unavailable? Can a specialist remain connected until another person joins? Which local relationship should be preserved? What happens when a life-safety emergency requires 911?
Every answer changes the system.
At RingMD, we are developing Ohio’s state-centralized 988 platform around this central challenge. Nineteen local contact centers need a shared environment for voice, text, chat, routing, warm transfers, referrals, documentation and statewide analytics. Each center also brings established practices, coverage relationships and knowledge of its community.
The platform has to create statewide coordination without deleting the information that makes local response useful.
That work begins with discovery.
“Current state” is rarely singular
Large procurements often describe a current state and a future state.
Across a network of local organizations, there may be nineteen current states.
Centers may use different telephony tools, staffing models, documentation conventions and referral processes. One center may have a mature relationship with a local Public Safety Answering Point. Another may route certain situations through a county behavioral-health authority. Mobile crisis availability may vary by geography and time. Resource information may be stored in different formats and updated through different practices.
We distinguish between practices that reflect the communities each center serves and workarounds that create avoidable burden. Our discovery process preserves local knowledge while identifying the variation a statewide platform should simplify.
Our discovery starts with a better question: how can statewide coordination strengthen the local knowledge each center brings?
We identify which workflows must be consistent for statewide interoperability, which local practices protect continuity, where configuration can preserve useful differences and where a common rule will reduce risk or delay.
Understanding why the centers differ is how we design a future state that works for all nineteen.
The frontline specialist holds part of the architecture
An organization chart identifies authority. It does not show the complete path of a crisis interaction.
The specialist answering the call knows where the workflow bends. They know which referral source is accurate, which screen requires duplicate entry, which transfer often fails, which local team wants a telephone call before an electronic dispatch and which information a receiving partner needs immediately.
That knowledge is architectural.
Our discovery process includes sessions and workshops with contact centers, local behavioral-health authorities and mobile crisis partners. We listen for the decisions their work already requires and make those decisions visible enough to build.
A strong session moves beyond feature requests. When someone asks for a button, we ask what event the button represents. When someone asks for a dashboard, we ask what decision the dashboard should support. When two centers describe different processes, we examine whether the underlying need differs or is simply expressed through different tools.
We listen first, then turn what we hear into workflows, data rules and testable platform behavior.
Vocabulary must become exact before logic can
Crisis systems contain words that sound universal until people try to implement them.
“Warm transfer” may mean that the original specialist introduces the caller to the receiving party and remains until the connection is established. Elsewhere, it may mean sending contextual information before transferring. “Dispatch” may refer to a request, an assignment or confirmation that a team is moving. “Available” may mean staffed, accepting referrals or capable of responding within a required period.
Software cannot safely rely on approximate definitions.
Discovery creates a shared vocabulary: actors, events, states, permissions, outcomes and exceptions. That vocabulary becomes a data model and a workflow model.
For example, a crisis interaction may move through states such as received, triaged, transferred, referred, dispatched, followed up and closed. Each transition requires conditions. Who can trigger it? What information is mandatory? What timestamp is recorded? Can the action be reversed? What happens if the next service declines or cannot be reached?
Clarity at this level may feel procedural. It is what allows reporting, automation and accountability to describe the same reality.
The exceptions reveal the real system
A process diagram usually shows the happy path.
A caller reaches the appropriate center. The specialist assesses the need. A suitable resource is available. The handoff succeeds. Documentation is complete.
Crisis operations are defined by what happens when one of those assumptions fails.
The caller’s location may be uncertain. The local center may be overloaded. A person may contact the system through text while a voice call would better support the next step. A mobile team may cover the area but lack current capacity. A referral listing may exist while the service itself is unavailable. A technical integration may be online while the human receiving workflow has changed.
We capture these exceptions and organize them into practical patterns: unavailable destination, missing data, conflicting jurisdiction, capacity constraint, safety escalation, failed integration or user-access issue. Each pattern can then have a defined fallback and a clear owner.
We test these exception paths with the same care as the primary workflow.
That work helps specialists act with clarity even when conditions change.
The handoff is a cross-system transaction
The Substance Abuse and Mental Health Services Administration’s crisis-care guidance describes a coordinated system with someone to contact, someone to respond and a safe place for help.
That model depends on transitions.
A 988 interaction may need to connect with 911, Mobile Response and Stabilization Services, a mobile crisis team, a crisis stabilization setting or a community provider. The person seeking help experiences one crisis. The institutions may experience several separate transactions.
We are designing Ohio’s platform to make those transitions more coherent. Smart routing is being built around geography, capacity and established local relationships. Warm-transfer and coordinated-dispatch workflows are being designed to preserve context. The referral layer will make the next service easier to identify, while dashboards will give centers and state leaders appropriate operational visibility.
The Ohio platform is under active development, and we are building and testing these capabilities with the people who will use them. Live operation will add statewide performance data to that strong implementation foundation.
Discovery lets us design every handoff as shared work across systems, with clear context, ownership and fallback paths.
Notes become requirements only when they are testable
A workshop can produce hundreds of observations. Engineering cannot build from observations alone.
Our job is to turn stakeholder knowledge into artifacts the delivery team can act on: workflow maps, user stories, acceptance criteria, data definitions, integration specifications, permission models, decision tables and traceable backlog items. Varun Arora, our COO and one of the leaders of the Ohio delivery, keeps that translation connected across agency discussions, program decisions and engineering work.
Consider the statement, “The system should route locally whenever possible.”
To become testable, the team must define “locally,” identify the authoritative location data, describe the capacity rule, specify exceptions, determine what the specialist can override and establish what the system records. A test case can then ask: given this caller location, center status and existing PSAP relationship, which destination appears first, what does the specialist see and what happens if the destination does not answer?
Acceptance criteria make stakeholder knowledge durable. They also allow disagreement to surface before code decides the answer by accident.
The traceability chain is straightforward:
Observed need → agreed workflow → explicit requirement → configured behavior → tested outcome.
Every missing link increases the risk that the product will be technically functional and operationally wrong.
Governance turns disagreement into decisions
Stakeholder-driven design brings local expertise into a clear statewide decision process.
Our governance process carries frontline knowledge into statewide decisions without blurring who has authority.
We make those tradeoffs visible before they become late changes or conflicting expectations.
When all centers share a need, we establish a common requirement. When a local difference protects continuity, we configure for it. When the State must decide, we document the question and move it to the appropriate authority. Decision logs preserve what was chosen and why, while change control protects agreed workflows from being altered without understanding the consequences.
In practice, good governance gives legitimate disagreement a clear path to resolution.
At RingMD, proximity is an operating advantage. Program leaders, product staff, engineers and government stakeholders can stay in a tight decision loop, with each decision documented and traceable.
Testing should replay the work
Traditional software testing can verify whether a button works, a field saves or an API returns the expected response.
Workflow testing asks whether the system helps a person complete the real task across boundaries.
For Ohio, our workflow tests follow an interaction from entry through assessment, routing, handoff, referral, documentation and reporting. Centers and roles test the variations they described during discovery. We rehearse failure conditions, check data at each transition and examine the receiving partner’s experience as carefully as the sending center’s.
User acceptance testing is where the people who understand the work verify that their knowledge survived translation into the system.
Training will carry the agreed workflows into practice. Hypercare after launch will capture issues that appear only under live volume, while analytics and frontline feedback will show where the configured process can improve.
We will continue discovery after the first release, using operating evidence—not expectation alone—to refine the platform.
The product of discovery is operational confidence
When deadlines tighten, discovery meetings can look slower than code appearing on a screen.
But unresolved ambiguity does not disappear when development begins. It moves downstream, where it becomes rework, inconsistent behavior, delayed integrations and user distrust.
Ohio’s challenge goes far beyond putting nineteen logos on one interface. We are creating a shared operating environment that specialists can trust during consequential interactions, that local partners can connect to and that state leaders can use to understand the system without erasing the communities inside it.
That requires engineering the invisible parts first: definitions, decisions, handoffs, exceptions and ownership.
For RingMD, discovery is engineering. It turns frontline knowledge into executable logic and gives Ohio’s statewide platform a foundation that reflects the system and communities it is being built to serve.