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

B.0 Structured Data Capture (SDC) Implementation Guide

The SDC specification provides an infrastructure to standardize the capture and expanded use of patient-level data collected within an EHR.

This includes two components:

• Support more sophisticated questionnaire/form use-cases such as those needed for research, oncology, pathology and other clinical domains.
• Support pre-population and auto-population of EHR data into forms/questionnaires for uses outside direct clinical care (patient safety, adverse event reporting, public health reporting, etc.).

A third component – defining standards for the sharing of common data element definitions between registries to enable broader and more consistent data element use is addressed in a second companion implementation guide.

This implementation guide is 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 workflow, constraints and extensions used should all have broad applicability.

B.0.1 Background

• Introduction - How this project came to be and what it is trying to achieve
• Security - Security and privacy rules and considerations
• Project wiki containing development materials and discussions (for additional background)

B.0.2 Specification

The SDC FHIR Implementation Guide is based on the HL7 FHIR standard. Readers of this specification should familiarize themselves with the FHIR specification, including its notions around the use of resources, extensions, bundles, conformance rules, etc. The Overview is probably a good place to start.

This specific profile makes use of the following resources:

• DataElement is used to define data elements that can be referenced in questionnaires and can be used to auto-populate form data
• Questionnaire is used to define form definitions that may be downloaded for manual and/or automatic population
• QuestionnaireResponse is used to share instance data captured using questionnaire forms
• ValueSet is used to define allowed values for data elements and for questions in questionnaires

Additional resources such as Patient, Practitioner, Provenance, AuditEvent and others are also likely to be used in SDC solutions, though no SDC-specific profiles have been created for them. Basic aspects of the FHIR protocol, including RESTful operations, data types, search, etc. also apply.

The SDC specification consists of the following components:

• SDC profiles - Profiles on the four FHIR resources used to support the IG requirements:
  • SDC Data Element (DE) Profile - Constraints and extensions for capturing data elements
  • SDC Questionnaire Profile - Constraints and extensions for capturing form designs
  • SDC Questionnaire Response Profile - Constraints and extensions for capturing form data instances
  • SDC Value Set Profile - Constraints and extensions for defining lists of allowed codes
• Pre-population Operation - The definition of the custom service that allows pre-population of forms based on CDA and other data sources
• Conformance statements - Definitions for the expected capabilities of each of the actors involved in supporting SDC functionality:
  • SDC Form Designer - System responsible for creating and editing forms
  • SDC Form Filler - System responsible for capturing user form input
  • SDC Form Manager - Repository for form definitions. May also perform pre-population
  • SDC Form Receiver - Repository for completed forms

When looking up data elements, the SDC Form Designer will communicate use of the SDC Data Element Registry, which is defined in the SDC Data Element Exchange implementation guide.

B.0.3 Pre-population service

The Questionnaire resource defines a custom operation called populate. This operation supports generating a "blank" QuestionnaireResponse instance based on a specified Questionnaire. It also allows for the returned questionnaire to be partially or even fully completed based on data passed in to the operation or data already available to the server on which the operation is invoked.

For SDC purposes, server systems claiming to support roles that require support for the populate operation (SDC Form Manager) SHALL, at minimum:

• Handle the input parameters identifier, questionnaire, questionnaireRef, subject and content
• Support content parameters consisting of a Binary resource containing a C-CDA* document
• Populate the returned QuestionnaireResponse instance for all questions referencing DataElements that are mapped to C-CDA content

Similarly, client systems claiming to support the populate operation (SDC Form Filler) SHALL, at a minimum:

• Be capable of invoking the operation on a selected questionnaire both directly (Questionnaire/[identifier]/$populate) as well as indirectly either by identifier or questionnaire
• Support passing a single C-CDA* document as a Binary resource using the content parameter

* While C-CDA is the focus for compliance with this release of the SDC specification, systems are encouraged to support additional formats. Candidates for mandatory support in future versions of this implementation guide include the Clinical Documents for Payors - SET 1 (CPD1) and Physician Reporting to a Public Health Repository specifications.

Systems supporting the populate operation are encouraged to support using the deReference extension to trace the linkage from Questionniare question to DataElement to support mapping. As well, systems may also choose to support the use of the deMap extension to support maintaining of question <-> data element links outside the questionnaire itself. If using this approach, the ConceptMap.sourceUri equal to the full resource id of the Questionnaire and a targetUri of the base URL for the DataElement end-point of the server to which data elements will be mapped. The ConceptMap.element.code and ConceptMap.element.map.code will correspond to the question linkId and the data element local id, respectively. Support for alternative mechanisms including ConceptMaps directly from Questionnaire questions to data sources, Questionnaire extensions providing mappings direct to data sources or use of Questionnaire.group.question.concept are all acceptable mechanisms for executing populate functionality.

IMPORTANT:

Not all DataElements will be appropriate or safe to reference in a Questionnaire. It is important that the definition associated with the data element fully reflects the context of the question in the questionnaire. For example, "gender" would not be a safe data element because it would not be clear whether the gender was that of the patient or a fetus of the patient. It must be clear from the data element definition exactly what piece of information should be extracted from a source system, C-CDA document or other data source.

Mapping to C-CDA, where applicable, should be constrained and specific (e.g. for particular demographic sections) rather than making it open and generic. These mappings should be per ONC's recommendations. Mapping to C-CDA is one of many options, not the only one.

B.0.4 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.