SpinSci Technologies

Two decades of integration middleware with an AI layer added on top, and a buyer should size it that way. The company was founded in 2005 and its durable value is the bidirectional EHR to contact center connection: pulling live patient data into the agent desktop and writing outcomes back to the system of record.

The newer AI agents handling inbound and outbound interactions are real, and the company describes a proprietary framework that extracts EHR decision logic to make those agents workflow aware, but the integration substrate is what the platform has always been.

Explicitly a hybrid model rather than full automation: the company positions AI agents as working alongside human staff to speed up interactions and reduce handle time, with a unified agent desktop putting patient data at a human agent's fingertips. Autonomy is highest on outbound campaigns and self service, lower on complex inbound where the agent assist framing dominates. Automated workflows include nurse triage, which is the one to scrutinize, since triage carries clinical consequence and no published detail describes the escalation threshold.

The company names a proprietary Healthcare AI Framework as the platform beneath its agents, describing it as extracting the EHR's decision logic and ingesting unstructured data to create an AI ready foundation, and is explicit that it is infrastructure rather than a standalone product. Earlier materials describe robotic process and desktop automation as the automation substrate. No model provider, architecture, or performance measurement is published.

Nothing identifies any party in the chain: no model provider, no hosting arrangement and no sub processor list was located, and no retention period, training position or de identification posture was found. A newer product surface changes what this axis is asking and makes the questions more pressing rather than less.

The company now offers protocol based integration tooling that lets third party artificial intelligence agents and digital assistants invoke operations against enterprise record systems, covering appointment scheduling, patient verification, prescription requests and billing inquiries, and describes itself as the secure execution layer for those calls. That is a materially different role from surfacing data into a human agent's screen.

It makes this vendor the intermediary through which other companies' agents act on a patient's chart, which is an architectural position this index has not recorded before and which relocates the governing questions entirely. They become what an agent is permitted to invoke, what is logged when it does, who reviews an action taken autonomously against a record, and how an action is attributed afterwards when three parties were involved in producing it.

A prescription request submitted by an agent through an execution layer into a record system has a chain of responsibility that nobody has drawn. Nothing published addresses any of it, and a buyer should treat the permission model, the logging and the review path as contract terms rather than implementation detail.

Scale claims are large and long running but thinly evidenced. The company reports serving more than 60 million patients and automating more than 400 million healthcare interactions, with a stated 40 percent cost reduction, and earlier materials cite over 100 Fortune 500 customers and 50,000 clinical and non clinical agents. Customer quotes come from named health system executives. What is absent is methodology behind the cost figure or any independent evaluation, and the aggregate interaction counts span two decades of integration work rather than AI specifically.

No published retention period, no statement on whether customer data is used to train or improve models, and no de identification posture was located. The data surface is broad and continuous: the platform surfaces live patient records into contact centre agent desktops, writes outcomes back to the record, and performs patient identity verification.

A newer product surface makes the questions more pressing rather than less. SpinSci now offers Model Context Protocol based integration tooling that lets Webex AI agents and digital assistants invoke operations against enterprise electronic health record systems, covering appointment scheduling, patient verification, prescription requests and billing inquiries, with SpinSci describing itself as the secure execution layer for those calls.

That is a materially different role from moving data into a human agent's screen. It makes the vendor the intermediary through which third party AI agents act on the record, which means the governing questions become what an agent is permitted to invoke, what is logged when it does, and who reviews an action taken autonomously against a patient's chart. Nothing published addresses any of the three, and a buyer should treat those as contract terms rather than implementation detail.

No HIPAA statement addressing SpinSci's own obligations and no business associate agreement terms were located. The company describes streamlining communication in a safe, secure and private manner, which is positioning rather than a commitment.

Business associate status is structurally certain given the deployment pattern, since the product surfaces live patient records into contact centre agent desktops and writes outcomes back. The compliance statements that are findable belong to Cisco and cover the Webex platform, and a buyer should not read those as reaching the integration layer.

The contracting question is sharper here than for a single vendor product. A health system deploying this holds agreements with Cisco for the contact centre, with SpinSci for the integration, and with its electronic health record vendor, while patient data moves across all three. Establish which party carries which obligation for the data in transit between them, because the architecture makes that boundary genuinely ambiguous rather than merely undocumented.

No SOC 2, HITRUST or ISO 27001 attestation held by SpinSci was located, and no trust centre was found.

The certifications that do surface belong to the platform the product plugs into, not to the product. Cisco holds HITRUST CSF certification for Webex components and states that Webex Contact Center and Webex Connect adhere to the health privacy rule. That is a real credential and it is Cisco's. It covers the collaboration platform, not the integration layer SpinSci builds on top of it, and it says nothing about how SpinSci handles the record data it moves between that platform and the electronic health record.

This is a variant of the certification non transfer problem worth naming separately, because it is more persuasive than the usual version. The inherited credential here is not a distant cloud provider's but the certification of the very application the product runs inside, which makes the elision easy for a buyer to miss. Marketplace listings on Cisco, Epic, Amazon and Salesforce imply each platform's own partner review was passed, which is a real signal but is not a published attestation either. Ask for SpinSci's own report and its scope.

No FDA pathway applies to contact centre and patient access automation. The nurse triage workflow is the closest the platform comes to clinical territory, and it is positioned as routing and communication support rather than clinical assessment.

Graded C because a different regime does apply and the company states no position on it. The platform runs outbound as well as inbound patient interactions, and the FCC ruled in February 2024 that AI generated voices are artificial voices under the Telephone Consumer Protection Act, requiring prior express consent and identification of the entity responsible for the call. Inbound contact raises none of this. Outbound does. Nothing published addresses where consent comes from, and because the platform is sold to the provider rather than operating on its own behalf, the buyer should also establish which party carries the consent and do not call obligation under its contract.

No governance framework or bias evaluation was located.

The material question in a patient access channel is whether automated handling performs consistently across accents, languages and speech patterns. Speech recognition accuracy is documented to vary along exactly those lines, and this is the front door to the health system: scheduling, referrals, pharmacy refills and nurse triage routing. Uneven performance here translates directly into uneven access to appointments and care, and it does so silently, because a caller who gives up after a failed interaction leaves no record of the attempt. Nothing published addresses whether that variation is measured.

Two passes located no model provider, no architecture, no accuracy or performance measurement, no evaluation methodology and no warranty, indemnity or remediation commitment. A proprietary framework is named as the platform beneath the agents and described as extracting the record system's decision logic and ingesting unstructured data to create a foundation for further work, with the company explicit that it is infrastructure rather than a standalone product.

That explicitness is worth a word: a vendor stating plainly that its offering is a substrate rather than an application is drawing a scope boundary, and it tells a buyer that the performance of anything built on it is not the same question as the performance of the substrate. It also means the substrate's own errors propagate into every application above it, which makes the absence of any measurement more consequential rather than less.

Extracting decision logic from a record system is the specific claim to press, because a misreading there does not produce a visible failure, it produces an agent acting on a rule the institution does not actually have. The execution layer role described on the other axis compounds it, since the same substrate now mediates third party agents acting on charts. Ask what accuracy the extraction achieves, how extracted logic is validated against the institution's actual configuration, and what happens when the record system changes.

This is the company's core competency and the most thoroughly evidenced axis. It states native bidirectional integration with Epic, Oracle Health, and other major EHRs, explicitly describing it as foundational rather than a surface level connection built over nearly two decades working exclusively in healthcare. Named integrations span CCaaS and telephony platforms including Cisco, Genesys, Five9, Avaya, and 8x8, plus CRM systems including Epic Cheers and Salesforce.

The company appears in Epic's app marketplace and multiple enterprise vendor marketplaces, and third party documentation confirms HL7 compliant integration with Epic, Cerner, and MEDITECH. Few vendors in this index can enumerate integration depth this specifically.

The integration architecture is disclosed, which is more than most of this category offers, and it is disclosed in the partner marketplace listing rather than on the vendor's own site. Enabling the solution requires paid Webex Contact Center licences, paid SpinSci licences through Cisco's ordering system, and access to the customer network where the electronic health record is hosted by way of a site to site VPN.

That last element is the substantive fact. The product reaches the record through a tunnel into the customer's own environment rather than by extracting data to a vendor estate, which removes part of the transfer question instead of merely locating it. Credited with attribution, and a buyer should note the vendor does not state it on its own materials.

Held at B rather than A because nothing describes SpinSci's own side: no hosting provider, no region, no tenancy model, no residency commitment and no subprocessor list. A VPN into the customer network still leaves the question of what the vendor's own components retain and where they run.

No published pricing, tier or mechanism.

Procurement may run through partner marketplaces given listings in several enterprise vendor stores, which can change the contracting path for an organisation already buying through those channels. That is a route, not a price, and no economics are disclosed on any of them.

Broad functional coverage of the patient access surface rather than clinical specialty depth: scheduling, billing, referrals, nurse triage, pharmacy refill, transfer center, operator console, call steering, and clinical communications. The buyer is a health system contact center or patient access organization, and the company states a healthcare focus while noting its communication technology also serves other regulated industries. Not a clinical product and should not be evaluated as one.