Implementation Guide for Astacus project
0.0.1 - ci-build
Implementation Guide for Astacus project - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
To facilitate conformance testing, testing software must be able to determine which patients are “in-scope” (meaning cancer patients whose data is presented or exchanged with the intention of conforming to Astacus). In FHIR terms, these are patients who have a Condition where Condition.code
is a member of the value set [PrimaryCancerDisorderVS] and Condition.verificationStatus
is confirmed.
However, due to technical, organizational, or legal reasons, Astacus Data Senders MAY exclude some cancer patients from Astacus. In that case, the Astacus Data Sender MUST define a Group resource to identify ALL in-scope patients in their system. This Group resource MUST set Group.code
to C19700
with code system http://ncicb.nci.nih.gov/xml/owl/EVS/Thesaurus.owl
(this is the NCI code for concept “Cancer Patient”). Data Senders that do not exclude any cancer patients from Astacus MAY still populate a Group resource.
All Astacus Data Senders MUST respond to GET [base]/Group?code=C19700
with either zero or one Group resource. If no Group resource is returned, all patients with cancer diagnoses (as defined above) will be considered to be in-scope. If a Group resource is returned, patients not referenced in the Group resource are assumed to be out of scope, independent of any cancer diagnosis. This requirement is reflected in ALL CapabilityStatements referenced in this section.
The following CapabilityStatements define the various methods participants can use to identify in-scope Patients. Participants implementing a pull architecture MUST support at least one of the CapabilityStatements listed from most to least preferable, below.
In this approach, Senders respond to the following request with a Group resource referencing the Patient resources for all in-scope Patients, AND allow the Receiver to retrieve a Bundle of the Patient resources referenced in the first response using composite search parameters:
GET [base]/Group?code=C19700
GET [base]/Patient?_id=some_patient_id_1,some_patient_id_2,...,some_patient_id_n
CapabilityStatements:
In this approach, Senders respond to the following request with a FHIR Bundle of Patient resources for all in-scope Patients. This method is preferred over the approaches below UNLESS reverse chaining is entirely unsupported on the system.
GET [base]/Patient?_has:Condition:subject:code:in=http://hl7.org/fhir/us/mcode/ValueSet/mcode-primary-or-uncertain-behavior-cancer-disorder-vs
Capability Statements:
In this approach, Senders can respond to a request using _include
to get a Bundle of the relevant Patient resources along with the subset of Condition resources with Condition.code
in [Primary Cancer Disorder Value Set][PrimaryCancerDisorderVS] in a single request. Preferred over the approach below UNLESS _include
is entirely unsupported on the system.
GET [base]/Condition?code:in=http://hl7.org/fhir/us/mcode/ValueSet/mcode-primary-or-uncertain-behavior-cancer-disorder-vs&_include=Condition:subject
Capability Statements:
In this approach, Senders return a Bundle with the subset of Condition resources with a code
in the [Primary Cancer Disorder Value Set][PrimaryCancerDisorderVS] in a single request, AND allow the Receiver to retrieve a Bundle of the Patient resources referenced in the first response using composite search parameters:
GET [base]/Condition?code:in=http://hl7.org/fhir/us/mcode/ValueSet/mcode-primary-or-uncertain-behavior-cancer-disorder-vs
GET [base]/Patient?_id=some_patient_id_1,some_patient_id_2,...,some_patient_id_n
Capability Statements: