1. Introduction

LAST UPDATED: JULY 16, 2018

BroadStreet Health, LLC (“BroadStreet”) is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its Customers. BroadStreet provides secure and compliant cloud-based software as a service (SaaS) to its Customers to track and analyze community health. Thus, BroadStreet hosted software falls into the broad category of SaaS. As providers of compliant, hosted SaaS used by health care and community organizations, BroadStreet strives to maintain compliance with the Health Insurance Portability and Accountability Act (HIPAA) by proactively addressing information security, mitigating risk for its Customers, and assuring known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by BroadStreet to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for BroadStreet Customers are enacted, transparent and continually updated.

This also means we make our HIPAA compliance policies available online for easy viewing and review, and version tracking of updates (see §1.4). This also includes BroadStreet HIPAA training materials. Thus, at BroadStreet we are continuously reviewing our approaches to protecting PHI, making sure any employees working with PHI are carefully vetted and trained, and doing this with fully transparent and verifiable methods.

When it comes to ePHI, the essential sections of the HIPAA Privacy Rule located at 45 CFR Part 160 and Subparts A and E of Part 164 is Section 164 Security and Privacy and the HITECH Act and Omnibus Rule: IT Security Provisions. This also includes the HITRUST Common Security Framework (CSF). With this in mind, below is a high-level overview of BroadStreet’s major architecture, guiding principles, and how these maximize BroadStreet’s security posture. A mapping of HIPAA safeguards and requirements to BroadSreet policies is available in §24.

1.1 Software as a Service (SaaS)

SaaS Customers utilize hosted software and infrastructure from BroadStreet to track community health through automatically generated reports, embedded dashboards on their websites, and aggregated statistics. The software application is deployed into compliant servers run on systems secured and managed by BroadStreet. BroadStreet makes every effort to reduce the risk of unauthorized disclosure, access, and/or breach of SaaS data through network (firewalls, dedicated IP spaces, etc) and server settings (encryption at rest and in transit, OSSEC throughout the application, etc.).

1.2 Compliance Inheritance

BroadStreet provides HIPAA compliant hosted software for its Customers. BroadStreet’s company policies, procedures, and technologies follow HIPAA best practices and are hosted at Amazon Web Services (AWS) that itself supports BroadStreet’s application in a manner consistent with HIPAA, HITECH, and HITRUST CSF.

BroadStreet signs business associate agreements (BAAs) [see §23.] with its Customers. These BAAs outline BroadStreet obligations and Customer obligations, as well as liability in the case of a breach.

Certain aspects of compliance cannot be inherited (see §2.). Because of this, BroadStreet Customers, in order to achieve full compliance or HITRUST Certification, must implement certain organizational policies. These policies and aspects of compliance fall outside of the services and obligations of BroadStreet.

1.3 BroadStreet Organizational Concepts

As mentioned, the physical infrastructure environment is hosted at AWS. The network components and supporting network infrastructure are contained within the AWS infrastructures and managed by AWS. BroadStreet does not have physical access into the network components. The BroadStreet environment consists of Cisco firewalls; Apache web servers; Python application servers; PostgreSQL database servers; OSSEC IDS services; Docker containers; and developer tool servers running on Linux Ubuntu.

Within the BroadStreet Platform on AWS all data transmission is encrypted and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers – those hosting Docker containers, databases, APIs, log servers, etc. BroadStreet assumes all data may contain ePHI and provides appropriate protections based on that assumption.

In the case of SaaS Customers, it is the responsibility of the Customer to restrict, secure, and assure the privacy of all ePHI data accessed through the BroadStreet API or downloaded, as this is not under the control or purview of BroadStreet.

Additionally, IPtables is used on each server for logical segmentation. IPtables is configured to restrict access to only justified ports and protocols. BroadStreet has implemented strict logical access controls so that only authorized personnel are given access to the internal management servers.

The Apache web server and application servers are externally facing and accessible via the Internet. The database servers, where the ePHI resides, are located on the internal BroadStreet network and can only be accessed over a secure connection. Access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business-justified reason. Remote access to internal servers is otherwise not accessible except through application servers.

All software modules and operating systems are tested end-to-end for usability, security, and impact prior to deployment to production.

1.4 Version Control

Refer to the GitLab repository at GitLab.com BroadStreet Policies for the full version history of these policies. Please send e-mail to hello@broadstreet.io to request access.

Thank You Datica!

These HIPAA compliance materials come mostly from Datica Health, Inc, some of which have been modified by BroadStreet. We would like to thank Datica for being so generous in opening up their HIPPAA compliance and training materials and putting health consumers and the community first.

2. HIPAA Inheritance

2.1 HIPAA Inheritance for SaaS Customers

When BroadStreet Customers use BroadStreet SaaS infrastructure to store and process their ePHI, they inherit BroadStreet’s compliance for many of the HIPAA provisions. The following tables outline which HIPAA provisions Customers inherit from BroadStreet’s controls. HIPAA provisions inherited by BroadStreet only apply for data stored and/or processed on BroadStreets SaaS. Any data processed and stored by a BroadStreet Customer locally on their computers, servers or in their own cloud server is not inherited by BroadStreet.

Administrative Controls HIPAA Rule	BroadStreet Control	Inherited
Security Management Process – 164.308(a)(1)(i)	Risk Management Policy	Yes
Assigned Security Responsibility – 164.308(a)(2)	Roles Policy	Partially
Workforce Security – 164.308(a)(3)(i)	Employee Policies	Partially
Information Access Management – 164.308(a)(4)(i)	System Access Policy	Yes
Security Awareness and Training – 164.308(a)(5)(i)	Employee Policy	No
Security Incident Procedures – 164.308(a)(6)(i)	IDS Policy	Yes
Contingency Plan – 164.308(a)(7)(i)	Disaster Recovery Policy	Yes
Evaluation – 164.308(a)(8)	Auditing Policy	Yes

Physical Safeguards HIPAA Rule	BroadStreet Control	Inherited
Facility Access Controls – 164.310(a)(1)	Facility and Disaster Recovery Policies	Yes
Workstation Use – 164.310(b)	System Access, Approved Tools, and Employee Policies	Partially
Workstation Security – 164.310(‘c’)	System Access, Approved Tools, and Employee Policies	Partially
Device and Media Controls – 164.310(d)(1)	Disposable Media and Data Management Policies	Yes

Technical Safeguards HIPAA Rule	BroadStreet Control	Inherited
Access Control – 164.312(a)(1)	System Access Policy	Partially
Audit Controls – 164.312(b)	Auditing Policy	Yes (optional)
Integrity – 164.312(‘c’)(1)	System Access, Auditing, and IDS Policies	Yes (optional)
Person or Entity Authentication – 164.312(d)	System Access Policy	Yes
Transmission Security – 164.312(e)(1)	System Access and Data Management Policy	Yes

Organizational Requirements HIPAA Rule	BroadStreet Control	Inherited
Business Associate Contracts or Other Arrangements – 164.314(a)(1)(i)	Business Associate Agreements and 3rd Parties Policies	Partially

Policies and Procedures and Documentation Requirements HIPAA Rule	BroadStreet Control	Inherited
Policies and Procedures – 164.316(a)	Policy Management Policy	Partially
Documentation – 164.316(b)(1)(i)	Policy Management Policy	Partially

HITECH Act – Security Provisions HIPAA Rule	BroadStreet Control	Inherited
Notification in the Case of Breach – 13402(a) and (b)	Breach Policy	Partially
Timelines of Notification – 13402(d)(1)	Breach Policy	Partially
Content of Notification – 13402(f)(1)	Breach Policy	Partially

3. Policy Management Policy

BroadStreet implements policies and procedures to maintain compliance and integrity of data. The Security Officer and Privacy Officer are responsible for maintaining policies and procedures and assuring all BroadStreet workforce members, business associates, customers, and partners are adherent to all applicable policies. Previous versions of policies are retained to assure ease of finding policies at specific historic dates in time. Refer to the GitLab repository at GitLab.com BroadStreet Policies for the full version history of these policies. Please send e-mail to hello@broadstreet.io to request access.

3.1 Applicable Standards

3.1.1 Applicable Standards from the HITRUST Common Security Framework

• 12.c – Developing and Implementing Continuity Plans Including Information Security

3.1.2 Applicable Standards from the HIPAA Security Rule

• 164.316(a) – Policies and Procedures
• 164.316(b)(1)(i) – Documentation
• 164.316(b)(2)(i) – Time Limit
• 164.316(b)(2)(ii) – Availability
• 164.316(b)(2)(iii) – Updates

3.2 Maintenance of Policies

1. All policies are stored and updated to maintain BroadStreet compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control are done similarly to source code control.
2. Policy update requests can be made by any workforce member at any time. Furthermore, all policies are reviewed annually by both the Security Officer and the Privacy Officer to assure they are accurate and up-to-date.
3. BroadStreet employees may request changes to policies using the following process:
   1. The BroadStreet employee initiates a policy change request by creating an Issue with a GitLab pull request from a separate branch or repository containing the desired changes.
   2. The Security Officer or the Privacy Officer is assigned to review the policy change request.
   3. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
   4. If the review is approved, the Security Officer or Privacy Officer then mark the Issue as Done, adding any pertinent notes required.
   5. If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel.
4. All HIPAA policies are made accessible to all BroadStreet workforce members. The current master policies are published at https://broadstreet.io/hipaa/.
   • Changes are automatically communicated to all BroadStreet team members through integrations between GitLab and Slack that log all GitLab policy changes to a dedicated BroadStreet Slack Channel.
   • The Security Officer also communicates policy changes to all employees via email. These emails include a high-level description of the policy change using terminology appropriate for the target audience.
5. All policies, and associated documentation, are retained for 6 years from the date of its creation or the date when it last was in effect, whichever is later
   1. Version history of all BroadStreet policies is done via GitLab.
   2. Backup storage of all policies is done with Dropbox.
6. The policies are reviewed annually, or after significant changes occur to BroadStreet’s organizational environment. Issues that come up as part of this process are reviewed by BroadStreet management to assure all risks and potential gaps are mitigated and/or fully addressed. The process for reviewing polices is outlined below:
   1. The Security Officer initiates the policy review by creating an Issue in GitLab.
   2. The Security Officer or the Privacy Officer is assigned to review the current BroadStreet policies (broadstreet.io/hipaa/).
   3. If changes are made, the above process is used. All changes are documented in the Issue.
   4. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
   5. If the review is approved, the Security Officer or Privacy Officer then marks the Issue as Done, adding any pertinent notes required.
   6. Policy review is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.

Additional documentation related to maintenance of policies is outlined in §5.3.1.

4. Risk Management Policy

This policy establishes the scope, objectives, and procedures of BroadStreet’s information security risk management process. The risk management process is intended to support and protect the organization and its ability to fulfill its mission.

4.1 Applicable Standards

4.1.1 Applicable Standards from the HITRUST Common Security Framework

• 03.a – Risk Management Program Development
• 03.b – Performing Risk Assessments
• 03.c – Risk Mitigation

4.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(1)(ii)(A) – HIPAA Security Rule Risk Analysis
• 164.308(a)(1)(ii)(B) – HIPAA Security Rule Risk Management
• 164.308(a)(8) – HIPAA Security Rule Evaluation

4.2 Risk Management Policies

1. It is the policy of BroadStreet to conduct thorough and timely risk assessments of the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) (and other confidential and proprietary electronic information) it stores, transmits, and/or processes for its Customers and to develop strategies to efficiently and effectively mitigate the risks identified in the assessment process as an integral part of the BroadStreet’s information security program.
2. Risk analysis and risk management are recognized as important components of BroadStreet’s corporate compliance program and information security program in accordance with the Risk Analysis and Risk Management implementation specifications within the Security Management standard and the evaluation standards set forth in the HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A), 164.308(a)(1)(ii)(B), 164.308(a)(1)(i), and 164.308(a)(8).
   1. Risk assessments are done throughout product life cycles:
   2. Before the integration of new system technologies and before changes are made to BroadStreet physical safeguards; and
      • These changes do not include routine updates to existing systems, deployments of new systems created based on previously configured systems, deployments of new Customers, or new code developed for operations and management of the BroadStreet Platform.
   3. While making changes to BroadStreet physical equipment and facilities that introduce new, untested configurations.
   4. BroadStreet performs periodic technical and non-technical assessments of the security rule requirements as well as in response to environmental or operational changes affecting the security of ePHI.
3. BroadStreet implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to:
   1. Ensure the confidentiality, integrity, and availability of all ePHI BroadStreet receives, maintains, processes, and/or transmits for its Customers;
   2. Protect against any reasonably anticipated threats or hazards to the security or integrity of Customer ePHI;
   3. Protect against any reasonably anticipated uses or disclosures of Customer ePHI that are not permitted or required; and
   4. Ensure compliance by all workforce members.
4. Any risk remaining (residual) after other risk controls have been applied, requires sign off by the senior management and BroadStreet’s Security Officer.
5. All BroadStreet workforce members are expected to fully cooperate with all persons charged with doing risk management work, including contractors and audit personnel. Any workforce member that violates this policy will be subject to disciplinary action based on the severity of the violation, as outlined in the BroadStreet Roles Policy.
6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of BroadStreet’s Security Officer (or other designated employee), and the identified Risk Management Team.
7. All risk management efforts, including decisions made on what controls to put in place as well as those to not put into place, are documented and the documentation is maintained for six years.

4.3 Risk Management Procedures

4.3.1 Risk Analysis & Assessment

The intent of completing a risk assessment is to determine potential threats and vulnerabilities and the likelihood and impact should they occur. The output of this process helps to identify appropriate controls for reducing or eliminating risk. Thus BroadStreet conducts an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the covered entity or business associate.

4.3.2 Risk Mitigation

Risk mitigation involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the Risk Assessment process to ensure the confidentiality, integrity and availability of BroadStreet Platform ePHI. Determination of appropriate controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission.

4.3.3 Risk Management Schedule

The two principle components of the risk management process – risk assessment and risk mitigation – will be carried out according to the following schedule to ensure the continued adequacy and continuous improvement of BroadStreet’s information security program:

• Scheduled Basis – an overall risk assessment of BroadStreet’s information system infrastructure will be conducted annually. The assessment process should be completed in a timely fashion so that risk mitigation strategies can be determined and included in the corporate budgeting process.
• Throughout a System’s Development Life Cycle – from the time that a need for a new, untested information system configuration and/or application is identified through the time it is disposed of, ongoing assessments of the potential threats to a system and its vulnerabilities should be undertaken as a part of the maintenance of the system.
• As Needed – the Security Officer (or other designated employee) or Risk Management Team may call for a full or partial risk assessment in response to changes in business strategies, information technology, information sensitivity, threats, legal liabilities, or other significant factors that affect BroadStreet’s Platform.

4.4 Process Documentation

Maintain documentation of all risk assessment, risk management, and risk mitigation efforts for a minimum of six years.

5. Roles Policy

BroadStreet has a Security Officer [164.308(a)(2)] and Privacy Officer [164.308(a)(2)] appointed to assist in maintaining and enforcing safeguards towards compliance. The responsibilities associated with these roles are outlined below.

5.1 Applicable Standards

5.1.1 Applicable Standards from the HITRUST Common Security Framework

• 02.f – Disciplinary Process
• 06.d – Data Protection and Privacy of Covered Information
• 06.f – Prevention of Misuse of Information Assets
• 06.g – Compliance with Security Policies and Standards

5.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(2) – Assigned Security Responsibility
• 164.308(a)(5)(i) – Security Awareness and Training

5.2 Privacy Officer

The Privacy Officer is responsible for assisting with compliance and security training for workforce members, assuring organization remains in compliance with evolving compliance rules, and helping the Security Officer in his responsibilities. Current BroadStreet training is hosted at broadstreet.io/hipaa/hipaa-training/.

1. Provides annual training to all workforce members of established policies and procedures as necessary and appropriate to carry out their job functions, and documents the training provided.
2. Assists in the administration and oversight of business associate agreements.
3. Manage relationships with customers and partners as those relationships affect security and compliance of ePHI.
4. Assist Security Officer as needed.

The current BroadStreet Privacy Officers are Tom Schmitt (tom@broadstreet.io) and Tracy Flood (tracy@broadstreet.io).

5.2.1 Workforce Training Responsibilities

1. The Privacy Officer facilitates the training of all workforce members as follows:
   1. New workforce members within their first month of employment;
   2. Existing workforce members annually;
   3. Existing workforce members whose functions are affected by a material change in the policies and procedures, within a month after the material change becomes effective;
   4. Existing workforce members as needed due to changes in security and risk posture of BroadStreet.
2. The Security Officer or designee maintains documentation of the training session materials and attendees for a minimum of six years.
3. The training session focuses on, but is not limited to, the following subjects defined in BroadStreet’s security policies and procedures:
   1. HIPAA Privacy, Security, and Breach notification rules;
   2. HITRUST Common Security Framework;
   3. NIST Security Rules;
   4. Risk Management procedures and documentation;
   5. Auditing. BroadStreet may monitor access and activities of all users;
   6. Workstations may only be used to perform assigned job responsibilities;
   7. Users may not download software onto BroadStreet’s workstations and/or systems without prior approval from the Security Officer;
   8. Users are required to report malicious software to the Security Officer immediately;
   9. Users are required to report unauthorized attempts, uses of, and theft of BroadStreet’s systems and/or workstations;
   10. Users are required to report unauthorized access to facilities
   11. Users are required to report noted log-in discrepancies (i.e. application states users last log-in was on a date user was on vacation);
   12. Users may not alter ePHI maintained in a database, unless authorized to do so by a BroadStreet Customer;
   13. Users are required to understand their role in BroadStreet’s contingency plan;
   14. Users may not share their user names nor passwords with anyone;
   15. Requirements for users to create and change passwords;
   16. Users must set all applications that contain or transmit ePHI to automatically log off after 15 minutes of inactivity;
   17. Supervisors are required to report terminations of workforce members and other outside users;
   18. Supervisors are required to report a change in a users title, role, department, and/or location;
   19. Procedures to backup ePHI;
   20. Procedures to move and record movement of hardware and electronic media containing ePHI;
   21. Procedures to dispose of discs, CDs, hard drives, and other media containing ePHI;
   22. Procedures to re-use electronic media containing ePHI;
   23. SSH key and sensitive document encryption procedures.

5.3 Security Officer

The Security Officer is responsible for facilitating the training and supervision of all workforce members [164.308(a)(3)(ii)(A) and 164.308(a)(5)(ii)(A)], investigation and sanctioning of any workforce member that is in violation of BroadStreet security policies and non-compliance with the security regulations [164.308(a)(1)(ii)(c)], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].

The current BroadStreet Security Officer is James Walters (james@broadstreet.io).

5.3.1 Organizational Responsibilities

The Security Officer, in collaboration with the Privacy Officer, is responsible for facilitating the development, testing, implementation, training, and oversight of all activities pertaining to BroadStreet’s efforts to be compliant with the HIPAA Security Regulations, HITRUST CSF, and any other security and compliance frameworks. The intent of the Security Officer Responsibilities is to maintain the confidentiality, integrity, and availability of ePHI.

These organizational responsibilities include, but are not limited to the following:

1. Oversees and enforces all activities necessary to maintain compliance and verifies the activities are in alignment with the requirements.
2. Helps to establish and maintain written policies and procedures to comply with the Security rule and maintains them for six years from the date of creation or date it was last in effect, whichever is later.
3. Reviews and updates policies and procedures as necessary and appropriate to maintain compliance and maintains changes made for six years from the date of creation or date it was last in effect, whichever is later.
4. Facilitates audits to validate compliance efforts throughout the organization.
5. Documents all activities and assessments completed to maintain compliance and maintains documentation for six years from the date of creation or date it was last in effect, whichever is later.
6. Provides copies of the policies and procedures to management, customers, and partners, and has them available to review by all other workforce members to which they apply.
7. Annually, and as necessary, reviews and updates documentation to respond to environmental or operational changes affecting the security and risk posture of ePHI stored, transmitted, or processed within BroadStreet infrastructure.
8. Develops and provides periodic security updates and reminder communications for all workforce members.
9. Implements procedures for the authorization and/or supervision of workforce members who work with ePHI or in locations where it may be accessed.
10. Maintains a program promoting workforce members to report non-compliance with policies and procedures.
    • Promptly, properly, and consistently investigates and addresses reported violations and takes steps to prevent recurrence.
    • Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of BroadStreet.
    • Mitigates, to the extent practicable, any harmful effect known to BroadStreet of a use or disclosure of ePHI in violation of BroadStreet’s policies and procedures, even if effect is the result of actions of BroadStreet business associates, customers, and/or partners.
11. Reports security efforts and incidents to administration immediately upon discovery. Responsibilities in the case of a known ePHI breach are documented in §12 the BroadStreet Breach Policy.
12. The Security Officer facilitates the communication of security updates and reminders to all workforce members to which it pertains. Examples of security updates and reminders include, but are not limited to:
    • Latest malicious software or virus alerts;
    • BroadStreet’s requirement to report unauthorized attempts to access ePHI;
    • Changes in creating or changing passwords;
    • Additional security-focused training is provided to all workforce members by the Security Officer. This training includes, but is not limited to:
    • Data backup plans;
    • System auditing procedures;
    • Redundancy procedures;
    • Contingency plans;
    • Virus protection;
    • Patch management;
    • Media Disposal and/or Re-use;
    • Documentation requirements.

5.3.2 Supervision of Workforce Responsibilities

Although the Security Officer is responsible for implementing and overseeing all activities related to maintaining compliance, it is the responsibility of all workforce members (i.e. team leaders, supervisors, managers, directors, co-workers, etc.) to supervise all workforce members and any other user of BroadStreet’s systems, applications, servers, workstations, etc. that contain ePHI.

1. Monitor workstations and applications for unauthorized use, tampering, and theft and report non-compliance according to the Security Incident Response policy.
2. Assist the Security and Privacy Officers to ensure appropriate role-based access is provided to all users.
3. Take all reasonable steps to hire, retain, and promote workforce members and provide access to users who comply with the Security regulation and BroadStreet’s security policies and procedures.

5.3.3 Sanctions of Workforce Responsibilities

All workforce members report non-compliance of BroadStreet’s policies and procedures to the Security Officer or other individual as assigned by the Security Officer. Individuals that report violations in good faith may not be subjected to intimidation, threats, coercion, discrimination against, or any other retaliatory action as a consequence.

1. The Security Officer promptly facilitates a thorough investigation of all reported violations of BroadStreet’s security policies and procedures. The Security Officer may request the assistance from others.
   • Complete an audit trail/log to identify and verify the violation and sequence of events.
   • Interview any individual that may be aware of or involved in the incident.
   • All individuals are required to cooperate with the investigation process and provide factual information to those conducting the investigation.
   • Provide individuals suspected of non-compliance of the Security rule and/or BroadStreet’s policies and procedures the opportunity to explain their actions.
   • The investigator thoroughly documents the investigation as the investigation occurs. This documentation must include a list of all employees involved in the violation.
2. Violation of any security policy or procedure by workforce members may result in corrective disciplinary action, up to and including termination of employment. Violation of this policy and procedures by others, including business associates, customers, and partners may result in termination of the relationship and/or associated privileges. Violation may also result in civil and criminal penalties as determined by federal and state laws and regulations.
   • A violation resulting in a breach of confidentiality (i.e. release of PHI to an unauthorized individual), change of the integrity of any ePHI, or inability to access any ePHI by other users, requires immediate termination of the workforce member from BroadStreet.
3. The Security Officer facilitates taking appropriate steps to prevent recurrence of the violation (when possible and feasible).
4. In the case of an insider threat, the Security Officer and Privacy Officer are to set up a team to investigate and mitigate the risk of insider malicious activity. BroadStreet workforce members are encouraged to come forward with information about insider threats, and can do so anonymously.
5. The Security Officer maintains all documentation of the investigation, sanctions provided, and actions taken to prevent reoccurrence for a minimum of six years after the conclusion of the investigation.

6. Data Management Policy

BroadStreet has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) stored in conjunction with BroadStreet and for SaaS Customers. This policy, and associated procedures for testing and restoring from backup data, do not apply to SaaS Customers that do not choose BroadStreet Backup Service. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by BroadStreet.

Data backup is done as needed to ensure that data remains available. Violation of this policy and its procedures by workforce members may result in corrective disciplinary action, up to and including termination of employment.

6.1 Applicable Standards

6.1.1 Applicable Standards from the HITRUST Common Security Framework

• 01.v – Information Access Restriction

6.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(7)(ii)(A) – Data Backup Plan
• 164.310(d)(2)(iii) – Accountability
• 164.310(d)(2)(iv) – Data Backup and Storage

6.2 Backup Policy and Procedures

1. Perform backups of all systems that process, store, or transmit ePHI for BroadStreet Customers, including SaaS Customers that utilize the BroadStreet Backup Service.
2. The BroadStreet Ops Team is designated to be in charge of backups.
3. Dev Ops Team members are trained and assigned to complete backups and manage the backup media.
4. Document backups
   • Name of the system
   • Date & time of backup
   • Where backup stored (or to whom it was provided)
5. Securely encrypt stored backups in a manner that protects them from loss or environmental damage.
6. Test backups annually and document that files have been completely and accurately restored from the backup media.

7. System Access Policy

Access to BroadStreet systems and application is limited for all users, including but not limited to workforce members, volunteers, interns, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized user or access of the organization’s information systems. These safeguards have been established to address the HIPAA Security regulations including the following:

7.1 Applicable Standards

7.1.1 Applicable Standards from the HITRUST Common Security Framework (CSF)

• 01.d – User Password Management
• 01.f – Password Use
• 01.r – Password Management System
• 01.a – Access Control Policy
• 01.b – User Registration
• 01.h – Clear Desk and Clear Screen Policy
• 01.j – User Authentication for External Connections
• 01.q – User Identification and Authentication
• 01.v – Information Access Restriction
• 02.i – Removal of Access Rights
• 06.e – Prevention of Misuse of Information Assets

7.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(4)(ii)(C) Access Establishment and Modification
• 164.308(a)(3)(ii)(B) Workforce Clearance Procedures
• 164.308(a)(4)(ii)(B) Access Authorization
• 164.312(d) Person or Entity Authentication
• 164.312(a)(2)(i) Unique User Identification
• 164.308(a)(5)(ii)(D) Password Management
• 164.312(a)(2)(iii) Automatic Logoff
• 164.310(b) Workstation Use
• 164.310(c) Workstation Security
• 164.308(a)(3)(ii)(C) Termination Procedures

7.2 Access Establishment and Modification

1. Requests for access to BroadStreet Platform systems and applications is made formally using the following process:
   1. A BroadStreet workforce member initiates the access request through the Security Officer and the Privacy Officers.
      • User identities must be verified prior to granting access to new accounts.
      • Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
      • For new accounts, the method used to verify the user’s identity must be recorded on the Issue.
2. The Security Officer or Privacy Officer will grant access to systems as dictated by the employee’s job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
3. Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
4. If the review is approved, the Security Officer or Privacy Officer then marks the Issue as Done, adding any pertinent notes required. The Security Officer or Privacy Officer then grants requested access.
   • New accounts will be created with a secure password that meets all requirements from §7.12, which may be changed on the initial login.
   • All password exchanges must occur over an authenticated channel.
   • For non-production systems, access grants are accomplished by leveraging the access control mechanisms built into those systems. Account management for non-production systems may be delegated to a BroadStreet employee at the discretion of the Security Officer or Privacy Officer.
5. Access is not granted until receipt, review, and approval by the BroadStreet Security Officer or Privacy Officer.
6. The request for access is retained for future reference.
7. All access to BroadStreet systems and services is reviewed and updated on a bi-annual basis to ensure proper authorizations are in place commensurate with job functions.
8. Any BroadStreet workforce member can request change of access using the process outlined in §7.2 paragraph 1.
9. Access to production systems is controlled using centralized user management and authentication.
10. Temporary accounts are not used unless absolutely necessary for business purposes.
    • Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily.
    • Accounts that are inactive for over 90 days are removed.
11. In the case of non-personal information, such as generic educational content, identification and authentication may not be required. This is the responsibility of BroadStreet Customers to define, and not BroadStreet.
12. Privileged users must first access systems using standard, unique user accounts before switching to privileged users and performing privileged tasks.
    • For production systems, this is enforced by creating non-privileged user accounts that must invoke sudo to perform privileged tasks.
    • Rights for privileged accounts are granted by the Security Officer or Privacy Officer.
13. All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems.
14. Generic accounts are not allowed on BroadStreet systems.
15. Access is granted through encrypted tunnels.
16. In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access.
17. Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.

7.3 Workforce Clearance

1. The level of security assigned to a user to the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user’s job classification and/or to a user needing access to carry out treatment, payment, or healthcare operations.
2. All access requests are treated on a “least-access principle.”
3. BroadStreet maintains a minimum necessary approach to access to Customer data. As such, BroadStreet, including all workforce members, does not readily have access to any ePHI.

7.4 Access Authorization

1. Role based access categories for each BroadStreet system and application are pre-approved by the Security Officer, or an authorized delegate of the Security Officer.
2. BroadStreet utilizes hardware and software firewalls to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.

7.5 Person or Entity Authentication

1. Each workforce member has and uses a unique user ID and password that identifies him/her as the user of the information system.
2. Each Customer and Partner has and uses a unique user ID and password that identifies him/her as the user of the information system.
3. All Customer support desk interactions must be verified before BroadStreet support personnel will satisfy any request having information security implications.
   • BroadStreet’s current support desk software requires users to authenticate before submitting support tickets.
   • Support issues submitted via BroadStreet’s dashboard require that users authenticate with their BroadStreet account before submitting support tickets.
   • Support issues submitted by email must be verified by BroadStreet personnel using a phone number that has been registered with the corresponding account.

7.6 Unique User Identification

1. Access to the BroadStreet Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
2. Passwords requirements mandate strong password controls (see below).
3. Passwords are not displayed at any time and are not transmitted or stored in plain text.
4. Default accounts on all production systems, including root, are disabled.
5. Shared accounts are not allowed within BroadStreet systems or networks.
6. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with BroadStreet workstations or production systems.

7.7 Automatic Logoff

1. Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
2. Information systems automatically log users off the systems after 30 minutes of inactivity.
3. The Security Officer pre-approves exceptions to automatic log off requirements.

7.8 Employee Workstation Use

The following items apply to any workstations owned by BroadStreet.

1. Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
2. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through organization’s system.
3. Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
4. Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
5. Transmitted messages may not contain material that criticizes the organization, its providers, its employees, or others.
6. Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
7. Workstation hard drives will be encrypted.
8. All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.
9. All workstations are to have the following messages added to the lock screen and login screen: This computer is owned by BroadStreet Health, Inc. By logging in, unlocking, and/or using this computer you acknowledge you have seen, and follow, these policies (https://broadstreet.io/legal/) and have completed HIPAA training. Please contact us if you have problems with this – hello@broadstreet.io.

7.9 Wireless Access Use

1. BroadStreet production systems are not accessible directly over wireless channels.
2. Wireless access is disabled on all production systems.
3. When accessing production systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.
4. Wireless networks managed within BroadStreet non-production facilities (offices, etc.) are secured with the following configurations:
   • All data in transit over wireless is encrypted using WPA2 encryption;
   • Passwords are rotated on a regular basis. This process is managed by the BroadStreet Security Officer.

7.10 Employee Termination Procedures

1. The Human Resources Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitating completion of the “Termination Checklist”.
2. The Human Resources Department, users, and supervisors are required to notify the Security Officer to terminate a user’s access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
   • The user has been using their access rights inappropriately.
   • A user’s password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password).
   • An unauthorized individual is utilizing a user’s User Login ID and password (a new password may be provided to the user if the user is not identified as providing the unauthorized individual with the User Login ID and password).
3. The Security Officer will terminate users’ access rights immediately upon notification, and will coordinate with the appropriate BroadStreet employees to terminate access to any non-production systems managed by those employees.
4. The Security Officer audits and may terminate access of users that have not logged into organization’s information systems/applications for an extended period of time.

7.11 Paper Records

BroadStreet does not use paper records for any sensitive information. Use of paper for recording and storing sensitive data is against BroadStreet policies.

7.12 Password Management

1. User IDs and passwords are used to control access to BroadStreet systems and may not be disclosed to anyone for any reason.
2. Users may not allow anyone, for any reason, to have access to any information system using another user’s unique user ID and password.
3. On all production systems and applications in the BroadStreet environment, password configurations are set to require:
   • A minimum length of 8 characters;
   • A mix of upper case characters, lower case characters, numbers or special characters; and
   • Account lockout after 5 invalid attempts.
4. All system and application passwords must be stored and transmitted securely.
   • Where possible, passwords should be stored in a hashed format using a salted cryptographic hash function (SHA-256 or equivalent).
   • Passwords that must be stored in non-hashed format must be encrypted at rest.
   • Transmitted passwords must be encrypted in flight.
5. Each information system automatically requires users to change passwords at a pre-determined interval as determined by the organization, based on the criticality and sensitivity of the ePHI contained within the network, system, application, and/or database.
6. Passwords are inactivated immediately upon an employee’s termination.
7. All default system, application, and Partner passwords are changed before deployment to production.
8. Upon initial login, users must change any passwords that were automatically generated for them.
9. Password change methods must use a confirmation method to correct for user input errors.
10. All passwords used in configuration scripts are secured and encrypted.
11. If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office.
12. In cases where a user has forgotten their password, the following procedure is used to reset the password.
    • The user submits a password reset request to hello@broadstreet.io. The request should include the system to which the user has lost access and needs the password reset.
    • An administrator with password reset privileges is notified and connects directly with the user requesting the password reset.
    • The administrator verifies the identity of the user either in-person or through a separate communication channel such as phone or Slack.
    • Once verified, the administrator resets the password.

The password-reset email inbox is used to track and store password reset requests. The Privacy Officer is the owner of this group and modifies membership as needed.

7.13 Access to ePHI

1. Employees may not download ePHI to any workstations used to connect to production systems.
2. Disallowing transfer of ePHI to workstations is enforced through technical measures.

7.14 SaaS Customer Access to Systems

In the case of data migration, BroadStreet does, on a case by case basis, support customers in importing data. In these cases BroadStreet requires that all data is secured and encrypted in transit, such as by using SFTP or SCP for transferring files.

In the case of an investigation, BroadStreet will assist customers, at BroadStreet’s discretion, and law enforcement in forensics.

8. Auditing Policy

BroadStreet shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. The Security Rule requires healthcare organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. BroadStreet shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

It is the policy of BroadStreet to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, BroadStreet shall audit access and activity to detect, report, and guard against:

• Network vulnerabilities and intrusions;
• Breaches in confidentiality and security of patient protected health information;
• Performance problems and flaws in applications;
• Improper alteration or destruction of ePHI;
• Out of date software and/or software known to have vulnerabilities.

This policy applies to all BroadStreet Add-on systems that store, transmit, or process ePHI.

8.1 Applicable Standards

8.1.1 Applicable Standards from the HITRUST Common Security Framework (CSF)

• 0.a Information Security Management Program
• 01.a Access Control Policy
• 01.b User Registration
• 01.c Privilege Management
• 09.aa Audit Logging
• 09.ac Protection of Log Information
• 09.ab – Monitoring System Use
• 06.e – Prevention of Misuse of Information

8.1.2 Applicable Standards from the HIPAA Security Rule

• 45 CFR §164.308(a)(1)(ii)(D) – Information System Activity Review
• 45 CFR §164.308(a)(5)(ii)(B) & (C) – Protection from Malicious Software & Log-in Monitoring
• 45 CFR §164.308(a)(2) – HIPAA Security Rule Periodic Evaluation
• 45 CFR §164.312(b) – Audit Controls
• 45 CFR §164.312(c)(2) – Mechanism to Authenticate ePHI
• 45 CFR §164.312(e)(2)(i) – Integrity Controls

8.2 Auditing Policies

1. Responsibility for auditing information system access and activity is assigned to BroadStreet’s Security Officer. The Security Officer shall:
   • Assign the task of generating reports for audit activities to the workforce member responsible for the application, system, or network;
   • Assign the task of reviewing the audit reports to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task;
   • Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.).
   • All connections to BroadStreet are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
2. BroadStreet’s auditing processes shall address access and activity at the following levels listed below. In the case of SaaS Customers, Application and User level auditing is the responsibility of the Customer; BroadStreet provides software to aggregate and view User and Application logs, but the log data collected is the responsibility of the SaaS Customer. Auditing processes may address date and time of each log-on attempt, date and time of each log-off attempt, devices used, functions performed, etc.
   • User: User level audit trails generally monitor and log all commands directly initiated by the user, all identification and authentication attempts, and data and services accessed.
   • Application: Application level audit trails generally monitor and log all user activities, including data accessed and modified and specific actions.
   • System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions. BroadStreet utilizes file system monitoring from OSSEC to assure the integrity of file system data.
   • Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
3. BroadStreet may log all incoming and outgoing traffic into and out of its environment. This includes all successful and failed attempts at data access and editing. Data associated with this data will include origin, destination, time, and other relevant details that are available to BroadStreet.
4. BroadStreet utilizes OSSEC to scan all systems for malicious and unauthorized software.
5. BroadStreet treats its Dashboard as a Platform Add-on and, as such, it logs all activity associated with Dashboard Access.
6. BroadStreet uses OSSEC to monitor the integrity of log files by utilizing OSSEC System Integrity Checking capabilities.
7. BroadStreet shall identify “trigger events” or criteria that raise awareness of questionable conditions of viewing of confidential information. The “events” may be applied to the entire BroadStreet Platform or may be specific to a Customer, partner, business associate, Platform Add-on or application (See Listing of Potential Trigger Events below).
8. BroadStreet’s Security Officer and Privacy Officer are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:
   • Scanning tools and devices;
   • Password cracking utilities;
   • Network “sniffers.”
   • Passive and active intrusion detection systems.
9. The process for review of audit logs, trails, and reports shall include:
   • Description of the activity as well as rationale for performing the audit.
   • Identification of which BroadStreet workforce members will be responsible for review.
   • Frequency of the auditing process.
   • Determination of significant events requiring further review and follow-up.
   • Identification of appropriate reporting channels for audit results and required follow-up.
10. Vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls.
    • Testing may be carried out internally or provided through an external third-party vendor. Whenever possible, a third party auditing vendor should not be providing the organization IT oversight services (e.g., vendors providing IT services should not be auditing their own services – separation of duties).
11. Software patches and updates will be applied to all systems in a timely manner.

8.3 Audit Requests

1. A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Privacy Officer, Security Officer, Customer, Partner, or an Application owner or application user.
2. A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request must be reviewed and approved by BroadStreet’s Privacy or Security Officer.
3. A request for an audit must be approved by BroadStreet’s Privacy Officer and/or Security Officer before proceeding. Under no circumstances shall detailed audit information be shared with parties without proper permissions and access to see such data.
   • Should the audit disclose that a workforce member has accessed ePHI inappropriately, the minimum necessary/least privileged information shall be shared with BroadStreet’s Security Officer to determine appropriate sanction/corrective disciplinary action.
   • Only de-identified information shall be shared with Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by BroadStreet’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, BroadStreet will consider seeking risk management and/or legal counsel.

8.4 Review and Reporting of Audit Findings

1. Audit information that is routinely gathered must be reviewed in a timely manner, currently monthly, by the responsible workforce member(s). On a quarterly basis, logs are reviewed to assure the proper data is being captured and retained.
2. The reporting process shall allow for meaningful communication of the audit findings to those workforce members, Customers, or Partners requesting the audit.
   • Significant findings shall be reported immediately in a written format. BroadStreet’s security incident response form may be utilized to report a single event.
   • Routine findings shall be reported to the sponsoring leadership structure in a written report format.
3. Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval.
4. Security audits constitute an internal, confidential monitoring practice that may be included in BroadStreet’s performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable ePHI shall not be included in the reports).
5. Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.
6. Log review activity is monitored on a quarterly basis using the Quality Management System reporting to assess compliance with above policy.

8.5 Auditing Customer and Partner Activity

1. Periodic monitoring of Customer and Partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between BroadStreet and the 3rd party. BroadStreet will make every effort to assure Customers and Partners do not gain access to data outside of their own Environments.
2. If it is determined that the Customer or Partner has exceeded the scope of access privileges, BroadStreet’s leadership must remedy the problem immediately.
3. If it is determined that a Customer or Partner has violated the terms of the HIPAA business associate agreement or any terms within the HIPAA regulations, BroadStreet must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

8.6 Audit Log Security Controls and Backup

1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy.
2. All audit logs are protected in transit and encrypted at rest to control access to the content of the logs.

8.7 Workforce Training, Education, Awareness and Responsibilities

1. BroadStreet workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI (see BroadStreet HIPAA Training). BroadStreet’s commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies. BroadStreet workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies.
2. BroadStreet Customers are provided with necessary information to understand BroadStreet auditing capabilities.

8.8 External Audits of Information Access and Activity

1. Prior to contracting with an external audit firm, BroadStreet shall:
   • Outline the audit responsibility, authority, and accountability;
   • Choose an audit firm that is independent of other organizational operations;
   • Ensure technical competence of the audit firm staff;
   • Require the audit firm’s adherence to applicable codes of professional ethics;
   • Obtain a signed HIPAA business associate agreement;
   • Assign organizational responsibility for supervision of the external audit firm.

8.9 Retention of Audit Data

1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on:
   • Organizational history and experience.
   • Available storage space.
2. Reports summarizing audit activities shall be retained for a period of six years.
3. Audit log data is retained locally on the audit log server for a one-month period.
4. For SaaS Customers, they choose the length of backup retention and availability that BroadStreet will implement and enforce.

8.10 Potential Trigger Events

• High risk or problem prone incidents or events.
• Business associate, customer, or partner complaints.
• Known security vulnerabilities.
• Atypical patterns of activity.
• Failed authentication attempts.
• Remote access use and activity.
• Activity post termination.
• Random audits.

9.1 Software Development Method

All software development will be performed in compliance with the written policies concerning systems access, data integrity, and approved tools.

Development of software tools and any part of BroadStreet’s production software, especially the functionality provided through the my.broadstreet.io web site, will follow a set procedure unless otherwise decided upon by BroadStreet leadership. Below is a high-level overview of BroadStreet’s software development procedure phases:

1. Specification of features and requirements
2. Estimate of resources required
3. Approval of estimate
4. Iterative development, review, feedback cycle
5. Integration testing
6. Deployment to production

9.1.1 Specification of Features and Requirements

Specification of features and requirements typically includes visual design, prototyping and testing of user experience, including specifications and written descriptions of software functionality. Design, prototyping and user testing central to the BroadStreet process to ensure the software appropriately meets user needs. Thus, well before developers begin building the software, protypes are built for using testing with UX/UI design tools (e.g., Adobe XD).

9.1.2 Estimate of Resources Required & 1.4.3 Approval of Estimate

For phases 2 and 3, estimate of resources is done by outlining and scoping the features from phase 1. The features and requirements are then reviewed and discussed with all important stakeholders to ensure the proposed software meets all compliance requirements. This also includes a breakdown of work effort into manageable units by the developer and final team approval of estimates.

9.1.3 Iterative Development, Review, Feedback Cycle

For phase 4, iterative development will be performed locally by the developer and submitted for review by BroadStreet leadership on an ongoing basis. All developers will incorporate feedback and design changes if needed and iterate for further review until complete. This loosely reflects the Agile software development methodology process, but in a more continuous and on-going way.

9.1.4 Integration Testing

In phase 5, Integration testing is performed utilizing a testing server which is securely accessible to permitted developers. Testing is essential to compliance as it allows for a thorough review of the software before it is made available to a wide audience of users in the live production environment.

9.1.5 Deployment to Production

Deployment to production in phase 6 is carried out by the CTO or a person designated by the CTO for that purpose. Deployments should be performed within scheduled maintenance windows to allow for detection and resolution of any technical issues without compromising user experience or compliance.

BroadStreet’s major production releases target a fixed once-a-month cycle on the 5th day of each month. Minor production releases are done continuously to ensure important software updates occur (e.g., bugs, patches, etc.).

9.2 Documentation

Any updates to BroadStreet’s production software will be recorded within the applicable Git source and version control repositories to provide an accessible history of modifications to the software. Iterative monthly major releases and minor interim releases will be tagged with the release number and accompanied by a written summary of changes.

9.3 Version Control

Refer to the GitLab repository at GitLab.com BroadStreet Policies for the full version history of these policies. Please send e-mail to hello@broadstreet.io to request access.

10. Facility Access Policy

BroadStreet works with Subcontractors to assure restriction of physical access to systems used as part of the BroadStreet Platform. BroadStreet and its Subcontractors control access to the physical buildings/facilities that house these systems/applications, or in which BroadStreet workforce members operate, in accordance to the HIPAA Security Rule 164.310 and its implementation specifications. Physical Access to all of BroadStreet facilities is limited to only those authorized in this policy. In an effort to safeguard ePHi from unauthorized access, tampering, and theft, access is allowed to areas only to those persons authorized to be in them and with escorts for unauthorized persons. All workforce members are responsible for reporting an incident of unauthorized visitor and/or unauthorized access to BroadStreet’s facility.

Of note, BroadStreet does not have ready access to ePHI, it provides cloud-based, compliant infrastructure to covered entities and business associates. BroadStreet does not physically house any systems used by its Platform in BroadStreet facilities. Physical security of our Platform servers is outlined in §1.3.

10.1 Applicable Standards

10.1.1 Applicable Standards from the HITRUST Common Security Framework

• 08.b – Physical Entry Controls
• 08.d – Protecting Against External and Environmental Threats
• 08.j – Equipment Maintenance
• 08.l – Secure Disposal or Re-Use of Equipment
• 09.p – Disposal of Media

10.1.2 Applicable Standards from the HIPAA Security Rule

• 164.310(a)(2)(ii) Facility Security Plan
• 164.310(a)(2)(iii) Access Control & Validation Procedures
• 164.310(b-c) Workstation Use & Security

11. Incident Response Policy

BroadStreet implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.

The incident response process addresses:

• Continuous monitoring of threats through intrusion detection systems (IDS) and other monitoring applications;
• Establishment of an information security incident response team;
• Establishment of procedures to respond to media inquiries;
• Establishment of clear procedures for identifying, responding, assessing, analyzing, and follow-up of information security incidents;
• Workforce training, education, and awareness on information security incidents and required responses; and
• Facilitation of clear communication of information security incidents with internal, as well as external, stakeholders

Note: These policies were adapted from work by the HIPAA Collaborative of Wisconsin Security Networking Group. Refer to the linked document for additional copyright information.

11.1 Applicable Standards

11.1.1 Applicable Standards from the HITRUST Common Security Framework

• 11.a – Reporting Information Security Events
• 11.c – Responsibilities and Procedures

11.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(5)(i) – Security Awareness and Training
• 164.308(a)(6) – Security Incident Procedures

11.2 Incident Management Policies

The BroadStreet incident response process largely follows the process recommended by SANS, an industry leader in security.

BroadStreet’s incident response classifies security-related events into the following categories:

• Events – Any observable computer security-related occurrence in a system or network with a negative consequence. Examples:
  • Hardware component failing causing service outages.
  • Software error causing service outages.
  • General network or system instability.
• Precursors – A sign that an incident may occur in the future. Examples:
  • Monitoring system showing unusual behavior.
  • Audit log alerts indicated several failed login attempts.
  • Suspicious emails targeting specific BroadStreet staff members with administrative access to production systems.
• Indications – A sign that an incident may have occurred or may be occurring at the present time. Examples:
  • IDS alerts for modified system files or unusual system accesses.
  • Antivirus alerts for infected files.
  • Excessive network traffic directed at unexpected geographic locations.
• Incidents – A violation of computer security policies or acceptable use policies, often resulting in data breaches. Examples:
  • Unauthorized disclosure of ePHI.
  • Unauthorized change or destruction of ePHI.
  • A data breach accomplished by an internal or external entity.
  • A Denial-of-Service (DoS) attack causing a critical service to become unreachable.

BroadStreet employees must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems (such as email or Slack). In practice this means keeping an eye out for security events, and letting the Security Officer know about any observed precursors or indications as soon as they are discovered.

11.2.1 Identification Phase

1. Immediately upon observation BroadStreet members report suspected and known Events, Precursors, Indications, and Incidents in one of the following ways:
   1. Direct report to management, the Security Officer, Privacy Officer, or other;
   2. Email;
   3. Phone call; and
   4. Secure Chat.
   5. Anonymously through workforce members desired channels.
2. The individual receiving the report notifies the Security Officer (if not already done).
3. The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident.
4. The Security Officer, Privacy Officer, or BroadStreet representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer.
5. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to BroadStreet and potentially external.

11.2.2 Containment Phase (Technical)

In this Phase, BroadStreet’s IT department attempts to contain the security incident. It is extremely important to take detailed notes during the security incident response process. This provides that the evidence gathered during the security incident can be used successfully during prosecution, if appropriate.

1. The SIRT reviews any information that has been collected by the Security Officer or any other individual investigating the security incident.
2. The SIRT secures the network perimeter.
3. The IT department performs the necessary platform and system modifications.
4. Continuously apprise Senior Management of progress.
5. Continue to notify affected Customers and Partners with relevant updates as needed

11.2.3 Eradication Phase (Technical)

The Eradication Phase represents the SIRT’s effort to remove the cause, and the resulting security exposures, that are now on the affected system(s).

1. Determine symptoms and cause related to the affected system(s).
2. Strengthen the defenses surrounding the affected system(s), where possible (a risk assessment may be needed and can be determined by the Security Officer). This may include the following:
   1. An increase in network perimeter defenses.
   2. An increase in system monitoring defenses.
   3. Remediation (“fixing”) any security issues within the affected system, such as removing unused services/general host hardening techniques.
3. Conduct a detailed vulnerability assessment to verify all the holes/gaps that can be exploited have been addressed.
   1. If additional issues or symptoms are identified, take appropriate preventative measures to eliminate or minimize potential future compromises.
4. Update the documentation with the information learned from the vulnerability assessment, including the cause, symptoms, and the method used to fix the problem with the affected system(s).
5. Apprise Senior Management of the progress.
6. Continue to notify affected Customers and Partners with relevant updates as needed.
7. Move to Phase IV, Recovery.

11.2.4 Recovery Phase (Technical)

The Recovery Phase represents the SIRT’s effort to restore the affected system(s) back to operation after the resulting security exposures, if any, have been corrected.

1. The technical team determines if the affected system(s) have been changed in any way.
   1. If they have, the technical team restores the system to its proper, intended functioning (“last known good”).
   2. Once restored, the team validates that the system functions the way it was intended/had functioned in the past. This may require the involvement of the business unit that owns the affected system(s).
   3. If operation of the system(s) had been interrupted (i.e., the system(s) had been taken offline or dropped from the network while triaged), restart the restored and validated system(s) and monitor for behavior.
   4. If the system had not been changed in any way, but was taken offline (i.e., operations had been interrupted), restart the system and monitor for proper behavior.
   5. Update the documentation with the detail that was determined during this phase.
   6. Apprise Senior Management of progress.
   7. Continue to notify affected Customers and Partners with relevant updates as needed.
   8. Move to Phase V, Follow-up.

11.2.5 Follow-up Phase (Technical and Non-Technical)

The Follow-up Phase V represents the review of the security incident to look for “lessons learned” and to determine whether the process that was taken could have been improved in any way. It is recommended all security incidents be reviewed shortly after resolution to determine where response could be improved. Timeframes may extend to one to two weeks post-incident.

1. Responders to the security incident (SIRT Team and technical security resource) meet to review the documentation collected during the security incident.
2. Create a “lessons learned” document.

11.2.6 Periodic Evaluation

It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding BroadStreet’s expectation for them, relative to security responsibilities. The incident response plan is tested annually.

11.3 Security Incident Response Team (SIRT)

Current members of the BroadStreet SIRT:

• Security Officer
• Privacy Officer

12. Breach Policy

To provide guidance for breach notification when impressive or unauthorized access, acquisition, use and/or disclosure of the ePHI occurs. Breach notification will be carried out in compliance with the American Recovery and Reinvestment Act (ARRA)/Health Information Technology for Economic and Clinical Health Act (HITECH) as well as any other federal or state notification law.

The Federal Trade Commission (FTC) has published breach notification rules for vendors of personal health records as required by ARRA/HITECH. The FTC rule applies to entities not covered by HIPAA, primarily vendors of personal health records. The rule is effective September 24, 2009 with full compliance required by February 22, 2010.

The American Recovery and Reinvestment Act of 2009 (ARRA) was signed into law on February 17, 2009. Title XIII of ARRA is the Health Information Technology for Economic and Clinical Health Act (HITECH). HITECH significantly impacts the Health Insurance Portability and Accountability (HIPAA) Privacy and Security Rules. While HIPAA did not require notification when patient protected health information (PHI) was inappropriately disclosed, covered entities and business associates may have chosen to include notification as part of the mitigation process. HITECH does require notification of certain breaches of unsecured PHI to the following: individuals, Department of Health and Human Services (HHS), and the media. The effective implementation for this provision is September 23, 2009 (pending publication HHS regulations).

In the case of a breach, BroadStreet shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals.

12.1 Applicable Standards

12.1.1 Applicable Standards from the HITRUST Common Security Framework

• 11.a Reporting Information Security Events
• 11.c Responsibilities and Procedures

12.1.2 Applicable Standards from the HIPAA Security Rule

• Security Incident Procedures – 164.308(a)(6)(i)
• HITECH Notification in the Case of Breach – 13402(a) and 13402(b)
• HITECH Timeliness of Notification – 13402(d)(1)
• HITECH Content of Notification – 13402(f)(1)

12.2 BroadStreet Breach Policy

1. Discovery of Breach: A breach of ePHI shall be treated as “discovered” as of the first day on which such breach is known to the organization, or, by exercising reasonable diligence would have been known to BroadStreet (includes breaches by the organization’s Customers, Partners, or subcontractors). BroadStreet shall be deemed to have knowledge of a breach if such breach is known or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is a workforce member or Partner of the organization. Following the discovery of a potential breach, the organization shall begin an investigation (see organizational policies for security incident response and/or risk management incident response) immediately, conduct a risk assessment, and based on the results of the risk assessment, begin the process to notify each Customer affected by the breach. BroadStreet shall also begin the process of determining what external notifications are required or should be made (e.g., Secretary of Department of Health & Human Services (HHS), media outlets, law enforcement officials, etc.)
2. Breach Investigation: The BroadStreet Security Officer shall name an individual to act as the investigator of the breach (e.g., privacy officer, security officer, risk manager, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others in the organization as appropriate (e.g., administration, security incident response team, human resources, risk management, public relations, legal counsel, etc.) The investigator shall be the key facilitator for all breach notification processes to the appropriate entities (e.g., HHS, media, law enforcement officials, etc.). All documentation related to the breach investigation, including the risk assessment, shall be retained for a minimum of six years.
3. Risk Assessment: For an acquisition, access, use or disclosure of ePHI to constitute a breach, it must constitute a violation of the HIPAA Privacy Rule. A use or disclosure of ePHI that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule and would not qualify as a potential breach. To determine if an impermissible use or disclosure of ePHI constitutes a breach and requires further notification, the organization will need to perform a risk assessment to determine if there is significant risk of harm to the individual as a result of the impermissible use or disclosure. The organization shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. The organization has the burden of proof for demonstrating that all notifications to appropriate Customers or that the use or disclosure did not constitute a breach. Based on the outcome of the risk assessment, the organization will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact specific and address:
   • Consideration of who impermissibly used or to whom the information was impermissibly disclosed;
   • The type and amount of ePHI involved;
   • The cause of the breach, and the entity responsible for the breach, either Customer, BroadStreet, or Partner.
   • The potential for significant risk of financial, reputational, or other harm.
4. Timeliness of Notification: Upon discovery of a breach, notice shall be made to the affected BroadStreet Customers no later than 10 days after the discovery of the breach. It is the responsibility of the organization to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay.
5. Delay of Notification Authorized for Law Enforcement Purposes: If a law enforcement official states to the organization that a notification, notice, or posting would impede a criminal investigation or cause damage to national security, the organization shall:
   • If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting of the timer period specified by the official; or
   • If the statement is made orally, document the statement, including the identify of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described above is submitted during that time.
6. Content of the Notice: The notice shall be written in plain language and must contain the following information:
   • A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known;
   • A description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of information were involved), if known;
   • Any steps the Customer should take to protect Customer data from potential harm resulting from the breach.
   • A brief description of what BroadStreet is doing to investigate the breach, to mitigate harm to individuals and Customers, and to protect against further breaches.
   • Contact procedures for individuals to ask questions or learn additional information, which may include a toll-free telephone number, an e-mail address, a web site, or postal address.
7. Methods of Notification: BroadStreet Customers will be notified via email and phone within the timeframe for reporting breaches, as outlined above.
8. Maintenance of Breach Information/Log: As described above and in addition to the reports created for each incident, BroadStreet shall maintain a process to record or log all breaches of unsecured ePHI regardless of the number of records and Customers affected. The following information should be collected/logged for each breach (see sample Breach Notification Log):
   • A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
   • A description of the types of unsecured protected health information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known.
   • A description of the action taken with regard to notification of patients regarding the breach.
   • Resolution steps taken to mitigate the breach and prevent future occurrences.
9. Workforce Training: BroadStreet shall train all members of its workforce on the policies and procedures with respect to ePHI as necessary and appropriate for the members to carry out their job responsibilities. Workforce members shall also be trained as to how to identify and report breaches within the organization.
10. Complaints: BroadStreet must provide a process for individuals to make complaints concerning the organization’s patient privacy policies and procedures or its compliance with such policies and procedures.
11. Sanctions: The organization shall have in place and apply appropriate sanctions against members of its workforce, Customers, and Partners who fail to comply with privacy policies and procedures.
12. Retaliation/Waiver: BroadStreet may not intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual for the exercise by the individual of any privacy right. The organization may not require individuals to waive their privacy rights under as a condition of the provision of treatment, payment, enrollment in a health plan, or eligibility for benefits.

12.3 BroadStreet Platform Customer Responsibilities

1. The BroadStreet Customer that accesses, maintains, retains, modifies, records, stores, destroys, or otherwise holds, uses, or discloses unsecured ePHI shall, without unreasonable delay and in no case later than 60 calendar days after discovery of a breach, notify BroadStreet of such breach. The Customer shall provide BroadStreet with the following information:
   • A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
   • A description of the types of unsecured protected health information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known.
   • A description of the action taken with regard to notification of patients regarding the breach.
   • Resolution steps taken to mitigate the breach and prevent future occurrences.
2. Notice to Media: BroadStreet Customers are responsible for providing notice to prominent media outlets at the Customer’s discretion.
3. Notice to Secretary of HHS: BroadStreet Customers are responsible for providing notice to the Secretary of HHS at the Customer’s discretion.

12.4 Sample Letter to Customers in Case of Breach

[Date]

[Name] [Name of Customer] [Address 1] [Address 2] [City, State Zip Code]

Dear [Name of Customer]:

I am writing to you from BroadStreet LLC, with important information about a recent breach that affects your account with us. We became aware of this breach on [Insert Date] which occurred on or about [Insert Date]. The breach occurred as follows:

Describe event and include the following information:

• A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known.
• A description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of information were involved), if known.
• Any steps the Customer should take to protect themselves from potential harm resulting from the breach.
• A brief description of what BroadStreet is doing to investigate the breach, to mitigate harm to individuals, and to protect against further breaches.
• Contact procedures for individuals to ask questions or learn additional information, which includes a toll-free telephone number, an e-mail address, web site, or postal address.

Other Optional Considerations:

• Recommendations to assist customer in remedying the breach.

We will assist you in remedying the situation.

Sincerely,

James Walters
Co-founder – BroadStreet LLC
james@broadstreet.io
414-555-1234

13. Disaster Recovery Policy

The BroadStreet Contingency Plan establishes procedures to recover BroadStreet following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the BroadStreet Security Officer and Privacy Officer.

The following objectives have been established for this plan:

1. Maximize the effectiveness of contingency operations through an established plan that consists of the following phases:
   • Notification/Activation phase to detect and assess damage and to activate the plan;
   • Recovery phase to restore temporary IT operations and recover damage done to the original system;
   • Reconstitution phase to restore IT system processing capabilities to normal operations.
2. Identify the activities, resources, and procedures needed to carry out BroadStreet processing requirements during prolonged interruptions to normal operations.
3. Identify and define the impact of interruptions to BroadStreet systems.
4. Assign responsibilities to designated personnel and provide guidance for recovering BroadStreet during prolonged periods of interruption to normal operations.
5. Ensure coordination with other BroadStreet staff who will participate in the contingency planning strategies.
6. Ensure coordination with external points of contact and vendors who will participate in the contingency planning strategies.

Example of the types of disasters that would initiate this plan are natural disaster, political disturbances, man made disaster, external human threats, internal malicious activities.

BroadStreet defined two categories of systems from a disaster recovery perspective.

1. Critical Systems. These systems host application servers and database servers or are required for functioning of systems that host application servers and database servers. These systems, if unavailable, affect the integrity of data and must be restored, or have a process begun to restore them, immediately upon becoming unavailable.
2. Non-critical Systems. These are all systems not considered critical by definition above. These systems, while they may affect the performance and overall security of critical systems, do not prevent Critical systems from functioning and being accessed appropriately. These systems are restored at a lower priority than critical systems.

13.1 Applicable Standards

13.1.1 Applicable Standards from the HITRUST Common Security Framework

• 12.c – Developing and Implementing Continuity Plans Including Information Security

13.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(7)(i) – Contingency Plan
• 164.312(a)(2)(ii) – Emergency Access Procedure

14. Disposable Media Policy

BroadStreet recognizes that media containing ePHI may be reused when appropriate steps are taken to ensure that all stored ePHI has been effectively rendered inaccessible. Destruction/disposal of ePHI shall be carried out in accordance with federal and state law. The schedule for destruction/disposal shall be suspended for ePHI involved in any open investigation, audit, or litigation.

BroadStreet utilizes dedicated hardware from Subcontractors. ePHI is only stored on SSD volumes in our hosted environment. All SSD volumes utilized by BroadStreet and BroadStreet Customers are encrypted. BroadStreet does not use, own, or manage any mobile devices, SD cards, or tapes that have access to ePHI.

14.1 Applicable Standards

14.1.1 Applicable Standards from the HITRUST Common Security Framework

• 0.9o – Management of Removable Media

14.1.2 Applicable Standards from the HIPAA Security Rule

• 164.310(d)(1) – Device and Media Controls

14.2 Disposable Media Policy

1. All removable media is restricted, audited, and is encrypted.
2. BroadStreet assumes all disposable media in its Platform may contain ePHI, so it treats all disposable media with the same protections and disposal policies.
3. All destruction/disposal of ePHI media will be done in accordance with federal and state laws and regulations and pursuant to the BroadStreet’s written retention policy/schedule. Records that have satisfied the period of retention will be destroyed/disposed of in an appropriate manner.
4. Records involved in any open investigation, audit or litigation should not be destroyed/disposed of. If notification is received that any of the above situations have occurred or there is the potential for such, the record retention schedule shall be suspended for these records until such time as the situation has been resolved. If the records have been requested in the course of a judicial or administrative hearing, a qualified protective order will be obtained to ensure that the records are returned to the organization or properly destroyed/disposed of by the requesting party.
5. Before reuse of any media, for example all ePHI is rendered inaccessible, cleaned, or scrubbed. All media is formatted to restrict future access.
6. All BroadStreet Subcontractors provide that, upon termination of the contract, they will return or destroy/dispose of all patient health information. In cases where the return or destruction/disposal is not feasible, the contract limits the use and disclosure of the information to the purposes that prevent its return or destruction/disposal.
7. Any media containing ePHI is disposed using a method that ensures the ePHI could not be readily recovered or reconstructed.
8. The methods of destruction, disposal, and reuse are reassessed periodically, based on current technology, accepted practices, and availability of timely and cost-effective destruction, disposal, and reuse technologies and services.
9. In the cases of a BroadStreet Customer terminating a contract with BroadStreet and no longer utilizing BroadStreet Services, the following actions will be taken depending on the BroadStreet Services in use. In all cases it is solely the responsibility of the BroadStreet Customer to maintain the safeguards required of HIPAA once the data is transmitted out of BroadStreet Systems.
   • In the case of SaaS Customer termination, BroadStreet will provide the customer with 30 days from the date of termination to export data.

15. IDS Policy

In order to preserve the integrity of data that BroadStreet stores, processes, or transmits for Customers, BroadStreet implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access. BroadStreet currently utilizes OSSEC to track file system integrity, monitor log data, and detect rootkit access.

15.1 Applicable Standards

15.1.1 Applicable Standards from the HITRUST Common Security Framework

• 09.ab – Monitoring System Use
• 06.e – Prevention of Misuse of Information
• 10.h – Control of Operational Software

15.1.2 Applicable Standards from the HIPAA Security Rule

• 164.312(b) – Audit Controls

15.2 Intrusion Detection Policy

1. OSSEC is used to monitor and correlate log data from different systems on an ongoing basis. Reports generated by OSSEC are reviewed by the Security Officer on a monthly basis.
2. OSSEC generates alerts to analyze and investigate suspicious activity or suspected violations.
3. OSSEC monitors file system integrity and sends real time alerts when suspicious changes are made to the file system.
4. Automatic monitoring is done to identify patterns that might signify the lack of availability of certain services and systems (DoS attacks).
5. BroadStreet firewalls monitor all incoming traffic to detect potential denial of service attacks. Suspected attack sources are blocked automatically. Additionally, our hosting provider actively monitors its network to detect denial of services attacks.
6. All new firewall rules and configuration changes are tested before being pushed into production. All firewall and router rules are reviewed every quarter.
7. BroadStreet utilizes redundant firewall on network perimeters.

16. Vulnerability Scanning Policy

BroadStreet is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. BroadStreet may utilize a vulnerability scanner to consistently scan, identify, and address vulnerabilities on our systems. We also utilize OSSEC on all systems, including logs, for file integrity checking and intrusion detection.

16.1 Applicable Standards

16.1.1 Applicable Standards from the HITRUST Common Security Framework

• 10.m – Control of Technical Vulnerabilities

16.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(8) – Evaluation

16.2 Vulnerability Scanning Policy

1. Vulnerability management is performed by the BroadStreet Security Officer, or an authorized delegate of the Security Officer.
2. Reviewing reports and findings, as well as any further investigation into discovered vulnerabilities, is the responsibility of the BroadStreet Security Officer.
3. In the case of new vulnerabilities, the following steps are taken:

• All new vulnerabilities are verified manually to assure they are repeatable. Those not found to be repeatable are manually tested after the next vulnerability scan, regardless of if the specific vulnerability is discovered again.
• Vulnerabilities that are repeatable manually are documented and reviewed by the Security Officer and Privacy Officer to see if they are part of the current risk assessment performed by BroadStreet.
  • Those that are a part of the current risk assessment are checked for mitigations.
  • Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in the BroadStreet Risk Assessment Policy.

4. Penetration testing is performed regularly as part of the BroadStreet vulnerability management policy.
5. This vulnerability policy is reviewed on a quarterly basis by the Security Officer and Privacy Officer.

17. Data Integrity Policy

BroadStreet takes data integrity very seriously. As stewards and partners of BroadStreet Customers, we strive to assure data is protected from unauthorized access and that it is available when needed. The following policies drive many of our procedures and technical settings in support of the BroadStreet mission of data protection.

Production systems that create, receive, store, or transmit Customer data (hereafter “Production Systems”) must follow the guidelines described in this section.

17.1 Applicable Standards

17.1.1 Applicable Standards from the HITRUST Common Security Framework

• 10.b – Input Data Validation

17.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(8) – Evaluation

17.2 Disabling Non-Essential Services

1. All Production Systems must disable services that are not required to achieve the business purpose or function of the system.

17.3 Monitoring Log-in Attempts

1. All access to Production Systems must be logged. This is done following the BroadStreet Auditing Policy.

17.4 Prevention of Malware on Production Systems

1. All Production Systems must have OSSEC running. Detected malware is evaluated and removed.
2. Virus scanning software may be run on Production Systems for anti-virus protection at the discretion of the Security Officer. Presently we have deemed this unnecessary for our Linux production systems due to the low risk of viruses on the Linux platform which is further mitigated by our other security practices.
   • Selected hosts will be scanned daily for malicious binaries in critical system paths.
   • The applicable malware signature database is checked regularly and automatically updated if new signatures are available.
3. All Production Systems are to only be used for BroadStreet business needs.

17.5 Patch Management

1. Software patches and updates will be applied to all systems in a timely manner. In the case of routine updates, they will be applied after thorough testing. In the case of updates to correct known vulnerabilities, priority will be given to testing to speed the time to production. Critical security patches are applied within 30 days from testing and all security patches are applied within 90 days after testing.
   • In the case of PaaS Customers, updates to Application and Database versions are the responsibility of Customers, though BroadStreet will, at it’s own discretion, notify and recommend updates to Customer systems.
2. Administrators ensure that they are using current versions of all BroadStreet-managed software on Production Systems.

17.6 Intrusion Detection and Vulnerability Scanning

1. Production systems are monitored using IDS systems. Suspicious activity is logged and alerts are generated.
2. Vulnerability scanning of Production Systems must occur on a predetermined, regular basis, no less than annually. Scans are reviewed by Security Officer, with defined steps for risk mitigation, and retained for future reference.

17.7 Production System Security

1. System, network, and server security is managed and maintained by the Security Officer in conjunction with the Dev Ops team.
2. Up to date system lists and architecture diagrams are kept for all production environments.
3. Access to Production Systems is controlled using centralized tools.

17.8 Production Data Security

1. Reduce the risk of compromise of Production Data.
2. Implement and/or review controls designed to protect Production Data from improper alteration or destruction.
3. Ensure that confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
4. Ensure BroadStreet Customer Production Data is segmented and only accessible to Customers authorized to access data.
5. All Production Data at rest is stored on encrypted volumes using encryption keys managed by BroadStreet.
6. Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
7. Encrypted volumes use AES encryption with a minimum of 256-bit keys, or keys and ciphers of equivalent or higher cryptographic strength.

17.9 Transmission Security

1. All data transmission is encrypted end to end using encryption keys managed by BroadStreet. Encryption is not terminated at the network end point, and is carried through to the application.
2. Transmission encryption keys and machines that generate keys are protected from unauthorized access. Transmission encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.
3. Transmission encryption keys use a minimum of 2048-bit RSA keys, or keys and ciphers of equivalent or higher cryptographic strength (e.g., 256-bit AES session keys in the case of IPsec encryption).
4. In the case of BroadStreet provided APIs, provide mechanisms to assure person sending or receiving data is authorized to send and save data.
5. System logs of all transmissions of Production Data access. These logs must be available for audit.

18. Data Retention Policy

Despite not being a requirement within HIPAA, BroadStreet understands and appreciates the importance of health data retention. Acting as a subcontractor, and at times a business associate, BroadStreet is not directly responsible for health and medical records retention as set forth by each state. Despite this, BroadStreet has created and implemented the following policy to make it easier for BroadStreet Customers to support data retention laws.

18.1 State Medical Record Laws

• Listing of state requirements for medical record retention

18.2 Data Retention Policy

• Current BroadStreet Customers who have data stored by BroadStreet as a part of the BroadStreet Service.
• Once a Customer ceases to be a Customer, as defined below, the following steps are
  1. Customer is sent a notice via email of change of standing, and given the option to reinstate account.
  2. If no response to notice in #1 above within 7 days, or if Customer responds they do not want to reinstate account, Customer is sent directions for how to download their data from BroadStreet and/or to have BroadStreet continue to store the data at a rate of $25/month for up to 100GB. If there is more than 100GB of data, BroadStreet will work with Customer to determine storage costs.
  3. If Customer downloads data or does not respond to notices from BroadStreet within 30 days, BroadStreet removes data from BroadStreet systems and Customer is sent notice of removal of data.

19. Employees Policy

BroadStreet is committed to ensuring all workforce members actively address security and compliance in their roles at BroadStreet. As such, training is imperative to assuring an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non-compliance.

19.1 Applicable Standards

19.1.1 Applicable Standards from the HITRUST Common Security Framework

• 02.e – Information Security Awareness, Education, and Training
• 06.e – Prevention of Misuse of Information Assets
• 07.c – Acceptable Use of Assets
• 09.j – Controls Against Malicious Code
• 01.y – Teleworking

19.1.2 Applicable Standards from the HIPAA Security Rule

• 164.308(a)(5)(i) – Security Awareness and Training

19.2 Employment Policies

1. All workforce members who have access to ePHI, including contractors, are given training on security policies and procedures, including operations security, within 30 days of employment.
   • Records of training are kept for all workforce members.
   • Current BroadStreet training is hosted at broadstreet.io/hipaa/hipaa-training.
   • Employees must complete this training before accessing production systems containing ePHI.
2. These workforce members are granted access to formal organizational policies, which include the sanction policy for security violations.
3. The BroadStreet Employee Handbook clearly states the responsibilities and acceptable behavior regarding information system usage, including rules for email, Internet, mobile devices, and social media usage.
   • Workforce members are required to sign an agreement stating that they have read and will abide by all terms outlined in the BroadStreet Employee Handbook, along with all policies and processes described in this document.
   • A Human Resources representative will provide the agreement to new employees during their onboarding process.
4. BroadStreet does not allow mobile devices to connect to any of its production networks.
5. These workforce members are educated about the approved set of tools to be installed on workstations.
6. These workforce members are given HIPAA training within 30 days of beginning employment. Training includes HIPAA reporting requirements, including the ability to anonymously report security incidents, and the levels of compliance and obligations for BroadStreet and its Customers and Partners.
   • Current BroadStreet training is hosted at broadstreet.io/hipaa/hipaa-training.
7. These remote (teleworking) workforce members are trained on the risks, the controls implemented, their responsibilities, and sanctions associated with violation of policies. Additionally, remote security is maintained through the use of VPN tunnels for all access to production systems with access to ePHI data.
8. Employees may only use BroadStreet-purchased and -owned workstations for accessing production systems with access to ePHI data.
   • Any workstations used to access production systems must be configured as prescribed in §7.8.
   • Any workstations used to access production systems must have virus protection software installed, configured, and enabled.
   • BroadStreet may monitor access and activities of all users on workstations and production systems in order to meet auditing policy requirements (§8).
9. Access to internal BroadStreet systems can be requested using the procedures outlined in §7.2. All requests for access must be granted by the BroadStreet Security Officer.
10. Request for modifications of access for any BroadStreet employee can be made using the procedures outlined in §7.2.
11. BroadStreet employees are strictly forbidden from downloading any ePHI to their workstations.
    • Restricting transfers of ePHI is enforced through technical controls as described in §7.13.
    • Employees found to be in violation of this policy will be subject to sanctions as described in §5.3.3.
12. Employees are required to cooperate with federal and state investigations.
    • Employees must not interfere with investigations through willful misrepresentation, omission of facts, or by the use of threats against any person.
    • Employees found to be in violation of this policy will be subject to sanctions as described in §5.3.3.

19.3 Issue Escalation

BroadStreet workforce members are to escalate issues using the procedures outlined in the Employee Handbook. Issues that are brought to the Escalation Team are assigned an owner. The membership of the Escalation Team is maintained by the Chief Executive Officer.

Security incidents, particularly those involving ePHI, are handled using the process described in §11.2. If the incident involves a breach of ePHI, the Security Officer will manage the incident using the process described in §12.2. Refer to §11.2 for a list of sample items that can trigger BroadStreet’s incident response procedures; if you are unsure whether the issue is a security incident, contact the Security Officer immediately.

It is the duty of that owner to follow the process outlined below:

1. Create an Issue in the BroadStreet GitLab.
2. The Issue is investigated, documented, and, when a conclusion or remediation is reached, it is moved to Review.
3. The Issue is reviewed by another member. If the Issue is rejected, it goes back for further evaluation and review.
4. If the Issue is approved, it is marked as Done, adding any pertinent notes required.
5. The workforce member that initiated the process is notified of the outcome via email.

20. Approved Tools Policy

BroadStreet utilizes a suite of approved software tools for internal use by workforce members for building and maintaining the BroadStreet SaaS application. These software tools are either self-hosted, with security managed by BroadStreet, or they are hosted by a Subcontractor with appropriate business associate agreements in place to preserve data integrity. Use of other tools requires approval from BroadStreet leadership.

20.1 List of Approved Tools

• GitLab. GitLab is an open source tool built on top of Git, the version control platform. It is utilized for storage of configuration scripts and other infrastructure automation tools, as well as for source and version control of application code used by BroadStreet.
• Dropbox. Dropbox is used for storage of files and sharing of files with Partners and Customers. BroadStreet has executed a BAA with Dropbox.
• Google Apps. Google Apps is used for email and document collaboration. Google Apps is not to be used to store or share ePHI data.

21. 3rd Party Policy

BroadStreet makes every effort to assure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of BroadStreet or BroadStreet Customer data. 3rd Parties include Customers, Partners, Subcontractors, and Contracted Developers.

21.1 Applicable Standards

21.1.1 Applicable Standards from the HITRUST Common Security Framework

• 05.i – Identification of Risks Related to External Parties
• 05.k – Addressing Security in Third Party Agreements
• 09.e – Service Delivery
• 09.f – Monitoring and Review of Third Party Services
• 09.g – Managing Changes to Third Party Services
• 10.1 – Outsourced Software Development

21.1.2 Applicable Standards from the HIPAA Security Rule

• 164.314(a)(1)(i) – Business Associate Contracts or Other Arrangements

21.2 Policies to Assure 3rd Parties Support BroadStreet Compliance

1. BroadStreet does not allow 3rd party access to production systems containing ePHI.
2. All connections and data in transit between the BroadStreet Platform and 3rd parties are encrypted end to end.
3. A standard business associate agreement with Customers and Partners is defined and includes the required security controls in accordance with the organization’s security policies. Additionally, responsibility is assigned in these agreements.
4. No BroadStreet Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
5. Any changes to Partner and Subcontractor services and systems are reviewed before implementation.

22. Key Definitions

• Application: An application hosted by BroadStreet, either maintained and created by BroadStreet, or maintained and created by a Customer or Partner.

• Application Level: Controls and security associated with an Application. In the case of SaaS Customers, BroadStreet does not have access to and cannot assure compliance with security standards and policies at the Application Level.

• Audit: Internal process of reviewing information system access and activity (e.g., log-ins, file accesses, and security incidents). An audit may be done as a periodic event, as a result of a patient complaint, or suspicion of employee wrongdoing.

• Audit Controls: Technical mechanisms that track and record computer/system activities.

• Audit Logs: Encrypted records of activity maintained by the system which provide: 1) date and time of activity; 2) origin of activity (app); 3) identification of user doing activity; and 4) data accessed as part of activity.

• Access: Means the ability or the means necessary to read, write, modify, or communicate data/ information or otherwise use any system resource.

• BaaS: Backend-as-a-Service. A set of APIs, and associated SDKs, for rapid mobile and web application development. APIs offer the ability to create users, do authentication, store data, and store files.

• Backup: The process of making an electronic copy of data stored in a computer system. This can either be complete, meaning all data and programs, or incremental, including just the data that changed from the previous backup.

• Backup Service: A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them. Offered with all BroadStreet Add-ons and as an option for SaaS Customers.

• Breach: Means the acquisition, access, use, or disclosure of protected health information (PHI) in a manner not permitted under the Privacy Rule which compromises the security or privacy of the PHI. For purpose of this definition, “compromises the security or privacy of the PHI” means poses a significant risk of financial, reputational, or other harm to the individual. A use or disclosure of PHI that does not include the identifiers listed at §164.514(e)(2), limited data set, date of birth, and zip code does not compromise the security or privacy of the PHI. Breach excludes:

  1. Any unintentional acquisition, access or use of PHI by a workforce member or person acting under the authority of a Covered Entity (CE) or Business Associate (BA) if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted under the Privacy Rule.
  2. Any inadvertent disclosure by a person who is authorized to access PHI at a CE or BA to another person authorized to access PHI at the same CE or BA, or organized health care arrangement in which the CE participates, and the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under the Privacy Rule.
  3. A disclosure of PHI where a CE or BA has a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information.

• Business Associate: A person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.

• Covered Entity: A health plan, health care clearinghouse, or a healthcare provider who transmits any health information in electronic form.

• De-identification: The process of removing identifiable information so that data is rendered to not be PHI.

• Disaster Recovery: The ability to recover a system and data after being made unavailable.

• Disaster Recovery Service: A disaster recovery service for disaster recovery in the case of system unavailability. This includes both the technical and the non-technical (process) required to effectively stand up an application after an outage. Offered with all BroadStreet Add-ons and as an option for SaaS Customers.

• Disclosure: Disclosure means the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.

• Customers: Contractually bound users of BroadStreet Platform.

• Electronic Protected Health Information (ePHI): Any individually identifiable health information protected by HIPAA that is transmitted by, processed in some way, or stored in electronic media.

• Environment: The overall technical environment, including all servers, network devices, and applications.

• Event: An event is defined as an occurrence that does not constitute a serious adverse effect on BroadStreet, its operations, or its Customers, though it may be less than optimal. Examples of events include, but are not limited to:
  • A hard drive malfunction that requires replacement;
  • Systems become unavailable due to power outage that is non-hostile in nature, with redundancy to assure ongoing availability of data;
  • Accidental lockout of an account due to incorrectly entering a password multiple times.

• Hardware (or hard drive): Any computing device able to create and store ePHI.

• Health and Human Services (HHS): The government body that maintains HIPAA.

• Individually Identifiable Health Information: That information that is a subset of health information, including demographic information collected from an individual, and is created or received by a health care provider, health plan, employer, or health care clearinghouse; and relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual; and identifies the individual; or with respect to which there is a reasonable basis to believe the information can be used to identify the individual.

• Indication: A sign that an Incident may have occurred or may be occurring at the present time. Examples of indications include:
  • The network intrusion detection sensor alerts when a known exploit occurs against an FTP server. Intrusion detection is generally reactive, looking only for footprints of known attacks. It is important to note that many IDS “hits” are also false positives and are neither an event nor an incident;
  • The antivirus software alerts when it detects that a host is infected with a worm;
  • Users complain of slow access to hosts on the Internet;
  • The system administrator sees a filename with unusual characteristics;
  • Automated alerts of activity from log monitors like OSSEC;
  • An alert from OSSEC about file system integrity issues.

• Intrusion Detection System (IDS): A software tool use to automatically detect and notify in the event of possible unauthorized network and/or system access.

• IDS Service: An Intrusion Detection Service for providing IDS notification to customers in the case of suspicious activity. Offered with all BroadStreet Add-ons and as an option for SaaS Customers.

• Law Enforcement Official: Any officer or employee of an agency or authority of the United States, a State, a territory, a political subdivision of a State or territory, or an Indian tribe, who is empowered by law to investigate or conduct an official inquiry into a potential violation of law; or prosecute or otherwise conduct a criminal, civil, or administrative proceeding arising from an alleged violation of law.

• Logging Service: A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them. Offered with all BroadStreet Add-ons and as an option for SaaS Customers.

• Messaging: API-based services to deliver and receive SMS messages.

• Minimum Necessary Information: Protected health information that is the minimum necessary to accomplish the intended purpose of the use, disclosure, or request. The “minimum necessary” standard applies to all protected health information in any form.

• Off-Site: For the purpose of storage of Backup media, off-site is defined as any location separate from the building in which the backup was created. It must be physically separate from the creating site.

• Organization: For the purposes of this policy, the term “organization” shall mean BroadStreet.

• Partner: Contractual bound 3rd party vendor with integration with the BroadStreet Platform. May offer Add-on services.

• Platform: The overall technical environment of BroadStreet.

• Protected Health Information (PHI): Individually identifiable health information that is created by or received by the organization, including demographic information, that identifies an individual, or provides a reasonable basis to believe the information can be used to identify an individual, and relates to:
  • Past, present or future physical or mental health or condition of an individual.
  • The provision of health care to an individual.
  • The past, present, or future payment for the provision of health care to an individual.

• Role: The category or class of person or persons doing a type of job, defined by a set of similar or identical responsibilities.

• Sanitization: Removal or the act of overwriting data to a point of preventing the recovery of the data on the device or media that is being sanitized. Sanitization is typically done before re-issuing a device or media, donating equipment that contained sensitive information or returning leased equipment to the lending company.

• Trigger Event: Activities that may be indicative of a security breach that require further investigation (See Appendix).

• Restricted Area: Those areas of the building(s) where protected health information and/or sensitive organizational information is stored, utilized, or accessible at any time.

• Role: The category or class of person or persons doing a type of job, defined by a set of similar or identical responsibilities.

• Precursor: A sign that an Incident may occur in the future. Examples of precursors include:
  • Suspicious network and host-based IDS events/attacks;
  • Alerts as a result of detecting malicious code at the network and host levels;
  • Alerts from file integrity checking software;
  • Audit log alerts.

• Risk: The likelihood that a threat will exploit a vulnerability, and the impact of that event on the confidentiality, availability, and integrity of ePHI, other confidential or proprietary electronic information, and other system assets.

• Risk Management Team: Individuals who are knowledgeable about the Organization’s HIPAA Privacy, Security and HITECH policies, procedures, training program, computer system set up, and technical security controls, and who are responsible for the risk management process and procedures outlined below.

• Risk Assessment: (Referred to as Risk Analysis in the HIPAA Security Rule); the process:
  • Identifies the risks to information system security and determines the probability of occurrence and the resulting impact for each threat/vulnerability pair identified given the security controls in place;
  • Prioritizes risks; and
  • Results in recommended possible actions/controls that could reduce or offset the determined risk.

• Risk Management: Within this policy, it refers to two major process components: risk assessment and risk mitigation. This differs from the HIPAA Security Rule, which defines it as a risk mitigation process only. The definition used in this policy is consistent with the one used in documents published by the National Institute of Standards and Technology (NIST).

• Risk Mitigation: Referred to as Risk Management in the HIPAA Security Rule, and is a process that prioritizes, evaluates, and implements security controls that will reduce or offset the risks determined in the risk assessment process to satisfactory levels within an organization given its mission and available resources.

• SaaS: Software as a service (or SaaS; pronounced /sæs/ is a method of delivering centrally hosted applications over the Internet—as a service. SaaS applications are sometimes called web-based software, on-demand software, or hosted software. In essence, SaaS applications run on a SaaS provider’s servers.

• Security Incident (or just Incident): A security incident is an occurrence that exercises a significant adverse effect on people, process, technology, or data. Security incidents include, but are not limited to:
  • A system or network breach accomplished by an internal or external entity; this breach can be inadvertent or malicious;
  • Unauthorized disclosure;
  • Unauthorized change or destruction of ePHI (i.e. delete dictation, data alterations not following BroadStreet’s procedures);
  • Denial of service not attributable to identifiable physical, environmental, human or technology causes;
  • Disaster or enacted threat to business continuity;
  • Information Security Incident: A violation or imminent threat of violation of information security policies, acceptable use policies, or standard security practices. Examples of information security incidents may include, but are not limited to, the following:
  • Denial of Service: An attack that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources;
  • Malicious Code: A virus, worm, Trojan horse, or other code-based malicious entity that infects a host;
  • Unauthorized Access/System Hijacking: A person gains logical or physical access without permission to a network, system, application, data, or other resource. Hijacking occurs when an attacker takes control of network devices or workstations;
  • Inappropriate Usage: A person violates acceptable computing use policies;
  • Other examples of observable information security incidents may include, but are not limited to:
    • Use of another person’s individual password and/or account to login to a system;
    • Failure to protect passwords and/or access codes (e.g., posting passwords on equipment);
    • Installation of unauthorized software;
    • Terminated workforce member accessing applications, systems, or network.
• Threat: The potential for a particular threat-source to successfully exercise a particular vulnerability. Threats are commonly categorized as:
  • Environmental – external fires, HVAC failure/temperature inadequacy, water pipe burst, power failure/fluctuation, etc.
  • Human – hackers, data entry, workforce/ex-workforce members, impersonation, insertion of malicious code, theft, viruses, SPAM, vandalism, etc.
  • Natural – fires, floods, electrical storms, tornados, etc.
  • Technological – server failure, software failure, ancillary equipment failure, etc. and environmental threats, such as power outages, hazardous material spills.
  • Other – explosions, medical emergencies, misuse or resources, etc.

• Threat Source: Any circumstance or event with the potential to cause harm (intentional or unintentional) to an IT system. Common threat sources can be natural, human or environmental which can impact the organization’s ability to protect ePHI.

• Threat Action: The method by which an attack might be carried out (e.g., hacking, system intrusion, etc.).

• Unrestricted Area: Those areas of the building(s) where protected health information and/or sensitive organizational information is not stored or is not utilized or is not accessible there on a regular basis.

• Unsecured Protected Health Information: Protected health information (PHI) that is not rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Pub. L.111-5 on the HHS website.
  1. Electronic PHI has been encrypted as specified in the HIPAA Security rule by the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without the use of a confidential process or key and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt. The following encryption processes meet this standard.
  2. Valid encryption processes for data at rest (i.e. data that resides in databases, file systems and other structured storage systems) are consistent with NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.
  3. Valid encryption processes for data in motion (i.e. data that is moving through a network, including wireless transmission) are those that comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPSec VPNs; or 800-113, Guide to SSL VPNs, and may include others which are Federal Information Processing Standards FIPS 140-2 validated.
  4. The media on which the PHI is stored or recorded has been destroyed in the following ways:
  5. Paper, film, or other hard copy media have been shredded or destroyed such that the PHI cannot be read or otherwise cannot be reconstructed. Redaction is specifically excluded as a means of data destruction.
  6. Electronic media have been cleared, purged, or destroyed consistent with NIST Special Publications 800-88, Guidelines for Media Sanitization, such that the PHI cannot be retrieved.

• Vendors: Persons from other organizations marketing or selling products or services, or providing services to BroadStreet.

• Vulnerability: A weakness or flaw in an information system that can be accidentally triggered or intentionally exploited by a threat and lead to a compromise in the integrity of that system, i.e., resulting in a security breach or violation of policy.

• Workstation: An electronic computing device, such as a laptop or desktop computer, or any other device that performs similar functions, used to create, receive, maintain, or transmit ePHI. Workstation devices may include, but are not limited to: laptop or desktop computers, personal digital assistants (PDAs), tablet PCs, and other handheld devices. For the purposes of this policy, “workstation” also includes the combination of hardware, operating system, application software, and network connection.

• Workforce: Means employees, volunteers, trainees, and other persons whose conduct, in the performance of work for a covered entity, is under the direct control of such entity, whether or not they are paid by the covered entity.

23. BroadStreet HIPAA Business Associate Agreement (“BAA”)

This Business Associate Agreement (“BAA”) is made and entered into by and between Customer ________________ and Broadstreet LL (“Company”). This BAA is issued in connection with the Master Agreement between Customer and Company (“Agreement”). Except as expressly set forth in this BAA, the Agreement remains unmodified and in full force and effect. In case of a conflict between this BAA and the Agreement, this BAA shall control. Customer and Company are entering into this BAA for the purpose of implementing the requirements of HIPAA (defined below) and supporting the parties’ compliance requirements thereunder in connection with the services provided under the Agreement. Together with the Agreement, this BAA will govern each party’s respective obligations regarding Protected Health Information (defined below) in connection with the Agreement. This BAA supersedes in its entirety any pre-existing BAA executed by the parties covering the Agreement. The parties agree as follows:

1. Definitions For purposes of this BAA, any capitalized terms not otherwise defined herein will have the meaning given to them in the Agreement or HIPAA.

   • “Covered Entity” has the meaning given to it under HIPAA
   • “HIPAA” means the Health Insurance Portability and Accountability Act of 1996 and the rules and the regulations thereunder, as amended (including with respect to the HITECH Act).
   • “HITECH Act” means the Health Information Technology for Economic and Clinical Health Act enacted in the United States Congress, which is Title XIII of the American Recovery & Reinvestment Act, and the regulations thereunder, as amended.
   • “Protected Health Information” or “PHI” will have the meaning given to it under HIPAA.
   • “Security Rule” means 45 C.F.R., Part 164, Subpart C, under HIPAA.

2. Applicability

This BAA applies to the extent Company is acting as a Business Associate, to create, receive, maintain or transmit PHI between itself and Customer, and where Customer is deemed under HIPAA to be acting as a Business Associate of its customers. Company is contractually obligated to the Covered Entities to protect and secure Protected Health Information in accordance with HIPAA and the terms of Company agreements with the Covered Entities. This BAA governs Company and Customer’s receipt, use, creation and storage of PHI and supplements as required in order to allow both parties to comply with HIPAA. Except as so supplemented and/or amended, the terms of the Agreement shall continue unchanged and shall apply with full force and effect to govern the matters addressed in this BAA and in the Agreement.

3. Permitted Use and Disclosure
   1. By Company. Company may use and disclose PHI only as permitted under HIPAA, Subparts C and E of 45 CFR Part 164, and as specified in the Agreement and this BAA. Company may also use and disclose PHI for the proper management and administration of its business and to carry out its legal responsibilities, provided that any disclosure of PHI for such purpose may only occur if (i) required by applicable law, or (ii) Company obtains written reasonable assurances from the person to whom PHI will be disclosed that it will be held in confidence, used only for the purpose for which it was disclosed and that Company will be promptly notified of any Breach.
   2. By Customer. Customer will neither request nor require Company to use or disclose PHI in any manner that would not be permissible under HIPAA (unless otherwise expressly permitted under HIPAA for a Business Associate). Customer will also take appropriate measures to limit its use or disclosure of PHI to Company to the minimum extent necessary for Company to carry out its authorized use of such PHI. Customer agrees that Company has no obligation to protect PHI under this BAA to the extent Company creates, receives, maintains or transmits such PHI outside of the scope of the Agreement.

4. Appropriate Safeguards The parties will use appropriate safeguards designed to prevent against unauthorized use or disclosure of PHI and protect the integrity of PHI and availability of PHI, consistent with this BAA, and as otherwise required under the Security Rule and Subpart C of 45 CFR Part 164, in connection with the Agreement.

5. Reporting Unless otherwise consistent with the legitimate needs of applicable law enforcement and applicable laws in accordance with 45 CFR 164.410, Company will promptly notify Customer within ten (10) days following the discovery of a Breach resulting in the unauthorized use or disclosure of PHI in violation of this BAA or the Agreement in accordance with 45 CFR 164.410, Further, such notice shall occur only after taking any measures necessary to determine the scope of the Breach and to restore the reasonable integrity of the Company Services by using commercially reasonable efforts to mitigate any further harmful effects to the extent practicable. Company agrees to maintain records of all Security Incidents and provide notice to Customer of successful Security Incidents pursuant to 45 C.F.R. 164.314 or as otherwise provided for in the Agreement or this BAA.

6. Agents and Subcontractors Company will take appropriate measures to ensure that any agents and subcontractors used by Company to perform its obligations under the Agreement that require access to PHI on behalf of Company are bound by written obligations that provide the same material level of protection for PHI as this BAA and the Agreement, and in accordance with 45 CFR Parts 164.502(e)(1)(ii) and 164.308(b)(2).

7. Accounting Rights Company will make available to Customer PHI in a Designated Record Set as necessary so Customer may fulfill its obligation to its customers to give individuals their rights of access, amendment and accounting in accordance with HIPAA, HITECH and 45 CFR Parts 164.524, 164.526 and 164.528 (including without limitation a disclosure permitted under 45 CFR 164.512).

8. Access to Records To the extent required by law, and subject to applicable attorney client privileges, Company will make its internal practices, books and records concerning the use and disclosure of PHI received from Customer, or created or received by Company on behalf of Customer, available to the Secretary of the U.S. Department of Health and Human Services (the “Secretary”) for the purpose of the Secretary determining compliance with this BAA.

9. Return/Destruction of Information Company agrees that upon termination of the Agreement or upon Customer’ request, Company will destroy all PHI received from Customer, or created or received by Company on behalf of Customer, which Company still maintains in accordance with the Agreement; provided, however, that if such destruction is not feasible, Company will so notify Customer and extend the protections of this BAA to the PHI not destroyed and limit further uses and disclosures to those purposes that make the destruction of the PHI infeasible. In the event this BAA is terminated earlier than the Agreement, Company must delete any PHI it maintains and cease to create, receive, maintain or transmit such PHI.

10. Breach/Cure Customer may immediately terminate this BAA and the Agreement upon thirty (30) days written notice to Company if Company has materially breached this BAA and such breach has not been cured within such thirty (30) days.

11. Term This BAA will expire upon the earlier of: (i) a permitted termination in accordance with this BAA, (ii) the natural expiration or termination of the Agreement between the parties, or (ii) the execution of an updated BAA that supersedes this BAA.

12. Miscellaneous.

    1. Interpretation. The terms of this BAA shall prevail in the case of any conflict with the terms of the Agreement.

    2. Survival. Notwithstanding any other provision of this BAA to the contrary, the terms of sections 1, 2, 3, 6, 9 and 12 of this BAA shall survive termination of this BAA and continue indefinitely solely with respect to PHI Company retains in accordance with this BAA.

    3. No Third Party Beneficiaries. Nothing in this BAA shall confer upon any person other than the Parties and their respective successors or assigns, any rights, remedies, obligations, or liabilities whatsoever.

    4. Policies and Procedures. Company agrees to maintain policies and procedures governing the protection of PHI and provide, upon Customer’ request, access to and copies of any such policies and procedures.

    5. Subpoenas. Company agrees to provide notice to Customer of any subpoena or other legal process seeking PHI received from or created on behalf of Customer, or otherwise relating to Company’s services, duties and obligations under the Company Agreement and/or the BAA. Such notice shall be provided within forty-eight (48) hours of Company’s receipt of such subpoena or legal process.

IN WITNESS WHEREOF, each of the undersigned has caused this BAA to be executed in its name and on its behalf by its duly authorized representative.

BroadStreet, LLC	Customer
By:_____________________	By:_____________________
Name:_____________________	Name:_____________________
Title:_____________________	Title:_____________________
Date:_____________________	Date:_____________________

24. HIPAA Mappings to BroadStreet Controls

Below is a list of HIPAA Safeguards and Requirements and the BroadStreet controls in place to meet those.

Standards	HIPAA & HITECH Sections	Implementation Specifications (R)=Required, (A)=Addressable	BroadStreet Sections
Administrative Safeguards
Security Management Process	164.308(a)(1)(i)	Risk Analysis (R)	4 – Risk Management Policy
		Risk Management (R)	4 – Risk Management Policy
		Sanction Policy (R)	5 – Roles Policy
		Information System Activity Review (R)	4.5 – Auditing Customer and Partner Activity
Assigned Security Responsibility	164.308(a)(2)	(R)	5 – Roles Policy
Workforce Security	164.308(a)(3)	Workforce Security Authorization and/or Supervision (A)	19 – Employee Policy
		Workforce Clearance Procedure (A)	19 – Employee Policy
		Termination Procedures (A)	19 – Employee Policy
Information Access Management	164.308(a)(4)	Isolating Health care Clearinghouse Function (R)	7 – System Access Policy
		Access Authorization (A)	7 – System Access Policy
		Access Establishment and Modification (A)	7 – System Access Policy
Security Awareness Training	164.308(a)(5)	Security Reminders (A)	19 – Employee Policy
		Protection from Malicious Software (A)	19 – Employee Policy
		Log-in Monitoring (A)	19 – Employee Policy
		Password Management (A)	19 – Employee Policy
Security Incident Procedures	164.308(a)(6)	Response and Reporting (R)	15 – IDS Policy
Contingency Plan	164.308(a)(7)	Data Backup Plan (R)	13 – Disaster Recovery Policy
		Disaster Recovery Plan (R)	13 – Disaster Recovery Policy
		Emergency Mode Operation Plan (R)	13 – Disaster Recovery Policy
		Testing and Revision Procedure (A)	13 – Disaster Recovery Policy
		Applications and Data Criticality Analysis (A)	13 – Disaster Recovery Policy
Evaluation	164.308(a)(8)	(R)	8 – Auditing Policy
Business Associate Contracts and Other Arrangement	164.308(b)(1); 164.314(a)(1)(i)	Written Contract or Other Arrangement	23 – BroadStreet HIPAA-Business Associate Agreement BAA
Physical Safeguards
Facility Access Controls	164.310(a)(1)	Contingency Operations (A)	10 – Facility Access Policy & 13 – Disaster Recovery Policy
		Facility Security Plan (A)	10 – Facility Access Policy & 13 – Disaster Recovery Policy
		Access Control and Validation Procedures (A)	10 – Facility Access Policy & 13 – Disaster Recovery Policy
		Maintenance Records (A)	10 – Facility Access & 13 – Disaster Recovery Policies
Workstation Use	164.310(b)	(R)	13 – System Access, 20 – Approved Tools, and 19 – Employee Policies
Workstation Security	164.310(c)	(R)	13 – System Access, 20 – Approved Tools, and 19 – Employee Policies
Device and Media Controls	164.310(d)(1)	Disposal (R)	14 – Disposable Media & 6 – Data Management Policies
		Media Re-use	14 – Disposable Media & 6 – Data Management Policies
		Accountability (A)	14 – Disposable Media & 6 – Data Management Policies
		Data Backup (A)	14 – Disposable Media & 6 – Data Management Policies
Technical Safeguards
Access Control	164.312(a)(1)	Unique User Identification (R)	7 – System Access Policy
		Emergency Access Procedure (R)	13 – Disaster Recovery Policy
		Automatic Logoff (A)	7 – System Access Policy
		Encryption and Decryption (A)	7 – System Access Policy
Audit Controls	164.312(b)	(R)	8 – Audit Policy
Integrity	164.312(c)(1)	Mechanism to Authenticate Electronic Protected Health Information (A)	7 – System Access, 8 – Auditing & 15 – IDS Policies
Person or Entity Authentication	164.312(d)	(R)	7 – System Access Policy
Transmission Security	164.312(e)(1)	Integrity Controls (A)	7 – System Access & 6 – Data Management Policies
		Encryption (A)	7 – System Access & 6 – Data Management Policies
Other
Policies and Procedures and Documentation Requirements	164.316(a); 164.316(b)(1)(i)	Time Limit (R)	3 – Policy Management Policy
		Availability (R)	3 – Policy Management Policy
		Updates (R)	3 – Policy Management Policy
HITECH Act – Security Provisions HIPAA Rule
Security Management Process	13402(a) & (b); 13402(d)(1); 13402(f)(1)	Risk Analysis (R)	12 – Breach Policy
		Risk Management (R)	12 – Breach Policy
		Sanction Policy (R)	12 – Breach Policy