minimal Common Oncology Data Elements (mCODE) Implementation Guide
2.1.0 - Pre-STU 3 Development United States of America flag

minimal Common Oncology Data Elements (mCODE) Implementation Guide, published by HL7 International Clinical Interoperability Council. This is not an authorized publication; it is the continuous build for version 2.1.0). This version is based on the current content of https://github.com/HL7/fhir-mCODE-ig/ and changes regularly. See the Directory of published versions

CapabilityStatement: mcode-receiver-patients-in-group (Experimental)

Official URL: http://hl7.org/fhir/us/mcode/CapabilityStatement/mcode-receiver-patients-in-group Version: 2.1.0
Draft as of 2020-10-30 Computable Name: CapabilityStatementReceiverPatientsInGroup

Capabilities for an mCODE Data Receiver where not all cancer patients conform to mCODE. Retrieves a Group of references to Patient resources that conform to mCODE, and allows for the full Patient resources to be retrieved in a subsequent request.

Raw OpenAPI-Swagger Definition file | Download

mCODE Data Receiver: Get Patients in Group

  • Official URL:http://hl7.org/fhir/us/mcode/CapabilityStatement/mcode-receiver-patients-in-group
  • Implementation Guide Version: None
  • FHIR Version: 4.0.1
  • Intended Use: Requirements
  • Supported Formats: XML, JSON
  • Published: 2020-10-30 07:15:00.000000-04:00
  • Published by: None
  • Status: Draft (experimental)

Capabilities for an mCODE Data Receiver where not all cancer patients conform to mCODE. Retrieves a Group of references to Patient resources that conform to mCODE, and allows for the full Patient resources to be retrieved in a subsequent request.

Support the Following Implementation Guides:

FHIR Client RESTful Capabilities

An mCODE Client SHALL:

  1. Support all profiles defined in this Implementation Guide..
  2. Implement the RESTful behavior according to the FHIR specification.
  3. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401/4xx): unauthorized request
    • (Status 403): insufficient scope
    • (Status 404): unknown resource
    • (Status 410): deleted resource.
  4. Support json source formats for all mCODE interactions.
  5. Identify the mCODE profiles supported as part of the FHIR meta.profile attribute for each instance.
  6. Support the searchParameters on each profile individually and in combination.

The mCODE Client SHOULD:

  1. Support xml source formats for all mCODE interactions.

Security:

  1. See the General Security Considerations section for requirements and recommendations.
  2. A client SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.

RESTful Capabilities by Resource/Profile:

Summary

Resource TypeSupported InteractionsSupported ProfilesSupported SearchesSupported _includesSupported _revincludesSupported Operations
Patientread Cancer Patient _id
Groupsearch-type code

Patient

Conformance Expectation: SHALL

Supported Profiles:

Profile Interaction Summary:

  • SHALL support read.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching a Patient resource using: GET [base]/Patient/[id]

Search Parameter Summary:

ConformanceParameterTypeExample
SHALL_idtokenGET [base]/Patient?_id=[id]

Group

Conformance Expectation: SHALL

Profile Interaction Summary:

  • SHALL support search-type.

search-type

Retrieve Group of references to Patient resources conforming to mCODE.

Fetch and Search Criteria:

  • A Client SHALL be capable of fetching resources matching a search query using: GET [base]/Group/[id]{?[parameters]{&_format=[mime-type]}}

Search Parameter Summary:

ConformanceParameterTypeExample
SHALLcodetokenGET [base]/Group?code=[system]|[code]