ArgonDigital - enterprise automation experts

Share This Post

Don’t Hold your Data Hostage! Agile Requirements for Data Maps

I am currently knee deep in a project to configure data mappings for healthcare ETL processes. Although there are standard formats for every exchange of healthcare information, the new core system needs some TLC to make all of the data flow correctly into and out of the system.

The best tip for managing successful data mapping is to prioritize the data first. The business stakeholders can certainly tell you which data is more critical than others. In industries with well defined data structures, this can be as simple as showing all of the data available and asking your stakeholders to rank each element (or groups of elements) with the MoSCoW rankings.

Your stakeholders may be over zealous in their rankings. That’s ok. Not everything can be a “must have” element. With a little business analysis, you can shed some light on discovering the true rankings for data. Examine the workarounds for getting the data if it isn’t mapped. How much time would it take? What would this cost?

As an example, consider a healthcare claim. There are thousands of individual data elements on a healthcare claim, but chances are your health insurance company doesn’t use each data element to adjudicate the claim. The claim data that does not impact adjudication can be ranked “could have” at best. Of the data that does impact adjudication, consider which elements take the most time to get. If the member name is missing, a claims analyst would have to call the provider who submitting the claim to find out who the member was. If this data was unmapped, they would have to call each provider and ask about each claim. This would take more hours than are available in the day. Clearly the member data, along with several others, are “must have” elements.

Data that isn’t necessary for the delivery of the product, but is still useful in other ways, is ranked “should have”. Continuing the healthcare claim example, any data that does not impact adjudication could be in this category. The company may use this data internally to analyze trends. For example, the ethnicity of a member doesn’t affect adjudication (the product that the healthcare company is offering), but it does assist in setting premium rates for members.

Once you have a sense of your data rankings, you can begin mapping. Start with your “must have” elements. After thorough testing, the business may consider going live with the mapping. After all, time is money. It could be wasteful for the “must have” data to be held hostage by the unmapped “could have” data.

By this point, the agile methodology is recognizable. Continuing with a release that addresses the “should have” data enhances the product that is already operating to address the core needs of the business. Finally, adding in the “could have” data in a subsequent releases accelerates the product for future functionality. All of these planned releases avoid the time and cost of defining, mapping, implementing, testing and releasing unneeded data.

Don’t Hold your Data Hostage! Agile Requirements for Data Maps

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage