A tauSpan platform

Module 01 · HDC:Quality

Stop reading every chart. Start with the ones the evidence points to.

HDC:Quality reads your inpatient clinical notes and returns a structured finding for every case it flags: the clinical evidence it found, the reasoning behind the call, a confidence level, and an explicit flag when the chart is ambiguous and a person should decide. It runs on one scheduled report out of your clinical data warehouse — six columns, one row per note. A reporting job, not an interface project.

See how a finding is built Email sales@tauspan.com

The problem

Your quality data is accurate. It's also months old.

By the time a case has been abstracted, coded and reported, the patient went home a long time ago. The work is careful and the numbers are right — they just describe a hospital that has already moved on.

The bottleneck usually isn't judgement. Your reviewers are good at deciding whether an outcome happened. The expensive part is finding the cases worth deciding about, which means reading a great deal of narrative text to rule most of it out.

HDC:Quality takes that first pass. It reads the notes, surfaces the cases where the evidence points somewhere, and hands your reviewers the specific passages it relied on — so the judgement call starts from evidence rather than from a blank chart.

How this runs

Three things that are true about it.

One

file a night

One workbook of inpatient notes lands in a storage location scoped to your tenant, on a schedule you set. It is validated in full before anything is written and merged by note ID, so re-sending yesterday's rows changes nothing.

Zero

interface engines

What you build is a query, in the reporting tool your analysts already use. No HL7 feed, no field-mapping exercise, no EHR change window, and no waiting behind the platform upgrade that owns your integration team this year.

Every

flag, sourced

Each finding carries the clinical evidence, the reasoning, a confidence level and an ambiguity flag — traceable to the note it was drawn from, so a reviewer can check it against the chart.

How it works

From your warehouse to your work queue.

Step 01 is the only part your hospital builds, and it is a scheduled report. Everything after it happens on our side or in your reviewers' hands.

  1. Step 01

    Export

    Your reporting team writes one query against your clinical data warehouse — Clarity, if you're an Epic shop — returning six columns: MRN, encounter, note ID, note type, date and note text. Schedule it daily to a location whose credentials are yours alone.

  2. Step 02

    Merge

    The whole file is validated before a single record is written, then merged by note ID. Amended notes update in place. If a load fails, you hear about it — you don't find out a week later.

  3. Step 03

    Analyse

    An analyst starts a run. Your trigger definitions are applied to the relevant notes — inclusion criteria and exclusions both — and each case comes back as a structured finding.

  4. Step 04

    Review and act

    Findings land in a work queue. Assign them, forward them, comment on them, record a structured finding, export a trigger report as a PDF.

What it reads for

Your definitions, not ours.

A detector is whatever criteria you load into it. We set your definitions up with you during onboarding, so the module looks for what your department is already accountable for rather than a fixed list chosen by a vendor.

  • Chart-abstracted CMS quality measures. The measures your team abstracts by hand today, read against the same specification.

  • Registry measure definitions. The clinical criteria behind the registries you participate in, applied to the notes to find candidate cases.

  • Infection surveillance definitions. Healthcare-associated infection criteria, including the exclusions — device days, present-on-admission, present at the time of surgery.

  • Your own harm and safety triggers. The internal definitions your safety committee already uses, including ones no registry has a code for.

It reads for what rules a trigger out, too.

A definition is not just a list of things to find. It carries the exclusions as well — the conditions under which a case that looks like a trigger is not one. The module applies both halves, so a candidate case comes back either with the evidence that supports it or with the specific exclusion that rules it out and the text that establishes it.

That matters more than the flagging does. Abstraction is mostly the work of defensibly excluding cases, and an excluded case with no stated reason has to be re-read by a person from scratch. Here the reason is already attached.

What you get back

Anatomy of a finding.

A flag on its own is a to-do item. A flag with its evidence attached is a decision you can make. This is the shape of every result the module returns.

Detected outcome

Requires review

Clinical evidence

The specific findings, test results, symptoms and timeline the model actually read — not a summary of them, the passages themselves.

Exclusions applied

The exclusion criteria in the definition, checked against the record — present on admission, present at the time of surgery, and whatever else the specification carves out. A case ruled out on one of them says so, and shows the text that establishes it.

Clinical reasoning

Why that evidence supports or defeats the call, in language a reviewer can agree or disagree with.

Confidence

How strongly the record supports the conclusion.

Ambiguity flag

Set when the documentation doesn't support a clean call. The case routes to a human instead of being guessed at — ambiguity is an answer, not a failure.

Source notes

The note type and date each piece of evidence came from, so it can be checked against the chart.

Structure of a returned finding. Detector definitions are configured per hospital, so what is looked for follows your priorities.

For your reviewers

A workflow, not an inbox.

  • Evidence, not a score. Every flag returns what the model read, traced to the note type and date it came from.

  • Detectors you can change. The trigger definitions are yours — CMS chart-abstracted measures, registry measure criteria, surveillance definitions or your own — so what you look for follows your priorities rather than a vendor's release calendar.

  • Real review mechanics. Assignment, forwarding with accept or decline, threaded comments, and structured findings: outcome confirmed, false positive, additional outcomes found, clinical significance, documentation quality, recommended actions.

  • Answers about one patient. Per-encounter chat, grounded in that patient's notes, citing the note it drew from.

  • Reports that leave the building. Export a trigger report as a PDF for committee packets and case review.

  • Demo mode. A presenter toggle that de-identifies clinical text on the fly, so the work can be shown to a board or a vendor without showing the patient.

Direction

What's next for HDC:Quality.

Today

Designed for

An analyst starts a run against imported encounters.

Runs that start themselves as each night's export lands.

Findings are reviewed case by case in the work queue.

Reporting on real historical findings across a service line or a quarter.

Quality and Policy run side by side on one platform.

Asking what your policy says about a case without leaving the case.

Items under Designed for are directional and are not commitments.

Who it's for

  • Chief Quality Officer
  • VP of Quality
  • Chief Medical Officer
  • Chief Financial Officer
  • Quality nurses and reviewers
  • Patient safety
  • CIO / CTO

Start with one month of notes

Bring us a sample export.

We'll show you what it finds on your own material — evidence, reasoning and ambiguity flags included. One scheduled report is the whole of the integration.

sales@tauspan.com