This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions
The Structured Data Capture (SDC) Initiative seeks to link clinical data, captured within the Electronic Health Record (EHR) system during clinical encounters, to supplemental systems that collect structured patient data within forms. For example, consider a clinician treating a patient who is participating in a clinical trial or comparative effectiveness research (CER). First, the EMR displays the electronic case report form (eCRF) to the clinician through the EHR user interface. Some information in the eCRF would be automatically populated with current data derived from the EMR, and the remainder of the form's data would be entered in response to standardized questions posed by the eCRF. The eCRF data will be captured in a structured form, and ultimately aggregated and transferred to end users as required for the particular use case.
SDC requires that the question/answer (data element) structure of EMR forms be specified in a standardized, interoperable and reproducible way. As a consequence, SDC requires the definition of metadata for forms and data elements, in a manner relevant to EHRs and entities using EHR data. Therefore SDC aims to leverage synergistic government and health care industry efforts underway related to standards definition, and representation to facilitate capture, reporting, and analysis. The standards and guidance incorporated into this implementation guide are based on the requirements defined in the Structured Data Capture Initiative Standards and Interoperability Framework Use Case document. Users of this implementation guide will benefit greatly from review of the SDC Use Case document.
The Structured Data Capture (SDC) Initiative identifies and recommends standards for the interoperable representation and transmission of the following:
The use cases for SDC interaction specifications are:
Where applicable, this implementation guide addresses data transmission security, limitation of access to appropriate personnel, data integrity, accountability, and adherence to suitable well-accepted informatics and networking standards.
The generic SDC workflow is pictured in Figure 1.
Figure 1: Generic Workflow
Note: The diagram depicts the optional storage of the completed form by the EHR. This can occur when the EHR stores a copy of the form as they send it to the External Data Repository or by the external data repository returning a copy of the form to the sender who can store an internal version of the form.
This implementation guide provides guidance on the use of Fast Healthcare Interoperability Resources (FHIR) Profile(s) for SDC using the new DataElement resource and on the existing Questionnaire and QuestionnaireAnswers resources. The profiles in this implementation guide will be used to meet SDC project objectives of:
This implementation guide provides implementers with guidance on how to achieve conformance with the standards recommended by the Office of the National Coordinator for Health Information Technology (ONC) Standards & Interoperability Framework (S&I), SDC Initiative.
The implementation guide will explain how the 4 resources (using the defined profiles) can be used to support auto-population of forms and data extraction. It will also describe secure interaction specifications using Representational State Transfer (REST) services to allow access, display, populate and saving of the resources.
For this project, Data Element (DE) is defined as a named (identified) definition for a single piece of data (e.g. systolic blood pressure). The new DataElement resource defines a common syntax based on ISO/IEC 11179-3 to allow unambiguous interpretation of DEs. The syntax is bound to controlled terminologies such as SNOMED CT, LOINC and RxNorm where appropriate.
The SDC profiles on the resources will identify the resource elements and extensions that must be supported to meet SDC use cases as well as constraints on their use.
Out of scope for this implementation guide: