Supported Implementation Guides

All of the following FHIR Implementation Guides have been verified by Firely to work out-of-the-box with Firely Server. Conformance to these Implementation Guides, more specifically their corresponding Capability Statements, is usually listed in CapabilityStatement.instantiates.

SMART App Launch

The SMART App Launch Implementation Guide facilitates the integration of third-party applications with Electronic Health Record data, enabling their launch from within or outside the EHR system’s user interface. It offers a robust and secure authorization protocol for various app architectures, accommodating both end-user device-based apps and those operating on a secure server, accessible to clinicians, patients, and others through PHRs, Patient Portals, or any FHIR system.

This implementation guide does not specify any FHIR conformance resources and provides textual guidance only.

SMART App Launch Overview

Supported version

Supporting documentation

Realm

Package Link

  • ✔️ v1.0.0

  • ✔️ v2.0.0

  • ✔️ v2.1.0

  • ✔️ v2.2.0

  • 🌍

Known Limitations

  • No dedicated support for User-access Brands and Endpoints

  • No dedicated support for SMART App State Persistence


Bulk Data Access

The FHIR Bulk Data Access Implementation Guide is designed to facilitate the seamless exchange of large-scale healthcare data. This IG offers comprehensive guidelines and specifications for accessing and sharing bulk data, enabling healthcare organizations and researchers to efficiently retrieve, process, and analyze vast amounts of patient information.

This implementation guide does not specify any FHIR conformance resources and provides textual guidance only.

Bulk Data Access Overview

Supported version

Supporting documentation

Realm

Package Link

  • ✔️ v1.0.1

  • ✔️ v2.0.0

  • 🌍

Known Limitations

  • The includeAssociatedData and _typeFilter parameters are not supported during the BDE kickoff request on system-, group-, and patient-level.


Basic Audit Log Patterns

The Basic Audit Log Patterns (BALP) Implementation Guide is a IHE Content Profile designed to establish fundamental and reusable patterns for AuditEvent logs in the FHIR. These patterns are intended for FHIR RESTful operations while focusing on the main objective to enable Privacy-centric AuditEvent logs that clearly indicate the Patient when they are the subject of the recorded activity.

BALP Overview

Supported version

Supporting documentation

Realm

Package Link

  • ✔️ v1.1.1

  • 🌍


USCDI & US Core

The United States Core Data for Interoperability (USCDI) is a standardized set of health data elements and their associated value sets. It serves as a foundational health data standard to support seamless and secure health information exchange across the healthcare ecosystem in the United States.

The US Core FHIR Implementation Guide is a set of implementation specifications and guidance to support the effective FHIR in the United States. The US Core FHIR Implementation Guide aligns with the USCDI, providing detailed instructions on how to implement the necessary FHIR resources and profiles to ensure consistency and interoperability with the USCDI’s data elements.

In summary, the USCDI defines the core health data elements for nationwide interoperability, while the US Core FHIR Implementation Guide complements it by offering practical guidelines and technical specifications for implementing FHIR to support seamless data exchange and improve care coordination within the US healthcare system.

USCDI Overview

Supported version

Supporting documentation

Realm

Specification Link

  • ✔️ v1 - based on US Core 3.1.1, US Core 4.0.0

  • ✔️ v2 - based on US Core 5.0.1

n/A

  • 🇺🇸

US Core Overview

Supported version

Supporting documentation

Realm

Package Link

  • ✔️ v3.1.1

  • ✔️ v4.0.0

  • ✔️ v5.0.1

  • ✔️ v6.1.0

n/A

  • 🇺🇸

Known Limitations

  • In order to validate resources claiming to conform to US Core, it is necessary to configure Firely Server to use an external terminology server incl. support for expanding SNOMED CT and LOINC ValueSets. See Terminology services.

  • Certain parameters are not implemented for the $docref operation on DocumentReference resources. See Fetch DocumentReference - $docref for more details.

  • US-Core Observation.code search parameter interferes with Firely Server’s handling of composite parameters. See this warning.

Test Data

Firely provides test data covering all US-Core profiles and all elements marked as Must-Support. In order to load all examples, two transaction bundles need to be posted against the base endpoint of Firely Server. The following Postman collection provides you with the bundles itself, and the bundle entries as individual PUT requests.

The following steps are necessary in order to execute the test collection against our own Firely Server instance:

  1. Select “Fork Collection” or “View collection” in the Postman dialog

    ../_images/Compliance_ForkTestCollectionPostman.png
  2. Sign-In with your Postman account

  3. Create a new Postman environment with a “BASE_URL” variable and adjust the URL to your server endpoint

    ../_images/Compliance_EnvironmentTestCollectionPostman.png
  4. Make sure that the newly created environment is selected as the active environment

  5. Open the collection “Firely Server - US Core Tests”

    ../_images/Compliance_USCoreTestCollectionPostman.png
  6. Execute the transaction request, the expected response is “HTTP 200 - OK”.


CPCDS & CARIN Blue Button

The CARIN Blue Button FHIR Implementation Guide is designed to facilitate the exchange of healthcare data between healthcare providers, payers, and patients. It enables a payor to provide secure access to a Common Payer Consumer Data Set (CPCDS) for a patient. API clients can hereby access, interpret and display the content of the data set.

The CPCDS includes a comprehensive set of health care data elements, such as claims and encounter data, enrollment and eligibility information, pharmacy data, and clinical data. By creating a common data format, the CPCDS facilitates the seamless sharing of health information across different payers and health systems, promoting interoperability and data-driven decision-making.

CARIN Blue Button Overview

Supported version

Supporting documentation

Realm

Specification Link

  • ✔️ v2.0.0

n/A

  • 🇺🇸

Known Limitations

  • FHIR ExplanationOfBenefits instances are not rejected if the claim conformance to the abstract “C4BB Explanation Of Benefit” profile

  • In order to validate resources claiming to conform to CARIN Blue Button, it is necessary to configure Firely Server to use an external terminology server incl. support for expanding SNOMED CT, LOINC, NUBC, CPT, ICD-10, NCPDP, X12 ValueSets. See Terminology services.

  • By default invalid values for a search parameter are not rejected by Firely Server with an HTTP 400 - Bad Request status code. To enable this behavior required by CARIN, include a “Prefer: handling=strict” HTTP header in the search request.

  • FHIRPath constraints using the “memberOf” function are not evaluated by Firely Server


Da Vinci - Member Attribution (ATR) List

The goal of Da Vinci - Member Attribution (ATR) List implementation guide is to enable providers to gain access to managed lists of all members (Patients) attibuted to their organization. Payors are responsible of managing these lists. Based on ATR lists, providers can retreive administrative information in bulk about all members. Additionally, ATR lists can serve as the basis to allow providers to access claims and encounter data.

Da Vinci - Member Attribution (ATR) List Overview

Supported version

Supporting documentation

Realm

Specification Link

  • ✔️ v2.0.0-ballot

n/A

  • 🇺🇸

Known Limitations

  • The custom operations $member-add and $member-remove are not supported. Therefore for all member updates, a new version of a Group resources is created.

  • The _until parameter is not supported as part of the Bulk Date Export operations.

  • The $davinci-data-export wrapper around $export is not supported.


ISiK

The “ISiK” FHIR implementation guide was developed by gematik (national agency for digital health in Germany). The specification defines specific implementation guidelines for the use of FHIR in the German healthcare system. The ISiK FHIR implementation guide aims to improve interoperability and the exchange of health data in Germany. It specifies which FHIR resources, profiles, and terminologies should be implemented to ensure a uniform and secure communication between different IT systems in the stationary healthcare sector.

ISiK Overview

Supported version

Supporting documentation

Realm

Package Link

  • ✔️ v1.0.7

n/A

  • 🇩🇪