Join the Applied AI Summit | Free online conference | October 13-15, 2026
was successfully added to your cart.

Automated
patient registries

Registry abstraction time drops 10x with exception-based validation. Every field arrives already coded, with its source document, supporting text, and confidence score attached. Runs inside your environment on OMOP CDM v5.4.

Why start with John Snow Labs

Powered by Medical LLMs validated
at production scale

500+

enterprise customers across health systems, pharma, payers, and government

30+

peer-reviewed papers and patents on clinical NLP and medical LLMs

150M+

downloads of our open-source libraries and medical models

80+

public case studies of real-world implementations

12 of 13

medical benchmarks where Medical LLM ranks first against frontier models

THE CHALLENGE

Regulatory-grade accuracy, verified

Regulatory-grade means the output holds up in front of an auditor or a peer reviewer – not “AI-assisted” drafts
a specialist must redo. In peer-reviewed results, automated abstraction exceeded human expert performance:
>95%

Accuracy on real-world data, above human expert abstraction

>95%

Reduction in human effort at regulatory-grade concordance

<15 min

Per case, for human review;
down from 120 minutes

Two registry paths

Two registry paths. One pipeline.

Both options use the same five-step pipeline, the same cohort definitions, and the same audit trail. The difference is where the field definitions come from: NAACCR and its 2,500+ pages of rules, or an ontology you import or define in plain language.
Pre-configured
NAACCR cancer registry
  • 750+ fields
  • 2,500+ pages of rules
  • AJCC staging
  • Edits validation
Read the cancer registry documentation →
One Cohort, Provenance, And Audit Trail Framework
  • 01 Cohort definition
  • 02 Case finding
  • 03 AI Abstraction
  • 04 HITL Validation
  • 05 Export + audit
No code
Custom registry
  • Plain-language field definitions
  • Versioned ontology
  • Patient- or document-level extraction
Read the cancer registry documentation →
How it works

From cohort definition to NAACCR submission

The output of each step is the input to the next, and every value stays traceable to the document it came from – from cohort definition to a NAACCR submission file.
Step 01

Cohort definition

  • The cohort sets the registry scope; defines which cases get pulled in, monitored, and routed for abstraction
  • Build it visually against OMOP CDM v5.4 across any domain, from a template (NPCR/SEER reportable, CoC accreditation, site-specific), or describe it in plain english;
  • A live patient count updates as you add criteria, so scope is verified before launch
  • OMOP CDM v5.4 filter builder
  • live patient count
  • plain-language cohort prompts

Learn more

Step 02

Registry creation and automatic case finding

  • The project wraps the cohort and sets the abstraction rules: NAACCR version, target state registry, and registrars assigned by site expertise, facility, or workload
  • On launch, the platform monitors the EHR continuously for cases matching the cohort definition
  • Note screening often surfaces cases weeks before diagnosis coding appears
  • Each case arrives with its detection source, cancer site, histology, and date of diagnosis, and the abstraction schema is chosen automatically
  • NAACCR version + registrars
  • found weeks before coding
  • automatic schema detection

Learn more

Step 03

Automated AI abstraction

  • Reads all relevant documentation per case: pathology, radiology, genomics, operative notes, treatment orders
  • Extracts, codes, and validates relevant NAACCR data items based on the selected schema: demographics, ICD-O-3 topography and morphology, AJCC TNM with stage group, tumor characteristics and SSDIs, biomarkers (ER, PR, HER2, Ki-67, PD-L1), treatment, and longitudinal outcomes
  • Medical Language Models trained per cancer site
  • Every value carries full provenance: source document, supporting text, confidence score, timestamp
  • 700+ NAACCR data items
  • AJCC staging
  • full provenance per field
  • site-specific language models

Learn more

Step 04

HITL Review

  • Registrars open a pre-populated NAACCR abstraction form – no chart hunting
  • Each field shows the coded value, a colour-coded confidence score, and both supporting and contradictory evidence highlighted in the source documents with the model’s reasoning
  • Accept, edit, or re-run extraction rules on a selected passage
  • Every extraction, correction, and approval is permanently logged with identity and timestamp; any two versions of a case can be compared side by side
  • NAACCR edit checks, completeness checks, and optional dual abstraction run before submission
  • review by exception
  • confidence-scored fields
  • evidence side by side
  • NAACCR edit checks
  • CoC · state · SEER audit trail

Learn more

Step 05

NAACCR export and submission

  • Export validated cases as NAACCR XML or JSON, compliant with NAACCR v25
  • Field mapping for your target – state cancer registry, SEER program, or CoC accreditation body – is applied automatically
  • Individual cases export on their own for amendments or outside review
  • No manual file formatting or edit-check scripting
  • NAACCR v25 XML / JSON
  • state · SEER · CoC mapping
  • single-case amendments

See more

Custom registries

Write the ontology. The registry builds itself.

A custom registry runs the same five-step pipeline against an ontology you write yourself, so defining one is a writing task for the person who knows the question.
  • 01Ask any clinical question Cardiology, rare disease, transplant, quality — nothing has to match an existing standard.
  • 02Define fields in plain language Display name, data type, extraction instruction, example values. That is the whole field.
  • 03Test on small samples & iterate Run the registry against a handful of cases, check the extracted values, then add, edit, or drop fields and re-run.
  • 04Apply on your cohort in a registry project Attach the ontology to a registry project and run it across the full cohort, with the same provenance and audit trail as a cancer registry.
Registries teams have defined this way
Cardiovascular outcome
Rare disease natural history
Transplant follow-up
Device and implant tracking
Quality and PI measures
Trial feasibility and screening
Biomarker surveillance
Health equity and SDOH
What you control per field
  • Patient - or document-level extraction
  • Validation rules and controlled vocabularies
  • Optional human review
  • JSON and CSV export with provenance
  • Applies to both paths

    One governance layer runs every registry

    The same controls govern cancer and custom registries, from assignment and review to audit-ready provenance.
    See it run

    Watch the team walk through registry automation

    Registrar validation:
    reviewing a NAACCR case by exception

    Defining a cohort three ways: OMOP filters, templates, plain language

    Building a custom
    registry ontology with prompt-based fields
    Deployment and engagement

    Your data stays where it is

    Where it runs

    On-premises, private cloud on AWS, Azure, or GCP, Databricks and Snowflake, and air-gapped environments. No external API calls, so no clinical data leaves your control.

    Data model and integration

    All registry data lands in OMOP CDM v5.4, with FHIR and HL7 ingestion and an OMOP-to-FHIR converter. Exports go out as NAACCR XML or JSON, CDC and state formats, JSON, and CSV.

    Compliance and governance

    HIPAA and GDPR compliant, with multimodal de-identification and full provenance on every extracted fact: source document, timestamp, confidence score, and transformation lineage, which is what FDA real-world evidence guidance asks for.

    Time to first value

    A pre-built registry template runs against historical cases in days. Most custom registries reach production in 6-8 weeks. Licensing is fixed-cost, with no per-token fees.

    Powered by

    The same products your teams already license

    Available on the AWS, Azure, Snowflake and Databricks marketplaces, so the pipeline runs next to data you cannot move.

    Pilot it on one registry, with your own cases

    Bring a sample of already-abstracted cases. We’ll compare the platform’s output field by field against your validated data, so you can judge it on your own results.

    Frequently asked questions

    No. Registrars stay the approvers. The platform removes chart hunting and transcription so their time goes to complex cases, conflicting evidence, and quality validation. Every case still passes through human review before submission, and every correction is logged and feeds back into model quality.

    Run a pilot on a sample of your own already-abstracted cases and compare field by field. The version diff view puts the AI extraction next to your registrar's validated abstraction, so you can see exactly where the model agrees, where it diverges, and on which fields. Dual abstraction with inter-rater tracking is available for ongoing QA.

    Every value traces to a source document, a specific text span, a confidence score, and a timestamp. Registrar edits record the original value, the correction, who made it, and when. That trail satisfies CoC, state registry, and SEER audit requirements without extra documentation work.

    Guideline logic lives in registry-specific agents as deterministic decision graphs, separate from the extraction models. Revisions are updated in that layer and applied consistently going forward, instead of retraining every registrar on a new edition at the same time.

    Yes. Custom registries take any ontology you define in plain language against any OMOP-scoped cohort: disease-specific research cohorts, device and implant tracking, quality improvement programs, or outcomes studies. Most reach production in 6–8 weeks. Human-in-the-loop validation for custom registries is in development and will follow the same field-level review workflow.

    No. The models run inside your infrastructure, on-premises or in your private cloud, including air-gapped deployments. There are no external API dependencies and no data movement.