SPHER

SPHER analyzes access to patient records and identifies unusual user behavior for privacy officers to investigate. Its learned component builds patterns from application audit logs, including the normal volume and timing of a person's activity. Anomalies are combined with detectors such as surname matching and presented through an investigation dashboard. This analysis is the core software offer, with reporting, retention and case handling supporting the detection process.

It is aimed specifically at healthcare applications and patient privacy rather than generic network administration. Some detectors have explicit matching logic, but the company also describes learned behavioral models that distinguish the product from a fixed rule audit log viewer.

A privacy or security officer reviews alerts in the dashboard, examines the underlying activity and decides whether to expand an investigation or declare a breach. This gives people responsibility for incident conclusions. However, the solution page also claims accurate detection of any unauthorized access, without a limitation on missed events in that statement.

Monitoring all daily activity is a coverage claim; detecting every unauthorized act is a stronger claim about output reliability. The public workflow does not supply sensitivity figures, confidence thresholds or defined blind spots that bound that assurance. Human investigation can resolve an alert, but cannot evaluate an incident that the system never surfaces.

The technical approach is behavioral anomaly detection over user activity logs. SPHER builds a profile of record access and compares activity such as volume, timing and location with expected patterns. A surname matching detector also flags access involving the user or people who may be relatives. The founders distinguish this approach from earlier SQL rule tools, and the solution identifies machine learning models as part of the detection process.

This explains the analytical method and inputs. It does not identify model families, versions, training data boundaries, release criteria or quantitative thresholds. The relationship between learned detection and fixed matching rules is described functionally rather than as a complete model specification.

The public architecture identifies application audit logs as inputs and SPHER's machine learning detectors as the analytical layer. eClinicalWorks is a confirmed source system, while secure file transfer brings activity into the hosted monitoring service. Neither the hosting provider nor any external model supplier is named in the public solution account.

The founders describe developing the product and refining its behavioral analysis, but do not provide a complete statement that all model processing is internal. A subprocessor inventory and recipient specific training or retention terms are absent. The seven year event archive describes one storage commitment without establishing every party that can receive or process those records.

Named customer accounts include Argus Medical Management, The Toledo Clinic and South Bay Gastroenterology. Their testimonials describe automated audit review and easier privacy monitoring, without dates, measured baselines or quantified changes in breach detection. A separate use case claim says that multiple instances of inappropriate access appear in 90% of initial deployments. The number of deployments, adjudication process, false positive rate and missed incident rate are not given.

This establishes actual customer use and a performance assertion, but not a test of detection accuracy. The 2026 conference appearance confirms continued company activity and does not add validation of the model's clinical application monitoring performance.

Documented events, incidents and the underlying audit history are retained for seven years according to the service FAQ. Alert emails omit specific user activity and go only to designated recipients, while details remain in the secured investigation interface. These are concrete handling commitments for sensitive access records.

They do not explain whether customer audit logs train shared models, how employee and patient identifiers are deidentified, or when copies outside the event archive are removed. The general privacy notice also defers customer processing to separate agreements. Public materials lack a model specific safety testing account and a procedure for addressing an AI failure that wrongly implicates or overlooks a user.

The solution is described as operating in a HIPAA compliant environment and handling access data for covered entities. Its privacy policy explicitly says that customer data processed through the service falls under service terms and any applicable BAA, confidentiality agreement or privacy agreement. The notice itself primarily governs the company's own account and website information, and excludes customer processing from that scope.

No readable service BAA or complete patient data processing agreement is attached. The public record therefore identifies a contractual route without showing its obligations, covered services or subcontractor terms. Product features that help a clinic meet privacy requirements are separate from the vendor's own contractual posture.

The solution page says that SPHER is maintained in a HITRUST certified environment and describes authenticated, encrypted file transfer with checks for alteration in transit. These statements support the described hosting and transfer safeguards. They do not identify the holder, scope or validity period of a certification belonging to SPHER itself. No company SOC 2 report, ISO certificate or independent security assessment is supplied with the public product material.

A certification of the environment cannot establish all controls operated by the application vendor. The identity of the host and the separation between its assurance coverage and SPHER's own responsibilities remain unspecified.

The product monitors access to health information rather than interpreting symptoms, diagnosing disease or recommending treatment. Its outputs are suspicious activity alerts, audit records and investigation reports for compliance and security staff. Source applications may contain clinical records, but the described analysis concerns who accessed them and how that activity compares with expected behavior. No FDA clearance is presented for SPHER.

References to ONC certified applications identify the systems being monitored and do not make the monitoring service a certified clinical device. The public use case is therefore administrative privacy and security support, with incident determination remaining part of the organization's compliance process.

The founders describe testing the early product with primary care and clinical groups, using their feedback to refine detection and investigation workflows. That is a development account, not a current model governance framework. Public materials do not specify validation gates, model change approval, drift monitoring or independent tests of disparate false alerts across employee roles and working patterns.

The product's purpose is to help customers govern data access, but that does not establish governance of its own AI. Commonly discussed patterns such as unusual hours or high record volume may have legitimate workflow explanations; no published evaluation quantifies how reliably the models distinguish those cases.

Investigators can return to the source audit history, examine visualizations and preserve the actions taken during an incident review. Exportable reports and a seven year archive provide a way to revisit why an alert was raised and how the organization resolved it. Those features support challenge and correction within the customer's workflow.

Public materials do not provide an output accuracy guarantee, reimbursement commitment or vendor obligation to remedy harm from a false accusation or missed breach. The privacy policy's account data rights are distinct from a route to contest a model conclusion about access behavior. The main available recourse is human investigation using retained evidence.

eClinicalWorks names Spher in its current audit log integrations and describes exporting user action logs as flat files. Its partner page also explains how SPHER analyzes those logs and presents an incident resolution process. This confirms a named connection with a specific direction of data flow. SPHER's own materials add secure FTP transfers, receipt acknowledgement, integrity checks and support for other clinical application logs.

The evidence concerns reading exported activity records, not writing clinical data or findings back into the EHR. Broad support claims for PACS, practice management and custom applications do not identify the same level of system specific detail for each connection.

SPHER is a centrally maintained cloud service accessed through a secure browser interface. The FAQ says that no software is installed at the customer's site, while application audit logs are transferred into the monitoring environment. This distinguishes the hosted service from the systems it monitors, which may themselves be local or cloud based. Public materials do not name the hosting provider, a processing region, backup locations or a choice of residency.

The Gardena address in the privacy policy is a company contact address rather than a data center commitment. Tenant isolation and access by support personnel across locations are also not specified in the public deployment account.

The company markets a hosted monitoring service through a channel partner program with recurring revenue for resellers. Deployment involves connecting application audit logs and training the customer's privacy or compliance staff to review alerts. That establishes a service model and the main implementation work, rather than a standalone consulting engagement.

Public pages do not identify a subscription price, a charge per provider or monitored user, a minimum contract value or a setup fee. Claims of affordability are not enough to calculate cost. Different source applications and versions can require different connections, but a public rate card does not show how those differences affect the customer's charge.

SPHER targets healthcare organizations from private practices to larger groups, monitoring activity in EHR, practice management, imaging and other systems holding patient information. The named customer accounts include a multispecialty clinic, a gastroenterology practice and a medical management organization. Those examples support use in part of the stated market. Public materials do not show separate detection performance by specialty, organization size or source application.

The eClinicalWorks connection gives a specific supported system, while broader references to ONC certified applications and custom systems describe intended reach. A practice's clinical specialty does not by itself establish that its local access patterns or exceptions have been validated.