3rd Party App Vetting
For customers where we are handing the developer registration process for Patient Access APIs, we will review and vet apps as described below

1upHealth Vetting

For our Patient Access customers we review and vet 3rd party apps as a centrally managed service. 1upHealth has years of in depth experience working with hundreds of healthcare 3rd party apps directly, and through its participation in the CARIN Alliance, Da Vinci, and other industry initiatives. The vetting criteria presented below is common across all 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 do routine log reviews.
At this time 1up will only approve apps for production access that have demonstrated their ability to interact with and consume R4 FHIR APIs in our independent sandbox environment, and who complete the privacy and security attestation described below.
Apps approved for production access will be added to our member-facing App Gallery, and will have their app’s credentials (client ID, client secret, redirect URI) 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 that vary by specific customer/environment for Patient Access. These synced credentials will allow apps read-only access to member data, one member at a time, when a member consents via our auth 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.

CMS Guidance for App Vetting

  • All State and Federal laws take precedence
  • Covered entities are not responsible under the HIPAA Rules for the security of PHI once 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 security threat to the PHI on their system (per HIPAA related security protocols, see automated monitoring on next slide, and 45 CFR Part 164, sub part c)
  • Payers can request security and privacy attestations from the app (including provisions like easy to find and readable policy, clear definition of secondary uses of data, clear policy on how to end a relationship between patient and app, etc.)
  • 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

3rd Party App Registration Process

1upHealth provides the following app registration and vetting process on behalf of our customers. This process is used uniformly across our customer base, and across apps requesting access to our CMS Patient Access Payer APIs.

App Vetting Information

App Information

Criteria
Required?
Type
App Name Displayed to User
Yes
Text
Company Name
Yes
Text
Support Email
Yes
Text
Contact Email for 1up Coordination
Yes
Text
Link to App
Yes
Hyperlink
Link to Company Website
Yes
Hyperlink
App Description
Yes
Text
CARIN Code of Conduct
No
File Upload
Square App Logo
Yes
File upload
Screenshots of App
No
File upload
FHIR Versions Supported (DSTU2, STU3, R4)
Yes
Multi-select
Selected Audience (Payers, Developers, Patient, Pharma, Provider)
Yes
Multi-select
App Categories (Clinical Trials, Care Coordination, Research, PopHealth Analytics, etc.)
Yes
Multi-select
Type of App (Payer R4 Claims Data, EHR Clinical Data Only)
Yes
Multi-select

Privacy and Security Attestations

The following questions are asked to be signed by app developers. A record of this attestation is maintained by 1up and is available to customers upon request, or some apps will only share this information directly during a meeting which 1up will facilitate as needed.
1up will ask 3rd party apps to re-attest on a biannual basis (every other year).
(1) Do you maintain a HiTrust and/or SOC II Type II certification?
If yes: please attach a copy of the respective report and reply N/A to all questions below.
If no: please provide an answer all questions listed below:
(2) Do you ask users for their permission before sharing or selling their data with other entities?
(3) After a user revokes your access to their data, do you delete the user’s historical data from your systems?
(4) In the event of a data breach and/or security incident, do you notify your users of such breach and/or event?
(5) Is all data exclusively used, accessed, and transferred in the United States of America?
(6) Is all of the data you maintain encrypted in transit and at rest in accordance with generally recognized encryption processes?
(7) Do you perform regular security testing of your application and promptly remediate any discovered issues?
(8) Does your application require the creation of strong passwords and/or multi-factor authentication?
(9) Do you store the users’ password/login credentials?
(10) Do you secure your applications in accordance with OWASP top 10 Web Application Security Risks?
(11) Does your application meet the accessibility requirements outlined in the Americans with Disabilities Act?

Approved Production Apps

Once apps have been approved for production access they are added to our centrally managed App Gallery maintained here:
Health Insurance - 1upHealth FHIR App Gallery

Process for De-listing an App

The process of listing apps is described above. In the event an app needs to be de-listed this can happen either on a global basis across all our customers OR can happen on a specific customer by customer basis depending on the situation.
If 1up determines 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 acting erratically, making invalid requests for data (e.g., attempting to POST write resources), making too many API requests (we have configurable API rate limits), requesting 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 is showing one or more of the above behaviors, we will temporarily block it from accessing any of our API endpoints (by invalidating its client ID and secret) while we conduct a more thorough review. If we determine the app does need to be blocked, here are the steps we will follow:
  • Revoke the app’s client ID and 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
  • Invalidate any existing access tokens, refresh tokens, and authorization codes for ALL members who have previously authorized the particular 3rd party app (if necessary)
  • Send an email notification message to all impacted members who have previously authorized the 3rd party app (if necessary)
  • Send an email notification to customer contacts (or alternative communication channel as desired)
  • Remove the app from the member-facing App Gallery
Last modified 13d ago