Version 1 -> Version 2

[jbregstone]

In version 1 of the VRO we handle claims for Hypertension and Asthma. These conditions each have a single VASRD code associated with them. Currently, as an input we are getting the VASRD code 7101 or 6602 as an input, this helps us route the claim to the correct processor. The processors contain logic specific to the condition they are built to handle and do tasks such as filter medical evidence and determine sufficiency for the fast track process.

In version 2 we are going to included conditions (such as Sinusitis) which have multiple associated VASRD codes. We would like to process these conditions with a single processor so we could simply map multiple VASRD codes to lead to that processor. For example all of the following VASRD codes could be routed to a single sinusitis medical data processor:

• 6510 – sinusitis, pansinusitis, chronic
• 6511 – sinusitis, ethmoid, chronic
• 6512 – sinusitis, frontal, chronic
• 6513 – sinusitis, maxillary, chronic
• 6514 – sinusitis, sphenoid, chronic

An alternative is to change the input for version 2 so a more general condition identifier is accepted. For example, the VRO would accept sinusitis as the identifier that helps route the claim to the correct condition processor. As an output of the VRO we could determine what the best VASRD codes are to rate the claim. The VRO will have a complete picture of the medical evidence associated with a claim and thus more easily assign a specific VASRD code(s). A VASRD code like 6511 sinusitis, ethmoid, chronic is very specific and information dense so it would be feasible to map conditions from a medical code set (ICD or SNOMED) to that VASRD code.

Hypothetically this will ease the requirements for upstream processing of claimed conditions on the 526EZ. There would be no need to attempt to assign a specific VASRD code to the claim before it is processed by the VRO.

[jbregstone]

@au2 @yoomlam thoughts?

[yoomlam]

In version 2 we are going to included conditions (such as Sinusitis) which have multiple associated VASRD codes.

Clarification: For VRO v2, VRO will only receive single-issue Hypertension claims-for-increase. @dianagriffin

We would like to process these conditions with a single processor so we could simply map multiple VASRD codes to lead to that processor.

Without going into the details of your use case, I've always envisioned a router early in the VRO workflow that examines the claim (and any additional veteran, service history, or medical data) and routes it to an appropriate assessor (this Claim Router is shown in the diagram at https://github.com/department-of-veterans-affairs/abd-vro/wiki/(March-2022)-Plan-to-Deploy-to-LHDI#vro-software).
In this v2 workflow diagram, the routing would happen after GetHealthData using claim,HealthData to determine the appropriate assessor.
I believe the closest Java component that does this is SlipClaimSubmitRouter, which has a comment that states:

dynamically route claim to endpoints depending on claim attributes

The Claim Router can be as complex as needed and can send claims with different diagnostic codes to the same assessor.

@jbregstone Does this help?

[jbregstone]

Yes, we can call it VRO v3, my understanding is that at some point we want to add sinusitis and rhinitis.

I've always envisioned a router early in the VRO workflow that examines the claim (and any additional veteran, service history, or >medical data) and routes it to an appropriate assessor

This makes sense to me and I agree with the need to route claims to the appropriate assessor. However the information needed to route a claim to an assessment service does not have to be as granular and detailed as the VASRD codes are.

The assessor is the piece that examines the medical data. It is at that point that we can consider what the medical evidence suggests is the VASRD code that RVSRs should use to rate the claim. From my perspective VASRD codes are not needed as an input to the VRO as much as they are needed as an output.

In the hypothetical scenario that I laid out, lets say that the Veteran claims "chronic sinusitis" as their condition on the 526EZ form. The VRO will accept this claim as a claim for sinusitis. From there it is routed to the condition processor for sinusitis which examines all the medical data and finds an ICD code for J32.2 Chronic ethmoidal sinusitis. At that point in the process we can positively say that the claim should be rated under VASRD 6511.

Does that demonstrate the idea better?

[yoomlam]

Yes, thank you for the clarifying example. In that scenario, perhaps we need the capability of an assessor to forward the claim to another assessor -- for your example, the claim goes to a claim router to a sinusitis assessor to a 6511 assessor. That workflow sounds technically fine to me but it's up to Product to define the workflow and decision points.
Similarly, the input (whether it's VASRD codes or medical data) used to do the routing and/or assessments is determined by Product.

Going back to your original post:

Hypothetically this will ease the requirements for upstream processing of claimed conditions on the 526EZ. There would be no need to attempt to assign a specific VASRD code to the claim before it is processed by the VRO.

I'll defer to @dianagriffin.

I think your points are valid; I'm just not sure when they'll incorporated into VRO.

[jbregstone]

I think we are on the same page based on the diagram but I wanted to bring this up because it would change slightly the inputs to the VRO. (edit: In the VRO software diagram there is one processor per condition) It would not require any changes to the current architecture (because there is a one to one mapping between 7101, 6602 and hypertension, asthma)

[yoomlam]

Yea, the diagram is simplistic in that sense. At the time and currently, VRO's workflow is to act based on those diagnostic codes. As Designer/Researchers propose new workflows and Product confirms their impact, VRO will be updated to behave differently based on different inputs.