In order to communicate expectations and updates to claimants, your systems need to be able to surface the relevant data to both internal users and claimants.
This may be a challenge for some states. Mainframes and other legacy systems may not integrate well with frontend platforms and can cause states to struggle to access and surface relevant data.
The following recommendations can help you to improve the quality, integrity, and availability of your data.
Recommendations
Choosing how to set up data in your system can impact how easily and accurately you are able to provide status updates to claimants.
There are two types of data:
-
Unstructured data is data that is not organized in a pre-defined way, like descriptive text or multimedia content.
-
Structured data is data that is categorized and organized consistently, using a pre-defined structure, and can include quantitative or qualitative information.
Using unstructured data in your system can make it difficult to surface status updates to claimants or staff in a consistent way. Ideally, claims processing can be done exclusively with structured data.
The table below includes examples of how data may be collected in a system.
Scenario |
Unstructured data |
Structured data |
||||||||||
Employer contesting separation reason. |
“The employer contacted SWA and said the claimant should not be eligible because they quit voluntarily – need to follow up with fact finding.” |
|
||||||||||
Claimant contact information. |
“The claimant can be reached at 555-1234, but they prefer to receive updates through email at superstar1@peoplemail.com" |
|
In the examples above, a system using unstructured data would require someone to read and interpret a note to advance a claim. In contrast, a system using structured data can be automated to identify a particular scenario and trigger a status message to be displayed.
If you are not able to use data to identify a claim scenario and surface a status message, you might need to address gaps in your structured data.
If important steps in your process currently use unstructured data, like notes for documentation, consider exploring how to capture that data in a way that can still be used for automated processes.
It is possible to use a combination of natural language processing, standardized note templates, machine learning, or artificial intelligence to work with unstructured data. However, it might require a lot of effort to set up and is often only a partial solution. For example, you might be able to configure logic to have a standardized note trigger a status to be shown to a claimant. However, you would need to do additional work in order to track metrics around that status.
It is often better to put energy toward updating your claims system to have the features you need, or toward migrating to an updated system if wholesale modernization is warranted.
Having structured data is critical, but if that data is inaccurate, it can almost be worse than having no data at all.
One issue with data integrity can duplicate issues. Even modern claims processing systems sometimes misidentify issues, can add multiple issues of the same type, or re-open issues that were resolved. These situations will end up causing a lot of confusion for claimants in any status tracking tool.
Some lightweight data analysis can help identify when issues are consistently duplicated or re-opened. If this is a pain point for your system, consider investing in additional business logic for your claims processing system.
Structured data can be used to communicate status messages to claimants through notifications, online portals, and contact center representatives. It is important that the data is surfaced consistently. For example, contact center representatives should be able to access the same status message as a claimant.
If data is not available to frontend systems, consider including scope in your project to build an application programming interface (API) or other tools to extract it. Check out ‘Incorporate a claims status tool into a legacy system’ for recommendations on how to add new functionality alongside your current codebase.
Key questions
- Which issues are not identifiable in the claims processing system (e.g., by contact center agents?)
- Which issues or statuses don’t have data available to access on the backend? (either through a query or API call)
Interested in addressing claims status? Email the UI Modernization Team
Was this page helpful? Fill out a short survey