esMD Harmonization Mapping Analysis for X12 274 & X12 277

1. esMD HarmonizationMapping Analysis forX12 274 & X12 277

2. Overview • Mapped UC1 data set requirements to X12 274 Healthcare Provider Information Transaction Set • Mapped UC2 data set requirements to X12 277 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

3. Background on X12 274 • The X12 274 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

4. 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: • NM1 Organization Name • PERPayer Contact Information

5. 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.

6. Background on X12 277 • The X12 277 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 • X12 277 is a messaging standard, so transaction contains both esMD Message elements and eMDRObject elements • Cannot represent eMDR Object as a distinct payload

7. eMDR Message (1/2)

8. eMDR Message (2/2)

9. General Request Information

10. Audit Specific Information

11. Claim Related Information

12. Claim Related Information (Claim Level Detail)

13. Claim Related Information (Line Level Detail)

14. Return Method Object

15. 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

16. 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