DSTU2

This page is part of the FHIR Specification (v1.0.2: DSTU 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

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 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 and artifacts 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. Tooling may provide support for a PDF or other document-approach representation of this implementation guide in a future release.

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

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

Feel free to explore other aspects of the FHIR specification that you feel may be relevant or of interest.

B.0.3 Background

The following links provide additional context for the SDC specification.

B.0.4 Workflows

The generic SDC workflow is pictured in Figure 1.

Figure 1: Generic Workflow

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.

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

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

Diagram showing interaction between Form Designer, Form Manager and Data Element Registry


Figure 3: Form Population

Diagram showing interaction between Form Filler, Form Manager, Form Receiver, Form Archiver and Data Element Registry


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

B.0.5.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 Payers - 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.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 what systems data captured using this implementation guide may be shared with.