Skip to main content

Applications and Data Criticality Analysis

Purpose​

To enable the continuation of critical business processes, to protect and secure ePHI during emergency mode operations.

Policy​

Assess the relative criticality of specific applications and data in support of other contingency plan components. The criticality analysis will serve as the basis for the recovery prioritization of ePHI and ePHI Systems during the disaster recovery plan.

Definitions​

  1. Electronic Protected Health Information (ePHI): individually identifiable health information that is transmitted by electronic media, maintained in electronic media, or transmitted or maintained in any other form or medium.
  2. Disaster (Information System): An event that makes the continuation of normal information system functions impossible; an event which would render the information system unusable or inaccessible for a prolonged period of time (may be departmental or organization-wide).
  3. Disaster Recovery Coordinator (DRC): Individual assigned the authority and responsibility for the implementation and coordination of IS disaster recovery operations.
  4. Disaster Recovery Plan: The document that defines the resources, actions, tasks, and data required to manage the business recovery process in the event of a business interruption. The plan is designed to assist in restoring the business process within the stated disaster recovery goals.
  5. Security Incident: A violation or imminent threat of violation of information security policies, acceptable use policies, or standard security practices; an adverse event whereby some aspect of computer security could be threatened. An IS Disaster would be considered a security incident.

Procedure​

  1. Activities and Materials that are critical to daily business operations include:
    1. Network services (i.e. firewalls, switches, fiber optic lines, wireless)
    2. Servers (i.e. authentication server, EMR server, PM server)
    3. Software (EMR, PM)
    4. Equipment (computers, printers)
    5. Automated processes that support critical services or operations
    6. Network services (i.e. firewalls, switches, T1 lines, wireless)
    7. Servers (i.e. authentication server, EMR server, PM server)
    8. Software (EMR, PM)
    9. Equipment (computers, printers)
  2. Security and Privacy officers, as well as the DRC (Criticality Team) will meet with key department representatives and ask them about the applications and data they use. Also, meet with members of IT staff to find out what computer systems support those applications and data—those are the systems you must bring up first if a disaster or emergency occurs.
  3. The criterion for identifying critical components is whether rendering a component unusable or unavailable would significantly disrupt iEHR ongoing operation.
    1. To determine criticality, the Criticality Team will assess the options for replacing the affected components. The analysis must identify components that must be quickly replaced or restored to operating condition during an emergency. It must also identify the longest potential period of time that those critical components can be unavailable and the most cost-effective method for restoring function within the critical time period.
  4. Power outages disrupting network services, servers, and EMR application can only be tolerated for 24 hours. Practice Management disruption can only be tolerated for 72 hours.
  5. If servers are destroyed, a new server would be purchased and put in the most secure and reliable location. Data would be restored as described in the Data Backup Plan and Contingency Plan policies (example).

Violations​

Any individual, found to have violated this policy, may be subject to disciplinary action up to and including termination of employment.