Page tree

Chapter Title “Personas and Patient Access Stories”

Personas are commonly used in user-centered design to describe a fictional character representing a user type that might use a product in a similar way. From a data interoperability perspective, personas are used to visualize the data needs and information workflows for a user type.

 

The stories below define how a consumer would establish the authentication and authorization for an app to access their explanation of benefit and clinical data from their payer. (Consumer access to payer’s clinical data is defined by the Payer Data Exchange (PDex) Implementation Guide (IG)). Once authenticated, authorized and the data is transferred to the app, what an app does with the data is out of scope for this IG.

 

Background:

The payer as a data provider must adhere to all applicable federal and state laws and regulations, when exposing the existence of any other member to the user of the app, when appropriate authorization to access this member's records has been granted. This means that when a payer's server responds to a launch request, only the requesting user, members for whom the user is allowed to make health care decisions (such as minor children), members for whom the user is their personal representative and members that provided consent for the payer to allow this user access to their data, can be listed on the member selection screen.

 

To provide data to their members through their portals, payers establish policies to meet the requirements of federal and state privacy laws and regulations. State privacy laws and regulations vary widely from one another and generally pertain to the release of sensitive data related to specific conditions (e.g., behavioral health, pediatrics, AIDS/HIV). There are other data sharing limitations, such as when there’s a threat to the safety or health of the member; for example, data could be blocked for a spouse with a restraining order against them and the sensitive data of addresses for the member cannot be provided. How payers implement these policies is out of scope of this IG.

 

A user's data returned by the payer through its consumer directed APIs leverages payer privacy policies and user consents held by the payer.

 

Payers would make available their authorization servers to where the apps would redirect the users and where the users would be able to authenticate and authorize their app. Once a user authenticates and grants authorization to their app, the authorization server will create and give the app an access token. These tokens might have expiration dates, so an app may need to get reauthorized occasionally (possibly using a refresh token).

 

Applications will need to be consent-aware in the sense that a person using the app may have access to more data than just his or her own records.

 

The app registration and authorization process would likely be the only common requirement for all the apps. After the initial data retrieval (all or part of the existing data), different apps might select different flows to maintain the data. Behind the scenes, apps may periodically query the API to keep the data up to date. This would continue until the member contacts his payer requesting the token be revoked, or the refresh token expires. After the initial data retrieval, other apps may decide to never store PHI data - instead, they might allow a user to run a query to see his/her data or data of a dependent, but will delete this data as soon as a user exits the app. Or, apps may update information only at the user’s request.

 

The Consumer-Directed Payer Data Exchange (CARIN BB) IG personas describe situations covered under CMS’ Interoperability and Patient Access Final Rule Regulated Entities: Medicare Advantage (MA), Qualified Health Plans (QHPs) on the Federally-facilitated Exchanges (FFEs), Medicaid Managed Care Organizations and Children’s Health Insurance Program (CHIP). The rule applies to the entity in which the member is currently enrolled (42 C.F.R. § 422.119(a)).

 

The personas are real-life examples of consumers in these entities.

 

  1. Husband and wife are covered under a single QHP health insurance policy; wife is HIV positive

Persona: (Bill), has a Qualified Health Plan (QHP) health insurance policy which covers himself and his wife (Ana). Ana is HIV positive. State privacy laws and regulations in the state where Bill and Ana live prevent the release of data related to AIDS/HIV. Through a business process established by the health insurance company, Ana has given her husband permission to access her information associated with the policy. The insurance company will create a Consent record between Bill and Ana. The Consent records may or may not have dates surrounding the consent timeline applicability.

 

Patient Story #1 : Bill uses an app that is registered with his insurance company to access claim information associated with his health insurance coverage. Bill wishes to access his wife’s data. Bill launches the app. The first time he uses the app, it redirects Bill to the insurance company’s authorization server which requests Bill’s credentials. Once the insurance company verifies Bill’s credentials, the app is then granted a token. The app uses Bill’s token to access Ana’s data, the insurer’s server interprets the consent and authorizes the operation. The insurer’s server will return all of Ana’s data with the exception of data associated with her HIV condition as directed by their state’s privacy law and regulations.

 

Patient Story #2 : Ana wishes to use an app to access her data. The authentication and authorization process is the same as in patient story #1. However, the insurer’s server will return all of Ana’s data to her app; i.e., it will not filter the data associated with her HIV condition.

 

  1. A divorced person and the minor children are covered under a prior spouse’s QHP health insurance policy

Persona : A person (Claudette) is divorced and under the divorce decree she and their minor children are covered under her ex-husband’s QHP health insurance policy. Although the policy is issued to her husband, Claudette is able to select information for herself or her children on her husband’s policy. When they were married, Claudette had granted her husband permission to view her data. She has since revoked that permission.

 

Patient Story : Claudette wishes to use an app to access her and her children’s information. The first time she uses the app she is requested to define profiles. Claudette creates a profile for her and each of her children and authenticates each one of them. The app is granted a token for Claudette and each of her children. (As Claudette revoked permission for her ex-husband to see her data, her ex-husband cannot select her data. However, he is able to access the minor children’s data from his app). The app collects data she has requested. What Claudette does with the data after it is downloaded to her app, for example, sharing her data with her primary care physician or sharing her children’s data with their pediatrician, is out of scope for this IG.

 

  1. Child who is a minor on a QHP policy

Persona : A child (Elsa), who is a minor, has health insurance coverage through her Dad (Danny). Danny has a QHP health insurance policy for his wife, Grace, his daughter Elsa and himself. Grace has given her husband permission to access her information. Either parent may access Elsa’s claim information. Elsa does not have the right to access her own health care data because she is a minor.

 

Patient Story : Elsa could download the app registered with the company who provides her health insurance benefits through her Dad’s plan, but she is not an authorized user with the insurance company. Although able to log into the app, Elsa would not be able to access her data.

 

  1. Child on a QHP policy becomes an adult

Persona: A child (Henri), has just had a birthday and he now qualifies as an adult in his state of residence. He has health insurance coverage through his Dad (Julian) who has a QHP health insurance policy which covers himself, his wife (Ida) and his son (Henri). At the time the policy was effective, Henri was a minor. Upon reaching the age of majority in the state of residence, the insurance company by default restricts Julian and Ida from accessing their son’s data as of the current date relative to Henri’s date of birth (DOB).

 

Patient Story : Henri receives a communication from the insurance company that wishes him a happy birthday and supplies his health insurance benefit information. The letter provides instructions about how Henri could establish a user account with the insurer. Henri wishes to download an app that makes it possible for him to access his health insurance claim information. Henri downloads the app. It redirects him to the insurance company’s authorization server which requests Henri’s credentials. Henri follows the instructions provided to him by the insurance company and creates his user account. Once the insurance company verifies Henri’s credentials, the app is then granted a token. He then is able to download his own information. Henri does not have the option to access information for either of his parents. Henri’s parents no longer have the option to access any information for him, unless Henri notifies the insurer to grant them permission to do so.

 

  1. Person grants adult child the right to access her MA health Information

Persona : An elderly person (Kate) has Medicare Advantage. She decides to allow her son (Larry) to access her health information in order to help with paperwork and navigation of her care. She contacts her health insurance company and requests her son be designated as a personal representative. As a personal representative, Larry is allowed access to his mother’s information. (The personal representative designation may also be enabled via a durable power of attorney). Once the request is processed by the insurer, Larry will be allowed access to his mother’s information.

 

Patient Story #1 : Larry does not have health insurance coverage from the company providing the MA coverage for his Mom. Larry receives notification from the insurer that supplies his mother’s health insurance benefits explaining he has been authorized to access his mother’s information on her behalf. The notification provides instructions about how Larry can access his mother’s data. Larry establishes user credentials with the insurance company.

 

Larry wishes to access his mother’s data on his app. Larry uses his app to select the insurance company that covers his mother. It redirects Larry to the insurance company’s authorization server which authenticates and authorizes Larry’s credentials. Once the insurance company verifies Larry’s credentials, the app is then granted a token. Larry is able to download his mother’s information. What Larry does with his mother’s data after it is downloaded to her app, for example, sharing her data with her primary care physician, is out of scope for this IG.

 

Patient Story #2 : Larry has health insurance coverage from the same company providing coverage for his Mom. Larry receives notification from the insurer that supplies his mother’s health insurance benefits explaining he has been authorized to access his mother’s information on her behalf. Larry establishes with the insurance company that his current user credentials with the insurance company can also be used to access his mother’s data in addition to his own data.

 

Larry wishes to access his mother’s data on his app. He indicates to the app that he wishes to access a new patient’s data. The app redirects Larry to the insurer’s authorization server, which authenticates his user ID and authorizes him to access his mother’s data. Larry is able to select his mother from a list of patients and download his mother’s information.

 

  1. A single mother with two minor children lose their QHP commercial health insurance coverage and signs up with Medicaid.

Persona : A single mother, Mindy, loses her job and therefore her commercial health insurance coverage. She signs herself and her two minor children up for Medicaid. Under the commercial coverage, Mindy and her two children were covered under one contract. Under Medicaid, each person is assigned an individual contract. Mindy had established user credentials with her commercial insurer. Mindy establishes her user credentials with the Medicaid insurer. Mindy establishes with Medicaid that she is the legal guardian of the two minor children. The Medicaid insurer authorizes Mindy to see her children’s data under her user account.

 

Patient Story : For the period of time when she and her children were with the commercial payer, it’s assumed that Mindy has her children’s data on her app. Mindy wishes to add her children’s data from the Medicaid insurer to the data she presently has for her children. To download the data from her Medicaid carrier, Mindy selects her Medicaid carrier. The app redirects Mindy to the Medicaid’s authorization server which requests Mindy’s credentials. The app is granted a token for Mindy and each of her children. Mindy is able to download each patient’s data.

 

The app may be able to combine the QHP and Medicaid data for each patient ; however, that is out of the scope for this IG.

 

  1. A person is covered by CMS under traditional Medicare and under Medicaid.

Persona : A person (Nicholas) has Medicare coverage through CMS. Nicholas has dementia and lives in a skilled nursing facility (nursing home). Nicholas is eligible to receive Medicaid benefits. Nicholas’s daughter, Odette, has been designated Nicholas’s personal representative. As Nicholas’s personal representative, Odette has requested and received permission from Medicare and Medicaid respectively to access her father’s data. She has established her user credentials with CMS and with the Medicaid carrier.

 

Patient Story #1 : Odette wishes to use her app to access her father’s Medicare and Medicaid data. Odette’s app is registered with CMS and with the Medicaid carrier. To download the Medicare data to her app, Odette selects CMS as the payer. The app redirects Odette to MyMedicare.gov. Once CMS verifies Odette’s credentials, the app is then granted a token authorizing sharing of her father’s information with the app. Odette is able to download her father’s Medicare data into her app.

 

To download the Medicaid data to her app, Odette selects the Medicaid carrier as the payer. The app redirects Odette to the Medicaid payer’s authorization server. Once the Medicaid payer verifies Odette’s credentials, the app is then granted a token authorizing sharing of her father’s information with the app. Odette is able to download her father’s Medicaid data into her app.

 

How the app presents the Medicare and Medicaid data is out of the scope for this IG.

 

Patient Story #2 : Odette wishes to use her app to access her father’s Medicare and Medicaid data. Odette’s app is registered with CMS. To download the Medicare data to her app, Odette selects CMS as the payer. The app redirects Odette to MyMedicare.gov. Once CMS verifies Odette’s credentials, the app is then granted a token authorizing sharing of her father’s information with the app. Odette is able to download her father’s Medicare data into her app. To download the Medicaid data to her app, Odette searches for the Medicaid insurer as a payer. However, the company providing Odette’s app has not registered with the Medicaid carrier and the Medicaid carrier is not in the app’s payer list. Odette is not able to download her father’s Medicaid data to her app. To download her father’s information, Odette will need to select an app that is registered with CMS and her father’s Medicaid payer.

 

  1. Gap in coverage – Covered Products: A person is enrolled in a Qualified Health Plan product, turns 65, and enrolls in Medicare. A year later, they enroll in a Medicare Advantage product. The QHP product and MA product are with the same payer.

 

 

Persona : A person (Rose) is enrolled with a payer’s Qualified Health Plan product. She turns 65 and enrolls in Medicare. A year later, she enrolls in a Medicare Advantage product. The QHP product and MA product are with the same payer. The payer issues Rose a MA contract that is different from her prior QHP contract. The user ID Rose had established when she was enrolled in the QHP product has expired. Rose re-establishes her user ID with the payer.

 

Patient Story #1 : Rose wishes to access her QHP and MA data through a new app. The app has been registered by the payer. The app redirects Rose to the payer’s authorization server. Rose enters her user credentials. Rose is able to download her MA information from the payer.  Rose requests the payer provide access to her QHP data.  The payer has not elected to link historical products with current products and denies the request for QHP data. Rose is not able to download her QHP information.

 

Patient Story #2 : Rose wishes to access her QHP and MA data through a new app. The app has been registered by the payer. The app redirects Rose to the payer’s authorization server. Rose enters her user credentials. The payer has elected to link historical products with current products and has linked the QHP and MA contracts to Rose’s user ID. Once the payer verifies Rose’s credentials, the app is granted a token. Rose is able to download her MA and QHP information from the payer.   Note that Rose will not have the option to select one of the products; she will receive both QHP and MA data. 

 

  1. Gap in Coverage-Medicare. A person previously enrolled in Medicare, enrolls in Medicare Advantage. Not satisfied with Medicare Advantage, the person re-enrolls in Medicare in the next open enrollment.

Persona : A person (Theresa) was enrolled with CMS to receive her Medicare coverage. During open enrollment, she decided to enroll in a Medicare Advantage product through a private health payer. Not satisfied with the Medicare Advantage product, during the next open enrollment, she decides to re-enroll in Medicare.

 

Patient Story : In the past, Theresa accessed her data through the CMS and payer portals. Theresa wishes to use an app to download her data. Using an app is new for her; she wishes to download her data from CMS and from her prior Medicare Advantage payer. The app has been registered by CMS and the Medicare Advantage payer.

 

To download her CMS data, Theresa uses her app to select CMS. The app redirects Theresa to MyMedicare.gov which authenticates and authorizes Theresa’s credentials. Once CMS verifies Theresa’s credentials, the app is then granted a token. Theresa is able to download her information from CMS. To download her Medicare Advantage data, Theresa uses her app to select the Medicare Advantage payer. It redirects Theresa to the payer who, since she is no longer a covered member, denies her authentication request. Theresa is not able to download Medicare Advantage information.

 

  1. A person is enrolled in Medicare and a Medicare supplemental policy.

Persona : A person (Victor) is enrolled with CMS to receive his Medicare coverage. He is also enrolled in a commercial payer’s Medicare supplement product which pays Medicare’s deductibles and co-pays.

 

Patient Story : Victor wishes to access his CMS and commercial payer’s data through his app. The app has been registered by CMS. The app redirects Victor to MyMedicare.gov which authenticates and authorizes his credentials. Once CMS verifies Victor’ credentials, the app is then granted a token. Victor is able to download his information from CMS. Victor wishes to access his data from the commercial payer. Although Victor’s app is registered with the commercial payer, it is registered for the Medicare Advantage product the commercial payer offers, but not for the Medicare supplemental product which Victor has purchased. Victor is not able to download his Medicare Supplemental data.

 

The CMS Patient Access and Interoperability rule requires health plans with Medicare Advantage plans including Medicare Advantage Prescription Drug plans, CHIP agencies, CHIP Managed Care plans, State Medicaid Agencies, Medicaid Managed Care plans, and Qualified Health Plans (QHPs) in the Federally Facilitated Exchange  to offer consumer access to information through standards-based APIs. It does not require payers to provide information through standards-based APIs for other products, such as Medicare supplemental products. However, there is nothing in the Implementation Guide preventing a payer from doing so.

 

  1. A person is enrolled in a QHP product, turns 65, and enrolls in the payer’s Medicare Advantage product.

Persona : A person (Sam) is enrolled with a payer’s Qualified Health Plan product. He turns 65 and enrolls in the payer’s Medicare Advantage product. The payer issues Sam a new MA contract. The CMS Patient Access and Interoperability rule requires health plans to provide data to active members. While Sam is no longer active under the QHP coverage, he is active with the same payer.  Sam may continue to have access to his QHP data if the payer has linked the QHP and MA contracts to Sam’s user ID.

 

Patient Story #1: Sam wishes to access his QHP and MA data through a new app. The app has been registered by the payer. The app redirects Sam to the payer’s authorization server. The payer has not linked the QHP and MA contracts to Sam’s user identifier. Sam enters his user credentials. Once the payer verifies Sam’s credentials, the app is granted a token. Sam is able to download his MA information from the payer. However, Sam is not able to download his QHP information. 

 

Patient Story #2 : Sam wishes to access his QHP and MA data through a new app. The app has been registered by the payer. The app redirects Sam to the payer’s authorization server. The payer has linked the QHP and MA contracts to Sam’s user ID. Once the payer verifies Sam’s credentials, the app is then granted a token. Sam is able to download his QHP and MA information from the payer. Note that Sam will not have the option to select one of the products; he will receive both QHP and MA data. 

 

 

  1. Coordination of Benefits: A beneficiary is covered under two health insurance policies with the same payer

Persona: A person (Wanda) has a health insurance policy through her employer (A) which covers her husband (Peter) and her. Wanda is also covered under the health insurance policy held by Peter through his employer (B). As the primary carrier, the policy through Wanda’s employer (A) will first apply benefits. The policy provided by employer (B) will then apply benefits to Wanda’s claim. Two claims result, one for each set of benefits adjudicated under each employers’ benefit plan. Both policies are with the same payer.

 

Patient Story #1: Wanda wishes to uses an app to access information relevant to the benefits she received. The first time she uses the app, she selects her contract. The app redirects to the payer’s authorization server which requests Wanda’s credentials. Wanda enters her credentials. The app is granted a token to use when requesting her information via the payer’s API.

 

If the payer has linked Wanda’s user credentials to her data under her policy and to her data under Peter’s policy, the app will be able to download Wanda’s data for both policies. If the insurer has not linked her credentials to the two policies, Wanda will be required to enter her credentials for each policy and the app would receive a two tokens. Wanda would download the data paid under her employer (A)’s coverage. She then would download the data paid under her husband’s (B)’s coverage.

 

Patient Story #2: If Wanda and Peter’s policies are with different payers, Wanda will need to authenticate and authorize with each payer.