Download
1 / 16
160 likes | 276 Vues
This presentation provides an overview of the mapping process for the X12 274 Healthcare Provider Information Transaction Set and the X12 277 Request for Additional Information Transaction Set. It emphasizes elements not represented in the standard transaction sets, presenting complete mappings available on Wiki. The analysis is based on version 4050 and 5010 of X12 and includes details on segments, elements, and loops essential for understanding healthcare provider demographics. Next steps involve prioritizing elements for inclusion in future versions and exploring implementation guidance.
E N D
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
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
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
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 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
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
