esMD Harmonization Mapping Analysis for X & X12 277

Overview Mapped UC1 data set requirements to X Healthcare Provider Information Transaction Set Mapped UC2 data set requirements to X Request for Additional Information Transaction Set Presentation focuses on elements that are not represented in the standard 274 & 277 transaction sets; complete mappings will be available on Wiki

Background on X The X Healthcare Provider Information Transaction Set provides a mechanism to exchange demographic and qualifications about healthcare providers. Mapping is based on version 4050 as well as change requests that came out of the S&I Provider Directories Initiative

X12 Terminology (1/2) Elements ‒ The most basic components of an X12 message ‒ Convey individual pieces of information, such as a name or phone number Segments ‒ Units of logically related elements. For example, the N4 segment conveys geographic information and includes the elements: City Name State or Province Code Postal Code County Code Loops ‒ Sets of logically related elements and segments. For example loop 2100A conveys information about a payer and includes segments such as: NM1Organization Name PERPayer Contact Information

X12 Terminology (2/2) Transaction Sets ‒ Business level groupings of segments and elements ‒ Represent a standardized business transaction, such as a request for additional claim information ‒ May contain multiple segments and segment types may be repeated. For example, N4 (geographic information) could be used for the seller’s address and again for the buyer’s address. ‒ Defines the order in which each segment must occur. This enables the same segment to be used multiple times. Segment use may be optional.

Background on X The X Request for Additional Information to support a health care claim or encounter Transaction Set provides a mechanism for asking one or more questions, or requests for information, about specific claims Mapping is based on version 5010 ‒ Patient loop replaced Subscriber and Dependent loops as of version 4050 X is a messaging standard, so transaction contains both esMD Message elements and eMDR Object elements ‒ Cannot represent eMDR Object as a distinct payload

eMDR Message (1/2) esMD Data Set RequirementComments Individual Provider or Provider Organization Address 277 workgroup saw no compelling reason for the payer to send the provider's address to the provider. Individual Provider Prefix 277 workgroup saw no compelling reason to include the prefix 'DR' for the provider Payer or Payer Contractor Digital Certificate Payer or Payer Contractor Signature Artifact Information from eMDR Object (section) Payload concept does not exist in X12 transaction set, not logical to replicate information in two places within message.

eMDR Message (2/2) esMD Data Set RequirementComments Unique ID for eMDR Object Payload concept does not exist in X12 transaction set. X12 message will have single Unique Message ID. Payer Organization vs Payer Contractor 277 does not support concurrent information for a Payer Organization and Payer Contractor Organization. 277 does support one or the other alone. Payer Contractor contact information could be placed in one of the multiple PER elements within the Payer Information loop or within the Claim Supplemental Information loop. Purpose of eMDR Limited to ASC X12 R Request Codes Request Type ASC X12 R Request Codes may satisfy some of this requirement R5 - Follow up/need more info that previously requested R13 & R14 - Subsequent Requests Request Type Reason See comments for Request Type

General Request Information esMD Data Set RequirementComments Date of Request In 277 the ‘Status Date’ is the date the payer determined that additional info was needed and POSSIBLY could have initiated the actual request for info. In 277 the ‘Transaction Date’ is the date the payer created the actual 277 Request Transaction and (generally) sent it to the provider. Neither of those is an exact match but could be considered a ‘Date of Request’. Cover Letter Text 277 workgroup did not find this applicable to electronic exchange Program - The type of program sending the eMDR (e.g. MAC, RAC, CERT, ZPIC)

Audit Specific Information esMD Data Set RequirementComments Scope or Type of Audit (e.g. Pre certification, Claim Payment Documentation, Audit, Payment Recovery) Unique Case Reference Identifier - A case number used to track one or more related eMDRs. Serves as a unique external ID.

Claim Related Information esMD Data Set RequirementComments Provider Directory Address Provider Directory ID Payer Identifier for the Policy holder Version 5010 only has a single Patient Loop, rather than distinct Subscriber and Dependent loops. This reflects use of patient ID numbers in clinical systems rather than insurance ID numbers. Beneficiary Date of Birth The provider specific account number & medical record are sent in the request so DOB was deemed unnecessary by the 277 workgroup.

Claim Related Information (Claim Level Detail) esMD Data Set RequirementComments Date Claim Received Type of Bill REF01 = BLT Bill type as found in ASC X12N 837, CLM05. Need to verify this reflects NUBC Form Locator 4 Place of Service Diagnosis Code(s) 277 workgroup saw no compelling reason for the payer to send the provider the diagnosis as the provider already knows and submitted it on the claim. Minimum necessary. Diagnosis Code Set Used See comments for Diagnosis Code(s) Diagnosis Related Group Code See comments for Diagnosis Code(s)

Claim Related Information (Line Level Detail) esMD Data Set RequirementComments Performing Provider NPI 277 supports NPI of Service Provider as identified in Loop 2100C, but Service Line Information does not have data element for additional or different NPI. Performing Provider Alternate ID See comments Performing Provider NPI Alternate ID Type See comments Performing Provider NPI Provider Specialty 277 workgroup found no compelling reason for the payer to send the provider's specialty to the provider since they already know it. Diagnosis Code 277 workgroup found no compelling reason for the payer to send the provider the diagnosis as the provider already knows and submitted it on the claim. Minimum necessary.

Return Method Object esMD Data Set RequirementComments Return Methods - Defines the high level transport to be used for the return (Physical, Electronic Transaction, URI) HIPAA does not require providers to implement electronic attachments, so 277 could not specify required return mechanism. 277 workgroup felt this was more of a Trading Partner agreement requirement. Electronic Service Information See comments for Return Methods Maximum Electronic Return Size per transaction See comments for Return Methods Return Constraints See comments for Return Methods Return Format(s) See comments for Return Methods

Summary of Analysis X12 workgroup and esMD workgroup took somewhat different approaches to eMDR ‒ X12 messaging does not support distinct payload ‒ Version 5010 represents patient information rather than distinct beneficiary and dependent information 277 Request for Additional Information Transaction Set supports many but not all elements identified in esMD data set requirements

Next Steps Prioritize elements that are not represented in standard 277 transaction set according to necessity for esMD eMDR ‒ High priority: Submit to X12 for review and possible inclusion in future version of transaction set ‒ Low priority: Reconsider necessity in esMD data set requirements If possible, identify short term workaround for initial implementation guidance based on current 277 transaction set