This is a pre-release of a future version of SDC (expected to be STU 2). The current version is STU 2.
For a full list of available versions, see the Directory of published versions .

0 SDC Home Page

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.

0.0.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 registry 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
• Conformance 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

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

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

0.0.4 Workflows

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.

The fundamental workflow in FHIR is to complete (and potentially submit) a completed questionnaire response. 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. Finally, 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.

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.

0.0.5 SDC Specification

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

0.0.5.1 Conformance Statements

FHIR Conformance 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 Receiver - Repository for completed forms which support their subsequent retrieval
• SDC Form Archiver - System responsible for archiving and retrieving of completed forms

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 2 and Figure 3 below:

Figure 2: Form Curation

Figure 3: Form Population

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

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

0.0.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 in the QuestionnaireResponse instance. answers will	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

* 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 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. 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:

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.

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