Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
Electronic Submission of
Medical Documentation
(esMD)
eDoC eClinical Templates for Structured Data
Capture on FHIR
Use Case
7/15/2015
1
2
3
4
3/22/2016
1
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
5
6
Table of Contents
7
2.0 Initiative Overview .................................................................................................................................. 4
8
2.1 Initiative Challenge Statement............................................................................................................ 6
9
3.0 Use Case Scope ....................................................................................................................................... 6
10
3.1 Background ......................................................................................................................................... 6
11
3.2 In Scope ............................................................................................................................................... 8
12
3.3 Out of Scope........................................................................................................................................ 8
13
3.4 Communities of Interest ..................................................................................................................... 9
14
4.0 Value Statement ................................................................................................................................... 11
15
5.0 Use Case Assumptions .......................................................................................................................... 12
16
6.0 Pre-Conditions....................................................................................................................................... 12
17
7.0 Post Conditions ..................................................................................................................................... 13
18
8.0 Actors and Roles ................................................................................................................................... 13
19
9.0 Use Case Diagram ................................................................................................................................. 15
20
10.0 Scenario............................................................................................................................................... 16
21
10.1 User Story........................................................................................................................................ 17
22
10.2 Activity Diagram .............................................................................................................................. 17
23
10.2.1 Base Flow ................................................................................................................................. 18
24
10.2.2 Alternate Flow.......................................................................................................................... 19
25
10.3 Functional Requirements ................................................................................................................ 20
26
10.3.1 Information Interchange Requirements .................................................................................. 20
27
10.3.2 System Requirements .............................................................................................................. 20
28
10.4 Sequence Diagram .......................................................................................................................... 21
29
11.0 Risks, Issues and Obstacles ................................................................................................................. 22
30
12.0 Dataset Requirements ........................................................................................................................ 24
31
Appendices.................................................................................................................................................. 26
32
Appendix A: Related Use Cases.............................................................................................................. 26
33
Appendix B: Previous Work Efforts ........................................................................................................ 26
34
Appendix C: References .......................................................................................................................... 26
1.0 Preface and Introduction ........................................................................................................................ 4
35
3/22/2016
2
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
36
List of Figures:
37
Figure 1: Use Case Diagram ........................................................................................................................ 15
38
Figure 2: Context Diagram .......................................................................................................................... 16
39
Figure 3: Activity Diagram ........................................................................................................................... 18
40
Figure 4: Sequence Diagram ....................................................................................................................... 22
41
42
List of Tables:
43
Table 1: Communities of Interest .................................................................. Error! Bookmark not defined.
44
Table 2: Actors and Roles ............................................................................................................................ 14
45
Table 3: Base Flow of Scenario 1................................................................................................................. 18
46
Table 4: Alternate Flow ............................................................................................................................... 19
47
Table 5: Information Interchange Requirements ....................................................................................... 20
48
Table 6: System Requirements ................................................................................................................... 21
49
Table 7: Dataset Requirements................................................................................................................... 25
50
51
3/22/2016
3
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
52
53
54
55
1.0 Preface and Introduction
56
57
58
59
60
61
62
63
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information
Technology (ONC), along with the Centers for Medicare and Medicaid Services (CMS), as part of the
Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability
requirements for high priority health care data exchange, in addition to maximizing efficiency,
encouraging rapid learning, and protecting patients’ privacy in an interoperable environment. These Use
Cases address the requirements of a broad range of Communities of Interest, including
patients/beneficiaries, their significant others, and family members, in addition to providers, payers,
vendors, standards organizations, public health organizations, and Federal agencies.
64
These Use Cases describe:
65
66
67
68
69
A.
B.
C.
D.
70
71
72
The Use Case is the foundation for identifying and specifying the standards required to support the data
exchange, as well as developing reference implementations and tools to ensure consistent and reliable
adoption of data exchange standards.
73
74
75
76
77
78
2.0 Initiative Overview
79
80
81
82
83
84
85
86
87
88
89
Healthcare payers frequently request providers to submit additional medical documentation in order to
adjudicate and support the processing of a specific claim or set of claims and perform other
administrative functions, including identification of improper payments. Currently, Medicare Review
Contractors send over 1 million requests for medical documents per year manually using a paper
request letter to mail through the US Postal Service to healthcare providers. Until recently, healthcare
providers had only two options for submitting the requested records to Medicare Review Contractors: 1)
mail paper or 2) send a fax. The manual paper process is costly, time consuming and can delay proper
claims processing on both the senders’ and receivers’ end.
Section Description: The Preface and Introduction briefly explains the purpose of Use Case development
as part of the Standards & Interoperability (S&I) Framework. A standard preface and introduction is
required across all S&I Framework Initiative Use Cases (text included below).
The operational context for the data exchange
The stakeholders with an interest in the Use Case
The information flows that must be supported by the data exchange
The types of data (structured/unstructured, etc.) and their specifications required in the data
exchange
Section Description: This section articulates the overarching issues that the Initiative aims to address.
The Initiative’s goals are at a higher level than those of the Use Case and are distinguished as such in this
section. If an Initiative has multiple Use Cases, this Initiative Overview should be consistent for each Use
Case. Note: A recommended starting point for this content is the project charter and related research
collected during the Pre-Discovery phase.
As of September 15, 2011, a pilot group of Health Information Handlers (HIHs) and Medicare Review
Contractors began accepting electronic submissions from providers, as part of the first phase of esMD.
3/22/2016
4
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
These electronic submissions consist of an unstructured .PDF format of a scanned image, within an
Integrating the Healthcare Enterprise Cross-Enterprise Document Reliable Interchange (IHE XDR)
wrapper. This initiative will provide added value to CMS, Commercial Payers, and Providers by defining
the interoperability requirements for additional automation of the electronic request and submissions
process.
CMS continues to investigate additional capabilities of electronic submission of medical documentation.
The next release for CMS esMD Phase 2 will enable Medicare Review Contractors to send electronic
medical documentation requests (eMDRs), eliminating the need to send the paper letters via mail or fax.
CMS joined the Standards & Interoperability (S&I) Framework to accomplish their short-term goals for
Phase 2 and to address their long-term requirement for replacement of wet signatures with digital
signatures. In joining the S&I Framework, esMD stakeholders were broadened beyond CMS to include
discussions with other payers in the esMD Community including Commercial Payers. With a goal of
promoting consistency across payers and standardizing processes for beneficiaries and providers dealing
with multiple payers, the requirements of multiple payer entities were incorporated into esMD Use
Cases.
esMD expanded Initiative capabilities to support electronic Determination of Coverage (eDoC). For
example, CMS believes the Prior Authorization of Power Mobility Devices (PMDs) Demonstration will
lead to reductions in improper payments for power mobility devices. In addition, this demonstration is
designed to develop and demonstrate improved methods for the determination of coverage for the
provision of care or services under the health programs established by the Social Security Act.
The key objectives for the overall S&I Framework esMD Initiative include:
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
A. Develop a registration process to allow Providers to sign up to receive electronic medical
documentation requests from CMS Review Contractors
Identify a secure method of sending medical documentation requests from CMS review
contractors to providers
C. Identify a solution that will enable an electronic replacement of wet signatures, for medical
documents submitted from providers to CMS
D. Identify standards-based, machine-interoperable electronic structured document templates to
provide an alternate electronic method using SDC for the current paper versions of
documentation for determination of coverage
B.
In order to address the objectives above, this Initiative included the following workgroups:
i.
Provider Profiles Authentication (PPA) workgroup: Addresses the registration process, technical
transport and authentication needed to allow Payers to identify Providers and send requests to
them. This workgroup is dependent on the Provider Directories Use Case #2 (Electronic Service
Information Discovery) outputs, as well as the Exchange support (for the CMS User Story) for
secure transport and other infrastructure.
ii.
Structured Content (SC) workgroup: Determines the structured electronic format of medical
document request letters to be sent to Providers, with consideration for the technical transport,
expected response and information needed to support the response.
3/22/2016
5
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
133
134
135
136
137
138
iii.
Author of Record (AoR) workgroup: Evaluates the business needs and implementable solutions
to address the ability to prove the authorship and authenticity of any message or
documentation that is part of the electronic submission of medical documentation. This
includes all messages that are part of provider registration (esMD UC 1), the electronic
submission of the structured medical documentation request (esMD UC 2) and the response by
the provider or their agent to the payer or payer contractor.
139
140
141
142
143
iv.
Electronic Determination of Coverage (eDoC) workgroup: Defines coverage determination
documentation requirements as structured data sets and templates. This includes defining data
sets, templates, and standards, in addition to providing guidance with decision support, enabling
provider capture of required structured documentation, and establishing secure exchange for
benefit determination.
144
145
146
147
2.1 Initiative Challenge Statement
148
149
150
151
152
153
154
The Centers for Medicare and Medicaid Services (CMS) and other Health Plans/Payers need a
standardized, implementable, machine-interoperable electronic solution to reduce the time, expense,
and paper required in current manual processing of medical documentation request letters, responses
to medical documentation requests, determination of coverage requests, and the relevant medical
documentation exchanged between Healthcare Providers and Health Plans/Payers. The challenge at
hand is to identify the data set requirements for structured documentation required by CMS and other
Health Plans/Payers for processing of coverage determination.
155
156
157
158
159
160
161
3.0 Use Case Scope
162
163
164
165
166
167
This Use Case specifically addresses the structured content requirements to process determination of
coverage. Although coverage determination requirements may only be applicable to CMS, the eDoC
workgroup determined that it would be beneficial for all Payers to follow a consistent process to identify
coverage data set requirements. This Use Case therefore includes input from a variety of stakeholders to
validate that the structured data sets, templates, and standards outlined apply to a broad Payer and
Provider community.
168
169
While the eDoC General Use Case outlines the high-level requirements for coverage determination
documentation, this Use Case will specifically leverage the Structured Data Capture(SDC) IHE and HL7
Section Description: This section provides the description of the current challenge or problem, on a
healthcare industry level, that the Initiative seeks to address. Related issues that currently exist should be
included within this section, with the exception of risks, which are outlined later in the Use Case.
Section Description: Section 3.0 is used as an introduction to the scope of the Use Case. Sections 3.1-3.3
further define the scope at a more granular level. It is a useful exercise to frequently validate that all
material in this section focuses specifically on the Use Case scope and NOT on the Initiative Scope. If
there are multiple Use Cases within the same Initiative, this section can be used to explain how the scope
of this Use Case relates to the others. Note: In the past, diagrams and other supplemental data /
examples have helped to provide context and clarify the basis for the Use Case.
3/22/2016
6
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
170
171
172
173
174
175
standards, including the HL7 Fast Health Interoperability Resource (FHIR) standard, to define questions
and responses used to support CMS eClinical Templates, establish pre-population of responses to predefined questions based on data within the EHR, and modify or expand upon pre-populated responses.
To exchange the contents generated using SDC standards, the HL7 Complete Documents for Payers Set 1
standard will be leveraged, in addition to the HL7 digital signature standard to verify authorship and
delegation of rights.
176
This effort will include investigating and recommending solutions for:
177
178
179
i.
ii.
iii.
Structured Data – Data Set requirements
Structured Data Capture Documentation Templates – Data Capture requirements
Decision Support related to documentation capture workflow – Template workflow
180
181
182
183
184
3.1 Background
185
186
187
188
189
CMS is developing eClinical Templates which define categories of clinical information to assist providers
with data collection and medical documentation to support payer coverage for planned or rendered
services and devices/items. The categories of clinical information are not intended to be required, but
rather serve as guidance for the physician or treating practitioner to use to create electronic medical
documentation in support of coverage for an item or service.
190
191
192
193
194
The purpose of the eDoC workstream is to define structured documentation data sets which may
include coded and un-coded data elements and the associated clinical vocabularies or code sets that
should be used, along with appropriate narrative, or unstructured, descriptions. These templates will
provide the basis to enable providers to capture structured documentation, and securely exchange this
documentation for benefit determination based on Health Plan/Payer’s coverage and payment rules.
195
196
This eDoC workstream will define specific requirements with respect to Structured Data, Documentation
Templates and Template Workflow, including addressing the following key challenges:
197
198
199
200
201
202
203
A. Define coverage determination documentation requirements for structured data sets and
exchange templates
B. Define standards enabling providers to capture documentation based on payer requirements
C. Define template workflow to facilitate provider documentatation
D. Define use of digital signatures on transactions and documents where appropriate
E. Determine secure content exchange standards for exchange of documentation between payers,
providers, and suppliers
204
205
Section Description: The Background section goes into more detail than the Initiative Overview to
describe the relevance of the Use Case in relation to what gaps currently exist within the healthcare
industry. All policy and/or regulatory issues as well as dependencies that may impact the Use Case
should be included in this section.
These challenges will be addressed by leveraging work that has already been completed by related S&I
Framework Initiatives such as Transitions of Care (Consolidated CDA), Provider Directories, Structured
3/22/2016
7
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
206
207
Data Capture, Longitudinal Coordination of Care (LCC), and esMD, in addition to other ONC efforts such
as Direct and CONNECT.
208
209
210
211
212
213
3.2 In Scope
214
215
216
217
218
219
This workgroup will focus on defining the use case, user stories and requirements supporting a
standards-based architecture. It will reuse existing S&I Initiative efforts, including the Structured Data
Capture Initiative, where possible in the process of selecting standards for structured data
documentation requirements, exchange templates, interactive information capture templates, decision
support rules and exchange standards. For the immediate effort to determine documentation
requirements the use case will:
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
Section Description: This section indicates what is in scope for the Use Case. For example, it can include
the type of transactions, the information/data to be exchanged, and specific aspects that need to be in
place to enable the information to be sent, received and understood the same at both ends of the
transmission. Note: A suggested starting point for this content is the project charter and related research
collected during the Pre-Discovery phase.
A. Evaluate and specify appropriate clinical elements for inclusion in eDoC SDC templates
B. Represent eDoC user stories for specific services and devices/items and their eClinical Templates
as SDC templates for coverage determination
C. Map CMS eClinical Template concepts onto SDC template data elements
D. Define acceptable responses, where appropriate, for CMS eClinical Templates using structured
data capture
E. Define clinical data elements (CDE) that may be pre-populated
F. Evaluate existing FHIR resources and profiles to address the gaps in supporting “A”-“E” above
G. Define FHIR resources and profiles required to address the gaps identified in “F”
H. Where gaps exist between eClinical Template concepts and SDC data elements, define clinical
data elements using, where possible, standard clinical vocabularies
I. Identify persistence of templates and responses
J. Identify standards for exchange of persisted templates and responses
K. Identify requirements for information exchange between providers and payers that can be used
during harmonization to specify appropriate transaction/message standards
L. Define provenance elements associated with information used in the determination of coverage
both created by the provider interacting with the SDC template and information that may be
incorporated from other sources
M. Define digital signature requirements to support provenance and data integrity
3.3 Out of Scope
Section Description: This section indicates what is out of scope for the Use Case. These points may
highlight dependencies on the feasibility, implementability, and usability that result in limitations of the
Use Case. At a high level, whatever is not declared “In Scope,” is by definition, “Out of Scope”. Note:
There may be some items that are out of scope for the Use Case and Functional Requirements
Development as well as the Standards Harmonization activities, that can be included as part of a Pilot.
These additions will be documented during that particular stage of the S&I Framework process; however,
this expansion should not conflict with the previously defined requirements.
3/22/2016
8
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
247
248
249
250
251
252
253
A. Provider documentation (with the exception of supporting documentation as defined above in
the In Scope section) that do not use the templates or standards specified by this use case and
its subsequent implementation guides
B. Electronic exchange between the Beneficiary and Payer/Payer Contractor
C. The capture and reporting of information specifically for quality measures is considered out of
scope until such time as the electronic Determination of Coverage Use Case specifically declares
it in scope.
254
255
256
257
258
3.4 Communities of Interest
259
260
Click here to view the list of definitions: http://wiki.siframework.org/UC+Simplification++Stakeholder+Classification+SWG
261
262
The Communities of Interest section identifies relevant stakeholders that are potentially affected by the
content of the Use Case.
263
Note - All items pulled from the Use Case simplification tables are marked with an asterisk. Some have
264
265
266
been further modified to fit the working definition or newly added to fit the initiative or Use Case needs.
Click here to view the list of definitions: http://wiki.siframework.org/UC+Simplification++Stakeholder+Classification+SWG.
Section Description: The Communities of Interest section identifies relevant stakeholders that are
potentially affected by the content of the Use Case. This list may vary per Initiative, but the stakeholder
definitions will be consistent throughout the S&I Framework, as defined by the Use Case Simplification
Workgroup (examples included below).
1
Members of Communities of
Interest
Individual Providers
2
Provider Organizations*
3
Healthcare Administrators and
Managers
3/22/2016
Working Definition
Healthcare providers with beneficiary care responsibilities including,
but not limited to, physicians, advanced practice nurses, physician
assistants, nurses, psychologists, emergency care providers, home
health providers, definitive care providers, pharmacists and other
personnel involved in beneficiary care.
Organizations that are engaged in or support the delivery of
healthcare to include Hospitals, Ambulatory Centers, Provider
Practices, Integrated Delivery Networks, and Rehabilitation Centers.
Healthcare administrators with beneficiary information and medical
records management responsibilities including Health Information
Management (HIM) personnel, Registered Health Information
Administrator (RHIA), Registered Health Information Technicians
(RHIT), Inpatient/Outpatient Clinical Coding Specialists, Medical
Transcription Specialists, Medical Records Safety and Security staff,
Quality Control personnel, Physician Practice Managers, Pharmacy
Benefit Managers, and other management personnel or entities
involved in managing beneficiary information.
9
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
4
Members of Communities of
Interest
Payer Contractors
5
Payers*
6
EHR/EMR/PHR Vendors*
7
Additional Healthcare
Vendors*
8
Additional Healthcare
Suppliers
9
Beneficiaries*
10
Standards Organizations*
3/22/2016
Working Definition
Claims review programs and/or their specific implementation through
associated contractors and their subcontractors that are established to
prevent improper payments before a claim is processed as well as
identify any improper payments that can be recovered after a claim is
paid. These programs include but are not limited to:
MAC- Medicare Administrative Contractors
MRA –Medicare Recovery Auditor (formerly Recovery Audit
Contractors, RAC)
PERM – Payment Error Rate Measurement Program
SMRC – Supplemental Medical Review Contractor
CERT –Comprehensive Error Rate Testing Program
ZPICS – Zone Program Integrity Contractors
UMO – Utilization Management Organization
Any private or public entity that finances heath care delivery or
organizes health financing. This includes commercial for-profit health
insurers, non-profit health insurers, ERISA self-insured, state and
federal department agencies that oversee Medicaid and Medicare
health services delivery.
Vendors which provide specific EHR/PHR solutions to clinicians such as
software applications and software services. These suppliers may
include developers, providers, resellers, operators, and others who
may provide these or similar capabilities.
Vendors that provide health care solutions other than EHR/EMR/PHR
solutions such as software applications and services. Examples include:
integration vendors, data providers, medical device vendors, RMMS
(Remote Monitoring Management System) vendors, diagnostic
imaging service provider, clinical order system supply vendor,
transcription service vendors, clearinghouses, drug knowledge
suppliers, network infrastructure provider, Clinical Decision Support
(CDS) resource system, practice-based registry system suppliers, public
health registry system, immunization information system providers,
clinical genetic database/repository system vendor, practice
management systems, beneficiary accounting systems, and utilization
management, etc.
Medical suppliers providing services or devices to the beneficiary,
including but not limited to, Durable Medical Equipment Suppliers,
Clinical Laboratories, Oxygen Suppliers, etc.
Members of the public who receive healthcare services from, but not
limited to, ambulatory medical and/or surgical departments,
emergency department, physician’s and/or Non-Physician Provider’s
(NPP) office; inpatient hospitals including Critical Care Hospitals and
the VAH, Medical Home Care Models, Home Health and Hospice (HHH)
entities that provide care within the beneficiary’s home environment;
and/or a public health agency/department, including services provided
within the criminal justice system.
Organizations whose purpose is to define, harmonize and integrate
standards that will meet clinical and business needs for sharing
information among organizations and systems
10
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
11
Members of Communities of
Interest
Licensing and Certification
Organizations*
12
Operating Rule Authoring
Entities
13
Beacon Communities*
14
Federal Agencies*
15
Agent – [Healthcare
Clearinghouses and Business
Associate and their
subcontractors as defined by
Health Insurance Portability
and Accountability Act (HIPAA)
including Health Information
Handlers]
Health Information
Organization (HIO)*
16
17
Regional Extension Centers
(REC)*
18
Health Information Service
Providers (HISP)*
267
268
269
270
271
Working Definition
Federal, Nationally approved and State Licensure Boards and local
organizations, including accredited teaching academies, responsible
for developing guidelines for Implementation, providing Licensure and
defined scope of practice (healthcare services), to ensure that relevant
parties qualify and adhere to those guidelines, ensuring proper
licensing and certification under systems and other healthcare
solutions related to delivery of safe healthcare services
As defined in Affordable Care Act Section 1104, such entities develop
operating rules that define the necessary business rules and guidelines
for the electronic exchange of information that are not defined by a
standard or its implementation specifications. Rules developed under
ACA Section 1104 may not necessarily apply to this Use Case.
Selected communities of groups who have received federal funding
through the ONC to build and strengthen their health information
technology (health IT) infrastructure and exchange capabilities to
improve care coordination, increase the quality of care, and slow the
growth of health care spending.
Organizations within the federal government that deliver, regulate or
provide funding for health and health care
Any organization that handles health information on behalf of a
provider as a covered entity or under a Business Associate Agreement
(BAA) is an Agent. Many providers already use Agents to submit
claims, provide electronic health record systems, etc. Organizations
that are Agents include but are not limited to Healthcare
Clearinghouses, Release of Information vendors, Health Information
Exchanges, Electronic Health Record vendors, etc.
HIOs are the management organizations that provide Health
Information Exchange (HIE) services which are defined as the
mobilization of healthcare information sent electronically across
organizations within a region, community or hospital system
Entities that support and serve health care providers to help them
quickly become adept and meaningful users of electronic health
records (EHRs). RECs provide training and support services to assist
doctors and other providers in adopting EHRs, offer information and
guidance to help with EHR implementation, and give technical
assistance as needed.
Entities that serve as a node on the National Health & Information
Network to enable a private, secure and safe alternative method to
send and receive sensitive health information.
Table 1: Communities of Interest
4.0 Value Statement
Section Description: This section provides the high level description of the value and/or benefit of this
Use Case to the healthcare community. This section also identifies the anticipated outcomes and the
metrics that will be used to assess the success of the Use Case.
3/22/2016
11
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
272
273
274
275
276
277
The value of the esMD Initiative will be to provide consensus-based use cases, functional requirements,
standards references and implementation specifications/guidance representing combined input from a
broad range of stakeholders, including CMS, commercial Health Plans/Payers, Providers, and vendors.
This will promote a nationally standardized approach to structured and unstructured data requirements
for the electronic Determination of Coverage and the proof of validity and authorship of relevant
medical documentation.
278
279
280
281
Health Plans/Payers and Providers will benefit from this workgroup’s implementation guidance on
electronic determination of coverage, by moving away from current unstructured (paper and images of
medical documentation) information for selected specific use cases pertaining to services and devices.
Benefits include, but are not limited to:
282
283
284
285
286
287
288
289
290
291
292
A. Standardized data sets, templates, and secure exchange of required documentation to meet
293
294
295
296
Further, the use of structured data capture and FHIR standards will enable CMS and other Payers to
request or remind providers of specific information that may not exist in the medical record at the time
of template execution to facilitate creation of appropriate documentation required for coverage
determination.
297
298
299
300
301
5.0 Use Case Assumptions
302
303
304
305
306
307
308
309
310
311
B.
C.
D.
E.
F.
G.
H.
I.
payer coverage and payment rules
Utilization of structured data capture to facilitate the collection of service specific information
Improved ability to support complex logic in the collection of procedure/service specific
information and the initial determination of covered service options
Saving time, money and resources for CMS, Commercial Health Plans/Payers, and Providers
Elimination of the paper or unstructured data processing and its associated labor and error rate
Reduction of improper payment
Improved accounts receivable cycle for Providers, so payments are received sooner
Reduced time for benefit determination and notification from Payer to Provider
Reduced staff time spent handling paper, printing, imaging and mailing
Section Description: The Use Case Assumptions section outlines what needs to be in place to meet or
realize the requirements of the Use Case (i.e. the necessary privacy and security framework). These
points are more functional in nature and state the broad overarching concepts related to the Initiative.
The Use Case assumptions will serve as a starting point for subsequent harmonization activities.
A. The structured data required to design SDC templates is defined in the eDoC General Use Case
and specific user stories.
B. SDC template libraries are available to support and respond to queries for SDC templates
C. The provider “knows” how to request and interact with an SDC template
D. For CMS Medicare FFS, this Use Case addresses the data requirements for determination of
coverage, as identified within CMS eClinical Templates
For other Payers, their documentation requirements will determine data set requirements for
structured data capture
F. Multiple valid diagnostic, documentation, and order workflows currently exist, including those
of various Providers and Service Suppliers
E.
3/22/2016
12
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
G. All actors have secure access to their information systems (e.g. Providers having access to
H.
I.
J.
K.
L.
M.
N.
O.
create/update beneficiary records in an EHR system)
The identity of the provider interacting with the template, as well as the date and time, is
captured and stored in the medical record at the time the interaction is completed
Electronic transaction based exchanges must be supported between all of the actors of this Use
Case
All data collected and submitted for coverage determination must be a permanent part of the
beneficiary’s medical record maintained by the responsible provider/supplier
All actors shall create all transactions utilizing current industry accepted standards
All transactions will be compliant with existing security standards to ensure data is transmitted
with integrity, confidentiality, and reliability
All actors and systems shall ensure all transactions will be delivered in a timely manner
All required declarations of conflict of interest as determined by the relevant payer policies must
be available
All documentation and transactions created as part of this use case should have Author of
Record (AoR) L1 or L2 Digital Signatures as appropriate
6.0 Pre-Conditions
Section Description: The Pre-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.
A. All Actors, as defined in this Use Case, shall have their respective systems maintain the ability to
exchange information as required by this use case.
B. SDC Template library is available and accessible to the requesting EHR
C. The EHR “knows” the address of the SDC template library
D. The EHR has the ability to request, pre-populate, and present SDC templates
E. The EHR has the ability to record and store answers in response to SDC templates
F. The EHR will always give the provider the option of using the most recent version of a specific
template in the SDC Template Library
G. Actors that utilize digital signatures, as defined in this Use Case, have the ability to create and
sign the documentation defined by this use case – this may be implemented in the EHR or as a
third party service
H. The Physician and Physician-Referred Entity EHR systems that utilize digital signatures have and
maintain the ability to use esMD AoR compliant Digital Signatures to attest to the actions taken
on required documentation
7.0 Post Conditions
Section Description: The Post Conditions section describes the state of the system, from a technical
perspective, that will result after the execution of the operation, process activity or task.
A. Completed SDC template information is stored in the beneficiary’s medical record in the EHR
B. The stored SDC template information is available to the provider as part of the medical record
3/22/2016
13
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
352
353
354
355
356
357
358
C. The stored SDC template data elements are available to down-stream applications
D. EHR populates CDP1 externally defined clinical data element section with stored SDC template
data elements prior to exchanging CDP1 for the eDoC General Use Case
E. Payer or Payer Contractor information system should validate AoR Level 1 or Level 2 (as
appropriate) digital signatures and Delegation of Rights Assertions
F. Recipient’s receiving system must be able to consume and process the signed, completed
template (e.g. – storage, forwarding, adjudication, etc.)
359
360
361
362
8.0 Actors and Roles
363
364
365
366
The business actor must use a system to perform the functions and to participate in the information
interchange. The system or system actor has roles (send, receive, publish, subscribe or in some cases
display) and actions which involve exchanging content. Please see the table below for an example of
these designations.
367
NOTE: A Business Actor may be a Stakeholder and also can have more than one role.
Section Description: This table outlines the business actors that are participants in the information
exchange requirements for each scenario. A business actor is a person or organization that directly
participates in a scenario. Thus, as a person or organization, the actor can (and should) be a stakeholder.
Actor
Provider
System
EHR System
SDC Template Library
Template Library System
EHR Database
EHR System
368
Role
 Send request for SDC
Template
 Receive SDC Template
 Display pre-populated SDC
Template
 Modify and complete SDC
Pre-Populated Template
 Approve completed
template
 Digitally sign completed
template
 Access completed templates
within the EHR Database
 Optionally sends completed
template to intended
recipient
 Receive request for SDC
Template
 Send SDC Template to EHR
System
 Saves completed SDC
Template as part of
beneficiary’s medical record
 Provides access to template
Table 2: Actors and Roles
3/22/2016
14
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
369
370
371
372
373
9.0 Use Case Diagram
374
375
376
377
378
379
The Use Case diagram shows the association and interaction between the business actors and the Use
Case. It provides an overview of the actors (users or external systems), Use Cases, and the interactions
between them. The context diagram uses inputs and outputs to provide a pictorial representation of the
environment, both internal and external, where the exchange takes place. As the UML associated with
the diagrams proceeds through the different S&I Framework functions (i.e., Harmonization, Reference
Implementation), it is defined at a more granular level closer to the coding (implementation).
Section Description: This section conceptually represents the Business Actors interacting with the Use
Case and the User Stories. These diagrams characterize the types of interactions that an actor has with a
specific system. The section can include a Use Case Diagram and, if applicable, a Context Diagram
(examples are shown below).
Use Case Diagram
Provider
Selects template
Accesses the completed
template within EHR
Database
Template Library
System
Receives request for
template
Sends template to the EHR
System
Modifies/completes/
approves, and optionally,
digitally signs completed
template
Sends request for template
Receives template
Pre-populates template
Displays Pre-populated
template
Saves completed template
as part of beneficiary’s
medical record
Provides access to
template
Optionally sends
completed template to
intended recipient
Stores completed template
EHR System
EHR Database
380
381
Figure 1: Use Case Diagram
3/22/2016
15
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
382
383
Figure 2: Context Diagram
384
385
386
387
388
389
390
10.0 Scenario
391
Suggested Format: Paragraphs
392
393
394
395
396
397
398
399
400
This eDoC Use Case focuses on the functionality and interoperability required for a provider to retrieve
an eClinical Template from an external template library, auto-populate data within the template with
information from the beneficiary’s electronic health record (EHR), enter additional data into the eClinical
Template, digitally sign the eClinical Template, and save and store the completed eClinical Template
within the EHR system using a standard format. Optionally, the Provider may opt to send the completed
eClinical Template to a party of their choice, including the Payer, directly after digitally signing the
template. The standard format of the eClinical Templates could be used as a means to provide data to
end users. Data captured shall also be stored in the EHR associated with the individual beneficiary and
encounter as part of the permanent medical record.
Section Description: The scenario is a comprehensive description of the actors, interactions, activities,
and requirements associated with the information exchange. It is a prototypical sequence of interactions
in a business collaboration or the application context. Scenarios pertain to supporting the health
information exchange and, describing key flows, and are supplemented by User Stories (example shown
below). Section 10.0 serves as an introductory section while sections 10.1 through 10.5 provide more
specific details (examples shown below in all sections).
3/22/2016
16
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
401
402
403
404
405
10.1 User Story
406
Suggested Format: Paragraphs
407
408
409
410
411
412
413
414
415
416
417
418
419
A beneficiary has a face-to-face visit with their physician provider. The Provider evaluates and assesses
the Beneficiary and determines the beneficiary is in need of a service or device eligible for coverage
determination. The Provider sends a request for the appropriate template from the EHR System to the
SDC Template Library. The SDC Template Library receives the request from the EHR System. The SDC
Template Library sends the requested template to the EHR System. The EHR System receives the
template from the SDC Template Library. Where appropriate, the EHR System pre-populates the
template with information from the beneficiary’s medical record. The pre-populated template is
displayed for the provider to input additional clinical information and/or to modify the pre-populated
information. The provider approves, optionally digitally signs, and saves the completed template for the
EHR System to store the completed template within the EHR System database/storage infrastructure as
part of the beneficiary’s medical record. The EHR System optionally sends the completed, approved, and
signed template, along with other relevant clinical documentation, to the Payer or other intended
recipient.
420
421
422
423
424
10.2 Activity Diagram
425
426
427
The Activity Diagram illustrates the Use Case flows graphically, and represents the flow of events and
information between the actors. It also displays the main events/actions that are required for the data
exchange and the role of each system in supporting the exchange.
Section Description: User Stories summarize the interaction between the actors of the Use Case, and
specify what information is exchanged from a contextual perspective. Furthermore, the User Stories
describe the real world application as an example of the Scenario. These interactions are further
described in subsequent sections. Historically, user stories have been utilized to provide clinical context
Section Description: An Activity Diagram is a special form of a state transition diagram in which all or
most of the states are activity states or action states. An action state represents the fulfillment of
associated responsibilities in response to the communication received from the previous step. Most
transitions are triggered by completion of activities in the source states.
428
3/22/2016
17
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
eDoC eClinical Templates for SDC on FHIR: Activity Diagram
Provider
EHR System
Template Library System
Start
1. Selects the
appropriate
template within the
EHR System
2. Sends a request
for template to the
Template Library
System
6. Pre-populates the
template within the
EHR System
9. Inputs additional
data and/or modifies
template
8. Accesses prepopulated template
within the EHR
System
5. Receives the
template from the
Template Library
System
4. Sends the
requested template
to the EHR System
7. Displays the prepopulated template
within the EHR
System
11. Stores the completed
template within the EHR
Database as part of the
beneficiary’s medical
record
10. Approves,
optionally digitally
signs, and saves the
completed template
3. Receives the
request from the
EHR System
12. Optionally sends the
completed, approved, and
signed template, along
with other relevant
clinical documentation,
the Payer or intended
recipient.
End
429
430
Figure 3: Activity Diagram
431
432
433
434
435
10.2.1 Base Flow
Section Description: The Base Flow presents the step by step process of the information exchange
depicted in the activity diagram (above). It indicates the actor who performs the action, the description
of the event/action, and the associated inputs (records/data required to undertake the action) and
outputs (records/data produced by actions taken).
436
Suggested Format: Table
Step #
1
2
3
4
Actor
Provider/
EHR
System
EHR
System
SDC
Template
Library
SDC
Template
Library
3/22/2016
Role
Event/Description
Selects the appropriate
template within the
EHR System
Sends a request for
template to the SDC
Template Library
Inputs
Receiver
Receives the request
from the EHR System
Requested
Template
Sender
Sends the requested
template to the EHR
System
Selector
Sender
Outputs
Template selection
Request for
template
Requested template
18
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
Step #
Actor
5
EHR
System
6
EHR
System
7
EHR
System
8
Provider/
EHR
System
9
Provider/
EHR
System
10
Provider/
EHR
System
11
EHR
Database
Role
Event/Description
Receives the template
Receiver
from the SDC Template
Library
Pre-populates the
Data
template within the
Entry
EHR System
Displays the preDisplayer populated template
within the EHR System
Accesses prepopulated template
Receiver
within the EHR
Database
Inputs additional data
Modifier
and/or modifies
template
Approves, optionally
Approver/ digitally signs, and
Signer
saves the completed
template
Stores the completed
Retainer
template within the
EHR Database
437
Inputs
Outputs
Requested
Template
Requested
Template
Pre-populated
template
Pre-populated
template
Displayed template
Displayed Template
Displayed Template
Completed modified
template
Completed
template
Approved, digitally
signed, completed
template
Approved, digitally
signed, completed
template
Table 3: Base Flow of Scenario 1
438
439
440
441
10.2.2 Alternate Flow
Section Description: An Alternate Flow describes a series of events that are related to the scenario but
present a new pathway for the information exchange. Alternative flows can be used to capture error
messages returned if the data are unavailable or not permitted to be shared.
442
Suggested Format: Table
443
444
Note: All steps 1-11 in the Base Flow apply to the alternate flow. Step 12 below is in addition to steps 111 in the Base Flow.
Step #
12
Actor
Role
EHR
System
Sender
445
Event/Description
Optionally sends the
completed, approved,
and signed template,
along with other
relevant clinical
documentation, to the
Payer or other
intended recipient
Inputs
Outputs
Approved template
Table 4: Alternate Flow
3/22/2016
19
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
446
447
448
449
450
451
10.3 Functional Requirements
452
453
454
455
10.3.1 Information Interchange Requirements
Section Description: The Information Interchange Requirements define the system’s name and role. They
also specify the actions associated with the actual transport of content from the sending system to the
receiving system.
456
Suggested Format: Table
Section Description: Functional Requirements identify the capabilities a system in a role must have in
order to enable interoperable exchange of the healthcare data of interest. They provide a detailed
breakdown of the requirements in terms of the intended functional behaviors of the application. The
Functional Requirements include Information Interchange Requirements, System Requirements and
Dataset Requirements as indicated in sections 10.3.1-10.3.3 below.
Initiating
System
(describes
action)
EHR System
Send
SDC eClinical
Template
Library
EHR System
Send
EHR System
EHR System
(optional)
EHR System
(optional)
Information
Interchange
Requirement Name
Request for eClinical
Template
Requested eClinical
Template
(describes
action)
Receiving System
Receive
Receive
SDC eClinical Template
Library
EHR System
Prepopulates
Complete/
update
prepopulated
template
Apply
digital
signature
Pre-Population of
Template with EHR data
Display template for
provider
completion/update
Display
EHR System
Save/Store
completed
template
EHR System/EHR Database
Digitally signed eClinical
Template
EHR System/EHR Database
Send
Completed, signed
eClinical Template
Save/Store
completed,
digitally
signed
template
Receive
Payer/Other Party System
457
Table 5: Information Interchange Requirements
458
459
460
461
10.3.2 System Requirements
Section Description: This section lists the requirements internal to the system necessary to participate
successfully in the transaction. System requirements may also detail a required workflow that is essential
to the Use Case.
462
Suggested Format: Table
System
3/22/2016
System Requirement
20
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
System
EHR System
EHR System
EHR System
SDC eClinical Template Library
SDC eClinical Template Library
SDC eClinical Template Library
SDC eClinical Template Library
SDC eClinical Template Library
SDC eClinical Template Library
EHR System
EHR System
EHR System
EHR System
EHR System
EHR System (optional)
EHR System/EHR Database
EHR System/EHR Database (optional)
EHR System (optional)
EHR System
EHR System
463
464
465
466
467
468
469
System Requirement
Provide for ability to select a specific eClinical
template
Maintain real-time updates and connectivity with SDC
eClinical Template Library
Send request for eClinical Template
Be available for connectivity to and access by EHR System
Receive eClinical Template request from EHR System
Correctly identify requested template in standard format
Send the correct requested template in standard format
Update existing templates
Receive and store new templates
Receive eClinical Template from library
Auto-population of displayed template with EHR-derived
patient data
Incorporate structured data in standard format into
template
Display an editable template containing pre-populated
patient data
Support provider interaction with editable template
Optionally digitally sign completed template
Incorporate the template information into the
beneficiary’s medical record
Optionally save and store the completed template in
standard format
Send completed and signed template to defined
recipient (Payer/other)
Has capability of identifying the author of record of a
completed template as metadata associated with the
template
Has capability of identifying the recipient of a
template from metadata with the template
Table 6: System Requirements
10.4 Sequence Diagram
Section Description: A Sequence Diagram is primarily used to show the interactions between objects in
the sequential order that they occur. This representation can make it easy to communicate how the
exchange works by displaying how the different components interact. The primary use of the diagram is
in the transition from requirements expressed as use cases to the next and more formal level of
refinement. Note: Horizontal lines are used to identify the specific activity between the systems.
3/22/2016
21
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
Provider (EHR
System)
SDC Template
Library System
EHR System
1. Selects the appropriate template
within the EHR System
2. Sends a request for template to
the Template Library System
3. Receives the request from
the EHR System
4. Sends the requested template
to the EHR System
5. Receives the template from the
Template Library System
6. Pre-populates the template
within the EHR System
7. Displays the pre-populated
template within the EHR System
for modification
8. Accesses pre-populated template
within the EHR Database
9. Inputs additional data and/or
modifies template
10. Approves, optionally digitally signs,
and optionally saves the completed
template
11. Stores the completed template
and other relevant information
within the EHR Database as part
of the beneficiary’s medical record
12. Optionally sends completed, approved,
and signed template, along with other
relevant clinical documentation, to the
Payer or intended recipient
Provider (EHR
System)
470
471
EHR System
SDC Template
Library System
Figure 4: Sequence Diagram
472
473
474
475
476
11.0 Risks, Issues and Obstacles
477
Suggested Format: Paragraphs, Bulleted List
Section Description: The Risks, Issues and Obstacles section lists the concerns that might interfere with
meeting the requirements of the Use Case. Any Initiative wide points should be made above between
both the Initiative Overview and the Initiative Challenge Statement sections. The information within this
section will be vital to the harmonization activities.
3/22/2016
22
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
Risks/Issues
A. Ensuring secure, trustable communications between providers, template libraries, technology
B.
suppliers, as well as the intended recipient of the completed template
The burden to individual providers to obtain and manage digital signing certificates
a) The ability to obtain and manage digital signing certificates may deter providers from
participating in the transactions as outlined in this use case
b) Risks associated with the digital identity process
 Compliance with Identity Proofing Requirements
 Compliance with Certificate Lifecycle (including revocation)
 Compliance with Delegation of Rights (including validation/revocation)
 Issues inherently in the creation and use of X.509v3+ Digital Certificates
C. Dependencies on schedule of and deliverables from the HL7 and S&I SDC initiatives
D. Unintended disclosure of Personal Health Information
E. Ensuring consistent and reliable mechanisms for establishing and updating documentation
requirements from changing payer payment policies
F. Availability of solutions to solving technical, operational, and/or financial barriers preventing
platforms, systems, and/or services from having adequate capacity and logic to accommodate
the volume of eDoC transactions
G. Overwriting/updating existing information
H. Duplicate data entry
I. Accuracy and reliability of EHR data
J. Inaccurate data pulled into the template during auto-population from a patient’s previous visit
Obstacles
A. Compliance with NIST, FIPS, and FISMA in sending PHI from Providers to Federal Agencies and
B.
C.
D.
E.
F.
G.
H.
I.
J.
K.
their agents
Compliance with HIPAA in sending PHI from Providers to intended recipients
Policy regarding signatures and/or provenance of documentation
Identifying implementable solutions to establish provenance that minimize burden to Providers
Lack of vendor (PMS and EMR) engagement in process
a) Insufficient engagement and participation by vendor communities, and eventual
adoption in Certified EHR products
b) Insufficient commitment and lack of participation by various vendors and organizations
in pilots
Technical, operational, and/or financial barriers preventing platforms, systems, and/or services
from having adequate capacity and logic to accommodate the volume of eDoC transactions
Accessibility of a template library or repository
Identification of a useful set of data elements for templates that can auto-populate with data
extracted from the existing EHR
Standards and solutions may not scale to small HIT vendors and small practices
Not all EHR systems offer or can support auto-population functionality
Lack of standardized format of EHR data, including structured and coded data
3/22/2016
23
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
519
520
521
522
523
524
525
L. Providers may not have the awareness or knowledge on process to query for and fill out the
template
M. Provider and patient may be burdened by the process of filling templates as part of the patient
encounter
N. Competing national CDE structure standardization initiatives
O. Developing standardized CDEs for eClinical Templates
526
527
528
529
530
531
532
533
534
535
536
537
538
12.0 Dataset Requirements
539
540
541
542
Furthermore, it is important to understand that the identification of data elements forms the foundation
for harmonization activities. The data elements identified in the Use Case set constraints on the contents
of documents and messages. Workgroups should make every effort to ensure that the dataset and data
element requirements are complete, accurate, and precise.
543
544
545
546
NOTE: This content of this section will vary per Initiative as the references are contingent upon the
specific list of Functional Requirements that is developed by the Workgroup. The Use Case Simplification
Workgroup is tasked with creating a structure for this section that will eventually be applied to all Use
Cases. Data element sets are defined for reuse within the Use Case Simplification Workgroup
547
548
Suggested Format: Table, Bulleted Lists (including data element name, definition, example
representation, and source vocabulary)
Section Description: This table lists the data elements and data element sets that will be available within
the message or document. Historically, the optional/required nature of each data element is deferred to
the discussions during the harmonization phase. Since the experts who know what data are to be
exchanged may be participating at this stage, it is essential that these dataset requirements be as fully
specified as is possible. Each data element listed below is necessary for some aspect of the Use Case;
however, the table does not specify exactly how they may be used together. All data element sets may
contain multiple data elements unless otherwise stated. For the purposes of this section, do not assume
that any data elements are inferred. Be sure to provide elements at their most granular level. For
example, if it is necessary to specify a zip code, do not use the less specific data element set, ‘address’. In
addition, specify the base standard from which they are chosen, i.e., a specific vocabulary (SNOMED),
code set (gender, marital status), classification (ICD-10-CM), or other, and who maintains this
terminology.
549
Section
Data Element

Multiple Values
(yes/no)
Data
Element
Description
Vocabulary
Additional Notes
<<Bulleted list>>
3/22/2016
24
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
550
Table 7: Dataset Requirements
551
3/22/2016
25
Use Case Development and Functional Requirements for Interoperability
DRAFT Structured Data Capture and FHIR for Electronic Determination of Coverage Use Case
552
553
554
555
Appendices
556
557
Appendix A: Related Use Cases
558
559
Appendix B: Previous Work Efforts
560
561
Appendix C: References
The content of this section varies depending on the needs brought forth by the Community. Some Use
Cases may have appendices that are specific to their content and issues. The appendices listed below are
suggested for inclusion.



<<Bulleted List>>
<<Bulleted List>>
<<Bulleted List>>
562
3/22/2016
26