After building several exploratory programs in Python, I decided to use Cursor to build a working prototype, the results of which can be found here. The entire build took several hours on a single afternoon, with a few additional modifications taking place the following day.
The application, in its current form, does a good job of showing the general Auth-to-Claim workflow and the use of GenAI to offer brief explanations of why the mismatch occurred. Cursor did an excellent job at reusing much of what had been built in earlier exercises as a starting point. At this early stage, there doesn’t appear to be significant value in documenting formal requirements or specifications. Instead, it’s more important to get ideas built in near real time and make continuous adjustments as needed.
As with any application, there is room for improvement. Let’s identify a few select limitations:
Limitation: Volume and workflow
This demonstration uses approximately 50 claims to model matching behavior, far below what would be encountered in a production system. For context, a small regional health plan might receive up to 25,000 claims per day, while a major PBM could receive millions of pharmacy claims over the same timeframe.
Limitation: Use of synthetic data
To show various matching exception cases, synthetic data was used. This can result in an overly simplistic solution that doesn’t reflect real-world use cases.
Limitation: Excessive manual intervention
Without the opportunity to speak with individuals responsible for claims processing, it’s difficult to know whether this UX is appropriate. The current workflow seems reasonable and easy to navigate, but it’s still quite manual-intensive, even with the use of GenAI.
Limitation: Prompt-based exploration vs. specification-based
This initial version was created using numerous prompts and exchanges using Cursor’s LLM (Composer 2.5); it did not use any well-defined specification. This can pose risks when deployed and used in a production setting.
Limitation: Exception logic assumptions
While I knew what types of exceptions to model, the underlying logic was primarily self-generated. The resulting code may or may not be completely accurate, so additional review/critique is necessary.
This is a good start. In a future post, I’ll start investigating how agents can play a larger role in managing the set of exception cases.