Custom registry automation: extract any data element from any cohort

Alongside standard NAACCR cancer registries, Patient Journey Intelligence supports fully custom registry configurations for any clinical use case: disease-specific cohorts, outcomes studies, quality improvement initiatives, and research programs whose data elements no standard registry template covers. You describe what to extract in plain language, and the system runs the extraction.

Prompt-based field definitions

Define extraction fields in plain language, with expected result examples. No coding and no pipeline configuration.

OMOP cohort scoping

Scope extraction to any patient population with the same OMOP-based cohort builder, conversational AI, or pre-built templates that standard registries use.

Source-linked provenance on every field

Every extracted field carries the provenance and governance of a standard registry: source document, extraction timestamp, and confidence score.

Step 1: scope the patient population

Scope which patients to include first. Custom registries use the same cohort definition tools as the Cancer Registry module, meaning the OMOP filter builder, conversational AI, or a pre-built template, so the process is identical whatever the registry type.

See Cancer Registry, Step 1: define the patient cohort for a full description of all three methods. The defined cohort is selected when you configure the curation job in Step 3.

Step 2: define a custom extraction ontology

An ontology is the extraction schema for your custom registry: the set of fields to populate for each patient, described in plain language. You describe what each field means and give examples of the values you expect, with no code and no pipeline configuration.

Reuse or adapt an existing ontology

Where a relevant ontology already exists from a previous project, select it as the starting point. Every field definition and example is editable before saving, so an existing schema can be reused, extended, or narrowed.

This is the recommended path when:

• Running a new cohort against an extraction schema you have already validated
• Deriving a focused sub-registry from a broader existing ontology
• Standardizing extraction across several projects on a shared base schema

Build a new ontology from plain-language field definitions

To build a new ontology, navigate to Patient Registry → Custom Registry and click Add Registry. Name and describe the registry, then add fields one at a time. Each field takes:

• Name: the internal identifier used in exports and API responses, for example primary_diagnosis or date_first_recurrence
• Display Name: the human-readable label shown in the interface and result views, for example Primary Diagnosis, Date of First Recurrence, or ECOG Performance Status
• Category: groups the field within the ontology for navigation and reporting. Standard categories are Demographics, Clinical, Lab, Medication, and Procedure, and custom categories can be defined
• Data Type: the expected shape of the extracted value, one of free text, date, numeric, boolean, or coded value. This controls validation and export formatting
• Extraction Instruction: the plain-language prompt the AI models follow at extraction time. Describe what to extract, which document types to look in, and the terminology to expect, for example "The patient's primary cancer diagnosis as documented in the pathology report or discharge summary. Extract the full histological description including morphology and behavior."
• Example Values: one example per line showing representative correct extractions. Include edge cases and, where relevant, negative examples of what the field should not capture. More specific examples produce more accurate extraction

How to write effective field descriptions

The field description is the instruction the AI models follow at extraction time, so specificity and examples are what raise accuracy. Name the terminology to expect and give at least two or three examples of valid values.

Example: one field, written twice

A vague instruction such as "the patient's stage" returns II, Stage 2, pT2N0, and 2B from different notes for the same cohort. An instruction that names the source and the format, such as "The pathologic AJCC 8th edition stage group documented in the synoptic section of the surgical pathology report. Return the stage group only, for example IIA.", with example values IA, IIA, IIIB, returns one comparable value per patient.

Fields can be added, reordered, and removed at any point before the ontology is published. Once published and used in a curation job, the ontology is versioned: a change creates a new version rather than overwriting the existing one, which preserves the extraction lineage of past jobs.

Step 3: create a curation job

A curation job ties the cohort and the ontology together and runs the automated extraction. Navigate to Data Curation Studio → New Curation Job and click Add Automation to open the curation wizard.

1. Select the registry: choose the ontology created or selected in Step 2. An overview of all its fields is shown so you can confirm the extraction schema before proceeding.
2. Select the cohort: choose the patient cohort defined in Step 1. The estimated patient count is displayed before you confirm.
3. Configure the automation: set two extraction parameters.
   • Extraction level: Patient level consolidates findings across all of a patient's documents into one abstraction record. Document level produces a separate result per document, which is what you need to track how a value evolves across visits or to compare findings across document types.
   • Document ranking: enable it to prioritize higher-quality or more recent documents when evidence conflicts, or disable it to weight all documents equally.
4. Name and describe the automation: a name and short description that will identify the results later, for example name NSCLC Outcomes 2022-2024, description Patient-level extraction of treatment response and recurrence for EGFR-mutated NSCLC cases. This metadata is searchable in the results library.
5. Review and create: the summary screen shows the full configuration, including registry, cohort patient count, extraction level, document ranking setting, and automation name. Confirm it, then click Create Automation. Processing starts immediately.

Verify cohort scope and field list before starting

Review the field list and patient count on the summary screen before confirming. Extraction runs against the full cohort, and changing the scope or ontology after launch requires a new automation job.

Step 4: monitor progress and review intermediary results

Once a curation job is running, the job dashboard gives real-time visibility into the extraction.

Cohort-level and per-patient progress

Progress is reported at two levels:

• Cohort level: overall completion percentage, patients processed, patients pending, and any processing errors
• Patient level: per-patient status, with any individual patient record open to show which fields are extracted and which are still pending

Intermediary results are available for patients whose extraction has completed while the rest of the cohort is still processing, so review starts before the job finishes.

Per-patient results with evidence and confidence scores

For each patient, results appear as a structured record with one row per ontology field:

• Extracted value: the result of the extraction for that field
• Source evidence: the document and passage the value was drawn from, with the relevant text highlighted
• Confidence score: the model's certainty, which is the signal for deciding which fields to review first

At cohort level, aggregate statistics show value distributions across fields, which is where extraction anomalies, unexpected null rates, and value patterns that suggest a field definition needs refinement become visible.

Step 5: export the extracted data

When extraction is complete, results can be exported for analysis, reporting, or integration with other systems.

Exporting the full cohort: go to Curation Job → Export Curation to generate a structured file holding every extracted field for every patient in the job.

Exporting individual patients: individual patient records export directly from the patient view.

Exports are available in JSON and CSV. Every exported record carries full provenance metadata, including source document reference, extraction timestamp, and confidence score, matching the governance of standard registry exports.

Certified expert validation for custom registries: coming soon

Human-in-the-loop validation for Custom Registries is in development. When it is released it will follow the same field-level review workflow as the Cancer Registry module, with accept, edit, and flag actions, supporting and contradictory evidence display, and a complete audit trail, applied to your custom ontology fields.

Editing and deleting registries built with the Ontology Builder

Custom registries created with the AI-assisted Ontology Builder can be edited and deleted after creation. An AI-built registry was previously treated as a built-in registry once saved, which blocked modifications and left no way to remove it.

To edit an AI-built registry, open it from the Custom Registries list and select Edit. Ontology fields, field instructions, categories, and data types are all editable. Changes apply to curation jobs started after the edit, and results from jobs that already ran are unaffected.

To delete a registry, select Delete from the registry's action menu and confirm. Deleting a registry leaves the extraction results of curation jobs that used it in place, and no new job can be started against a deleted registry.

Custom Registries and Data Curation profiles are separate lists

Custom Registries and the curation profiles used in Data Curation previously appeared in one shared list in two places, under Patient Registry and inside Data Curation, so a change made by one team showed up for the other.

They are now maintained separately:

• Patient Registry owns the Custom Registries list. Registrars and registry managers define, edit, and manage their ontology-based extraction schemas here.
• Data Curation has its own Profiles page. Curation users see and manage the profiles relevant to their workflows.

Existing registries and profiles are unaffected by the separation and appear in the appropriate list according to how they were created. The separation is what stops a curation profile change from silently altering a registry, and the reverse.

---

An ontology is the extraction schema: the set of fields to populate for each patient. Each field carries a Name, a Display Name, a Category (Demographics, Clinical, Lab, Medication, Procedure, or a custom category), a Data Type (free text, date, numeric, boolean, or coded value), a plain-language Extraction Instruction, and Example Values. No code or pipeline configuration is involved.

Patient-level extraction consolidates findings across all of a patient's documents into one abstraction record. Document-level extraction produces a separate result per document, which is what you use to track how a value evolves across visits or to compare findings across document types. The choice is made at step 3 of the curation wizard.

Document ranking prioritizes higher-quality or more recent documents when the evidence conflicts. With it disabled, all documents are weighted equally. It is set per automation at step 3 of the wizard.

Yes. Ontologies are versioned once published and used, so a change creates a new version rather than overwriting the existing one, and the extraction lineage of past jobs is preserved. Changes apply to jobs started after the edit.

Yes. Open the registry from the Custom Registries list and select Edit to change fields, instructions, categories, and data types, or Delete from the action menu to remove it. Deleting a registry leaves the results of jobs that already used it in place, and no new job can run against a deleted registry.

JSON and CSV. Every exported record carries the source document reference, the extraction timestamp, and the confidence score, which matches the governance of standard registry exports. The full cohort exports from Curation Job, then Export Curation, and individual patients export from the patient view.

No. They are maintained as separate lists. Patient Registry owns the Custom Registries list, where registrars and registry managers define their ontology-based extraction schemas. Data Curation has its own Profiles page. Existing registries and profiles appear in the appropriate list according to how they were created.

Human-in-the-loop validation for Custom Registries is in development. When released it will follow the Cancer Registry module's field-level review workflow, with accept, edit, and flag actions, supporting and contradictory evidence display, and a complete audit trail, applied to custom ontology fields.