Chapter Title “Personas and Patient Stories”
Personas are commonly used in user-centered design to describe a fictional character who would represent 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 EOB data from their p ayer. (Consumer access to payer’s clinical data is defined by the PDex Implementation Guide). 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.
To uphold the consumer’s right to privacy under federal regulations and state laws, the payer as a data provider must not expose the existence of any other member to the user of the app, unless the user is authorized to access this member's records. This means that when a payer's server responds to a launch request, only the requesting user, members for whom under applicable law 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 EOBs and other data to their members through their portals, payers establish policies to meet the requirements of federal and state privacy laws. State privacy laws 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 for whom a restraining order has been placed against 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 data holder 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. Payers are required to support a Patient Scope. Under Patient Scope, a user requests an OAuth server to return a separate patient scope token for each patient for whom they have an authorization. An app would use these tokens for accessing data of the authorized patients. (Payer OAuth servers may support User Scope. When the OAuth server responds to a launch request, a list of tokens for each member for whom consent is given will be presented back to the app. The app would use the tokens to present back to the user on the patient selection screen.) Once a user has completed the login sequence all interactions between the application and the server will be conducted through the context of a single member.
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 insurance EOBs or EOBs 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 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 CHIP. The rule applies to current patients and their personal representatives. The personas are real-life examples of consumers in these entities.
Persona: (John), has a Qualified Health Plan (QHP) health insurance policy which covers himself and his wife (Mary). Mary is HIV positive. Through a business process established by the health insurance company, Mary has given her husband permission to access her claims information associated with the policy. The insurance company will create a Consent record between John and Mary. The Consent records may or may not have dates surrounding the consent timeline applicability.
Patient Story #1 : John uses an app that is registered with his insurance company to access claim information associated with his health insurance coverage. John wishes to access his wife’s data. John launches the app. The first time he uses the app, it redirects John to the insurance company’s authorization server which requests John’s credentials. Once the insurance company verifies John’s credentials, the app is then granted a token. John’s token will be sufficient to access both his and Mary’s data. The app uses John’s token to access Mary’s data, the insurer’s server interprets the consent and authorizes the operation. Depending on how the app issues a request, it may just ask for John’s data or Mary’s data, or both at the same time. The insurer’s server will return all of Mary’s data with the exception of those claims associated with her HIV condition.
Patient Story #2 : Mary wishes to use an app to access her data. The authentication and authorization process is the same. However, the insurer’s server will return all of Mary’s data to her app; i.e., it will not filter the claims associated with her HIV condition.
Persona : A person (Sue) 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, Sue is able to select information for herself or her children on her husband’s policy. When they were married, Sue had granted her husband permission to view her data. She has since revoked that permission.
Patient Story : Sue wishes to use an app to access her and her children’s claims information. The first time she uses the app she is requested to define profiles. Sue creates a profile for her and each of her children and authenticates each one of them. The app is granted a token for Sue and each of her children. (As Sue 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 EOB information she has requested. What Sue 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.
Persona : A child (Jennie), who is a minor, has health insurance coverage through her Dad (Bob). Bob has a QHP health insurance policy for his wife, Barbara, his daughter Jennie and himself. Barbara has given her husband permission to access her claims information. Either parent may access the child’s claim information. Jennie does not have the right to access her own health care data because she is a minor.
Patient Story : Jennie 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, Jennie would not be able to receive her claims data.
Persona: A child (Ben), 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 (Dave) who has a QHP health insurance policy which covers himself, his wife (Donna) and his son (Ben). At the time the policy was effective, Ben was a minor. Upon reaching the age of majority in the state of residence, the insurance company by default restricts Dave and Donna from accessing their son’s data as of the current date relative to Ben’s date of birth (DOB).
Patient Story : Ben receives a communication from the insurance company that wishes him a happy birthday and supplies his health insurance benefits. The letter provides instructions about how Ben could establish a user account with the insurer. Ben wishes to download an app that makes it possible for him to access his health insurance claim information. Ben downloads the app. It redirects him to the insurance company’s authorization server which requests Ben’s credentials. Ben follows the instructions provided to him by the insurance company and creates his user account. Once the insurance company verifies Ben’s credentials, the app is then granted a token. He then is able to download his own EOB information. Ben does not have the option to access EOB information for either of his parents. Ben’s parents no longer have the option to access any EOB information for him, unless Ben notifies the insurer to grant them permission to do so.
Persona : An elderly person (Joyce) has Medicare Advantage. She decides to allow her son (Mark) 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, Mark is allowed access to his mother’s claims information. (The personal representative designation may also be enabled via a durable power of attorney). Once the request is processed by the insurer, Mark will be allowed access to his mother’s claims.
Patient Story #1 : Mark does not have health insurance coverage from the company providing the MA coverage for his Mom. Mark receives notification from the insurer that supplies his mother’s health insurance benefits explaining he has been authorized to access his mother’s EOB information on her behalf. The notification provides instructions about how Mark can access his mother’s data. Mark establishes user credentials with the insurance company.
Mark wishes to access his mother’s data on his app. Mark uses his app to select the insurance company that covers his mother. It redirects Mark to the insurance company’s authorization server which authenticates and authorizes Mark’s credentials. Once the insurance company verifies Mark’s credentials, the app is then granted a token. Mark is able to download his mother’s EOB information. What Mark 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 : Mark has health insurance coverage from the same company providing coverage for his Mom. Mark receives notification from the insurer that supplies his mother’s health insurance benefits explaining he has been authorized to access his mother’s EOB information on her behalf. Mark 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.
Mark 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 Mark to the insurer’s authorization server, which authenticates his user id and authorizes him to access his mother’s data. Mark is able to select his mother from a list of patients and download his mother’s EOB information.
Persona : A single mother, Amanda, loses her job and therefore her commercial health insurance coverage. She signs up herself and her two minor children for Medicaid. Under the commercial coverage, Amanda and her two children were covered under one contract. Under Medicaid, each person is assigned an individual contract. Amanda had established user credentials with her commercial insurer. Amanda establishes her user credentials with the Medicaid insurer. Amanda establishes with Medicaid that she is the legal guardian of the two minor children. The Medicaid insurer authorizes Amanda 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 Amanda has her children’s data on her app. Amanda 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, Amanda selects her Medicaid carrier. The app redirects Amanda to the Medicaid’s authorization server which requests Amanda’s credentials. The app is granted a token for Amanda and each of her children. Amanda 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.
Persona : A person (Joe) has Medicare coverage through CMS. Joe has dementia and lives in a skilled nursing facility (nursing home). Joe is eligible to receive Medicaid benefits. Joe’s daughter, Eileen, has been designated Joe’s personal representative. As Joe’s personal representative, Eileen 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 : Eileen wishes to use her app to access her father’s Medicare and Medicaid data. Eileen’s app is registered with CMS and with the Medicaid carrier. To download the Medicare data to her app, Eileen selects CMS as the payer. The app redirects Eileen to MyMedicare.gov. Once CMS verifies Eileen’s credentials, the app is then granted a token authorizing sharing of her father’s information with the app. Eileen is able to down load her father’s Medicare data into her app.
To download the Medicaid data to her app, Eileen selects the Medicaid carrier as the payer. The app redirects Eileen to the Medicaid payer’s authorization server. Once the Medicaid payer verifies Eileen’s credentials, the app is then granted a token authorizing sharing of her father’s information with the app. Eileen 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 : Eileen wishes to use her app to access her father’s Medicare and Medicaid data. Eileen’s app is registered with CMS. To download the Medicare data to her app, Eileen selects CMS as the payer. The app redirects Eileen to MyMedicare.gov. Once CMS verifies Eileen’s credentials, the app is then granted a token authorizing sharing of her father’s information with the app. Eileen is able to down load her father’s Medicare data into her app. To download the Medicaid data to her app, Eileen searches for the Medicaid insurer as a payer. However, the company providing Eileen’s app has not registered with the Medicaid carrier and the Medicaid carrier is not in the app’s payer list. Eileen is not able to down load her father’s Medicaid data to her app. To download her father’s information, Eileen will need to select an app that is registered with CMS and her father’s Medicaid payer.
Persona : A person (Evelyn) 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 with CMS.
Patient Story : In the past, Evelyn accessed her data through the CMS and payer portals. Evelyn 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, Evelyn uses her app to select CMS. The app redirects Evelyn to MyMedicare.gov which authenticates and authorizes Evelyn’s credentials. Once CMS verifies Evelyn’s credentials, the app is then granted a token. Evelyn is able to download her EOB information from CMS for both periods of time when she was with CMS. To download her Medicare Advantage data, Evelyn uses her app to select the Medicare Advantage payer. It redirects Evelyn to the payer who, since she is no longer a covered member, denies her authentication request. Evelyn is not able to download Medicare Advantage EOB information.
Persona : A person (Dennis) 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 : Dennis wishes to access his CMS and commercial payer’s data through his app. The app has been registered by CMS. The app redirects Dennis to MyMedicare.gov which authenticates and authorizes his credentials. Once CMS verifies Dennis’ credentials, the app is then granted a token. Dennis is able to download his EOB information from CMS. Dennis wishes to access his data from the commercial payer. Although Dennis’ 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 Dennis has purchased. Dennis is not able to download his Medicare Supplemental data.
The CMS Patient Access and Interoperability rule requires health plans in Medicare advantage, Medicaid fee-for-service, Medicaid CHIP plans, Medicaid managed care plans, and qualified health plans (QHPs) in the federally-facilitated exchange marketplace to offer consumer access to plan and claims 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.
Persona: A person (Jane) has a health insurance policy through her employer (A) which covers her husband (Jim) and her. Jane is also covered under the health insurance policy held by Jim through his employer (B). As the primary carrier, the policy through Jane’s employer A will first apply benefits. The policy provided by employer (B) will then apply benefits to Jane’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: Jane wishes to uses an app to access claims information relevant to the benefits she received for her claims. The first time she uses the app, she selects her contract. The app redirects to the payer’s authorization server which requests Jane’s credentials. Jane 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 Jane’s user credentials to her data under her policy and to her data under Jim’s policy, the app will be able to download Jane’s data for both policies. If the insurer has not linked her credentials to the two policies, Jane will be required to enter her credentials for each policy and the app would receive a two tokens. Jane would download the EOBs paid under her employer (A)’s coverage. She then would download the EOBs paid under her husband’s (A)’s coverage.
Patient Story #2: If Jane and Jim’s policies are with different payers, Jane will need to authenticate and authorize with each payer.