# Third-party applications The following consumer health applications have been approved by 1upHealth and granted access to the 1upHealth Health Plan Patient Access API endpoints. The approved list of third-party applications includes apps for patients, providers, and payers. b.well b.well is a subscription-based service for employers, health plans, and health systems that enables the digital transformation of healthcare data. myFHR by CareEvolution You can use myFHR™ to get up to four years of your healthcare data as electronic health records from participating providers. Flexpa Flexpa is a digital health application that allows users to access, manage, and provision access to their medical records. mPowered Mpowered provides patients the ability to manage their healthcare data solutions and improves transparency, choice, access, and convenience. OneRecord OneRecord enables patients to access, aggregate, and consolidate their healthcare data, and end the frustrating search for healthcare information. ReimburseRPM ReimburseRPM (Remote Patient Monitoring) facilitates and streamlines the reimbursement process for healthcare providers that provide remote patient monitoring services. Wisely Health Wisely Health helps patients understand their medical bills, and manage their finances and healthcare. Primary Record Primary Record offers a unique software platform that helps individuals, families, and professional care teams organize, collaborate, and share health data, ensuring seamless communication and better-coordinated care. ## Third-party app vetting For our Patient Access customers, we review and vet third-party apps as a centrally managed service. 1upHealth has years of in-depth experience working with hundreds of healthcare third-party apps directly, and through our participation in the CARIN Alliance, Da Vinci, and other industry initiatives. The vetting criteria presented below is common across all of our customers, and we will review requests for additional criteria on a case-by-case basis. Apps that present active security threats, misuse, or abuse our APIs will have their access revoked and be blocked from API access until a thorough review is completed. We perform continuous monitoring of our API endpoints, have dashboards summarizing usage, and execute routine log reviews. 1upHealth only approves apps for production access that have a demonstrated ability to interact with and consume R4 FHIR APIs in our independent demo environment, and that complete the privacy and security attestation described below. Apps approved for production access are included in our member-facing Third-Party Applications gallery, and have their app’s credentials (client ID, client secret, OAuth redirect URL) synced and available to use in all of our payer production environments for Patient Access. This means the apps can use the same client ID across our payer production environments when traversing the various member authentication and OAuth 2.0 handshakes, which vary by specific customer and environment for Patient Access. These synced credentials allow apps read-only access to member data, one member at a time, when a member consents through our authorization flow for Patient Access. The synced app credentials can’t be used to write or update member data, or to access more than one member at a time. All published apps are reviewed on an annual basis. 1upHealth reserves the right to review apps on a more frequent basis in the event of material changes to, or any additional, regulations or requirements, or if 1upHealth has a good faith reason to believe additional reviews are required. ### Vetting process The [Info for third-party developers](/docs/patient-access/dev-implementation) and [Client credentials and OAuth 2.0](/docs/get-started/o-auth) pages contains more information for third-party app developers but the overall process is below: 1. Developer creates an account with 1up. 2. Developer creates an application with 1up. 3. Developer requests access to the demo environment and tests the Patient Access API connection. 4. Developer requests production access. 5. 1upHealth reviews the production access request and app developer information including the following: * app's public privacy policy * terms of service * website * country of origin * security information * evidence of demo environment testing 6. 1up approves the app and enables its connection to the production environment. 7. 1up continuously monitors the app's activity. ## CMS Guidance for Vetting Apps CMS indicates in the Interoperability and Patient Access Final Rule (CMS-9115-F) that: * All State and Federal laws take precedence over the data sharing requirements in the CMS regulations. * Covered entities are not responsible under the HIPAA Rules for the security of PHI after it has been received by a third-party application chosen by an individual (84 FR 7621 through 7622). * If an app has a written privacy policy and does not follow the policies as written, the FTC has authority to intervene. * The only reason a payer can deny an app access to their API is if they determine that app would pose a security threat to the PHI on their system (per HIPAA-related security protocols, see automated monitoring, and 45 CFR Part 164, sub-part c). * Health plans can request security and privacy attestations from the app (including provisions such as easy to find and readable policy, clear definition of secondary uses of data, and a clear policy on how to end a relationship between a patient and an app). * If the app doesn't attest, the payer can inform the patient and he or she can choose to change their mind. Ultimately it’s the patient’s decision to make. * It’s up to the health plan to enable members to make informed decisions. ## Privacy and security attestations The following attestations are required to be completed by all third-party application developers prior to being listed on the 1upHealth list of approved third-party applications. The attestations are renewed every other year. A record of responses is maintained by 1upHealth and, subject to any confidentiality obligations and restrictions, can be made available to customers upon request. If a third-party application provider is not willing to complete the attestation, or if based on such answers 1upHealth has a good faith reason to believe the third-party application could pose a privacy or security threat, the application won’t be added as an approved application to the 1up list of third-party applications. 1upHealth uses CMS guidance and any other generally accepted industry standards to make any determinations with regards to any third-party application’s approval. The attestation questions are below: 1. Do you maintain a HiTrust or SOC II Type II certification? * If Yes, the developer must attach a copy of the respective certification. Developers can answer N/A to all following questions if they answer Yes here. * If No, the developer must answer all following questions. 2. In the event of a data breach or security incident, do you notify your users of such breach or event? 3. Is all the data you maintain (including user login credentials) encrypted in transit and at rest in accordance with generally recognized encryption processes? 4. Do you perform regular security testing of your application and promptly remediate any discovered issues? 5. Do you secure your applications in accordance with [OWASP top 10 Web Application Security Risks](https://owasp.org/www-project-top-ten/)? * Can answer No if you answered Yes to question 4. 6. Do you ask users for their permission before sharing or selling their data with other entities? 7. After a user revokes your access to their data, do you delete the user’s historical data from your systems? 8. Is all data exclusively used, accessed, and transferred in the United States of America? 9. Does your application require the creation of strong passwords or multi-factor authentication? 10. Does your application meet the accessibility requirements outlined in the Americans with Disabilities Act? Qualification Unless otherwise stated, developers must answer Yes to all of the attestation questions to be included in our list of third-party apps. ## Remove an App from the Approved Apps List If an approved third-party app needs to be removed from the approved apps list, the app can either be removed on a global basis from all 1upHealth customers or it can be removed from only one or more specific customers. If 1upHealth determines that an app poses a security threat through our regular API monitoring and log reviews, or based on information provided by a customer (or member), we will revoke the app's access effective immediately until a further review is conducted. We monitor applications to identify if they are functioning erratically, making invalid requests for data (such as attempting to POST write resources), making too many API requests (we have configurable API rate limits), sending requests from non-US IP addresses, or have an unusual number of member authorizations (exact threshold to be determined based on initial member volume baseline for typical volume of authorizations). App API monitoring is performed by our standard tools including DataDog, and AuditEvent resources (capturing individual transactions and requests made to the FHIR server). If we determine that an application has one or more of these behaviors, we will temporarily block it from access to any of our API endpoints (by invalidating its client ID and secret) while we conduct a more thorough review. If we determine the app needs to be blocked, we complete the following steps. 1. Revoke the app’s client ID and client secret credentials from all environments. * This eliminates the ability for the app to receive an access token, refresh token, or authorization code for any member in the environment. 2. Invalidate any existing access tokens, refresh tokens, and authorization codes for all members who have previously authorized the particular third-party app, if necessary. 3. Send an email notification message to all impacted members who have previously authorized the third-party app, if necessary. 4. Send an email notification to customer contacts or alternative communication channel, as requested. 5. Remove the app from the member-facing approved third-party application list.