USCDI+ Clinical Trials Matching Implementation Guide
0.1.0

⚠️ This is a developmental version of the guide and is under active development. Content may change at any time without notice. No official release has been made. The final base canonical URL and hosting location have not yet been determined. This guide should not be used for production implementations.

This page is under active development and subject to change.

2.5. CTM Sponsor-initiated Trial Matching: FHIR Query-Based Cohort Identification Workflow

On this page

2.5.1. Overview

In this interaction, a CTM service uses FHIR query interactions identifying a cohort of patients at a provider's FHIR-endpoint based on the CTM-defined eligibility criteria. The resulting patient data set is used to retrieve patient data from a provider’s FHIR endpoint. The CTM service may temporarily store or process this data to execute eligibility matching logic.

2.5.2. Scope

2.5.3. Actors

  • CTM Service: authorized FHIR client that identifies candidate patients and retrieves CTM data
  • Provider FHIR Server: FHIR server that exposes the CTM-relevant resources and search interfaces
  1. The CTM Service initiates a query against the Provider’s FHIR server.
  2. A broad query is executed to identify candidate patients.
  3. The Provider system returns a Bundle of matching patients.
  4. The CTM Service iterates through candidate patients and retrieves detailed data: Conditions, Observations, Procedures, Medications
  5. The CTM Service aggregates and processes the data.
  6. Trial matching is performed internally (out of scope for this IG).

2.5.5. Cohort Flexibility

The IG intentionally does not prescribe a single cohort definition language or algorithm. A CTM Service MAY define or derive a candidate cohort through:

  • structured query logic
  • terminology/value-set matching
  • implementation-specific query builders
  • FHIR Group resources that identify in-scope patients
  • other approaches that can be translated into FHIR retrieval steps

When a CTM cohort is represented explicitly, the CTM Service SHOULD consider using a FHIR Group resource as the exchange-facing representation of the candidate cohort. This pattern is similar to the mCODE approach for identifying in-scope cancer patients, where Data Senders use Group.code and support a query such as GET [base]/Group?code=C19700 to identify the applicable patient group. In CTM, the specific Group.code, membership criteria, and population semantics are implementation-defined unless otherwise constrained by a CTM use case or profile.

The Provider FHIR server is not required to understand external cohort-definition languages. The Provider's responsibility is to expose the CTM-relevant FHIR resources and search capabilities needed to retrieve candidate patient data. Where the Provider FHIR server supports Group, it MAY expose CTM-relevant candidate cohorts as Group resources and allow clients to retrieve referenced Patient resources using standard FHIR search patterns.

2.5.6. Minimum Retrieval Capabilities

After candidate patients have been identified, the CTM Matching Service SHALL be able to retrieve the baseline CTM data elements from the baseline resource set outlined in the Capability Statement page.

2.5.6.1. Example queries based on the minimum patient-level retrieval patterns

The queries below are illustrative examples showing how the minimum CTM data elements MAY be retrieved. Specific codes and parameters for these queries are implementation-defined.

Data element / retrieval purpose Example search query
Patient GET Patient/[id]GET [base]/Patient?_id=[id]
Clinical Performance Status and Clinical Performance Status Assessment Date GET [base]/Observation?patient=[id]&code=http://loinc.org|89247-1,http://loinc.org|89243-0,http://loinc.org|89246-3
Smoking Status GET [base]/Observation?patient=[id]&code=http://loinc.org|72166-2
Laboratory Test, Laboratory Date and Time, Values/Results, Reference Range, and Unit of Measure GET [base]/Observation?patient=[id]&category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory
Pregnancy Status GET [base]/Observation?patient=[id]&code=http://loinc.org|82810-3
Comorbid Conditions GET [base]/Observation?patient=[id]&code=http://snomed.info/sct|398192003
General Stage GET [base]/Observation?patient=[id]&code=http://loinc.org|21908-9,http://loinc.org|21902-2,http://loinc.org|21914-7
TNM - T Category GET [base]/Observation?patient=[id]&code=http://loinc.org|21905-5,http://loinc.org|21899-0,http://loinc.org|21911-3
TNM - N Category GET [base]/Observation?patient=[id]&code=http://loinc.org|21906-3,http://loinc.org|21900-6,http://loinc.org|21912-1
TNM - M Category GET [base]/Observation?patient=[id]&code=http://loinc.org|21907-1,http://loinc.org|21901-4,http://loinc.org|21913-9
Date of Diagnosis and Problems (example condition: B-cell acute lymphoblastic leukemia) GET [base]/Condition?patient=[id]&category=http://terminology.hl7.org/CodeSystem/condition-category|problem-list-item&code=http://snomed.info/sct|277571004
Histology, Primary Site, Metastasis Anatomic Site, and Recurrence Anatomic Site GET [base]/Condition?patient=[id]
Procedure and Procedure Date (example procedure: radiotherapy) GET [base]/Procedure?patient=[id]&code=http://snomed.info/sct|1217123003
Procedure and Procedure Date (example procedure: defibrillator implant) GET [base]/Procedure?patient=[id]&code=http://www.ama-assn.org/go/cpt|33249
Medication and Medication Administered Date (example medication: cyclophosphamide) GET [base]/MedicationAdministration?patient=[id]&code=http://www.nlm.nih.gov/research/umls/rxnorm|3002&_include=MedicationAdministration:medication

2.5.7. Profile Strategy for Sponsor-initiated Trial Matching

Sponsor-initiated Trial uses the same profile strategy defined in the USCDI+ CTM V1 data mappings:

  • The Provider server SHALL expose the mapped base resource and mapped data elements needed for each required CTM data element
  • The Provider server SHOULD support the listed CTM preferred profile for each data element
  • The CTM Matching Service SHALL be capable of consuming the mapped data elements when represented in the preferred profile
  • The CTM Matching Service SHOULD also tolerate the mapped alternative profiles listed in the public mapping table when the preferred profile is not available

2.5.8. Authorization Guidance

Detailed authorization requirements for Sponsor-initiated Trial Matching are out of scope for this Implementation Guide. Implementations that use backend system-to-system access SHOULD follow the SMART on FHIR Backend Services authorization model, including appropriate client authentication, access token use, least-privilege scopes, and access limited to the resources and operations needed for the interaction.

2.5.9. Missing Data Guidance

Sponsor-initited Trial Matching SHALL treat incomplete search results as incomplete data, not as evidence that a clinical fact is false.

  • An empty searchset Bundle means no matching resource was returned by that query, not necessarily the patient does not have the clinical fact.
  • If a mapped element is absent within a returned resource, the CTM Matching Service SHOULD treat the element as unknown/unavailable unless the resource explicitly carries a negated or absent-data meaning.
  • The CTM Matching Service SHOULD continue processing with available data when feasible and SHOULD track that the evaluation is limited by missing data.