Promoting Interoperability: Patient Access APIs

General Question: What is the overall process for a patient to retrieve their health information via the API using an app? A patient identifies an app that they would like to use to access their health information. They follow the instructions provided by your organization to request use of the app. Your organization screens and vets the application per the policies and procedures outlined by your internal security/legal teams; engages MEDITECH via an NMI Task to assist you with testing and onboarding the app into your MEDITECH EHR; and notifies the patient that access is available. Next, the patient accesses the app on their device and is asked to authenticate-- depending on your set up, their existing MEDITECH Portal username/password could be used to authenticate OR they could log on using their username/password for a 3rd party IdP, such as Google. Once they successfully authenticate, the patient requests their health information. Depending on the app, this could include medications, lab results, etc. The API retrieves the requested data from the MEDITECH EHR and returns it to the patient to view within the app. Question: Is there an audit trail available for health information which is accessed via API? There is full audit capability of the REST infrastructure within the SQL database which is stood up as part of REST, as well as full audit capability within the EHR itself. Your typical patient audit will be updated to reflect that data was retrieved and looked at via the API. If you have more questions or concerns once you have your REST infrastructure stood up and your authentication realm set up, the API team under NMI/IOP can work with you to test that out and show you what the audits look like. Question: My organization uses a non-MEDITECH Patient Portal. Can we still use MEDITECH’s API interfaces? Yes. MEDITECH's APIs are set up separately from the Portal and can be utilized for patient access regardless of whether you are using a MEDITECH or other vendor Portal solution.
Compliance Question: What are the requirements to meet the Stage 3 Provide Patient Electronic Access to Their Health Information measure? There are 2 components to this requirement 1) Providing access to the patient and 2) Enabling the API functionality for use with an app of the patient's choice. 1. Providing Access to the Patient: Patients must be provided access to their health information both via a Portal and via an API. Guidance on how to offer this access as well as how it will be counted can be found in our Stage 3 best practice for Provider to Patient Exchange. In short, your current process for offering patients access to the Portal can be modified to also include information on what to do if they have an app that they would like to use to access their health information (ie. contact Medical Records at ###-##-###). The same 3 methods for counting this (query, discharge forms or enrollment/access) are still available and will need to be updated to reflect that information was provided for access via both the Portal and API. 2. Enabling API functionality for use with an app of the patient's choice: API functionality must be fully enabled such that any application chosen by a patient would allow them to gain access to their individual health information, provided the application is configured to meet the technical specifications of the API. Below are the steps to enable your API functionality for use with an app: INFRASTRUCTURE: Deploy MEDITECH's RESTful API infrastructure via TECH Task "Hardware Evaluation: Meaningful Use Stage 3 Requirements" CONTENT: Complete the build for the PI3 Compliant CCD including new required fields and sections. This is necessary because the data that comprises the PI3 compliant CCD is the data available to apps via the API. Information can be found on our CCD Resource Center. Support from MEDITECH's clinical applications will be offered via M Task "PI3 CCD Update Project" during your scheduled implementation. CODE: Accept additional code for Patient Access via NMI Task "MD: Additional Code for PI3 Patient Access". Once this code is LIVE and the task is Complete, we will open a new NMI Task titled "Patient Access Staging" to begin work with you on staging the API. Note: Portal and MPM customers may have related tasks for these applications which will also need to be accepted. AUTHENTICATION REALM: Work with MEDITECH to set up your Authentication Realm via NMI Task "Patient Access Staging". Authentication can be set up to utilize the MEDITECH Patient Portal credentials or it can be set up to utilize a 3rd party IdP. NOTE: CMS specifications for Patient Electronic Access do not require testing with an app prior to your reporting period. The steps listed above will enable the API functionality for use with any app that you would like to onboard into your system in the future. Question: Does my organization need to provide patients with a specific app to use for accessing their data via the API? The final rule (pg 520) states that the measure does not require that the eligible hospital or CAH provide an application for its patients’ use. The patient must have the ability to access their health information via an application of their own choice. Additional considerations on this topic can be found on HHS.gov. It will be up to your organization to develop security policies and procedures for screening and vetting apps that have been presented by patients requesting their health information. Question: The performance based objective states “at least one unique patient” do I need to provide access for only one patient to get full credit? For the current EH, EP, EC Medicare & Dual Eligible programs, entering one patient in a measure numerator will only get you the minimum allotted points. The total available points for the Provide Patient Access measure is 40 points. Your points are based on your level of compliance, so full credit will not be awarded unless you are 100% compliant with the measure. See CMS FAQ (pg 3 under Provider to Patient Exchange Objective) for additional information. Question: What if no patient requests to connect via an application during the 90 day reporting period? You do not receive a penalty for low buy-in with API usage among your patient population. What is important is that you have the ability to meet the functional standards for on-boarding an application. Having the necessary infrastructure in place leaves you in compliance with the measure and in a position to be prepared once there is greater demand within the industry.
Offering Access Question: Do we need to build a new query to track access to the API or do we update our Patient Portal access query from Stage 2? If you are tracking offering patients access to a patient portal via the query workflow, then you are able to simply update your current query to reflect you also offered API access. The query may remain set to demo recall as at the time it is updated you should already have a process in place for offering access to both the portal and API. You do not have to create a new query or create an additional query to specifically track API access. If your organization would prefer to create a new query then you will need to update the SQL parameters to reflect the new query mnemonic and inactivate the old query. Please review the Stage 3 Best Practice for Provider to Patient Exchange for additional information on recommended workflows. Question: What text does MEDITECH recommend we use on the discharge form? Sample text can be found in the Stage 3 Best Practice for Provider to Patient Exchange under MEDITECH's Recommended Workflows.
App Vetting & Onboarding Question: What apps can be used for a patient to access their data via the API? MEDITECH does not have a list of apps that can be used for Patient Access. The Stage 3 requirement states that the patient can use any app of their choosing which meets the specifications of the EHR. MEDITECH's APIs are app agnostic, utilizing FHIR industry standards, and can be accessed via any app that is developed in accordance with FHIR. It is up to you as an organization to put a process in place to screen and vet possible apps patients present. Question: We are using the MHealth app - does this app work with MEDITECH’s API? No. MEDITECH’s MHealth app allows patients to access our Portal via an app. It does not utilize API technology. To access data via an API, patients will use a 3rd party app that meets the specifications or MEDITECH’s EHR. Question: How does my organization vet a patient selected application? It is up to your organization to put a process in place for vetting an application. Aside from being built according to the FHIR protocols, your organization may require additional security and network safeguards, evaluation of terms and conditions, etc in order to meet your internal standards for privacy and security. You should work with your IT/networking and legal staff to develop a process for reviewing patient selected applications according to the standards you have in place. Question: What if a patient selected application does not meet our security standards? The final rule (beginning on pg 520) includes language confirming that reasonable action can be taken to protect the privacy and security of their patients’ information, including vetting application developers prior to allowing their applications to connect to the API functionality of the provider’s health IT. It should also be noted that denying an application does not remove a patient from the numerator as they were still offered access and could still access their information via portal and API should they select an application that will meet your security requirements. Question: Once an app has been vetted and approved by my organization, what is the next step? After your organization has vetted an application, MEDITECH can be engaged via an NMI Task (use Task Category ON-BOARD) to help the app vendor test in Greenfield, before onboarding them directly to your test or production environment. MEDITECH Greenfield is a testing ground for apps that can integrate with MEDITECH. Developers have the ability to execute the APIs and test their applications against a real MEDITECH EHR. It also gives customers and application developers access to interactive documentation for the APIs published by MEDITECH. Question: Is there a limit to how many apps we can connect to? There is no limit. You may connect to as many as are presented to you and approved by your vetting process. Question: What are the requirements to onboard the Apple Health app for use with the MEDITECH EHR? MEDITECH Patient and Consumer Health Portal users can onboard the Apple Health app once RESTful API infrastructure has been deployed/validated and you are at the required release. The clinical build for the PI3 compliant CCD must be complete prior to testing. Click here for additional details on how to give your patients access to their Health Records on iPhone. Question: What are the MEDITECH release requirements for onboarding the Apple Health app? MEDITECH’s EHR has completed Apple certification, which extends beyond the Patient Access API requirements set forth by CMS/ONC. The following software release, as well as an update to REST packages, will be required before onboarding the Apple Health app: Expanse 2.1.10+ and 2.2.1+ 6.16 pp25+ 6.15 pp51+ 6.08 Acute pp39+ 6.08 MPM: pp41+ CS 5.67 TBD () MG 5.67 TBD () CS and MG code is being tested by Early Adopters. Release requirements will be finalized pending this testing. Your update to the above releases will also provide enhancements to functionality for other known patient health apps as well as the code needed for HIE measure 2: Receiving and Incorporating Health Information. Please contact your Account Manager/HCIS Coordinator to schedule your update. Question:* If a patient requests access to their health information using Apple’s Health app, but I cannot onboard this at my current release, am I still in compliance with the Promoting Interoperability Patient Access requirement? Yes. Use of the Apple Health app requires additional code that is outside the scope of what is required by CMS/ONC and beyond what is included in MEDITECH’s API specifications. MEDITECH is pleased to offer this functionality, but an update will be needed in order to obtain the code which has been Apple-certified. Question: Can we use the Apple Health App at our Pediatric Clinics/Hospitals? While there is no technical limitation, the workflow is not desirable in a Pediatric setting. Apple’s current release supports primary access to health records vs proxy access. In simplest terms, this means review of a child's data on the parents’ phone. Within the Apple Health app, there is no indication of which data belongs to the child vs the parent/user. Since most pediatric data is viewed via proxy access, Apple recommends not onboarding Pediatric locations at this time. MEDITECH’s API offering will need no changes once Apple adds this functionality in the future. Please open an NMI task for the Interoperability API team if you'd like to discuss further.
Authentication & Identity Providers (IdP) Question: What is an Identity Provider? An Identity Provider, or IdP, will sit between the patient facing app and MEDITECH’s APIs to broker authentication access to the API data. If this is confusing, it might be easier first to think of a non-EHR example. When using a mobile app, such as Uber or MyFitnessPal, you may sign up for these apps by using your Google or Facebook account. By doing so, you are granting Uber or MyFitnessPal access to Google or Facebook to authenticate using those credentials. By providing these permissions, your new app has access to your Google email or Facebook email, and assigns it to your user. Instead of saving a password with Uber or MyFitnessPal, you use Google or Facebook to sign in. Google or Facebook authenticates you confirming your identity, allowing you to use the app. The MEDITECH workflow is actually very similar. There is a published medical records workflow that outlines where external identities, such as your email address, can be associated to a medical record in HIM/MRI. An IdP would authenticate an email address stored on the medical record, confirm its authenticity, and signal to MEDITECH “it’s ok to open up the clinical data file to the app requesting it.” Question: Do I need an IdP to manage patient access? Customers who use a non-MEDITECH Portal solution will need to set up a 3rd party IdP to manage external identities. For MEDITECH Portal users, there is functionality available which simplifies the authentication process and eliminates the need for a 3rd party IdP. Our API analysts will work with you to set up the appropriate authentication realm. Question: What 3rd party IdPs can be used? MEDITECH has tested this functionality with Google Identity Solution, however any IdP that utilizes OpenID Connect or SAML 2.0 can be utilized. Before selecting an IdP for your organization, please work with MEDITECH so due diligence can be done to confirm its compatibility with RESTful API Infrastructure. Question: Can we set up more than one IdP? Yes. While it is only required to set up one authentication method, the authentication realm can be set up to support login via multiple 3rd party IdPs and/or authentication via the MEDITECH Portal. When the patient accesses the app they will be presented with the options that your organization has set up for authentication. Once they have selected their authentication method and enter their credentials the app will allow them to proceed with the process of requesting their data. Question: Is the Manage User Identities routine/workflow outlined in the Provider to Patient Exchange best practice required when authenticating via MEDITECH Portal credentials? No. As noted in the best practice, for organizations with a non-MEDITECH Portal, the patient must be added to the Manage User Identities for Patient Access routine in order to provide the patient with credentials to sign into the API application. When organizations use the MEDITECH Portal, the patient will use the same credentials for the API application as they use to access the Portal. Question: For IdP authenticated patients, if they are a guarantor for others, do they each need to set up an account? The account and the way the app works is up to the app itself. Certain apps allow for proxy users to show up within the app, and others are user based and only allow for one user. When logging in with your credentials, an approval page is presented displaying the medical records you have access to. That would include your own medical record as well as any proxy access you have access to. The one you select is the one the app is granted access to. If an app has proxy access, you would be prompted to log in multiple times to have access to the multiple accounts.

General

Question: What is the overall process for a patient to retrieve their health information via the API using an app? A patient identifies an app that they would like to use to access their health information. They follow the instructions provided by your organization to request use of the app. Your organization screens and vets the application per the policies and procedures outlined by your internal security/legal teams; engages MEDITECH via an NMI Task to assist you with testing and onboarding the app into your MEDITECH EHR; and notifies the patient that access is available. Next, the patient accesses the app on their device and is asked to authenticate-- depending on your set up, their existing MEDITECH Portal username/password could be used to authenticate OR they could log on using their username/password for a 3rd party IdP, such as Google. Once they successfully authenticate, the patient requests their health information. Depending on the app, this could include medications, lab results, etc. The API retrieves the requested data from the MEDITECH EHR and returns it to the patient to view within the app.

Question: Is there an audit trail available for health information which is accessed via API? There is full audit capability of the REST infrastructure within the SQL database which is stood up as part of REST, as well as full audit capability within the EHR itself. Your typical patient audit will be updated to reflect that data was retrieved and looked at via the API. If you have more questions or concerns once you have your REST infrastructure stood up and your authentication realm set up, the API team under NMI/IOP can work with you to test that out and show you what the audits look like.

Question: My organization uses a non-MEDITECH Patient Portal. Can we still use MEDITECH’s API interfaces? Yes. MEDITECH's APIs are set up separately from the Portal and can be utilized for patient access regardless of whether you are using a MEDITECH or other vendor Portal solution.

Compliance

Question: What are the requirements to meet the Stage 3 Provide Patient Electronic Access to Their Health Information measure? There are 2 components to this requirement 1) Providing access to the patient and 2) Enabling the API functionality for use with an app of the patient's choice.

1. Providing Access to the Patient: Patients must be provided access to their health information both via a Portal and via an API. Guidance on how to offer this access as well as how it will be counted can be found in our Stage 3 best practice for Provider to Patient Exchange. In short, your current process for offering patients access to the Portal can be modified to also include information on what to do if they have an app that they would like to use to access their health information (ie. contact Medical Records at ###-##-###). The same 3 methods for counting this (query, discharge forms or enrollment/access) are still available and will need to be updated to reflect that information was provided for access via both the Portal and API.

2. Enabling API functionality for use with an app of the patient's choice: API functionality must be fully enabled such that any application chosen by a patient would allow them to gain access to their individual health information, provided the application is configured to meet the technical specifications of the API. Below are the steps to enable your API functionality for use with an app:

INFRASTRUCTURE: Deploy MEDITECH's RESTful API infrastructure via TECH Task "Hardware Evaluation: Meaningful Use Stage 3 Requirements"

CONTENT: Complete the build for the PI3 Compliant CCD including new required fields and sections. This is necessary because the data that comprises the PI3 compliant CCD is the data available to apps via the API. Information can be found on our CCD Resource Center. Support from MEDITECH's clinical applications will be offered via M Task "PI3 CCD Update Project" during your scheduled implementation.

CODE: Accept additional code for Patient Access via NMI Task "MD: Additional Code for PI3 Patient Access". Once this code is LIVE and the task is Complete, we will open a new NMI Task titled "Patient Access Staging" to begin work with you on staging the API. Note: Portal and MPM customers may have related tasks for these applications which will also need to be accepted.

AUTHENTICATION REALM: Work with MEDITECH to set up your Authentication Realm via NMI Task "Patient Access Staging". Authentication can be set up to utilize the MEDITECH Patient Portal credentials or it can be set up to utilize a 3rd party IdP.

NOTE: CMS specifications for Patient Electronic Access do not require testing with an app prior to your reporting period. The steps listed above will enable the API functionality for use with any app that you would like to onboard into your system in the future.

Question: Does my organization need to provide patients with a specific app to use for accessing their data via the API? The final rule (pg 520) states that the measure does not require that the eligible hospital or CAH provide an application for its patients’ use. The patient must have the ability to access their health information via an application of their own choice. Additional considerations on this topic can be found on HHS.gov. It will be up to your organization to develop security policies and procedures for screening and vetting apps that have been presented by patients requesting their health information.

Question: The performance based objective states “at least one unique patient” do I need to provide access for only one patient to get full credit? For the current EH, EP, EC Medicare & Dual Eligible programs, entering one patient in a measure numerator will only get you the minimum allotted points. The total available points for the Provide Patient Access measure is 40 points. Your points are based on your level of compliance, so full credit will not be awarded unless you are 100% compliant with the measure. See CMS FAQ (pg 3 under Provider to Patient Exchange Objective) for additional information.

Question: What if no patient requests to connect via an application during the 90 day reporting period? You do not receive a penalty for low buy-in with API usage among your patient population. What is important is that you have the ability to meet the functional standards for on-boarding an application. Having the necessary infrastructure in place leaves you in compliance with the measure and in a position to be prepared once there is greater demand within the industry.

Offering Access

Question: Do we need to build a new query to track access to the API or do we update our Patient Portal access query from Stage 2? If you are tracking offering patients access to a patient portal via the query workflow, then you are able to simply update your current query to reflect you also offered API access. The query may remain set to demo recall as at the time it is updated you should already have a process in place for offering access to both the portal and API. You do not have to create a new query or create an additional query to specifically track API access. If your organization would prefer to create a new query then you will need to update the SQL parameters to reflect the new query mnemonic and inactivate the old query. Please review the Stage 3 Best Practice for Provider to Patient Exchange for additional information on recommended workflows.

Question: What text does MEDITECH recommend we use on the discharge form? Sample text can be found in the Stage 3 Best Practice for Provider to Patient Exchange under MEDITECH's Recommended Workflows.

App Vetting & Onboarding

Question: What apps can be used for a patient to access their data via the API? MEDITECH does not have a list of apps that can be used for Patient Access. The Stage 3 requirement states that the patient can use any app of their choosing which meets the specifications of the EHR. MEDITECH's APIs are app agnostic, utilizing FHIR industry standards, and can be accessed via any app that is developed in accordance with FHIR. It is up to you as an organization to put a process in place to screen and vet possible apps patients present.

Question: We are using the MHealth app - does this app work with MEDITECH’s API? No. MEDITECH’s MHealth app allows patients to access our Portal via an app. It does not utilize API technology. To access data via an API, patients will use a 3rd party app that meets the specifications or MEDITECH’s EHR.

Question: How does my organization vet a patient selected application? It is up to your organization to put a process in place for vetting an application. Aside from being built according to the FHIR protocols, your organization may require additional security and network safeguards, evaluation of terms and conditions, etc in order to meet your internal standards for privacy and security. You should work with your IT/networking and legal staff to develop a process for reviewing patient selected applications according to the standards you have in place.

Question: What if a patient selected application does not meet our security standards? The final rule (beginning on pg 520) includes language confirming that reasonable action can be taken to protect the privacy and security of their patients’ information, including vetting application developers prior to allowing their applications to connect to the API functionality of the provider’s health IT. It should also be noted that denying an application does not remove a patient from the numerator as they were still offered access and could still access their information via portal and API should they select an application that will meet your security requirements.

Question: Once an app has been vetted and approved by my organization, what is the next step? After your organization has vetted an application, MEDITECH can be engaged via an NMI Task (use Task Category ON-BOARD) to help the app vendor test in Greenfield, before onboarding them directly to your test or production environment. MEDITECH Greenfield is a testing ground for apps that can integrate with MEDITECH. Developers have the ability to execute the APIs and test their applications against a real MEDITECH EHR. It also gives customers and application developers access to interactive documentation for the APIs published by MEDITECH.

Question: Is there a limit to how many apps we can connect to? There is no limit. You may connect to as many as are presented to you and approved by your vetting process.

Question: What are the requirements to onboard the Apple Health app for use with the MEDITECH EHR? MEDITECH Patient and Consumer Health Portal users can onboard the Apple Health app once RESTful API infrastructure has been deployed/validated and you are at the required release. The clinical build for the PI3 compliant CCD must be complete prior to testing. Click here for additional details on how to give your patients access to their Health Records on iPhone.

Question: What are the MEDITECH release requirements for onboarding the Apple Health app? MEDITECH’s EHR has completed Apple certification, which extends beyond the Patient Access API requirements set forth by CMS/ONC. The following software release, as well as an update to REST packages, will be required before onboarding the Apple Health app:

Expanse 2.1.10+ and 2.2.1+
6.16 pp25+
6.15 pp51+
6.08 Acute pp39+
6.08 MPM: pp41+
CS 5.67 TBD (*)
MG 5.67 TBD (*)

*CS and MG code is being tested by Early Adopters. Release requirements will be finalized pending this testing.

Your update to the above releases will also provide enhancements to functionality for other known patient health apps as well as the code needed for HIE measure 2: Receiving and Incorporating Health Information. Please contact your Account Manager/HCIS Coordinator to schedule your update.

Question: If a patient requests access to their health information using Apple’s Health app, but I cannot onboard this at my current release, am I still in compliance with the Promoting Interoperability Patient Access requirement? Yes. Use of the Apple Health app requires additional code that is outside the scope of what is required by CMS/ONC and beyond what is included in MEDITECH’s API specifications. MEDITECH is pleased to offer this functionality, but an update will be needed in order to obtain the code which has been Apple-certified.

Question: Can we use the Apple Health App at our Pediatric Clinics/Hospitals? While there is no technical limitation, the workflow is not desirable in a Pediatric setting. Apple’s current release supports primary access to health records vs proxy access. In simplest terms, this means review of a child's data on the parents’ phone. Within the Apple Health app, there is no indication of which data belongs to the child vs the parent/user. Since most pediatric data is viewed via proxy access, Apple recommends not onboarding Pediatric locations at this time. MEDITECH’s API offering will need no changes once Apple adds this functionality in the future. Please open an NMI task for the Interoperability API team if you'd like to discuss further.

Authentication & Identity Providers (IdP)

Question: What is an Identity Provider? An Identity Provider, or IdP, will sit between the patient facing app and MEDITECH’s APIs to broker authentication access to the API data. If this is confusing, it might be easier first to think of a non-EHR example. When using a mobile app, such as Uber or MyFitnessPal, you may sign up for these apps by using your Google or Facebook account. By doing so, you are granting Uber or MyFitnessPal access to Google or Facebook to authenticate using those credentials. By providing these permissions, your new app has access to your Google email or Facebook email, and assigns it to your user. Instead of saving a password with Uber or MyFitnessPal, you use Google or Facebook to sign in. Google or Facebook authenticates you confirming your identity, allowing you to use the app. The MEDITECH workflow is actually very similar. There is a published medical records workflow that outlines where external identities, such as your email address, can be associated to a medical record in HIM/MRI. An IdP would authenticate an email address stored on the medical record, confirm its authenticity, and signal to MEDITECH “it’s ok to open up the clinical data file to the app requesting it.”

Question: Do I need an IdP to manage patient access? Customers who use a non-MEDITECH Portal solution will need to set up a 3rd party IdP to manage external identities. For MEDITECH Portal users, there is functionality available which simplifies the authentication process and eliminates the need for a 3rd party IdP. Our API analysts will work with you to set up the appropriate authentication realm.

Question: What 3rd party IdPs can be used? MEDITECH has tested this functionality with Google Identity Solution, however any IdP that utilizes OpenID Connect or SAML 2.0 can be utilized. Before selecting an IdP for your organization, please work with MEDITECH so due diligence can be done to confirm its compatibility with RESTful API Infrastructure.

Question: Can we set up more than one IdP? Yes. While it is only required to set up one authentication method, the authentication realm can be set up to support login via multiple 3rd party IdPs and/or authentication via the MEDITECH Portal. When the patient accesses the app they will be presented with the options that your organization has set up for authentication. Once they have selected their authentication method and enter their credentials the app will allow them to proceed with the process of requesting their data.

Question: Is the Manage User Identities routine/workflow outlined in the Provider to Patient Exchange best practice required when authenticating via MEDITECH Portal credentials? No. As noted in the best practice, for organizations with a non-MEDITECH Portal, the patient must be added to the Manage User Identities for Patient Access routine in order to provide the patient with credentials to sign into the API application. When organizations use the MEDITECH Portal, the patient will use the same credentials for the API application as they use to access the Portal.

Question: For IdP authenticated patients, if they are a guarantor for others, do they each need to set up an account? The account and the way the app works is up to the app itself. Certain apps allow for proxy users to show up within the app, and others are user based and only allow for one user. When logging in with your credentials, an approval page is presented displaying the medical records you have access to. That would include your own medical record as well as any proxy access you have access to. The one you select is the one the app is granted access to. If an app has proxy access, you would be prompted to log in multiple times to have access to the multiple accounts.