MHV-61122: Medical records access updated with new eligibility check

[mattwrightva]

Summary

• Added a new client and configuration for checking user access eligibility.
• Modified the medical records access policy to use the new client and access check endpoint.
• Added a feature flag to toggle the new eligibility check for medical records access

Related issue(s)

https://jira.devops.va.gov/browse/MHV-61122

Implement findings on: Update MR policy to not rely on the old eligibility check

Description
Implement findings on: Update MR policy to not rely on the old eligibility check.

See https://jira.devops.va.gov/browse/MHV-55523

SM is already looking into a new method for determining whether a user is Basic or Premium, so we can potentially use their method, if feasible.

Here are some notes about this:

Currently, to determine MHV account type (basic, advanced, premium), VA.gov is utilizing the bluebutton/geteligibledataclass endpoint. Currently, SM is using this to determine eligibility for users of their app.

However I just spoke with Muazzam and there is some recent concern that this is the wrong endpoint to use. Since the elimination of the "advanced" account type, there are now edge cases for which this endpoint may return wrong results.

There is apparently another endpoint, "sm eligibility" that is more accurate and is the one we should be using. As a side benefit, it accounts for the fact that an eligible user must have a treatment facility, so it satisfies all the acceptance criteria for this ticket.

User Story: As a Medical Records User, I want to be able to easily determine if a user is premium or basic on the backend and implement that solution on va.gov.

Testing done

Tests written for a user having access, not having access, missing parameters, an invalid ICN, and not having the feature flag enabled.

Screenshots

No UI changes.

Acceptance criteria

AC1 Implement the new solution of determining if user is premium or basic from ticket https://jira.devops.va.gov/browse/MHV-55523

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

Do I need to write tests for the mhv_medical_records_policy.rb file? I don't see any tests for other similar policy files.

[LindseySaari]

Seems like there should be a rescue clause here incase of issue in the client requests performed here

Sorry ,I see the validate_client method is in place, but should we also consider logging additional details around the error_message? This could help capture cases where the error originates from the client or a service, especially if the error doesn't fit within the predefined responses you're currently handling (lines 22-24)

[mattwrightva]

Hi Lindsey, thank you for your review. I moved the error handling block to the access method so it would catch client failures as well, and added the error message to the logged details. Let me know if you see anything else that could be improved. Thanks!

[mmoyer-va]

Great job Matt -- this looks good. Don't forget to make the modifications in devops and vsp-infra-application-manifests before merging.

[stevenjcumming]

Consider in the future this approach for readability

Suggested change

	base_request_headers.merge({
	'x-api-key': Settings.mhv.medical_records.x_api_key,
	appToken: Settings.mhv.rx.app_token
	})
	mhv_headers = {
	'x-api-key': Settings.mhv.medical_records.x_api_key,
	appToken: Settings.mhv.rx.app_token
	}
	base_request_headers.merge(mhv_headers)

[mattwrightva]

Good call!