One system of record for patient data

We integrate read-only with EHR systems, consolidate patient records into a single source of truth, and surface the patients who meet your clinical and coverage criteria — with an audit trail behind every match.

The problem

Patient data lives wherever each facility put it

Vendors and suppliers serving multiple facilities inherit whatever EHR each one runs. The result is four recurring costs.

Manual chart review

Staff read charts by hand to determine who qualifies for a product or treatment. It doesn't scale with the number of facilities, and it competes with clinical work.

Lists that go stale immediately

A qualified-patient list is accurate the day it's built. Admissions, discharges, diagnosis changes, and coverage changes erode it from that point on.

No single view across facilities

Each EHR has its own schema, vocabulary, and access path. Without normalization there's no way to ask one question across every facility at once.

Decisions you can't reconstruct

When a determination is questioned months later, spreadsheet-and-email workflows can't show which criteria were applied or which records satisfied them.

How it works

Connect, define, surface

Three stages, run continuously rather than as a one-off extract.

Connect to the source systems

We establish read-only access to each facility's EHR and normalize incoming records — demographics, diagnoses, orders, coverage — into a common schema. Source values are preserved alongside the normalized form, so nothing is lost in translation.

Define the criteria

You express what qualifies a patient: diagnosis codes, clinical thresholds, care setting, coverage and payer rules, exclusions. Criteria are versioned, so a change is a new revision rather than a silent overwrite.

Surface and maintain the matches

Matching runs against the consolidated record and produces qualified-patient lists that update as the underlying charts change. Each match carries the criteria version and the source records that satisfied it.

Integrations

EHR systems we connect to

Six systems are approved, two of them running in production today. The connector layer is pluggable — adding a system is connector work, not a platform rewrite.

“In production” means the integration is built and currently moving data. “Approved” means SoftFinity is an approved integration partner with the connector available, and the integration is activated per engagement. SEEK EDI is an EDI and clearinghouse interface rather than an EHR proper, and is listed here because it sits in the same data path. Any further provider is onboarded subject to that provider's own review and approval process.
System Status Access model
McKesson EHR In production Read-only, scoped credentials
Experity Health In production Read-only, scoped credentials
PointClickCare Approved Read-only, scoped credentials
MatrixCare Approved Read-only, scoped credentials
NIKO Health Approved Read-only, scoped credentials
SEEK EDI Approved EDI / clearinghouse interface
Additional providers Onboarded per engagement API, HL7, FHIR, or structured export
Architecture & safeguards

Built for the review you'll be asked to pass

EHR providers and their customers vet integrators carefully. These are the properties we design to, and the ones we can evidence during a security review.

Read-only by design

We read what's needed to build the record and evaluate criteria. We do not write back, modify, or delete anything in a source chart.

Encrypted in transit and at rest

Transport is encrypted end to end, and stored records are encrypted at rest. Credentials are held in a managed secret store, never in application code.

Tenant-isolated storage

Each customer's data is isolated. No tenant can query, infer, or observe another tenant's records.

Minimum necessary access

Connectors request the narrowest field set that supports the defined criteria, rather than whole-chart replication.

Versioned, not overwritten

Records and criteria are archived as new revisions rather than destructively updated, so any past state stays reconstructable.

Auditable matches

Every match records the criteria version, the satisfying source records, and the evaluation time — so a determination can be explained later without re-querying the EHR.

Implementation

What onboarding looks like

We work inside whatever review process the EHR provider and facility require, and we expect to evidence our controls rather than assert them.

Access and scope

Agree the access path, credential scope, and field set. Validate against a non-production environment first.

Connector and mapping

Build the connector, map source fields to the common schema, and reconcile against known-good records.

Criteria definition

Encode the qualifying rules with you, then test them against historical data to check both matches and misses.

Production and monitoring

Cut over to live data with monitoring on freshness, connector health, and match volume, so drift surfaces early.

Clinical staff reviewing patient data on screen
FAQ

Questions EHR providers ask us

The answers below match the structured data on this page, so search and answer engines can quote them directly.

Which EHR systems does SoftFinity integrate with?

SoftFinity has production integrations with McKesson EHR and Experity Health, and is an approved integration partner for PointClickCare, MatrixCare, NIKO Health, and SEEK EDI, with those connectors available and activated per engagement. The connector layer is pluggable, so further systems are onboarded without rebuilding the platform.

Does SoftFinity write data back into the EHR?

No. Integrations are read-only by design. We read the records needed to build the system of record and to evaluate matching criteria, and we never modify, delete, or write back to source charts.

How is protected health information handled?

Data is encrypted in transit and at rest, storage is tenant-isolated so no customer can observe another customer's records, and access is scoped to the minimum fields required. Handling is HIPAA-aware: records are versioned and archived rather than deleted, so history remains reconstructable.

Can a patient match be audited after the fact?

Yes. Every match records which criteria were evaluated, which source records satisfied them, and when. A match can be reconstructed and explained without re-querying the EHR.

How long does onboarding a new EHR connector take?

It depends on the access path the provider offers. Where a documented API or standards-based interface such as HL7 or FHIR exists, the work is connector configuration and field mapping. Where access is limited to exports or reports, onboarding also covers ingestion and normalization of those formats.

What does SoftFinity need from an EHR provider to begin?

A read-only access path with scoped credentials, interface documentation, and a non-production environment to validate against. We work within whatever review, security questionnaire, and approval process the provider requires.

Evaluating us as an integration partner?

Tell us which EHR system and which review process you need us to go through, and we'll respond with the technical and security detail your team requires.

Get in touch