Skip to main content

Create a patient cohort with the Assistant

Describe a patient population in plain language, read the criteria the Assistant used to match it, refine the request until the population is right, and save it as a named cohort. The page stops at the saved cohort. The workflows that consume it are covered on their own pages.

Who this is for​

Anyone who can state a patient population in a sentence but does not want to build the filters behind it by hand:

  • Clinicians and clinical researchers scoping a question before committing to a study
  • Tumor registrars and abstractors doing case finding
  • Clinical data analysts defining denominators for quality measurement or real-world evidence work
  • Data curators who need a patient population before building a dataset
  • The administrator who confirms ingestion is complete and grants access to the Assistant and Cohort Builder

Why it matters​

"Female patients with stage II or III breast cancer diagnosed in the last three years" is a sentence a tumor registrar can write without stopping to think. For anyone who has to turn it into a query, it is a join across condition, person, and observation-period tables, with a vocabulary lookup for every way stage II gets recorded, and the stage itself often lives in the pathology report rather than in a coded field. That gap between the clinical sentence and the query is where cohort work stalls, usually on someone else's calendar.

The Assistant takes the sentence and returns a patient count together with the criteria it applied. You can read those criteria, decide they are wrong, and say so in the next message rather than filing a request and waiting.

What you save at the end is a named object, not a query someone ran once on a Tuesday. The same cohort definition feeds dataset creation, care gap analysis, registry projects, and trial matching, so every one of those workflows starts from an identical population. Six months later, when a reviewer asks how the denominator was defined, the answer is a cohort record anyone can open.

What you gain​

A saved cohort and the criteria summary that explains why each patient is in it. The summary is what makes the cohort reviewable: a colleague who did not build it can read the inclusion logic and check it against the clinical intent, instead of trusting a number.

The cohort is reusable by design. Point Dataset Builder at it, run a care gap analysis against it, or use it as the patient population for a registry project, and none of those steps requires rebuilding the definition. PJI assembles the population and documents how it was assembled; clinicians make the clinical decisions about the patients in it.

Before you start​

  • Completed ingestion of the structured clinical data and linked documents you expect to query. Building a cohort against a partly loaded environment is the most common cause of a count that looks wrong for reasons that have nothing to do with your criteria
  • A clear natural-language cohort question. "Cancer patients" will return something; it will not return a population you can defend
  • Any constraints you plan to apply, such as a date range, diagnosis, medication, lab result, demographic attribute, or document requirement
  • An understanding of whether the facts you are filtering on are coded in the structured data or only stated in narrative documents. That distinction decides what the platform can match on
  • Access to the Assistant and Cohort Builder in your deployment

Step 1: Ask for the patient population​

  1. Open the Assistant or Cohort Builder experience.
  2. Describe the patient population in plain language, for example: "patients with breast cancer and pathology reports in the last two years."
  3. Include the constraints that matter to the question, such as a date range, diagnosis, medication, lab, demographic, or document requirement.
  4. Keep the first request close to the clinical question you actually care about. Broad first, then narrow, is easier to review than a single long request.

Step 2: Review the patient count and criteria summary​

  1. Read the returned patient count.
  2. Open the criteria summary and check what the Assistant matched on for each part of your request.
  3. Confirm that date windows, diagnosis terms, and document requirements were interpreted the way you intended. A phrasing can be read more literally, or more loosely, than you meant it.
  4. Treat a count that looks too low or too high as a question about the underlying data before you treat it as a question about the criteria. See Limitations.

Step 3: Refine the request​

  1. Add follow-up constraints in the same conversation, for example narrowing a date range or requiring a specific document type.
  2. Clarify any clinical term the criteria summary interpreted differently from what you intended.
  3. Remove constraints that are excluding patients you expect to be in the population.
  4. Review the count and criteria summary again after each change, so you can attribute a shift in the population to a specific edit.

Step 4: Save the cohort​

  1. Save the final population as a cohort and give it a name a colleague will recognize in six months.
  2. Confirm the saved cohort carries the criteria summary that explains why patients were included.
  3. Reuse the cohort as the starting point for datasets, care gap analysis, registry projects, or de-identification.

Limitations​

  • A zero-patient result may mean the data is missing, not that the clinical population does not exist. An empty cohort is a statement about what has been ingested, linked, and coded in this environment, and nothing more. Before concluding that no patient matches, check that ingestion completed, that documents are linked to patients, and that the fact you filtered on is recorded somewhere the query can reach it. A stage recorded only in the narrative of a pathology report will not match a filter on a coded staging field.
  • Ambiguous clinical terms may need clarification. A term that carries several meanings in practice can be interpreted more broadly or more narrowly than you intended, which is what the criteria summary is there to expose.
  • Cohorts should be reviewed before being used for regulatory, trial, or operational decisions. The saved population is a documented starting point for that review, not a substitute for it.
  • Which entry point you use, and which data the cohort can reach, depend on how your deployment is configured and on what has been ingested into it.