Healthcare data sharing is only as good as your data standards

Standards are a funny thing. In this era of insurance industry innovation, Insurtech startups, and rapid agile software development and distribution, many people blanch at the constriction that standards often represent.

While there is a well-established standards approach for medical treatment coding, healthcare data standards are noticeably lacking. That is important because standards are the essential ingredient for optimizing advanced analytics and the information value derived from a well-designed standards structure.

The healthcare insurance vertical, like most other verticals in the insurance industry, has struggled with pulling together the vast treasure troves of provider and patient information in their many and sundry data stores. Many reasons for this are familiar to all: older systems with poor data editing capabilities; proprietary data stores that require specific data formats but are incompatible with other systems; and operational data stores that create data quality degradation to name a few. However, many of these problems have a root cause based on the fact that most healthcare organizations do not have strong data standards as a part of their overall business and technology ecosystem.

An example of this issue using a couple of pretty common healthcare data elements should prove illustrative: the difference between insurance eligibility and attribution enrollment. With a solid set of data standards in place, the first order of business is defining the data elements once and only once for use by all interested systems:

• Eligibility is health insurance coverage that one has for a certain or fixed period
• Enrollment is signing up for coverage or program for a certain or fixed period, or derivation of a relationship for a certain or fixed period. A good way to think about enrollment is as a relationship, much like a marriage or friendship as it exists over some period.

While it might seem mundane, these standards-driven definition distinctions are important for creating analytical insights and actionable value from this data. Because one of the foundations of analytical insight is data sharing across systems and platforms, it is critical to know when a particular data element was created and when the data contained therein was last updated. The same holds true for any subsequent subsets of data. This means that there may be a number of “date” elements that are defined in a particular way. For instance, a “date” definition for when a file was created, versus a “date” definition for when that file is updated, and a subsequent file is created. While this sounds elementary, more often than these initial data standard markers are not present in healthcare technology systems. Here are a couple of examples why that is a problem:

• Eligibility data needs to be shared when building an analytical claims population file that includes the subset of the claims population a given set of claims represents, and if the date spans are based on either service dates as opposed to paid dates. That is important as there is often a lag between when a patient is seen by a doctor, and when that service is billed.
• For enrollment, an attribution enrollment analytical file needs first to include the date described time span of the data necessary to derive the attribution and for what period the attribution is valid. An example of this is a patient seeing a doctor for the first time then making an attribution of the patient-doctor relationship valid for some period that includes the past, present, and future.

In both cases, a standards-based definition of the various date elements required is crucial for analytical data quality and insight. So how does one define data standards that optimize healthcare data sharing?

To start, it is important to fix any communication problems among the various parties involved. For instance, providers usually hire an external vendor or buy a COTS product for analytical needs. However, the claims data needed for provider data analysis is usually provided by the payers. In this scenario, there are often two contracts - one between the payer and the provider for the claim, and the other between the provider and the analytical service vendor for the reports. More often than not, the two contracts have different communication protocols, different points of contact, and different delivery timelines. As a result, the provider often plays the role of the middleman, exchanging questions and answers between the payer and the analytics vendor. Many times the communication happens during the beginning of the contract but then fades into an ad hoc basis only. Adding to the problem, there is often no service level agreement in place for questions and verifications between the parties.

Saif article graphic 1

To correct this common situation and make sure all of the parties are working synchronously, there needs to be some upfront collaboration between all the potential stakeholders before the creation and execution of the various contracts. The purpose of this collaboration is to ensure that each party understands the business goals and the analytical needs of the provider – both tactical and strategic. This collaboration will help the team understand what data is available; what will be provided to whom; and what will be required and expected to meet the data goals. This collaboration should then continue at regular intervals during the entire course of the contracts. This will provide a platform to ask questions and inform the group of any immediate or future changes to the data or process. There should be a medium set (i.e. Jira, MS Excel, or some other collaboration toolset) for asking questions and sharing relevant data.

Saif article graphic 2

Once these high-level agreements are in place, it is time to get into the details of what will allow the parties involved to work in an efficient and effective manner on behalf of the provider. For example, all medical claims cannot be provided in one file. There is a clear distinguishing feature between facility, professional and Rx claims. These claims should be provided in separate files, but if they are provided in one file, there should be a clear indication of that. Also, since claims files are usually created on a monthly basis from the source, the data is often extracted based on service date. This results in an incomplete file because not all claims in that service month might have made it into the system. Hence, the easiest and safest choice is to extract data based on paid dates. This will always be a complete set with no duplication from month to month.

Furthermore, a primary file should always have a supporting file (e.g., Provider_Rx_022016.txt should also have Provider_Rx_022016_support.txt). The support file has information such as when the file was created and its corresponding eligibility file. Similarly, an attribution file will have look-back dates, validity date, etc. Another possible option would be that all files come bundled in a zip format with a summary file. Of course, it is understandable that for privacy purposes claims related to STD, mental illness, or drug abuse are not shared. However, not sharing such data might lead to incorrect analytical output. A solution for this is to effectively mask the member information and provide the rest so that it can be included in the analytics. Finally, it is important to create a mandatory and industry specific list of columns populated with relevant data before sharing. A good example of this is that a claims file should always contain the service date, paid date, member id, POS, ICD code, servicing provider, etc. An eligibility file should contain an effective date, end date, member id, subscriber id, coverage info, etc.

All of the above can be thought of as part of a data standards approach that will lead to efficient and effective data sharing. Once these elements and standards are in place, providers should be able to create insightful and actionable data analytics that provide more effective patient care and more efficient financial management.

Saifuddin Bhagat is a senior consultant at X by 2, a software architecture and leadership consultancy for the insurance industry—health, life and P&C. He is a software project manager lead on various enterprise-level engagements as well as excels at implementing agile methodologies. Bhagat holds a bachelor of engineering with focus in computer science from KCG College of Technology.

The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of Becker's Hospital Review/Becker's Healthcare. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.

© Copyright ASC COMMUNICATIONS 2017. Interested in LINKING to or REPRINTING this content? View our policies by clicking here.


Top 40 Articles from the Past 6 Months