healthcare edi software Caliber Health

Notes from the 2018 WEDI Spring Conference

The 2018 WEDI Spring Conference mixed deep dives into emerging X12 standards with sessions centered on Open APIs and a greater unification of clinical and administrative data. Here are a few of the topics that jumped out at me, with some thoughts on what these healthcare data trends might mean for our T-Connect EDI Software customers.

FHIR – The maturing FHIR standards arguably represent the most dynamic developments in HIT at present. FHIR (Fast Healthcare Interoperability Resources) is set of specifications developed by HL7 that most immediately concerns clinical data in EHR systems, but also extends to the exchange and content of administrative transactions, such as claims and eligibility requests.

FHIR is an implementation of modern web standards present in most other industries:

FHIR also defines resources which represent discrete data elements. Here’s a partial view of a FHIR claim resource:

A FHIR Claim Resource
A FHIR Claim Resource

It’s important to note that these standards are still developing. HL7 ranks each resource on a maturity scale from 1-6; Claims currently stand at 2. There is significant momentum behind FHIR:

In the short to medium term, it seems likely that health plans will kick off FHIR integration projects while maintaining their investment in the mature X12 transactions.

Provider Directories – A separate section of the 21st Century Cures Act mandated the establishment of state-based provider directories. Surveys have determined that provider data in Health Information Exchanges may be incorrect as much as 50% of the time, including critical information such as office hours and whether the provider is accepting new patients. The Cures Act placed the onus for the submission of provider information on health plans, with the expectation that submissions occur on a monthly basis. The law did not provide guidance on the syntax of the information exchange, and considerable variation exists between states in terms of format and frequency.

California has taken the lead in establishing a Provider Directory, with other states evaluating the approach. In July 2015, Senate Bill 137 required MediCal plans to submit standardized provider information, and the law went into effect a year later. As part of the regulation, California’s Department of Health Care Services (DHCS) required the submission of the X12 274 transaction back to the state for verification. The 274 Provider Directory transaction is not a HIPAA standard and will represent an initial implementation effort for affected health plans. This visualization in T-Connect’s X12 Studio represents Provider and Site information:

Validating a 274 in X12 Studio
Validating a 274 in X12 Studio

The version numbers required by DHCS for 274 submission are:

  • ST01 = 274
  • GS08 = 004050X109

Given California’s rapid adoption of the 274 transaction, it’s likely other states will soon adopt a similar approach to managing Provider Directory submissions.

Attachments – When the original HIPAA legislation passed in 1996 and mandated a set of administrative transactions, attachments were included in the list. The Affordable Care Act reaffirmed the requirement for an attachment standard, but as of May 2018, HHS has not submitted a Notice for Proposed Rulemaking (NPRM), which would move one of the submitted attachment proposals closer to an official status.

This seems likely to change in the coming months, although considerable uncertainty exists. WEDI moderators indicated an NPRM in August is the current best case, which could put a standard in place by the end of the year.

Much of the delay in arriving at an attachment standard was due to a lack of consensus regarding the syntax of the attachment payload. Over the last several years, the HL7 Consolidated Clinical Document Architecture (C-CDA) has emerged as the best mechanism for submitting structured clinical attachments. The designers of the X12 attachment transaction recognized that unstructured content will remain common (scanned notes, images, PDFs); therefore this is also permitted under the emerging standard.

The X12 275 Attachment transaction take two forms:

  • X314 Additional Information to Support a Health Care Claim or Encounter. This transaction set provides clinical information required by the payer to process a claim.
  • X316 Additional Information to Support a Health Care Services Review. This attachment corresponds to the 278 Request for Review and Response. This is additional information required to respond to a prior authorization request.

One thing to note is that the transactions submitted for consideration are based on 6020 X12 specifications. This prompted some concern about a lack of operability with 5010-based EDI translators, and why 6020 is in play since WEDI is focused on the 7030 standards as the replacement for 5010. The 5010/6020 version difference alone does not present compatibility issues for EDI parsers, but it does require 275 support. Since the 7030 version of the 275 is not yet complete, the 6020 version is currently the best candidate for the standard.

The 275 attachment supports two models of interaction between plans and providers:

  • Solicited: A payer pends a claim due to the need for additional information. A 277-RFAI (Request For Additional Information) is returned to the provider or clearinghouse, which contains control numbers linking to the original 837 claim. The expectation is that the provider will produce a payload (unstructured or C-CDA), which is Base64 encoded and included as the BDS-03 element in the 275 transaction.
  • Unsolicited: In this scenario, a provider is aware the plan will require additional documentation, and proactively sends the 275 attachment to accompany the 837 or 278.

The inclusion of encoded HL7 content within an X12 wrapper makes these transactions unique. Here are the CMS specifications for the BDS segment:

BDS Segment Specifications
BDS Segment Specifications

Beyond the X12 wrapper and the HL7 C-CDA payload, another standard that plays an important role in the 275 workflow is the use of LOINC codes (Logical Observation Identifiers Names and Codes). LOINC is an international standard intended to provide standard descriptors for health measures and documents. LOINC codes are used within the attachment workflow to specify precise information on the types of attachments requested, or present in the response.

This newly released whitepaper from WEDI does a great job of drilling deeper into attachments and includes X12 samples. With the amount of overhead required for manually requesting and producing attachments and a probable HHS requirement, electronic attachment processing is likely to impact most health plans within the next few years.

All Payer Claims Databases – A panel discussion covered the state of All Payer Claims Databases. As with Provider Directories, there is wide variation on a state-by-state basis in terms of what has been implemented, however in the case of APCDs no mandate currently requires states to aggregate claims data.

Since our last post on the subject, the landscape remains much the same. 41 states have at least entered the planning phase for establishing an APCD. Variations of the Common Data Layout still provide the foundation for the submissions of many states. The PACDR transactions have a few distinct advantages over CDL:

  • The PACDR 298, 299 and 300 transactions (corresponding to the 837P, I and D) conform to the standard EDI validation framework. 999 acknowledgements serve as the basis for structural validation. Additionally, a new variant of the 277 is under development for providing specific business level response information to the PACDR transactions.
  • The PACDR transactions contain both claim and adjudication information in the same transaction in X12 format, which provides the deepest view of claim processing.
  • PACDR 837s were designed to standardize data reporting to both APCDs and Medicaid. New York is currently accepting post-adjudication claims as their standard for APCD submission, which can prove the viability of these transactions on a national level.

Visit Caliber Health’s EDI software comparison page to pinpoint the best solution to meet your healthcare data processing needs. 

Leave a Reply

Your email address will not be published. Required fields are marked *