Legal Documentation
Terms and Policies:
HIPAA:
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.
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.).
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.
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.
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.
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.
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 |
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.
Additional documentation related to maintenance of policies is outlined in §5.3.1.
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.
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.
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.
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:
Maintain documentation of all risk assessment, risk management, and risk mitigation efforts for a minimum of six years.
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.
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/.
The current BroadStreet Privacy Officers are Tom Schmitt (tom@broadstreet.io) and Tracy Flood (tracy@broadstreet.io).
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).
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:
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.
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.
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.
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:
sudo
to perform privileged tasks.The following items apply to any workstations owned by BroadStreet.
BroadStreet does not use paper records for any sensitive information. Use of paper for recording and storing sensitive data is against BroadStreet policies.
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.
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.
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:
This policy applies to all BroadStreet Add-on systems that store, transmit, or process ePHI.
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:
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).
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.
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.
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.
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.).
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.
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.
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.
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:
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.
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:
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.
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.
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).
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.
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.
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.
Current members of the BroadStreet SIRT:
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.
[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:
Other Optional Considerations:
We will assist you in remedying the situation.
Sincerely,
James Walters
Co-founder – BroadStreet LLC
james@broadstreet.io
414-555-1234
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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.
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 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.
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.
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.
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:
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
Miscellaneous.
Interpretation. The terms of this BAA shall prevail in the case of any conflict with the terms of the Agreement.
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.
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.
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.
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:_____________________ |
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 |
© 2023 BroadStreet