Stream: Da Vinci PDex Drug Formulary
Topic: CMS requirements for formulary
Craig McClendon (Jan 18 2022 at 23:56):
I'm having trouble wrapping my head around the CMS requirements as they pertain to the formulary APIs.
First off, can someone confirm that they are required at this time (for Medicare Part D plans, etc.)?
Second, they are mentioned as part of the Patient Access APIs as others have pointed out, but from looking at the IG and this stream I understand they are patient agnostic and contain no PII. Is it reasonable/allowed under the CMS guidelines to host them only under an unauthenticated base URL separate from the Patient Access APIs. I assume so, but it's confusing that CMS lumps them in with Patient Access rather than Provider Directory or on their own making me question it.
Corey Spears (Jan 19 2022 at 01:35):
The enforcement of the regulation hinted at (CMS-9115-F - https://www.cms.gov/files/document/cms-9115-f.pdf) has varying enforcement dates based on the specific requirement. Formulary is listed as part of the Patient Access API and was required on 1/1/2021, but enforcement delayed until 7/1/2021. This page may be helpful: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
While the Da Vinci Drug Formulary IG does not include resources that are member specific, the IG does specify authenticated or non-authenticated methods of access (http://hl7.org/fhir/us/davinci-drug-formulary/use_cases_and_overview.html#access-methods). Authenticated access provides responses to queries that are specific to the member's coverage. Since the information is connected to a member through the interaction, it could be considered PHI (knowing who the member is along with their plan information).
Authenticated access was added to the IG in response to the Formulary API being placed in the patient access API requirement of the regulation.
The determination of which access method is sufficient to meet CMS requirements would probably be best answered by CMS.
Craig McClendon (Jan 19 2022 at 16:26):
The Authenticated access guidance in the 1.1.0 IG is confusing (to me). (NOTE: it's also not present in the 1.0.1 IG version CMS references.)
It says:
"When accessing data through an authenticated API, the response depends on whether the member is currently enrolled in a plan and whether they are a member of a group."
Is the FHIR server supposed to infer from the user's authenticated identity the user's plan/group rather than responding to the query as asked? Is an authenticated user not allowed to query for plan IDs that are not their own? i.e. not allow to "shop" or compare plans. Or am I misunderstanding the table?
Thinking out loud -
Authentication does not protect the communication of a query in any way. A bad actor could potentially snoop and see I am querying for a specific plan ID or drug whether I'm authenticated or not. Authentication just lets the server know what information it can return to me, essentially.
If an app has authenticated access the Patient APIs it could query for things like my medications, my planID, etc. Then it could use that information to query the unauthenticated formulary APIs for non-protected data about various plans, covered drugs, etc. If the formulary APIs never respond with any member-specific information there is really no need for authenticated access to them and they could serve the 'shop for plans' and 'see what my plan covers' use-cases equally.
What am I missing?
Corey Spears (Jan 20 2022 at 03:38):
That is correct, the idea is that the authenticated identity would be associated with a member's plan/group and there fore the user would have access to plan/group/formulary data related to their plan. This was included in the IG to bring it in line with the rest of the Patient Access API requirements and to provide data that is specific for the member.
If a payer choses to offer a shopping experience, a user could access the non-authenticated API (How this is managed by the payer is out of scope of the IG).
Usual exchange security protocols are required. For Formulary those are specified by HReX, which specifies the use of TLS (http://hl7.org/fhir/us/davinci-hrex/2020Sep/security.html)
Craig McClendon (Jan 20 2022 at 16:37):
How does one link the Patient resource to a plan/group? I see some prior discussions when @Lee Surprenant posed a similar question, but no definitive answer. Is it the expectation that this is done outside of FHIR with special server-side business logic?
Daniel Venton (Jan 20 2022 at 16:41):
A formulary and plan definitions are not linked to a patient. They exist outside of these blueprint resources. Later on when you have a coverage that links a member (patient) to a specific plan. Plan 1 which has formulary 1. Patient 1 buys Coverage from the insurer, Thus the member is linked to their plan via Coverage (member 1, Plan 1).
I hope I got my terminology correct.
Corey Spears (Jan 21 2022 at 20:55):
Yes, this is correct. We have not included Coverage as the information contained is not a requirement of the regulation. As currently defined, the means in which to connect an authenticated identity to an InsurancePlan is not specified by the IG. The implementer can choose how they would like to make that happen.
Craig McClendon (Jan 21 2022 at 21:41):
Thanks for engaging with me, @Corey Spears . It seems this would all be simpler if the formulary APIs did not consider the authenticated user and just allowed apps to query for the (non-private) formulary data. Users could query for their current plan, a different plan, etc. Apps which are authenticated to the Patient APIs could fetch Coverage and MedicationXX data and use that info to query/compare different formularies. Other apps could compare across different plans (different payers perhaps) with no access to patient info at all and let the user filter for things that matter to them.
It is stated here that formulary data is not PHI and should be 'widely available':
https://www.federalregister.gov/documents/2020/05/01/2020-05050/medicare-and-medicaid-programs-patient-protection-and-affordable-care-act-interoperability-and
"In the proposed rule, we explained this included two types of information: personal health information that health care providers and health plans, or payers, must make available to an individual, such as their current and past medical conditions and care received; and information that is of general interest and should be widely available, such as plan provider networks, the plan's formulary, and coverage policies."
It's just the statement here that muddles it by including it with Patient Access:
https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index
"Under the CMS Interoperability and Patient Access final rule, Part D Medicare Advantage plans must make formulary information available via the Patient Access API. "
But does that mean Formulary APIs MUST be authenticated and at the same base URL as Patient Access?
Corey Spears (Jan 28 2022 at 21:37):
The authenticated access has been identified as the method associated with the Patient Access API. A response to this question has been posted on theFAQ, which can be found here (question 6017):
https://confluence.hl7.org/display/DVP/CMS+Final+Rule+Questions+and+Answers+log
Josh Mandel (Jan 29 2022 at 17:59):
Are you saying there's no requirement to publicly make the non-PHI data available?
Josh Mandel (Jan 29 2022 at 18:00):
Curious why this would be different here versus the public requirements for, say, provider directory and other non-PHI.
Craig McClendon (Jan 31 2022 at 19:05):
The response from CMS referenced states:
"The final rule does require that the formulary data specific to the patient in question be made available via the Patient Access API. As such, access to the formulary service when integrated with protected health information (PHI) or personally identifiable information (PII) as part of the Patient Access API shall be protected through an authorized, authenticated transaction."
But there is a disconnect in that the Formulary APIs don't integrate with any PHI - you can't include any query parameters that contain PHI, and they don't return any PHI.
Lacking an option through the APIs, the IG seems to suggest implementers should filter the data using some custom logic - presumably using the auth headers to determine the user, link to a plan, and filter the formulary request to that plan.
But how does the server know when a request should use the custom logic vs execute the query as given?
It feels un-FHIR-like.
Josh Mandel (Jan 31 2022 at 19:38):
"formulary data specific to the patient in question" doesn't seem to describe the use case here though, agreed.
Josh Mandel (Jan 31 2022 at 19:39):
It'd be good to have a clear publication pattern for open (and potentially bulk) public data sets, similar to what's done for provider directories.
Josh Mandel (Jan 31 2022 at 19:39):
We did something similar for COVID vaccine appointment data at https://github.com/smart-on-fhir/smart-scheduling-links/blob/master/specification.md (major pharmacies publishing slots in FHIR NDJSON files, which clients can statically fetch)
Corey Spears (Feb 01 2022 at 05:34):
We will discuss this in an upcoming PDEX leadership meeting.
Craig McClendon (Mar 29 2022 at 14:40):
Hi @Corey Spears, was the topic of the need for authenticated formulary access ever raised in a PDEX leadership meeting?
As you can piece together from my prior posts on the topic, I don't understand the need for authenticated access to Formulary APIs. And if there is no need then I think the authenticated access guidance in the IG places unnecessary burden on implementers to create one-off, custom solutions.
If I'm wrong (quite possible), I'd be appreciative if someone could explain the need.
Last updated: Apr 12 2022 at 19:14 UTC
