1upHealth HIPAA Compliance


This page expresses the requirements for HIPAA compliance in application programming interfaces and web applications with access to personal health information and examines the adequacy of 1upHealth security practices. The requirements are presented in four sections:


HIPAA Requirements


§ 164.308 Administrative safeguards.


A covered entity or business associate must, in accordance with § 164.306:


  1. Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.

  2. Implementation specifications


    1. Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.
    2. We conduct quarterly analyses and testing of the security and accuracy of the web application and APIs. So far, we have conducted one risk analysis that described the 1upHealth platform and testing efforts.
    3. Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).
    4. Our team is continuously looking for ways to improve our security practices. If our risk analyses reveal potential vulnerabilities, 1upHealth's technology team makes the necessary changes to reduce risks. Our team members use GitHub, a software versioning and source code management system, to track bug reports and respond to issues.
    5. Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate.
    6. All of our team members receie HIPPA training, and they closely follow HIPAA Security and Privacy rules. If any of our members fail to comply, their administrative rights are taken away and administrative accounts are suspended until they re-review the relevant HIPAA training documents.
    7. Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
    8. We use Amazon Web Services (AWS) and Linode for data storage and hosting. AWS and Linode are both built to support HIPAA compliance, as described in their documentation, and include powerful auditing and logging capabilities. Additionally, every object in our database is timestamped with created and updated values that enable our team to track changes.

  3. Assigned security responsibility. Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the covered entity or business associate.
  4. Ricky Sahu is 1upHealth’s security official responsible for the development and implementation of the policies and procedures required by HIPAA.

  5. Workforce security. Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information.

  6. Implementation specifications


    1. Authorization and/or supervision (Addressable). Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
    2. Qualified members of the team go through am onboarding process involving HIPAA training. With successful completion of the training, members receive administrative access to the web application, granted (ii). All activity by administrative users is tracked in the same way that patient and provider user activity is tracked.
    3. Workforce clearance procedure (Addressable). Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
    4. Only 1upHealth administrators with patient or provider facing responsibilities have immediate access to patient health information. Administrative users are distinguished based on their role, so this type of delineation is simple. Technology team members who develop the web applications and APIs may be granted access to our administrative interface to ensure the application is functioning properly on production servers.
    5. Termination procedures (Addressable). Implement procedures for terminating access to electronic protected health information when the employment of, or other arrangement with, a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section.
    6. Our administrative members have the necessary power to grant or terminate access to patient health information through our administrative interface.
  7. Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.

  8. Implementation specifications


    1. Isolating health care clearinghouse functions (Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
    2. Not applicable. 1upHealth is not a clearinghouse.
    3. Access authorization (Addressable). Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
    4. Qualified members are given accounts only after completing HIPAA training, and they access patient health information through our administrative interface.
    5. Access establishment and modification (Addressable). Implement policies and procedures that, based upon the covered entity's or the business associate's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process.
    6. This is implemented through the paragraph above
  9. Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).

  10. Implementation specifications


    1. Security reminders (Addressable). Periodic security updates.
    2. We have a recurring calendar event for seasonal risk analyses and security update. Additionally, we constantly evaluate our security practices.
    3. Protection from malicious software (Addressable). Procedures for guarding against, detecting, and reporting malicious software.
    4. AWS and Linode implement the necessary precautions to detect malicious software. Our team members protect their workstations with operating systen and software security updates.
    5. Log-in monitoring (Addressable). Procedures for monitoring log-in attempts and reporting discrepancies.
    6. Any user’s electronic footprint regarding activity touching 1upHealth patient data is recorded in logs.
    7. Password management (Addressable). Procedures for creating, changing, and safeguarding passwords.
    8. All passwords are hashed, salted, and encrypted. Any user (patient, provider, or admin) has the ability to change or reset his or her password, but can never see another user's password.
  11. Security incident procedures. Implement policies and procedures to address security incidents.

  12. Implementation specification


    Response and reporting (Required). Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes
    All security incidents are identified and reported to our security officer. The security officer takes the necessary precautions to mitigate the incident and notifies the parties involved in the incident. These incidents are documented internally and available upon request.

  13. Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.

  14. Implementation specifications


    1. Data backup plan (Required). Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
    2. Data backup is accomplished through AWS. 1upHealth pushes backs up our database periodically and AWS allows us to retrieve copies of documents stored in its servers.
    3. Disaster recovery plan (Required). Establish (and implement as needed) procedures to restore any loss of data.
    4. We use AWS Simple Storage Service (S3) for file storage. Scheduled processes automatic backup production data into S3. These services store backups for a “user-defined period”
    5. Emergency mode operation plan (Required). Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.
    6. In case of an emergency (i.e. data breach or data loss), AWS and Linode provide the necessary tools to retrieve information, block incoming traffic to our servers, and continue the use of 1upHealth web applications and APIs in a controlled manner.
    7. Testing and revision procedures (Addressable). Implement procedures for periodic testing and revision of contingency plans.
    8. We do not have specific testing and revision procedures to test emergency scenarios. However, our codebase includes over hundreds of unit and integration tests that are run before every deployment to ensure application health and security.
    9. Applications and data criticality analysis (Addressable). Assess the relative criticality of specific applications and data in support of other contingency plan components.
    10. The security of files stored in S3 and unique user identifiers stored in our production databases are of utmost importance. AWS (S3 & EC2) and Linode (Server) services we utilize to store the sensitive data provide the necessary tools to prevent data loss and store data securely.
  15. Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart.
  16. Our team evaluates our security practices on a regular basis. We analyzed potential risks and vulnerabilities of our services continuously and have started producing quarterly risk analysis reports. In the case that a report reveals a vulnerability, necessary precautions will be taken to reduce exposure to the given risk.

Business associate contracts and other arrangements.


  1. Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
  2. A business associate may permit a business associate that is a subcontractor to create, receive, maintain, or transmit electronic protected health information on its behalf only if the business associate obtains satisfactory assurances, in accordance with § 164.314(a), that the subcontractor will appropriately safeguard the information.

  3. Implementation specifications


    Written contract or other arrangement (Required). Document the satisfactory assurances required by paragraph (b)(1) or (b)(2) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a)
    As we partner with hospitals or other health institutions to store and manage patient health information we have to have an approved BAA with them.
[ 68 FR 8376, Feb. 20, 2003, as amended at 78 FR 5694, Jan. 25, 2013]




§ 164.310 Physical safeguards.


A covered entity or business associate must, in accordance with § 164.306:


  1. Facility access controls. Implement policies and procedures to limit physical access to its electronic information systems and the facility or facilities in which they are housed, while ensuring that properly authorized access is allowed.

  2. Implementation specifications


    1. Contingency operations (Addressable). Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.
    2. Not applicable. We do not have any facilities.
    3. Facility security plan (Addressable). Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.
    4. Not applicable. We do not have any facilities.
    5. Access control and validation procedures (Addressable). Implement procedures to control and validate a person's access to facilities based on their role or function, including visitor control, and control of access to software programs for testing and revision.
    6. Not applicable. We do not have any facilities.
    7. Maintenance records (Addressable). Implement policies and procedures to document repairs and modifications to the physical components of a facility which are related to security (for example, hardware, walls, doors, and locks).
    8. We do not have any facilities. All our workstations are password-protected and receive software and security updates.
  3. Workstation use. Implement policies and procedures that specify the proper functions to be performed, the manner in which those functions are to be performed, and the physical attributes of the surroundings of a specific workstation or class of workstation that can access electronic protected health information.
  4. All our workstations are password-protected and receive software and security updates.

  5. Workstation security. Implement physical safeguards for all workstations that access electronic protected health information, to restrict access to authorized users.
  6. The hardware used for development is secured by passwords and encryption.

  7. Device and media controls. Implement policies and procedures that govern the receipt and removal of hardware and electronic media that contain electronic protected health information into and out of a facility, and the movement of these items within the facility.

  8. Implementation specifications


    1. Disposal (Required). Implement policies and procedures to address the final disposition of electronic protected health information, and/or the hardware or electronic media on which it is stored.
    2. Our team does not store ePHI on electronic media. All our workflows use our web services.
    3. Media re-use (Required). Implement procedures for removal of electronic protected health information from electronic media before the media are made available for re-use.
    4. Our team does not store ePHI on electronic media. All our workflows use our web services.
    5. Accountability (Addressable). Maintain a record of the movements of hardware and electronic media and any person responsible therefore.
    6. AWS and Linode provide logging capabilities to track the electronic footprints of all our users (patient, provider and admin).
    7. Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.
    8. All health information is stored online in AWS and Linode and can be retrieved without movement of equipment.
[ 68 FR 8376, Feb. 20, 2003, as amended at 78 FR 5694, Jan. 25, 2013]




§ 164.312 Technical safeguards.


A covered entity or business associate must, in accordance with § 164.306:


  1. Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).

  2. Implementation specifications:


    1. Unique user identification (Required). Assign a unique name and/or number for identifying and tracking user identity.
    2. All our users (patient, provider and admin), requests, access controls and documents have unique user identifiers that are randomly generated and not predictable.
    3. Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
    4. In case of an emergency, AWS and Linode provide the necessary tools to block incoming traffic to our servers and handle the emergency in a controlled manner. We also always have secure command-line access to AWS servers, and periodically conduct PORT audits.
    5. Automatic logoff (Addressable). Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
    6. 1upHealth APIs provide an session expiration timeout which deactivates tokens after some time.
    7. Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
    8. We use 256-bit encryption and SSL to encrypt/decrypt patient health information during transit and at rest.
  3. Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
  4. AWS and Linode provide logging capabilities to track the electronic footprints of all our users (patient, provider and admin).

  5. Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

  6. Implementation specification:


    1. Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
    2. Unauthorized users cannot delete or modify data. Only the owners of the patient health information or those that they have shared access with can modify existing data. These users can be applications, providers, or patients. All modifications and deletions are tracked in logs and via timestamps on database objects.

  7. Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
  8. We verify the identities of our users via email or SMS. After this initial verification, patients and providers use the system via username/password combinations tied to their email or phone number.

  9. Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

  10. Implementation specifications:


    1. Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
    2. We use 256-bit encryption and SSL to encrypt/decrypt patient health information during transit and at rest. The data is transferred securely and is not prone to modification in transit.
    3. Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
    4. We use 256-bit encryption during rest and transit.
[ 68 FR 8376, Feb. 20, 2003, as amended at 78 FR 5694, Jan. 25, 2013]




§ 164.316 Policies and procedures and documentation requirements.


A covered entity or business associate must, in accordance with § 164.306:


  1. Policies and procedures. Implement reasonable and appropriate policies and procedures to comply with the standards, implementation specifications, or other requirements of this subpart, taking into account those factors specified in § 164.306(b)(2)(i), (ii), (iii), and (iv). This standard is not to be construed to permit or excuse an action that violates any other standard, implementation specification, or other requirements of this subpart. A covered entity or business associate may change its policies and procedures at any time, provided that the changes are documented and are implemented in accordance with this subpart.
  2. All our security practices and privacy notices are online and documented here.

  3. Documentation. Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.

  4. Implementation specifications:


    1. Time limit (Required). Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.
    2. Documents in 1upHealth will be stored for at least 6 years.
    3. Availability (Required). Make documentation available to those persons responsible for implementing the procedures to which the documentation pertains.
    4. This and other security-related documents are available to all members of our team. Our users can also read our privacy and security practices on our user portals.
    5. Updates (Required). Review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.
    6. Our team follows HIPAA requirements closely to ensure that 1upHealth security practices remain up-to-date and relevant.
[ 68 FR 8376, Feb. 20, 2003, as amended at 78 FR 5695, Jan. 25, 2013]