Protocols for Clinical Registry Extraction and Data Submission (CREDS) IG
1.0.0 - STU1 United States of America flag

This page is part of the Protocols for Clinical Registry Extraction and Data Submission (CREDS) IG (v1.0.0: STU1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Home

Official URL: http://hl7.org/fhir/us/registry-protocols/ImplementationGuide/hl7.fhir.us.registry-protocols Version: 1.0.0
Active as of 2023-11-14 Computable Name: FHIRRegistryProtocolsIG

About This Guide

The IG demonstrates a process and workflow to support the needs of clinical registries to define how registry submissions can be automatically extracted from multiple data sources and combined into a registry submission. It profiles the definitional resources needed to collect data and construct a registry submission using existing FHIR resource profiles.

An example, included in this Implementation Guide, is the American College of Cardiology CathPCI registry. This registry uses a large (375+) number of items collected from a patient’s current and historical record. Currently that information has to be manually entered into a data form. The CREDS system converts the Excel-based data structure into a FHIR StructureDefinition, with data elements that outline possible queries expressed as FHIRPath, that allow for automated query of the data that may be stored in FHIR, CDA or HL7 V2. The application can query for the data and then prompt for those data elements that were not found. This data is then bundled and uploaded, automatically, to the registry for verification.

Organization of This Guide

This guide is organized into four main sections:

  1. Introduction and Scope - General introduction to the CREDS use case.
    1. Overview - Provides an overview of the challenges this effort is trying to address.
    2. Use Cases - Illustrates key use cases.
  2. Architecture - Illustrates the conversion steps and transactions
    1. Technology Environment - Describes the technology environment for uninitiated.
    2. Security Considerations - Documents security concerns and mitigations.
    3. Actors - Provides an overview of technical components.
    4. Profiles - FHIR Resource Profiles created by this IG.
  3. Transactions
    1. Search / Retrieve Registry Definition
    2. Create / Update Registry Definition
    3. Retrieve Registry Submission Data
    4. Create / Update Registry Submission
    5. Validate Registry Submission
  4. Test Plan - Testing for a conformant system.
    1. Conformance - Conformance requirements.

Click on any of the links above or refer to the table of contents, or if you are looking for a specific artifact, refer to the index.

You can also download:

The source code for this Implementation Guide can be found on https://github.com/HL7/fhir-registry-protocols-ig.

CREDS and Content IGs

CREDS focuses on providing healthcare provider organizations information on how to collect the data needed to submit to registries. This may include but is not limited to data sources such as EHRs, HIEs and other sources using FHIR, HL7 CDA documents, and HL7 V3 messages that are not available via FHIR APIs.

Other content IGs such as MedMorph and UDS+ specify the use of standard FHIR APIs to collect data from EHRs and potentially other systems and exchange with systems that can receive data in FHIR format. This IG can support multiple use cases through content IGs, including but not limited to case-based surveillance, registry reporting, national health care surveys, and research.

Use cases that need to obtain data not available via FHIR APIs should consider the use of CREDS. Once there is a CREDS FHIR bundle, the MedMorph or UDS+ profiles could be used for transport.

While this implementation guide and the underlying FHIR are licensed as public domain under the FHIR license. The license page also describes rules for the use of the FHIR name and logo.

This guide includes examples making use of terminologies such as LOINC, SNOMED CT and RxNorm codes that have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and any other constraints of terminologies, questionnaires, and other components used as part of their implementation process. In some cases, licensing requirements may limit the systems that data captured using certain Definitions may be shared with.

This publication includes IP covered under the following statements.