Oracare AI

Oracare AI is the third stage of the product, and the first part of SC-Oracare to become a separate service. It has its own repository, its own deployment and its own authentication, and SC-Oracare holds no model, no provider key and no provider SDK. The service does four things for SC-Oracare: transcription, medical entity extraction, document capture, and retrieval over de-identified patient records. Only SC-Oracare calls it, from its server.

Oracare AI is a FastAPI service that runs as two containers on Azure Container Apps. The API container scales out on its own and never loads a model. The model runtime holds the biomedical entity model and an open embedding model in memory, loads them once at startup, and accepts no call without a service token, so the model sits on its own scaling axis and never in every API replica’s memory.

Every capability follows one provider contract, so a provider can be swapped by configuration: Azure AI Speech or Deepgram for speech, Azure Document Intelligence for documents. Simulated providers exist for local development only, and any simulated answer is flagged as such, so a deployment can never quietly return made-up patient details as if they were real.

One rule outranks the others: the service keeps no patient content. Audio, images, transcripts and extracted fields exist only for the length of one request, and logs and audit records carry field names, sizes, durations and outcomes, never values.

Drafts, not decisions

AI output here is a proposal, never a record. When a clinician dictates a referral, the draft fills SC-Oracare’s referral wizard and stops at the review step; a person approves it, and nothing is submitted automatically.

The extraction is built to refuse rather than guess. A date without a year is not accepted as a date of birth, an unreadable time becomes a question rather than an approximation, and a doctor or clinic that does not match exactly is asked about instead of picked. Missing details become short follow-up questions, and nothing is written to the form until every question is answered, so cancelling leaves the form exactly as it was.

Retrieval and isolation

Records are isolated per patient by PostgreSQL row level security, enabled and forced, so that even the table’s owner cannot bypass it. The patient is set for one transaction only, which keeps the design safe behind a connection pooler, and the policy is the only filter: the search query has no patient clause at all, so there is nothing for the next person who writes a query to forget.

A question about a patient needs a patient access grant. SC-Oracare issues one only after its own scope and care team checks pass, keeps it short-lived, and binds it to both the clinician and that one patient. Oracare AI verifies the grant independently, so a bug on one side does not silently become a bug on both.

Search is hybrid, in one SQL statement: vector similarity with pgvector for meaning, and PostgreSQL full-text search for exact tokens such as procedure codes. The two ranked lists are fused by reciprocal rank fusion, because ranks compare cleanly where raw scores do not, and results come back with citations to the records they came from. Recency only breaks ties, so an old allergy that is still current is never buried. An empty result stays empty.

Key decisions

Security and identity

Each call carries a Microsoft Entra ID token that SC-Oracare gets on behalf of the signed-in clinician, scoped to one capability. The browser never talks to Oracare AI, so no token sits in page scripts, and every call still passes through SC-Oracare’s audit trail.

I wrote the validator myself. It checks the algorithm against an allowlist before it looks at the signature, then verifies the signature against Entra’s published keys, found through OpenID Connect discovery, cached, and refreshed when a token names a key it has not seen, with a cooldown so that tokens carrying random key IDs cannot make it hammer Microsoft’s key endpoint. Then it checks issuer, audience, expiry and the scope for the capability being called. Identity comes only from the token, never from a body, a header or a URL, and every rejection gets the same message.

Filling the retrieval index uses an app-only credential that can write to the index and cannot read it, while the query side can read and cannot write, so a leak of either credential is limited to one direction.

De-identification

Patient records reach the retrieval index only after two separate checks, on both sides of the boundary, using different techniques on purpose so that they do not share a blind spot.

On the SC-Oracare side, a chart becomes documents keyed only by its medical record number. Fields can reach a document only through an allowlist, the patient’s own name, contact details, address and date of birth are removed by known value, very old ages are banded as HIPAA’s Safe Harbor method requires, and a final sweep aborts the whole export if any identifier survived.

On the Oracare AI side, every incoming document is screened again, and one that still carries an identifier is refused, not cleaned. The rejection reports what kind of identifier it found, never the value.

Delivery and operations

Each capability is covered by unit tests with providers faked, so the suite runs with no keys and no network. A security suite runs across all of the capabilities together: it checks authentication and per-capability authorization, confirms that a token for one capability is refused by the others, plants a patient’s name in every capability and searches every log line for it, and confirms that forged tokens all get the same answer. A coverage floor is enforced in the test run, dependencies are audited for known vulnerabilities, and both container images run as a non-root user.

When I moved extraction out of SC-Oracare, I ran the old and new implementations side by side on the same inputs and compared them field by field before any test was written. Defects inherited from the original code were pinned by tests and reported, not fixed in the same change, so any difference in an extracted value could be traced to its cause.

Isolation is tested against a neighbouring patient given an identical vector and nearly identical text, at several retrieval depths. Retrieval quality is measured against a gold set of questions, including some that cannot be answered, with recall and abstention reported separately, and the targets the current phase did not meet are recorded rather than dropped.

Result

Both containers run in Azure, and SC-Oracare calls them for dictation and document capture. The retrieval index holds synthetic data only, and stays that way until it has a customer-managed key and a private endpoint. Retrieval with citations is built and measured; no language model is attached yet. The next phase is grounded answering on a self-hosted open model inside the same tenant, so clinical text never leaves it, followed by the clinician chat in SC-Oracare.

Demo

Oracare AI has no public endpoint: it answers only SC-Oracare, from its server. Its dictation and document capture run inside the SC-Oracare live demo (opens in new tab), and the isolation demo on the home page simulates per-patient retrieval with synthetic records.