Solution Validation Overview


The Solution Validation Call is considered to be the last checkpoint necessary for athenahealth to ensure that the API solution is properly configured, functions as scoped, and does not compromise our systems and servers or the workflow of athenaNet users.

Preparation for Solution Validation

Client/vendors/partners and/or developer should prepare to:

  • Detail the workflow and API endpoints listed in the solution's scoping documents
  • Conduct a LIVE end-to-end demonstration within their dedicated tablespace using test/fake patients 

Common Solution Validation Issues

During the live demonstration, members of athenahealth's internal teams will be auditing the API endpoints to ensure that the solution: 

  • Matches the submitted scoping documents
  • Adheres to athenahealth's compliance regulations and ultimately does not compromise athenaNet

Should a solution utilize endpoints that were not previously scoped and approved, violate athenahealth's compliance regulations, or compromise athenaNet it will fail Solution Validation.


Solution Validation Steps

Throughout the build and eventual validation of a solution, the following issues should be proactively addressed:

User Authentication for Surfacing PHI

  • Concern: Surfacing PHI to incorrect patients, etc
  • Workflow/ API Solutions:
  • Registration and log-in with 2-factor authentication (text/email). This should be in accordance with the regulations established by the relevant state, etc.
  • For more information see here. 


Patient Matching Safety/Compliance

  • Concern: Duplicative patient entry or updates to incorrect patient charts 
  • Workflow/API Solution: To match patients, be sure to pass at least 4 input parameters
  • Required Parameters: First name, Last name, DOB, Fourth Parameter: email, phone number, Zip Code, SSN, etc

Relevant API Calls:

  • GET/POST/PUT /patients
  • GET /patients/search
  • GET /patients/enhancedbestmatch

Note: For more information see here


Security Compliance

  • Concern: Key/secret storage
  • Solution: Maintain your athena key/secret in a centralized place (a key server) for a higher level of security and restrict the amount of people who can access the key/server.  
  • Do not check the key/secret within any codebases
  • Never send bearer tokens, keys, and secrets over unencrypted email.


API Call Limitations

  • Concern: Placing too many API Calls outside of the limitations, compromises all of athenaNet
  • Solution: Adhere to pre-established limitations:
  • Preview Environments: (path: /preview1) 5 calls/second; 50000/day
  • Production Environments (path: /v1) 50/sec, 500000Utilize subscription endpoints. See here for more information.
  • Limit large data pulls. See here for more information.
  • Relevant API Calls:
  • All calls, especially: GET /patientsGET /booked/open/appointments


Updating Patient Chart Information

  • Concern:Only athenaNet practice users can update the chart. Patients cannot update their chart information.
  • Solution: Utilize and post Health History Forms or CCDAs as those initiate reconciliation task

Relevant API Calls:

Discrete data points within a patient’s chart like:

  • POST /chart/{patientid}/vitals /preview1/:practiceid/chart/:patientid/vitals
  • POST /chart/{patientid}/problems
  • /preview1/:practiceid/chart/:patientid/problems
  • POST /chart/encounter/{encounterid}/diagnoses
  • /preview1/:practiceid/chart/encounter/:encounterid/diagnoses

Lack of compliance and proactive integration of the aforementioned solutions, along with any other issues, will result in a failed Solution Validation, along with the reassessment of the solution.

Was this information helpful? Yes | No Thank you for your feedback! What went wrong? Incomplete or incorrect information | Irrelevant Content | Others

On this Page