Structure Data Capture
Implementation Guide Document
Version 1.0 (draft 04)
September, 2013
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
READ ME FIRST
INSTRUCTIONS FOR USING THIS DOCUMENT

The S&I Framework Implementation Guide (IG) template is intended to provide high-level
direction around what type of content should be documented to describe to the end-user
community how a standard or stack of standards could be constrained or implemented to align
with a specific Use Case outlining business requirements around information exchange or
standardization.

Unlike other artifact templates in the S&I lifecycle, the IG may vary based on the type of content
represented. The table of contents and high-level section descriptions of this template will help
with development of relevant sections, provide organization, and document needed pieces for
S&I. However, having a “complete” IG depends on several factors which are listed below. The
considerations listed here will mostly impact Section 2.0: Implementation Approach.
1) Standards development organization (SDO) or standards organization
balloting


Determine what ballot content is needed for the standards artifact (IG, profile)
to be considered as a final artifact
Action: determine if there is a balloting plan for the initiative, and ensure that
the IG sections developed and documented here align with the necessary
content for organization balloting
2) The “stack” or type of standards being addressed in the Implementation
Guide


Determine if the IG focuses on constraining a content or structure standard as
opposed to completing a profile with security, transport, and payload
standards.
Action: confirm the scope of standards being addressed in the IG, and
document complete guidance around each type of standard(s), and any
interactions.
Page 2 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
Version History
Version Number
1.0
Revision Date
<mm/dd/yy>
Author
Description of Change
<name>
<description of change>
Page 3 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
Contents
1
Introduction.................................................................................................................. 1
1.1
1.2
1.3
1.4
2
Implementation Approach ............................................................................................ 5
2.1
2.2
2.3
2.4
2.5
2.6
3
Purpose ....................................................................................................................................................1
Approach ..................................................................................................................................................2
1.2.1
Approach for this guide ...........................................................................................................2
Intended Audience ...................................................................................................................................2
Organization of This Guide .......................................................................................................................3
1.4.1
Conformance Verbs (Keywords) ..............................................................................................3
1.4.2
Cardinality................................................................................................................................4
1.4.3
Definition of Actors .................................................................................................................4
Solution Plan ............................................................................................................................................5
Pre- and Post-conditions ..........................................................................................................................6
SDC Data Element Definition....................................................................................................................8
2.3.1
Overview..................................................................................................................................8
2.3.2
SDC Data Element Definition ...................................................................................................9
2.3.3
SDC CDEs and SDC Forms ......................................................................................................10
2.3.4
Version Control ......................................................................................................................10
2.3.5
SDC Data Elements and Forms ..............................................................................................10
2.3.6
Version Control ......................................................................................................................10
Structure and Overview of MFI Form Model Definition ........................................................................10
2.4.1
Scope and approach ..............................................................................................................10
2.4.2
SDC Form Definition ..............................................................................................................10
Transaction Definition ............................................................................................................................12
2.5.1
Transport, Security, and Authentication ...............................................................................12
2.5.2
Request ..................................................................................................................................14
2.5.3
Response ...............................................................................................................................16
2.5.4
Submission .............................................................................................................................17
Auto-population Definition ....................................................................................................................17
Suggested Enhancements ............................................................................................ 17
Appendix A.......................................................................................................................... 19
Definition of Acronyms and Key Terms ............................................................................................................19
Appendix B .......................................................................................................................... 20
Conformance Statements List ..........................................................................................................................20
Appendix C .......................................................................................................................... 21
Templates List ..................................................................................................................................................21
Appendix D ......................................................................................................................... 22
Specifications References.................................................................................................................................22
Page 4 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
List of Figures
Figure 1 Form/Template Exchange ................................................................................................................................5
Figure 2: Form/Template Exchange with Patient Data ..................................................................................................6
Figure 3: Complete Form/Template Structure Data Exchange ......................................................................................6
Figure 4: Diagram showing content of service payload .................................................. Error! Bookmark not defined.
Figure 5: Form Request without Patient Data .............................................................................................................14
Figure 6: Form Request with Patient Data...................................................................................................................14
Figure 7: Response without Patient Data ....................................................................................................................16
Figure 8: Response with Patient Data..........................................................................................................................16
Figure 9: Completed Structured Data ..........................................................................................................................17
Page 5 of 27
S&I Framework
Structured Data Capture Implementation Guide
1
1
2
3
4
5
6
7
Version 1.0 (draft 04)
September, 2013
Introduction
With electronic health record (EHR) adoption rising across the U.S., the volume and detail of
information captured by healthcare organizations and providers is growing exponentially. Although
health care Providers and others use various sources and methods to capture and synthesize patientlevel data, EHRs have been recognized as the data source with the highest potential to provide timely
and relevant data in a form that is quickly usable for quality and safety improvement, population
health, and research (sometimes labeled “secondary” use or “reuse”).
8
9
10
11
EHR data obtained during episodes of care will become increasingly valuable to healthcare
organizations striving to leverage electronic information to drive efficiency and quality. Of particular
interest are efforts to leverage clinical data captured during episodes of care and efforts to link the
clinical data to supplemental data collected for other purposes including:
12
15




16
17
Once captured, aggregated and analyzed, these combined data can be used to identify trends, predict
outcomes and influence patient care, drug development and therapy choices.
18
19
20
21
22
23
24
25
26
27
In addition, it should be noted that various clinical and health services research groups and specialty
societies are already engaged in independent initiatives to standardize data collection across projects
in their domains in order to maximize the utility of the resulting datasets for subsequent research.
Many important efforts that focus on this level of standardization, such as the Patient Reported
Outcomes Measurement System (PROMIS), PhenX (consensus measures for Phenotypes and
eXposures), and the Federal Interagency Traumatic Brain Injury Research (FITBIR) Informatics System,
are funded by the National Institutes of Health (NIH) and other Federal sources. The National Library
of Medicine (NLM) is working with the NIH research community and others to identify and coordinate
research initiatives that use standardized patient assessment instruments and structured data
definitions, also known as Common Data Elements (CDEs).
28
29
30
31
32
33
34
35
36
Work is also beginning, under the auspices of NLM and the Department of Health and Human
Services (HHS), to consider how to incorporate these CDEs more directly into the data infrastructure
for patient-centered outcomes research (PCOR) using EHRs. The Agency for Healthcare Research and
Quality (AHRQ) has developed a comparable library of terms and Common Formats to standardize
data collected and reported for patient safety events. With such CDEs and standardized assessment
instruments, data captured within an EHR could be consistently defined and collected, thereby
improving its validity and usability not just in retrospective analysis but also in prospective
observational or interventional research, public health active surveillance, comparative effectiveness
research and patient safety monitoring.
37
38
This implementation guide will provide implementers of the structure data initiative the mean to
successfully implement the base standard(s) identified in this document.
39
40
41
A corollary document to this implementation guide is the Structured Data Capture Initiative
Standards and Interoperability Framework Use Case document. It is highly recommended that users
of this implementation guide also study the Use Case document.
13
14
42
43
44
1.1
Research;
Patient-safety event reporting;
Public health reporting;
Determination of coverage.
Purpose
The utility of EHR data for supplemental purposes has been limited due to a lack of uniformity in the
terminology and definitions of data elements across EHRs. This limitation is compounded by the fact
Page 1 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
45
46
47
that clinician workflow often records patient information in unstructured free-text data well after the
episodes of care. Linking EHR data with other data in a uniform and structured way could accelerate
quality and safety improvement, population health and research.
48
49
The purpose of this Implementation Guide is to enable the use of standardized Structure Data
Capture through the leveraging of base standards. These leveraged standards include:
50



51
52
The IHE RFD profile as the service standard;
The TLS v1.0 standard for Authentication;
The SOAP transport standards for Web services.
53
1.2
Approach
54
1.2.1
Approach for this guide
55
This guide is laid out to support the following implementation objectives:
56
57
58

To provide an overview of the standards and specifications used in this implementation guide
and to explain how each standard contributes to the HeD CDS Guidance Service
implementation;
59
60

To specify how the full stack of base standards can be leveraged to standardize the use of CDS
Guidance Services;
61
62

To specify where and how the documentation for each supporting standard/specification may
be obtained.
63
64
65
This implementation guide focuses not only on the structure of the in-scope transactions, but also on
the message semantics through the use of standard terminologies, value sets and taxonomies such as
SNOMED-CT.
66
1.3
Intended Audience
67
The following describes the intended audience for this implementation guide:
68



Healthcare Providers and Clinical Informaticians;






Patient Safety Organizations (PSOs);
69
70
71
72
73
74
75
76
77
78
79
80
81
82
Patients;
Clinical/PCOR Research Community and CER/PCOR Thought Leaders and organizations, such as:
Patient-Centered Outcomes Research Institute (PCORI), EDM Forum, CDISC, Electronic Medical
Records and Genomics Network (eMERGE), Distributed Ambulatory Research in Therapeutics
Network (DARTNet), Electronic Patient-Reported Outcome (ePRO) Consortium, ASTER and
ASTER-D, SHARPn, College of American Pathologists (CAP): Cancer Committee, electronic Cancer
Checklists (eCC) program, Pathology Electronic Reporting Committee (PERT), and Cancer
Biomarkers Reporting Committee (CBRC);
Privacy and Security Experts;
Patient Advocates;
Biopharmaceutical Firms;
Device manufacturers;
Government Agencies:
Page 2 of 27
S&I Framework
Structured Data Capture Implementation Guide

83
84
85
86
87
88
Version 1.0 (draft 04)
September, 2013
Food & Drug Administration (FDA), Assistant Secretary for Planning and Evaluation
(ASPE), NIH (NLM & other Institutes/Centers), AHRQ, Centers for Disease Control (CDC),
Centers for Medicare & Medicaid Services (CMS), Indian Health Services, Human
Resources and Services Administration (HRSA), Institute of Medicine (IOM), Veterans
Administration (VA), Department of Defense (DoD), Social Security Administration
(SSA), Department of Transportation (DoT), State Medicaid Programs;
89
90

Vendors: EHR/EMR systems, Health Information Exchange (HIE), Data Warehouse/Data Mart,
Electronic Data Capture (EDC) and Patient Safety Event Reporting Systems;
91
92

Standards-Related Organizations: Standards Development Organizations (SDOs),
vocabulary/terminology organizations, standards setting organizations:

93
Value Set authors (e.g. AMA) and Value Set repositories (e.g. VSAC, PHIN VADS);
94
95
96

Healthcare payers, particularly those with robust research, quality improvement (QI), patient
safety and public health activities, including professionals involved in registries and surveillance
at a regional and national level;
97


Professional liability carriers;
98
99
1.4
100
101
102
103
Healthcare Professional associations.
Organization of This Guide
Section Description: In this section, describe the general structure and organization of this
guide, so that the reader can understand and follow the different conventions used in the
guide.
1.4.1
Conformance Verbs (Keywords)
104
105
Conformance Verb (aka keywords) is defined throughout this implementation guide using BOLD and
CAPS to denote the conformance criteria to be applied.
106
107
The keywords SHALL, SHOULD, MAY, NEED NOT, SHOULD NOT, and SHALL NOT in this document are
to be interpreted as described in the HL7 Version 3 Publishing Facilitator's Guide 1:
108



SHALL: an absolute requirement;
113
114

MAY/MAY NOT: truly optional; can be included or omitted as the author decides with no
implications.
115
116
117
Much of the conformance requirements are specified in the underlying standards. The SHALL and
SHALL NOT conformance verbs relating to requirements that are only defined in this implementation
guide are underlined as well for distinction.
109
110
111
112
1
SHALL NOT: an absolute prohibition against inclusion;
SHOULD/SHOULD NOT: best practice or recommendation. There may be valid reasons to ignore
an item, but the full implications must be understood and carefully weighed before choosing a
different course;
http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm
Page 3 of 27
S&I Framework
Structured Data Capture Implementation Guide
118
1.4.2
Version 1.0 (draft 04)
September, 2013
Cardinality
119
120
The following table represents the Cardinality of elements within this guide. Cardinality is defined by
the minimum and maximum number of times that the data element may appear.
121
122
The cardinality indicators are interpreted with the following format “m…n” where m represents the
least and n the most.
123
Table 1: Cardinality
Cardinality
124
Description
0..0
The element is never present
0..1
The element MAY be omitted and has at most one occurrence
1..1
The element is present once and only once
0..n
The element MAY be omitted or may repeat up to n times
1..n
The element MUST appear at least once, and MAY repeat up to n times
0..*
The element MAY be omitted, or it MAY repeat an unlimited number of times
1..*
The element MUST appear at least once, and MAY repeat an unlimited number of
times
m..n
The element MUST appear at least m times, and at most, n times
2..2
The element MUST appear two and only two times
3..3
The element MUST appear three and only three times
1.4.3
Definition of Actors
125
126
127
This table outlines the business actors that are participants in the information exchange requirements
for the generic SDC scenario. The system or system actor has roles (e.g., send, receive, publish) and
actions which involve exchanging content.
128
129
130
The actors/systems designated in the following table are core to the Use Case but do not preclude
the use of other actors/systems to be added based upon the information and system requirements of
the specific implementation.
131
The text with asterisks (*) denotes “Optional” or “Conditional” functionality where defined.
132
Table 2: Actors and Roles
Actor
Provider
EHR System
System
EHR System
Role
 Identifies necessary form/template*
 Inputs data into form/template*
 Reviews and saves completed form/template*






Sends requests for form/template
Receives form/template
Displays form/template
Auto-populates form / template*
Stores complete form/template data*
Sends completed form/template data
Page 4 of 27
S&I Framework
Structured Data Capture Implementation Guide
Actor
133
System
Version 1.0 (draft 04)
September, 2013
Role
Form/Template Repository
 Receives form/template request
 Auto-populates form/template*
 Sends form/template
External data repository
 Receives completed form/template data
 Stores completed form/template data*
2
Implementation Approach
134
This guide is laid out to support the following implementation objectives:
135
136
137

To provide an overview of the standards and specifications used in this implementation guide,
and to explain how each standard contributes to the HeD CDS Guidance Service
implementation;
138
139

To specify how the full stack of base standards can be leveraged to standardize the use of CDS
Guidance Services;
140
141

To specify where and how the documentation for each supporting standard/specification may
be obtained.
142
143
144
This implementation guide focuses not only on the structure of the in-scope transactions, but also on
the message semantics through the use of ISO 11179 standard data elements that take advantage of
standard terminologies, value sets and taxonomies such as SNOMED-CT.
145
146
2.1
Solution Plan
Figure 1 Form/Template Exchange
147
Page 5 of 27
S&I Framework
Structured Data Capture Implementation Guide
148
Figure 2: Form/Template Exchange with Patient Data
149
150
Figure 3: Complete Form/Template Structure Data Exchange
Version 1.0 (draft 04)
September, 2013
151
152
2.2
Pre- and Post-conditions
153
154
155
156
The Pre- and Post-Conditions section describes the state of the system, from a technical perspective,
that must be true before an operation, process, activity or task can be executed. It lists what needs to
be in place before executing the information exchange as described by the Functional Requirements
and Dataset requirements.
157
158

Provider & End Users have secure access to clinical information in accordance with applicable
jurisdictional, organizational, and patient privacy consent directive requirements.
Page 6 of 27
S&I Framework
Structured Data Capture Implementation Guide
159
II01 - EHR Requests Form/Template from Form/Template Repository
160

Pre-conditions
161
162
163

164
165

166
167

168
169

170

Standardized forms or templates, structured as specified by the Form/Template
standard, which is based on ISO/IEC 19763-13 (MFI-13), are available in a
Form/Template Repository.
EHR system used by requestor of form is able to request the form in accordance with
the MFI-13/ONC standards.
EHR system used by requestor of a form is able to demonstrate authority to access
both the repository and the form.
EHR system used by requestor of form is able to parse the form template in accordance
with the MFI-13/ONC standards.
Post Conditions
171
172

173

Form Repository has received the request and is able to locate the appropriate
FormTemplate, compliance rules and maps.
Form Repository can wrap all of the above in preparation for return to requestor.
174
II03 - EHR Receives Form/Template from Repository
175

176
177
Pre-conditions

Form Repository is able to recognize and authorize access to both the repository and the
form (and any related artifacts).
178
179

180
181
182

183
184

185
Version 1.0 (draft 04)
September, 2013

Form Repository can receive the request and can locate the appropriate Form
Template, compliance rules and maps.
Form Repository can wrap all of the above in preparation for return to
requestor, using SOAP or REST in accordance with the requirements of the
requestor
Form Repository can provide secure transport of Form Templates, in
accordance with SDC standards.
EHR system used by Requestor of form is able to:
186

Implement a form in accordance with MFI-13/ONC standard,
187

Implement compliance rules associated with a form,
188

Associate Form Template elements with mapping file entries
189
190
191
192

193
194

195
The relevant jurisdictional entity, wherein the “Provider” operates, (often a state or local
agency) has (or can access) both a Form/Template Repository and an External Data
Repository capable of receiving data from the form/template for those with appropriate
access.
An organization’s Form/Template repository has forms/templates that meet the data
reporting needs of the activities under their specific jurisdiction.
II05 - EHR Sends Completed Form data (Structured Data) to External Data Repository
Page 7 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
196
197

EHR System is capable of temporarily capturing, when applicable storing, and sending
completed form/template data in the standards specified by SDC initiative.
198
199
200

EHR System is capable of enabling consistent, appropriate, and accurate information exchange
across Provider & End User systems, data repositories and locator services, including but not
limited to methods to:
201

Identify and authenticate users;
202

Identify and determine Providers of care;
203

Enforce data access authorization policies.
204
Auto-population/Use of Standard Clinical Terminologies and Value Sets
205
206

For auto-population, EHR System is capable of extracting data from its database in a way that
preserves the associations, validation and integrity of data elements.
207
208
209

210
211


212
213
214
2.3
215
216
217
For example, a form may specify that systolic and diastolic blood pressure are captured as
discrete data elements, but should always be linked when captured, and should remain
linked during any edits.
A form may specify the unit of measure for a lab test report, or that a particular value set
is to be used to populate the form for a particular question.
For auto-population in relevant implementation settings, the EHR System has the ability to track
updates to data pulled or stored with the EHR System.
SDC Data Element Definition
Section Description: In this section, describe how Common Data Elements will be defined and
stored.
2.3.1
Overview
218
219
220
221
222
223
224
The many and varied ways in which the same information is collected in different systems and
settings inhibit the ability to exchange information effectively. From early on, the community sees a
need to standardize the collection of data to facilitate comparison of results across studies and to
more effectively aggregate information. Various efforts have been initiated, including CDE initiatives
at NIH ICs such as NINDs CDEs [ref] and NCI CDEs [ref], CDEs using standard terminologies and value
sets, such as LOINC [ref] and NLM value sets [ref], AHRQ common formats [ref], College of American
Pathologists electronic Cancer Checklists, etc.
225
226
227
The ONC’s Structure Data Capture (SDC) initiative intends leverage the community efforts and
develop a standards-based framework to enable standardized data collection, extraction and
exchange.
228
229
230
231
232
ISO/IEC 11179 Information technology — Metadata registries (MDR) — Part 3: Registry metamodel
and basic attributes [2](MDR-3:2013) was developed to address the need for defining data standards
that are unambiguous, accurate, consistent and verifiable. For these data exchanges to be effective it
is essential that the meanings (e.g., semantics and the definitions) of the data are understood so that
suitable data exchange mechanisms can be developed.
233
234
235
To this end, the scope and purpose of CDEs in the SDC Forms Sub Work Group is parallel to the
purpose and scope of MDR-3:2013. MDR-3:2013 in recognizing that a “prerequisite for correct and
proper use and interpretation of data is that both users and owners of data have a common
Page 8 of 27
S&I Framework
Structured Data Capture Implementation Guide
236
237
238
Version 1.0 (draft 04)
September, 2013
understanding of the meaning and representation of the data. To facilitate this common
understanding, a number of characteristics, or attributes, of the data have to be defined.”
2.3.2
SDC Data Element Definition
239
240
241
242
243
244
245
Data Elements are defined in MDR-3:2013 as a unit of data for which the definition, identification,
representation and Permissible Values are specified by means of a set of attributes. An SDC data
element whose definition, identification, representation and Permissible Values has been agreed
upon and understood for use in SDC Forms is “common data element” (CDE). It is linked to registered
concept system for its semantics and registered by assigning a globally unique identifier and
registration status of “Standard,” and thus is considered standardized for the purpose of use within
the S&I Framework.
246
247
248
249
250
MDR-3:2013 data element metaclasses and attributes defined provide a structured definition for data
elements that can be leveraged for use in applications and database design to ensure data can be
collected and exchanged the same way, which is an important characteristic for interoperability.
Similarly, an SDC CDE defines a structured question and answer set, and can form the basis for the
semantics and representation of questions on structured data capture forms (SDC forms).
251
252
253
254
The full details of the MDR-3:2013 metaclasses and attributes are described in the published MDR3:2013 [ref, see http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html]. The set of the
metaclasses and attributes and further constraints that are essential for SDC CDE are driven by those
needed for form definitions and are described herein.
255
2.3.2.1
SDC CDEs
256
257
258
259
References between SDC forms questions and CDEs based on ISO/IEC 11179-3 data elements will
utilize the ISO/IEC 19763-13 MDR_Mapping class, which allows for a Question on a form to be linked
to an MDR-3 Data Element. An extension to the MDR_Mapping capability add the ability to map
between a Question on a form and a ??????.
260
261
The table below describes the mapping between the SDC Data Element attributes and an MFI-13
Question.
Page 9 of 27
S&I Framework
Structured Data Capture Implementation Guide
SDC Common Data
Element
Description
Version 1.0 (draft 04)
September, 2013
MFI-13
CDE attributes related
to Question Attributes
Question Text
Answer Attributes
List Field Item
Administrative
Attributes
262
2.3.3
SDC CDEs and SDC Forms
263
2.3.4
Version Control
264
How a CDEs repository is maintained or CDEs added to the repository is out of scope for this guide.
265
2.3.5
SDC Data Elements and Forms
266
2.3.6
Version Control
267
2.4
268
269
Structure and Overview of MFI Form Model Definition
Section Description: In this section, describe how the Form/Container will be defined.
2.4.1
Scope and approach
270
271
272
SDC Forms address the need for systems to interoperate by exchanging data that has been defined as
part of a structured document. In the ISO/IEC 19763-13 (MFI-13) forms standard recognizes the
challenge presented by these data exchanges.
273
274
“…it is essential that the business information requirements that are met by the data stored in these
systems are understood so that suitable data exchange mechanisms can be developed.
275
276
277
278
Not only does this require a clear understanding of the meaning of the data, it also frequently
requires the coordination of data capture. Where data input is manual, an important source of data
semantics is the design of the form used for data entry. Inspecting the form design can provide
additional semantics and context."
279
280
281
282
283
284
2.4.2
SDC Form Definition
Wikipedia defines a form as “a document with spaces into which to write or enter data.” The spaces
on a form generally have a prompt to elicit the data, sometimes an instruction to clarify the prompt,
and can be organized into sets of related questions. The basic structure of an SDC form contains one
or more sections, sections contain one or more questions. Each response to a question, an answer, is
stored as an atomic unit of data. Sometimes the answer to one question determines the next
Page 10 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
285
286
question or section that should be presented, or is used in a calculation of data value(s). All of these
different types of items are referred to as form elements.
287
288
289
290
291
292
293
294
The SDC form is based on ISO/IEC 19763-13 Metamodel for Forms Registration (MFI-13). The
standard defines a universal metamodel for forms, devoid of specific domain knowledge, that allows
documentation and registration of form designs, in both paper and electronic from any/all sources.
MFI-13 inherits from ISO/IEC11179 Metamodel for Data Element Registration (MDR-3), which
provides classes and types that support the identification, naming, registration and administration of
form designs and other supporting documents. The form design can be associated with appropriate
entity-relationship diagrams or data models so that data and semantics may be faithfully exchanged
between systems and so that those data may be compared, joined or composed for analysis.
295
296
297
298
299
Used in concert, MFI-13 provides the ability to record reusable form semantics and MDR-3 provides
the ability to record reusable atomic data descriptions. Together, both standards can support the
rapid design and reuse of forms, wrap and hide the complexity of semantic annotation from subject
matter experts, and provide a ready reference of associations and transformations for users seeking
to collect and use interoperable data.
300
SDC forms are based on MFI-13, but has specialized its use for healthcare.
301
2.4.2.1
Form design
302
303
304
The Form design is the overall structure and description of the spaces, or questions, on a form. Each
form design will contain various text elements that are important to the overall semantics of a form,
however the primary parts of a form design are:
305


306


Mappings between question elements either from MDR-3, or some other data element
specification, for the purpose of defining the semantics and input constraints of the
question and its answer.
Compliance;

315
Administrative information includes details on the registry owning the form design, its
status, contacts, keywords, interfaces, language, style, effective dates and change
notes
Mappings;

311
312
313
314
Administrative;

307
308
309
310
Title, Header and Footer;
Compliance

316
317

318
Submission

319

320

323

A set of rules regarding submission of completed forms
Security and Privacy
321
322
A set of rules that must be followed or satisfied to indicate compliance with
some aspect of a form design
A set of rules regarding the security and privacy for competed forms
Sections;

Instructions
Page 11 of 27
S&I Framework
Structured Data Capture Implementation Guide

324

325
Version 1.0 (draft 04)
September, 2013
Directions for completing the section
Questions

326
327
There are 3 types of questions each with a set of attributes and rules
requesting information.

328
329
330
331
332
List Fields: a field in which only predefined answers are allowed
Each answer is a List Item consisting of a Value and optional
descriptive fields, including a prompt, the meaning of the value, a
media element and rules that trigger based on the selection of the
answer
333
334

335
336
337
338
339
340

341
342
Text Field: a field in which any value may be entered, subject to
pattern and length constraints
Lookup Field: a valid list of answers from a defined domain, but
where the members of the domain vary with time and between
implementations: e.g. a view providing a valid set of active customer
IDs for a sales order system; a terminology approved for tagging an
experimental result; a web service; open issue lookup in bug tracking
software
Table below shows the details for a form design, a definition for each field of the form design and its
related source.
Element name
Description
Cardinality
Template ID
343
2.4.2.2
Sample XML
344
2.4.2.2.1
Local_Definitions (Actions)
345
2.5
346
347
Source
i.e. MDR-3
Transaction Definition
Section Description: In this section, describe in detail the payload along with related details for
transport, security, authentication, and service layers
348
2.5.1
Transport, Security, and Authentication
349
2.5.1.1
SOAP
350
351
352
The SOAP header establishes specific routing information for an exchange of patient data and within
the Header would be additional metadata depending on whether a push-based or pull-based model is
used.
353
354
The following example shows the structure of the SOAP Header and how a Provider and Register
Document Set-b is provided.
355
<soapenv:Header>
356
<wsa:To>http://localhost:5000/axis2/services/xdsrepositoryb</wsa:To>
Page 12 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
357
<wsa:MessageID>urn:uuid:AFBE87CB65FD88AC4B1220879854302</wsa:MessageID>
358
<wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</wsa:Action>
359
</soapenv:Header>
360
361
362
363
The SOAP Header SHALL NOT contain specific PHI within the specific header elements itself. This
meets the use case requirement to NOT expose data in the header of a response to a data query that
might indirectly expose additionally protected patient data to an intermediary, and only exposing the
information necessary to achieve the mechanism.
364
2.5.1.2
SAML
365
366
The SOAP Header SHALL contain a SAML assertion. The implementer SHOULD refer to the IHE XUA
profile for a complete set of SAML attributes.
367
368
369
370
371
The SOAP body contains the specific payload that is being transported. Any transaction that uses
SOAP or SOAP with Attachments will end with a response message that is SOAP encoded. Thus a
query for consent directive, which uses SOAP, will also use SOAP to return the consent directive. This
will also occur for any transaction, such as a request for patient data, which will always be wrapped in
XML and use SOAP.
372
2.5.1.3
Transport Layer Security (TLS) and Node Authentication
373
374
375
The XD* Profiles and their transactions are all encrypted so that only the intended recipient can
decrypt them. These XD* profiles also support bi-directional (Mutual) authentication using digital
certificate identities, and integrity controls chaining back to those same digital identities.
376
377
378
379
380
In accordance with the IHE ITI TF (Vol 2a pg. 136), when configured for use on a physically secured
network, the normal connection mechanisms may be used. However, when configured for use in an
environment not on a physically secured network, implementations shall use a secure channel such
as the TLS protocol. It is expected that the payload used in this use case will cross affinity domains
and therefore transport encryption is required.
381
382
The requirements for transport security are therefore based on the traversal of organizational
boundaries:

383
384
Transactions traversing organizational boundaries (e.g. over untrusted/non-secured
network) utilizing SOAP SHALL utilize TLS 1.0 or greater in order to provide a secure channel.
385

386
387
388
389
390
391
The underlying specifications listed in the IHE Audit Trail and Node Authentication (ATNA) Integration
Profile help protect confidentiality and integrity, and use cryptographic mechanisms to ensure that
both endpoints are mutually authenticated. Note that IHE ATNA allows each secure node to use the
access control technology of its choice to authenticate users, but requires the use of bi-directional
certificate-based node authentication for connections to and from each node in order to authenticate
the endpoints and secure the communications channel.
392
393
Implementers SHOULD reference the NwHIN Messaging Platform Specification for instructions on
how to implement TLS.
394
395
396
2.5.1.3.1
The SOAP Envelope SHALL use TLS 1.0 or higher for transport-level security.
Use of IHE ATNA for Recording Security Audit Events
The Record Audit Event transaction is a foundational component that is used to record audit events
throughout an implementation.
Page 13 of 27
S&I Framework
Structured Data Capture Implementation Guide
397
Version 1.0 (draft 04)
September, 2013
Table 3: Record Audit Event
Implementation Approach
Record Audit Event
Required
Standards/Profiles
ASTM E2147
Optional Standards/Profiles
IHE ATNA
This guidance recommends flexibility for
implementers to select the standard for the
audit record format.
398
399
400
401
402
403
This implementation guidance recommends usage of the IHE ATNA profile for capturing auditable
events. The HL7 Purpose of Use codes provide meaningful attributes that can be used to support the
accounting of disclosures, although it should be noted that IHE ATNA contains implementation
specifications for Security audit trails, not disclosure logs. Implementers SHOULD refer to the IHE
ATNA profile for specific implementation guidance and conformance criteria.
2.5.2
404
405
406
Request
Section Description: In this section, describe the Transport and Security, Service
Implementation, Use of TLS Encryption, and XML-based template protocols used for the SDC
initiative.
407
Figure 4: Form Request without Patient Data
408
409
Figure 5: Form Request with Patient Data
410
411
2.5.2.1
Service Implementation
412
413
See 3.34.4.1 Retrieve Form Request in IHE ITI TF_Rev10.0, Vol 2b for transaction requirements for
both Form Request with and without Patient Data.
414
An example of a Form Request without Patient Data:
Page 14 of 27
S&I Framework
Structured Data Capture Implementation Guide
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
Version 1.0 (draft 04)
September, 2013
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To>
<wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID>
<wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveForm</wsa:Action>
</soap:Header>
<soap:Body>
<RetrieveFormRequest xmlns="urn:ihe:iti:rfd:2007">
<prepopData/>
<workflowData>
<formID>1</formID>
<encodedResponse>false</encodedResponse>
<archiveURL />
<context />
<instanceID />
</workflowData>
</RetrieveFormRequest>
</soap:Body>
</soap:Envelope>
An example of a Form Request with Patient Data, using the additional constraints as defined by
Clinical Research Document (CRD), Trial Implementation, September 24, 2012:
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To>
<wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID>
<wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveForm</wsa:Action>
</soap:Header>
<soap:Body>
<RetrieveFormRequest xmlns="urn:ihe:iti:rfd:2007">
<prepopData>
<ClinicalDocument xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<realmCode code="US" />
…
…
</ClinicalDocument>
</prepopdata>
<workflowData>
<formID>12346</formID>
<encodedResponse>false</encodedResponse>
<context>
<StudyID>POIUY42</StudyID>
<SiteID>abcdef42</SiteID>
<SubjID>88888</SubjID>
</context>
<instanceID/>
</workflowData>
</RetrieveFormRequest>
</soap:Body>
Page 15 of 27
S&I Framework
Structured Data Capture Implementation Guide
470
Version 1.0 (draft 04)
September, 2013
</soap:Envelope>
471
472
2.5.2.2
Transaction Data
473
2.5.3
Response
474
475
476
Section Description: In this section, describe the Transport and Security, Service
Implementation, use of TLS Encryption, and XML-based template protocols used for the SDC
initiative.
477
Figure 6: Response without Patient Data
478
479
Figure 7: Response with Patient Data
480
481
2.5.3.1
Service Implementation
482
See 3.34.4.2 Retrieve Form Response in IHE ITI TF_Rev10.0, Vol 2b.
483
An example Retrieve Form Response:
484
485
486
487
488
489
490
491
492
493
494
495
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header>
<wsa:To>http://localhost:4040/axis2/services/someservice</wsa:To>
<wsa:MessageID>urn:uuid:76A2C3D9BCD3AECFF31217932910053</wsa:MessageID>
<wsa:Action soap:mustUnderstand="1">urn:ihe:iti:
2007:RetrieveFormResponse</wsa:Action>
</soap:Header>
<soap:Body>
<RetrieveFormResponse xmlns="urn:ihe:iti:rfd:2007">
Page 16 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
496
497
498
499
500
501
502
503
504
<form>
<URL>http://somehost/xxx/services/someForm</URL>
<instanceID>1.2.3.4.5</instanceID>
</form>
<contentType />
<responseCode />
</RetrieveFormResponse>
</soap:Body>
</soap:Envelope>
505
2.5.3.2
Transaction Data
506
2.5.4
Submission
507
508
509
Section Description: In this section, describe the Transport and Security, Service
Implementation, Use of TLS Encryption, and XML-based template protocols used for the SDC
initiative.
510
Figure 8: Completed Structured Data
511
512
2.5.4.1
Service Implementation
514
2.5.4.2
Transaction Data
515
2.6
Auto-population Definition
513
516
517
518
519
520
521
Overview
3
Suggested Enhancements
Section Description: In this section, identify gaps in base standards referenced in this document
and list the suggested enhancements. The suggestion should provide additional details such as
proposed resolution, additional work required, and identify a possible owner against each
suggestion.
Requested
Enhancement/problem
Detail
Proposed
Resolution
Additional work
required
Suggested Owner
or Point of
Contact
Page 17 of 27
S&I Framework
Structured Data Capture Implementation Guide
522
523
Version 1.0 (draft 04)
September, 2013
If the gaps are identified for multiple standards used in this IG, please use a separate table and
sub-section for each standard.
524
525
Page 18 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
526
Appendix A
527
Definition of Acronyms and Key Terms
528
529
Section Description: In this section, create a glossary table. The purpose of this table is to help
reader understand the specific acronyms and key terms used in this document.
530
Page 19 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
531
Appendix B
532
Conformance Statements List
533
534
535
536
537
538
539
Section Description: In this section, create a consolidated list of all the conformance statements
from this document. The table will contain conformance statement text, associated ID, and the
section of the document or message where defined. Additionally, the conformance statement
can be hyperlinked with its associated section. If we are using base standards as is, then those
conformance statements should not be included in this list. However, if we are further
constraining any of the conformance statements from the base standards, they should be listed
in the table below.
540
541
The following table summarizes all conformance statements that are required for complying
with the SDC implementation guide:
Conformance Statement
Conformance Statement ID
Document
Section
Related
Transaction
542
543
Page 20 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
544
Appendix C
545
Templates List
546
547
548
549
Section Description: In this optional section, create a consolidated list of all the templates from
this document. The table will contain the name of the template, associated ID and the section
of the document where it is defined. Depending on the number of templates, separate lists –
one arranged in alphabetical order and another arranged in hierarchal order, can be created.
550
551
This section will be relevant to IGs developing templates or other modular components to be
listed and categorized in a summarized table.
552
The following table summarizes all templates referenced in this implementation guide:
Template Name
Template ID
Document Section
553
554
Page 21 of 27
S&I Framework
Structured Data Capture Implementation Guide
Version 1.0 (draft 04)
September, 2013
555
Appendix D
556
Specifications References
557
Section Description: In this section, list all the references used in the implementation guide.
558
Current references for this implementation guide are listed in the table below:
Reference
Description and/or Link
1
2
3
caCORE: A common infrastructure for cancer informatics,
Peter A. Covitz, Frank Hartel, Carl Schaefer, Sherri De
Coronado, Gilberto Fragoso, Himanso Sahni, Scott
Gustafson and Kenneth H. Buetow, Journal for
Bioinformtics, Vol. 19 no. 18 2003, pages 2404–2412 DOI:
10.1093/bioinformatics/btg335
ISO/IEC 11179 Information technology — Metadata
registries (MDR) Part 3: Registry metamodel and basic
attributes,
http://standards.iso.org/ittf/PubliclyAvailableStandards/c0
50340_ISO_IEC_11179-3_2013.zip
ISO/IEC 19763 Information technology – Metamodel
framework for interoperability (MFI) – Part 13: Metamodel
for Form Registration Committee Draft ISO/IEC CD 1976313 SC32N2417, http://jtc1sc32.org/doc/N24012450/32N2417T-text_for_ballot-CD_19763-13.pdf
559
Page 22 of 27