CardX - Cardiac Implantable Electronic Devices
1.0.0-ballot - STU 1 - Ballot International flag

This page is part of the CardX - Cardiac Implantable Electronic Devices (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) v5.0.0. No current official version has been published yet. For a full list of available versions, see the Directory of published versions

CapabilityStatement: CardX CIED Connectivity Server Capability Statement

Official URL: http://hl7.org/fhir/uv/cardx-cied/CapabilityStatement/cied-data-sender Version: 1.0.0-ballot
Standards status: Trial-use Maturity Level: 2 Computable Name: CIEDConnectivityServerCapabilityStatement

CardX CIED Connectivity Server CapabilityStatement

Raw OpenAPI-Swagger Definition file | Download

CardX CIED Connectivity Server Capability Statement

  • Implementation Guide Version: 1.0.0-ballot
  • FHIR Version: 5.0.0
  • Supported Formats: json
  • Supported Patch Formats:
  • Published on: 2025-07-09
  • Published by: HL7 International / Clinical Interoperability Council

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

FHIR RESTful Capabilities

Mode: server

A CardX CIED Connectivity Server SHALL:

  1. Implement the RESTful behavior according to the FHIR specification.
  2. Return the following response classes:
    • (Status 400): invalid parameter
    • (Status 401): unauthorized request
    • (Status 403): insufficient scope
    • (Status 404): unknown resource
    • (Status 410): deleted resource.
    • (Status 501): not implemented.
Security
  1. See the General Security Considerations section for requirements and recommendations.
  2. A server SHALL reject any unauthorized requests by returning an HTTP 401 unauthorized response code.
Summary of System-wide Interactions

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
Resource TypeProfileRSUCSearches_include_revincludeOperations
PatientSupported Profiles
  Patient - CIED Patient Profile		yyidentifier
DeviceSupported Profiles
  Device - Cardiovascular Implantable Electronic Device (CIED)
  Device - CIED Monitor Profile		yymanufacturer, model, udi-di, type, serial-number
ObservationSupported Profiles
  Observation - CIED Connectivity		yysubject, code, component-value-concept

Resource Conformance: SHALL Patient

Core FHIR Resource
Patient
Reference Policy
Interaction summary
  • SHALL support read, search-type.

Supported Profiles

Patient - CIED Patient Profile

Search Parameters
ConformanceParameterTypeDocumentation
SHOULDidentifiertoken
 

Resource Conformance: SHALL Device

Core FHIR Resource
Device
Reference Policy
Interaction summary
  • SHALL support read, search-type.

Supported Profiles

Device - Cardiovascular Implantable Electronic Device (CIED)
Device - CIED Monitor Profile

Search Parameters
ConformanceParameterTypeDocumentation
SHOULDmanufacturerstring
SHOULDmodelstring
SHOULDudi-distring
SHOULDtypetoken
SHOULDserial-numberstring
 

Resource Conformance: SHALL Observation

Core FHIR Resource
Observation
Reference Policy
Interaction summary
  • SHALL support read, search-type.

Supported Profiles

Observation - CIED Connectivity

Search Parameters
ConformanceParameterTypeDocumentation
SHALLcodetoken
SHOULDsubjectreference
SHOULDcomponent-value-concepttoken