Structured Data Capture

Summary

The Structured Data Capture (SDC) Profile provides an infrastructure for capturing, exchanging and using patient data within electronic health record (EHR) systems for clinical research, adverse event reporting and public health reporting. The utility of EHR data for supplemental purposes has been limited due to a lack of uniformity in the terminology and definitions of data elements across EHRs. This limitation is compounded by the fact that in a typical clinician workflow patient information is often recorded in an unstructured free-text format well after the episodes of care.

The SDC Profile provides specifications to enable an EHR system, or other application, to retrieve a structured data capture form and submit data from a completed form. The SDC Profile utilizes transactions from the IHE ITI Retrieve Form for Data Capture (RFD) Profile and an ISO/IEC 19763-13 based form definition, for requesting and receiving forms, and submitting data captured in forms in a standardized and structured format.

The Structured Data Capture Implementation page provides additional information about implementing this Profile.

Following is a visual conceptualization of the SDC workflow.

Benefits

Health care providers and others use various sources and methods to capture and synthesize patient-level data, EHRs have been recognized as the data source with the highest potential to provide timely and relevant data in a form that is quickly usable for quality and safety improvement, population health, and research (sometimes labeled "secondary" use or "reuse"). EHR data obtained during episodes of care will become increasingly valuable to healthcare organizations striving to leverage electronic information to drive efficiency and quality. Of particular interest are efforts to leverage clinical data captured during episodes of care and link the clinical data to supplemental data collected for other purposes including: 1) clinical research, 2) patient-safety event reporting, 3) public health reporting, and 4) determination of coverage. Once captured, aggregated and analyzed, these combined data can be used to identify trends, predict outcomes and influence patient care, drug development and therapy choices. Linking EHR data with other data in a uniform and structured way could accelerate quality and safety improvement, population health and research.

The SDC profile is a standard for exchanging structured data, whether it is used for a clinical trial, determination of coverage, or to report on a patient safety event, which can be collected in a timely manner, then readily compared and aggregated improving the overall quality, value and utility of these data. The identification and harmonization of standards for structured data capture within EHRs will not only help achieve this vision, but they will also help to:

• Reduce data collection burden on health care providers by enabling secure, single-point data entry that populates to multiple systems
• Decrease the need to make site-specific modifications to EHR system capabilities to enable participation in important reporting and research activities
• Lower the barriers to volunteer adverse event reporting on medical products to public health agencies leading to improvements in population health

Details

SDC profile defines the “question/answer set” (QAS) or Data Element (DE) content and structure of a Data-Entry Form (DEF) in a technology-agnostic XML format. SDC XML uses an XML Schema to define an XML-based information model that represents a generic DEF with generic DEs and related metadata. Rather than have an XML Schema for each form, SDC uses a single XML Schema that can be used to define an infinite number of different DEFs.

The SDC initiative has developed and validated a standards-based data architecture so that a structured set of data can be accessed from EHRs and be stored for merger with comparable data for other relevant purposes to include:

• The electronic Case Report Form (eCRF) used for clinical research including Patient Centered Outcomes Research (PCOR)
• The Incident Report used for patient safety reporting leveraging AHRQ ‘Common Formats’
• The Surveillance Case Report Form used for public health reporting of infectious diseases
• The collection of patient information used for determination of coverage, as resources permit.
• The electronic Cancer Checklists (eCC)
• The electronic Radiology Procedure Report Form used for patient procedure reports in cancer imaging.

The IHE SDC Use Case focuses on the functionality and interoperability required to allow a Provider to retrieve a form/template, auto-populate data within the form (when this functionality is implemented in the EHR system), enter additional data into the form/template, and transmit the form/template to an External Data Repository in a standard format. The standard format could be used as a means to provide data to end users. Optionally, data captured may be stored in the EHR associated with the individual patient and encounter as part of the permanent medical record.

Systems Affected

Systems involved in this profile are:

• EHR systems and Enterprise-wide information systems may find SDC an effective format to provide patient data.
• Departmental information systems may find SDC an effective format to provide data to end users and registries.
• Web application developers may find the standardized data capture within SDC to provide a clear direction for integration with a variety of data sources

Actors & Transactions:

SDC Actors

There are four primary actors in the SDC ecosystem, each of which performs different interdependent functions:

• 1. Form Manager (FM) store the structured forms/templates in a repository and transmits the form/template immediately in response to a request from Form Filler (FF). When supported, the FM can pre-populate the data from the C-CDA document received from the Form Filler and respond with partially-filled form/template rather than an empty one.
• 2. Form Filler supports following functions:
  • a. Retrieve a form/template from a Form Manager
  • b. Render the SDC XML form definition as a DEF using any convenient programming languages and methodologies. For example, the SDC XML form definition may be rendered (transformed) as an HTML web page using the XSLT language
  • c. Capture and validate the user-entered responses
  • d. Implement implicit and explicit rules that define the behaviors/actions of the forms in response to user interaction, and
  • e. Store and/or transmit the captured response data contained inside the original form/template. SDC response data is transmitted to one or more actors called Form Receiver (FR).
• 3. Form Receiver receives the SDC response data from the Form Filler and process the data according to the FR’s needs. FRs are responsible for storing the captured SDC data as native SDC XML and/or “shredded” into some other storage format.
• 4. Form Archiver is responsible for archiving the form instance data as submitted by the FF.

Specification

Profile Status: Trial Implementation

Documents: IHE QRPH SDC Supplement

Underlying Standards:

• HL7
• ISO/IEC 19763-13
• Hypertext Transfer Protocol - HTTP/1.1
• Hypertext Transfer Protocol - HTTP/2
• Uniform Resource Identifier (URI): Generic Syntax
• The application/json Media Type for JavaScript Object Notation (JSON)
• Additional HTTP Status Codes

See Also

Related Profiles

This supplement also references the following documents. The reader should review these documents as needed:

• IT Infrastructure Technical Framework Volume 1
• Retrieve Form for Data Capture (RFD) Integration Profile
• Audit Trail and Node Authentication (ATNA) Integration Profile
• Consistent Time (CT) Integration Profile
• Cross-Enterprise User Assertion (XUA) Integration Profile
• IT Infrastructure Technical Framework Volume 2b
• W3C SOAP
• OASIS SAML
• ISO/IEC 11179-3:2013 Metadata Registries - Part 3 Registry metamodel and basic attributes
• ISO/IEC CD 19763-13 Metamodel for Forms Registration
• Optionally, the QRPH Clinical Research Document (CRD) Trial Implementation Supplement for the definition of Audit Log message content and the [QRPH-36] transaction
• HL7® CDA® R2 and other standards documents referenced in Volume 1 and Volume 2
• IETF HTTPS and TLS v1.0 standard

Implementer Information

The Structured Data Capture Implementation page provides additional information about implementing this Profile.

Introduction to Structured Data Capture Recording