Conformance Requirements

Conformance Patterns

For implementing CA:FeX, implementers must claim to be at least one Actor and one of their available Options, then implement associated Transactions and expectations found in the CapabilityStatement:

Declaring Conformance

Systems (or Implementation Guides) that implement CA:FeX can declare their level of conformance using the CapabilityStatement.instantiates or CapabilityStatement.implementationGuide elements:

• Use **implementationGuide** when the system complies with the full scope of CA:FeX, including both technical capabilities and broader expectations such as data sharing behavior, privacy, and security considerations.
• Use **instantiates** when the system supports a subset of CA:FeX requirements, as defined in one or more CapabilityStatements.

These indicators help clarify the extent to which a system aligns with CA:FeX and assist others in understanding its role and capabilities within a broader exchange environment.

CapabilityStatement.Instantiates

Declares conformance with CA:FeX by including the official URL of the applicable CA:FeX CapabilityStatement in the system's CapabilityStatement.instantiates element, as shown below:

The declared CapabilityStatement must represent the full set of behaviors, interactions, and expectations for the actor and option the system claims to support. This element is commonly used to signal conformance with a specific interaction pattern or role defined within an implementation guide.

CapabilityStatement.ImplementationGuide

Communicates compliance by referencing the canonical CA:FeX URI in its implementationGuide element. This indicates that systems do (or should) support CA:FeX in entirety (compliant to CA:FeX by requiring all that CA:FeX requires).

Reference Implementations

FHIR reference implementation (RI) is a software implementation of the FHIR standard that serves as a reference or starting point for developers who are building their own FHIR-based systems. It typically includes a FHIR server, client libraries, and tools, as well as sample resources and example code, and is designed to be flexible and extensible. Reference implementations include a range of testing tools, such as web-based clients for querying and updating FHIR resources, and APIs for accessing FHIR data. These tools provide a platform for testing and development that help ensure compliance with the standard.

When CA:FeX implementers are setting up their own servers these RIs can act as a guide by providing pre-built configurations and settings that can be used as a starting point. There are industry recognized reference implementations that can provide a working example of a FHIR server, such as:

• HAPI FHIR: HAPI FHIR is a popular open-source FHIR server and client framework for Java. It supports all FHIR resource types and can be used to create custom FHIR implementations. HAPI FHIR also provides a RESTful API for accessing FHIR resources.

• Firely Server: Firely Server is an open-source FHIR server built on the .NET platform. It supports all FHIR resource types, has a built-in FHIR validation engine, and includes a web-based FHIR client for testing.

• Microsoft FHIR Server for Azure: The Microsoft FHIR Server for Azure is an open-source FHIR server built on the Azure cloud platform. It provides support for FHIR R4 and STU3, as well as a range of security features, including Azure Active Directory authentication and encryption of data at rest.

• Aidbox: Aidbox is a cloud-based FHIR server that provides a range of features, including support for FHIR R4 and STU3, advanced data management and search capabilities, and built-in security features. It also includes a web-based FHIR client for testing and debugging.

• FHIRbase: FHIRbase is an open-source FHIR server built on PostgreSQL. It provides full-text search, versioning, and transaction support, and supports all FHIR resource types.