This page is part of the FHIR Specification (v1.0.2: DSTU 2). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

C.0 Structured Data Capture (SDC) - Data Element Exchange Implementation Guide

This implementation guide is a supplement to the base Structured Data Capture (SDC) implementation guide. It defines expectations for Data Element registries, as well as those systems that are responsible for the creation and maintenance of data elements within those registries. This capability is documented as a distinct implementation guide because the expectations for systems creating and maintaining data elements are higher than for those systems that are merely responsible for referencing data elements when creating forms or configuring their systems to support pre-population or auto-population.

The set of expectations described within this implementation guide reflects the consensus view of those stakeholders involved in the Structured Data Capture public consultation group, which included representatives from several large organizations responsible for data element registries, including:

• The US Federal Drug Administration (FDA)
• The US National Cancer Institute (NCI)
• The US National Library of Medicine (NLM)
• The College of American Pathologists (CAP)

This implementation guide is intended to be conformant with the ISO/IEC 11179-3 standard, though it only defines (and requires support for) only a subset of the properties defined in that specification.

This implementation guide was prepared as a U.S. Realm Specification on behalf of the Structured Data Capture project - an effort under the U.S. Office of the National Coordinator (ONC) 's Standards and Infrastructure (S & I) Framework However, much of the content is likely to be useable in other jurisdictions. The only portions of this specification that may be problematic for use of this implementation guide in some jurisdictions are the bindings to terminologies such as SNOMED CT and RxNorm. The constraints and extensions used should all have broad applicability.

C.0.1 Navigation

This implementation guide follows the FHIR pattern of being published as a web-based specification. This allows easy navigation between the SDC-specific portion of the implementation guide and the resources, data types, value sets and other specification components leveraged from the FHIR core specification. This approach also allows implementers to easily navigate to the information needed to perform a particular task.

A Table of Contents page is provided that lists all of the pages and artifacts defined as part of this implementation guide. (Do be aware that some pages have multiple tabs.) A table of contents is also available for the full FHIR specification if you really want to read absolutely everything. Tooling may provide support for a PDF or other document-approach representation of this implementation guide in a future release.

Bread-crumb navigation is provided in the gray bar just below the menu at the top of each page, allowing easy navigation back to the main SDC page.

This implementation guide has a number of sections:

• Understanding FHIR should be read by those who are not familiar with FHIR as a pre-requisite to reading the rest of the implementation guide
• Background provides links to background and implementation information including security guidelines and the SDC wiki
• Conformance Statements describes the different roles systems wishing to conform to this implementation guide can take on and summarizes how those roles interact.
• Resources describes the resources used as part of this implementation guide, including profiles placed on those resources to constrain and extend their capabilities.
• ISO 11179 relationship provides an overview of how the resource profile maps to the ISO 11179 specification
• Intellectual Property Considerations provides information about intellectual property referenced by this implementation guide

C.0.2 Understanding FHIR

This implementation guide is based on the HL7 FHIR standard. It uses terminology, notations and design principles that are specific to FHIR. Before reading this implementation guide, it's important to be familiar with some of the basic principles of FHIR as well as general guidance on how to read FHIR specifications. Readers who are unfamiliar with FHIR are encouraged to read (or at least skim) the following prior to reading the rest of this implementation guide.

• FHIR overview
• Developer's introduction
• (or Clinical introduction)
• FHIR data types
• Using codes
• References between resources
• How to read resource & profile definitions
• Base resource
• RESTful operations
• Search

Feel free to explore other aspects of the FHIR specification that you feel may be relevant or of interest.

C.0.3 Background

DataElement instances do not convey patient-specific information. However, because the mappings associated with data elements can influence the data that might be automatically populated into forms and could also influence the security controls around data associated with the DataElement, security precautions should be taken to ensure that data elements are not created or revised by someone without the proper authority. Security practices for systems complying with this implementation guide are the same as those for the primary SDC implementation guide.

Additional information about the Structured Data Capture project can be found on the project's wiki .

C.0.4 Specification

The following sections describe the artifacts that set expectations for systems wishing to be conformant to the FHIR SDC implementation guide.

C.0.4.1 Conformance Statements

FHIR Conformance statements define the expectations for particular system "roles" within an SDC environment. To be considered SDC-conformant, a system must adhere to the requirements defined by at least one of these statements. Some systems might choose to comply with more than one.

• SDC Data Element Registry - Repository for data elements
• SDC Data Element Curator - System responsible for creating and updating data elements

Systems supporting the SDC Data Element Registry role SHALL be capable of accepting, persisting and returning all DataElement properties marked as "must support" in the SDC Data Element Exchange profile. Systems supporting the SDC Data Element Curator role SHALL be capable of providing and updating those same properties.

C.0.4.2 Resources

This implementation guide defines profiles on several resources. Implementations are expected to be conformant with these profiles in order to be conformant with this implementation guide.

Additional resources such as ConceptMap, Provenance, AuditEvent and others are also likely to be used in SDC solutions, though no SDC-specific profiles have been created for them.

C.0.5 ISO 11179 Relationship

ISO 11179 is one of the principle authorities on the notion of "Data Element". For a complete view of the alignment between the SDC FHIR specification and ISO 11179, the FHIR profile on DataElement includes mappings to the ISO 11179 specification for each of the core elements and extensions of the resource. As a summary, the FHIR DataElement resource can express most (all, if additional extensions are introduced) of the notions present in 11179, however the approach differs in a few ways:

• FHIR does not define separate resources for the Data Element vs. the Data Element Concept. Both notions can be represented using the same structure and both conceptual and conceptual domain and value domain aspects can be represented within a single instance.
• FHIR uses ValueSets to represent both permissible values and value meanings (and allows the sets to be defined by expression rather than only by enumeration)
• The notions of Object_Class and Property are considered to be just one possible model for defining the meaning of a given element

C.0.6 Intellectual Property Considerations

While this implementation guide and the underlying FHIR are licensed as public domain, this guide mandates the use of terminologies including LOINC, SNOMED CT and RxNorm which have more restrictive licensing requirements. Implementers should make themselves familiar with licensing and any other constraints of terminologies, questionnaires, data elements and other components used as part of their implementation process. In some cases, licensing requirements may limit what systems data captured using this implementation guide may be shared with.