This is the second STU release of the Structured Data Capture (SDC) implementation guide. A list of changes from prior releases can be found here. Other versions of the specification can be found in the FHIR.org IG registry.

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.

1.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 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. There's also an Artifact index that lists all artifacts defined within this implementation guide.

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, the SDC wiki and the use-cases driving the implementation guide
• Workflow describes the primary workflow associated with the SDC implementation guide
• Capability 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.
• Pre-population Service describes in detail how the pre-population mechanism is intended to work
• Intellectual Property Considerations provides information about intellectual property referenced by this implementation guide

1.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.

1.3 Background

The following links provide additional context for the SDC specification.

• 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)

1.4 Workflows

There are two primary workflows that fall within the scope of the SDC implementation guide - form creation/curation and form filling.

Figure 1: Form Curation Workflow

In form curation, the Form Designer interacts with both the Form Manager and the Data Element Registry to create, edit and update forms, including identifying and defining associated terminologies and data elements. This is an iterative process where an initial version is created and then subsequently updated and maintained, eventually changing status to active and later retired.

The more significant (and complex) workflow in SDC is to complete (and potentially submit) a completed questionnaire response.

Figure 2: Form Filling 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.

The driver of this workflow is the Form Filler system. It retrieves a form (Questionnaire) from the Form Manager. It may also request that the Form Manager generate an initial QuestionnaireResponse, potentially partially populated with information known by the Form Manager or supplied by the Form Filler. The Form Filler could generate the QuestionnaireResponse itself without the assistance of the Form Manager and in either case could partially fill in the response based on information known by the form filler.

When as much of the questionnaire response as possible has been filled in by automated means, the form is displayed to an end-user who reviews and edits the automatically populated content as well as completing those portions of the form that were not populated automatically. In some cases, the form may be stored locally or using a Form Response Manager to allow a user to stop and resume editing at a later point.

The Form Filler (possibly with help from the Form Manager) is responsible for verifying that a completed form is actually complete and valid against the corresponding Questionnaire. Once valid, the form filler submits the form to one or more target repositories (Form Receiver allows the completed form to be subsequently retrieved, Form Archiver does not) and/or stores the completed form itself. (Note - Form Receivers may perform validation on forms prior to consumption, Form Archivers typically will not.)

The pre-population process (done by the Form Manager) and the auto-population process (done by the Form Filler itself) can be done by a variety of means. If using data elements referenced directly within the questionnaire or mapped via ConceptMap, those may need to be retrieved from a Data Element Registry in order to look up what mappings the data element has to other resources.

1.5 SDC Specification

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

1.5.1 Capability Statements

FHIR Capability 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 Form Designer - System responsible for creating and editing form designs
• SDC Form Filler - System responsible for capturing user form input to produce partially or fully completed forms
• SDC Form Manager - Repository for form definitions. May also perform pre-population
• SDC Form Response Manager - Searchable repository for storage and retrieval of completed and partially completed forms.
• SDC Form Receiver - Write-only destination to which forms are sent for processing
• SDC Form Archiver - Write-only system responsible for archiving completed forms as well as works in progress

In addition to the above, there's another relevant role:
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.

A summary of how these roles interact can be seen in Figure 1 and Figure 2 above.

1.5.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.

SDC Profile	Based on FHIR Resource	Purpose
SDC Data Element (DE) Profile	DataElement	Used to define data elements that can be referenced in questionnaires and can be used to auto-populate form data
SDC Questionnaire Profile	Questionnaire	Used to define form definitions that may be downloaded for manual and/or automatic population
SDC Questionnaire Response Profile	QuestionnaireResponse	Used to share instance data captured using questionnaire forms
SDC Value Set Profile	ValueSet	Used to define collections of allowed values for data elements and for questions in questionnaires
SDC Code System Profile	CodeSystem	Used to define allowed values for data elements and for questions in questionnaires

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

For the purposes of this implementation guide, "must support" shall be interpreted as follows:

• Conformant systems SHALL be capable of sending and receiving the data element
• When a system persists a resource instance, all "must support" elements SHALL be persisted and retrieved with other elements
• Where an element affects the display or validation of a Questionnaire and a system performs either or both of those operations, the behavior established by the value of the element SHALL be performed

1.5.3 Pre-population service

The Questionnaire resource defines a set of custom operations to support generation of completed questionnaires, possibly automatically filling in some of the answers using existing system information. This could be information passed to the system on which the operation is invoked (as a CDA document, FHIR bundle or other recognized source) or using data the system already has locally. The three operations are as follows:

Operation	Description
populate	This operation supports generating a QuestionnaireResponse instance based on a specified Questionnaire. If matching data is available for any of the questions and the server supports the pre-population capability, the answers for those questions will be filled in the QuestionnaireResponse instance.
populatehtml	This operation produces an HTML web page as a Binary instance. The HTML page provides an interactive rendering of the form, using html-based controls to capture user inputs and scripting languages to support form validation and submission to the server that generated the form and/or the recipient(s) designated by the Questionnaire. If matching data is available for any of the questions and the server supports the pre-population capability, the form will initially render with the answers for those questions filled in.
populatelink	This operation returns a URL leading to an web page with an interactive rendering of the form that allows a user navigating to the link with a browser to complete and submit a response to the questionnaire. The response will be transmitted to the server generating the link, hosting the form and/or as designated as part of the Questionnaire itself. If matching data is available for any of the questions and the server supports the pre-population capability, the form will initially render with the answers for those questions filled in.

For SDC purposes, server systems claiming to support roles that require support for the populate, populatehtml or populatelink operations (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 or rendered form for all questions referencing DataElements that are mapped to C-CDA content

Similarly, client systems claiming to support the populate, populatehtml and/or populatelink operations (SDC Form Filler) SHALL, at a minimum:

• Be capable of invoking the operation(s) 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
• Be able to accept an incoming partially-populated QuestionnaireResponse and render it as if they had retrieved a saved partially-completed QuestionnaireResponse
• It is the responsibility of the SDC Form Filler to ensure the form is valid after a human has reviewed and edited the form.

* 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 Payers - SET 1 (CPD1) and Physician Reporting to a Public Health Repository specifications. Passing a Bundle of FHIR resources is also an option that has been used by at least some implementers.

Systems supporting one or more of the populate operations are encouraged to support using the definition element to trace the linkage from Questionniare question to DataElement or StructureDefinition element 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. More formal conversion between existing data sources and Questionnaires can be represented using StructureMap which allows the definition of fully computable mappings between a given source structure and target structure where either (or even both) structures can be a QuestionnaireResponses. The questionnaire-sourceStructureMap extension allows a Questionnaire to point to a StructureMap that can be used to populate it. The source structure mapped from could be a FHIR structure, but could also be any other data structure, including CDA documents.

IMPORTANT CONSIDERATIONS FOR MAPPING:

• Mapping can be dangerous because it can lead to the sharing of incorrect data or, occasionally, the failure to share correct data. For this reason, it is essential that human users be given the opportunity to review questionnaire responses that have been populated by automated means.
• Even with this precaution, care should be taken when performing data mappings, including:
  • Be aware that the risk of incorrect mapping occurring can be significantly higher when mapping complex questionnaires and/or complex data structures and especially high when mapping both.
  • The degree of risk is implementation dependent (type of data, type of questionnaire, type of source, mapping mechanism, type of user, etc.)
  • Both mappings and the implementation of those mappings should be carefully verified and in some situations should be subject to certification or external verification
  • Mapping to data elements not specifically defined for use in the context of a particular questionnaire or set of questionnaires (i.e. with a defined context) magnifies the risk of erroneous population. Defining data elements for "general purpose" mapping use carries a significant risk of inappropriate data population, particularly for complex structures.
• 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.

1.6 Terminology Operations

In addition to the QuestionnaireResponse population operations, it will be useful for Form Filler and Form Manager systems to support some of FHIR's terminology service capabilities - specifically the Valueset Expand and Validate code operations.

1.7 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 the systems that data captured using this implementation guide may be shared with.