The Centers for Medicare & Medicaid
Services and the Office of the National
Coordinator for Health Information
Technology
Standards & Interoperability Framework
Electronic Submission of Medical Documentation Electronic
Determination of Coverage: Companion Guide with ASC
X12N 275 (X275) Transaction Sets
August 20, 2014
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
1
Table of Contents
2
3
4
5
6
7
8
9
10
11
12
1. Introduction ............................................................................................................................................ 3
1.1 Purpose & Business Needs Supported............................................................................................ 3
1.2 Intended Audience ........................................................................................................................... 3
1.3 Requisite Knowledge & Referenced Documents and Standards .................................................... 4
1.4 Assumptions ..................................................................................................................................... 4
1.5 Relationship to Previous esMD Effort .............................................................................................. 4
1.6 Referenced Documents and Standards ........................................................................................... 5
1.6.1 esMD Specific References ................................................................................................... 5
1.6.2 Payload Specific References ................................................................................................ 6
1.6.3 Transport Specific References ............................................................................................. 7
1.6.4 Provider Directories Specific References ............................................................................. 8
13
14
2. Process for Exchange of eDoC Documentation ................................................................................. 8
2.1 Pre-Conditions ................................................................................................................................. 8
15
16
17
18
19
20
21
22
23
3. esMD eDoC Additional Documentation Submission for Claims Adjudication and Pre/Post
Payment Audit ............................................................................................................................................. 8
3.1 Solicited 275 Flow ............................................................................................................................ 9
3.2 Unsolicited 275 Flow (Same Interchange) ....................................................................................... 9
3.3 Unsolicited 275 Flow (Separate Interchanges) .............................................................................. 10
3.4 Traceability between Requests and Responses ............................................................................ 10
3.4.1 Matching with 837 ............................................................................................................... 11
3.4.2 Matching with 277 ............................................................................................................... 11
3.5 ASC X12N 275 TR3 Data Element Grid (Information Requirements) ........................................... 12
24
25
26
4. esMD eDoC Transport Options ........................................................................................................... 15
4.1 ASC X12 Transaction Error Responses ........................................................................................ 15
4.2 esMD eDoC Security Options ........................................................................................................ 16
27
28
29
30
5. Overview of relevant standards for ASC X12N 275 over Phase II CAQH CORE Rule 270:
Connectivity Rule 2.2.0 ............................................................................................................................. 16
5.1 Phase II CORE 270: Connectivity Rule version 2.2.0 .................................................................... 16
5.2 Error Handling ................................................................................................................................ 18
31
32
33
34
35
6. Overview of Relevant Standards for ASC X12N 275 over CONNECT with CAQH CORE X12
Document Submission Service Interface Specification and XDR ....................................................... 18
6.1 ASC X12N 275 over CONNECT (CORE) ...................................................................................... 18
6.2 esMD Security Metadata ................................................................................................................ 19
6.3 CONNECT SAML Assertions ......................................................................................................... 20
36
37
7. Overview of Relevant Standards over Direct using XDM ................................................................ 20
7.1 IHE XD* Metadata .......................................................................................................................... 22
38
39
40
41
42
43
Appendix A.
X12 Error Flows for ASC X12N 275 ............................................................................. 24
Appendix B.
Example ASC X12N 275 ................................................................................................ 25
B.1 ASC X12N 275 (Solicited) .............................................................................................................. 25
B.2 ASC X12N 275 (Unsolicited) .......................................................................................................... 25
Appendix C: Glossary of Terms .............................................................................................................. 26
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 2 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
44
1. Introduction
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
The Electronic Submission of Medical Documentation (esMD) Initiative intends to replace current paper
processes for medical documentation requests/submissions with an electronic alternative. This initiative is
focused on providing solutions that address CMS prior-authorization, pre-payment, and post-payment
reviews specifically. However, through the participation of other relevant stakeholders, the outputs of this
initiative have expanded to reflect the requirements of other payers, providers, and additional relevant
stakeholders.
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
The Centers for Medicare & Medicaid Services (CMS) Medicare Fee for Service (FFS) and other Health
Plans/Payers need a standardized, implementable, machine-interoperable electronic solution to reduce
the time, expense, and paper required to document patient conditions and proposed or provided services
as part of current processing of benefit determination based on payer coverage rules.
89
90
91
This companion guide is intended to assist Providers, Agents, Referred-to Entities, Payers, Payer
Contractors, and any other health care organization that participates in the process to make electronic
determinations of coverage.
The esMD Initiative focuses on identifying the requirements, core data sets, and standards to support
these specific use cases:
1. Provider Registration with a Payer to receive eMDRs1
2. Secure sending of eMDRs from Payer/Contractors to Registration Requestors
3. Replacement of wet signatures with a digital signature
4. Electronic Determination of Coverage documentation requirements
This companion guide addresses the Electronic Determination of Coverage (eDoC) use case, and covers
the requirements for sending additional documentation to support the processing of electronic
determinations of coverage.
1.1
Purpose & Business Needs Supported
This companion guide benefits Health Plans/Payers and Providers by providing guidance on electronic
determinations of coverage and by moving away from paper-based or unstructured images of medical
documentation for selected specific use cases pertaining to certain payment areas that are of high
interest for reducing reduce improper payments and fraud.
Additional benefits include:
 Standardized data sets, templates, structured data capture and secure exchange of required
documentation as per payer coverage and payment rules
 Saving time, money and resources for CMS, Commercial Health Plans/Payers, and Providers
 Elimination of the paper and its associated labor and error rate
 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
This guidance covers the:
 Technical transport, standards, and authentication needed to allow Payers and Payer Contractors
to make electronic determinations of coverage.
 CMS-specific requirements (when they differ from commercial Payers)
1.2
Intended Audience
eMDR – Electronic Medical Documentation Request refers to a request sent electronically from a Payer
or Payer Contractor
1
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 3 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
1.3
Requisite Knowledge & Referenced Documents and Standards








1.4
Assumptions

115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
HL7 Clinical Document Architecture, Release 2:
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, Release 2 – US
Realm. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258
Prior esMD efforts (see Section 1.6.1: esMD Specific References)
For participants interacting with CMS have completed required CMS or eHealth Exchange2
onboarding as explained in Section 2 of the “Implementation Guide for Health Information
Handlers for Electronic Submission of Medical Documentation Project:”
http://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-andSystems/ESMD/Downloads/Release30_esMDImplementationGuide_v5-2.pdf
ASC X12N/006020X275 Transaction Set Implementation Guide – Additional Information to
Support a Health Care Claim or Encounter (275): http://store.x12.org/store/ and
http://examples.x12.org
ASC X12N/006020X268 Transaction Set Implementation Guide – Health Care Claim Request for
Additional Information (277): http://store.x12.org/store/ and http://examples.x12.org/
ASC X12N/005010X222 Transaction Set Implementation Guide – Health Care Claim:
Professional (837): http://store.x12.org/store/ and http://examples.x12.org/
CAQH CORE Connectivity rules, which facilitate interoperability, improve utilization of
administrative transactions, enhance efficiency and lower the cost of information exchange in
healthcare: http://www.caqh.org/CORE_phase2.php










Multiple valid diagnostic, documentation, and order workflows currently exist, including those of
various Providers and Service Suppliers
All actors have secure access to their information systems (e.g., Providers having access to
create/update beneficiary records in an EHR system)
All documentation and transactions created as part of this use case shall have Author of Record
(AoR) L1 or L2 Digital Signatures as appropriate
All actors shall create all transactions utilizing current industry-accepted standards
Electronic transaction-based exchanges must be supported between all the actors of this
guidance
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
Documentation requirements are the same regardless of transaction methods employed
Documentation submitted electronically by Provider/supplier actors covered by this guidance
must be supported
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 required declarations of conflict of interest as determined by the relevant payer policies must
be available
134
1.5
Relationship to Previous esMD Effort
135
136
As of September 15, 2011, a pilot group of Health Information Handlers (HIHs) and Medicare Review
Contractors began accepting electronic submissions of medical documentation from Providers, as part of
2
eHealth Exchange was formerly known as the NwHIN Exchange, and is now known as Healtheway
Exchange.
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 4 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
the first phase of esMD. These electronic submissions consist of an unstructured .PDF format of a
scanned image, within an IHE XDR or ASC X12 275 wrapper.
182
183
184
These sections list the materials referenced in the guide.
185
186
187
188
There is added value to CMS, Commercial Payers, and Providers in pursuing additional automation of the
electronic request and submissions process. CMS joined the ONC Standards & Interoperability (S&I)
Framework to develop solutions to enable CMS and Review Contractors to send electronic medical
requests (eMDRs), eliminating the need to send the paper letters via mail or fax.
In joining the S&I Framework, the 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 Providers dealing with multiple
Payers, the requirements of multiple Payer entities were incorporated into the Use Cases.
There was a need on CMS’s part to: 1) verify the identity of the individual or organization prior to sending
Protected Health Information (PHI) contained in the eMDR and 2) to ensure the authenticity of the
documents submitted in response to an eMDR. Prior implementation guides (see Section 1.6.1: esMD
Specific References) identify standards and methods to accomplish these goals.
The esMD implementation guides for esMD’s Author of Record work stream focus on three Author of
Record Levels:
 Level 1 – application of a digital signature to a document bundle
 Level 2 – application of a digital signature to a single document
 Level 3 – application of one or more digital signatures to content within a document
AoR Level 1 supports both the use case of a document owner applying a digital signature to a document
bundle or transaction and the use case of a document owner delegating another party the right to apply a
digital signature to a document bundle on his/her behalf.
AoR Level 2 supports both the use case of a document owner applying a digital signature to a single
document and the use case of a document owner delegating another party the right to apply a digital
signature to a single document on his/her behalf. In the case of a digital signature applied to a CDA
document, the signer may indicate the role and purpose for the signature.
AoR Level 3 guidance will be developed in 2014.
This guide builds on the previous esMD implementation guides to incorporate transport, payload and
security requirements for supporting electronic determinations of coverage. It provides guidance on the
use of ASC X12N 275 (006020X275) (hereafter referred to as “ASC X12N 275” or “275”) transactions to
provide additional medical documentation (in a solicited response to a 277 or an unsolicited response
with an 837).
This guide refers only to the ASC X12N 275 (version 006020X275)
1.6
Referenced Documents and Standards
1.6.1 esMD Specific References

Implementation Guide for Health Information Handlers for Electronic Submission of Medical
Documentation Project (esMD Phase 1)
o Org/SDO: CMS
o Version: 5.2
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 5 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
o





Link: http://www.cms.gov/Research-Statistics-Data-and-Systems/Computer-Data-andSystems/ESMD/Downloads/Release30_esMDImplementationGuide_v5-2.pdf
esMD Provider Profiles Authentication: Registration Implementation Guide
o Org/SDO: ONC S&I Framework
o Version: 1.0
o Link:
http://wiki.siframework.org/file/view/esMD%20Use%20Case%201%20Implementation%2
0Guide%20Final.docx
esMD Secure Transportation and Structured Content of eMDRs Implementation Guide
o Org/SDO: ONC S&I Framework
o Version 1.0
o Link:
http://wiki.siframework.org/file/view/esMD%20Use%20Case%202%20Implementation%2
0Guide%20Final.docx/425295588/esMD%20Use%20Case%202%20Implementation%20
Guide%20Final.docx
esMD Author of Record Level 1 Implementation Guide
o Org/SDO: ONC S&I Framework
o Version: 1.0
o Link:
http://wiki.siframework.org/file/view/esMD%20AoR%20Level%201%20Implementation%2
0Guide%20DRAFT%20v1.6.docx/436981852/esMD%20AoR%20Level%201%20Implem
entation%20Guide%20DRAFT%20v1.6.docx
esMD Author of Record Level 2 Implementation Guide
o Org/SDO: ONC S&I Framework
o Version: 1.0
o Link:
http://wiki.siframework.org/file/view/SIFramework_esMD_AoR_Level_2_UC_DRAFT%20
V2%20032.docx/513763172/SIFramework_esMD_AoR_Level_2_UC_DRAFT%20V2%20032.docx
esMD Electronic Determination of Coverage Use Case
o Org/SDO: ONC S&I Framework
o Version: 1.0
o Link: http://wiki.siframework.org/esMD+-+Electronic+Determination+of+Coverage
1.6.2 Payload Specific References




HL7 CDA Release 2
o Org/SDO: Health Level 7
o Version: Release 2
o Link: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1.1 US Realm (C-CDA)
o Org/SDO: HL7
o Version: 1.1
o Link: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=258
ASC X12N/006020X275 TR3 – Additional Information to Support a Health Care Claim or
Encounter (275)
o Org/SDO: ASC X12
o Version: 6020
o Link: Draft Version
ASC X12N/006020X268 TR3 – Health Care Claim Request for Additional Information (277)
o Org/SDO: ASC X12
o Version: 6020
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 6 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294



o Link: Draft version
ASC X12N/005010X333 TR3 – Health Care Claim: Professional (837)
o Org/SDO: ASC X12
o Version: 5010
o Link: http://store.x12.org/store/healthcare-5010-original-guides
ASC X12C/005010X231 TR3 – Implementation Acknowledgment For Health Care Insurance
(999)
o Org/SDO: ASC X12
o Version: 5010
o Link: http://store.x12.org/store/healthcare-5010-original-guides
o Includes TA1 Interchange Acknowledgment segment
ASC X12N/005010X186 TR3 – Application Reporting for Insurance (824)
o Org/SDO: ASC X12
o Version: 5010
o Link: http://store.x12.org/store/healthcare-5010-original-guides
1.6.3 Transport Specific References








NwHIN Exchange Service Interface Specification CAQH CORE ASC X12 Document Submission
Service Interface Specifications
o Org/SDO: eHealth Exchange
o Version: 1.0
o Link: http://healthewayinc.org/images/Content/Documents/specs/2011/caqh-core-x12document-submission-service-specification-v1-0-508.pdf
NwHIN Exchange Messaging Platform Specification
o Org/SDO: eHealth Exchange
o Version: 3.0
o Link: http://healthewayinc.org/images/Content/Documents/specs/2011/nhin-messagingplatform-production-specification-v3.0.pdf
NwHIN Exchange Authorization Framework Specification
o Org/SDO: eHealth Exchange
o Version: 3.0
o Link: http://healthewayinc.org/images/Content/Documents/specs/2011/nhin-authorizationframework-production-specification-v3.0.pdf
NwHIN Exchange Document Submission Production Web Service Interface Specifications
o Org/SDO: eHealth Exchange
o Version: 2.0
o Link: http://healthewayinc.org/images/Content/Documents/specs/2011/nhin-documentsubmission-production-specification-v2-0-a.pdf
CAQH CORE Connectivity Rules
o Org/SDO: CAQH CORE
o Version: 2.2.0
o Link: http://www.caqh.org/pdf/EDITED5010/270-v5010.pdf
XDR and XDM for Direct Messaging Specification
o Org/SDO: DirectTrust.org
o Version: 1.0
o Link: http://wiki.directproject.org/file/view/2011-03-09%20PDF%20%20XDR%20and%20XDM%20for%20Direct%20Messaging%20Specification_FINAL.pdf
IHE XDR Cross-Enterprise Document Reliable Interchange (XDR)
o Org/SDO: IHE
o Version: 9.0
o Link: http://wiki.ihe.net/index.php?title=Crossenterprise_Document_Reliable_Interchange
IHE XDS Provide and Register Document Set-b
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 7 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
295
296
297
298
299
o
o
o
Org/SDO: IHE
Version: 9.0
Link: http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol2b.pdf
1.6.4 Provider Directories Specific References

300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315


Query for Electronic Service Information Including Electronic Address Use Case
o Org/SDO: ONC S&I Framework
o Link: http://wiki.siframework.org/PD++Query+for+Electronic+Service+Information+including+Electronic+Address++Use+Case
S&I Framework’s Provider Directories Guidance
o Org/SDO: ONC S&I Framework
o Version: Non-balloted Draft
o Link:
http://wiki.siframework.org/file/view/Provider+Directories+Use+Case+2+Guidance+DRAF
T.docx
Provider Directory Guidance for esMD
o Org/SDO: ONC S&I Framework
o Link:
http://wiki.siframework.org/file/view/Provider+Directories+Guidance+for+esMD+Final.doc
x
316
2. Process for Exchange of eDoC Documentation
317
318
319
320
321
322
323
324
325
The process detailed below enables Providers and Payers to exchange electronic documentation for prior
authorization of various services or devices to determine whether coverage can be provided to a
beneficiary. After review of the prior authorization request and associated documentation provided by a
Physician or Physician-Referred Entity, a Payer can determine whether the requested or provided service
(or device) is medically necessary, appropriate, and documented as required by coverage policy. When a
Provider needs to submit additional documentation for the purposes of claims adjudication or pre or post
payment audit, he/she can do so via the 275.
326
327
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.
328
329
330
331
332
333
334
335
336
337
338
339
340
341
2.1
Pre-Conditions



All Actors have the ability to create and sign the documentation specified in this guide – this may
be implemented in the EHR or as a third party service.
The Physician and Physician-Referred Entity EHR systems shall have and maintain the ability to
use esMD AoR compliant Digital Signatures to attest to the actions taken on required documents.
All Actors shall have their respective systems maintain the ability to exchange information as
required by this guide.
3. esMD eDoC Additional Documentation Submission for Claims
Adjudication and Pre/Post Payment Audit
The ASC X12N 275 Additional Information to Support a Health Care Claim or Encounter (006020X275)
Technical Report Type 3 provides the standardized data requirements and content for all users who
submit additional documentation in a solicited or unsolicited manner.
The 275 allows the Provider to send additional information in response to an X12N 277 (006020X268)
Health Care Claim Request for Additional Information (solicited). The 275 may also be sent with the initial
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 8 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
342
343
344
345
346
347
X12N 837 (005010X222) Health Care Claim (unsolicited). These transactions may be sent in the same
interchange or in separate interchanges.
This guide is intended to be used as a companion guide to the ASC X12N 275 TR3, and is not intended
to contradict or exceed established ASC X12 standards.
Name of Specification
ASC X12N 275 (006020X275)
348
349
350
351
352
353
354
355
3.1
Purpose
Allows a Provider to submit additional information about a claim or
encounter to a Payer
Solicited 275 Flow
In the solicited 275 workflow:
1) The Provider sends an 837 Health Care Claim to the Payer
2) The Payer requests additional information via a 277 Request
3) The Provider sends a 275 Additional Information transaction to the Payer
Figure 3-1: 275 Solicited Business Flow
837 Health Care Claim
277 Request for Additional Information
Payer /
CMS
Provider
275 Additional Information to Support
a Health Care Claim or Encounter
356
357
358
359
3.2
360
361
In the unsolicited 275 workflow (same interchange), the Provider submits to the Payer an 837 Health
Care Claim along with the 275 Additional Information.
Unsolicited 275 Flow (Same Interchange)
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 9 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
362
Figure 3-2: 275 Unsolicited Business Flow (Same Transaction)
Provider
363
364
365
366
367
368
369
370
371
3.3
837 Health Care Claim
+
275 Additional Information to Support
a Health Care Claim or Encounter
Payer
Unsolicited 275 Flow (Separate Interchanges)
In the unsolicited 275 workflow (separate interchanges):
1. The Provider sends an 837 Health Care Claim to the Payer
2. The Provider sends the 275 Additional Information in a separate exchange
Figure 3-3: 275 Unsolicited Business Flow (Separate Transaction) 3
837 Health Care Claim
Provider
Payer
275 Additional Information to Support
a Health Care Claim or Encounter
372
373
374
3.4
375
376
377
The ASC X12N 275 has two related transactions types: the 277 (Health Care Claim Request for
Additional Information), and the 837 (Health Care Claim (Institutional, Professional and Dental)).
Traceability is important in both paper-based exchanges and electronic exchanges of documents.
Traceability between Requests and Responses
3
In this scenario, the 275 may follow the same logical path between provider and payer, OR, it may follow
a different logical path (e.g., using a different service, such as an 837 claim going through a
clearinghouse to a Medicare Administrative Contractor (MAC), and the 275 going through esMD to the
same MAC)
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 10 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
378
379
380
381
382
383
384
385
386
387
Matching responses to their original requests should be accommodated through the available X12 data
segments, which should appear in metadata or paper cover sheets (e.g., fax transmissions). There are
two document types between which data elements in the 275 may be matched: the 837 and the 277.
388
389
390
391
Claim submission via the 837 is generally the first step in an adjudication process. When additional
information must be sent with the 837 in order to complete this process, an unsolicited 275 is sent. The
table below lists the mapping of data elements between the 275 and 837.
The mappings in the following tables are summarized from Section 3.5: ASC X12N 275 TR3 Data
Element Grid (Information Requirements) below. For complete cross-reference information and
explanation, see the ASC X12N 275 (006020X275): Additional Information to Support a Health Care
Claim or Encounter.
3.4.1 Matching with 837
275
392
393
394
395
396
837
Notes
Loop 1000A – NM103
Loop 1000A – NM108
Loop 1100C – N3 segment
Loop 1100C – N4 segment
Loop 1000D – NM1 segment
Loop 2010BB – NM103
Loop 2010BB – NM108
Loop 2010AA – N3 segment
Loop 2010AA – N4 segment
Loop 2010CA – NM1 segment
Loop 1000D – REF02
Loop 2300 – CLM01
Loop 1000D – REF02
Loop 2300 – Must be a concatenation
of CLM05-01 and CLM05-03
Loop 2000A – TRN02
Loop 2300 – PWK06a
Loop 2400 – PWK06b
Refers to the segment REF – Provider’s
Assigned Claim Identifier
Refers to the segment REF – Institutional
Type of Bill
aWhen attachment applies to entire 837
bWhen
attachment applies to specific
service line
3.4.2 Matching with 277
A payer may also request additional information in support of adjudication using a 277. The table below
lists the mapping of data elements between the 275 and 277.
275
277
Loop 1000A – NM103
Loop 1000A – NM108
Loop 2100A – NM103
Loop 2100A – NM108
Loop 1000A – PER segment
Loop 2210D – PER segment
Loop 1000D – REF02
Loop 2200D – REF02
Loop 1000D – REF02
Loop 2200D – REF02 (see
notes)
Loop 1000D – REF segment
Loop 2200D – REF segment
Loop 2000A – TRN segment
Loop 2000A – STC segment
Loop 2200D – TRN segment
Loop 2220D – STC segment
Loop 2200D – REF segment
(see notes)
Loop 2200D – REF segment
(see notes)
Loop 2000A – REF segment
Loop 2000A – REF segment
Loop 2000A – HI segment
Notes
Required when PER segment of 2210D loop of
277 is reported
Refers to the segment REF – Provider’s Assigned
Claim Identifier
Refers to the segment REF – Institutional Type of
Bill
Refers to the segment REF – Claim Identifier for
Transmission Intermediaries
Refers to the segment REF – Case Reference
Number
Refers to the segment REF – Attachment Request
Tracking Identifier
Where a specific LOINC code is requested in the
277, and the documentation submitted is specific
to the LOINC code requested, then the requested
LOINC code should be included in the HI segment
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 11 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
397
3.5
ASC X12N 275 TR3 Data Element Grid (Information Requirements)
398
399
400
401
402
403
404
The table below maps the esMD data requirements to the ASC X12N 275. This guide constrains the allowed codes within certain data elements
by specifying those codes within the “Allowable Code(s)” columns. Blank cells under the “Allowable Code(s)” columns indicate that no constraints
have been applied. The “Comments” columns indicate where a data element is required, or if additional constraints or comments are warranted.
By default, this guide constrains data elements to all Payers using esMD standards (including Medicare FFS). The “Comments” columns indicate
where constraints only apply to Medicare FFS (rather than all Payers).
Data
Element/
Segment
esMD Unsolicited
Name
Allowable
Code(s)
Comments
esMD Solicited
Allowable
Code(s)
Comments
1000A Loop – Payer Name
NM1
NM103
NM108
PER
Payer Name
Last Name or
Organization Name
Identification Code
Qualifier
Payer Contact
Information
Must map to 2010BB loop – NM103
element within 837
Must map to 2010BB loop – NM108
element within 837
Must map to 2100A loop – NM103 within
277
Must map to 2100A loop – NM108 within
277
Required when PER segment of 2210D loop
of 277 is reported
1000B Loop – Submitter Information
NM1
NM102
Submitter
Information
Entity Type Qualifier
1000C Loop – Provider Name Information
NM1
Provider Name
Information
REF
Provider Secondary
Information
Should match 2010AA - NM1 on 837
(Billing Provider)
Not applicable for Medicare FFS
provider/supplier billing. Beneficiary billing
is not anticipated to use HIPAA-mandated
X12 transactions
Should match 2010AA - NM1 on 837 (Billing
Provider)
Not applicable for Medicare FFS
provider/supplier billing. Beneficiary billing is
not anticipated to use HIPAA-mandated X12
transactions
Should match 2010AA - N3 on 837 (Billing
Provider)
Should match 2010AA - N4 on 837 (Billing
Provider)
Should match 2010AA - N3 on 837 (Billing
Provider)
Should match 2010AA - N4 on 837 (Billing
Provider)
Should match 2010CA - NM1 on 837
(Billing Provider)
Should match 2010CA - NM1 on 837 (Billing
Provider)
1100C Loop – Provider Identification
N3
Provider Address
N4
Provider City, State,
Zip Code
1000D Loop – Patient Name
NM1
Patient Name
NM108 Identification Code
MI
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
MI
Page 12 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
Data
Element/
Segment
esMD Unsolicited
Name
Allowable
Code(s)
Comments
esMD Solicited
Allowable
Code(s)
Comments
Qualifier
NM109
REF
REF02
REF
REF02
REF
REF
Identification Code
Provider’s Assigned
Claim Identifier
Reference
Identification
Institutional Type of
Bill
Reference
Identification
Medical Record
Identification
Number
Claim Identifier for
Transmission
Intermediaries
For Medicare FFS, this must be the HICN
(Health Insurance Claim Number)
For Medicare FFS, this must be the HICN
(Health Insurance Claim Number)
Must match 2300 loop - CLM01 within 837
Must match 2200D loop - REF02 within 277
Required when Institutional Type of Bill is
submitted in 837, or is included in 2200D REF segment of 277
Must be a concatenation of CLM05-01 and
CLM05-03 within 837
Required when Institutional Type of Bill is
submitted in 837, or is included in 2200D REF segment of 277
Required when submitted in the original
claim
Required when submitted in the original
claim
Must match 2200D loop - REF02 within 277
Required when submitted in the original
claim (2200D - REF segment of the 277)
2000A Loop – Assigned Number
TRN
TRN01
TRN02
STC
REF
REF
HI
Payer Claim Control
Trace Number /
Provider Attachment
Control Trace
Number
Trace Type Code
Reference
Identification
1
2
If attachment applies to entire 837, TRN02
must match 2300 loop - PWK06 from 837.
If attachment applies to specific service
line, TRN02 must match 2400 loop PWK06 for that service line
Status Information
Case Reference
Identifier
Attachment Request
Tracking Identifier
Health Care
Information Codes
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Must match 2200D loop - TRN segment
within the 277
Required and must match 2220D loop - STC
segment within the 277
Must match loop 2200D - REF segment
within the 277, if it exists there
Must match loop 2200D - REF segment
within the 277, if it exists there
Where a specific LOINC code is requested
in the 277, and the documentation submitted
is specific to the LOINC code requested,
Page 13 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
Data
Element/
Segment
SVC
esMD Unsolicited
Name
Allowable
Code(s)
Comments
esMD Solicited
Allowable
Code(s)
Comments
then the requested LOINC code should be
included in the HI segment
Only currently accepted code types may be
used
Service Information
2100A – Service Line Service Date
2100B – Additional Information Submitted Date
2110B – Associated Object Type Identification
BDS
Binary Data
Segment
This guide does not restrict object types to
64 megabytes as recommended in the 275
(X275), i.e., no maximum length is set by
this guide.
This guide does not restrict object types to
64 megabytes as recommended in the 275
(X275), i.e., no maximum length is set by
this guide.
File size concerns remains an open issue
with this specification as it is not clear how
multiple 275s (split up to accommodate
size limitation recommendations) are then
reassembled.
File size concerns remains an open issue
with this specification as it is not clear how
multiple 275s (split up to accommodate size
limitation recommendations) are then
reassembled.
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 14 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
405
4. esMD eDoC Transport Options
406
407
408
409
Phase II CAQH CORE Rule 270: Connectivity Rule 2.2.0, CONNECT with CAQH CORE ASC X12 Document Submission Service Interface
Specification, and Direct are three supported transport mechanisms. The following are acceptable transport and payload combinations using the
ASC X12N 837 and the ASC X12N 275:
Transport
Phase II CAQH CORE Rule 270: Connectivity Rule
2.2.0 (for real-time transactions)
CONNECT w/ CAQH CORE X12 Document
Submission Service Interface Specification
Direct w/ XDR/XDM
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
Payload
ASC X12N 275 (with
optional ASC X12N 837)4
ASC X12N 275 (with
optional ASC X12N 837)5
ASC X12N 275 (with
optional ASC X12N 837)6
User
CMS or
Commercial
CMS or
Commercial
CMS or
Commercial
The following sections provide detailed explanations for each supported transport method by defining uniform metadata content and identifying
valid code sets for entities exchanging documentation for electronic determinations of coverage.
There is no intent in this document to comment on or extend the current claims submission process.
4.1
ASC X12 Transaction Error Responses
Because transactions in this guide are limited to exchange of the ASC X12N 275, transaction-level error handling occurs as defined by the
relevant ASC X12 standards.
ASC X12 Interchange Envelope Conformance errors in the esMD ASC X12N 275 transaction shall be communicated in an ASC X12 TA1
response. The possible TA1 error codes are located in the ASC X12 TA1 005010X231A1 Implementation Specification.
ASC X12 Standard Conformance & Implementation Guide Conformance errors in the esMD ASC X12N 275 transaction shall be communicated in
an ASC X12 999 response. The possible 999 error codes are located in the ASC X12 999 005010X231A1 Implementation Specification.
Application processing errors in the ASC X12N 275 transaction shall be communicated in an X12 824 response. The possible 824 error codes are
located in the ASC X12 824 005010X186A1 Implementation Specification. When the error has been caused by a specific segment or segments
within the ASC X12N 275, the response should identify the segment or segments that caused the error.
4
Wrapped with appropriate metadata. See section Error! Reference source not found.
Wrapped with appropriate metadata. See section 6.1
6 Wrapped with appropriate metadata. See section 7
5
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 15 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
430
431
432
433
434
435
The relevant ASC X12 Implementation Guides for error and acknowledgment handling are available at http://store.x12.org/store/healthcare5010-original-guides. The Insurance Business Process Application Error Codes are maintained by the Washington Publishing Company and are
available at http://www.wpc-edi.com/reference/codelists/healthcare/insurance-business-process-application-error-codes/.
436
437
438
This implementation guide assumes all transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality,
reliability; and with authentication of both the sender and receiver.
439
5. Overview of relevant standards for ASC X12N 275 over Phase II CAQH CORE Rule 270:
Connectivity Rule 2.2.0
440
441
442
443
444
445
446
447
See Appendix A for additional information on error and acknowledgment flows for both the 275 and 277.
4.2
esMD eDoC Security Options
This section defines how additional information in support of an esMD eDoC authorization request may be sent using the ASC X12N 275
transaction set with the Phase II CAQH CORE Rule 270: Connectivity Rule 2.2.0.
5.1
Phase II CORE 270: Connectivity Rule version 2.2.0
Phase II CAQH CORE Rule 270: Connectivity Rule Version 2.2.0 defines a set of metadata used for message routing, transaction
auditing, transaction scheduling, resource allocation, backward compatibility, error handling, and audit logging. The required CAQH
CORE metadata for esMD eDoC are listed in
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 16 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
448
449
450
below.
Figure 5-1: ASC X12N 275 with 837 (CORE)
Phase II CAQH CORE 270:
Connectivity Rule Version 2.2.0
SOAP Envelope over HTTP
<SOAP Header>
</SOAP Header>
<SOAP Body>
CAQH CORE Envelope Metadata
ASC X12 Envelope
Interchange/Functional Groups
ASC X12N
837 (optional)
ASC X12N 275
esMD Security Metadata (Optional)
451
</SOAP Body>
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 17 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
452
Table 5-1: CAQH CORE Metadata
CORE Field
Requirement
PayloadType
R
ProcessingM
ode
PayloadLeng
th
R
R
Data
type
Coded
Set
Coded
Set
Payload Type specifies the type of payload included within the request/response,
(e.g., HIPAA ASC X12 transaction set).
Processing Mode indicates Batch or Real-time processing mode (as defined by
CORE)
See footnote below7
Integer
Defines the length of the actual payload in bytes.
Base 10
Definition
Payload ID (unique within the domain of the party that sets this value) is a payload
identifier assigned by the sender. If the payload is being resent in the absence of
confirmation of receipt to persistent storage, the same PayloadID may be reused.
PayloadID
R
TimeStamp
R
SenderID
ReceiverID
CORERuleVer
sion
R
R
CheckSum
ErrorCode
ErrorMessag
e
7
R
R
R (for a
response to
an ASC X12
transaction)
R (for a
response to
an ASC X12
transaction)
String
dateTi
me
String
String
Coded
Set
PayloadID will conform to ISO UUID standards (described at ftp://ftp.rfceditor.org/in-notes/rfc4122.txt), with hexadecimal notation, generated using a
combination of local timestamp (in milliseconds) as well as the hardware (MAC)
address, to ensure uniqueness.
The Sender (request) or Receiver (response) Time Stamp combines time and date
message metadata into a single Coordinated Universal Time (UTC) time stamp
(including time zone information) specifying when a message is created and sent
to a receiver. This does not require a shared time server for consistent time.
A unique business entity identifier representing the message envelope creator.
A unique business entity identifier representing the next-hop receiver.
The CORE Rule version that this envelope is using. This value can be used to
maintain backward compatibility when parsing/processing messages.
String
An element used to allow receiving site to verify the integrity of the message that is
sent.
Coded
Set
Error code to indicate the error when processing the envelope (includes “Success”
response).
String
Text Error message that describes the condition that caused the error. The text of
the ErrorMessage must provide additional information describing how the Error can
be resolved, and must not provide conflicting information from that provided in the
ErrorCode.
Value or Field Constraints
for eDoC
RealTime
Unique esMD eDoC Message
ID
Date and Time the Message
was created
(http://www.w3.org/TR/xmlsch
ema11-2/#dateTime)
v2.2.0
Algorithm is SHA-1, Encoding
is hexadecimal. Checksum
must be computed only on
the payload and not on the
metadata.
See Phase II CAQH CORE
Rule 270: Connectivity Rule
Version 2.2.0 Section 4.3.3.2
for appropriate codes
Value will be updated when a CAQH CORE Connectivity Rule is published to accommodate X12 6020 transaction sets.
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 18 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
453
5.2
454
455
456
457
458
459
460
461
462
This section follows error handling specified in Section 4.3.3 of the Phase II CAQH CORE 270:
Connectivity Rule Version 2.2.0.
463
6. Overview of Relevant Standards for ASC X12N 275 over CONNECT
with CAQH CORE X12 Document Submission Service Interface
Specification and XDR
464
465
Error Handling
Envelope level errors shall be handled in accordance with Phase II CAQH CORE Rule 270: Connectivity
Rule Version 2.2.0. “To handle CORE-compliant envelope processing status and error codes, two fields
called errorCode and errorMessage are included in the CORE-compliant Envelope. errorMessage
is a free form text field that describes the error for the purpose of troubleshooting/logging. When an error
occurs, PayloadType is set to CoreEnvelopeError.”8
466
467
468
469
470
This section defines how an esMD eDoC document may be sent over CONNECT with the CAQH CORE
ASC X12 Document Submission Service Interface Specification as well as using the IHE CrossEnterprise Document Reliable Interchange (XDR).
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
Healtheway (previously the Nationwide Health Information Network (NHIN)) adopted the Phase II CAQH
CORE Rule 270: Connectivity Rule Version 2.2.0 to exchange ASC X12 Administrative Transactions
between one or more Health Information Exchanges via the Internet. CONNECT is the open-source
solution used by CMS supporting Exchange participants. The “CAQH CORE X12 Document Submission
Service Interface Specification” 9 defines specific constraints on the use of the CAQH CORE Connectivity
Rule. Figure 6-1 below presents the components of a request or response message using 275 and
CONNECT with the NHIN CAQH CORE X12 Document Submission Service Interface Specification.
Specific CONNECT implementations may provide support for X12 transactions with a CAQH CORE
wrapper without an XDR wrapper. Implementations of CONNECT should be capable of sending and
receiving CAQH CORE-wrapped X12 transactions with an XDR wrapper, and optionally without an XDR
wrapper based on trading partner agreements.
6.1
ASC X12N 275 over CONNECT (CORE)
esMD eDoC transactions using XDR specifications shall conform with NHIN Document Submission v2.0
transmissions. The XDR XML body element will contain a reference to the 275, where the metadata
information block is encapsulated with the XDR submission set and its document attributes. XDR
submission specifications (i.e., submission set & document metadata attributes) for esMD are available in
Section 3.2 (Submission Specifications) within the NHIN esMD XDR Specification.10
8
Phase II CAQH CORE 270: Connectivity Rule Version 2.2.0, Section 4.3.3.2.
http://healthewayinc.org/images/Content/Documents/specs/2011/caqh-core-x12-document-submissionservice-specification-v1-0-508.pdf
10 http://exchangespecifications.wikispaces.com/file/view/ESMD_XDR_Production_Specification_v1.0.pdf
9
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 19 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
488
Figure 6-1: ASC X12N 275 over CONNECT (CORE)
CONNECT: XDR
SOAP Envelope over HTTP
<SOAP Header>
esMD SAML Assertions
</SOAP Header>
<SOAP Body>
XDR Document
(see description above)
CAQH CORE Envelope Metadata
ASC X12 Envelope
Interchange/Functional Groups
ASC X12N 275
esMD Security Metadata (Optional)
</SOAP Body>
489
490
491
492
493
494
6.2
esMD Security Metadata
When using the Phase II CAQH CORE Rule 270: Connectivity Rule 2.2.0, the esMD Security Metadata
must be placed in the Body element of the SOAP envelope, as illustrated below:
<S11:Envelope>
<S11:Header>...</S11:Header>
<S11:Body>
<esMD:Metadata>
<esMD:Signature>...</esMD:Signature>
<esMD:Delegation>...</esMD:Delegation>
</esMD:Metadata>
</S11:Body>
</S11:Envelope>
495
496
Table 6-1: Error Code Extensions for esMD Security Elements
esMD Error
esMD Error Code
One or more digital certificate formats does not meet x.509 v3 standards
esMDCertificateStandardError
One or more digital certificates not issued by or chained to a trusted authority
esMDCertificateTrustAuthorityErr
or
Unknown signature format
esMDSignatureFailure
497
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 20 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
498
6.3
CONNECT SAML Assertions
499
500
501
502
503
504
505
506
507
508
509
CONNECT SAML Assertions define the exchange of metadata used to characterize the initiator of a
request. The purpose of this SAML Assertion exchange is to provide the Payer Gateway with the
information needed to make an authorization decision using the policy enforcement point for the
requested esMD function. Each initiating SOAP message must convey information regarding the sender’s
attributes and authentication using SAML 2.0 Assertions. SAML assertions for esMD eDoC must conform
to the NHIN Authorization Framework Specification v3.0.
510
7. Overview of Relevant Standards over Direct using XDM
511
512
513
514
515
516
517
518
519
520
521
522
523
This section defines how an esMD eDoC document may be sent over Direct using XDR/XDM.
XDR supports a direct push model of a package from the sender to the receiver, while XDM supports a
direct push model of a package of content where one of several optional transports is via SMTP. Use of
XDR to wrap the 275 for transport over Direct requires conversion from SOAP to SMTP to comply with
the Direct standard. The conversion from SOAP to SMTP involves using the SOAP headers and/or XDR
metadata to identify the correct SMTP headers to assure proper transport and processing of the
message. Full specifications on this process can be reviewed in the Direct Project’s “XDR and XDM for
Direct Messaging Specification v.1.”11
SAML assertions for esMD eDoC from CMS must conform to the “Implementation Guide for Health
Information Handlers for Electronic Submission of Medical Documentation Project,” section 5.3.5.5: esMD
SAML Assertions Details.
The figure below presents the components of an eDoC document using ASC X12N 275 over Direct with
XDM.
Figure 7-1: ASC X12N 275 over Direct (XDM)
Direct: XDM
SMTP
S/MIME Attachment
Zip File
XDM Submission Set Metadata
XDM Document Metadata
X12N 275 Message
esMD Security Metadata
524
525
526
527
528
The following are requirements for sending an esMD eDoC payload over Direct using XDM/XDR:
 Must conform to the XDR and XDM for Direct Messaging Specification v.1 with XD* metadata as
defined in Section 7.1
11
http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging+Working+Version
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 21 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545






The esMD eDoC ASC X12N 275 and esMD Security Artifacts must be sent as documents in a
Zip file attachment to a Direct message.
Must be a binary file.
The esMD Security Artifacts shall be a metadata document with the name esMDMetadata.xml.
Errors in processing the XD* metadata or the esMD Security Artifacts shall be communicated via
a Direct message with an attached ebRS RegistryResponse in conformance with the Provide
and Register Document Set-b Response section of “IHE’s IT Infrastructure Technical Framework
Volume 2b.”
o These errors will be communicated using existing XDS and esMD extension error codes
in the errorCode field of the ebRS RegistryResponse.
o For errors related to processing the esMD Security metadata, the response must use the
esMD security specific error codes identified in Section 5.2.
Errors in processing the 275 shall be wrapped and sent as a Direct message with an attached
TA1, 999, or 824 message. See Section 5.2 for more information on errors for a 275.
A response to a successful 275 shall be a Direct message with an attached 824 Acceptance
message.
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 22 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
546
7.1
IHE XD* Metadata
547
548
549
550
551
552
553
554
555
556
557
558
esMD systems using Direct should adopt the IHE Cross Enterprise Document Reliable Interchange (XDR) profile with XDS Repository Submission
Request Provide and Register Document set – b (ITI-41) transaction metadata.
Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct
document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS
Registry and Repositories.
Cross-Enterprise Document Media Interchange (XDM) provides document interchange using a common file and directory structure over several
standard media, including email. This permits the use of person-to-person email to convey documents. XDM defines no new metadata but
leverages the existing XDS metadata.
Table 7-1: XD* Submission Set Metadata
S.
No
esMD XD*
Metadata
Attribute
Definition
Author
Represents the humans and/or machines that authored the document. This
attribute contains the following sub-attributes:
• authorInstitution
• authorPerson
• authorRole
• authorSpecialty
• authorTelecommunication
which are individually defined below.
1.1
authorInstitution
(sub-attribute of
author)
XON.1 - Name of the sender of the 275
XON.10 - ID of the sender of the 275
1.2
authorPerson
(sub-attribute of
author)
1.3
authorTelecommu
nication
1
2
Comments
Contact person for esMD administrative questions
XCN.2 - Last Name
XCN.3 - First Name
XCN.4 - Middle Name
XCN.5 - Suffix
XCN.6 - Prefix
Telephone/fax/email for esMD administrative questions
XTN.1 - [NNN] [(999)]999-9999 [X99999] [B99999] [C any text]
XTN.4 - Email Address
XTN.6 - area code
XTN.7 - phone number
XTN.8 - extension
Description of reason for the replacement, follow up, or termination for a
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Data Type
Required (R)
Required if Known (R2)
Optional (O)
R2
XON
R2
XCN
O
XTN
O
O
Page 23 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
prior request
3
contentTypeCode
The code specifying the type of clinical activity that resulted in placing these
XDS Documents in this XDS-Submission Set. These values are to be drawn
for a vocabulary defined by the XDS Affinity Domain.
4
contentTypeCode
DisplayName
“esMD eDoC X12N 275 (X275)”
5
entryUUID
A unique ID or a globally unique identifier within the document submission
request for the SubmissionSet. Intervening portal generates this as part of
generating the XDR/XDM message
6
intendedRecipient
Intended Recipient represents the organization(s) or person(s) for whom the
Document Submission set is intended. The Intended Recipient for the 275
will be the 275 Consumer to whom the sender sends the message. This
Intended Recipient will be identified by the NPI or Alternate ID.
See Table 9 of
Implementation Guide
for Health Information
Handlers for esMD
See Table 9 of
Implementation Guide
for Health Information
Handlers for esMD
R2
R2
UUID
R
XON/XCN
R2
XON.1 - Name of the Consumer
XON.10 - ID of the Consumer
7
patientID
8
sourceID
9
submissionTime
The patientId represents the subject of care of the document.
R2
Globally unique identifier, in OID format, identifying the esMD Gateway
through which the request was sent.
Point in Time at the Document Source when the Submission Set was
created and issued for registration to the Document Registry. Shall have a
single value.This shall be provided by the Document Source (in case of email with significant delay).
R
DTM
R
In esMD 275, this is a timestamp created by the originator of the message
and propagated by all intermediaries.
10
title
11
uniqueID
Timestamp should be to at least the second
Represents the title of the Submission Set. esMD Title for the Document
SubmissionSet shall be – “esMD eDoC X12N 275 (X275)”
A globally unique identifier, in OID format, assigned by the Sender to the
submission set in the transmission. The length of this Unique Identifier shall
be consistent with the IHE XDS profile.
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
O
R
Page 24 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
559
Appendix A. X12 Error Flows for ASC X12N 275
560
561
562
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 25 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
563Appendix B.
Example ASC
564
565
B.1 ASC X12N 275 (Solicited)
Loop
Header
1000A
1000B
1000C
1100C
1000D
2000A
X12N 275
Example
ST*275*1001*006020X275~
BGN*11*0001*20111115~
NM1*PR*2*ABC INSURANCE COMPANY*****XV*12345~
PER*IC*MEDICAL REVIEW DEPARTMENT*TE*5552221212*EX*6593~
NM1*41*2*XYZ SERVICES*****46*A2222222221~
NM1*1P*2*ST HOLY HILLS HOSPITAL*****XX*3999000801~
NX1*1P~
N3*2345 WINTER BLVD~
N4*MIAMI*FL*33132~
NM1*QC*1*JACKSON*JACK*J***MI*987654320~
REF*X1*JACKSON123~
REF*EA*STHHL12345~
DTP*472*D8*20111012~
LX*1~
TRN*2*1822634840~
STC*R4:18626-2::LOI~
2100A
DTP*368*D8*20111115~
CAT*AE*TX~
OOI*1*47*ATTACHMENT~
BDS*ASC*8031*.....~
SE*27*1001~
2100B
2110B
Trailer
566
567
B.2
ASC X12N 275 (Unsolicited)
Loop
Header
1000A
1000B
1000C
1100C
1000D
2000A
Example
ST*275*1001*006020X275~
BGN*02*0001*20111021~
NM1*PR*2*ABC INSURANCE COMPANY*****XV*12345~
NM1*41*2*XYZ SERVICES*****46*A2222222221~
NM1*1P*2*ST HOLY HILLS HOSPITAL*****XX*3999000801~
NX1*1P~
N3*2345 WINTER BLVD~
N4*MIAMI*FL*33132~
NM1*QC*1*JACKSON*JACK*J***MI*987654320~
REF*X1*JACKSON123~
REF*EA*STHHL12345~
DTP*472*D8*20111012~
LX*1~
TRN*1*986543~
2100A
2100B
2110B
Trailer
DTP*368*D8*20111115~
CAT*AE*HL~
OOI*1*47*ATTACHMENT~
BDS*ASC*3192*.....~
SE*19*1001~
568
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 26 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
569
Appendix C: Glossary of Terms
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611














Accredited Standards Committee X12 (ASC X12) – An organization which develops and maintains
electronic data interchange standards and XML schemas.
Alternate ID - An alternate ID can be used if a Registration Requester is not eligible to obtain an NPI.
Beneficiary - The individual on which the service was performed. For purposes of CMS, the
subscriber, member, and beneficiary are the same.
Type of Bill – A three-digit numeric code which identifies the specific type of bill and represents the
setting in which care was provided. As defined by the National Uniform Billing Committee in Form
locator 04.
Claim – Request for payment from a provider, supplier, or beneficiary, which the provider, supplier, or
beneficiary requesting payment must furnish the appropriate payer with sufficient information to
determine eligibility for payment and the amount of payment.
Council for Affordable Quality Healthcare (CAQH) Committee on Operating Rules for
Information Exchange (CORE) Connectivity Rules – Protocols which define a set of metadata
used for: message routing, transaction auditing, transaction scheduling, resource allocation,
backward compatibility, error handling, and audit logging.
The Direct Project (Direct) – A set of standards which specifies a simple, secure, scalable,
standards-based way for participants to send authenticated, encrypted health information directly to
known, trusted recipients over the Internet.
Electronic Health Record (EHR) – [Qualified] Electronic Health Record: An electronic record of
health-related information on an individual that: (A) Includes patient demographic and clinical health
information, such as medical history and problem lists; and (B) has the capacity: (i) To provide clinical
decision support; (ii) to support physician order entry; (iii) to capture and query information relevant to
health care quality; and (iv) to exchange electronic health information with, and integrate such
information from other sources. This is the statutory definition from HITECH. 12
Electronic Medical Documentation Request (eMDR) - A request sent electronically from a Payer or
Payer Contractor.
eXtensible Markup Language (XML) - A markup language that defines a set of rules for encoding
and transporting (not displaying) data.
esMD Gateway – CMS esMD Gateway is NwHIN compliant solution built using the open source
CONNECT software. This solution enables secure exchange of electronic health information adhering
to various Health Information Technology (HIT) interoperability standards. Currently the Gateway
receives medical documents submitted by various Health Information Handlers (HIHs) on behalf of
the Providers and will soon accept documents sent by CMS to the Providers as well, thus facilitating
bi-directional health information exchange. The CMS esMD Gateway went live on September 15,
2011.
Health Information Handler (HIH) – Any company that handles health information on behalf of a
provider. For example, Health Information Exchange (HIE), Regional Health Information Organization
(RHIO), Release of Information (ROI) vendors.
Integrating the Healthcare Enterprise (IHE) - An initiative by healthcare professionals and industry
to improve the way computer systems in healthcare share information.
IHE Cross-Enterprise Document Media Interchange (XDM) – A profile which provides document
interchange using a common file and directory structure over several standard media, including email.
12
Office of the National Coordinator for Health Information Technology (ONC), January 13, 2010, interim
final rule: “Health Information Technology: Initial Set of Standards, Implementation Specifications, and
Certification Criteria for Electronic Health Record Technology.”
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 27 of 28
Centers for Medicare and Medicaid Services
& the Office of the National Coordinator for
Health Information Technology
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657















13
IHE Cross-Enterprise Document Reliable Interchange (XDR) – A profile which provides document
interchange using a reliable messaging system. This permits direct document interchange between
EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure.
Medicare Administrative Contractors (MACs) - Process claims submitted by physicians, hospitals,
and other health care providers/suppliers, and submit payment to those providers in accordance with
Medicare rules and regulations. This includes identifying and correcting underpayments and
overpayments.
Medicare Recovery Auditors (MRA) - The MRAs are responsible for identifying improper Medicare
payments that may have been made to healthcare providers and that were not detected through
existing program integrity efforts.
National Provider Identifier (NPI) - The National Provider Identifier (NPI) is a standard required
under HIPAA. The NPI is a unique, 10-digit identification number for health care providers that is free
of any personal or identifying information. HIPAA covered health care providers, health plans, and
health care clearinghouses must use the NPI in administrative and financial transactions (e.g., claims
submission) that are adopted under HIPAA.
Nationwide Health Information Network (NwHIN) Exchange - A confederation of trusted entities,
bound by mission and governance to securely exchange health information. The NwHIN Exchange is
now called Healtheway Exchange.
Payer - In health care, an entity that assumes the risk of paying for medical treatments. This can be a
self-insured employer, a health plan, or an HMO.13
Payer Contractor - 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.
Provider - Any provider (e.g., hospital, skilled nursing facility, home health agency, outpatient
physical therapy, comprehensive outpatient rehabilitation facility, end-stage renal disease facility,
hospice, physician, non-physician provider, laboratory, supplier, etc.) providing medical services
covered by a Payer (for example, under Medicare Part A & B). Any organization, institution, or
individual that provides health care services to Medicare beneficiaries. Physicians, ambulatory
surgical centers, and outpatient clinics are some of the providers of services covered by a Payer (for
example, under Medicare Part A & B).13
Simple Mail Transfer Protocol (SMTP) – A standard for e-mail transmission across Internet Protocol
(IP) networks.
Secure/Multipurpose Internet Mail Extensions (S/MIME) – A protocol which provides a consistent
way to send and receive secure MIME data. Digital signatures provide authentication, message
integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality.
Compression can be used to reduce data size.
Security Assertion Markup Language (SAML) – A standard which defines a framework for
exchanging security information between online business partners.
Simple Object Access Protocol (SOAP) - A lightweight protocol intended for exchanging structured
information in a decentralized, distributed environment.
Standards and Interoperability (S&I) Framework - A collaborative community of participants from
the public and private sectors who are focused on providing the tools, services and guidance to
facilitate the functional exchange of health information.
Subscriber - For purposes of CMS, the subscriber, member, and beneficiary are the same.
Wet Signatures - Physically signing a document by hand using an ink pen.
http://www.cms.gov/apps/glossary/
Electronic Determination of Coverage Companion Guide with 275 (X275)
Last Updated on March 12, 2016
Page 28 of 28