This page is part of the FHIR Specification (v0.5.0: DSTU 2 Ballot 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

2.15.5.0 Structured Data Capture (SDC) Implementation Guide

This implementation guide is intended to support clinical systems in the creation and population of forms with patient-specific data. It defines a mechanism for linking questions in forms to pre-defined data elements to enable systems to automatically populate portions of the form based on existing data, either locally or by invoking an operation on a third-party system.

This implementation guide is prepared as a U.S. Realm Specification on behalf of the Structured Data Capture - 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.

2.15.5.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)

2.15.5.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
• QuestionnaireAnswers 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 Answers 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 Data Element Registry - Repository for data elements
  • 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

2.15.5.0.3 Pre-population service

The Questionnaire resource defines a custom operation called populate. This operation supports generating a "blank" QuestionnaireAnswers 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, subject and content
• Support content parameters consisting of a Binary resource containing a C-CDA document
• Populate the returned QuestionnaireAnswers 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

Systems supporting the populate operation SHALL be able to use 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.

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, CCDA document or other data source.

Mapping to CCDA, 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 CCDA is one of many options, not the only one.