Healthwise Information Security Policies

Ignite Healthwise, LLC (Healthwise) is committed to ensuring the confidentiality, integrity, and availability of all Electronic Protected Health Information (ePHI) it receives, maintains, processes and/or transmits on behalf of its Customers. The following documents define the core policies used by Healthwise to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for Healthwise Customers.

1.1 Scope

The policy requirements and restrictions defined in these documents shall apply to network infrastructures, databases, external media, encryption, hardcopy reports, films, slides, models, wireless, telecommunication, conversations, and any other methods used to convey knowledge and ideas across all hardware, software, and data transmission mechanisms. These policies must be adhered to by all Healthwise Workforce at all locations and by contractors working with Healthwise as subcontractors. Unless a time frame is specified in a policy or procedure, the policy or procedure is executed as required.

These documents define common security requirements for all Healthwise 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 of Healthwise, entities in the private sector, in cases where Healthwise has a legal, contractual or fiduciary duty to protect Information Resources while in Healthwise custody. In the event of a conflict, the more restrictive measures apply. This policy covers the Healthwise network system which is comprised of various hardware, software, communication equipment and other devices designed to assist Healthwise in the creation, receipt, storage, processing, and transmission of information. This definition includes equipment connected to any Healthwise domain or VLAN, either hardwired or wirelessly, and includes all stand-alone equipment that is deployed by Healthwise at its office locations or at non-Healthwise remote locations.

1.2 Version Control

Refer to the Github repository at https://github.com/healthwise/policy.healthwise.org for the full version history of these policies.

1.3 Applicable Statutes / Regulations

The following is a list of the various agencies/organizations whose laws, mandates, or regulations have been incorporated into the various policy statements included in these documents.

Each of the policies defined in these documents are applicable to the tasks being performed – not just to specific departments or job titles.

1.4 Exceptions

Any exceptions to policies in these documents must be approved in writing, in advance, by the Security Officer or Privacy Officer.

1.5 Requesting Audit and Compliance Reports

Healthwise, at its sole discretion, shares Audit reports, including its HITRUST reports and Corrective Action Plans (CAPs), with customers on a case by case basis. All Audit reports are shared under an explicit NDA or contractual confidentiality requirement between Healthwise and party to receive materials. Audit reports can be requested by Healthwise workforce members for Customers or directly by Healthwise Customers. To request an audit or compliance report, please email your request (including the type of report being requested and any required timelines) to gro.esiwhtlaeh@ecnailpmoc.

1.6 Last Reviewed Date

The policies contained herein were last reviewed and updated July 12, 2023.

1.7 Changelog

Janurary 16, 2024

Section 6.2: Add statement regarding free software tools not automatically approved

Dec 19, 2022

Section 12.6: Update to require cloud security training for employees accessing the production environment

May 3, 2022

Section 7: Update to exclude personal computers from list of approved personal devices

January 31, 2022

Section 11.1: Update statement on vulnerability scanning frequency to monthly

July 13, 2021

Section 9.11: Update password length requirements to 12 characters

January 29, 2021

Section 3: Add statement regarding Healthwise obligations to ensure compliance with security plan
Section 3.1: Additional language covering Privacy Officer responsibilities
Section 4.11: Employee actions may be monitored, and employee consents to such monitoring
Section 6.1: Additional language regarding risk identification related to third party access
Section 9.8: Require a minimum of WPA2/AES for accessing wireless APs
Section 12.6: Additional language regarding the goals of security awareness training
Section 13.1: Add HITRUST requirements for developing applications based on secure coding guidelines
Section 14.1: Disciplinary action will be taken against Healthwise Workforce that fails to cooperate with federal and state investigations

October 22, 2020

Section 4.10: Add statement requiring Healthwise Workforce to immediately report lost or stolen devices

November 24, 2019

Section 3.1: Incorporate Privacy Officer changes

October 31, 2019

Section 6.4: Add policy statements for consuming and contributing to open source.

January 14, 2019

Updates to bring policies into compliance with HITRUST v9.1. Noteworthy changes are:

Section 2.1: Describe how Healthwise Workforce may initiate policy complaints.
Section 6.1: Add statement indicating third party access is limited to minimum necessary.
Section 6.2: Add statement indicating a list of blacklisted software is maintained and not allowed on Healthwise Systems.
Section 7.3: Add statement indicating Healthwise will monitor for unauthorized mobile connections to its corporate network. Also added statement prohibiting personal devices downloading applications from app stores not officially supported by the device manufacturer.
Section 9.7: Describe security controls applied to workstations.
Section 9.8: Add statement indicating scans for rogue wireless access points happen periodically.
Section 9.9: Add statement indicating that terminated workforce will not have unchaperoned access unless authorized in advance.
Section 10: Add statement describing where ePHI can be stored and that it must be deleted immediately after it is no longer required.
Section 12.1: Update audit policies and levels logged.
Section 13.1: Add statement indicating Security Officer reviews and updates software development procedures periodically.
Section 13.3: Add statement indicating if a system or component is no longer supported by its manufacturer, that Healthwise will create and implement a migration plan.
Section 18.1: Add statement indicating that all visitors are required to register and receive a temporary badge that must be surrendered when they leave.

December 14, 2018

Section 4.7: Clarify that individuals are not authorized to pay ransoms to return Healthwise data or personnel unless authorized by the Security Officer

November 26, 2018

Section 9.1: Change inactive account disabling from 90 days to 60 days

November 13, 2018

Section 10.2: Add data retention policy

August 8, 2018

Section 3.2: Incorporate Security Officer changes

June 28, 2018

Section 13.1.1: Clarify software development policies

May 10, 2018

Section 3.5: Clarify that unauthorized removal of ePHI will result in termination, instead of inability to access any ePHI
Section 4.2: Clarify that Healthwise Confidential Information must not be forwarded to personal email accounts
Section 6.2: Add reference to software approval procedure for adding necessary software to the Healthwise Approved Software page
Section 8.1: Define Retention Schedule
Section 9.1: Clarify that access request records are kept for six years; define Retention Schedule
Section 9.11: Update account lockout to occur after 5 invalid attempts, instead of 10, per 01.p HITRUST control
Section 10.1: Update to allow for 13 months of data in the SIEM
Section 11.3: Update malware definition updates to occur at reboot and hourly thereafter. Remove requirement to scan system on reboot.

Ignite Healthwise, LLC (Healthwise) 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 tracking all Healthwise workforce member, Business Associate, customer, and partner compliance with applicable policies. Previous versions of policies are retained to assure ease of finding policies at specific historic dates in time.

The information protection program is formally documented and actively monitored, reviewed and updated to ensure program objectives continue to be met. The Information Security Management Program (ISMP) is formally documented, protected, controlled, and retained according to federal, state and organizational requirements. The ISMP also incorporates a Plan, Do, Check, ACT (PDCA) cycle for continuous improvement in the ISMP, particularly as information is obtained that could improve the ISMP or indicates any shortcomings of the ISMP.

Healthwise shall develop, disseminate, and review/update annually a formal, documented personnel security policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and formal, documented procedures to facilitate the implementation of the personnel security policy and associated personnel security controls.

Information security objectives, approach, scope, importance, goals and principles for Healthwise's security program shall be formally identified, communicated throughout Healthwise to users in a form that is relevant, accessible and understandable to the intended reader, and supported by a controls framework that considers legislative, regulatory, contractual requirements and other policy-related requirements. The information security policy documents shall state the purpose and scope of the policy, communicate management's commitment, describe management and workforce member's roles and responsibilities, and establish Healthwise's approach to managing information security.

As applicable to the focus of a particular document, policies shall contain:

Healthwise's mission, vision, values, objectives, activities, and purpose, including Healthwise's place in critical infrastructure;
a definition of information security, its overall objectives and scope and the importance of security as an enabling mechanism for information sharing;
a statement of management intent, supporting the goals and principles of information security in line with the business strategy and objectives;
a framework for setting control objectives and controls, including the structure of risk assessment and risk management;
the business case for and objectives of information security in Healthwise's business operations;
compliance scope;
legislative, regulatory, and contractual requirements, including those for the protection of covered information and the legal and ethical responsibilities to protect this information;
arrangements for notification of information security incidents, including a channel for raising concerns regarding confidentially, without fear of blame or recrimination;
a brief explanation of the security policies, principles, standards, and compliance requirements of particular importance to Healthwise, including but not limited to HITRUST CSF control objectives;
a definition of general and specific responsibilities for information security management, including reporting information security incidents;
requirements to develop, disseminate, and review/update formal, documented procedures to facilitate the implementation of security policy and associated security controls; and
references to documentation which may support the policy (e.g., more detailed security policies and procedures for specific information systems or security rules users shall comply with).

An independent review of Healthwise's information security management program shall be initiated by management to ensure the continuing suitability, adequacy, and effectiveness of Healthwise's approach to managing information security and privacy. The reviews shall:

include an assessment of Healthwise's adherence to the security plan and the tests and methods used shall be sufficient to validate the effectiveness of the security plan;
include notification requirements to confirm whom to inform within Healthwise about the timing and nature of the assessment;
address the need for changes to the approach to security in light of evolving circumstances, including the policy and control objectives and other opportunities for improvement, including those based on regular vulnerability assessments (e.g., network scans and penetration testing);
carefully control information security tests to limit the risks to confidentiality, integrity, and system availability;
be carried out by individuals independent of the area under review (e.g., the internal audit function, an independent manager or a third-party organization specializing in such reviews); and
be carried out by individuals who have the appropriate skills and experience.

2.1 Procedures

All policies are stored and kept up to date in order to maintain Healthwise compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control are done similar to source code control.

All policies are made accessible to all Healthwise workforce members. The current master policies are published at https://policy.healthwise.org. The Healthwise Human Resources department, with input from the Healthwise Security Officer and Healthwise Privacy Officer, communicates policy changes to all Healthwise Workforce via email. These emails include a high-level description of the policy change using terminology appropriate for the target audience.

Healthwise workforce members may initiate complaints against the policies by sending an email to gro.esiwhtlaeh@ecnailpmoc. Policy update requests can be made by any workforce member at any time by emailing a policy change request to gro.esiwhtlaeh@ecnailpmoc. Furthermore, all policies are reviewed at least annually by both the Security and Privacy Officer to assure they are accurate and up-to-date.

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 Healthwise policies is done via Bitbucket. Backup storage of all policies is done with Microsoft Office 365.

The policies and information security policies are reviewed and audited against the current version of the HITRUST Common Security Framework by an independent 3rd party annually, or after significant changes occur to Healthwise's Environment. Issues that come up as part of this process are reviewed by Healthwise management to assure all risks and potential gaps are mitigated and/or fully addressed. The result of the policy review and audit are retained for no less than 3 years.

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

Senior management shall assign an individual or group to ensure the effectiveness of the information protection program through program oversight, establish and communicate Healthwise's priorities for organizational mission, objectives, and activities, review and update of Healthwise's security plan, ensure compliance with the security plan by the workforce, and to evaluate and accept security risks on behalf of Healthwise. Senior management shall formally:

appoint a senior-level information security official for the development, implementation and administration of security matters;
establish and communicate Healthwise's priorities for information security mission, objectives, and activities;
ensure that Healthwise's information security processes are in place, are communicated to all stakeholders, and consider and address organizational requirements;
assign a single point of contact or group to provide program oversight (governance), review and update Healthwise's security plan, ensure compliance with the security plan by the workforce, and evaluate and accept information security risk on behalf of Healthwise;
formulate, review, and approve information security policies and a policy exception process;
periodically, at a minimum, annually, review and assess the effectiveness of the implementation of the information security policy;
provide clear direction and visible management support for security initiatives;
provide the resources needed for information security;
initiate plans and programs to maintain information security awareness; *. ensure that all appropriate measures are taken to avoid cases of identity theft targeted at patients, employees and third parties; *. ensure that the implementation of information security controls is coordinated across Healthwise; and *. determine and coordinate, as needed, internal or external information security specialists, and review and coordinate results of the specialists' advice throughout Healthwise.

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

The public shall have access to information about Healthwise's security and privacy activities and is able to communicate with its senior security official and senior privacy official.

3.1 Privacy Officer

Healthwise must formally appoint a Privacy Officer, who reports directly to the highest level of management. Healthwise's Privacy Officer shall be directly and fully responsible for Healthwise's individual privacy protection program. The appointment shall be based on professional qualities and, in particular, expert knowledge of data protection law and practices and the ability to fulfill required tasks. Responsibilities shall include:

the development, implementation, and maintenance of privacy policies and procedures;
serving as the point of contact for all privacy-related issues, including the receipt of privacy-related complaints; and
providing privacy-related guidance to managers, users, and service providers on their individual responsibilities and the specific procedures that should be followed.

The Privacy Officer will, in the performance of those tasks, have due regard to the risk associated with processing operations, taking into account the nature, scope, context and purposes of processing. The Privacy Officer may fulfill other tasks and duties; however, Healthwise ensures that any such tasks and duties do not result in a conflict of interests.

Healthwise will support the Privacy Officer in performing the tasks required by law or regulation by providing resources necessary to carry out those tasks and access to personal data and processing operations, and to maintain the Privacy Officer's expert knowledge. Healthwise shall ensure the Privacy Officer has the authority and discretion to perform the required tasks, including making decisions as action to be taken or not taken, and the ability to consult with advisors as he or she deems necessary. The Privacy Officer shall follow applicable law and/or regulations in the performance of those tasks, including applicable confidentiality requirements.

Healthwise shall not intimidate, threaten, coerce, discriminate against, or take other retaliatory action against the Privacy Officer for performing those tasks.

The current Healthwise Privacy Officer is Matt Berther (mberther@healthwise.org).

3.2 Security Officer

The senior-level information security official shall be employed by Healthwise and is responsible for its cybersecurity program in compliance with applicable regulatory requirements.

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 Healthwise security policies and non-compliance with the security regulations [164.308(a)(1)(ii)(c)], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].

The current Healthwise Security Officer is Matt Berther (mberther@healthwise.org).

3.2.1 Organizational Responsibilities

The Security Officer, in collaboration with the Privacy Officer, is responsible for facilitating the development, testing, implementation, training, and oversight of all activities pertaining to Healthwise's efforts to be compliant with the HIPAA Security Regulations, HITRUST CSF, and any other security and compliance frameworks as determined by management. The intent of the Security Officer's responsibilities is to maintain the confidentiality, integrity, and availability of ePHI. The Security Officer reports to the Healthwise CEO or delegate.

The Security Officer is responsible for securing the necessary resources and capital to implement the security and compliance program at Healthwise.

Senior management shall formally appoint security specialists and must review and coordinate results of the specialists' advice throughout Healthwise.

Healthwise will ensure plans for security testing, training and monitoring activities are developed, maintained, and executed in a timely manner. Healthwise reviews testing, training and monitoring plans for consistency with Healthwise's risk management strategy and organization-wide priorities for risk response actions.

3.2.2 Workforce Training Responsibilities

The Security Officer facilitates the training of all workforce members as follows:

New workforce members within their first month of employment;
Existing workforce members annually;
Existing workforce members whose functions are affected by a material change in the policies and procedures, within a month after the material change becomes effective;
Existing workforce members as needed due to changes in security and risk posture of Healthwise.

The Security Officer or delegate maintains documentation of the training session materials and attendees for a minimum of six years.

3.3 Workforce Responsibilities

User security roles and responsibilities shall be clearly defined and communicated. User roles and responsibilities include:

implementing and acting in accordance with Healthwise's information security policies;
protecting assets from unauthorized access, disclosure, modification, destruction or interference;
executing particular security processes or activities;
ensuring responsibility is assigned to the individual for actions taken; and
reporting security events or potential events or other security risks to Healthwise.

Security roles and responsibilities, as described in Healthwise's information security policy, and any involvement in processing covered information shall be documented in relevant job descriptions. The job description, including security roles and responsibility, shall be defined and clearly communicated to job candidates during the pre-employment process.

3.4 Supervision of Workforce Responsibilities

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

3.5 Sanctions of Workforce Responsibilities

All workforce members must report non-compliance of Healthwise'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 Healthwise's security policies and procedures. The Security Officer may request assistance from others. The Healthwise Security Officer will notify the individual's supervisor and the Human Resources team within 48 hours of initiating the sanctions process.

Violation of any security policy or procedure by workforce members may result in corrective disciplinary action, up to and including termination of employment. Violation of this policy and procedures by others, including Business Associates, customers, and partners may result in termination of the relationship and/or associated privileges. Violation may also result in civil and criminal penalties as determined by federal and state laws and regulations. A malicious violation of any security policy or procedure resulting in a breach of confidentiality (i.e. release of PHI to an unauthorized individual), change of the integrity of any ePHI, or unauthorized removal of any ePHI, requires immediate termination of the workforce member from Healthwise.

The Security Officer maintains all documentation of the investigation, sanctions provided, and actions taken to prevent reoccurrence for a minimum of six years after the conclusion of the investigation.

This Acceptable Use Policy covers the security and use of all Ignite Healthwise, LLC (Healthwise) information and IT equipment. It also includes the use of email, Internet, voice, and mobile IT equipment. This policy applies to all Healthwise Workforce.

This policy applies to all information, in whatever form, relating to Healthwise's business activities worldwide, and to all information handled by Healthwise relating to other organizations with whom it deals. It also covers all IT and information communications facilities operated by Healthwise or on its behalf.

Management must approve the use of information assets and takes appropriate action when unauthorized activity occurs.

4.1 Computer Access Control - Individual's Responsibility

Access to the Healthwise IT systems is controlled by the use of User IDs, passwords, and/or tokens. All User IDs and passwords are to be uniquely assigned to named individuals and consequently, individuals are accountable for all actions on Healthwise's IT systems.

Individuals must not:

Allow anyone else to use their User ID/token and password on any Healthwise IT system.
Leave their user accounts logged in at an unattended and unlocked computer.
Use someone else's User ID and password to access Healthwise's IT systems.
Leave their password unprotected (e.g., writing it down on a Post-It note).
Perform any unauthorized changes to Healthwise's IT systems or information.
Attempt to access data that they are not authorized to use or access.
Exceed the limits of their authorization or specific business need to interrogate the system or data.
Connect any non-Healthwise authorized device to the Healthwise corporate network or IT system.
Store Healthwise data on any non-authorized Healthwise equipment or on non-authorized cloud storage services.
Give or transfer Healthwise data or software to any person or organization outside Healthwise without the authority of Healthwise.

Team managers must ensure that individuals are given clear direction on the extent and limits of their authority with regard to IT systems and data.

4.2 Internet and Email Conditions of Use

Use of Healthwise Internet and email is intended for business use. Personal use is permitted where such use does not affect the individual's business performance, is not detrimental to Healthwise in any way, not in breach of any term and condition of employment and does not place the individual or Healthwise in breach of statutory or other legal obligations.

All individuals are accountable for their actions on the Internet and email systems.

Individuals must not:

Use the Internet or email for the purposes of harassment or abuse
Use profanity, obscenities, or derogatory remarks in communications
Access, download, send or receive any data (including images), which Healthwise considers offensive in any way, including sexually explicit, discriminatory, defamatory or libelous material.
Use the Internet or email to make personal gains or conduct a personal business.
Use the Internet or email to gamble.
Use the email systems in a way that could affect its reliability or effectiveness (e.g., distributing chain letters or spam).
Place any information on the Internet that relates to Healthwise, alter any information about it, or express any opinion about Healthwise, unless they are specifically authorized to do so.
Send unprotected sensitive or Confidential Information externally.
Forward Healthwise Confidential Information, including but not limited to PHI, to personal (non-Healthwise) email accounts (e.g., a personal Gmail account).
Make official commitments through the Internet or email on behalf of Healthwise unless authorized to do so.
Download copyrighted materials, such as music media (mp3) files, file and video files (not an exhaustive list) without appropriate approval.
In any way infringe any copyright, database rights, trademarks or other intellectual property.
Download any software not on the List of Approved Tools.

4.3 Clear Desk and Clear Screen Policy

Covered or critical business information shall not be left unattended or available for unauthorized individuals to access, including on desks, printers, copiers, fax machines, and computer monitors. Healthwise shall establish the following practices:

covered or critical business information must be locked away (ideally in a safe or cabinet or other forms of security furniture) when not required, especially when the office is vacated;
computers and terminals must be left logged off or protected with a screen and keyboard locking mechanism controlled by a password, token or similar user authentication mechanism that conceals information previously visible on the display when unattended and are protected by key locks, passwords or other controls when not in use;
incoming and outgoing mail points and unattended facsimile machines must be protected;
unauthorized use of photocopiers and other reproduction technology (e.g., scanners, digital cameras) must be prevented;
documents containing covered or classified information must be be removed from printers, copiers, and facsimile machines immediately; and
when transporting documents with covered information wtihin facilities and through inter-office mail, information must not be visible through envelope windows, and envelopes must be marked according to the information's classification level (e.g., Confidential).

In order to reduce the risk of unauthorized access or loss of information, Healthwise enforces a clear desk and screen policy as follows:

Personal or confidential business information must be protected using security features provided (e.g., secure print on printers)
Computers must be logged off/locked or protected with a screen locking mechanism controlled by a password when unattended.
Care must be taken to not leave confidential material on printers or photocopiers.
All business-related printed matter must be disposed of using confidential waste bins or shredders.

4.4 Working Off-site

It is accepted that laptops and mobile devices will be taken off-site. Upon hire, and annually thereafter, Healthwise will provide guidelines to Healthwise workforce that teleworks. The following controls must be applied:

Working away from the office must be in line with the Healthwise Remote Access Policy.
Equipment and media taken off-site must not be left unattended in public places and not left in sight in a car.
Laptops must be carried as hand luggage when traveling. Healthwise Workforce shall not take Healthwise equipment to locations deemed to be of significant risk in accordance with organizational policies and procedures.
Information should be protected against loss or compromise when working remotely (e.g., at home or in public places). Laptop encryption must be used.
Individuals should avoid connecting to unsecured wireless networks (i.e., those that do not require a password to join). If it is absolutely necessary, the individual should connect to a trusted VPN provider to secure their connection (e.g., the Healthwise corporate VPN).
Particular care should be taken with the use of mobile devices such as laptops, mobile phones, smart phones and tablets. They must be protected at least by a password or a PIN and, where available, encryption. Personal devices must be configured consistent with the Healthwise Personal Device Policy.

4.5 Mobile Storage Devices

Pursuant to the Disposable Media Policy, mobile devices such as memory sticks, CDs, DVDs, and removable hard drives may not be used to share any Healthwise confidential data.

4.6 Software

Individuals must only use software that is authorized by Healthwise on Healthwise's computers. Authorized software must be used in accordance with the software supplier's licensing agreements. All software on Healthwise computers must be approved and installed by the Healthwise IT department or on the List of Approved Tools.

4.7 Viruses

The Healthwise IT department will implement centralized, automated virus detection and virus software definition updates with in the Healthwise network. All servers and workstations must have anti-virus software installed to detect and remove any virus automatically.

Individuals must not:

Remove or disable anti-virus software.
Attempt to remove virus-infected files or clean up an infection, other than by use of approved Healthwise anti-virus software and procedures.

An individual shall not pay any ransom to return Healthwise data or personnel unless previously authorized, in writing, by the Healthwise Security Officer.

4.8 Telephony (Voice) Equipment Conditions of Use

Use of Healthwise voice equipment is intended for business use. Individuals must not use Healthwise's voice facilities for sending or receiving private communications if they incur additional expense for Healthwise, except in exceptional circumstances. All non-urgent personal communications should be made at an individual's own expense using alternative means of communications.

Individuals must not:

Use Healthwise's voice equipment for conducting private business.
Make hoax or threatening calls to internal or external destinations.
Accept reverse charge calls from domestic or international operators, unless it is for business use.

4.9 Actions upon Termination

All Healthwise equipment and data (e.g., laptops, mobile devices, telephones) must be returned to Healthwise at termination.

All Healthwise data or intellectual property developed or gained during the period of employment remains the property of Healthwise and must not be retained beyond termination or reused for any other purpose.

4.10 Healthwise Owned Computers and Peripherals

Although all Healthwise technology is meant for business use, Healthwise allows the reasonable personal use of technology subject to the following guidelines:

Personal use of Healthwise technology should not interfere with work.
Personal use of Healthwise technology should be consistent with the Healthwise principle of Do the Right Thing.

Healthwise provided devices are supported and maintained by the Service Desk. Users should not attempt any repairs or upgrades without contacting the Service Desk by phone or email. Users must immediately call the Healthwise Service Desk at (208) 331-6998 to report lost or stolen devices.

All Healthwise provided workstations are delivered to end users pre-configured to receive updates for the operating system and for the installed anti-virus software.

4.11 Monitoring and Filtering

Healthwise shall provide notice that the employee's actions may be monitored, and that the employee consents to such monitoring. Healthwise shall review and update the rules of behavior annually and requires individuals who have acknowledged a previous version of the rules of behavior to read and re-acknowledge when the rules of behavior are revised/updated.

All data that is created and stored on Healthwise computers is the property of Healthwise and there is no official provision for individual data privacy. However, wherever possible Healthwise will avoid opening personal emails and files.

IT system logging will take place where appropriate and investigations will commence where reasonable suspicion exists of a breach of this or any other policy. Healthwise has the right to monitor activity on its systems, including Internet and email use, in order to ensure systems security and effective operation, and to protect against misuse.

Any monitoring will be carried out in accordance with audited, controlled internal processes.

It is the responsibility of each Healthwise Workforce member to report suspected breaches of security policy without delay to their team manager and/or the information security department. All breaches of information security policies will be investigated. Where investigations reveal misconduct, disciplinary action may follow in line with Healthwise's Sanctions of Workforce Responsibilities.

The purpose of the Remote Access Policy is to describe the various means of remotely accessing Healthwise resources, including access to the Healthwise internal network and services and data stored in cloud providers or outside the Healthwise network, and the terms and guidelines under which remote access is granted.

Teleworking activities must be formally managed/controlled and are only authorized if suitable security arrangements and security controls that comply with relevant security policies and organizational requirements are in place. The following teleworking arrangements and controls are required:

The communications security requirements are addressed and account for the need for remote access to Healthwise's internal systems, the sensitivity of the information that will be accessed and pass over the communication link, and the sensitivity of the internal system.
The use of home networks and requirements/restrictions on the configuration of wireless network services, including encryption (AES WPA2, at minimum) are addressed.
Anti-virus protection, operating system and application patching, and firewall requirements consistent with corporate policy are addressed.
Revocation of authority and access rights and the return of equipment when the teleworking activities are terminated are addressed.
Verifiable unique IDs are required for all teleworkers accessing Healthwise's network via a remote connection.
The connection between Healthwise and the teleworker's location is secured via an encrypted channel.
Healthwise shall maintain ownership over the assets used by the teleworker.

5.1 Unauthorized Access

Strong authentication methods shall implemented for all external connections to Healthwise's network. Authentication of remote users shall be implemented using a password or passphrase and at least one of the following methods: a cryptographic based technique; biometric techniques; hardware tokens; software tokens; a challenge/response protocol; or certificate agents.

Allowing access to network resources from remote locations is a necessary business function but introduces significantly increased risk of unauthorized access. Healthwise depends on its employees and contract employees to understand those risks and take appropriate measures to minimize them. This includes keeping passwords unique and confidential, keeping virus protection software up to date, and preventing unauthorized access to devices having the keys to Healthwise networks.

Remote access by vendors and business partners (e.g., for remote maintenance) shall be disabled/deactivated when not in use unless specifically authorized by management. Remote access to business partner accounts (e.g., remote maintenance) must be immediately deactivated after use.

5.2 Passwords

Unique and confidential passwords are critical to network security, and even more so when users have remote access privileges. Please refer to the Password Policy for more information.

5.3 Antivirus

Antivirus software is required for any computer connecting to Healthwise resources. Antivirus software is installed and configured by IT on all Healthwise-owned computers. For other devices, antivirus should be configured to check for virus updates regularly.

5.4 Software Currency

Any hardware or software used to connect to Healthwise resources must be using an actively supported and patched version of provided software / firmware. Software includes the Operating System of the device as well as the VPN client, Internet Browser and other applications used to access Healthwise resources. Devices that are not able to be updated or are no longer supported and patched by the vendor must not be used.

5.5 Foreign Devices

A foreign device is any computer not owned by Healthwise that is used to remotely access Healthwise network resources. This includes computers owned by employees and contract employees. This also includes computers used for outside access including those at a client site, hotel, trade show, friend or family home, etc.

The Service Desk provides support to Healthwise staff to configure and use remote access features from a foreign device. They do not, however, provide support for the foreign devices themselves. That includes problems with hardware, operating system, or internet connectivity.

5.6 Internet Service Providers (ISP)

The Service Desk provides support to Healthwise staff on issues related to internet connectivity services where the internet service is coordinated and funded by Healthwise. This is not generally the case for offsite employees.

The Service Desk does not support internet services not acquired and funded by Healthwise. Internet connectivity problems must be resolved between the person owning the service and the service provider.

5.7 Staff Member Responsibility

Remote access agreements are authorized only if the arrangements and controls comply with the Healthwise security policies. Healthwise requires contractors to read and sign an access agreement indicating their responsibilities to protect against the unauthorized disclosure of information, theft of equipment, and unauthorized access to Healthwise's Systems. Remote access is removed when no longer required.

It is the responsibility of the employee or contract employee to read and understand this policy, understand the risks inherent with remote access and do their part to prevent unauthorized access. If an employee or contract employee is unclear on any of the content of this document, they should contact the Service Desk by phone or email for clarification. Failure to comply with the guidelines and requirements set forth in this document may result in suspension of remote access privileges.

Ignite Healthwise, LLC (Healthwise) makes every effort to assure all third-party organizations are compliant and do not compromise the confidentiality, integrity, and availability of Healthwise or Healthwise Customer data. Third Parties include Customers, Partners, Vendors, subcontractors and contracted developers.

6.1 Policies to Assure Third Parties Support Healthwise Compliance

Access to Healthwise's information and systems by external parties shall not be permitted until due diligence has been conducted, the appropriate controls have been implemented, and a contract/agreement reflecting the security requirements is signed acknowledging they understand and accept their obligations. Due diligence must be conducted prior to establishing a formal relationship with the service provider and includes an evaluation of the information security risks posed by the external party, and identifies any requirements for specific controls where access to sensitive information (e.g., covered information) by the external parties is required. The contract, where feasible, shall define the terms and conditions for the connection or access and the working arrangement. All security requirements resulting from work with external parties or internal controls shall be reflected by the agreement with the external party. Healthwise must ensure the external party is aware of their obligations, and accepts the responsibilities and liabilities involved in accessing, processing, communicating, or managing Healthwise's information and information assets.

Remote access connections between Healthwise and external parties must be encrypted. Any covered information shared with an external party must be encrypted prior to transmission.

The identification of risks related to external party access shall take into account a minimal set of specifically defined issues:

the information asset(s) an external party is required to access;
the type of access the external party will have to the information and information asset(s), such as:
- physical access (e.g., to offices, computer rooms, filing cabinets);
- logical access (e.g., to an organization's databases, information systems);
- network connectivity between Healthwise’s and the external party's network(s) (e.g., permanent connection, remote access);
- whether the access is taking place on-site or off-site;
the value and sensitivity of the information involved, and its criticality for business operations;
the controls necessary to protect information that is not intended to be accessible by external parties;
the external party personnel involved in handling Healthwise’s information;
how Healthwise or personnel authorized to have access can be identified, the authorization verified, and how often this needs to be reconfirmed;
the different means and controls employed by the external party when storing, processing, communicating, sharing and exchanging information;
the impact of access not being available to the external party when required, and the external party entering or receiving inaccurate or misleading information;
practices and procedures to deal with information security incidents and potential damages, and the terms and conditions for the continuation of external party access in the case of an information security incident;
legal and regulatory requirements and other contractual obligations relevant to the external party that shall be taken into account;
how the interests of any other stakeholders may be affected by the arrangements.

Access granted to external parties shall be limited to the minimum necessary to minimize risks to security, granted only for the duration needed, and must be revoked when no longer needed.

A standard agreement with third parties shall be defined and includes the required security controls in accordance with Healthwise's security policies. The following terms must be implemented for inclusion in the agreement:

the information security policy;
controls to ensure asset protection, including:
- procedures to protect organizational assets, including information, software and hardware;
- any required physical protection controls and mechanisms;
- controls to ensure protection against malicious software;
- procedures to determine whether any compromise of the assets (e.g., loss or modification of information, software and hardware) has occurred;
- controls to ensure the return or destruction of information and assets at the end of, or at an agreed point in time during the agreement;
- confidentiality, integrity, availability, and any other relevant property of the assets; and
- restrictions on copying and disclosing information, and using confidentiality agreements;
user and administrator training in methods, procedures, and security;
ensuring user awareness for information security responsibilities and issues;
provision for the transfer of personnel, where appropriate;
responsibilities regarding hardware and software installation and maintenance;
a clear reporting structure and agreed reporting formats;
provisions for changing systems or configurations, consistent with Healthwise's configuration management policies and procedures;
access-control policy, covering:
- the different reasons, requirements, and benefits that make the access by the third-party necessary;
- permitted access methods, and the control and use of unique identifiers such as user IDs and passwords;
- an authorization process for user access and privileges;
- a requirement to maintain a list of individuals authorized to use the services being made available, and what their rights and privileges are with respect to such use;
- a statement that all access that is not explicitly authorized is forbidden; and
- a process for revoking access rights or interrupting the connection between systems;
arrangements for reporting, notification (e.g., how when and to whom), and investigation of information security incidents and security breaches, as well as violations of the requirements stated in the agreement, stating:
- the third-party, following the discovery of a breach of unsecured covered information, shall notify Healthwise of such breach, including the identification of each individual whose unsecured protected health information has been, or is reasonably believed by the business associate to have been, accessed, acquired, or disclosed during such breach;
- all notifications shall be made without unreasonable delay and in no case later than 30 calendar days after the discovery of a breach if the Business Associate is an agent of the covered entity, otherwise the timing of the notification should be explicitly addressed in the contract if the Business Associate is not an agent of the covered entity;
- evidence shall be maintained demonstrating that all notifications were made without unreasonable delay; and
- any other information that may be needed in the notification to individuals, either at the time notice of the breach is provided or promptly thereafter as information becomes available.
a description of the product or service to be provided, and a description of the information to be made available along with its security classification;
the target level of service and unacceptable levels of service;
the definition of verifiable performance criteria, their monitoring and reporting;
the right to monitor, and revoke, any activity related to Healthwise’s assets;
the right to audit responsibilities, defined in the agreement, to have those audits carried out by a third-party, and to enumerate the statutory rights of auditors;
the penalties exacted in the event of any failure in respect of the above;
the establishment of an escalation process for problem resolution;
service continuity requirements, including measures for availability and reliability, in accordance with an organization's business priorities;
the respective liabilities of the parties to the agreement;
responsibilities with respect to legal matters and how it is ensured that the legal requirements are met (e.g., data protection legislation) especially taking into account different national legal systems if the agreement involves co-operation with organizations in other countries;
intellectual property rights (IPRs) and copyright assignment and protection of any collaborative work; and
conditions for renegotiation/termination of agreements:
- a contingency plan shall be in place in case either party wishes to terminate the relation before the end of the agreements;
- renegotiation of agreements if the security requirements of Healthwise change; and
- current documentation of asset lists, licenses, agreements or rights relating to them.

Healthwise requires third-party providers to notify a designated individual or role (e.g., a member of the contracting or supply chain function) of any personnel transfers or terminations of third-party personnel who possess organizational credentials and/or badges, or who have information system privileges within fifteen (15) calendar days.

Healthwise will maintain written agreements (contracts) that include: an acknowledgement that the third-party (e.g., a service provider) is responsible for the security of the data the third-party possesses or otherwise stores, processes or transmits on behalf of Healthwise (or to the extent that they could impact the security of Healthwise's information environment) and requirements to address the associated information security risks; and requirements to address the information security risks associated with information and communications technology services (e.g., cloud computing services) and product supply chain.

In the case of outsourcing arrangements, Healthwise shall plan the necessary transitions (e.g., of information, information processing systems, and anything else that needs to be moved), and ensures that security is maintained throughout the transition period. Healthwise shall ensure that the third party maintains sufficient service capabilities together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster.

Where software development is outsourced, formal contracts shall be in place to address the ownership and security of the code and application. Outsourced software development contracts address licensing arrangements, code ownership, intellectual property rights, certification and rights of access for the audit of the quality and accuracy of work, escrow arrangements, quality and security functionality requirements for the developed code, and security testing and evaluation prior to installation.

Healthwise shall ensure that Customers and Partners are aware of their obligations and rights, and accept the responsibilities and liabilities involved in accessing, processing, communicating, or managing Healthwise's information and information assets. The following security terms must be addressed prior to giving customers access to any of Healthwise's assets: description of the product or service to be provided; the right to monitor, and revoke, any activity related to Healthwise’s assets; and the respective liabilities of Healthwise and the customer.

In the event that Healthwise stores Electronic Protected Health Information ("ePHI) generated by or on behalf of a Customer or Partner, Healthwise will execute a Business Associate Agreement that includes the required security controls in accordance with Healthwise's security policies. Additionally, responsibility is assigned in these agreements. No Healthwise Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other third parties.

Service Level Agreements (SLAs) or contracts with an agreed service arrangement shall address liability, service definitions, security controls, and other aspects of services management. Subcontractors must coordinate, manage, and communicate any changes to services provided to Healthwise. Changes to third party services are classified as configuration management changes and thus are subject to the policies and procedures described in §13; substantial changes to services provided by third parties will invoke a Risk Assessment as described in §17. Healthwise utilizes monitoring tools to regularly evaluate Vendors against relevant SLAs.

Regular progress meetings shall be conducted to review SLA reports, audit trails, security events, operational issues, failures, and disruptions. Information about information security incidents shall be provided to Healthwise's incident response team. This information shall be reviewed by Healthwise and the third party that experienced the incident, as required by the agreement and any supporting guidelines and procedures. Identified problems or issues shall be investigated and resolved accordingly.

Healthwise maintains and annually reviews a list of all current Vendors and subcontractors. Any changes to Vendor and subcontractor services and systems are reviewed before implementation. These reviews are performed by the Healthwise Security Officer, Privacy Officer, and legal department as necessary.

Healthwise shall monitor security control compliance by external service providers on an ongoing basis. Monitoring involves a service management relationship and process between the organization and the third party. The organization monitors the network service features and service levels to detect abnormalities and violations. Healthwise uses an external service provider to measure Vendor or subcontractor compliance with security controls and service level availability.

6.2 Approved Tools

Healthwise uses a suite of approved software tools for internal use by Workforce members. These software tools are either self-hosted, with security managed by Healthwise, or they are hosted by a Vendor with appropriate Business Associate Agreements in place to preserve data integrity. Free software tools made available by a Vendor at no cost to Healthwise must still be submitted through the software approval procedure for approval before use. Use of other tools for the purposes detailed in the List of Approved Tools requires approval from the Healthwise Chief Technology Officer or delegate.

Healthwise maintains a list of unauthorized software programs that are prevented from execution on Healthwise Systems. The Security Officer or delegate reviews this list no less than annually.

6.2.1 List of Approved Tools

Office 365. Office 365 is used for email, telephony, analytics, and other collaboration tools.
Bitbucket. Bitbucket is a tool built on top of Git, the version control platform. Bitbucket is hosted and secured by Atlassian. This tool is used for storage of configuration scripts, infrastructure automation tools, policy documents, and source and version control of application code used by Healthwise.
JIRA. JIRA is used for configuration management and to generate artifacts for compliance procedures.
Confluence. Confluence is used for knowledge management.
SalesForce. SalesForce is used for customer relationship management.

The comprehensive list of approved software tools for employee use is maintained on the Healthwise Approved Software page. If Healthwise Workforce members require the use of an additional tool, approval must be obtained through the software approval procedure. This procedure is maintained by the Chief Technology Officer or delegate.

6.3 Third-Party Software in Healthwise Products

Healthwise maintains a list of approved third-party software (including open source) that may be included in Healthwise software offerings. Any additions to the approved third-party software list must be obtained in advance through the established Third-Party Licensing procedures. These procedures are maintained by the Chief Technology Officer or delegate.

6.4 Open Source

Healthwise values employee productivity and encourages the use of open source software to lower total cost of ownership, enable faster time to market, and build the knowledge of employees. Healthwise evaluates open source software in the software acquisition process as both a viable alternative and a way to negotiate prices on non-open source software. Teams using open source software make sure the software meets their needs, verify that appropriate support options are in place, and complete the open source license review process.

Healthwise supports employees contributing source code to open source projects, including company-sponsored open source projects. To protect Healthwise interests, employees must receive explicit permission to contribute fixes or projects to the open source community.

The purpose of the Personal Device Policy is to provide Ignite Healthwise, LLC (Healthwise) Workforce with the flexibility of using personal devices, not including Blacklisted Devices, to conduct business related work while protecting the security and integrity of the Healthwise infrastructure. This policy is applicable to all Workforce that use a personal electronic device (personal device) to connect to the Healthwise infrastructure.

7.1 Approved Personal Devices

Personal devices include personal computers, laptops, tablets, smartphones, watches, eReaders, or any other electronic item capable of connecting to the Healthwise infrastructure (collectively, each a personal device). Personal devices that are currently supported by the manufacturer, loaded with an officially supported operating system, and updated as recommended may connect to the Healthwise infrastructure, except for those categorized by Healthwise as a Blacklisted Device. Certain devices, including Blacklisted Devices, are not allowed to connect to the Healthwise infrastructure, including, but not limited to, non-Healthwise-owned computers, rooted (Android) or jailbroken (iOS) devices. Questions on whether your device may be connected to the Healthwise infrastructure should be directed to the Service Desk.

7.2 Service Desk Support

Personal devices will not be purchased or maintained by Healthwise. All costs associated with the purchase and maintenance of personal devices are the responsibility of the employee.

In order to properly configure the settings and security tools, personal devices must be presented to the Service Desk prior to connecting to the Healthwise infrastructure. Healthwise enforces password policies on personal devices connected to the Healthwise infrastructure using technical controls. Employees are responsible for maintaining the settings configured by the Service Desk. Only connectivity issues relating to the Healthwise infrastructure will be supported by the Service Desk. Employees should contact the manufacturer or their carrier for operating system or hardware-related issues.

7.3 Guidelines for Use of Approved Personal Devices for Business Purposes

Upon hire, and annually thereafter, Healthwise will provide guidelines to Healthwise workforce that use approved personal devices. These guidelines include:

Approved personal devices may only connect to the mobile device network (HW-Mobile) and not the corporate wireless (HW-Corp) or any wired network. Healthwise will monitor for unauthorized mobile devices connecting to its corporate network.
Approved personal devices must be password protected using the features of the device and a strong password that meets the requirements of the Healthwise Information Security Policy.
As business needs require, Healthwise may monitor, track, and log all activities and/or disconnect or disable personal devices while connected to the Healthwise infrastructure. Users have no expectation of privacy while connected to or using the Healthwise infrastructure.
The employee will not download applications from any application store that is not officially supported by the device manufacturer. Official application stores include Google Play, iTunes Store, and the Microsoft Store.
The employee is responsible for the loss of Healthwise data or personal data due to an operating system crash, errors, bugs, viruses, malware, and/or other software or hardware failures, or programming errors that render the personal device unusable.
Personal devices that have been connected to the Healthwise infrastructure may be remotely wiped by Healthwise if the device is lost or stolen, or IT detects a data or policy breach, a virus, or similar threat to the security of the Healthwise infrastructure. Remotely wiping the device will be a last resort after discussions with the owner of the personal device reveal there is no better alternative. Personal devices that have been connected to the Healthwise infrastructure may also be remotely wiped by Healthwise if the employment relationship ends and Healthwise has concrete evidence the individual has malicious intentions to keep or redistribute information that is considered to be Healthwise intellectual property or client information. Healthwise acknowledges that individuals may back up the contents of their personal devices using third-party backup tools and servers. Some sensitive data may be included in these backups, such as contacts, emails, and expense reports. Individuals will not intentionally offload or backup Healthwise information separate from the general device backup recommendations.
Non-exempt employees should not use their personal devices for business purposes outside of regular work hours unless requested to do so by his/her supervisor. All hours worked must be recorded on their timesheet. Working unauthorized overtime is strictly prohibited. Questions should be directed to Human Resources.

Employees should use good judgment when connected to the Healthwise infrastructure and may not engage in any activity that violates Healthwise employee policies, laws or regulations, or the rights of any third party. Violations of the Personal Device Policy may result in disciplinary action up to and including suspension of any and all technology use or connectivity and termination. Questions about this policy should be directed to the Service Desk or Human Resources. Exceptions to the Personal Device Policy must be approved in advance by the Healthwise Security Officer.

Healthwise, based on the data classification level, shall register media (including laptops) prior to use, places reasonable restrictions on how such media be used, and provides an appropriate level of physical and logical protection (including encryption) for media containing covered information until properly destroyed or sanitized. Media containing covered information must be physically stored and its data encrypted in accordance with Healthwise's data protection and privacy policy on the use of cryptographic controls until the media are destroyed or sanitized and commensurate with the confidentiality and integrity requirements for its data classification level.

Media must be labeled, encrypted, and handled according to its classification. Procedures for handling, processing, communication and storage of information (including information media awaiting disposal) are established to protect data from unauthorized disclosure or misuse including physical and technical access restrictions commensurate with the data classification level; and handling and labeling of all media according to its indicated classification (sensitivity) level.

The status and location of unencrypted covered information must be maintained and monitored.

8.1 Disposable Media Policy

Healthwise restricts the use of removable media. Healthwise Workforce may not use removable media to share any Healthwise confidential data.

Healthwise assumes all disposable media in its Platform may contain ePHI, so it treats all disposable media with the same protections and disposal policies. All destruction/disposal of ePHI media will be done in accordance with federal and state laws and regulations and pursuant to the Retention Schedule. Records that have satisfied the period of retention will be destroyed/disposed of in an appropriate manner.

Records involved in any open investigation, audit or litigation should not be destroyed/disposed of. If notification is received that any of the above situations have occurred or there is the potential for such, the record retention schedule shall be suspended for these records until such time as the situation has been resolved. If the records have been requested in the course of a judicial or administrative hearing, a qualified protective order will be obtained to ensure that the records are returned to Healthwise or properly destroyed/disposed of by the requesting party.

All Healthwise Workforce 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.

Before reuse of any media, all ePHI is rendered inaccessible, cleaned, or scrubbed. All media is formatted to restrict future access. Any media containing ePHI is disposed consistent with NIST 800-88 Revision 1 Guidelines for Media Sanitization. The methods of destruction, disposal, and reuse are reassessed periodically, based on current technology, accepted practices, and availability of timely and cost-effective destruction, disposal, and reuse technologies and services.

Ignite Healthwise, LLC (Healthwise) limits access to Healthwise's Systems for all users, including but not limited to Workforce members, Business Associates, contracted providers, and any other entity, and is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized use or Access of Healthwise's Systems. These safeguards have been established to address HIPAA Security regulations including the following standards:

9.1 Access Establishment and Modification

Requests for Access to Healthwise's Systems are made formally. User identities must be verified, in person where possible, prior to granting Access to new accounts. Proper identification and request approval shall be required for requests to establish information system accounts. The method used to verify the user's identity must be stored with the access request. All requests for access are retained for future reference in accordance with the Retention Schedule.

User registration and de-registration shall:

communicate password procedures and policies to all users who have system access;
confirm the user has authorization from the system owner for the use of the information system or service;
separate approval for access rights from management;
confirm the level of access granted is appropriate to the business purpose and is consistent with Healthwise's security policy;
give users a written statement of their access rights;
require users to provide written acknowledgement indicating that they understand the conditions of access;
ensure service providers do not provide access until authorization procedures have been completed;
ensure default accounts are removed and/or renamed;
maintain a formal record of all persons registered to use the service;
remove or block critical access rights of users who have changed roles or jobs or left Healthwise immediately and remove or block non-critical access within 24 hours; and
automatically remove or disable accounts that have been inactive for a period of 60 days or more.

Access to the information systems shall be the minimum necessary for assigned official duties and intended system usage. Such usage/access shall be granular enough to support patient or participant consent captured by Healthwise and should limit access, use, or disclosure based on the minimum necessary to satisfy a particular purpose or carry out a function.

Acceptable use agreements must be signed by all employees before being allowed access to information assets. Employees shall be notified their actions may be monitored and that, through signing an acceptable use agreement, they have consented to such monitoring.

Before allowing access to system components or data, the organization shall require verifiable unique IDs for all types of users including, but not limited to, technical support personnel, operators, network administrators, system programmers, and database administrators.

Management must ensure employees, contractors and third-party users:

are properly briefed on their information security roles and responsibilities prior to being granted access to covered information or information systems;
are provided with guidelines to state security expectations of their role within Healthwise;
are motivated and comply with the security policies of Healthwise;
achieve a level of awareness on security relevant to their roles and responsibilities within Healthwise;
conform to the terms and conditions of employment, which includes Healthwise's information security policy and appropriate methods of working; and
continue to have the appropriate skills and qualifications to apply security in accordance with Healthwise policies and procedures.

The Security Officer or delegate will approve access to Healthwise's Systems as dictated by the Workforce member'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.

A background check is required for all Healthwise Workforce members. After the check is complete, the Security Officer approves or rejects the request. If the request is rejected, it goes back for further review and documentation. Access is not granted until receipt, review, and approval by the Healthwise Security Officer.

User's access rights shall be reviewed after any changes, such as promotion, demotion, or termination of employment, or other arrangement with a workforce member ends. Further, access rights shall be reviewed and re-allocated when moving to another role within Healthwise.

System and service administrators must be notified when users' access rights change (e.g., termination, change in position) and modify the user's account accordingly. Account managers must be notified when users are terminated or transferred, their information system usage or need-to-know/need-to-share changes, or when accounts (including shared/group, emergency, and temporary accounts) are no longer required.

All access to Healthwise's Systems are reviewed and updated on a bi-annual basis to ensure proper authorizations are in place commensurate with job functions. The Director of Technology Operations and Security Officer are responsible for these procedures.

Access to Healthwise's Systems is controlled using centralized user management and authentication. Temporary accounts are not used unless approved in advance by the Healthwise Security Officer. Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily. Accounts that are inactive for over 60 days are removed. Generic accounts are not allowed on Healthwise Systems.

Privileged users must first access systems using standard, unique user accounts before switching to privileged users and performing privileged tasks. For production systems, this is enforced by creating non-privileged user accounts that must invoke Windows User Access Control to perform privileged tasks.

All application to application communications using service accounts are restricted and not permitted unless absolutely needed. Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access.

The information system must employ replay-resistant authentication mechanisms such as nonce, one-time passwords, or time stamps to secure network access for privileged accounts; and, for hardware token-based authentication, employ mechanisms that satisfy minimum token requirements discussed in NIST SP 800-63-2, Electronic Authentication Guideline. Appropriate authentication methods including strong authentication methods in addition to passwords shall be used for communicating through an external, non-Healthwise-controlled network (e.g., the Internet).

Remote access is granted through encrypted VPN tunnels that utilize two-factor authentication. VPN connections use 256-bit AES 256 encryption, or equivalent. If encryption or two-factor authentication is not used, prior to granting access, the Healthwise Security Officer must approve the access request in writing.

In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access.

9.2 Workforce Clearance

The level of security assigned to a user of Healthwise's Systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user's job classification. Healthwise maintains a minimum necessary approach to access Customer data. All access requests are treated on a least-access principle. As such, Healthwise Workforce does not have ready access to any Unsecured ePHI.

Specific user actions that can be performed on the information system without identification or authentication shall be identified and supporting rationale documented. Actions to be performed without identification and authentication shall be permitted only to the extent necessary to accomplish mission objectives.

9.3 Access Authorization

Role-based access categories for each Healthwise System are pre-approved by the Security Officer or delegate.

9.4 Person or Entity Authentication

Each workforce member has and uses a unique user ID and password that identifies him/her as the user of the information system. Each Customer and Partner has and uses a unique user ID and password that identifies him/her as the user of the information system. All Customer support desk interactions must be verified before Healthwise support personnel will satisfy any request having information security implications.

9.5 Unique User Identification

Access to Healthwise's Systems is controlled by requiring unique User Login IDs and passwords for each individual user and developer. Shared user or group IDs shall only be used in exceptional circumstances, where there is a clear business benefit. In this case, additional controls shall be required to maintain accountability and management approval shall be documented. Generic IDs for use by an individual shall only be allowed where the functions accessible or actions carried out do not need to be traced (e.g., read-only access).

Password requirements mandate strong password controls (§9.11) and are not displayed at any time and are not transmitted or stored in plain text.

Default accounts on Healthwise's Systems, including root, are disabled. Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with Healthwise workstations or production systems.

Support staff verifies the identity of a user, either in-person or through a separate communication channel, prior to working on any request that has security implications.

9.6 Automatic Logoff and Lock

A time-out system (e.g., a screen saver) shall pause the session screen after 15 minutes of inactivity; close network sessions after 30 minutes of inactivity; and require the user to reestablish authenticated access once the session has been paused or closed; or, if the system cannot be modified, use a limited form of time-out that clears the screen but does not close down the application or network sessions.

The Security Officer pre-approves exceptions to automatic log off and lock requirements.

9.7 Workforce Member Workstation Use

Mobile computing devices shall be protected at all times by access controls, usage restrictions, connection requirements, encryption, virus protections, host-based firewalls or equivalent functionality, secure configurations, and physical protections. Protections shall include the following:

Healthwise shall use full-disk encryption to protect the confidentiality of information on laptops and other mobile devices that support full-disk encryption and is enforced through technical controls;
A mobile computing policy shall be developed and include Healthwise’ definition of mobile devices, acceptable usage, and the requirements for physical protection, access controls, cryptographic techniques, back-ups, and virus protection;
Healthwise installs personal firewall software or equivalent functionality on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access Healthwise's network;
Mobile computing devices are physically protected against theft especially when left, for example, in cars and other forms of transport, hotel rooms, conference centers, and meeting places;
Healthwise only authorizes connections of mobile devices meeting organizational usage restrictions, configuration requirements, connection requirements, and implementation guidance; enforce requirements for the connection of mobile devices to sensitive information systems; and
Information system functionality on mobile devices that provides the capability for automatic execution of code without user direction is disabled.

All workstations at Healthwise are company owned, and all are either Dell products running Microsoft Windows or Apple products running Mac OSX. Prior to deployment, workstations are classified, dependent on the workforce member's level of access; given a baseline hardened security configuration; and registered with the Healthwise asset inventory tracking system. Workstation hard drives will be encrypted using Microsoft BitLocker, Apple FileVault 2.0 or equivalent. Workstations connected to Healthwise networks rely on a network-based firewall to prevent unauthorized access. When Healthwise workstations are connected to non-Healthwise networks, a host-based firewall is enabled to prevent unauthorized access, unless explicitly granted.

Workstations may not be used to engage in any activity that is illegal or is in violation of Healthwise'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 Healthwise'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 Healthwise's best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval from Healthwise's Chief Legal Officer.

Solicitation of non-company business, or any use of Healthwise's Systems for personal gain is prohibited.

Transmitted messages may not contain material that criticizes Healthwise, its providers, its workforce, or others.

Users may not misrepresent, obscure, suppress, or replace another user's identity in transmitted or stored messages.

9.8 Wireless Access Use

Healthwise Hosted Environment systems are not accessible directly over wireless channels. Wireless access is disabled on all Hosted Environment systems. When accessing the Hosted Environment systems via remote wireless connections, the same system access policies and procedures apply to wireless as all other connections, including wired.

Wireless access shall be explicitly approved, and wireless access points and devices shall have appropriate (e.g., FIPS-approved; minimum of AES WPA2) encryption enabled for authentication and transmission.

When configuring wireless access points and devices, Healthwise shall change the following:

vendor default encryption keys;
encryption keys anytime anyone with knowledge of the keys leaves the company or changes positions;
default SNMP community strings on wireless devices;
default passwords/passphrases on access points; and
other security-related wireless vendor defaults, if applicable.

Passwords used to access the wireless network must be rotated on a regular basis. Healthwise maintains an inventory of authorized wireless access points and their secure location. Healthwise scans the Corporate Environment for rogue access points no less than quarterly.

9.9 Workforce Termination Procedures

Access rights to information assets and facilities shall be reduced or removed before the employment or other workforce arrangement terminates or changes, depending on the evaluation of risk factors including:

whether the termination or change is initiated by the employee, contractor, third-party user, other workforce member, or by management and the reason of termination;
the current responsibilities of the employee, contractor, workforce member or any other user; and
the value of the assets currently accessible.

The Human Resources Department (or other designated department) and the departing Workforce member's supervisor are required to notify the Security Officer or delegate upon completion and/or termination of access needs and facilitate the completion of the Departing Employee Procedure. Unless approved in writing by the Security Officer or delegate, a terminated Workforce member will not have unchaperoned access to any Healthwise facility or system.

Access rights for the terminated individual shall be disabled in a timely manner, at least within twenty-four (24) hours.

Further, changes of employment or other workforce arrangement (e.g., transfers) shall be reflected in removal of all access rights that were not approved for the new employment or workforce arrangement. Access changes due to personnel transfer shall be managed effectively. Old accounts shall be closed after ninety (90) days, and new accounts shall be opened. The access rights that shall be removed or adapted include physical and logical access, keys, identification cards, IT systems and application, subscriptions, and removal from any documentation that identifies them as a current member of the organization. If a departing employee, contractor, third-party user or other workforce member has known passwords for accounts remaining active, these shall be changed upon termination or change of employment, contract, agreement, or other workforce arrangement.

The Security Officer or delegate audits and may terminate access of Workforce members that have not logged into Healthwise's Environment for an extended period of time.

9.10 Paper Records

Healthwise does not use paper records for any Protected Health Information. Use of paper for recording and storing Protected Health Information is against Healthwise policies.

9.11 Password Management

User IDs and passwords are used to control access to Healthwise's Systems and may not be disclosed to anyone for any reason. Users may not allow anyone, for any reason, to have access to any information system using another user's unique credentials, including, but not limited to: user ID and password; or an access token or key generated by the user that is used to authenticate as that user.

Password policies, applicable to mobile devices, shall be documented and enforced through technical controls on all company devices or devices approved for BYOD usage, and prohibit the changing of password/PIN lengths and authentication requirements for reading e-mail, composing documents, or surfing the Internet.

Healthwise shall:

maintain a list of commonly-used, expected or compromised passwords, and updates the list at least every 180 days and when organizational passwords are suspected to have been compromised, either directly or indirectly;
verify, when users create or update passwords, that the passwords are not found on Healthwise-defined list of commonly-used, expected or compromised passwords;
allow users to select long passwords and passphrases, including spaces and all printable characters, consistent with NIST 800-63B Digital Identity Guidelines; and
employ automated tools to assist the user in selecting strong passwords and authenticators.

On all systems and applications in the Healthwise environment, password configurations are set to require: a minimum length of 12 characters; any printable character, including spaces; and account lockout after 5 invalid attempts.

Healthwise shall transmit passwords only when cryptographically-protected and store passwords using an approved hash algorithm and salt. Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in §11.7. All passwords used in configuration scripts are secured and encrypted.

Passwords are inactivated upon a Workforce member's termination (refer to the Workforce Termination Procedures in §9.9).

Healthwise must change passwords for default system accounts, whenever there is any indication of password compromise, at first logon following the issuance of a temporary password and requires immediate selection of a new password upon account recovery. Any temporary passwords used must be unique and not reasonably guessable. Users must acknowledge receipt of passwords and upon initial login must change any passwords that were automatically generated for them. Password change methods must use a confirmation method to correct for user input errors.

If a user believes their user ID has been compromised, they are required to immediately report the incident to the Service Desk. In the event a user's password is compromised, the password is changed.

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 the service desk. 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 Skype.
Once verified, the administrator resets the password.

The service desk ticketing system is used to track and store password reset requests.

9.12 Unauthorized Access

The Human Resources Department (or other designated department) and the Workforce member's supervisor are required to notify the Security Officer or delegate to terminate a user's access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):

The user has been using their access rights inappropriately;
A user's password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
An unauthorized individual is utilizing a user's User Login ID and password (a new password may be provided to the user if the user is not identified as providing the unauthorized individual with the User Login ID and password).

9.13 Access to ePHI

Copy (including print screen), move, print, and storage of sensitive data shall be prohibited when accessed remotely without a defined business need.

Healthwise uses technical controls to ensure that Workforce may not copy, move, print, or store ePHI outside of the Hosted Environment without a definied business need. Workforce may not download employee ePHI to any workstations unless authorized by the Healthwise Privacy Officer, Healthwise Security Officer, or delegate. Disallowing transfer of ePHI to workstations is enforced through technical measures. All Hosted Environment production access is performed through a bastion/jump host accessed through a VPN. Direct access to the Hosted Environment production systems is disallowed by Healthwise's VPN configuration. On the Hosted Environment production Windows bastions, local drive mappings are disabled by Group Policy settings. Configuration settings for enforcing these technical controls are managed by Healthwise's Configuration Management Tooling.

Access to ePHI is denied by default and permitted by exception. Healthwise will maintain a current list of all Healthwise workforce members with access to ePHI.

9.14 Privilege Management

The allocation of privileges for all systems and system components shall be controlled through a formal authorization process. Access privileges associated with each system product (e.g., operating system, database management system and each application) and the users to which they need to be allocated shall be identified. Privileges shall be allocated to users on a need-to-use basis and on an event-by-event basis in line with the access control policy (i.e. the minimum requirement for their functional role, e.g., user or administrator, only when needed).

Access requests are approved by the Healthwise Security Officer or delegate and is limited to the minimum necessary to perform a job function.

Healthwise shall explicitly authorize access to the following list of security functions (deployed in hardware, software, and firmware) and security-relevant information:

setting/modifying audit logs and auditing behavior;
setting/modifying boundary protection system rules;
configuring/modifying access authorizations (i.e., permissions, privileges);
setting/modifying authentication parameters; and
setting/modifying system configurations and parameters.

Healthwise security functions are defined by the Healthwise Security Officer and access to these functions are formally authorized and controlled. Security functions must be performed by a privileged account that is not used for normal business use. Privileged functions are audited and Healthwise systems prohibit non-privileged users from executing the defined security functions.

All file system access not explicitly required for system, application, and administrator functionality shall be disabled. Healthwise will ensure only authorized users are permitted to access those files, directories, drives, workstations, servers, network shares, ports, protocols, and services that are expressly required for the performance of the users' job duties.

Access to privileged functions and security information shall be restricted. Healthwise promotes the principle of least privilege to avoid needing elevated privileges to execute programs. Only the minimum necessary access to perform the required function is granted to Healthwise workforce and third parties. This access is granted only after the workforce member or third party individual agrees to comply with Healthwise's security requirements.

Users who performed privileged functions (e.g., system administration) must use separate accounts when performing those privileged functions. Healthwise shall audit the execution of privileged functions on information systems and ensures information systems prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards (e.g., IDS/IPS or malicious code protection mechanisms).

All users shall access privileged services in a single role (users registered with more than one role designate a single role during each system access session). The use of system administration privileges (any feature or facility of an information system that enables the user to override system or application controls) shall be minimized.

Access to all hypervisor management functions or administrative consoles for systems hosting virtualized systems shall be restricted to personnel based upon the principle of least privilege and supported through technical controls (e.g., two-factor authentication, audit trails, IP address filtering, firewalls, and TLS encapsulated communications to the administrative consoles).

Business applications shall provide means to control access to application system functions and control access rights of users (e.g., read, write, delete, and execute).

Contractors will be provided with minimal system and physical access, and agree to and support Healthwise's security requirements. The contractor selection process will assess the contractor's ability to adhere to and support Healthwise's security policy and procedures.

Ignite Healthwise, LLC (Healthwise) provides guidelines regarding the ownership, classification, retention, storage, handling, and disposal of all Confidential Information. The Healthwise Security Officer and Privacy Officer review and approve the guidelines no less than annually.

Healthwise permits Electronic Protected Health Information (ePHI) generated by or on behalf of Healthwise Customers to be stored in encrypted databases controlled and managed by Healthwise and on infrastructure located in the United States. In some circumstances, authorized Healthwise workforce members may store ePHI generated by or on behalf of Healthwise Customers on their workstations. Extracts of ePHI are deleted immediately after the use of such extract is no longer required.

Healthwise maintains administrative, technical, and physical safeguards to protect the confidentiality, integrity, and availability of Confidential Information. This policy and related procedures will assure that complete, accurate, retrievable, and tested backups are available for all systems used by Healthwise that contain critical/confidential information.

Healthwise's important records (e.g., contracts, personnel records, financial information, client/customer information, etc.) shall be protected from loss, destruction and falsification through the implementation of security controls such as access controls, encryption, backups, electronic signatures, locked facilities or containers, etc.

Violation of this policy and its procedures by workforce members may result in corrective disciplinary action, up to and including termination of employment.

10.1 Backup Policy and Procedures

Backup copies of information and software shall be made, and tests of the media and restoration procedures will be regularly performed at appropriate intervals. Backups are required to be made when equipment is moved (relocated). The Healthwise Operations Team, led by the Director of Technology Operations, is designated to be in charge of backups in the Hosted Environment. Members of the Healthwise Operations Team are trained and assigned to complete backups and manage the backup media.

A formal definition of the level of backup required for each system shall be defined and documented including how each system will be restored, the scope of data to be imaged, frequency of imaging, and duration of retention based on relevant contractual, legal, regulatory and business requirements. Healthwise shall formally define and document how each system is completely restored from backup.

Backups are encrypted and stored at geographically different regions from the system being backed up and in a manner that protects them from loss or environmental damage. An inventory of backups, including the content and location, is maintained. Periodic tests of the Hosted Environment backups will be performed and documented to demonstrate that files can be completely and accurately restored from the backup media. Any failure of a backup must be corrected immediately.

10.2 Data Retention Policy

PHI records for information prescriptions generated by or on behalf of Healthwise Customers will be retained for a period of 24 months. Healthwise will store the records until the retention period has expired and will store the records in a secure manner. The PHI records must be protected from unauthorized access and accidental/incorrect destruction. Records will be destroyed monthly in accordance with the retention time frames and the Data Destruction Policy.

10.3 Data Destruction Policy

It is the policy of Healthwise to destroy PHI provided by or generated on behalf of a Client and Confidential Information after the termination of agreements. In the case of Healthwise's vendors, confidential information is retained until the business relationship between the vendor and Healthwise ends, after which such information is destroyed. Healthwise uses a Security Incident and Event Management (SIEM) system in support of a real-time analysis of security alerts generated by network hardware and applications. The Healthwise SIEM includes data which is unable to be removed on demand. Any data that remains in the Healthwise SIEM system will be purged from the SIEM system within 12 months of the data being logged into the SIEM system. Until all PHI is removed from the Healthwise Production Systems, the protections of the BAA shall survive with respect to any Client PHI. Upon request, Healthwise will provide a certificate of destruction.

Ignite Healthwise, LLC (Healthwise) takes data integrity very seriously. As stewards and partners of Healthwise Customers, we strive to assure data is protected from unauthorized access and that it is available when needed. The following policies drive many of our data protection procedures and technical settings in support of the Healthwise mission of helping people make better health decisions.

Healthwise must ensure the security of information in networks, availability of network services and information services using the network, and the protection of connected services from unauthorized access. The following controls shall be implemented:

responsibilities and procedures for the management of networking equipment;
operational responsibility for networks is separated from computer operations where appropriate;
special controls are established to safeguard the confidentiality and integrity of data passing over public networks or over wireless networks, and to protect the connected systems and applications; special controls may also be required to maintain the availability of the network services and computers connected.

Healthwise Systems shall run on a dedicated computer or only share resources with trusted application systems. Isolation is achieved using physical or logical methods. When a sensitive application is to run in a shared environment, the application systems with which it shall share resources and the corresponding risks will be identified and accepted by the owner of the sensitive application.

Healthwise shall formally manage equipment on the network, including equipment in user areas. Equipment maintained by third-party data storage services shall be the responsibility of the third-party and agreed upon in signed agreements with the third-party providing the service.

Healthwise Systems are categorized into roles and isolated from each other to ensure proper segmentation. System resources shared between two (2) or more users shall be released back to the information system, and must be protected from accidental or purposeful disclosure. Healthwise Systems that create, receive, store, or transmit Customer data must follow the guidelines described in this section.

Agreed services provided by a network service provider/manager shall be formally managed and regularly monitored to ensure they are provided securely. The right to audit must be agreed to by management. The security arrangements necessary for particular services including security features, service levels, and management requirements, must be identified and documented.

Healthwise shall formally address multiple safeguards before allowing the use of information systems for information exchange. The following safeguards must be addressed:

policies or guidelines shall be defined outlining acceptable use of electronic communication applications or systems;
anti-malware must be used for the detection of and protection against malicious code that may be transmitted through the use of electronic communications;
procedures shall be implemented for the use of wireless communications, including an appropriate level of encryption;
employee, contractor and any other user's responsibilities shall be defined to not compromise Healthwise (e.g., through defamation, harassment, impersonation, forwarding of chain letters, unauthorized purchasing, etc.);
cryptographic techniques must be used to protect the confidentiality, integrity and availability of covered information;
retention and disposal guidelines shall be defined for all business correspondence, including messages, in accordance with relevant national and local legislation and regulations and documented business needs; and
controls and restrictions shall be implemented associated with the forwarding of communications (e.g., automatic forwarding of electronic mail to external mail addresses).

Encryption shall be used to protect covered information on mobile/removable media and across communication lines based on pre-determined criteria. Encryption procedures will address the required level of protection (e.g., the type and strength of the encryption algorithm required); and specifications for the effective implementation throughout Healthwise (i.e., which solution is used for which business process).

11.1 Disabling Non-Essential Services

Healthwise's Systems must disable services that are not required to achieve the business purpose or function of the system.

11.2 Monitoring Log-in Attempts

All access to Healthwise's Systems must be logged. This is done following the Healthwise Auditing Policy.

11.3 Prevention of Malware on Healthwise's Systems

Anti-virus and anti-spyware shall be installed, operating and updated (including virus definitions), on all end-user devices to conduct periodic scans of the systems to identify and remove unauthorized software. Updates must occur automatically whenever updates are available. Periodic reviews/scans must be required of the installed software and the data content of systems to identify and, where possible, remove any unauthorized software. Healthwise employs anti-malware software that offers a centralized infrastructure that compiles information on file reputations or has administrators manually push updates to all machines. After applying an update, automated systems verify that each system has received its signature update. The checks carried out by the malicious code detection and repair software to scan computers and media must include:

checking any files on electronic or optical media, and files received over networks, for malicious code before use;
checking electronic mail attachments and downloads for malicious code before use or file types that are unnecessary for Healthwise’ business before use; this check is carried out at different places (e.g., at electronic mail servers, desk top computers and when entering the network of Healthwise);
checking Web traffic, such as HTML, JavaScript, and HTTP, for malicious code; and
checking removable media (e.g., USB tokens and hard drives, CDs/DVDs, FireWire devices, and external serial advanced technology attachment devices) when inserted.

If applicable, bring your own device (BYOD) users are required to use anti-malware software (where supported). Server environments for which the server software developer specifically recommends not installing host-based anti-virus and anti-spyware software are addressed via a network-based malware detection (NBMD) solution.

Audit logs of the anti-virus scans shall be maintained according to the requirements outlined in §12.5.

Healthwise's Systems are to only be used for Healthwise business needs.

11.4 Patch Management

Technical vulnerabilities shall be identified, evaluated for risk and corrected in a timely manner. Actions taken must include patching of vulnerable systems and/or applying other controls.

Software patches and updates will be applied to all systems in a timely manner. In the case of routine updates, they will be applied after thorough testing. In the case of updates to correct known vulnerabilities, priority will be given to testing to speed the time to production. Critical security patches are applied within 30 days of release and all security patches are applied within 90 days of release.

Administrators subscribe to notification services to assure they are up to date on current version of all Healthwise managed software on Healthwise's Systems.

11.5 Intrusion Detection and Vulnerability Scanning

The Hosted Environment is monitored using IDS systems. Suspicious activity is logged and alerts are generated. Vulnerability scanning of the Hosted Environment must occur on a predetermined, regular basis, no less than monthly. Scans are reviewed by Security Officer, with defined steps for risk mitigation, and retained for future reference. Any non-informational items identified during scanning are captured in the Healthwise work-item tracking system and prioritized for remediation.

11.6 Hosted Environment System Security

System, network, and server security is managed and maintained by the Director of Technology Operations and the Security Officer. Up to date system lists and architecture diagrams are kept for all Hosted Environments. Access to the Hosted Environment is controlled using centralized tools and two-factor authentication. Access to Healthwise network equipment is physically protected from access by unauthorized individuals.

11.7 Hosted Environment Data Security

Hosted Environment data security is managed and maintained by the Director of Technology Operations and the Security Officer. Confidential Customer data is stored in a manner that supports user access logs and automated monitoring for potential security incidents. Healthwise Customer data must be segmented and only accessible to the Customer authorized to access data.

Data stored in the information system shall be protected with system access controls including file system, network share, claims, application, and/or database specific access control lists and shall be encrypted when residing in non-secure areas.

The confidentiality and integrity of covered information at rest shall be protected using an encryption method appropriate to the medium where it is stored. If encryption is not applied because it is determined not to be reasonable or appropriate, Healthwise will document its rationale for its decision or use compensating controls other than encryption if the method is approved and reviewed annually by the Security Officer.

Covered information, at minimum, is rendered unusable, unreadable, or indecipherable anywhere it is stored, including on personal computers (laptops, desktops) portable digital media, backup media, servers, databases, or in logs; exceptions are authorized by management and documented. Encryption shall be implemented via one-way hashes, truncation, or strong cryptography and key-management procedures. Acceptable encryption algorithms and strengths are AES-CBC or Triple DES with a 128-bit key minimum (256-bit key for cloud services). For full-disk encryption, logical access is independent of operating system access and decryption keys are not tied to user accounts. The information system protects the confidentiality and integrity of information at rest.

All Hosted Environment Data at rest is stored on encrypted volumes using encryption keys managed by Healthwise or designated Infrastructure provider. Encryption at rest is ensured through the use of automated deployment scripts referenced in the Configuration Management Policy. Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts. Encrypted volumes use AES encryption with a minimum of 256-bit keys, or keys and ciphers of equivalent or higher cryptographic strength.

11.8 Transmission Security

Strong cryptography protocols shall be used to safeguard covered information during transmission over less trusted / open public networks.

All data transmission is encrypted end to end using encryption keys managed by Healthwise. Keys and machines that generate keys are protected from unauthorized access. Key material is protected with access controls such that the key material is only accessible by privileged accounts. Healthwise uses industry standard algorithms and protocols with high cryptographic strength (e.g., AES, SHA256, ECDHE-RSA). Public key certificates used to secure access to publicly available endpoints are limited to use for no longer than five years and then must be regenerated. Keys that are compromised or have been determined to no longer provide adequate protection are immediately regenerated.

In the case of Healthwise provided APIs, mechanisms are provided to assure the person sending or receiving data is authorized to send and save data.

System logs of all transmissions of Hosted Environment Data access must be available for Audit.

Healthwise shall provide security and privacy protections for the transfer of organizational records, or extracts of such records, containing sensitive personal information to a state or federal agency or other regulatory body that lawfully collects such information.

11.9 Firewalls

Healthwise's security gateways (e.g. firewalls) shall enforce security policies and must be configured to filter traffic between domains, block unauthorized access, and are used to maintain segregation between internal wired, internal wireless, and external network segments (e.g., the Internet and 3rd party networks) including DMZs. Healthwise's security gateways enforce access control policies for each of the domains. Wireless networks must be segregated from internal and private networks. Healthwise requires a firewall between any wireless network and the covered information systems environment.

For public-facing web applications, Healthwise must address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either:

reviewing applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes;
installing an automated technical solution that detects and prevents web-based attacks (e.g., web-application firewalls) in front of public-facing web applications to continually check all traffic.

For any public-facing applications that are not web-based, Healthwise shall implement a network-based firewall specific to the application type. If the traffic to the public-facing application is encrypted, Healthwise must ensure the device either sits behind the encryption or can decrypt the traffic prior to analysis.

Networks shall be divided into separate logical network domains (e.g., an organization's internal network domains and external network domains) each protected by a defined security perimeter. A graduated set of controls shall be applied in different logical network domains to further segregate the network security environments (e.g., publicly accessible systems, internal networks; critical assets; and key information security tools, mechanisms, and support components associated with system and security administration).

Healthwise will implement subnetworks for publicly accessible system components that are logically separated from internal organizational networks. To ensure proper separation, Healthwise will verify any server that is visible from the Internet or an untrusted network, and if it is not required for business purposes, moves it to an internal VLAN and gives it a private address. The criteria for segregation of networks into domains shall be based on the access control policy and access requirements, and also takes account of the relative cost and performance impact of incorporating suitable network routing or gateway technology. In addition, segregation of networks shall be based on the value and classification of information stored or processed in the network, levels of trust, or lines of business, in order to reduce the total impact of a service disruption.

Separate domains shall be implanted by controlling the network data flows using routing/switching capabilities, including access control lists, according to applicable flow control policies. The domains shall be defined based on a risk assessment and the different security requirements within each of the domains.

The ability of users to connect to the internal network must be restricted using a deny-by-default and allow-by-exception policy at managed interfaces according to the access control policy and the requirements of Healthwise's business applications.

Routing controls shall be implemented through security gateways used between internal and external networks.

Changes to firewall configurations are documented consistent with the policies in §13.2.

Ignite Healthwise, LLC (Healthwise) shall audit access and activity of Electronic Protected Health Information (ePHI) applications and systems in order to ensure compliance with regulatory requirements. 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. Healthwise shall make reasonable and good-faith efforts to safeguard information privacy and security through a well-thought-out approach to auditing that is consistent with available resources.

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

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

12.1 Auditing Policies

Responsibility for auditing information system access and activity is assigned to Healthwise's Security Officer. The Security Officer shall:

Assign the task of generating reports for audit activities to the workforce member responsible for the application, system, or network
Assign the task of reviewing the audit reports to the workforce member responsible for the application, system, or network, the Privacy Officer, or any other individual determined to be appropriate for the task
Organize and provide oversight to a team structure charged with audit compliance activities (e.g., parameters, frequency, sample sizes, report formats, evaluation, follow-up, etc.)

Healthwise's auditing processes shall address access and activity at the following levels listed below.

User: User level audit trails generally monitor and log all commands directly initiated by the user, all identification and authentication attempts, and data and services accessed
Privileged User: Privileged user level audit trails generally monitor and log all commands directly initiated by the privileged user, all identification and authentication attempts, and data and services accessed
Application: Application level audit trails generally monitor and log application state changes; application errors; and user activities, including data accessed, modified and specific actions performed
System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions
Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities
Security: Security level audit trails generally monitor information regarding security configuration changes, changes to authentication mechanisms, and creation and deletion of system-level objects.

Healthwise must ensure auditing is available at all times while the system is active and audit logs shall include, but not limited to:

dates, times, and details of key events (e.g. log-on and log-off);
records of successful and rejected system access attempts;
records of successful and rejected data and other resource access attempts;
changes to system configuration and procedures for managing configuration changes;
use of privileges;
use of system utilities and applications;
files accessed and the kind of access;
network addresses and protocols;
alarms raised by the access control system;
activation and de-activation of protection systems (e.g., anti-virus systems, intrusion detection systems, identification and authentication mechanisms, etc.);
creation and deletion of system level objects;
account management activities;
system/server shutdown and reboot;
system/server alerts and errors;
application/system shutdown and reboot;
application errors and modifications;
file changes (create, update, delete);
security policy changes;
configuration changes;
modification to sensitive information;
read access to sensitive information; and
printing of sensitive information.

A secure audit record shall be created for all activities on the system (create, read, update, delete) involving covered information. Audit records must include origin, destination, time, and other relevant details that are available to Healthwise. The activities of privileged users (e.g., administrators, operators, etc.) shall include the success/failure of the event, time the event occurred, the account involved, the processes involved, and additional information about the event.

Healthwise leverages process monitoring tools throughout its environment. Healthwise uses Intrusion Detection Systems (IDS) to monitor the integrity of log files and shall identify trigger events or criteria that raise awareness of questionable conditions of viewing of Confidential Information. IDS Systems are managed independently of the system and network that they are monitoring. The events may be applied to the entire Healthwise System or may be specific to a Customer, partner, Business Associate, or application (Listing of Potential Trigger Events). In addition to trigger events, Healthwise utilizes Security Incident and Event Management System (SIEM) log correlation functionality to proactively identify and enable alerts based on log data. Logs are reviewed weekly by the Security Officer or delegate.

Healthwise shall monitor inbound and outbound communications at defined frequencies for unusual or unauthorized activities or conditions. Change detection mechanisms (e.g., file-integrity monitoring tools) will be used to alert personnel to unauthorized modification of critical system files, configuration files, or content files, critical file comparisons are conducted at least weekly, and the organization responds to any alerts generated.

Healthwise will use automated tools to support near real-time analysis of events and maintain an audit log to track prohibited sources and services. Information systems will provide near real-time alerts for the presence of malicious code, unauthorized export of information, signaling to an external information system, or potential intrusions. Automated alerts shall be generated for technical personnel to review and analyze, and suspicious activity or suspected violations are investigated as an integrated part of Healthwise's formal incident response and investigations program.

Healthwise shall provide information systems containing covered information with automated tools for monitoring system events, detecting attacks, and analyzing logs and audit trails to allow the identification of all access or modification of any given record by any given system user over a given period of time. Monitoring devices must be deployed at strategic and ad-hoc locations to track specific transactions and the impact of security changes to information systems. Healthwise shall deploy NetFlow collection and analysis tools to DMZ network flows to detect anomalous activity.

Healthwise shall review physical access logs weekly and upon occurrence of security incidents involving physical security.

Results of monitoring activities shall be reviewed through the use of automated tools on a daily basis for those servers that perform security functions (e.g., IDS/IPS) for:

all security events;
logs of all critical system components; and
logs of all servers that perform security functions (e.g., intrusion detection system (IDS); intrusion prevention system (IPS); and authentication, authorization, and accounting protocol (AAA) servers (e.g., RADIUS)).

System records shall be reviewed daily for initialization sequences, log-ons and errors, system processes and performance, and system resources utilization, and the results are used to determine anomalies on demand.

Healthwise's Security Officer and Privacy Officer are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to:

Scanning tools and devices
Password cracking utilities
Network sniffers
Passive and active intrusion detection systems

The process for review of audit logs, trails, and reports shall include:

Description of the activity as well as rationale for performing the audit
Identification of which Healthwise workforce members will be responsible for review (workforce members shall not review audit logs that pertain to their own system activity)
Frequency of the auditing process
Determination of significant events requiring further review and follow-up
Identification of appropriate reporting channels for audit results and required follow-up

Vulnerability testing software may be used to probe the network to identify what is running (e.g., operating system or product versions in place), whether publicly-known vulnerabilities have been corrected, and evaluate whether the system can withstand attacks aimed at circumventing security controls. Testing may be carried out internally or provided through an external third-party vendor. Whenever possible, a third-party auditing vendor should not be providing IT oversight services (e.g., vendors providing IT services should not be auditing their own services - separation of duties). Testing shall be done on a routine basis, currently quarterly. Vulnerabilities are tracked and remediated consistent with §11.5

12.2 Audit Requests

A request may be made for an audit for a specific cause. The request may come from a variety of sources including, but not limited to, Privacy Officer, Security Officer, Customer, Partner, or an Application owner or application user. A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request for an audit must be approved by Healthwise'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 Healthwise's Security Officer to determine appropriate sanction/corrective disciplinary action. Only de-identified information shall be shared with Customer or Partner regarding the results of the investigative audit process. This information will be communicated to the appropriate personnel by Healthwise's Privacy Officer or delegate. Prior to communicating with customers and partners regarding an audit, Healthwise may consider seeking risk management and/or legal counsel.

12.3 Review and Reporting of Audit Findings

Audit information that is routinely gathered must be reviewed in a timely manner, currently monthly, by the responsible workforce member(s). On a quarterly basis, logs are reviewed to assure the proper data is being captured and retained. The reporting process shall allow for meaningful communication of the audit findings to those workforce members, Customers, or Partners requesting the audit. Significant findings shall be reported immediately in a written format. Single events may be reported by sending an email to gro.esiwhtlaeh@ecnailpmoc. Routine findings shall be reported to the sponsoring leadership structure in a written report format.

Reports of audit results shall be limited to internal use on a minimum necessary/need-to-know basis. Audit results shall not be disclosed externally without administrative and/or legal counsel approval. Security audits constitute an internal, confidential monitoring practice that may be included in Healthwise's performance improvement activities and reporting. Care shall be taken to ensure that the results of the audits are disclosed to administrative level oversight structures only and that information which may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports (individually-identifiable ePHI shall not be included in the reports). Whenever indicated through evaluation and reporting, appropriate corrective actions must be undertaken. These actions shall be documented and shared with the responsible workforce members, Customers, and/or Partners.

12.4 Auditing Customer and Partner Activity

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 Healthwise and the 3rd party. Healthwise will make every effort to assure Customers and Partners do not gain access to data outside of their own environments. If it is determined that the Customer or Partner has exceeded the scope of access privileges, Healthwise's leadership must remedy the problem immediately. If it is determined that a Customer or Partner has violated the terms of the HIPAA Business Associate Agreement or any terms within the HIPAA regulations, Healthwise must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.

12.5 Audit Log Security Controls and Backup

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

Separation of duties shall be implemented to limit the risk of unauthorized or unintentional modification of information and systems.

Healthwise information systems shall support audit reduction and report generation that supports expeditious, on-demand review, analysis, reporting and after-the-fact incident investigations of security incidents and do not alter the original content or time marking of audit records. Healthwise logging servers include a Security Incident and Event Management (SIEM) System as part of their baseline configuration to ease reviewing of audit log data. The SIEM System provides message summarization, reduction, and reporting functionality.

12.6 Workforce Training and Responsibilities

Employees and contractors shall receive documented initial (i.e., as part of their onboarding within 30 days of hire), annual and ongoing training on their roles related to security and privacy. Awareness training will commence with a formal induction process designed to introduce Healthwise's security and privacy policies, state and federal laws, and expectations before access to information or services is granted and no later than 30 days after the date the employee is hired. Ongoing training shall include security and privacy requirements (e.g., objective, scope, roles and responsibilities, coordination, compliance, communicating threat information, legal responsibilities and business controls) as well as training in the correct use of information assets and facilities (e.g., including but not limited to log-on procedures, use of software packages, anti-malware for mobile devices, and information on the disciplinary process). Training shall discuss how Healthwise addresses each area (e.g., audit logging and monitoring); how events or incidents are identified (e.g., monitoring for inappropriate or failed user logins), and the actions Healthwise takes in response to events or incidents (e.g., notifying the workforce member or the members supervisor), as appropriate to the area of training. All employees who interact with the Healthwise production environment will also be required to complete secure cloud development training annually.

Healthwise shall define rules to describe employee responsibilities and acceptable behavior for information system usage, including at a minimum, rules for email, internet, mobile devices (especially for the use outside the premises of Healthwise), social media, and facility usage. Rules of behavior must include explicit restrictions on the use of social media and networking sites, posting information on commercial websites, and sharing information system account information.

Employees using mobile computing devices shall be trained on the risks, the controls implemented, and their responsibilities (e.g., shoulder surfing, physical protections). Users of mobile computing devices in public places must take care to avoid the risk of overlooking (shoulder surfing) by unauthorized persons. Training will be arranged for personnel using mobile computing to raise their awareness on the additional risks resulting from this way of working and the controls that are implemented.

Employees shall be appropriately trained on leading principles and practices for all types of information exchange (oral, paper and electronic). Personnel must be appropriately educated and periodically reminded of the following:

not to leave covered or critical information on printing systems (e.g., copiers, printers, and facsimile machines) as these may be accessed by unauthroized personnel;
to take necessary precautions, including not to reveal covered information, to avoid being overheard or intercepted when making a phone call by:
- people in their immediate vicinity, particularly when using mobile phones;
- wiretapping, and other forms of eavesdropping through physical access to the phone handset or the phone line, or using scanning receivers; or
- people at the recipient's end;
not to leave messages containing sensitive information on voicemail or other answering or recording services since these may be replayed by unauthorized persons, stored on communal systems or stored incorrectly as a result of misdialing;
the problems with printers, facsimile and copy machines, such as:
- unauthorized access to built-in message stores to retrieve messages;
- deliberate or accidental programming of machines to send messages to specific numbers; and
- sending documents and messages to the wrong number either by misdialing or using the wrong stored number;
not to register demographic data in software that could be collected later for unauthorized use; and
that modern facsimile machines and photocopiers have page caches and store pages in case of a paper or transmission fault, which will be printed once the fault is cleared.

Employees and contractors shall be informed in writing that violations of the security policies will result in sanctions or disciplinary action. Healthwise requires all employees to sign an acknowledgement of policies at time of hire and annually thereafter.

12.7 External Audits of Information Access and Activity

Prior to contracting with an external audit firm, Healthwise shall:

Outline the audit responsibility, authority, and accountability
Choose an audit firm that is independent of other organizational operations
Ensure technical competence of the audit firm staff
Require the audit firm's adherence to applicable codes of professional ethics
Obtain a signed HIPAA Business Associate Agreement, if necessary
Assign organizational responsibility for supervision of the external audit firm

12.8 Retention of Audit Data

Audit records shall be retained for ninety (90) days and old records archived for one (1) year to provide support for after-the-fact investigations of security incidents and to meet regulatory and the organization's retention requirements.

Reports summarizing audit activities shall be retained for a period of six years.

12.9 Potential Trigger Events

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

Ignite Healthwise, LLC (Healthwise) standardizes and automates configuration management through the use of industry standard tools well as documentation of all changes to production systems and networks. The tools used to automate configuration management automatically configure all Healthwise Systems according to established and tested policies and are used as part of the Disaster Recovery plan and process.

13.1 Configuration Management Policies

Healthwise uses industry-standard tools to standardize and automate configuration management. No systems are deployed into Healthwise environments without approval of the Healthwise Chief Technology Officer or delegate. All changes to production systems, network devices, and firewalls are approved by the Healthwise Chief Technology Officer or delegate before they are implemented to assure they comply with business and security requirements. Healthwise utilizes development and staging environments that simulate production to assure proper function. All changes to production systems are tested before they are implemented. All formal change requests require unique ID and authentication. Implementation of approved changes are performed by authorized personnel.

An inventory of assets and services must be maintained. Healthwise shall identify and inventory all assets including information (e.g., ePHI, PII), encrypted or unencrypted, wherever it is created, received, maintained, or transmitted, including organizational and third-party sites, and documents the importance of these assets. Locations in which ePHI constitutes a designated record set shall be explicitly identified in the asset inventory.

Healthwise maintains tooling to generate an up-to-date inventory of systems, including corresponding architecture diagrams for related products and services. All systems are categorized as production and utility to differentiate based on criticality. Healthwise maintains a single inventory of systems for its production environment and another inventory of systems for its corporate environment.

Healthwise maintains information systems according to a current baseline configuration and configures system security parameters to prevent misuse. Vendor supplied software used in operational systems must be maintained at a level supported by the supplier and uses the latest version of Web browsers on operational systems to take advantage of the latest security functions in the application.

Windows-based systems use a baseline Active Directory group policy configuration. Clocks are continuously synchronized to an authoritative source across all systems using Network Time Protocol (NTP) or a platform-specific equivalent. Modifying time data on systems is restricted.

Annual compliance reviews must be conducted by security or audit individuals using manual or automated tools; if non-compliance is found, appropriate action shall be taken. Healthwise will determine the causes of the non-compliance; evaluate the need for actions to ensure that non-compliance do not recur; determine and implement appropriate corrective action; and review the corrective action taken.

Healthwise shall perform annual checks on the technical security configuration of systems, either manually by an individual with experience with the systems and/or with the assistance of automated software tools. If any non-compliance is found, Healthwise will determine the causes of the non-compliance; evaluate the need for actions to ensure that non-compliance do not recur; determine and implements appropriate corrective action; and review the corrective action taken.

Healthwise shall use its configuration control program to maintain control of all implemented software and its system documentation and archives prior versions of implemented software and associated system documentation. Previous versions of application software must be retained as a contingency measure. Old versions of software shall be archived, together with all required information and parameters, procedures, configuration details, and supporting software for as long as the data is retained in archive or as dictated by Healthwise’s data retention policy.

Physical or logical access shall be only given to suppliers for support purposes when necessary, with management approval, and such access must be monitored.

A current network diagram (including wireless networks) must be created and maintained and updated whenever there are network changes and no less than every six months. The diagram must document all high-risk environments, data flows, and connections to systems storing, processing or transmitting covered information, including any wireless networks that may have legal compliance impacts.

13.1.1 Software Development

Healthwise considers security and privacy in all phases of its Software Development Life Cycle (SDLC). Wherever possible, Healthwise applies automated controls to protect the confidentiality, integrity, and availability of information. When automated controls are not possible, Healthwise applies manual controls to safeguard information. Healthwise applies secure development practices when implementing software changes. The Security Officer is responsible for providing secure development training to the Healthwise software development team.

Non-trivial software development uses feature branches based on the main branch used for the current release. If feature branches are used for a new feature or defect fix, any related changes are committed to that feature branch. Healthwise tests software changes prior to deploying them to production. The level of testing is proportional to the importance and nature of the software change. Tests may be either automated or manual and are performed by a different person than the person who developed the software change. Healthwise provides development and test environments for software testing. These environments have identical security controls to the production environment.

Non-trivial software changes require a corresponding work item to track the change. The work item is created in advance of beginning the work and must document the communication protocols and intended functionality. Additionally, a non-trivial software change requires a pull request and should provide a description of the changes made. A code review occurs 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. Engineers reviewing the change 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 a software change directly interacts with ePHI or controls access to data potentially containing ePHI, the code changes must be reviewed and approved by no less than two reviewers. The review of a change that interacts with ePHI or controls access to data potentially containing ePHI 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. After this review has been approved by two reviewers, the change may be merged into the master branch.

Healthwise does not host, or otherwise make available, software applications that interact with ePHI in its Corporate Data Center.

Healthwise software products use role-based access control to limit access to application functions and data. Healthwise requires actions to be performed by authenticated users; actions that do not require authentication are permitted upon approval by the Security Officer. Any ePHI output from Healthwise software products is limited to the minimum necessary and Healthwise protects the confidentiality of that information by securing transmission as described in §11.8.

Applications developed by Healthwise shall be based on secure coding guidelines to prevent common vulnerabilities or undergo appropriate testing. Software development processes include, but are not limited to:

injection flaws, particularly SQL injection (e.g., validate input to verify user data cannot modify meaning of commands and queries, utilize parameterized queries, etc.);
buffer overflow (e.g., validate buffer boundaries and truncate input strings);
insecure cryptographic storage (e.g., prevent cryptographic flaws);
insecure communications (e.g., properly encrypt all authenticated and sensitive communications);
improper error handling (e.g., do not leak information via error messages);
broken authentication/sessions (e.g., prevent unauthorized individuals from compromising legitimate account credentials, keys or session tokens that would otherwise enable an intruder to assume the identity of an authorized user);
cross-site scripting (XSS) (e.g., validate all parameters before inclusion, utilize context-sensitive escaping, etc.);
improper access control, such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access functions (e.g., properly authenticate users and sanitize input, and do not expose internal object references to users);
cross-site request forgery (CSRF) (e.g., do not reply on authorization credentials and tokens automatically submitted by browsers); and
any other input-validation vulnerability listed in the OWASP top 10.

Applications that are not developed using secure coding guidelines must undergo automatic or manual input validation checks during testing and annually thereafter, and such checks include:

dual input or other input checks, such as boundary checking or limiting fields to specific ranges of input data, to detect the following errors:
- out-of-range values
- invalid characters in data fields
- missing or incomplete data
- exceeding upper and lower data volume limits
- unauthorized or inconsistent control data
periodic review of the content of key fields or data files to confirm their validity and integrity;
procedures for responding to validation errors;
procedures for testing the plausibility of the input data;
verifying the identity of an individual opening or updating an account;
defining the responsibilities of all personnel involved in the data input process; and
creating a log of the activities involved in the data input process.

System and information integrity requirements must be developed, documented, disseminated, reviewed, and updated no less than annually. Consistent with §2.1, the Healthwise Security Officer reviews and updates the procedures for developing software no less than annually.

13.2 Changing Existing Systems

Only authorized administrators shall be allowed to implement approved upgrades to software, applications, and program libraries, based on business requirements and the security implications of the release. Operational systems will only hold approved programs or executable code (i.e., no development code or compilers).

Any decision to upgrade to a new release shall take into account the business requirements for the change, and the security and privacy impacts of the release (e.g., the introduction of new security functionality or the number and severity of security problems affecting this version).

Applications and operating systems shall be tested for usability, security and impact prior to production. The tests are carried out on separate systems.

Managers who are responsible for application systems shall also be responsible for the strict control (security) of the project or support environment and ensure that all proposed system changes are reviewed to check that they do not compromise the security of either the system or the operating environment.

Subsequent changes to already-provisioned systems are unconditionally handled by modifying the configuration or scripts used to standardize and automate configuration management. In the case that a configuration change cannot be handled by the configuration management tool, a runbook will be created describing what changes will be made and by whom. All changes will be stored in a version-control system and must be peer-reviewed prior to implementation. Before rolling the change to production, the change must be described in the Healthwise work-item tracking system and the issue must link to the reviewed change in the version-control system.

Healthwise defines rollback procedures prior to implementing the change. These rollback procedures are executed in the case of unsuccessful change.

Once the request has been approved by the Director of Technology Operations, and/or the Security Officer or a designated member of the Information Security team, the ops team member may roll out the change into production environments.

If a change will result in an update to the system inventory or network diagram, the inventory or diagram is regenerated.

13.3 Patch Management

Healthwise uses automated tooling to ensure systems are up-to-date with the latest security patches. Prior to installation on a production system, Healthwise validates security and operating system patches in a non-production environment. On Healthwise's systems, the baseline Group Policy setting configures Windows Update to implement the patching policy.

If an operational system or component is no longer supported by its manufacturer, Healthwise will create and implement a migration plan.

13.4 Software Release Procedures

Software releases are treated as changes to existing systems and thus follow the procedure described in §13.2.

A formal security incident response program shall be established by Healthwise to respond, report (without fear of repercussion), escalate and treat breaches and reported security events or incidents. Healthwise will establish an incident response and escalation program, setting out the action to be taken on receipt of a report of an information security event, treating the breach as discovered, and the timeliness of reporting and response. Organization-wide standards will be specified for the time required for system administrators and other personnel to report anomalous events to the incident handling team, the mechanisms for such reporting, and the kind of information that should be included in the incident notification. This reporting must also include notifying internal and external stakeholders, the appropriate Community Emergency Response Team and law enforcement agencies in accordance with all legal or regulatory requirements for involving that organization in computer incidents. With the importance of Information Security Incident Handling, this policy shall be established to set the direction of management. Employees and other workforce members, including third parties, shall be able to freely report security weaknesses (real and perceived) without fear of repercussion.

14.1 Incident Management Policies

The Healthwise incident response process follows the process recommended by NIST SP 800-61r2. Process flows are a direct representation of the NIST process which can be found in this document.

Healthwise's incident response classifies security-related events into the following categories:

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

Healthwise shall implement continuous monitoring of threats through intrusion detection systems (IDS) and/or other monitoring applications.

Healthwise shall provide workforce training on information security incidents and required responses. Healthwise Workforce must report any unauthorized or suspicious activity seen on production systems or associated with related communication systems. 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. Healthwise shall facilitate clear communication of information security incidents with internal, as well as external, stakeholders. Workforce members must cooperate with federal or state investigations or face disciplinary proceedings. Healthwise must ensure workforce members do not interfere with federal or state investigations or disciplinary proceedings through willful misrepresentation or omission of facts or by the use of threats or harassment against any person. Healthwise shall take disciplinary action against workforce members that fail to cooperate with federal and state investigations and ensures violations of these requirements are incorporated into disciplinary procedures.

The Healthwise Security Officer is notified within 24 hours of a security incident and retains responsibility for notifying stakeholders, the Critical Response Team, and law enforcement agencies or regulatory agencies, as required by legal or regulatory requirements. Only the Healthwise Marketing Communications team or Chief Executive Officer are authorized to respond to media inquiries regarding incidents.

The processes surrounding security incident response are reviewed and evaluated for effectiveness periodically, currently annually.

14.2 Critical Response Team

Healthwise will establish a Critical Response Team (CRT). The Critical Response Team are the key staff responsible for making decisions regarding response to a disaster or business continuity event. The Critical Response Team may call other individuals to assist with incident response as deemed necessary.

The Critical Response Team follows the line of succession detailed at §16.1.

Healthwise provides incident response training to CRT members within 60 days of being appointed to the team and no less than annually thereafter.

It is the policy of Ignite Healthwise, LLC (Healthwise) to provide guidance for breach notification when unauthorized access, acquisition, use and/or disclosure of unsecured ePHI occurs. Breach notification will be carried out as required by law. In the case of a breach, Healthwise shall notify all affected Customers. Unless mutually agreed upon otherwise, it is the responsibility of the Customers to notify affected individuals.

For an acquisition, access, use or disclosure of unsecured ePHI to constitute a breach, it must constitute a violation of the HIPAA Privacy Rule. A use or disclosure of unsecured ePHI that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule and would not qualify as a potential breach. To determine if an impermissible use or disclosure of ePHI constitutes a breach and requires further notification, Healthwise will need to perform a risk assessment to determine if there is significant risk of harm to the individual as a result of the impermissible use or disclosure. Healthwise shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. Healthwise has the burden of proof for demonstrating that all notifications to appropriate Customers or that the use or disclosure did not constitute a breach. Based on the outcome of the risk assessment, Healthwise will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact-specific and address:

Consideration of who impermissibly used or to whom the information was impermissibly disclosed
The type and amount of ePHI involved
The cause of the breach, and the entity responsible for the breach, either Customer, Healthwise, or Partner
The potential for significant risk of financial, reputational, or other harm

15.1 Healthwise Breach Policy

A breach of ePHI shall be treated as discovered as of the first day on which such breach is known to Healthwise, or, by exercising reasonable diligence would have been known to Healthwise. Healthwise shall be deemed to have knowledge of a breach if such breach is known or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is a workforce member or partner of Healthwise. Following the discovery of a potential breach, Healthwise shall begin an investigation (see Incident Response Policy) immediately, conduct a risk assessment, and based on the results of the risk assessment, begin the process to notify each Customer affected by the breach. Healthwise shall also begin the process of determining what external notifications are required or should be made (e.g., Secretary of Department of Health & Human Services (HHS), media outlets, Law Enforcement Officials, etc.)

The Healthwise Security Officer shall name an individual to act as the investigator of the breach (e.g., Privacy Officer, Security Officer, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others at Healthwise as appropriate (e.g., administration, Critical 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.

Upon discovery of a breach, notice shall be made to the affected Healthwise Customers no later than 72 hours after the discovery of the breach. It is the responsibility of Healthwise to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay. If a Law Enforcement Official states to Healthwise that a notification, notice, or posting would impede a criminal investigation or cause damage to national security, Healthwise shall:

If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting of the timer period specified by the official; or
If the statement is made orally, document the statement, including the identity of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described above is submitted during that time.

Healthwise Customers will be notified of breaches via email and phone within the timeframe for reporting breaches as outlined above. The email notification shall be written in plain language and must contain the following information:

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

As described above and in addition to the reports created for each incident, Healthwise shall maintain a process to record or log all breaches of unsecured ePHI regardless of the number of records and Customers affected. The following information should be collected/logged for each breach:

A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known.
A description of the types of Unsecured Protected Health Information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known.
A description of the action taken with regard to notification of patients regarding the breach.
Resolution steps taken to mitigate the breach and prevent future occurrences.

Healthwise 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 Healthwise.

Healthwise 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. Healthwise 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.

Healthwise shall provide a process for individuals to make complaints concerning Healthwise's patient privacy policies and procedures or its compliance with such policies and procedures. Healthwise 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.

15.2 Sample Letter to Customers in Case of Breach

[Date]

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

Dear [Name of Customer]:

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

Describe event and include the following information:

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

Other Optional Considerations:

Recommendations to assist customer in remedying the breach.

We will assist you in remedying the situation.

Healthwise shall recover and restore business operations and establish an availability of information in the time frame required by the business objectives and without a deterioration of the security measures. The business continuity planning process must include the following:

recovery and restoration of business operations and establish an availability of information in a timeframe specified by Healthwise;
attention shall be given to the assessment of internal and external business dependencies and the contracts in place;
documentation of agreed procedures and processes; and
testing and updating of at least a section of the plans.

The planning process focuses on the required business objectives (e.g., restoring of specific communication services to customers in an acceptable amount of time). The procedures for obtaining necessary electronic covered information during an emergency is defined. The services and resources facilitating this procedure are identified, including staffing, non-information processing resources, as well as fallback arrangements for information processing facilities. Fallback arrangements may include arrangements with third parties in the form of reciprocal agreements, or commercial subscription services.

The contingency program shall address required capacity, identifies critical missions and business functions, defines recovery objectives and priorities, and identifies roles and responsibilities. The business continuity plans must:

identify the necessary capacity for information processing, telecommunications, and environmental support is available during contingency operations (e.g., during an information system disruption, compromise or failure);
identify essential missions and business functions and associated contingency requirements;
provide recovery objectives, restoration priorities, and metrics; and
address contingency roles, responsibilities, and assign individuals with contact information.

The business continuity planning framework shall address a specific, minimal set of information security requirements, including the following:

the conditions for activating the plans which describe the process to be followed (e.g., how to assess the situation, who is to be involved) before each plan is activated;
emergency procedures which describe the actions to be taken following an incident that jeopardizes business operations;
fallback procedures which describe the actions to be taken to move essential business activities or support services to alternative temporary locations, and to bring business processes back into operation in the required timeframe;
resumption procedures which describe the actions to be taken to return to normal business operations;
a maintenance schedule which specifies how and when the plan will be tested, and the process for maintaining the plan;
awareness, education, and training activities which are designed to create understanding of the business continuity processes and ensure that the processes continue to be effective; and
the critical assets and resources needed to be able to perform the emergency, fallback and resumption procedures.

The Ignite Healthwise, LLC (Healthwise) Emergency Preparedness, Disaster Recovery and Business Continuity Plan (Contingency Plan) establishes procedures to recover Healthwise following a disruption resulting from a disaster. Example of the types of disasters that would initiate this plan are natural disaster, political disturbances, man-made disaster, external human threats, internal malicious activities. The Contingency Plan defines a business continuity strategy based on Healthwise's risk assessment, as defined in §17. This policy and the Contingency Plan Disaster Recovery are reviewed and maintained by the Healthwise Security Officer and Privacy Officer.

Copies of the business continuity plans shall be distributed to key contingency personnel, including the Security Officer, system owner, system administrators, and database administrators.

Healthwise defines two categories of systems from a disaster recovery perspective. Critical 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 availability of data and must be restored, or have a process begun to restore them, immediately upon becoming unavailable. Non-critical Systems 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.

Healthwise uses a redundant architecture for Critical Systems used to provide service to Healthwise's Customers. Consistent with §17, Healthwise considers the redundant components when performing risk assessments.

Healthwise shall develop, disseminate, and review/update annually a formal, documented physical and environmental protection policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities and compliance requirements for its physical and environmental protection program and policy and associated physical and environmental protection controls (e.g., through policy, standards, guidelines, and procedures).

16.1 Line of Succession

The following order of succession to ensure that decision-making authority for the Healthwise Contingency Plan is uninterrupted. The Healthwise Security Officer is responsible for ensuring the safety of personnel and the execution of procedures documented within this Healthwise Contingency Plan. If the Security Officer is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the CTO or CEO shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.

Matt Berther, Security Officer: mberther@healthwise.org
Adam Husney, CEO and CMO: ahusney@healthwise.org

16.2 Responsibilities

The Technology Operations and Business Technology Systems teams have been developed and trained to respond to a contingency event affecting IT systems. These teams are responsible for recovery of the Healthwise technology environments (both hosted and corporate), network devices, and all servers. These teams obtain maintenance support and/or spare parts for information systems to support the defined recovery time objective. Members of the team include Workforce who are also responsible for the daily operations and maintenance of Healthwise information systems. The team leader is the Director of Technology Operations who reports to the CTO.

The Facilities team have been developed and trained to respond to a contingency event affecting the Healthwise corporate campus. This team is responsible for restoring operations to the Healthwise corporate campus in case of disaster. This team obtains maintenance support and/or spare parts for facility components to support the defined recovery time objective. Members of the team include Workforce who are responsible for the daily operations and maintenance of the Healthwise campus. The team leader is the Facilities Directory who reports to the CFO.

Healthwise requires service providers to maintain business continuity plans and places the responsibility on the service provider to test, maintain, and execute those plans as necessary.

Members of the Technology Operations, Business Technology Systems, and Facilities teams must maintain local copies of the contact information from §16.1. Additionally, the Security Officer, CTO, and CEO must maintain a local copy of this policy and related procedures in the event Internet access is not available during a disaster scenario.

16.3 Testing and Maintenance

The Security Officer shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test to support Healthwise's recovery time objective (RTO) of less than 24 hours and recovery point objective (RPO) of less than 4 hours. This process will also serve as training for personnel involved in the plan's execution. At a minimum the Contingency Plan shall be tested annually. The types of validation/testing exercises include tabletop and technical testing. Contingency Plans for all application systems must be tested at a minimum using the tabletop testing process. However, if the application system Contingency Plan is included in the technical testing of their respective support systems that technical test will satisfy the annual requirement.

As new requirements are identified, the Contingency Plan is reviewed and updated to ensure consistency with the overall business continuity strategy.

16.3.1 Tabletop Testing

Healthwise shall routlinely test the Contingency Plan using tabletop exercises. The primary objective of the tabletop test is to ensure designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures as outlined in the Contingency Plan in a timely manner. The exercises include testing to validate the ability to respond to a crisis in a coordinated, timely, and effective manner, by simulating the occurrence of a specific crisis.

16.3.2 Technical Testing

The primary objective of the technical test is to ensure the communication processes and data storage and recovery processes can function at an alternate site to perform the functions and capabilities of the system within the designated requirements. Technical testing shall include but is not limited to: processing from backup system at the alternate site; restoring system using backups; and switching compute and storage resources to alternate processing site.

This policy establishes the scope, objectives, and procedures of the Ignite Healthwise, LLC (Healthwise) information security risk management process. The risk management process is intended to support and protect Healthwise and its ability to fulfill its mission.

17.1 Policies

Healthwise shall perform risk assessments in a consistent way and at planned intervals, or when there are major changes to Healthwise’s environment. Risk assessments must identify information security risks to Healthwise; risk assessment results are reviewed annually. Risk assessments shall be performed that address all of the major domains of the HITRUST CSF.

Risk assessments shall include the evaluation of multiple factors that may impact security as well as the likelihood and impact from a loss of confidentiality, integrity and availability of information and systems. Risk assessments (analysis) shall be used to determine whether a breach of unsecured Protected Health Information (PHI), as these terms are defined by the Secretary of Health and Human Services, is reportable to the Secretary must demonstrate there is a low probability of compromise (lo pro co) rather than a significant risk of harm. The methodology, at a minimum, must address the following factors:

the nature of the PHI involved, including the types of identifiers involved and the likelihood of re-identification;
the unauthorized person who used the PHI or to whom the disclosure was made;
whether the PHI was actually acquired or viewed;
the extent to which the risk to the PHI has been mitigated; and
and other factors/guidance promulgated by the Secretary.

Risk analysis and risk management are recognized as important components of Healthwise's corporate compliance program and information security program in accordance with the Risk Analysis and Risk Management implementation specifications within the Security Management standard. Risk assessments are done throughout product lifecycles, including:

Before the integration of new system technologies and before changes are made to Healthwise physical safeguards; and while making changes to Healthwise physical equipment and facilities that introduce new, untested configurations.
- 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 Healthwise Platform.
Healthwise 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 and other confidential and proprietary electronic information.

Healthwise implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to:

Ensure the confidentiality, integrity, and availability of all ePHI and other confidential and proprietary electronic information Healthwise receives, maintains, processes, and/or transmits for its Customers and/or employees;
Protect against any reasonably anticipated threats or hazards to the security or integrity of Customer and/or Workforce member ePHI;
Protect against any reasonably anticipated uses or disclosures of Customer and/or Workforce member ePHI that are not permitted or required; and
Ensure compliance by all workforce members

Any risk remaining (residual) after other risk controls have been applied, requires sign off by the Healthwise Management Committee and Healthwise Security Officer.

All Healthwise 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 Healthwise Roles Policy.

The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of the Healthwise Security Officer or delegate, and the identified Risk Management Committee. Healthwise will perform a risk assessment as defined in this policy no less than annually.

All risk management efforts, including decisions on what controls to put in place as well as those to not put into place, are documented and the documentation is maintained for six years.

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

This policy is applicable to any company facility that is managed by Healthwise. Third-Party Data Centers are not managed or controlled by Healthwise. However, due diligence is conducted for all third-party service agreements.

18.1 Healthwise-controlled Facility Access Policies

Visitor (including family and friends of Healthwise employees) and third-party support access shall be recorded and supervised unless previously approved. Access by third-party support personnel to secure areas or covered information processing facilities is granted only when required, authorized, and monitored. Records must contain:

name and organization of the person visiting;
signature of the visitor;
form of identification;
date of access;
time of entry and departure;
purpose of visit; and
name and organization of person visited.

Healthwise shall formally address the purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities and compliance requirements for its equipment maintenance program (e.g., through policy, standards, guidelines, and procedures). Healthwise will maintain formal, documented procedures to facilitate the implementation of the information system maintenance policy and associated system maintenance controls.

The Healthwise Facilities Director determines the necessary safeguards for the publicly accessible reception area.

Healthwise shall establish a process for maintenance personnel authorization and maintains a list of authorized maintenance organizations or personnel; ensures that non-escorted personnel performing maintenance on the information system have required access authorizations; and designates organizational personnel with required access authorizations and technical competence to supervise the maintenance activities of personnel who do not possess the required access authorizations. This list is reviewed no less than quarterly by the Healthwise Security Officer or delegate. Persons that no longer require access are removed from the list during this review.

Healthwise shall both monitor and control nonlocal maintenance and diagnostic activities; and prohibits nonlocal system maintenance unless explicitly authorized, in writing, by the Security Officer or delegate. If nonlocal maintenance and diagnostic activties are authorized, Healthwise will:

allow the use of nonlocal maintenance and diagnostic tools only as consistent with organizational policy and documented in the security plan for the information system;
employ strong identification and authentication techniques in the establishment of nonlocal maintenance and diagnostic sessions;
maintain records for nonlocal maintenance and diagnostic activities; and
terminate all sessions and network connections when nonlocal maintenance is completed.

Fire extinguishers and detectors shall be installed according to applicable laws and regulations. Fire extinguishers are located throughout the facility and are no more than fifty (50) feet away from critical electrical components; and fire detectors (e.g., smoke or heat activated) are installed on and in the ceilings and floors. For any Healthwise managed buildings, Healthwise shall ensure that fire authorities are automatically notified when a fire alarm is activated.

Maintenance is controlled and conducted by authorized personnel in accordance with supplier-recommended intervals, insurance policies and Healthwise's maintenance program.

Physical access is restricted using smart locks that track all access. Healthwise maintains audit logs of physical access to Healthwise facilities. Restricted areas and facilities are locked when unattended (where feasible). Only authorized workforce members receive access to restricted areas (as determined by the Security Officer). Access and keys are revoked upon termination of workforce members. Workforce members must report a lost and/or stolen key(s) to the Security Officer or Facilities Director. The Security Officer facilitates the changing of the lock(s) within 7 days of a key being reported lost/stolen.

Report violations of this policy to the restricted area's department team leader, supervisor, manager, or director, or the Security Officer. Workforce members in violation of this policy are subject to disciplinary action, up to and including termination. Visitors in violation of this policy are subject to loss of vendor privileges and/or termination of services from Healthwise.

Workstations may only be accessed and utilized by authorized workforce members to complete assigned job/contract responsibilities. All workforce members are required to monitor workstations and report unauthorized users and/or unauthorized attempts to access systems/applications as per the System Access Policy. All workstations purchased by Healthwise are the property of Healthwise and are distributed to users by the company.

Technology equipment often contains parts which cannot simply be thrown away. Proper disposal of equipment is both environmentally responsible and often required by law.

Healthwise shall securely dispose of media containing sensitive information. Healthwise shall destroy (e.g., disk wiping, degaussing, shredding, disintegrating, grinding, incinerating, pulverizing, or melting) media when it is no longer needed for business or legal reasons.

Disposal methods shall be commensurate with the sensitivity of the information contained on the media and will address:

the use of generally accepted, secure disposal or erasure methods for use by another application within Healthwise, for media that contains (or might contain) covered information; and
the identification of information that qualifies as covered, or a policy shall be developed that all information shall be considered covered in the absence of unequivocal evidence to the contrary.

19.1 Overview

Surplus Healthwise IT assets must be stored securely when not in use. Obsolete Healthwise IT assets must be disposed according to legal requirements and environmental regulations in accordance with company-approved methods.

Electronic and physical media containing covered information shall be securely sanitized prior to reuse, or if it cannot be sanitized, will be destroyed prior to disposal. Disk wiping or degaussing shall be used to securely remove electronic information. Shredding, disintegration, grinding surfaces, incineration, pulverization, or melting will be used to destroy electronic and hard copy media. Devices containing covered information must be physically destroyed or the information is destroyed, deleted or overwritten using techniques to make the original information non-retrievable rather than using the standard delete or format function. Healthwise shall render information unusable, unreadable, or indecipherable on system media, both digital and non-digital, prior to disposal or release for reuse using organization-defined sanitization techniques and procedures in accordance with applicable federal and organizational standards and policies. Healthwise must destroy media containing sensitive information that cannot be sanitized.

19.2 Scope

This policy applies to any IT assets that are no longer needed within Healthwise. IT assets includes computer and networking technology such as desktops, servers, hard drives, laptops, smart phones, peripherals (i.e., keyboards, mice, speakers), monitors, printers, scanners, portable storage devices (i.e., USB drives), and networking equipment.

All Healthwise employees must comply with this policy.

19.3 Policy

When IT assets have reached the end of their useful life they should be collected by the Healthwise Service Desk for proper disposal. The Healthwise Service Desk will remove all licensed software and render any data on any storage medium inaccessible with current industry best practices. Healthwise will then forward the IT asset to a designated third-party for disposal or destruction. The third-party must have security controls consistent with those describe in these policies and experience in IT asset disposal and destruction. The third-party will provide Healthwise a certificate of disposal upon completion.

All data, including files and licensed software, shall be removed from equipment using disk sanitizing software that cleans the media overwriting every disk sector of the machine with zero-filled blocks, consistent with Department of Defense standards. All electronic drives must be degaussed or overwritten with a commercially available disk cleaning program. Hard drives may also be removed and rendered unreadable (via drilling, crushing, or other demolition methods). IT assets with non-functioning memory or storage technology will have the memory or storage device removed and destroyed. The Healthwise Service Desk will place a sticker on the equipment case indicating the data on the device's storage medium has been rendered inaccessible. The sticker will include the date and the initials of the technician who performed this. Any exceptions to this must be approved by the Healthwise Security Officer or delegate.

All IT assets must be disposed of using an approved method stated above. Prior to leaving Healthwise premises, all equipment must be removed from the Information Technology inventory system. IT assets includes any desktop, laptop, tablet or netbook computers, printers, copiers, monitors, servers, handheld device, telephones, cell phones, disc drives or any storage device, network switches, routers, wireless access points, batteries, backup tapes, etc.

No IT assets may be sold to any individual other than through the processes identified in this policy. Any IT Asset not being reused or sold must be properly disposed of in accordance with all laws and regulations.

19.4 Approved Disposal Methods

Sold to a licensed used equipment dealer or scrap dealer
Used as a trade-in against cost of replacement item
Donated to schools, charities, and other non-profit organizations
Discarded as trash

Application: An application created, maintained, and hosted by Healthwise.

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

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

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

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

Breach: The acquisition, access, use, or disclosure of Protected Health Information (PHI) in a manner not permitted under the Privacy Rule which compromises the security or privacy of the PHI. For purpose of this definition, compromises the security or privacy of the PHI means poses a significant risk of financial, reputational, or other harm to the individual. A use or disclosure of PHI that does not include the identifiers listed at 45 C.F.R. §164.514(e)(2), limited data set, date of birth, and zip code does not compromise the security or privacy of the PHI. Notwithstanding the foregoing, Breach shall have the same meaning as the term is defined under 45 C.F.R §164.402, including all conditions, limitations, and exclusions.

Business Associate: A person or entity that performs certain functions or activities that involves creating, receiving, maintaining, or transmitting Protected Health Information on behalf of, or provides services to, a Covered Entity, as more fully defined under 45 C.F.R. §160.103.

Confidential Information: All pricing terms and customer lists; Healthwise proprietary product development information and technology; any other information that if disclosed in tangible form, is marked or labeled to show that it is confidential or proprietary information of the disclosing party, or if only disclosed verbally or visually, is identified as confidential or proprietary at the time of disclosure; or as otherwise may be defined within a binding contract.

Corporate Environment: The Healthwise Corporate environment and systems. These systems exclude the Hosted Environment which is managed independently.

Covered Entity: A health plan, health care clearinghouse, or a healthcare provider who transmits any health information in electronic form in connection with a transaction, as more fully defined under 45 C.F.R. §160.103.

Customers: Contractually bound users of Healthwise's Applications.

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

De-identification: The process of removing identifiable information in a manner proscribed under 45 C.F.R. §164.514 in which data is rendered un-identifiable and no longer considered PHI.

Denial of Service or DOS: An attack that prevents or impairs the authorized use of networks, systems, or applications by exhausting resources.

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

Electronic Protected Health Information: Any Protected Health Information that is transmitted by, processed in some way, or stored in electronic media.

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

Event: An event is defined as an occurrence that does not constitute a serious adverse effect on Healthwise, its operations, or its Customers, though it may be less than optimal. Examples of events include, but are not limited to:

A hard drive malfunction that requires replacement;
Systems become unavailable due to power outage that is non-hostile in nature, with redundancy to assure ongoing availability of data;
Accidental lockout of an account due to incorrectly entering a password multiple times.

Hosted Environment: The Healthwise HITRUST environment used to host products for our SaaS offerings. These systems exclude the Corporate Environment which is managed independently.

Inappropriate Usage: A person violates acceptable computing use policies.

Indication: A sign that an Incident may have occurred or may be occurring at the present time. Examples of indications include:

The network intrusion detection sensor alerts when a known exploit occurs against an FTP server. Intrusion detection is generally reactive, looking only for footprints of known attacks. It is important to note that many IDS hits are also false positives and are neither an event nor an incident;
The antivirus software alerts when it detects that a host is infected with a worm;
Users complain of slow access to hosts on the Internet;
The system administrator sees a filename with unusual characteristics;
Automated alerts of activity from log monitors;
An alert from log monitors about file system integrity issues.

Individually Identifiable Health Information: As defined under 45 C.F.R §160.103, which includes 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.

Information Resources: An element of infrastructure that enables the transaction of certain selected significant and relevant data, prepared so as to provide content and information services that can be used.

Information Security Incident: A violation or imminent threat of violation of information security policies, acceptable use policies, or standard security practices. Examples of information security incidents may include, but are not limited to, DOS, Malicious Code, Unauthorized Access/System Hijacking and Inappropriate Usage. Other examples of observable information security incidents may include, but are not limited to:

Use of another person's individual password and/or account to login to a system;
Failure to protect passwords and/or access codes (e.g., posting passwords on equipment);
Installation of unauthorized software;
Terminated workforce member accessing applications, systems, or network.

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

Law Enforcement Official: Any officer or employee of an agency or authority of the United States, a State, a territory, or a political subdivision of a State or territory, 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.

Malicious Code: A virus, worm, Trojan horse, or other code-based malicious entity that infects a host.

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

Partner: Contractual bound 3rd party Vendor that integrates with the Healthwise Environment. May offer Add-on services.

Precursor: A sign that an Incident may occur in the future. Examples of precursors include:

Suspicious network and host-based IDS events/attacks;
Alerts as a result of detecting malicious code at the network and host levels;
Alerts from file integrity checking software;
Audit log alerts.

Privacy Officer: The person who is responsible for the development and implementation of the policies and procedures of Ignite Healthwise, LLC (Healthwise). This person is also responsible for receiving complaints under this section and who is able to provide further information about matters covered by the notice required by §164.520 of the HIPAA Security Rule.

Protected Health Information: Individually identifiable health information that is created by or received by Healthwise, including demographic information, that identifies an individual, or provides a reasonable basis to believe the information can be used to identify an individual, and relates to:

Past, present or future physical or mental health or condition of an individual.
The provision of health care to an individual.
The past, present, or future payment for the provision of health care to an individual.

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

Retention Schedule: Healthwise retains records for no less than one year, unless related to the provision of access to the production environment, in which case the record is retained for no less than three years. If the record is related to access of Protected Health Information, Healthwise retains records consistent with state and federal regulations

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

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

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

Risk Management Team: Individuals who are knowledgeable about the Healthwise'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.

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

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

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

Security Incident or Incident: An occurrence that exercises a significant adverse effect on people, process, technology, or data. Security incidents include, but are not limited to:

A system or network breach accomplished by an internal or external entity; this breach can be inadvertent or malicious;
Unauthorized disclosure;
Unauthorized change or destruction of ePHI (i.e. delete dictation, data alterations not following Healthwise's procedures);
Denial of service not attributable to identifiable physical, environmental, human or technology causes;
Disaster or enacted threat to business continuity;

Security Incident and Event Management System: Identifying, monitoring, recording, and analyzing security events or incidents within the Healthwise Environment. Attributes include retention, dashboards, correlation, alerting, data aggregation, and compliance.

Security Officer: The person who is responsible for the development and implementation of the policies and procedures required by the HIPAA Security Rule for the Covered Entity or Business Associate.

System: All servers and network devices contained in the Environment. These servers and network devices may be on-premise or cloud-based.

Threat: The potential for a particular threat-source to successfully exercise a particular vulnerability. Threats are commonly categorized as:

Environmental - external fires, HVAC failure/temperature inadequacy, water pipe burst, power failure/fluctuation, etc.
Human - hackers, data entry, workforce/ex-workforce members, impersonation, insertion of malicious code, theft, viruses, SPAM, vandalism, etc.
Natural - fires, floods, electrical storms, tornadoes, etc.
Technological - server failure, software failure, ancillary equipment failure, etc. and environmental threats, such as power outages, hazardous material spills.
Other - explosions, medical emergencies, misuse or resources, etc.

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

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

Trigger Event: Activities that may be indicative of a security breach that require further investigation.

Unauthorized Access/System Hijacking: A person gains logical or physical access without permission to a network, system, application, data, or other resource. Hijacking occurs when an attacker takes control of network devices or workstations.

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

Unsecured Protected Health Information: Protected Health Information that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Public Law 111-5.

Vendor: Persons from other organizations marketing or selling products or services, or providing services to Healthwise.

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

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

Workforce: Employees, temporary employees, volunteers, trainees, contract workers, and other persons whose conduct, in the performance of work for Healthwise, is under the direct control of Healthwise, whether or not they are paid by Healthwise.

Information Security Policies

1 Introduction

1.1 Scope

1.2 Version Control

1.3 Applicable Statutes / Regulations

1.4 Exceptions

1.5 Requesting Audit and Compliance Reports

1.6 Last Reviewed Date

1.7 Changelog

Janurary 16, 2024

Dec 19, 2022

May 3, 2022

January 31, 2022

July 13, 2021

January 29, 2021

October 22, 2020

November 24, 2019

October 31, 2019

January 14, 2019

December 14, 2018

November 26, 2018

November 13, 2018

August 8, 2018

June 28, 2018

May 10, 2018

2 Policy Management Policy

2.1 Procedures

3 Roles Policy

3.1 Privacy Officer

3.2 Security Officer

3.2.1 Organizational Responsibilities

3.2.2 Workforce Training Responsibilities

3.3 Workforce Responsibilities

3.4 Supervision of Workforce Responsibilities

3.5 Sanctions of Workforce Responsibilities

4 Acceptable Use Policy

4.1 Computer Access Control - Individual's Responsibility

4.2 Internet and Email Conditions of Use

4.3 Clear Desk and Clear Screen Policy

4.4 Working Off-site

4.5 Mobile Storage Devices

4.6 Software

4.7 Viruses

4.8 Telephony (Voice) Equipment Conditions of Use

4.9 Actions upon Termination

4.10 Healthwise Owned Computers and Peripherals

4.11 Monitoring and Filtering

5 Remote Access Policy

5.1 Unauthorized Access

5.2 Passwords

5.3 Antivirus

5.4 Software Currency

5.5 Foreign Devices

5.6 Internet Service Providers (ISP)

5.7 Staff Member Responsibility

6 Third Party Policy

6.1 Policies to Assure Third Parties Support Healthwise Compliance

6.2 Approved Tools

6.2.1 List of Approved Tools

6.3 Third-Party Software in Healthwise Products

6.4 Open Source

7 Personal Device Policy

7.1 Approved Personal Devices

7.2 Service Desk Support

7.3 Guidelines for Use of Approved Personal Devices for Business Purposes

8 Disposable Media Policy

8.1 Disposable Media Policy

9 System Access Policy

9.1 Access Establishment and Modification

9.2 Workforce Clearance

9.3 Access Authorization

9.4 Person or Entity Authentication

9.5 Unique User Identification

9.6 Automatic Logoff and Lock

9.7 Workforce Member Workstation Use

9.8 Wireless Access Use

9.9 Workforce Termination Procedures

9.10 Paper Records

9.11 Password Management

9.12 Unauthorized Access