Source: https://policy.spokehealth.com/
Timestamp: 2019-04-25 23:46:06+00:00

Document:
Spoke delivers a best-in-class surgery savings and patient concierge program, designed to improve the lives of patients and their families while also reducing the cost of health care. As a result, Spoke as well as the individuals and entities with which it interacts, are entrusted with the protection of confidential information including Protected Health Information (“PHI”).
The purpose of this policy document is to establish requirements for proper handling of PHI through the adoption of the policies and processes outlined in this document, as updated as required to ensure compliance with changes to federal and state regulations. Such a process is required as a means of managing the privacy and security of PHI under the HIPAA Privacy Rule and HIPAA Security Rule §164.308(a)(1), and to comply with any other applicable information security regulations and protect the overall security of the organization. The process includes analysis and management of risks, implementation of secure systems and applications, the use of security incident procedures to learn from prior issues, information system usage audits and activity reviews, regular security evaluations and regulation compliance assessments, training for all staff using electronic information systems, and documentation of compliance activities.
This policy document defines common security requirements for all Spoke personnel and systems that create, maintain, store, access, process or transmit information. This policy also applies to information resources owned by others, such as contractors, vendors and partners, in cases where Spoke has a legal, contractual or fiduciary duty to protect said resources while in Spoke custody. In the event of a conflict, the more restrictive measures apply.
The policy requirements and restrictions defined in this document shall apply to network infrastructures, databases, external media, encryption, hardcopy reports, films, slides, models, wireless, telecommunication, conversations, and any other methods used to store and convey knowledge and ideas across all hardware, software, and data transmission mechanisms, as well as the general handling of PHI by individuals. This policy must be adhered to by all Spoke employees or temporary workers at all locations and by Spoke’s contractors, vendors, and partners.
Each of the policies defined in this document is applicable to the task being performed – not just to specific departments or job titles.
Spoke provides a surgery-savings and concierge program to payers and health plan sponsors. The program is built on a proprietary technology platform and utilizes an online patient portal for patient engagement and support. The platform sources data from clients regarding plan members, from surgery providers regarding bundled surgery rates, and from patients who are considering opting into Spoke’s program. The online patient portal provides an interactive environment through which Spoke presents provider options to patients for their consideration.
Spoke 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 ensuring all Spoke 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.
All policies are stored and up to date to maintain Spoke compliance with HIPAA, HITRUST, and other relevant standards. Updates and version control are done similar to source code control.
Policy update requests can be made by any workforce member at any time. Furthermore, all policies are reviewed annually by both the Security and Privacy Officer to assure they are accurate and up-to-date.
The Spoke employee initiates a policy change request by creating an Issue in the JIRA Employee Access project.
The Security Officer or the Privacy Officer is assigned to review the policy change request.
Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel using Spoke’s change management process.
All policies are made accessible to all Spoke workforce members. The current master policies are contained in Spoke’s Information Security Policies published at https://policy.spokehealth.com.
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.
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.
Version history of all Spoke policies is done via Google Docs.
The Security Officer initiates the policy review by creating an Issue in the JIRA Employee Access project.
The Security Officer or the Privacy Officer is assigned to review the current Spoke Information Security Polices (https://policy.spokehealth.com/).
If changes are made, the above process is used. All changes are documented in the Issue.
Policy review is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
The Security Officer initiates the HITRUST self-assessment activity by creating an Issue in the JIRA Employee Access project.
The Security Officer or the Privacy Officer is assigned to own and manage the HITRUST self-assessment activity.
Once the HITRUST self-assessment activity is completed, the Security Officer approves or rejects the Issue.
Additional documentation related to maintenance of policies is outlined in §1.2, Maintenance of Policies.
This policy establishes the scope, objectives, and procedures of Spoke’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.
It is the policy of Spoke 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 Spoke’s information security program.
Risk analysis and risk management are recognized as important components of Spoke’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).
All of these policies apply both to internal Spoke resources, as well as subcontractors, partners and vendors.
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 Spoke Platform.
Spoke 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.
Any risk remaining (residual) after other risk controls have been applied, requires sign off by the senior management and Spoke’s Security Officer.
All Spoke 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 Spoke Roles Policy.
The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of Spoke’s Security Officer (or other designated employee), and the identified Risk Management Team.
Step 1. The Security Officer or the Privacy Officer initiates the Risk Management Procedures by creating an Issue in the JIRA Employee Access Project.
Step 2. The Security Officer or the Privacy Officer is assigned to carry out the Risk Management Procedures.
Step 3. All findings are documented in approved spreadsheet that is linked to the Issue.
Step 4. Once the Risk Management Procedures are complete, along with corresponding documentation, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
Step 5. If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
The Risk Management Procedure is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
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.
The first step in assessing risk is to define the scope of the effort. To do this, identify where ePHI is received, maintained, processed, or transmitted. Using information-gathering techniques, the Spoke Platform boundaries are identified.Output – Characterization of the Spoke Platform system assessed, a good picture of the Platform environment, and delineation of Platform boundaries.
Potential threats (the potential for threat-sources to successfully exercise a particular vulnerability) are identified and documented. All potential threat-sources through the review of historical incidents and data from intelligence agencies, the government, etc., to help generate a list of potential threats.Output – A threat list containing a list of threat-sources that could exploit Platform vulnerabilities.
Develop a list of technical and non-technical Platform vulnerabilities that could be exploited or triggered by potential threat-sources. Vulnerabilities can range from incomplete or conflicting policies that govern an organization’s computer usage to insufficient safeguards to protect facilities that house computer equipment to individuals within the organization to any number of software, hardware, or other deficiencies that comprise an organization’s computer network.Output – A list of the Platform vulnerabilities (observations) that could be exercised by potential threat-sources.
Document and assess the effectiveness of technical and non-technical controls that have been or will be implemented by Spoke to minimize or eliminate the likelihood / probability of a threat-source exploiting a Platform vulnerability.Output – List of current or planned controls (policies, procedures, training, technical mechanisms, insurance, etc.) used for the Platform to mitigate the likelihood of a vulnerability being exercised and reduce the impact of such an adverse event.
Determine the overall likelihood rating that indicates the probability that a vulnerability could be exploited by a threat-source given the existing or planned security controls.Output – Likelihood rating of low (.1), medium (.5), or high (1). Refer to the NIST SP 800-30 definitions of low, medium, and high.
Determine the level of adverse impact that would result from a threat successfully exploiting a vulnerability. Factors of the data and systems to consider should include the importance to Spoke’s mission; sensitivity and criticality (value or importance); costs associated; loss of confidentiality, integrity, and availability of systems and data.Output – Magnitude of impact rating of low (10), medium (50), or high (100). Refer to the NIST SP 800-30 definitions of low, medium, and high.
Establish a risk level. By multiplying the ratings from the likelihood determination and impact analysis, a risk level is determined. This represents the degree or level of risk to which an IT system, facility, or procedure might be exposed if a given vulnerability were exercised. The risk rating also presents actions that senior management must take for each risk level.Output – Risk level of low (1-10), medium (>10-50) or high (>50-100). Refer to the NIST SP 800-30 definitions of low, medium, and high.
Identify controls that could reduce or eliminate the identified risks, as appropriate to the organization’s operations to an acceptable level. Factors to consider when developing controls may include effectiveness of recommended options (i.e., system compatibility), legislation and regulation, organizational policy, operational impact, and safety and reliability. Control recommendations provide input to the risk mitigation process, during which the recommended procedural and technical security controls are evaluated, prioritized, and implemented.Output – Recommendation of control(s) and alternative solutions to mitigate risk.
Results of the risk assessment are documented in an official report, spreadsheet, or briefing and provided to senior management to make decisions on policy, procedure, budget, and Platform operational and management changes.Output – A risk assessment report that describes the threats and vulnerabilities, measures the risk, and provides recommendations for control implementation.
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 Spoke Platform ePHI. Determination of appropriate controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission.
Taking into account the information and results from previous steps, Spoke’s mission, and other important criteria, the Risk Management Team determines the best control(s) for reducing risks to the information systems and to the confidentiality, integrity, and availability of ePHI. These controls may consist of a mix of administrative, physical, and/or technical safeguards.
The overall implementation plan provides a broad overview of the safeguard implementation, identifying important milestones and timeframes, resource requirements (staff and other individual’s time, budget, etc.), interrelationships between projects, and any other relevant information. Regular status reporting of the plan, along with key metrics and success indicators should be reported to Spoke Senior Management.
An overall risk assessment of Spoke’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.
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.
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 Spoke’s Platform.
Spoke has a Security Officer appointed to assist in maintaining and enforcing safeguards towards compliance. The responsibilities associated with these roles are outlined below.
Manage relationships with customers, vendors and partners as those relationships affect security and compliance of ePHI.
The current Spoke Privacy Officer is Greg Mogab (greg@spokehealth.com).
Existing workforce members as needed due to changes in security and risk posture of Spoke.
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 Spoke security policies and non-compliance with the security regulations 164.308(a)(1)(ii)(c), and writing, implementing, and maintaining all policies, procedures, and documentation related to efforts toward security and compliance 164.316(a-b).
The current Spoke Security Officer is Richard Coyte (richard@spokehealth.com).
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.
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 Spoke infrastructure.
Develops and maintains an overall strategic security plan.
Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of Spoke.
Mitigates, to the extent practicable, any harmful effect known to Spoke of a use or disclosure of ePHI in violation of Spoke’s policies and procedures, even if effect is the result of actions of Spoke business associates, customers, and/or partners.
Reports security efforts and incidents to administration immediately upon discovery.
Works with the COO to ensure that any security objectives have appropriate consideration during the budgeting process.
In general, security and compliance are core to Spoke’s technology and service offerings; in most cases this means security-related objectives cannot be split out to separate budget line items.
For cases that can be split out into discrete items, such as licenses for commercial tooling, the Security Officer follows Spoke’s standard corporate budgeting process.
At the beginning of every fiscal year, the COO contacts the Security Officer to plan for the upcoming year’s expenses.
The Security Officer works with the COO to forecast spending needs based on the previous year’s level, along with changes for the upcoming year such as additional staff hires.
During the year, if an unforeseen security-related expense arises that was not in the budget forecast, the Security Officer works with the COO to reallocate any resources as necessary to cover this expense.
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 Spoke’s systems, applications, servers, workstations, etc. that contain ePHI.
Take all reasonable steps to hire, retain, and promote workforce members and provide access to users who comply with the Security regulation and Spoke’s security policies and procedures.
All workforce members report non-compliance of Spoke’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. The Security Officer promptly facilitates a thorough investigation of all reported violations of Spoke’s security policies and procedures.
The Security Officer may request the assistance from others.
thoroughly document the investigation as the investigation occurs. This documentation must include a list of all employees involved in the violation.
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. Spoke workforce members are encouraged to come forward with information about insider threats, and can do so anonymously.
Spoke has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) stored in conjunction with Datica utilizing Datica’s Backup Service. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by Spoke.
Data backup is an important part of the day-to-day operations of Spoke. To protect the confidentiality, integrity, and availability of ePHI, both for Spoke and Spoke Customers, complete backups are done daily to assure that data remains available when it needed and in case of a disaster.
Perform daily snapshot backups of all systems that process, store, or transmit ePHI.
Spoke Ops Team, lead by VP of Engineering, is designated to be in charge of backups.
Spoke’s policies regarding paper records is included in Spoke’s Employee Handbook (https://employees.spokehealth.com).
Spoke’s policies regarding the use of fax machines and printers is included in Spoke’s Employee Handbook (https://employees.spokehealth.com).
Spoke’s policies regarding the use of emails is included in Spoke’s Employee Handbook (https://employees.spokehealth.com).
Owners and Production Information-All electronic information managed must have a designated Owner. Production information is information routinely used to accomplish business objectives. Owners are responsible for assigning appropriate sensitivity classifications as defined below. Owners do not legally own the information entrusted to their care. They are instead designated members of the Spoke Health management team who act as stewards, and who supervise the ways in which certain types of information are used and protected.
This classification applies to the most sensitive business information that is intended for use strictly within Spoke Health. Its unauthorized disclosure could seriously and adversely impact Spoke Health, its customers, its business partners, and its suppliers. All PHI and ePHI fall into this category.
This classification applies to less-sensitive business information that is intended for use within Spoke Health. Its unauthorized disclosure could adversely impact Spoke Health or its customers, suppliers, business partners, or employees.
This classification applies to information that has been approved by Spoke Health management for release to the public. By definition, there is no such thing as unauthorized disclosure of this information and it may be disseminated without potential harm.
Data Owners must make decisions about who will be permitted to gain access to information, and the uses to which this information will be put.
The Spoke workforce member, or their manager, initiates the access request by creating an Issue in the JIRA Employee Access Project.
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.
The Security 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.
If the review is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required. The Security Officer then grants requested access.
New accounts will be created with a temporary secure password that meets all requirements from §5.13, Password Management, which must be changed on the initial login.
All password exchanges must occur over an authenticated channel.
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 Spoke employee at the discretion of the Security Officer.
The Security Officer initiates the review of user access by creating an Issue in the JIRA Employee Access Project.
The Security Officer, or a Privacy Officer, is assigned to review levels of access for each Spoke workforce member.
If user access is found during review that is not in line with the least privilege principle, the process below is used to modify user access and notify the user of access changes. Once those steps are completed, the Issue is then reviewed again.
Review of user access is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
Any Spoke workforce member can request change of access using the process outlined in §5.4.1paragraph 1.
Access to production systems is controlled using centralized user management and authentication.
Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily.
In the case of non-personal information, such as generic educational content, identification and authentication may not be required.
Generic accounts are not allowed on Spoke systems.
Access is granted through encrypted, VPN tunnels that utilize two-factor authentication.
Two-factor authentication is accomplished using a Time-based One-Time Password (TOTP) as the second factor.
VPN connections use 256-bit AES 256 encryption, or equivalent.
VPN sessions are automatically disconnected after 30 minutes of inactivity.
Spoke maintains a minimum necessary approach to access to Customer data. As such, Spoke, including all workforce members, does not readily have access to any ePHI.
Role based access categories for each Spoke system and application are pre-approved by the Security Officer.
Spoke, through Datica, utilizes hardware and software firewalls to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.
All Customer support desk interactions must be verified before Spoke support personnel will satisfy any request having information security implications.
Spoke’s current support desk software requires users to authenticate before submitting support tickets.
Access to the Spoke Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
Shared accounts are not allowed within Spoke systems or networks.
Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with Spoke workstations or production systems.
Information systems automatically log users off the systems after 15 minutes of inactivity.
All workstations at Spoke are company owned.
Workstations may not be used to engage in any activity that is illegal or is in violation of Spoke’s policies.
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.
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.
Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
All remote access and file sharing services will be configured to require authentication and encryption.
Transmitted messages may not contain material that criticizes the organization, its providers, its employees, or others.
Workstation hard drives will be encrypted using FileVault 2.0 or equivalent.
All workstations will have unnecessary or unused programs and services either disabled or uninstalled.
This computer is owned by Spoke Health, Inc.Access to protected data is strictly enforced.
Any unauthorized access to protected data or use by unauthorized individuals is prohibited.By logging in, unlocking, and/or using this computer you acknowledge you have seen, and AGREE TO follow, these policies (https://policy.spokehealth.com) and have completed this training (https://training.spokehealth.com).Please contact us if you have problems with this – privacy@spokehealth.com.
Access to the Administration Portal at Spoke Health, Inc. is restricted.Access to protected data is strictly enforced. Any unauthorized access to protected data or use by unauthorized individuals is prohibited.By logging in you acknowledge you have seen, and AGREE TO follow, these policies (https://policy.spokehealth.com) and have completed this training (https://training.spokehealth.com).Please contact us if you have problems with this – privacy@spokehealth.com.
Wireless access is disabled on all production systems.
When accessing production systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.
Passwords are rotated on a regular basis, presently quarterly. This process is managed by the Spoke Security Officer.
The Human Resources Department (or other designated department) must inform the Security Officer immediately upon determining to terminate an employee. The Security Officer will terminate the departing employee’s access to Spoke’s systems, the timing of which depends on the circumstances surrounding the termination.
The Human Resources Department (or other designated department) and supervisors must inform the Security Officer immediately upon learning an employee is resigning. The Security Officer will terminate the departing employee’s access to Spoke’s systems, the timing of which depends on the circumstances surrounding the termination.
These processes are included in Spoke’s “Termination Checklist,” which is available to Spoke directors and above upon request.
The Security Officer will terminate users’ access rights immediately upon notification, and will coordinate with the appropriate Spoke employees to terminate access to any non-production systems managed by those employees.
User IDs and passwords are used to control access to Spoke systems and may not be disclosed to anyone for any reason.
account lockout after 5 invalid attempts.
Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in §15.8.
Transmitted passwords must be encrypted in flight pursuant to the requirements in §15.9.
Each information system automatically requires users to change passwords at a predetermined interval as determined by the organization, based on the criticality and sensitivity of the ePHI contained within the network, system, application, and/or database.
Passwords are inactivated immediately upon an employee’s termination or resignation.
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 password-reset@spokehealth.com. 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 Security Officer is the owner of this group and modifies membership as needed.
Employees may not download ePHI to any workstations used to connect to production systems.
Disallowing transfer of ePHI to workstations is enforced through technical measures.
All production access to systems is performed through a bastion/jump host accessed through a VPN. Direct access to production systems is disallowed by Spoke’s VPN configuration.
On production Linux bastions, all file transfer services are disabled including file-transfer functionality of SSH services (SCP/SFTP).
On production Windows bastions, local drive mappings are disabled by Group Policy settings.
Configuration settings for enforcing these technical controls are managed by Spoke’s configuration management tooling, Chef.
Spoke, in conjunction with Datica, 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. Spoke 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.
All connections to Spoke are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
Spoke’s auditing processes shall address access and activity at the following levels listed below.Spoke provides software to aggregate and view User and Application logs, but the log data collected is the responsibility of the PaaS 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 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 level audit trails generally monitor and log all user activities, including data accessed and modified and specific actions.
System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions. Spoke utilizes file system monitoring from OSSEC to assure the integrity of file system data.
Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities.
Spoke shall log all incoming and outgoing traffic to 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 Spoke.
Spoke utilizes OSSEC to scan all systems for malicious and unauthorized software every 2 hours and at reboot of systems.
Spoke leverages process monitoring tools throughout its environment.
Spoke uses OSSEC to monitor the integrity of log files by utilizing OSSEC System Integrity Checking capabilities.
Spoke shall identify “trigger events” or criteria that raise awareness of questionable conditions of viewing of confidential information.(See Listing of Potential Trigger Events below).
In addition to trigger events, Spoke utilizes OSSEC log correlation functionality to proactively identify and enable alerts based on log data.
Logs are reviewed weekly by the Security Officer.
Identification of which Spoke workforce members will be responsible for review (workforce members shall not review audit logs that pertain to their own system activity).
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).
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, employees, and Customers.
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 Spoke’s Privacy or Security Officer.
A request for an audit must be approved by Spoke’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 Spoke’s Security Officer to determine appropriate sanction/corrective disciplinary action.
Only de-identified information shall be shared with Customer regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by Spoke’s Privacy Officer or designee. Prior to communicating with Customers regarding an audit, it is recommended that Spoke consider seeking risk management and/or legal counsel.
If the Issue is approved, the Security Officer then marks the Issue as Done, adding any pertinent notes required.
The reporting process shall allow for meaningful communication of the audit findings to the party requesting the audit.
Significant findings shall be reported immediately in a written format. Spoke’s security incident response form may be utilized to report a single event.
Security audits constitute an internal, confidential monitoring practice that may be included in Spoke’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 e PHI shall not be included in the reports).
Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the appropriate party.
Log review activity is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
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 Spoke and the 3rd party.
If it is determined that the Customer or Partner has exceeded the scope of access privileges, Spoke’s leadership must remedy the problem immediately.
If it is determined that a Customer or Partner has violated any terms within the HIPAA regulations, Spoke must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.
All audit logs are protected in transit and encrypted at rest to control access to the content of the logs.
Spoke’s audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges.Separate systems are used to apply the security principle of “separation of duties” to protect audit trails from hackers.Logging servers include Elasticsearch, Logstash, and Kibana (ELK) as part of their baseline configuration to ease reviewing of audit log data. The ELK toolkit provides message summarization, reduction, and reporting functionality.
Spoke workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI (for more information on Spoke’s onboarding and training policies, see below in §16.7).Spoke’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. Spoke 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.
Spoke Customers are provided with necessary information to understand Spoke auditing capabilities.
Audit log data is retained locally on the audit log server for a one-month period. Beyond that, log data is encrypted and moved to warm storage (currently S3) using automated scripts, and is retained for a minimum of one year.
Spoke standardizes and automates configuration management through the use of Chef scripts as well as documentation of all changes to production systems and networks. Chef automatically configures all Spoke systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.
Chef is used to standardize and automate configuration management.
No systems are deployed into Spoke environments without approval of the Spoke CTO.
All changes to production systems, network devices, and firewalls are approved by the Spoke CTO before they are implemented to assure they comply with business and security requirements.
All changes to production systems are tested before they are implemented in production.
Implementation of approved changes are only performed by authorized personnel.
Tooling to generate an up-to-date inventory of systems, including corresponding architecture diagrams for related products and services, is hosted on GitLab.
All systems are categorized as production and utility to differentiate based on criticality.
The Security Officer maintains scripts to generate inventory lists on demand using APIs provided by each cloud provider.These scripts are used to generate the diagrams and asset lists required by the Risk Assessment phase of Spoke’s Risk Management procedures (§2.3).
After every use of these scripts, the Security Officer will verify their accuracy by reconciling their output with recent changes to production systems. The Security Officer will address any discrepancies immediately with changes to the scripts.
All committed code is reviewed using pull requests to assure software code quality and proactively detect potential security issues in development.
Spoke utilizes development and staging environments that mirror production to assure proper function.
Spoke also deploys environments locally using Vagrant to assure functionality before moving to staging or production.
All local and staging environments will never have access to any ePHI, or utilize ePHI for testing.
Spoke uses the Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency as a baseline for hardening systems.
Windows-based systems use a baseline Active Directory group policy configuration in conjunction with the Windows Server 2012 STIG.
Linux-based systems use a Red Hat Enterprise Linux STIG which has been adapted for Ubuntu and improved based on the results of subsequent vulnerability scans and risk assessments.
Clocks are continuously synchronized to an authoritative source across all systems using NTP or a platform-specific equivalent. Modifying time data on systems is restricted.
Before provisioning any systems, ops team members must file a request in the company project tracking system (e.g. JIRA).JIRA access requires authenticated users.The CTO grants access to the project following the procedures covered in the Access Establishment and Modification section.
The CTO must approve the provisioning request before any new system can be provisioned.
for SaltStack Orchestration, this means adding the appropriate grains to the Salt configuration file and running a highstate operation.
for Chef, this means adding the appropriate roles to the system’s Chef profile and doing a Chef run.
If the system will be used to house production data (ePHI), the ops team member must add an encrypted block data volume to the VM during provisioning.For systems on AWS, the ops team member must add an encrypted Elastic Block Storage (EBS) volume.For systems on other cloud providers, the ops team member must add a block data volume and set up OS-level data encryption using the configuration management (CM) software.
all items listed in the operating system-specific subsections below.
Once the security team member has verified the new system is correctly configured, the team member must add that system to the company security scanner software, if applicable.
The new system may be rotated into production once the CTO verifies all the provisioning steps listed above have been correctly followed and has marked the Issue with the Approved state.
Ensuring that the machine is up-to-date with security patches and is configured to apply patches in accordance with our policies.
Stopping and disabling any unnecessary OS services.Installing and configuring an IDS agent (e.g. OSSEC).
Configuring 15-minute session inactivity timeouts.
Installing and configuring a virus scanner (e.g. ClamAV).
Installing and configuring the NTP daemon, including ensuring that modifying system time cannot be performed by unprivileged users.
Configuring authentication to the centralized LDAP servers.
Configuring audit logging as described in the Auditing Policy section.
Any additional server settings applied to the Linux system must be clearly documented by the ops team member in the project tracker request by specifying the purpose of the new system.
Provisioning management systems such configuration management servers, LDAP servers, or VPN appliances follows the same procedure as provisioning a production system.
Critical infrastructure services such as logging, monitoring, LDAP servers, or Windows Domain Controllers must be configured with appropriate configuration management settings.
Password size, strength, and expiration requirements.
Critical infrastructure roles applied to new systems must be clearly documented by the ops team member in the project tracker request.
Spoke uses automated tooling to ensure systems are up-to-date with the latest security patches.
On Ubuntu Linux systems, the unattended-upgrades tool is used to apply security patches in phases.
The security team maintains a mirrored snapshot of security patches from the upstream OS vendor. This mirror is synchronized bi-weekly and applied to development systems nightly.
If the development systems function properly after the two-week testing period, the security team will promote that snapshot into the mirror used by all staging systems. These patches will be applied to all staging systems during the next nightly patch run.
If the staging systems function properly after the two-week testing period, the security team will promote that snapshot into the mirror used by all production systems. These patches will be applied to all production systems during the next nightly patch run.
Patches for critical kernel security vulnerabilities may be applied to production systems using hot-patching tools at the discretion of the Security Officer. These patches must follow the same phased testing process used for non-kernel security patches; this process may be expedited for severe vulnerabilities.
Will be subject to a full assessment prior to approval of the change control documentation and/or release into the live environment.
Will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.
Will be subject to an appropriate assessment level based on the risk of the changes to the application functionality and/or architecture.
An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out. Emergency releases will be designated as such by the Chief Information Officer or an appropriate manager who has been delegated this authority.
Any high risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the live environment.
Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly. Applications with medium risk issues may be taken off-line or denied release into the live environment based on the number of issues and if multiple issues increase the risk to an unacceptable level. Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.
Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.
The Risk Levels are based on the OWASP Risk Rating Methodology.
Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.
A full assessment is comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide. A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered.
A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum.
A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.
If any employee, manager, director, executive or otherwise authorized individual feels the need to submit a change to the Spoke Health network, they may submit that request to the relevant individual in charge of the maintenance and development of that area. For issues dealing with product, database, or customer facing systems, the request will need to be directed to the Chief Product Officer. For issues dealing with integration with 3rd party partners, clients, standards, compliance, and other non-product issues, the request will need to be directed to the Chief Technology Officer.
All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.
These changes must be covered under 1) a unit test where possible, or 2) integration tests.
Integration tests are required if unit tests cannot reliably exercise all facets of the change.
Every release will run automated test suites for both code coverage tests and automated functional tests (using Selenium).
Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.
Commit messages should be wrapped to 72 characters.
Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
Once the feature and corresponding tests are complete, a pull request will be created using the GitLab web interface from our stable staging line. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically via an @channel message in Slack.
Other engineers will review the changes, using the guidelines above.
Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
If the feature or defect interacts with ePHI, or controls access to data potentially containing ePHI, the code changes must be reviewed by the Security Officer before the feature is marked as complete.
This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10.
This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.
Once the review process finishes, each reviewer should leave a comment on the pull request saying “looks good to me” (often abbreviated as “LGTM”), at which point the original author(s) may merge their change into the release branch.
All releases are tagged to allow for easy reversion in the event of a failed release.
Pass tests and linters that are run on each build as part of our deployment process.
The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-throughs, business tool reports, internal and external audits, and feedback to the policy owner.
Any exception to the policy must be approved by the Infosec team in advance.
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. Web application assessments are a requirement of the change control process and are required to adhere to this policy unless found to be exempt. All application releases must pass through the change control process. Any web applications that do not adhere to this policy may be taken offline until such time that a formal assessment can be performed at the discretion of the Chief Information Officer.
Software releases are treated as changes to existing systems and thus follow the procedure described in §7.6.
Changes to Vendor ServicesChanges to 3rd party services are classified as configuration management changes and thus are subject to the policies and procedures described in this §7;Substantial changes to services provided by 3rd parties will invoke a Risk Assessment as described in §2.2.
Spokes Changes Impacting SLAsThe impact of change on existing SLAs shall be considered; andThe impact(s) are communicated to the third-party at the discretion and direction of the Security Officer.
Physical access to Spoke facilities is limited to only those authorized in this policy.
Employee access to Spoke facilities and premises, including specific areas and offices, is restricted to an as-needed basis.
The Security Officer provides new employees access to only those areas necessary for the employee to perform his/her duties. The Security Officer maintains a record of the keys, regardless of type or modality, issues to each employee.
Workforce members must report a lost and/or stolen key(s) to the Security Officer. If a key is reported missing, the Security Officer facilitates the changing of the lock(s) within 7 days.
The Security Officer revokes access and collects keys upon termination of workforce members, as provided for in Spoke’s Termination Checklist, which is available to Spoke directors and above upon request.
Third-party access to Spoke facilities and premises, including specific areas and offices, is restricted to an as-needed basis and is described in detail in Spoke’s Visitor Policy (https://policy.spokehealth.com).
Visitors in violation of this policy are subject to loss of vendor privileges and/or termination of services from Spoke.
Spoke 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 Spoke incident response process follows the process recommended by SANS, an industry leader in security. Process flows are a direct representation of the SANS process which can be found in this document.
Suspicious emails targeting specific Spoke staff members with administrative access to production systems.
IDS alerts for modified system files or unusual system accesses.
Unauthorized change or destruction of ePHI.
Unauthorized or uncontrolled changes to the system.
Loss or theft of a physical asset.
Spoke 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.
The Security Officer determines if the issue is an Event, Precursor, Indication, or Incident. If the issue is an event, indication, or precursor the Security Officer forwards it to the appropriate resource for resolution.
Non-Technical Event (minor infringement): the Security Officer completes a SIR Form and investigates the incident.
If the issue is a security incident, the Security Officer activates the Security Incident Response Team (SIRT) and notifies senior management.
The lead member of the SIRT team facilitates initiation of a SIR Form or an Incident Survey Form. The intent of the SIR form is to provide a summary of all events, efforts, and conclusions of each Phase of this policy and procedures.
The Security Officer, Privacy Officer, or Spoke 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.
In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to Spoke and potentially external.
In this Phase, Spoke’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.
If it is safe, allow the system to continue to function, complete any documentation relative to the security incident on the SIR Form, and Move to Phase V, Follow-up.
The individual completing this phase provides written communication to the SIRT, continuously apprises senior management of progress, and notify affected Customers and Partners with relevant updates as needed.
Evaluate the cost and impact of the security incident to Spoke using the documents provided by the SIRT and the technical security resource.
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 the Spoke’s expectation for them, relative to security responsibilities. The incident response plan is tested annually.
In the case of a breach, Spoke shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals.
The Spoke 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. A template breach log is located here.
The cause of the breach, and the entity responsible for the breach, either Customer, Spoke, or Partner.
Upon discovery of a breach, notice shall be made to the affected Spoke Customers no later than 4 hours 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.
A brief description of what Spoke is doing to investigate the breach, to mitigate harm to individuals and Customers, and to protect against further breaches.
Methods of Notification: Spoke Customers will be notified via email and phone within the timeframe for reporting breaches, as outlined above.
Spoke 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.
Spoke 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.
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.
Spoke 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.
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 Spoke 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.
The Spoke Contingency Plan establishes procedures to recover Spoke following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the Spoke Security Officer and Privacy Officer.
Identify the activities, resources, and procedures needed to carry out Spoke processing requirements during prolonged interruptions to normal operations.
Identify and define the impact of interruptions to Spoke systems.
Assign responsibilities to designated personnel and provide guidance for recovering Spoke during prolonged periods of interruption to normal operations.
Ensure coordination with other Spoke staff who will participate in the contingency planning strategies.
This Spoke Contingency Plan has been developed as required under the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, Appendix III, November 2000, and the Health Insurance Portability and Accountability Act (HIPAA) Final Security Rule, Section §164.308(a)(7), which requires the establishment and implementation of procedures for responding to events that damage systems containing electronic protected health information.
This Spoke Contingency Plan is created under the legislative requirements set forth in the Federal Information Security Management Act (FISMA) of 2002 and the guidelines established by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-34, titled “Contingency Planning Guide for Information Technology Systems” dated June 2002.
Example of the types of disasters that would initiate this plan are natural disaster, political disturbances, manmade disaster, external human threats, internal malicious activities.
Spoke defined two categories of systems from a disaster recovery perspective.
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.
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.
The following order of succession to ensure that decision-making authority for the Spoke Contingency Plan is uninterrupted. The Chief Technology Officer (CTO) and VP Engineering are responsible for ensuring the safety of personnel and the execution of procedures documented within this Spoke Contingency Plan. If the CTO and VP Engineering are unable to function as the overall authority or chooses to delegate this responsibility to a successor, the CEO or COO shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.
Ops team is responsible for recovery of the Spoke hosted environment, network devices, and all servers. Members of the team include personnel who are also responsible for the daily operations and maintenance of Spoke. The team leader is the VP of Engineering and directs the Dev Ops Team.
Web Services Team is responsible for ensuring all application servers, web services, and platform add-ons are working. It is also responsible for testing redeployments and assessing damage to the environment. The team leader is the CTO and directs the Web Services Team.
Members of the Ops and Web Services teams must maintain local copies of the contact information from §11.4. Additionally, the CTO and VP Engineering must maintain a local copy of this policy in the event Internet access is not available during a disaster scenario.
This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to Spoke. Based on the assessment of the Event, sometimes according to the Spoke Incident Response Policy, the Contingency Plan may be activated by either the CTO or VP of Engineering.
Spoke will be unavailable for more than 48 hours.
Other criteria, as appropriate and as defined by Spoke.
The following procedures are for recovering the Spoke infrastructure at the alternate site. Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.
Recovery Goal: The goal is to rebuild Spoke infrastructure to a production state.
The tasks outlined below are not sequential and some can be run in parallel.
This section discusses activities necessary for restoring Spoke operations at the original or new site. The goal is to restore full operations within 24 hours of a disaster or outage. When the hosted data center at the original or new site has been restored, Spoke operations at the alternate site may be transitioned back. The goal is to provide a seamless transition of operations from the alternate site to the computer center.
If the Spoke environment is moved back to the original site from the alternative site, all hardware used at the alternate site should be handled and disposed of according to the Spoke Media Disposal Policy.
Spoke 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.
Spoke utilizes dedicated hardware from Subcontractors. ePHI is only stored on SSD volumes in our hosted environment. All SSD volumes utilized by Spoke and Spoke Customers are encrypted. Spoke does not use, own, or manage any mobile devices, SD cards, or tapes that have access to ePHI.
Spoke assumes all disposable media may contain ePHI, so it treats all disposable media with the same protections and disposal policies.
Any time disposable media is in transit, it is required to be protected at all times and kept within constant control and supervisions.
All destruction/disposal of ePHI media will be done in accordance with federal and state laws and regulations and pursuant to the Spoke’s written retention policy/schedule. Records that have satisfied the period of retention will be destroyed/disposed of in an appropriate manner.
All Spoke 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.
The methods of destruction, disposal, and reuse are re-assessed periodically, based on current technology, accepted practices, and availability of timely and cost-effective destruction, disposal, and reuse technologies and services.
In order to preserve the integrity of data that Spoke stores, processes, or transmits for Customers, Spoke, in conjunction with Datica, implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access. Datica currently utilizes OSSEC to track file system integrity, monitor log data, and detect rootkit access.
Spoke 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.
Spoke utilizes redundant firewall on network perimeters.
Spoke is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. Spoke protects its systems from any vulnerabilities in conjunction with Datica. Datica utilizes Nessus Scanner from Tenable 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.
Nessus management is performed by the Datica Security Officer with assistance from the VP of Engineering.
Nessus is used to monitor all internal IP addresses (servers, VMs, etc) on Spoke networks.
The Security Officer initiates the review of a Nessus Report by creating an Issue in the JIRA Employee Access Project.
The Security Officer, or a Datica Security Engineer assigned by the Security Officer, is assigned to review the Nessus Report.
If new vulnerabilities are found during review, the process below is used to test those vulnerabilities is outlined below. Once those steps are completed, the Issue is then reviewed again.
Once the review is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review.
Vulnerabilities that are repeatable manually are documented and reviewed by the Security Officer, VP of Engineering, and Privacy Officer to see if they are part of the current risk assessment performed by Spoke.
Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in the Spoke Risk Assessment Policy.
All vulnerability scanning reports are retained for 6 years by Spoke. Vulnerability report review is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
Penetration testing is performed regularly as part of the Datica vulnerability management policy.
Internal penetration testing is performed quarterly. Below is the process used to conduct internal penetration tests.
The Security Officer initiates the penetration test by creating an Issue in the JIRA Employee Access Project.
The Security Officer, or a Spoke Security Engineer assigned by the Security Officer, is assigned to conduct the penetration test.
Gaps and vulnerabilities identified during penetration testing are reviewed, with plans for correction and/or mitigation, by the Spoke Security Officer before the Issue can move to be approved.
Once the testing is completed, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further testing and review.
Internal penetration testing is monitored on an annual basis using JIRA reporting to assess compliance with above policy.
This vulnerability policy is reviewed on a quarterly basis by the Security Officer and Privacy Officer.
Penetration tests results are retained for 6 years by Spoke.
Spoke, through its partnership with Datica, ensures the highest level of data integrity possible. Production systems that create, receive, store, or transmit Customer data (hereafter “Production Systems”) must follow the guidelines described in this section.
All access to Production Systems must be logged. This is done following the Spoke Auditing Policy.
All Production Systems must have OSSEC running, and set to scan system every 2 hours and at reboot to assure not malware is present. Detected malware is evaluated and removed.
Virus scanning software is run on all Production Systems for antivirus protection.
Hosts are scanned daily for malicious binaries in critical system paths.
The malware signature database is checked hourly and automatically updated if new signatures are available.
Logs of virus scans are maintained according to the requirements outlined in §6.6.
All Production Systems are to only be used for Spoke business needs.
Production systems are monitored using IDS systems. Suspicious activity is logged and alerts are generated.
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.
System, network, and server security is managed and maintained by the Datica VP of Engineering and the Security Officer.
All Production Data at rest is stored on encrypted volumes using encryption keys managed by Datica. Encryption at rest is ensured through the use of Datica’s platform.
All data transmission is encrypted end to end using encryption keys managed by Datica. Encryption is not terminated at the network endpoint, and is carried through to the application.
Transmission encryption keys use a minimum of 4096-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).
In the case of Spoke provided APIs, provide mechanisms to assure person sending or receiving data is authorized to send and save data.
Spoke is committed to ensuring all workforce members actively address security and compliance in their roles at Spoke. As such, training is imperative to ensuring an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non-compliance.
Unfair Competition Agreement for all other employees that addresses non-disclosure, non-solicitation of Spoke human resources, non-solicitation of clients, and disclosure and assignment of innovations.
The policies and documents for recruiting, hiring and contracting are detailed in Spoke’s policy document titled, “Hiring Process and Documents” (https://employees.spokehealth.com).
Spoke follows a formal onboard process as described in Spoke’s Onboarding and Training Policies and Documents (https://employees.spokehealth.com).
Security Policies and Procedures (https://policy.spokehealth.com).
Spoke follows a standard, regimented training process as described in Spoke’s Onboarding and Training Policies and Documents found at https://employees.spokehealth.com.
Certain new employees will receive additional, robust training on Spoke’s policies and procedures for working remotely.
Employees must take and pass an exam after completing the modules listed above in §16.4.1.
Employees must complete this training and pass each exam before accessing Spoke systems containing ePHI.
Spoke tracks each employee’s progress through the training program.
Spoke retains training records for each employee.
Spoke 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.
Create an Issue in the JIRA Employee Access Project.
The Issue is investigated, documented, and, when a conclusion or remediation is reached, it is moved to Review.
The Issue is reviewed by another member of the Escalation Team. If the Issue is rejected, it goes back for further evaluation and review.
If the Issue is approved, it is marked as Done, adding any pertinent notes required.
The workforce member that initiated the process is notified of the outcome via email.
Security incidents, particularly those involving ePHI, are handled using the process described in §9.2. If the incident involves a breach of ePHI, the Security Officer will manage the incident using the process described in §10.2. Refer to §9.2 for a list of sample items that can trigger Spoke’s incident response procedures; if you are unsure whether the issue is a security incident, contact the Security Officer immediately.
Spoke follows a formal termination process, outlined in Spoke’s Employee Handbook (https://employees.spokehealth.com). HR managers are provided clear guidance in Spoke’s Termination Checklist, which is available upon request by directors and above.
For information about Spoke’s policies for terminating a departing employee’s access rights, see above in §5.12.
Employees may only use Spoke-purchased and -owned workstations for accessing systems with access to ePHI data and for communications with patients, providers, and Business Associates.
Any workstations used to access systems must be configured as prescribed in §5.10.
This computer is owned by Spoke Health, Inc.
Access to protected data is strictly enforced.
or use by unauthorized individuals is prohibited.
By logging in, unlocking, and/or using this computer you acknowledge you have seen, and AGREE TO follow, these policies (https://policy.spokehealth.com) and have completed this training (https://training.spokehealth.com).
Please contact us if you have problems with this – privacy@spokehealth.com.
Spoke utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by Spoke, 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 Spoke leadership.
GitLab. GitLab is an open source tool built on top of Git, the version control platform. GitLab is hosted and secured by Spoke. 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 Spoke.
Google Apps. Google Apps is used for email and document collaboration, and for the storage of and sharing of files with Partners and Customers.
JIRA. JIRA is used for configuration management and to generate artifacts for compliance procedures.
Slack. Slack is used as a collaboration and communication tool among the Spoke employees.
All 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 systems with access to ePHI data.
During the onboarding of employees authorized to work remotely are provided an encrypted laptop, a remote firewall, and a Spoke-dedicated cell phone.
The encrypted laptop and firewall are preconfigured by Spoke to ensure the laptop’s online access is restricted to only the remote firewall, and the remote firewall will connect with only the dedicated laptop.
The laptop and cell phone are configured by Spoke to contain only the software required for the employee to perform the work assigned to him/her by Spoke, and to restrict the employee’s ability to add or remove software so that all changes must be performed by Spoke.
Spoke makes every effort to assure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of Spoke or Spoke Customer data. 3rd Parties include Customers, Partners, Subcontractors, and Contracted Developers.
provide Spoke with a valid HITRUST Certificate.
If the third-party will use Spoke’s Vendor Assessment Questionnaire or will submit the results of its HITRUST Self-assessment, Spoke reviews the information provided and determines the if the potential third-party satisfies the minimum required security policies and procedures required by Spoke’s internal Security Policies, Spoke’s contractual obligations, or by federal and state regulations, whichever imposes the most stringent standards.
* Changes to 3rd party services are classified as configuration management changes and thus are subject to the policies and procedures described in §7; substantial changes to services provided by 3rd parties will invoke a Risk Assessment as described in §2.2.
Spoke has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
Spoke maintains and annually reviews a list all current Partners and Subcontractors.
The list of current Partners and Subcontractors is maintained by the Spoke Privacy Officer, includes details on all provided services (along with contact information).
Spoke utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
The annual review of Partners and Subcontractors is conducted as a part of the security, compliance, and SLA review referenced below.
Spoke assesses security, compliance, and SLA requirements and considerations with all Partners and Subcontractors. This includes annual assessment and reporting for all Spoke infrastructure partners.
Regular review is conducted as required by SLAs to assure security and compliance. These reviews may include reports, audit trails, security events, operational issues, failures and disruptions, and identified issues are investigated and resolved in a reasonable and timely manner.
For all partners, Spoke reviews activity annually to assure partners are in line with SLAs in contracts with Spoke.
SLA review is monitored on a quarterly basis using JIRA reporting to assess compliance with above policy.
Spoke does not allow 3rd party access to production systems containing ePHI.
All connections and data in transit between the Spoke Platform and 3rd parties are encrypted end to end.
No Spoke Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
An application hosted by Spoke, either maintained and created by Spoke, or maintained and created by a Customer or Partner.
Controls and security associated with an Application. In the case of PaaS Customers, Spoke does not have access to and cannot assure compliance with security standards and policies at the Application Level.
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.
Technical mechanisms that track and record computer/system activities.
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.
Means the ability or the means necessary to read, write, modify, or communicate data/ information or otherwise use any system resource.
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.
A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them. This service is provided to Spoke by Datica.
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.
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.
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.
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.
A health plan, health care clearinghouse, or a healthcare provider who transmits any health information in electronic form.
Companies that engage Spoke to provide its surgery-savings benefits program.
A partner, as defined herein, engaged by Spoke to encapsulate all Spoke systems with access to ePHI in a digital environment that meets or exceeds the highest industry standards as well as all federal and state regulations. References in this document to Spoke’s policies, practices, processes, reporting, etc., can reflect the inclusion of those adopted by Datica.
The process of removing identifiable information so that data is rendered to not be PHI.
The ability to recover a system and data after being made unavailable.
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.
Disclosure means the release, transfer, provision of, access to, or divulging in any other manner of information outside the entity holding the information.
Any individually identifiable health information protected by HIPAA that is transmitted by, processed in some way, or stored in electronic media.
The overall technical environment, including all servers, network devices, and applications.
Any computing device able to create and store ePHI.
The government body that maintains HIPAA.
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.
A software tool use to automatically detect and notify in the event of possible unauthorized network and/or system access.
An Intrusion Detection Service for providing IDS notification to customers in the case of suspicious activity. This service is provided to Spoke by Datica.
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.
API-based services to deliver and receive SMS messages.
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.
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.
For the purposes of this policy, the term “organization” shall mean Spoke.
Contractually bound 3rd party vendor with integration with the Spoke Platform and/or otherwise interacts with Spoke in such a way as to touch upon PHI.
The overall technical environment of Spoke.
The category or class of person or persons doing a type of job, defined by a set of similar or identical responsibilities.
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.
Activities that may be indicative of a security breach that require further investigation (See Appendix).
Those areas of the building(s) where protected health information and/or sensitive organizational information is stored, utilized, or accessible at any time.
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.
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.
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).
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.
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.
The method by which an attack might be carried out (e.g., hacking, system intrusion, etc.).
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.
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.
Persons from other organizations marketing or selling products or services, or providing services to Spoke.
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.
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.
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.
Below is a list of HIPAA Safeguards and Requirements and the Spoke controls in place to meet those.

References: §164
 §1
 §5
 §5
 §15
 §15
 §16
 §7
 §7
 §2
 §164
 §11
 §6
 §16
 §9
 §10
 §9
 §5
 §5
 §7
 §2