Declaring Conformance

Conformance Artifacts

The Conformance Requirements page outlines conformance requirements and expectations for the CA:FeX Server and Client applications. In addition, the CA:FeX Server CapabilityStatement identifies the specific RESTful interactions and searches that need support.

Conformance Patterns

There are three different ways to implement CA:FeX:

  • Interaction Only Support: Systems may support only the RESTful interactions for the listed resources
  • Profile Only Support: Systems may support only the CA:FeX Profiles to represent clinical information.
  • Profile Support + Interaction Support: Systems may support both the CA:FeX Profile content structure and the RESTful interactions defined for a resource.

Note: At the time of this release, profiles have not been established for CA:FeX to leverage. Early implementers are expected to incorporate the interaction requirements in order to claim conformance to CA:FeX 2.1.0 DFT-preBallot.

Declaring Conformance

Systems (or implementation guides) complying or claiming conformance with the CA:FeX Specification at this time can declare conformance through the use of indicators in CapabilityStatement.Instantiates or CapabilityStatement.ImplementationGuide. Details are provided below to guide implementers in selecting the right method for their implementation.

If a system supports all CA:FeX requirements (particularly textual requirements around interoperability behaviors and security), it is compliant with the full scope of the CA:FeX Implementation Guide. In this case implementationGuide element should be used to provide a more comprehensive view of the system's capabilities and reflect this compliance. However, if a system supports only some of CA:FeX's requirements (particularly requirements expressed in the CapabilityStatement), the system instantiates CA:FeX since it supports subsets of CA:FeX.

CapabilityStatement.Instantiates

Declares conformance with CA:FeX by including its official URL in the server's CapabilityStatement.instantiates element, as shown below: CapabilityStatement-fragment The system may actually implement a subset of the capability statement it claims to implement, so the capability statement must specify the full capability details. It is often used to indicate that the system conforms to a specific profile or set of profiles defined in 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.