STU 3 Candidate
This page is part of the FHIR Specification (v1.4.0: STU 3 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 
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:
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.
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:
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.
The following links provide additional context for the SDC specification.
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.
The following sections describe the artifacts that set expectations for systems wishing to be conformant to the FHIR SDC implementation guide.
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.
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
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:
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:
identifier, questionnaire, questionnaireRef, subject and contentcontent parameters consisting of a Binary resource containing a C-CDA* document
Similarly, client systems claiming to support the populate operation (SDC Form Filler)
SHALL, at a minimum:
Questionnaire/[identifier]/$populate)
as well as indirectly either by identifier or questionnairecontent 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.
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.
© HL7.org 2011+. FHIR STU3 Candidate (v1.4.0-8139) generated on Thu, Mar 31, 2016 08:10+1100. QA Page
Links: Search |
Version History |
Table of Contents |
Compare to DSTU2 |
|
Propose a change