Problem:  There are ecosystem and infrastructure barriers that prevent the wide-scale adoption and deployment of FHIR for payers and providers.

Purpose: Through a collaborative effort, the taskforce aims to address ecosystem barriers and accelerate adoption of FIHR for production exchange of clinical information between providers and payers.  

Scope Statement:  The Testing and Certification Tiger Team will focus on process and specifications for testing and certification of the requirements defined to meet the core competencies of identity, security, Endpoint discovery, scaling and exchange process.

Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test.

Certification refers to the confirmation of certain characteristics of an object, person, or organization.

Testing and Certification should be decoupled as a matter of practicality. Waiting to test late in the software development cycle - i.e. at certification time - reveals bugs which are exponentially more expensive to fix than if they had been discovered and addressed prior to building on top of the bug. It is important that developers of FHIR-based systems are empowered with test scripts and tooling that enable them to meet the requirements of FHIR certification as they first begin to write software, otherwise re-development involved with passing certification requirements becomes a barrier to entering or remaining in the market. Most importantly, it delays the potentially life-saving benefits of those systems participating in the market for the benefit of patients. FHIR certification must be a process in which requirements that are well established and broadly shared can be absolutely confirmed.

Supporting continuous interoperability at the ecosystem level (i.e.. all stakeholders interoperating effectively) will require proficiency at each of three levels. Baseline FHIR, FHIR at Scale, and Industry Use Case Implementation Guides.

Baseline FHIR:

A prerequisite to using FHIR at Scale is the ability to demonstrate basic FHIR Conformance. Systems can only claim FHIR Conformance for functionality described in the applicable CapabilityStatement. To provide details about specific usage of the frameworks and resource contents, FHIR provides a conformance layer that implementers, national/regional programs, and other profiling organizations such as IHE, can use to provide a computable statement about how the resources and their exchange paradigms are used to solve particular use cases. The conformance layer itself is implemented using the following key resources:

Value Set

Defines a set of coded values (see "Using Codes" for more details)

StructureDefinition

Makes rules about how a resource (or type) and its data elements are used in a particular context, including defining how extensions are used.

 A structure definition references value sets for the coded elements in a resource

CapabilityStatement

A statement of the kinds of resources and operations provided and/or consumed by an application. The Capability Statement references profiles to describe specific use of resources by the application

Implementation Guide

A single coherent collection of capability statements, profiles, extensions, value sets, and documentation describing a set of interoperable applications


FHIR at Scale:

In order to assure scalability, the FHIR at Scale Task Force (FAST) will develop requirements around core competencies in each of the following areas: ecosystem, identity, directory, security, and exchange process.

Core capability requirements need to be identified and documented in an implementation guide – like process where they are vetted with the community. The core capability requirements will become the metrics for FAST testing and certification. It is not clear at this time whether the Core Capabilities will become computable FHIR Implementation Guides or requirements documented and validated in a different way.

A prerequisite to testing and certifying FAST core capability requirements and FHIR Implementation Guides is verification of competency against baseline FHIR. This can be accomplished using existing FHIR validation tools known as conformance resources.

A system can only claim FHIR Conformance for functionality described in the applicable CapabilityStatement. To provide details about specific usage of the frameworks and resource contents, FHIR provides a conformance layer that implementers, national/regional programs, and other profiling organizations such as IHE, can use to provide a computable statement about how the resources and their exchange paradigms are used to solve particular use cases.

Core capability conformance requirements should be vetted with authors of FHIR Implementation Guides. The process of developing the FHIR Implementation Guide may identify more ecosystem and scalability gaps that need to be included in the FAST core capabilities.


FHIR Implementation Guides:

An implementation guide (IG) is a set of rules about how FHIR resources are used (or should be used) to solve a particular problem, with associated documentation to support and clarify the usage. Classically, FHIR implementation guides are published on the web after they are generated using the FHIR Implementation Guide Publisher.

The Implementation Guide resource is a single resource that defines the logical content of the IG, along with the important entry pages into the publication. The logical package of the IG represents the computable contents.

In particular, validation tools are able to use the Implementation Guide resource to validate content against the implementation guide as a whole. The significant conformance expectation introduced by the Implementation Guide resource is the idea of Default Profiles. Implementations may conform to multiple implementation guides at once, but this requires that the implementation guides are compatible.


Project Deliverables

  1. Certification Program Plan
    1. Frequency of re-certification of API if applicable i.e., annually, every 2 years etc.
  2. Testing assertions document based on Use Case Team Requirements
  3. Tooling Requirements





Project Plan with Timeline

  • No labels