Cancer Pathology Data Sharing, published by HL7 International / Orders and Observations and College of American Pathologists. This guide is not an authorized publication; it is the continuous build for version 2.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/cancer-reporting/ and changes regularly. See the Directory of published versions

Specification

Page standards status: Informative

FHIR Paradigms Supported by This IG

• RESTful API

This guide defines 7 FHIR profiles:

• US Pathology Exchange Bundle
• US Pathology Composition
• US Pathology Observation derived from IHE SDC/eCP on FHIR Observation
• US Pathology Diagnostic Report derived from US Core DiagnosticReport (Notes)
• US Pathology Specimen derived from FHIR R4 Specimen
• US Pathology Service Request derived from US Core ServiceRequest
• US Pathology Related Practitioner Role derived from US Core PractitionerRole

This guide defines 5 value sets:

• US Pathology Provider Types ValueSet
• CAP eCC Answer Codes ValueSet
• CAP eCC Form Codes ValueSet
• CAP eCC Question Codes ValueSet
• CAP eCC Section Codes ValueSet

This guide defines 2 code systems:

• CAP eCC CodeSystem
• US Pathology CodeSystem

Extensions

This IG defines one extension:

• Extensions Lab

Document and Report Structure Design

This implementation guide adopts a dual-perspective approach where cancer pathology reports serve both as:

• Structured clinical data accessible through DiagnosticReport searches for EHR integration
• Legally signable documents organized through Composition resources for regulatory compliance and CAP eCC documentation

DiagnosticReport-Reference Extension Usage

The diagnosticReport-reference extension in the US Pathology Composition Laboratory Report enables bidirectional navigation between the document structure (optimized for CAP eCC organization) and the clinical report structure (optimized for clinical searches).

This approach follows the design pattern established by the HL7 Europe Laboratory Report and addresses the clinical workflow expectation that pathology reports are primarily accessed through DiagnosticReport queries while maintaining the document structure required for CAP eCC compliance.

Claiming Conformance to This Specification

This specification conforms to US Core Profiles. To claim conformance to this specification, servers SHALL:

• Be able to populate all profile data elements that have a minimum cardinality >= 1 and/or flagged as Must Support as defined by that profile’s StructureDefinition.
• Conform to this IG’s Server Capability Statement expectations for that profile’s type.

Details on profiles and extensions present in this specification are available on the Artifact Index page.

Must Support and Missing Data

Systems claiming to conform to a profile SHALL support the elements in a profile as defined below. This guide adopts the following definitions of MustSupport for all direct transactions between the Sending and Receiving Systems.

Sending Systems are defined as systems that generate and push data within a pathology lab workflow. These systems may be used by clinicians (ie oncologists) when ordering the pathological analysis for a patient, which will necessarily entail collecting (procedure) the specimen and sending it to a lab. These systems may also be used by a pathologists in cases of completed analysis and reports that need to be sent back to an clinician and/or to a cancer registry.

• As part of the sending of a US Pathology Bundle, the Sender SHALL be capable of including all elements defined in the profiles that have a MustSupport flag and SHALL populate all elements with a MustSupport flag if the information exists.
• In situations where information on a particular data element is not present, the Sender SHALL NOT include the data element in the resource instance if the cardinality is 0..n.
• If the information does not exist and the cardinality of the element is >= 1..*, the Sender SHALL use the dataAbsentReason extension where it is defined. Note: populating the element with the value set absent reason or using the dataAbsent Reason SHOULD be handled by the Sending System and not require provider action.

Receiving Systems are defined as systems that receive and are expected to process data within a pathology lab workflow. These systems may be used by pathologists (i.e. LIS, associated interface engines) when receiving a specimen and a request for analysis. These systems may also be used by clinicians who ordered the lab analysis/report. These systems may also represent central registries who aggregate and analyze pathology lab information.

• The Receiving System SHALL be capable of processing resource instances containing required and allowed data elements without generating an error or causing the application to fail.
• Receiving Systems SHOULD be capable of processing (display, store, etc.) the data elements based on the utility of the specific element to the receiver.
• When receiving a US Pathology Bundle from the Sender, the Receiving System SHALL interpret missing data elements within resource instances as data not present in the Senders systems.
• Receiving Systems SHALL be able to process resource instances containing data elements asserting missing information without generating an error or causing the application to fail.

Conformance to US Core Profile

Where this IG does not additionally constrain a US Core profile, the actors shall follow the US Core definition of Must Support and Missing Data.

Privacy and Security

Systems implementing this guide are expected to follow the general FHIR Security guidelines, as well as all additionally applicable public and private laws and policies.