Source: https://policy.waytohealth.org/
Timestamp: 2019-04-23 22:18:17+00:00

Document:
PennMedicine Way To Health, Inc (“WayToHealth”) is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its Customers. As a patient engagement and health research technology organization, WayToHealth strives to maintain compliance, proactively address information security, mitigate risk for its Customers, and assure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by WayToHealth to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for WayToHealth Customers.
WayToHealth provides secure and compliant software to administer behavioral change and patient engagement programs. Customers utilize the hosted software and infrastructure from WayToHealth to research and deploy evidence-based approches to engage patients in their health. WayToHealth makes every effort to reduce the risk of unauthorized disclosure, access, and/or breach of Customer data through network (firewalls, dedicated IP spaces, etc), server settings (encryption at rest and in transit etc), and application security requirements (password strength rules, account roles/privileges, etc).
WayToHealth signs business associate agreements (BAAs) with its Customers. These BAAs outline WayToHealth obligations and Customer obligations, as well as liability in the case of a breach. In providing infrastructure and managing security configurations that are a part of the technology requirements that exist in HIPAA and HITRUST, as well as future compliance frameworks, WayToHealth manages various aspects of compliance for Customers. The aspects of compliance that WayToHealth manages for Customers are inherited by Customers, and WayToHealth assumes the risk associated with those aspects of compliance as defined in the BAA. In doing so, WayToHealth achieves and maintains compliance, while mitigating Customer risk.
WayToHealth does not act as a covered entity but rather as a provider of services to covered entities and other organizations. Certain aspects of our compliance are inherited from our hosting provider, Azure or Penn Medicine Academic Compute Services (PMACS), part of Penn Medicine Corporate IS as appropriate. More details about Azure’s HITRUST and HIPAA compliance posture is available for review here. Penn Medicine’s policies and procedures are also incorporated into this document as relevant given that WayToHealth operates within the Penn Medicine umbrella.
Certain aspects of compliance cannot be inherited. Because of this, WayToHealth, in order to achieve full compliance or HITRUST Certification, has implemented certain organizational policies.
Mappings of HIPAA Rules to WayToHealth controls are covered in §2.
The physical infrastructure environment is hosted at Microsoft Azure or on PMACS. In either case, the network components and supporting network infrastructure are contained within the relevant infrastructure and is managed by the provider. WayToHealth does not have physical access into the network components. The WayToHealth environment consists of Fortinet firewalls and CentOS-based Virtual servers running Apache and/or nginx web servers; PHP and Node.js application servers; MariaDB and PostgreSQL database servers; Logstash logging servers; Ansible configuration management servers; OSSEC IDS services and / or Fortigate IPS services; Docker containers; and developer tool servers.
Within the WayToHealth Platform, all data transmission is encrypted and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers - those hosting Docker containers, databases, APIs, log servers, etc. WayToHealth assumes all data may contain ePHI, even though our Risk Assessment does not indicate this is the case, and provides appropriate protections based on that assumption.
WayToHealth additionally restricts, secures, and assures the privacy of all ePHI data at the Application Level.
Additionally, IPtables is used on each server for logical segmentation. IPtables is configured to restrict access to only justified ports and protocols. WayToHealth has implemented strict logical access controls so that only authorized personnel are given access to the internal management servers. The environment is configured so that data is transmitted from the load balancers to the application servers over an TLS encrypted session.
Once the data is received from the application server, a series of Application Programming Interface (API) calls or SQL queries is made to the database servers where the ePHI resides.
The VPN server and Apache web server are externally facing and accessible via the Internet. The application and database servers, where the ePHI resides, are located on the internal WayToHealth network and can only be accessed through a bastion host over a VPN connection. Access to the internal database is restricted to a limited number of personnel and strictly controlled to only those personnel with a business-justified reason. Remote access to internal servers is not accessible except through load balancers.
Application, database and operating systems are tested end-to-end for usability, security, and impact prior to deployment to production.
WayToHealth, at its sole discretion, can share audit reports, including its planned HITRUST reports and Corrective Action Plans (CAPs), with customers on a case by case basis. All audit reports are shared under explicit NDA in Penn Medicine’s format between Penn Medicine and party to receive materials. Audit reports can be requested by WayToHealth workforce members for Customers or directly by WayToHealth Customers.
Email is sent to compliance@waytohealth.org. In the email, please specify the type of report being requested and any required timelines for the report.
WayToHealth staff will log an issue with the details of the request into the WayToHealth Ticketing and Quality Management System (TQMS). The WayToHealth TQMS is used to track requests’ status and outcomes.
WayToHealth will confirm if a current NDA is in place with the party requesting the audit report. If there is no NDA in place, WayToHealth will send one for execution.
Once it has been confirmed that an NDA is executed, WayToHealth staff will move the issue to “Under Review”.
The WayToHealth / PennMedicine Security Officer or Privacy Officer must Approve or Reject the Issue. If the Issue is rejected, WayToHealth will notify the requesting party that we cannot share the requested report.
If the issue has been Approved, WayToHealth will send the customer the requested audit report and close the TQMS issue for the request.
These policies are managed in a private Gitlab repository managed within the University of Pennsylvania network for source control. The most recent version of the policies is available at https://policy.waytohealth.org.
These policies were last updated on June 6th, 2018.
WayToHealth implements policies and procedures to maintain compliance and integrity of data. The designated Security Officer and Privacy Officer are responsible for maintaining policies and procedures and assuring all WayToHealth workforce members, business associates, customers, and partners are adherent to all applicable policies. Previous versions of policies are retained to assure ease of finding policies at specific historic dates in time.
All policies are stored and updated to maintain WayToHealth compliance with HIPAA, HITRUST, NIST, and other relevant standards. Updates and version control are done similarly to source code control.
Policy suggestions can be made by any workforce member at any time. Furthermore, all policies are reviewed annually by the Security and Privacy Officer or their designees to assure they are accurate and up-to-date.
The WayToHealth employee initiates a policy change request by creating an Issue in the WayToHealth TQMS (TQMS). The change request may optionally include a Gitlab pull request from a separate branch or repository containing the desired changes.
Once the review is completed, the Security Officer or Privacy Officer approves or rejects the Issue. Only the Security Officer and the Privacy Officer are granted the access permissions to merge policy change requests. If the Issue is rejected, it goes back for further review and documentation.
If the policy change requires technical modifications to production systems, those changes are carried out by authorized personnel using WayToHealth’s change management process (§9.4).
All policies are made accessible to all WayToHealth workforce members. The current master policies are published at https://policy.waytohealth.org.
Changes are automatically communicated to all WayToHealth team members through integrations between GitLab and Slack that log all GitLab policy updates to a dedicated WayToHealth Slack Channel.
All policies, and associated documentation, are retained for 6 (six) years from the date of its creation or the date when it last was in effect, whichever is later.
Version history of all WayToHealth policies is done via GitLab.
The Security Officer initiates the policy review by creating an Issue in the WayToHealth TQMS.
The Security Officer or the Privacy Officer is assigned to review the current WayToHealth policies (https://policy.waytohealth.org).
If changes are made, the process described in (§3.3) above is followed. All changes are documented in the Issue.
Policy review is monitored on a quarterly basis using the TQMS reporting to assess compliance with above policy.
The Security Officer initiates the HITRUST audit activity by creating an Issue in the WayToHealth TQMS.
The Security Officer or the Privacy Officer is assigned to own and manage the HITRUST activity.
Once the HITRUST activity is completed, the Security Officer approves or rejects the Issue.
Compliance with annual compliance assessments, utilizing the HITRUST CSF as a framework, is monitored on a quarterly basis using the TQMS reporting to assess compliance with above policy.
This policy establishes the scope, objectives, and procedures of WayToHealth’s information security risk management process. The risk management process is intended to support and protect the organization and its ability to fulfill its mission.
It is the policy of WayToHealth to conduct thorough and timely risk assessments of the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI) (and other confidential and proprietary electronic information) it stores, transmits, and/or processes for its Customers and to develop strategies to efficiently and effectively mitigate the risks identified in the assessment process as an integral part of WayToHealth’s information security program.
Risk analysis and risk management are recognized as important components of WayToHealth and its parent corporate compliance program and information security program in accordance with the Risk Analysis and Risk Management implementation specifications within the Security Management standard and the evaluation standards set forth in the HIPAA Security Rule, 45 CFR 164.308(a)(1)(ii)(A), 164.308(a)(1)(ii)(B), 164.308(a)(1)(i), and 164.308(a)(8).
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 WayToHealth system.
While making changes to WayToHealth physical equipment and facilities that introduce new, untested configurations.
WayToHealth performs periodic technical and non-technical assessments of the security rule requirements as well as in response to environmental or operational changes affecting the security of ePHI.
Any risk remaining (residual) after other risk controls have been applied, requires sign off by the senior management and WayToHealth’s Security Officer.
All WayToHealth 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 WayToHealth Roles Policy (§5).
The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of WayToHealth’s Security Officer (or other designated employee), and the identified Risk Management Team.
The Security Officer or the Privacy Officer initiates the Risk Management Procedures by creating an Issue in the WayToHealth TQMS.
The Security Officer, the Privacy Officer, or a designated team member is assigned to carry out the Risk Management Procedures.
All findings are documented in the Issue comments section and/or an approved spreadsheet with associated calculations. If a spreadsheet is used, it should be attached to the Issue upon completion.
Once the Risk Management Procedures are complete, along with corresponding documentation, the Security Officer approves or rejects the Issue. If the Issue is rejected, it goes back for further review and documentation.
The Risk Management Procedure is monitored on a quarterly basis using the TQMS reporting to assess compliance with above policy.
The intent of completing a risk assessment is to determine potential threats and vulnerabilities and the likelihood and impact, should they occur. The output of this process helps to identify appropriate controls for reducing or eliminating risk.
The first step in assessing risk is to define the scope of the effort. To do this, identify where ePHI is received, maintained, processed, or transmitted. Using information-gathering techniques, WayToHealth system boundaries are identified.
Output - Characterization of the WayToHealth system assessed, a good picture of the environment, and delineation of system boundaries.
Potential threats (the potential for threat-sources to successfully exercise a particular vulnerability) are identified and documented. All potential threat-sources from historical incidents and data from intelligence agencies, the government, etc., are reviewed to help generate a list of potential threats.
Output - A threat list containing a list of threat-sources that could exploit WayToHealth system vulnerabilities.
Develop a list of technical and non-technical WayToHealth system vulnerabilities that could be exploited or triggered by potential threat-sources. Vulnerabilities can range from incomplete or conflicting policies that govern an organization’s computer usage to insufficient safeguards to protect facilities that house computer equipment to any number of software, hardware, or other deficiencies that comprise an organization’s computer network.
Output - A list of the WayToHealth system vulnerabilities (observations) that could be exercised by potential threat-sources.
Document and assess the effectiveness of technical and non-technical controls that have been or will be implemented by WayToHealth to minimize or eliminate the likelihood / probability of a threat-source exploiting a WayToHealth system vulnerability.
Output - List of current or planned controls (policies, procedures, training, technical mechanisms, insurance, etc.) used for the WayToHealth system to mitigate the likelihood of a vulnerability being exercised and reduce the impact of such an adverse event.
Output - Likelihood rating of low (.1), medium (.5), or high (1). Refer to the NIST SP 800-30 definitions of low, medium, and high.
Determine the level of adverse impact that would result from a threat successfully exploiting a vulnerability. Factors of the data and systems to consider should include the importance to WayToHealth’s mission; sensitivity and criticality (value or importance); costs associated; loss of confidentiality, integrity, and availability of systems and data.
Output - Magnitude of impact rating of low (10), medium (50), or high (100). Refer to the NIST SP 800-30 definitions of low, medium, and high.
Output - Risk level of low (1-10), medium (>10-50) or high (>50-100). Refer to the NIST SP 800-30 definitions of low, medium, and high.
Output - Recommendation of control(s) and alternative solutions to mitigate risk.
Results of the risk assessment are documented in an official report, spreadsheet, or briefing and provided to senior management to make decisions on policy, procedure, budget, and WayToHealth system operational and management changes.
Output - A risk assessment report that describes the threats and vulnerabilities, measures the risk, and provides recommendations for control implementation.
Risk mitigation involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the Risk Assessment process to ensure the confidentiality, integrity and availability of WayToHealth system ePHI. Determination of appropriate controls to reduce risk is dependent upon the risk tolerance of the organization consistent with its goals and mission.
Taking into account the information and results from previous steps, WayToHealth’s mission, and other important criteria, the Risk Management Team determines the best control(s) for reducing risks to the information systems and to the confidentiality, integrity, and availability of ePHI. These controls may consist of a mix of administrative, physical, and/or technical safeguards.
The overall implementation plan provides a broad overview of the safeguard implementation, identifying important milestones and timeframes, resource requirements (staff and other individuals’ time, budget, etc.), interrelationships between projects, and any other relevant information. Regular status reporting of the plan, along with key metrics and success indicators should be reported to WayToHealth Senior Management.
Scheduled Basis - an overall risk assessment of WayToHealth’s information system infrastructure will be conducted annually. The assessment process should be completed in a timely fashion so that risk mitigation strategies can be determined and included in the corporate budgeting process.
Throughout a System’s Development Life Cycle - from the time that a need for a new, untested information system configuration and/or application is identified through the time it is disposed of, ongoing assessments of the potential threats to a system and its vulnerabilities should be undertaken as a part of the maintenance of the system.
As Needed - the Security Officer (or other designated employee) or Risk Management Team may call for a full or partial risk assessment in response to changes in business strategies, information technology, information sensitivity, threats, legal liabilities, or other significant factors that affect WayToHealth’s WayToHealth system.
WayToHealth has a Security Officer [164.308(a)(2)] and Privacy Officer [164.308(a)(2)] appointed to assist in maintaining and enforcing safeguards towards compliance. The responsibilities associated with these roles are outlined below.
The Privacy Officer is responsible for assisting with compliance and security training for workforce members, assuring that the WayToHealth organization remains in compliance with evolving compliance rules, and helping the Security Officer in his responsibilities. A number of these requirements are inherited from the parent organization, namely Penn Medicine also known as the University of Pennsylvania Health System (UPHS) and its associated policies.
The current WayToHealth Privacy Officer is Mohan Balachandran.
Penn Medicine’s Chief Privacy Office is Lauren Steinfeld.
Existing workforce members as needed due to changes in security and risk posture of WayToHealth.
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 WayToHealth security policies and non-compliance with the security regulations [164.308(a)(1)(ii)&lpar;c&rpar;], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)].
The current WayToHealth Security Officer is Michael Kopinsky.
Penn Medicine’s Chief Information Security Officer (CISO) is Dan C. Constantino.
The Security Officer(s), in collaboration with the Privacy Officer(s), is responsible for facilitating the development, testing, implementation, training, and oversight of all activities pertaining to WayToHealth’s efforts to be compliant with the HIPAA Security Regulations, HITRUST CSF, and any other security and compliance frameworks. The intent of the Security Officer Responsibilities is to maintain the confidentiality, integrity, and availability of ePHI. The WayToHealth Security Officer reports to the COO (Chief Operating Officer / Corporate Director of Way To Health) and the Way To Health Steering Committee.
Annually, and as necessary, reviews and updates documentation to respond to environmental or operational changes affecting the security and risk posture of ePHI stored, transmitted, or processed within WayToHealth infrastructure.
Applies consistent and appropriate sanctions against workforce members who fail to comply with the security policies and procedures of WayToHealth.
Mitigates, to the extent practicable, any harmful effect known to WayToHealth of a use or disclosure of ePHI in violation of WayToHealth’s policies and procedures, even if effect is the result of actions of WayToHealth business associates, customers, and/or partners.
Reports security efforts and incidents to administration immediately upon discovery. Responsibilities in the case of a known ePHI breach are documented in the WayToHealth Breach Policy (§12).
The Security Officer works with the COO to ensure that any security objectives have appropriate consideration during the budgeting process.
In general, security and compliance are core to WayToHealth’s technology and service offerings; in most cases this means security-related objectives cannot be split out to separate budget line items.
For cases that can be split out into discrete items, such as licenses for commercial tooling, the Security Officer follows WayToHealth’s standard corporate budgeting process.
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 WayToHealth’s systems, applications, servers, workstations, etc. that contain ePHI.
Take all reasonable steps to hire, retain, and promote workforce members and provide access to users who comply with the Security regulation and WayToHealth’s security policies and procedures.
All workforce members report non-compliance of WayToHealth’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 WayToHealth’s security policies and procedures. The Security Officer may request assistance from others.
Provide individuals suspected of non-compliance of the Security rule and/or WayToHealth’s policies and procedures the opportunity to explain their actions.
Violation of any security policy or procedure by workforce members may result in corrective disciplinary action, up to and including termination of employment per UPHS policies. 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 per UPHS policies.
A violation resulting in a breach of confidentiality (i.e. release of PHI to an unauthorized individual), change of the integrity of any ePHI, or inability to access any ePHI by other users, requires immediate revokation of access to all aspects of WayToHealth. Termination of the workforce member will follow UPHS policies.
In the case of an insider threat, the Security Officer and Privacy Officer are to set up a team to investigate and mitigate the risk of insider malicious activity. WayToHealth workforce members are encouraged to come forward with information about insider threats, and can do so anonymously.
WayToHealth has procedures to create and maintain retrievable exact copies of electronic protected health information (ePHI) utilizing our Backup Service. This policy, and associated procedures for testing and restoring from backup data apply generally to all WayToHealth Customers excepting those Customers that do not choose or opt-out of the WayToHealth Backup Service. The policy and procedures will assure that complete, accurate, retrievable, and tested backups are available for all Customers using WayToHealth.
Data backup is an important part of the day-to-day operations of WayToHealth. To protect the confidentiality, integrity, and availability of ePHI, both for WayToHealth and WayToHealth Customers, complete backups are done daily to assure that data remains available when it is needed and in case of a disaster.
Violation of this policy and its procedures by workforce members may result in corrective disciplinary action, up to and including termination of employment per UPHS policies.
Perform daily (snapshot / logical or binary dump) backups of all systems that process, store, or transmit ePHI for WayToHealth Customers.
The WayToHealth Dev and Infrastructure Team is designated to be in charge of backups.
Dev and Infrastructure Team members are trained and assigned to complete backups and manage the backup media.
A WayToHealth workforce member initiates the access request by creating a Ticket in the WayToHealth TQMS.
For new accounts, the method used to verify the user’s identity must be recorded on the Ticket.
The Security Officer or designated personnel will grant access to systems as dictated by the employee’s job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
Once the review is completed, the Security Officer or designated personnel or Privacy Officer approves or rejects the Ticket. If the Ticket is rejected, it goes back for further review and documentation.
If the review is approved, the Security Officer or designated personnel or Privacy Officer then marks the Ticket as Approved, adding any pertinent notes required. The Security Officer, Privacy Officer, or designated team member then grants requested access and marks the Ticket as Done.
For newly created accounts on core WayToHealth applications, an email will be sent to the user with a link to set an initial secure password that meets all requirements from §7.12.
On some ancillary systems, an initial temporary password will be generated, which must also meet all requirements from §7.12 and must also be changed on the first login. All such password exchanges must occur over an authenticated channel.
Access is not granted until review and approval by the WayToHealth Security Officer or Privacy Officer.
The Security Officer or designated personnel initiates the review of user access by creating an Ticket in the WayToHealth TQMS.
The Security Officer or designated personnel is assigned to review levels of access for each WayToHealth workforce member.
If user access is found during review that is not in line with the least privilege principle, the process below is used to modify user access and notify the user of access changes. Once those steps are completed, the Ticket is then reviewed again.
Once the review is completed, the Security Officer or designated personnel approves or rejects the Ticket. If the Ticket is rejected, it goes back for further review and documentation.
If the review is approved, the Security Officer or designated personnel then marks the Ticket as Done, adding any pertinent notes required.
Review of user access is monitored on a quarterly basis using the TQMS reporting to assess compliance with above policy.
Any WayToHealth workforce member can request change of access using the process outlined in §7.2 paragraph 1.
Accounts are reviewed every 90 days to ensure temporary accounts are not left unnecessarily active.
User accounts on systems containing highly sensitive or confidential data that have not been accessed for ninety (90) days will be disabled.
Privileged users (e.g., system administrators) must have their access rights reviewed at least two (2) times per year by the Information Owner to ensure access to UPHS/SOM information is appropriate.
Users with access to privileged accounts must use their non-privileged user account to log into the system. These users must take care to only log into their privileged accounts when necessary, and only for the duration required to complete the task requiring privileged access.
In the case of non-personal information, such as generic educational content, identification and authentication may not be required. This is the responsibility of WayToHealth Customers to define, and not WayToHealth.
Rights for privileged accounts are granted by the Security Officer or designated personnel or Privacy Officer using the process outlined in §7.2 paragraph 1.
All application to application communication using service accounts is restricted and not permitted unless absolutely needed.
Generic accounts are not allowed on WayToHealth systems.
Server access is granted through encrypted, VPN tunnels that utilize two-factor authentication.
Two-factor authentication is accomplished using Duo Security.
A WayToHealth workforce member initiates the access request by creating an Issue in the WayToHealth TQMS for the Project Manager (PM).
No access outside of the minimum necessary to perform job functions will be provided.
Once access has been granted to the project PM, s/he will invite other members necessary to accomplish their project objectives as needed via the user interface provided. Invites require names, email addresses and roles at the very minimum. The verification of names and email addresses are the PM’s responsibility and is not verified by WayToHealth.
Customer personnel, once invited, will be required to set their username and password that meets all requirements from §7.12.
Customer personnel are required to follow their organization’s HIPAA and other privacy policies.
Customer personnel are required to sign a Data Security Agreement before getting access to the application.
Generic and temporary accounts are not allowed on WayToHealth systems.
Personnel who have not accessed the system in more than three (3) months will have their accounts terminated.
PMs will be required to actively review the personnel with access to their programs on a quarterly basis.
Direct system to system, system to application, and application to application authentication and authorization are limited and controlled to restrict access. This will primarily apply in the case where sysem to system integration is required.
WayToHealth maintains a minimum necessary approach to access to Customer data. As such, WayToHealth workforce members, are mandated by policy to only have access to ePHI to provide support services.
Role based access categories for each WayToHealth system and application are pre-approved by the Security Officer or designated personnel.
WayToHealth utilizes hardware and software firewalls to segment data, prevent unauthorized access, and monitor traffic for denial of service attacks.
Each user 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 WayToHealth support personnel will satisfy any request having information security implications.
WayToHealth’s current support desk software, Service Desk, requires users to authenticate before submitting support tickets.
Support issues submitted via WayToHealth’s dashboard require that users authenticate with their WayToHealth account before submitting support tickets.
Support issues submitted by email must be verified by WayToHealth personnel using a phone number that has been registered with the corresponding account.
Access to the WayToHealth systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
Shared accounts are not allowed within WayToHealth systems or networks.
Automated log-on configurations that store user passwords or bypass password entry are not permitted for use with WayToHealth workstations or production systems. The use of an enterprise-grade password manager (such as LastPass) is required for all workforce members.
For server access, users are assigned IDs that are consistent with theur current PennKey IDs. The privilege level of the account should not be identifiable within the userID (e.g., a userID named “sysadmin1” is not permissible).
The Security Officer or designated personnel generally rejects but can pre-approve exceptions to automatic log off requirements.
All workstations at WayToHealth are owned and managed by UPHS and/or PMACS (Penn Medicine Academic Computing Services).
Must have the following language added to the lock and login screens: This computer is owned by Way to Health/Penn Medicine. By logging in, unlocking, and/or using this computer you acknowledge you are authorized to use this computer and agree to follow the policies at https://policy.waytohealth.org. UPHS-managed devices will have lock screen info as dictated by UPHS policy/practice.
WayToHealth production systems are not accessible directly over wireless channels.
Passwords are rotated on a regular basis, presently annually. This process is managed by the WayToHealth Security Officer or designated personnel.
System access is further restricted to be over VPN only.
The Human Resources Department of UPHS (or other designated department), users, and their supervisors are notified by the Security Officer or designated personnel to terminate specific personnel. Based upon the date of termination and upon completion and/or termination of personnel, access is termnated based upon the “Termination Checklist” ticket filed in the TQMS. The ticket is assigned to authorized individual(s) and must be completed within 24 hours.
The Security Officer or designated personnel will terminate users’ access rights immediately upon notification, and will coordinate with the appropriate WayToHealth employees to terminate access to any non-production systems managed by those employees.
The Security Officer or designated personnel audits and may terminate access of users that have not logged into organization’s information systems/applications for an extended period of time.
WayToHealth does not use paper records for any sensitive information. Use of paper for recording and storing sensitive data is against WayToHealth policies.
User IDs and passwords are used to control access to WayToHealth systems and may not be disclosed to anyone for any reason.
Passwords that must be stored in non-hashed format must be encrypted at rest pursuant to the requirements in §17.8.
Transmitted passwords must be encrypted in flight pursuant to the requirements in §17.9.
Passwords are deactivated immediately upon an employee’s termination (refer to the Employee Termination Procedures in §7.10).
There are no default system or application passwords.
Passwords are not auto-generated for users. Users must set their passwords when invited following the complexity rules defined above.
Password change methods must use a confirmation method to correct for user input errors such as matching entries.
If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Officer or designated personnel. A specific form on the user support portal is used for this purpose.
The user submits a password reset request via the user interface.
The system automatically generates a password reset link and sends it to the email address on record for the user.
The user can click on the link provided and if the new password passes the complexity check, the password is reset.
WayToHealth shall audit access and activity of electronic protected health information (ePHI) applications and systems in order to ensure compliance. The Security Rule requires healthcare organizations to implement reasonable hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Audit activities may be limited by application, system, and/or network auditing capabilities and resources. WayToHealth 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.
This policy applies to all WayToHealth systems that store, transmit, or process ePHI.
All connections to WayToHealth are monitored. Access is limited to certain services, ports, and destinations. Exceptions to these rules, if created, are reviewed on an annual basis.
WayToHealth’s auditing processes shall address access and activity at the following levels listed below. WayToHealth uses software to aggregate and view User and Application logs. Auditing processes may address date and time of each log-on attempt, date and time of each log-off attempt, devices used, functions performed, etc.
Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities. WayToHealth uses Nessus by Tenable for vulnerability scanning. These scans are run four (4) times a day and logs reviewed at least quarterly. IPS (Intrusion Prevention System) is managed via Fortigate on the Fortinet Firewalls.
WayToHealth shall log all incoming and outgoing traffic to into and out of its environment. This includes all successful and failed attempts at data access and editing. Data associated with this data will include origin, destination, time, and other relevant details that are available to WayToHealth.
WayToHealth leverages process monitoring tools throughout its environment.
WayToHealth shall identify “trigger events” or criteria that raise awareness of questionable conditions of viewing of confidential information. The “events” may be applied to the entire WayToHealth Platform or may be specific to a Customer, partner, business associate or external application (See Listing of Potential Trigger Events below).
Vulnerability scan results are reviewed four (4) times a day by Penn Medicine IS for guest operating systems.
Application, database and similar logs are reviewed monthly by the Security Officer or designated personnel.
Identification of which WayToHealth workforce members will be responsible for review (workforce members shall not review audit logs that pertain to their own system activity).
Testing shall be done on a routine basis, currently quarterly.
Software patches and updates will be applied to all systems in a timely manner, minimally on a quarterly basis.
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 or designated personnel, Customer, Partner, or application user.
A request for an audit for specific cause must include time frame, frequency, and nature of the request. The request must be reviewed and approved by WayToHealth’s Privacy or Security Officer or designated personnel.
A request for an audit must be approved by WayToHealth’s Privacy Officer and/or Security Officer or designated personnel 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 WayToHealth’s Security Officer or designated personnel 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 WayToHealth’s Privacy Officer or designee. Prior to communicating with customers and partners regarding an audit, it is recommended that WayToHealth consider seeking risk management and/or legal counsel.
The Security Officer or designated personnel initiates the log review by creating an Ticket in the WayToHealth TQMS.
The Security Officer or a WayToHealth Security Engineer assigned by the Security Officer, is assigned to review the logs.
Relevant audit log findings are added to the Ticket; these findings are investigated in a later step. Once those steps are completed, the Ticket is then reviewed again.
Once the review is completed, the Security Officer or designated personnel approves or rejects the Ticket. Relevant findings are reviewed at this stage. If the Ticket is rejected, it goes back for further review and documentation. The communications protocol around specific findings are outlined below.
If the Ticket is approved, the Security Officer or designated personnel then marks the Ticket as Done, adding any pertinent notes required.
Significant findings shall be reported immediately in a written format. WayToHealth’s security incident response form may be utilized to report a single event.
Security audits constitute an internal, confidential monitoring practice that may be included in WayToHealth’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).
Log review activity is monitored on a quarterly basis using the TQMS reporting to assess compliance with above policy.
Periodic monitoring of Customer and Partner activity shall be carried out to ensure that access and activity is appropriate for privileges granted and necessary to the arrangement between WayToHealth and the 3rd party. WayToHealth 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, WayToHealth’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, WayToHealth must take immediate action to remediate the situation. Continued violations may result in discontinuation of the business relationship.
Audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges.
Separate systems are used to apply the security principle of “separation of duties” to protect audit trails from hackers.
WayToHealth logging servers include Elasticsearch, Logstash, and Kibana (ELK) as part of their baseline configuration to ease reviewing of audit log data. The ELK toolkit provides message summarization, reduction, and reporting functionality.
WayToHealth workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and ePHI. WayToHealth’s commitment to auditing access and activity of the information applications, systems, and networks is communicated through new employee orientation, ongoing training opportunities and events, and applicable policies derived wholly from UPHS. WayToHealth workforce members are made aware of responsibilities with regard to privacy and security of information as well as applicable sanctions/corrective disciplinary actions should the auditing process detect a workforce member’s failure to comply with organizational policies.
WayToHealth Customers are provided with necessary information to understand WayToHealth auditing capabilities, when requested.
Audit log data is retained locally on the audit log server for a one-month period. Beyond that, log data is encrypted and moved to warm storage (e.g. Azure Storage) using automated scripts, and is retained for a minimum of one year.
WayToHealth standardizes and automates configuration management through the use of Ansible and Terraform scripts as well as documentation of all changes to production systems and networks. Ansible automatically configures all WayToHealth systems according to established and tested policies, and are used as part of our Disaster Recovery plan and process.
No systems are deployed into WayToHealth environments without approval of the WayToHealth Engineering Lead.
All changes to production systems are approved by the WayToHealth Engineering Lead before they are implemented to assure they comply with business and security requirements.
An up-to-date inventory of systems, including corresponding architecture diagrams for related products and services, is maintained in Confluence pages in the WayToHealth TQMS.
All systems are categorized as production, test, staging, and utility to differentiate based on criticality.
These reports are used to generate and / or maintain the diagrams and asset lists required by the Risk Assessment phase of WayToHealth’s Risk Management procedures (§4.3.1).
On a regular frequency, currently quarterly, the Security Officer or designated personnel will verify the accuracy of the reports by reconciling their output with recent changes to production systems. The Security Officer or designated personnel will address any discrepancies immediately with changes to the scripts.
All frontend functionality (admin dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers or containers.
WayToHealth utilizes test (development) and staging environments that mirror production to assure proper function.
WayToHealth also deploys environments locally to assure functionality before moving to staging or production.
All change requests must be formally filed and authorized before implementation.
WayToHealth uses the Security Technical Implementation Guides (STIGs) published by the Defense Information Systems Agency as a baseline for hardening systems.
Before provisioning any systems, engineering team members must file a request in the WayToHealth TQMS.
TQMS access requires authenticated users.
The Engineering Lead grants access to the TQMS following the procedures covered in the Access Establishment and Modification section.
The Engineering Lead, or an authorized delegate of the Engineering Lead, must approve the provisioning request before any new system can be provisioned.
Once provisioning has been approved, the Infrastructure team member must configure the new system according to the standard baseline chosen for the system’s role.
For Linux systems, this means adding the appropriate configurations to the Ansible and / or Terraform configuration file.
If the system will be used to house production data (ePHI), the engineering team member must encrypt the associated data volume of the VM during provisioning.
For systems on cloud providers, the engineering team member must add a block data volume and set up OS-level data encryption using Ansible or Terraform.
Removal of default users used during provisioning.
All items listed below in the operating system-specific subsections below.
Once the Engineering Lead has verified the new system is correctly configured, the team member must add that system to the security scanner configuration.
The new system may be rotated into production once the Engineering Lead verifies all the provisioning steps listed above have been correctly followed and has marked the Ticket with the Approved state.
Stopping and disabling any unnecessary OS services.
Configuring LUKS volumes (where necessary) for providers that do not have native support for encrypted data volumes, including ensuring that encryption keys are protected from unauthorized access.
Configuring IDS and antivirus/antimalware agents.
Any additional Ansible states applied to the Linux system must be clearly documented by the engineering team member in the request by specifying the purpose of the new system.
Provisioning management systems such as Ansible servers, LDAP servers, or VPN appliances follows the same procedure as provisioning a production system.
Critical infrastructure services such as logging, monitoring and LDAP servers must be configured with appropriate Ansible states.
Critical infrastructure roles applied to new systems must be clearly documented by the infrastructure team member in the provisioning request.
For configuration changes that cannot be handled by Terraform or Ansible, a runbook describing exactly what changes will be made and by whom.
Configuration changes to Terraform recipes or Ansible states must be initiated by creating a Merge Request in GitLab.
The engineering team member will create a feature branch and make their changes on that branch.
The engineering team member must test their configuration change locally when possible, or on a development and/or staging sandbox otherwise.
At least one other engineering team member must review the Terraform or Ansible change before merging the change into the main branch.
In all cases, before rolling out the change to production, the engineering team member must file an Ticket describing the change. This Ticket must link to the reviewed Merge Request and/or include a link to the runbook.
Once the request has been approved by the Engineering Lead, the engineering team member may roll out the change into production environments.
WayToHealth uses a combination of manual processes and automated tooling to ensure systems are up-to-date with the latest security patches.
On CentOS Linux systems, the cron tool is used to apply security patches in phases.
The security team maintains a mirrored snapshot of security patches from the upstream OS vendor. This mirror is synchronized bi-weekly and applied to development and staging systems monthly.
If the development and staging systems function properly after a one-week testing period, these patches will be applied to all production systems during the next patch run.
Patches for critical kernel security vulnerabilities may be applied to production systems using hot-patching tools at the discretion of the Security Officer or designated personnel. These patches must follow the same phased testing process used for non-kernel security patches; this process may be expedited for severe vulnerabilities.
Once the feature and corresponding tests are complete, a pull request will be created using the GitLab web or command line interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.
Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the designated technical reviewer will be notified using an appropriate mechanism, typically via an @user message in Slack.
The designated engineer(s) will review the changes, using the guidelines above.
If the feature or defect interacts with ePHI, or controls access to data potentially containing ePHI, the code changes must be reviewed as follows before the feature is marked as complete.
Perform a security analysis of features to ensure they satisfy WayToHealth’s compliance and security commitments.
Perform a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10 or the CWE top 25.
Verify that any actions performed by authenticated users will generate appropriate audit log entries.
Designated engineers will be required to undergo annual training on identifying the most common software vulnerabilities and will receive ongoing training on WayToHealth’s compliance and security requirements.
Once the review process finishes, each reviewer should leave a comment on the pull request saying “looks good to me” (often abbreviated as “LGTM”) or similar, at which point the original author(s) may merge their change into the release branch.
Software releases are treated as changes to existing systems and thus follow the procedure described in §9.4.
WayToHealth works with Subcontractors to assure restriction of physical access to systems used as part of the WayToHealth Platform. WayToHealth and its Subcontractors control access to the physical buildings/facilities that house these systems/applications, or in which WayToHealth workforce members operate, in accordance to the HIPAA Security Rule 164.310 and its implementation specifications. Physical Access to all of WayToHealth 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 WayToHealth’s facility.
Of note, WayToHealth does not physically house any systems used by its Platform in WayToHealth facilities. Physical security of our Platform servers is outlined in §1.1.
WayToHealth maintains offices within The University Of Pennsylvania campus. Access to the building is restricted by badge access. WayToHealth inherits security, repair and maintenance, insurance and other requirements from the parent UPHS and University of Pennsylvania organizations.
Physical access is restricted using badges and keys where necessary.
Restricted areas and facilities are locked when unattended (where feasible).
Only authorized workforce members receive access to restricted areas.
Workforce members must report a lost and/or stolen key(s) immediately to the floor manager (Dana Opeila).
The floor manager will facilitate the changing of the lock(s) per UPHS/PSOM policies.
Visitors in violation of this policy are subject to loss of vendor privileges and/or termination of services from WayToHealth.
All workstations purchased by WayToHealth are the property of UPHS or the University of Pennsylvania and are distributed to users by the those organizations.
WayToHealth implements an information security incident response process to consistently detect, respond, and report incidents, minimize loss and destruction, mitigate the weaknesses that were exploited, and restore information system functionality and business continuity as soon as possible.
Note: These policies are inherited from Penn Medicine’s Incident Response policy.
The WayToHealth incident response process follows the processes defined by Penn Medicine. This is based on the policy updated as of 5/31/2016 (ISD-SEC-10). These are defined as follows.
Penn Medicine must ensure the effective response to and management of security events that may compromise the confidentiality, integrity or availability of confidential data or other Penn Medicine assets. This document, the Security Incident Response Policy (or “Policy”) outlines the governance and procedures to define, address, and report on incident response activities.
The purpose of this Policy is to direct individuals and offices in responding to security incidents in a structured, efficient, and compliant manner.
This Policy applies to all members of the workforce of Penn Medicine and all Security Incidents, as defined below. This Policy is owned by and resides with the Penn Medicine Corporate Information Services (IS). This Policy also involves significant participation by the Offices of Information Security, Privacy, General Counsel, and other areas of Penn Medicine as needed. This Policy should be reviewed and updated periodically, informed by experience addressing data security incidents and tabletop exercises.
All Penn Medicine workforce members, as defined above, are responsible for implementation of this policy.
IS is responsible for the operation of Penn Medicine’s data networks as well as the establishment of information security policies, guidelines, and standards. The Office of Audit, Compliance and Privacy, including the PMPO, has authority to develop and oversee policies and procedures regarding the privacy of personal information. These offices therefore have the authority and responsibility to specify security incident response requirements to protect those networks as well as Penn Medicine data contained on those networks.
1.1. Workforce members who suspect a security incident has taken place are required by policy to notify the Office of Information Security (“OIS”). See UPHS Information Security Incident Reporting Policy.
1.2.1. Establishing an Incident Response Team when, based on the level of risk, that a Team-based approach would be warranted to address such risk. See Section 2.
1.2.2. Following Incident Handling Procedures as appropriate. See Section 3.
1.3. OIS must determine whether Protected Health Information (PHI) or other Confidential Data is or was vulnerable or exposed.
1.4. If OIS has been determined that PHI or other Confidential Data was vulnerable or exposed in connection with the Security Incident, OIS must notify the Penn Medicine Privacy Office (PMPO). The PMPO is responsible for ensuring that Breach Analysis and Response Procedures are followed. See Section 4 below.
a. Generate the creation of an Immediate Response Team on a per incident basis when, based on the level of risk, a Team-based approach would be warranted to address such risk. See Section 2 below.
b. Follow appropriate Breach Analysis and Response procedures. See Section 4 below. OIS is responsible for logging, investigating, and reporting on data security incidents.
2.1. Purpose. The purpose of each Immediate Response Team is to supplement Penn Medicine’s information security infrastructure and minimize the threat of damage resulting from Security Incidents.
2.2. Per Incident Basis. An Immediate Response Team shall be created for Security Incidents, when OIS or OACP determines such a Team is appropriate to address the incident.
2.3. Membership. Membership on the Immediate Response Team shall be as designated by OIS. In most cases, members shall include a representative from OIS Information Security and from the affected area’s technical and management staff. In the case of a Data Security Incident, such Team shall also include a member of the PMPO.
2.4. Responsibilities. Responsibilities of the Immediate Response Team are to assess the incident and follow incident handling procedures, appropriate to the incident as determined by OIS. In the case of Data Security Incidents, responsibilities also include assisting in the PMPO’s Breach Analysis and Response.
2.5. Confidentiality. Immediate Response Team members will share information about security incidents beyond the Immediate Response Team only on a need-to-know basis, and only after consultation with all other team members.
3. Incident Handling: The following is a list of response priorities that should be reviewed and followed as recommended by OIS. The most important items are listed first.
3.1. Safety and Human Issues. If an information system involved in a security incident affects human life and safety, responding to any incident involving any life-critical or safety-related system is the most important priority.
3.2. Address Urgent Concerns. There may be urgent concerns about the availability or integrity of critical systems or data that must be addressed promptly.
3.3. Establish Scope of Incident. The Immediate Response Team shall promptly work to establish the scope of the incident and to identify the extent of systems and data affected. This includes determining whose hands the data may have fallen into, and the length and extent of the exposure.
3.4. Determine the scope of the data. This includes an analysis of the amount and type of data that was exposed.
3.5. Containment. Once life-critical and safety issues have been resolved, the Immediate Response Team shall identify and implement actions to be taken to reduce the potential for the spread of an incident or its consequences across additional systems and networks. Such steps may include requiring that the system be disconnected from the network.
3.6. Develop Plan for Preservation of Evidence. The Immediate Response Team shall develop a plan promptly upon learning about an incident for identifying and implementing appropriate steps to preserve evidence, consistent with the needs to restore availability. Preservation plans may include preserving relevant logs and screen captures. The affected system may not be rebuilt until the Immediate Response Team determines that appropriate evidence has been preserved. Preservation will be addressed as quickly as possible to restore availability that is critical to maintain operations.
3.7. Investigate the Incident. The Immediate Response Team shall investigate the causes of the incident and future preventative actions. During the investigation phase, members of the incident response team will attempt to determine exactly what happened during the incident, especially the vulnerability that made the incident possible. In short, investigators will attempt to answer the following questions: Who? What? Where? When? How?
3.8. Incident-Specific Risk Mitigation. The Immediate Response Team shall identify and recommend strategies to mitigate risk of harm arising from the incident, including but not limited to reducing, segregating, or better protecting personal, proprietary, or mission critical data.
3.9. Restore Availability. Once the above steps have been taken, and upon authorization by the Immediate Response Team, the availability of affected devices or networks may be restored.
3.10. Penn Medicine-Wide Learning. The Immediate Response Team shall develop and arrange for implementation of a communications plan to spread learning from the security incident throughout Penn Medicine to individuals best able to reduce risk of recurrence of such incident. This Penn Medicine-wide learning must utilize solely de-identified PHI in order to avoid a possible breach.
Breach Analysis and Response 4.1 When PHI has been vulnerable or exposed, the PMPO shall, based on information gathered by the Incident Response Team, conduct an analysis of whether a “breach” as defined by HIPAA has occurred. 4.2 If a breach has occurred, the PMPO – in consultation with Entity Privacy Officers, the Office of General Counsel, and Human Resources as appropriate – will develop and implement a plan to notify the patient(s) affected within 60 days, consistent with requirements under HIPAA. 4.3 If a breach has occurred and the number of individuals affected is greater than 500, the PMPO is responsible for ensuring appropriate notification to HHS, the media, and the data subjects within 60 days, consistent with requirements under HIPAA. 4.4 At the latest, by the close of February of any calendar year, PMPO is responsible for reporting to HHS any breaches that have occurred in the prior calendar year. 4.5 All security incidents involving PHI or other Confidential Data, regardless of whether they qualify as a “breach” under HIPAA, must be logged in the Navex system maintained by OACP, or any successor system.
Senior Response Team The Senior Response Team (SRT) consists of The Associate Vice President for Audit, Compliance and Privacy, the Penn Medicine General Counsel, the Penn Medicine Chief Information Officer and Vice President, and the Senior Vice President for Communications. The SRT can be convened by any member of the Senior Response Team when requested. Ordinarily, this will be in cases of incidents or breaches with significant impact to the individuals or the organization. The SRT will be charged with the responsibility to (1) determine whether additional briefing of leadership is warranted (2) guide and oversee investigations, required notifications, and other material responses to the security incident.
DEFINITIONS: Security Incident: A real or suspected adverse event in relation to the security of information systems, networks, data, or other assets such as a Denial of Service/Distributed Denial of Service attack, website defacement, ransom ware (Malware) or a breach, among many other things. Breach: A type of security incident that encompasses the unauthorized access, use, or disclosure of unsecured PHI, as further defined by HIPAA, and other Confidential Data. Workforce Member: All faculty members, physicians, employees, volunteers, trainees, and other persons whose conduct, in the performance of work for a covered entity, is under the direct control of such entity, whether or not they are paid by the covered entity.
In the case of a breach, WayToHealth shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals.
Breach Investigation: The WayToHealth Security Officer shall name an individual to act as the investigator of the breach (e.g., privacy officer, security officer, risk manager, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others in the organization as appropriate (e.g., administration, security incident response team, human resources, risk management, public relations, legal counsel, etc.) The investigator shall be the key facilitator for all breach notification processes to the appropriate entities (e.g., HHS, media, law enforcement officials, etc.). All documentation related to the breach investigation, including the risk assessment, shall be retained for a minimum of six years. A template breach log is located here.
The cause of the breach, and the entity responsible for the breach, either Customer, WayToHealth, or Partner.
Timeliness of Notification: Upon discovery of a breach, notice shall be made to the affected WayToHealth Customers no later than 4 hours after the discovery of the breach. It is the responsibility of the organization to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay.
A brief description of what WayToHealth is doing to investigate the breach, to mitigate harm to individuals and Customers, and to protect against further breaches.
Methods of Notification: WayToHealth Customers will be notified via email and phone within the timeframe for reporting breaches, as outlined above.
Workforce Training: WayToHealth shall train all members of its workforce on the policies and procedures with respect to ePHI as necessary and appropriate for the members to carry out their job responsibilities. Workforce members shall also be trained as to how to identify and report breaches within the organization.
Complaints: WayToHealth must provide a process for individuals to make complaints concerning the organization’s patient privacy policies and procedures or its compliance with such policies and procedures.
Retaliation/Waiver: WayToHealth may not intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual for the exercise by the individual of any privacy right. The organization may not require individuals to waive their privacy rights under as a condition of the provision of treatment, payment, enrollment in a health plan, or eligibility for benefits.
Notice to Media: WayToHealth Customers are responsible for providing notice to prominent media outlets at the Customer’s discretion.
Notice to Secretary of HHS: WayToHealth Customers are responsible for providing notice to the Secretary of HHS at the Customer’s discretion.
A brief description of what WayToHealth is doing to investigate the breach, to mitigate harm to individuals, and to protect against further breaches.
The WayToHealth Contingency Plan establishes procedures to recover WayToHealth following a disruption resulting from a disaster. This Disaster Recovery Policy is maintained by the WayToHealth Security Officer and Privacy Officer.
Identify the activities, resources, and procedures needed to carry out WayToHealth processing requirements during prolonged interruptions to normal operations.
Identify and define the impact of interruptions to WayToHealth systems.
Assign responsibilities to designated personnel and provide guidance for recovering WayToHealth during prolonged periods of interruption to normal operations.
Ensure coordination with other WayToHealth staff who will participate in the contingency planning strategies.
This WayToHealth Contingency Plan has been developed as required under the Office of Management and Budget (OMB) Circular A-130, Management of Federal Information Resources, Appendix III, November 2000, and the Health Insurance Portability and Accountability Act (HIPAA) Final Security Rule, Section §164.308(a)(7), which requires the establishment and implementation of procedures for responding to events that damage systems containing electronic protected health information.
This WayToHealth Contingency Plan is created under the legislative requirements set forth in the Federal Information Security Management Act (FISMA) of 2002 and the guidelines established by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-34, titled “Contingency Planning Guide for Information Technology Systems” dated June 2002.
WayToHealth defined two categories of systems from a disaster recovery perspective.
The following order of succession to ensure that decision-making authority for the WayToHealth Contingency Plan is uninterrupted. The Engineering Lead is responsible for ensuring the safety of personnel and the execution of procedures documented within this WayToHealth Contingency Plan. If the Engineering Lead is unable to function as the overall authority or chooses to delegate this responsibility to a successor, the COO shall function as that authority. To provide contact initiation should the contingency plan need to be initiated, please use the contact list below.
The Engineering Team is responsible for recovery of the WayToHealth hosted environment, network devices, and all servers. Members of the team include personnel who are also responsible for the daily operations and maintenance of WayToHealth. The team leader is the Engineering Lead and directs the engineering Team.
The Ops Team is responsible for assuring all applications are working as intended. It is also responsible for testing redeployments and assessing damage to the environment. The team leader is the Product Manager and directs the Ops Team.
Members of the Engineering and Ops teams should ideally maintain local copies of the contact information from §13.2.
The Engineering Lead shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test. 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 (within 365 days). 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.
This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to WayToHealth. Based on the assessment of the Event, sometimes according to the WayToHealth Incident Response Policy, the Contingency Plan may be activated by either the Engineering Lead.
The first responder is to notify the Engineering Lead. All known information must be relayed to the Engineering Lead.
The Engineering Lead is to contact the Ops Team and inform them of the event. The Engineering Lead is to to begin assessment procedures.
The Engineering Lead is to notify team members and direct them to complete the assessment procedures outlined below to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the Engineering Lead is to following the steps below.
The Engineering Lead is to logically assess damage, gain insight into whether the infrastructure is salvageable, and begin to formulate a plan for recovery.
Upon notification, the Engineering Lead is to follow the procedures for damage assessment with combined Engineering and Ops Teams.
WayToHealth will be unavailable for more than 24 hours.
Other criteria, as appropriate and as defined by WayToHealth.
If the plan is to be activated, the Engineering Lead is to notify and inform team members of the details of the event and if relocation is required.
Upon notification from the Engineering Lead, group leaders and managers are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary.
The Engineering Lead is to notify the hosting facility partners that a contingency event has been declared and to ship the necessary materials (as determined by damage assessment) to the alternate site.
The Engineering Lead is to notify remaining personnel and executive leadership on the general status of the incident.
The following procedures are for recovering the WayToHealth infrastructure at the alternate site. Procedures are outlined per team required. Each procedure should be executed in the sequence it is presented to maintain efficient operations.
Recovery Goal: The goal is to rebuild WayToHealth infrastructure to a production state.
This section discusses activities necessary for restoring WayToHealth operations at the original or new site. The goal is to restore full operations within 24 hours of a disaster or outage. When the hosted data center at the original or new site has been restored, WayToHealth operations at the alternate site may be transitioned back. The goal is to provide a seamless transition of operations from the alternate site to the computer center.
If the WayToHealth environment is moved back to the original site from the alternative site, all hardware used at the alternate site should be handled and disposed of according to the WayToHealth Media Disposal Policy.
WayToHealth recognizes that media containing ePHI may be reused when appropriate steps are taken to ensure that all stored ePHI has been effectively rendered inaccessible. Destruction/disposal of ePHI shall be carried out in accordance with federal and state law. The schedule for destruction/disposal shall be suspended for ePHI involved in any open investigation, audit, or litigation.
WayToHealth utilizes dedicated hardware from Subcontractors. ePHI is only stored on SSD volumes in our hosted environment. All SSD volumes utilized by WayToHealth and WayToHealth Customers are encrypted. WayToHealth does not use, own, or manage any mobile devices, SD cards, or tapes that have access to ePHI.
WayToHealth 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 WayToHealth’s written retention policy/schedule. Records that have satisfied the period of retention will be destroyed/disposed of in an appropriate manner.
All WayToHealth Subcontractors provide that, upon termination of the contract, they will return or destroy/dispose of all patient health information. In cases where the return or destruction/disposal is not feasible, the contract limits the use and disclosure of the information to the purposes that prevent its return or destruction/disposal.
In the cases of a WayToHealth Customer terminating a contract with WayToHealth and no longer utilizing WayToHealth Services, the following actions will be taken depending on the WayToHealth Services in use. In all cases it is solely the responsibility of the WayToHealth Customer to maintain the safeguards required of HIPAA once the data is transmitted out of WayToHealth Systems.
In the case of Customer termination, WayToHealth will provide the customer with the ability to export data in commonly used format, currently CSV, for 30 days from the time of termination.
In order to preserve the integrity of data that WayToHealth stores, processes, or transmits for Customers, WayToHealth implements strong intrusion detection tools and policies to proactively track and retroactively investigate unauthorized access. WayToHealth currently utilizes OSSEC to track file system integrity, monitor log data, and detect rootkit access.
WayToHealth firewalls monitor all incoming traffic to detect potential denial of service attacks. Suspected attack sources are blocked automatically. Additionally, our hosting provider actively monitors its network to detect denial of services attacks.
WayToHealth utilizes redundant firewall on network perimeters.
WayToHealth is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. WayToHealth utilizes Nessus Scanner from Tenable to consistently scan, identify, and address vulnerabilities on our systems.
Nessus management is performed by the WayToHealth Security Officer, or an authorized delegate of the Security Officer.
Nessus is used to monitor all internal IP addresses (servers, VMs, etc) on WayToHealth networks.
The Security Officer initiates the review of a Nessus Report by creating an Ticket in the WayToHealth TQMS.
The Security Officer, or designated personnel, is assigned to review the Nessus Report.
If new vulnerabilities are found during review, the process outlined below is used to test those vulnerabilities. Once those steps are completed, the Ticket is then reviewed again.
Once the review is completed, the Security Officer approves or rejects the Ticket. If the Ticket is rejected, it goes back for further review.
If the review is approved, the Security Officer then marks the Ticket as Done, adding any pertinent notes required.
Vulnerabilities that are repeatable manually are documented and reviewed by the Security Officer and Privacy Officer to see if they are part of the current risk assessment performed by WayToHealth.
Those that are not part of the current risk assessment trigger a new risk assessment, and this process is outlined in detail in the WayToHealth Risk Assessment Policy.
All vulnerability scanning reports are retained for 6 years by WayToHealth. Vulnerability report review is monitored on a quarterly basis using the TQMS reporting to assess compliance with above policy.
Penetration testing is performed regularly as part of the WayToHealth vulnerability management policy.
External penetration testing is performed annually by a third party.
Internal penetration testing is performed bi-annually. Below is the process used to conduct internal penetration tests.
The Security Officer initiates the penetration test by creating an Ticket in the WayToHealth TQMS.
The Security Officer, or a WayToHealth Security Engineer assigned by the Security Officer, is assigned to conduct the penetration test.
Gaps and vulnerabilities identified during penetration testing are reviewed, with plans for correction and/or mitigation, by the WayToHealth Security Officer before the Ticket can move to be approved.
Once the testing is completed, the Security Officer approves or rejects the Ticket. If the Ticket is rejected, it goes back for further testing and review.
If the Ticket is approved, the Security Officer then marks the Ticket as Done, adding any pertinent notes required.
Penetration tests results are retained for 6 years by WayToHealth.
Internal penetration testing is monitored on an annual basis using the TQMS reporting to assess compliance with above policy.
This vulnerability policy is reviewed on an annual basis by the Security Officer and Privacy Officer.
WayToHealth takes data integrity very seriously. As stewards and partners of WayToHealth Customers, we strive to assure data is protected from unauthorized access and that it is available when needed. The following policies drive many of our procedures and technical settings in support of the WayToHealth mission of data protection.
All access to Production Systems must be logged. This is done following the WayToHealth Auditing Policy.
All Production Systems are to only be used for WayToHealth functional needs.
Production systems are monitored using IPS systems. Suspicious activity is logged and alerts are generated.
Vulnerability scanning of Production Systems occurs continually. Currently, four (4) times a day. Scans are reviewed by Security Officer or designated personnel, with defined steps for risk mitigation at least quarterly, and retained for future reference.
System, network, and server security is managed and maintained by the Security Officer or designated personnel, in conjunction with the Engineering team.
Access to Production Systems is controlled using centralized tools and two-factor authentication, where possible.
Ensure WayToHealth Customer Production Data is segmented and only accessible to Customers authorized to access data.
All Production Data at rest is stored on encrypted volumes using encryption keys managed by WayToHealth. Encryption at rest is ensured through the use of automated deployment scripts referenced in the Configuration Management Policy.
All data transmission is encrypted end to end using encryption keys managed by WayToHealth. Encryption is not terminated at the network end point, and is carried through to the application.
In the case of WayToHealth provided APIs, provide mechanisms to assure person sending or receiving data is authorized to send and save data.
Despite not being a requirement within HIPAA, WayToHealth understands and appreciates the importance of health data retention. Acting as a subcontractor, and at times a business associate, WayToHealth is not directly responsible for health and medical records retention as set forth by each state. Despite this, WayToHealth has created and implemented the following policy to make it easier for WayToHealth Customers to support data retention laws.
Current WayToHealth Customers have data stored by WayToHealth as a part of the WayToHealth Service.
If no response to notice in #1 above within 7 days, or if Customer responds they do not want to reinstate account, Customer is sent directions for how to download their data from WayToHealth within 90 days.
If Customer downloads data or does not respond to notices from WayToHealth within 30 days, WayToHealth will remove identifiable data from WayToHealth systems and Customer is sent notice of removal of data.
WayToHealth is committed to ensuring all workforce members actively address security and compliance in their roles at WayToHealth. As such, training is imperative to assuring an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non-compliance.
Current WayToHealth training is offered via UPHS or the University Of Pennsylvania employee training services.
The UPHS or the University Of Pennsylvania Employee policies clearly states the responsibilities and acceptable behavior regarding information system usage, including rules for email, Internet, mobile devices, and social media usage.
The Human Resources department will emphasize secure and confidential information handling policies when introducing new individuals to Penn Medicine / School of Medicine. A copy of the Information Security policies will be made available to all new workforce members.
Workforce members will acknowledge in writing that they understand their responsibilities as stated in the policies.
WayToHealth does not allow mobile devices to connect to any of its production networks.
All new workforce members are given HIPAA training within 30 days of beginning employment. Training includes HIPAA reporting requirements, including the ability to anonymously report security incidents, and the levels of compliance and obligations for WayToHealth and its Customers and Partners.
Employees may only use UPHS or the University of Pennsylvania-purchased and -owned workstations for accessing production systems with access to ePHI data.
WayToHealth may monitor access and activities of all users on workstations and production systems in order to meet auditing policy requirements (§8).
Access to internal WayToHealth systems can be requested using the procedures outlined in §7.2. All requests for access must be granted by the WayToHealth Security Officer or designated personnel.
Request for modifications of access for any WayToHealth employee can be made using the procedures outlined in §7.2.
WayToHealth employees are strictly forbidden from downloading any ePHI to their workstations.
WayToHealth workforce members are to escalate issues as described in HIPAA training.
Security incidents, particularly those involving ePHI, are handled using the process described in §11.2. If the incident involves a breach of ePHI, the Security Officer will manage the incident using the process described in §12.2. Refer to §11.2 for a list of sample items that can trigger WayToHealth’s incident response procedures; if you are unsure whether the issue is a security incident, contact the Security Officer immediately.
Create an Ticket in the WayToHealth TQMS.
The Ticket is investigated, documented, and, when a conclusion or remediation is reached, it is moved to Review.
The Ticket is reviewed by designated personnel. If the Ticket is rejected, it goes back for further evaluation and review.
If the Ticket is approved, it is marked as Done, adding any pertinent notes required.
WayToHealth utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by UPHS or the University Of Pennsylvania, or they are hosted by a Subcontractor with appropriate business associate agreements in place to preserve data integrity. Use of other tools requires approval from WayToHealth leadership.
GitLab. GitLab is an open source tool built on top of Git, the version control platform. GitLab is hosted and secured by the University Of Pennsylvania. It is utilized for storage of configuration scripts and other infrastructure automation tools, as well as for source and version control of application code used by WayToHealth.
Box. Box is used for storage of files and sharing of files with Partners and Customers.
Google Apps. Google Apps is occasionally used for document collaboration.
JIRA. JIRA is used for configuration management and to generate artifacts for compliance procedures and is the basis for the Ticketing and Quality Management System (TQMS).
WayToHealth makes every effort to assure all 3rd party organizations are compliant and do not compromise the integrity, security, and privacy of WayToHealth or WayToHealth Customer data. 3rd Parties include Customers, Partners, Subcontractors, and Contracted Developers.
WayToHealth does not allow 3rd party access to production systems containing ePHI.
All connections and data in transit between the WayToHealth Platform and 3rd parties are encrypted end to end.
WayToHealth has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management.
Subcontractors must coordinate, manage, and communicate any changes to services provided to WayToHealth.
Changes to 3rd party services are classified as configuration management changes and thus are subject to the policies and procedures described in §9; substantial changes to services provided by 3rd parties will invoke a Risk Assessment as described in §4.2.
WayToHealth utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs.
No WayToHealth Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties.
WayToHealth does not outsource software development.
WayToHealth maintains and annually reviews a list all current Partners and Subcontractors.
The list of current Partners and Subcontractors is maintained by the WayToHealth Privacy Officer, includes details on all provided services (along with contact information), and is recorded in §1.1.
WayToHealth assesses security, compliance, and SLA requirements and considerations with all Partners and Subcontractors. This includes annual assessment of SOC2 reports for all WayToHealth infrastructure partners.
The Security Officer or designated personnel initiates the SLA review by creating an Ticket in the WayToHealth TQMS.
The Security Officer, Privacy Officer, or designated personnel, is assigned to review the SLA and performance of 3rd parties. The list of current 3rd parties, including contact information, is also reviewed to assure it is up to date and complete.
SLA, security, and compliance performance is documented in the Ticket.
Once the review is completed and documented, the Security Officer or designated personnel approves or rejects the Ticket. If the Ticket is rejected, it goes back for further review and documentation.
For all partners, WayToHealth reviews activity annually to assure partners are in line with SLAs in contracts with WayToHealth.
SLA review is monitored on a annual basis using the TQMS reporting to assess compliance with above policy.
The 3rd Party Assurance process is reviewed annually and updated to include any necessary changes.
Changes to the 3rd Party Assurance process will also be made on an ad-hoc basis in cases where operational changes require it or if the process is found lacking.
Application: An application hosted by WayToHealth, either maintained and created by WayToHealth, or maintained and created by a Customer or Partner.
Application Level: Controls and security associated with an Application. In the case of Customers using the WayToHealth Application, WayToHealth will assure compliance with security standards and policies at the Application Level. In the case of Customers accessing their own custom Applications, WayToHealth does not have access to and cannot assure compliance with security standards and policies at the Application Level.
Disaster Recovery Service: A disaster recovery service for disaster recovery in the case of system unavailability. This includes both the technical and the non-technical (process) required to effectively stand up an application after an outage. Offered with all WayToHealth Add-ons and as an option for PaaS Customers.
Customers: Contractually bound users of WayToHealth Platform.
Health and Human Services (HHS): The government body that ensures adherence to HIPAA under the Office of Civil Rights (OCR).
IDS Service: An Intrusion Detection Service for providing IDS notification to customers in the case of suspicious activity.
Logging Service: A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them.
Off-Site: For the purpose of storage of Backup media, off-site is defined as any location separate from the physical location or building in which the backup was created. It must be physically separate from the creating site.
Organization: For the purposes of this policy, the term “organization” shall mean WayToHealth under the auspices of the University of Pennsylvania and Penn Medicine (The University of Pennsylvania Health System).
Partner: Contractual bound 3rd party vendor with integration with the WayToHealth Platform. May offer Add-on services.
Platform: The overall technical environment of WayToHealth.
Environmental - external fires, HVAC failure/temperature inadequacy, water pipe burst, power failure/fluctuation, etc.
Human - hackers, data entry, workforce/ex-workforce members, impersonation, insertion of malicious code, theft, viruses, SPAM, vandalism, etc.
Natural - fires, floods, electrical storms, tornados, etc.
Technological - server failure, software failure, ancillary equipment failure, etc. and environmental threats, such as power outages, hazardous material spills.
Other - explosions, medical emergencies, misuse or resources, etc.
Vendors: Persons from other organizations marketing or selling products or services, or providing services to WayToHealth.
Below is a list of HIPAA Safeguards and Requirements and the WayToHealth controls in place to meet those.
This set of policies and procedures are based on Penn Medicine’s policies and on the open source compliance policies provided by Datica Inc. which are available here. These policies are also are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

References: §2
 §7
 §7
 §7
 §7
 §7
 §17
 §17
 §7
 §9
 §1
 §164
 §13
 §7
 §7
 §11
 §12
 §11
 §9
 §4
 §1