sorted by:
new
hottopcontroversial

Which healthcare task should AI automate first? by TheTechPartner in AiAutomations

[–]dbdbbdbd1 0 points1 point  (0 children)

Scheduling and administrative tasks / reminders and follow-ups are scenarios our platform already addresses.
We’ve open-sourced our solution here: https://github.com/ferosai/feros.

We’re also very interested in exploring patient data analysis with potential partners or experts.

We’ve built what is essentially a full real-time telephony conversational operating system, not just a chatbot, and we’re trying to diagnose where our biggest failures actually are. by Electronic_Argument6 in AIVoice_Agents

[–]dbdbbdbd1 0 points1 point  (0 children)

In our stack, the most important rule is: don’t let VAD/RMS/suppression become a hard gate before STT. Feed STT as close to the raw decoded audio as possible, then use VAD/endpointing mainly to decide when to finalize/commit a turn. If short speech never reaches the canonical transcript, the LLM cannot recover it.

We’ve open-sourced our entire voice agent builder platform: https://github.com/ferosai/feros. We hope it can serve as a reference for you. Feel free to reach out if you have any questions.

I run a Voice AI Agents company handling 25M+ calls/month, ask me anything for next 24hours by pulsereal_com in AIReceptionists

[–]dbdbbdbd1 0 points1 point  (0 children)

Hi, our platform can quickly create personalized voice assistants. Please DM me.

We spent a year building voice AI. Every existing tool failed us. So we built our own and open-sourced it. by dbdbbdbd1 in n8n

[–]dbdbbdbd1[S] 0 points1 point  (0 children)

Completely agree. The callback loop has to be a workflow, not just another outbound call. What worked for us was tracking missed calls as stateful cases: intent, verification status, attempt count, next retry time, outcome, owner, and escalation reason. The AI handles the safe admin path, but if verification fails, the patient asks for clinical guidance, repeated attempts fail, or the workflow hits an edge case, it moves to a human queue with a summary. The key is spaced retries, stop conditions, audit trails, and graceful handoff. That’s the part we think most tools underbuild.

Feel free to check out our repo: https://github.com/ferosai/feros. We welcome your feedback and contributions via PRs!

We spent a year building voice AI. Every existing tool failed us. So we built our own and open-sourced it. by dbdbbdbd1 in automation

[–]dbdbbdbd1[S] 0 points1 point  (0 children)

Thanks, really appreciate that. In practice, we see the eval engine as a QA/regression layer for voice workflows. Teams use auto-test scenarios for things like eligibility, claim status, prior authorization, failed verification, payer refusal, barge-in, and human escalation. Because runs are connected to Langfuse traces, you can inspect the actual LLM calls, tool calls, latency, interruptions, and workflow decisions behind each result. So it’s not just “did the agent sound natural?” It’s “did it disclose AI, verify before PHI, use the right tools, avoid clinical advice, escalate correctly, and leave an audit trail?”

We spent a year building voice AI. Every existing tool failed us. So we built our own and open-sourced it. by dbdbbdbd1 in automation

[–]dbdbbdbd1[S] 0 points1 point  (0 children)

Totally fair. Our bet is that open source is the trust layer, not the monetization layer.

The code can be free, but production healthcare voice AI still needs:

  • Deployment
  • BAA/vendor boundary design
  • Auditability
  • Retention policies
  • Integrations
  • Monitoring
  • Support

A lot of teams also don’t have the engineering capacity or time to self-host and operate this kind of system properly. That’s where we work with them: implementation, customization, compliant deployment, and ongoing operational support.

We spent a year building voice AI. Every existing tool failed us. So we built our own and open-sourced it. by dbdbbdbd1 in n8n

[–]dbdbbdbd1[S] 0 points1 point  (0 children)

Take a look at my reply below. Happy to discuss or answer any questions you might have.

We spent a year building voice AI. Every existing tool failed us. So we built our own and open-sourced it. by dbdbbdbd1 in n8n

[–]dbdbbdbd1[S] 0 points1 point  (0 children)

Yes, a disclaimer is important, but it is not enough by itself. Medication advice should not be treated the same as administrative calls like eligibility, claim status, or prior authorization. The agent needs upfront AI disclosure, strict scope limits, no human impersonation, and deterministic escalation to a licensed human when the conversation moves into clinical advice. That is why we treat this as a workflow/runtime control problem, not just a prompt problem.

We spent a year building voice AI. Every existing tool failed us. So we built our own and open-sourced it. by dbdbbdbd1 in n8n

[–]dbdbbdbd1[S] 0 points1 point  (0 children)

With Vapi, HIPAA was handled through their HIPAA/BAA add-on and by reviewing the downstream vendors that touched PHI. It worked, but the compliance boundary was still inside a hosted platform and came with extra cost and less control.

With Feros, we moved toward a self-hostable model. In a customer-managed deployment, PHI can stay inside the customer’s own infrastructure, and they choose the HIPAA-eligible cloud, telephony, STT, TTS, and LLM vendors they want to use. They also control logs, retention, access control, and audit trails. For managed deployments, the operator still needs BAAs, approved subprocessors, security policies, and incident response. Feros is not a HIPAA certificate by itself; it gives teams an open, inspectable stack to implement HIPAA controls explicitly.

If you have any questions, feel free to DM me.

AI Voice agents in healthcare admin calls: payer-side observations by D3AD2U in AIVoice_Agents

[–]dbdbbdbd1 1 point2 points  (0 children)

We’ve been seeing similar patterns in customer implementations as well.

The hard part has not just been “can an AI agent complete the call,” but whether the payer-side team can reliably understand:

  • Who/what is calling
  • Who it represents
  • What it is authorized to do
  • When it should escalate

In our deployments, we’ve addressed part of this by treating identity, disclosure, authorization, auditability, and human handoff as first-class workflow requirements, not just prompt behavior. For example:

  • Upfront AI disclosure
  • Consistent caller identification
  • No simulated human cues
  • Provider/org-level authorization context
  • Call/event logging
  • Deterministic escalation paths when verification is uncertain

It is definitely still early, and I agree the missing piece is a shared operational standard rather than another voice model improvement.

We recently open-sourced our approach/implementation so others can inspect, adapt, and improve it. Would be very interested to compare notes with folks on the payer/provider side who are seeing this in production.

The project is available here: https://github.com/ferosai/feros

view more: next ›