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

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 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).
  • Health plans 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 attestations are required to be completed by all third-party application developers prior to being listed on the 1upHealth application gallery. A record of responses will be maintained by 1upHealth, and as 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 will not be added as an approved application to the 1upHealth application gallery. 1upHealth will use CMS guidance and any other generally accepted industry standards in making any determinations with regards to any third party application’s approval.
1up will ask 3rd party apps to re-attest on a biannual basis (every other year).
Required Answers For Publishing to the 1upHealth App Gallery
(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) In the event of a data breach and/or security incident, do you notify your users of such breach and/or event? (Must answer "Yes")
(3) Is all the data you maintain (including user login credentials) encrypted in transit and at rest in accordance with generally recognized encryption processes? (Must answer "Yes")
(4) Do you perform regular security testing of your application and promptly remediate any discovered issues? (Must answer "Yes")
(5) Do you secure your applications in accordance with OWASP top 10 Web Application Security Risks? (Can be "No" as long as #4 is "Yes") Required Answers For "Trusted" Badge on the App Gallery (6) Do you ask users for their permission before sharing or selling their data with other entities? (Must answer "Yes")
(7) After a user revokes your access to their data, do you delete the user’s historical data from your systems? Is all data exclusively used, accessed, and transferred in the United States of America? (Must answer "Yes")
(8) Is all data exclusively used, accessed, and transferred in the United States of America? (Must answer "Yes")
(9) Does your application require the creation of strong passwords and/or multi-factor authentication? (Must answer "Yes") Required Answer for "ADA" Badge on the App Gallery
(10) Does your application meet the accessibility requirements outlined in the Americans with Disabilities Act? (Must answer "Yes")

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