Whether your institution utilizes a comprehensive electronic medical record (EMR) or a home-grown documentation system, as a 340B-eligible institution, you are likely to face challenges with data integration and transmission in order to be compliant with the 340B statute and provisions. While crucial, Information Technology (IT) jargon isn’t the most user-friendly language for many clinicians and healthcare leaders, or 340B Program stakeholders. Understanding key concepts of how technical terms integrate into the 340B space is priceless to safely optimize a high-risk process, and troubleshoot issues as they arise.

Two decades ago, healthcare data transmission within US institutions used to be mainly performed through what’s referred to as “print feed.”  This entails sending clinical and financial data through a text-like file such as a Word document to a receiving system which, in turn, will need to “parse” this data into distinguished fields containing information such as patient name, medical record number, medication quantity, etc. This feed is still in use in many institutions in the United States. A main advantage of the print feed format is its simplicity which enables most vendors to easily accommodate. As one may guess, print feed represents an area of high variability, less versatility, less flexibility, and fewer opportunities for integration with modern systems.

The Centers for Medicare and Medicaid Services (CMS) require states and manufacturers to send their 340B-related data using a “flat file” format specific to each data set. The flat file is mainly represented as a text file (.txt) with lines of records divided into pre-determined fields. This would normally look like a long uniform text file with pipe line (“|”) between data elements. Many US healthcare institutions utilize this method when transmitting 340B information to Third Party Administrator (TPA) or Split-billing software. Examples include periodic dispensing activity, updates to current provider files, and Charge Description Master (CDM) files. This information will then be utilized to determine 340B transaction eligibility along with subsequent purchasing behavior through Wholesale Acquisition Cost (WAC), Group Purchase Organization (GPO), or 340B accounts, as appropriate. The flat file format offers standardization and streamlining of processes that could otherwise be more complicated. The major disadvantage of this method, as you may realize, is the lack of real-time data visibility. Once this flat file is generated, changes occurring after (such as new dispensing activity, registration, payer, CDM or provider updates, etc.) will only be visible when the next version of that flat file is generated.

Finally, we have the HL7 format. Health Level Seven International is a universal technical framework that aims at standardizing the way of exchanging, integrating, sharing, and retrieval of electronic health information (for more information, you can click here).   The way HL7 works is by breaking healthcare record information into designated subsections referred to as groups, segments, fields, components, and subcomponents. Certain indicators help in separating data elements within the HL7 format, such as segment headings, pipe lines (“|”), and carets (“^”). This method is becoming the most widely preferred method of healthcare data transfer due to scalability, versatility, and ability to integrate with most current healthcare technology products.  ADT (admission, discharge, transfer) information transmission and electronic data interchange (EDI) functionality can also be efficiently handled using this method in a real-time fashion.

Regardless which method of data transfer your institution currently utilizes for 340B data transmission, several issues can arise which can put your institution at risk of noncompliance with HRSA requirements.  The method of data transfer will dictate how complicated these issues can become, and how long the troubleshooting process can take. These issues include, but are not limited to, provider ineligibility, location ineligibility, National Drug Code (NDC) mismatch, National Provider Identification (NPI) mismatch, Medicaid identification, and billing units per package (BUPP) conversion. Accurate implementation of both EMR and 340B-split billing software is paramount to avoid such pitfalls. Timely and efficient troubleshooting for these situations helps in avoiding the “snowball” effect that results in a larger amount of ineligible transactions, leading to a possible HRSA material breach.

Note that if the 340B-split billing software is configured to identify a provider as “always eligible,” all orders and prescriptions from that provider will be identified as 340B-eligible regardless of the location.  This creates a risk for 340B drug diversion since these prescriptions may originate from ineligible locations. For carved-in institutions, a duplicate discount issue will arise if a Medicaid BIN number was not identified as such, resulting in 340B split-billing software classifying such claims as non-Medicaid while, in fact, Medicaid was billed (in any payer position). Another example is in regards to interpretation of billing units per package (BUPP) using the EMR setup and feed. In some cases, this value is represented by a straight “base unit” field while, in others, it may be represented by an “implied” or “factor” units.  Working closely with the billing and financial services department, while implementing 340B-split-billing software, is a crucial step to avoid future over- or under-accumulations on any purchasing account.

In an era of drug shortages, NDC mismatches continue to be a risky area that requires close monitoring. An accurate and updated “crosswalk” for current CDM and NDC data helps in reducing the amount of workload that 340B professionals will encounter on an ongoing basis. Mapping new NDCs to CDMs is an important step to ensure correct accumulation at the correct account. For institutions that are subject to Orphan Drug Prohibition, listing orphan drugs in 340B-split billing software needs to be monitored by covered entities and updated as needed to ensure that orphan drugs are not purchased using the 340B purchasing account. The good news is that these lists are available from the HRSA web site and 340B split-billing software in a user-friendly exportable format, such as an Excel spreadsheet.

In summary, although informatics and technological advancements have created great venues to streamline data transmission and processing, there are many gaps and opportunities for improvement that still need to be addressed. In the meanwhile, covered entities should maintain vigilance and continuous monitoring of their 340B-related data to avoid possible noncompliance with the 340B statute and other provisions by HRSA.

Share this on Twitter: