• Introduction
• Overview of our Approach
• HIPAA Background
• Iguana and HIPAA
• Things outside Iguana’s control
• Iguana HIPAA Best Practices
• Instructions
• More Information

Introduction

The HIPAA standard is all about protecting patient data.

We often get asked: Is Iguana HIPAA compliant? Yes it is if you follow a few simple security best practices. This article explains how to set up Iguana to ensure that all the processing performed by Iguana is HIPAA compliant.

If you only want to set up HIPAA compliance asap — then jump straight to the Instructions section. You can always come back and read more later…

For a high level view of our approach read the next section Overview of our Approach. If you want more in depth information about how Iguana works with HIPAA, then read the other sections that interest you.

Overview of our Approach [top]

So what is HIPAA about? In essence it is all about protecting patient data.

So how does this relate to Iguana? In simple terms we need to protect patient data while it is being processed by Iguana.

So how do we protect the data Iguana is processing? There are the main areas we address:

• Access to Data files:

  Access to all local disk files used by Iguana should be strictly controlled. This can be done using files and folder permissions set up in the operating system. Basically only Iguana users, system administrators and the Iguana service (or daemon) user should need to have access to these files.

• User Access:

  Each user must have their own Iguana login and use a secure password. User permissions are controlled through Iguana’s users and groups.

• Data Encryption:

  All local disk files used by Iguana should be encrypted. File encryption needs to be set up in the operating system.

• Audit Controls:

  Iguana automatically logs user sessions, user IP addresses, channel changes, starting/stopping channels, importing channels and modifying interfaces. Iguana also records when a message has been altered and resubmitted, and who made the change. Iguana does not log when somebody views a particular message — instead we use role-based permissions to restrict access to messages.

• Log Encryption:

  Log files should be encrypted we recommend using Iguana’s built in Log Encryption features — though you can use other methods like operating system disk encryption.

We actually address all of the requirements specified in the HIPAA Technical Safeguards, the next two sections go into this in more depth.

HIPAA Background [top]

As we said earlier HIPAA is all about protecting patient data. Unfortunately the full HIPAA regulations are very complex, even though they are well documented. The official regulations can be found on the U.S. Department of Health & Human Services website. There is some excellent educational material, as well as the complete HIPAA regulations.

The HIPAA regulations are composed of two parts the Privacy Rule and the Security Rule. The Privacy Rule defines the standards for protecting patient data. The Security Rule defines the standards for protecting electronic patient data — basically how to apply the Privacy Rule standards to electronic data. In this article we are primarily interested in how the Privacy Rule applies to Iguana.

The HIPAA for Professionals page on the HHS website has a wealth of useful information. The Security Guidance page has links to various useful PDF documents like Security 101 for Covered Entities, and Technical Safeguards — both of which are very helpful. The security matrix at the end of Security 101 for Covered Entities is very useful.

It is probably also worth knowing about the  Combined Regulation Text (it contains all the HIPAA regulations as of March 2013). Having all regulations in one PDF file is easier than digging around in the various different HIPAA Acts, unfortunately it is still 115 pages of obscure legalese and is only useful as a reference.

The Privacy Rule is broken down into three parts: Administrative Safeguards, Physical Safeguards, and Technical Safeguards. This article will address how to implement the Technical Safeguards shown in the matrix below (from Security 101 for covered Entitiies).

We will also address another important requirement Access to Data files (controlled by file permissions). This is discussed in the Technical Safeguards document, but for some reason has been omitted from the matrix.

Administrative and Physical safeguards while obviously important are beyond the scope of this article.

Iguana and HIPAA [top]

The HIPAA requirements are very broad and not everything applies to Iguana. We need to identify the HIPAA requirements that directly affect Iguana and focus most of our attention on those.

The first step is to identify what part of our interface is under the control of Iguana. Then we can identify which part of the HIPAA standards will apply. There are basically only two things that Iguana has control over when it is processing data over user access and access to local resources like disks and databases.

So first we will restrict our attention to the Security Rule because it deals with electronic data. The Security Rule is further broken down into three parts: Administrative Safeguards, Physical Safeguards and Technical Safeguards. All three are important but only Technical Safeguards apply directly to Iguana. Administrative and Physical safeguards while obviously important are beyond the scope of this article.

This article we will focus on setting up Iguana to comply with the Technical Safeguards from the Security Rule. We will use matrix at the end of the Security 101 for Covered Entities article as a list of safeguards to implement. We will also address one other important requirement Access to Data files (file permissions), which is discussed in Technical Safeguards but is (surprisingly) omitted from the matrix.

The HIPAA standards specify two types of items Required (R) and Addressable (A). Anything that is Required must be implemented, where Addressable items are optional and only need to be implemented if there is deemed to be a security risk. We will cover all the Technical Safeguards, but with a greater emphasis on the Required items.

The matrix (from Security 101 for Covered Entities) shows the Technical Safeguards that we will address:

Things outside Iguana’s control [top]

Some parts of the interface are outside of Iguana’s control, this article will only address one HIPAA requirement for these areas: Transmission Security (the last item in the matrix).

Basically the areas outside of Iguana’s control relate to receiving/sending data from/to other systems. For example data could be sent in an unencrypted format, which may fail HIPAA compliance.
Note: That encryption of transmitted data is an “addressable” requirement — so it will only fail HIPAA compliance if it is deemed to be a risk.

There are various secure protocols that can be used to mitigate the risk of unencrypted data. In particular VPN and SSH tunneling are good as they do not require software changes, just some administration. Also if you are up/downloading from an FTP it is fairly simple to change to FTPS or SFTP. Changing from an unsecured web service (http) to a secured one (https) should also be easy enough.

Iguana also supports LLP using TLS (Transport Layer Security) or SSL (Secure Socket Layer). However you will probably not use this very often as it is not supported by many systems (but a VPN or SSH tunnel will probably work instead).

If you have any questions please contact us at support@interfaceware.com.

Iguana HIPAA Best Practices [top]

This section discusses how we recommend addressing the issues raised in the Technical Safeguards section of the HIPAA Security Rule.

Note: Each item is prefixed with (Iguana) if it is implemented within Iguana, (External) if it is implemented external to Iguana or (Iguana + External) for a combination.

1. Access to Data files: See 164.308(a)(4)(i)
This is the only one of the requirements that is not included in the Technical Safeguards matrix for the HIPAA Security Rule.

164.308(a)(4)(i) Standard: Information access management. Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.
164.308(e) Maintenance. Security measures implemented to comply with standards and implementation specifications adopted under § 164.105 and this subpart must be reviewed and modified as needed to continue provision of reasonable and appropriate protection of electronic protected health information as described at § 164.316.
Note: This quote from page 4 of the educational paper Technical Safeguards – PDF is also relevant (but appears to be an advisory comment — as it is not part of the HIPAA regulations)
“Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in§ 164.308(a)(4)[Information Access Management].”

• Required: Restrict File Permissions
  (External) All disk files used by Iguana should have should have minimum access granted to allow your users to do their work. Permissions will need to be granted at the operating system level. You will need to address this with your system administration staff. This applies to all disk files used by Iguana that contain patient data, for example:
  • The Iguana Windows Service user (or Daemon user in Linux etc.), will need access to all files used by Iguana:
    • Full access is required for the Iguana install directory.
    • Access to data files etc used by channels should be restricted to the minimum required.
  • Access to the Iguana log files should be restricted to the Iguana Windows Service user (or Daemon user in Linux etc.)
  • The system user that runs your backup software will need read access to the log files
  • Iguana users should only be granted read access to files needed to do their jobs
  • An administrative user with full access should be available for “emergency” use only by the Iguana system administrator
    Note: We strongly recommend not giving full access to a personal user logon to prevent accidental file changes or deletions.

2. Access Control: See 164.312(a)(1)

(a)(1) Standard: Access control. Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).

• Required: Unique User Identification
  (Iguana) Each person that uses Iguana will be issued with their own individual Iguana User, that they use to login to Iguana. These Iguana Users are used track user actions for Audit purposes and therefore should not be shared. Standards should be implemented to ensure that secure passwords are used.
• Required: Emergency Access Procedure
  (External) You must have procedures in place to get Iguana up and running on a Secondary server if the Primary server becomes unavailable for any reason. The recovery process will vary depending on the requirements of your Iguana installation, for example: A system that processes batch updates could be down for several hours without causing a problem, but a mission critical transactional system will need to be back up as fast a possible. The approach to this is two-pronged: All systems should implement backup and restore procedures, mission critical systems should also implement an Iguana failover server for high availability. Iguana is very flexible and can be configured to fit into any kind of “high availability” (HA) approach, please contact us at support@interfaceware.com so we can help you to implement a custom HA solution.
• Addressable: Automatic Logoff
  (Iguana) The Session Timeout entry in the Web Server settings governs how long a user can be inactive before being logged out. A suitable delay for a production system is probably around 5-10 minutes. The exact delay will vary depending on your the security requirements of your Iguana installation.
• Addressable: Encryption and Decryption
  (External) All disk files used by iguana should be encrypted at the operating system level. You will need to address this with your local system administration staff. This applies to all disk files used by Iguana that contain patient data, for example:
  • The Iguana log files should always be encrypted
  • Local Database files used by any of your channels
  • Local message files, perhaps downloaded from FTP or a web service etc.
  • Any other local files containing patient data

3. Audit Controls:

There are two sections that are particularly relevant: 164.312(1)(b) which states that system data must be logged and audited, and 164.308(a)(1)(ii)(d) which states that audit logs must be regularly reviewed.

See 164.312(1)(b)

(b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

• Required: Audit Controls
  (Iguana) Iguana includes a built-in Logging System that contains all the necessary information for auditing. Iguana automatically logs user sessions, user IP addresses, channel changes, starting/stopping channels, importing channels and modifying interfaces. Iguana also records when a message has been altered and resubmitted, and who made the change. Iguana does not log when somebody views a particular message — instead we use role-based permissions to restrict access to messages.We recommend regularly reviewing Iguana logs for unauthorized or suspicious access to data — things like overuse of administrator, unknown users, or just unusual access patterns. Ideally you can implement some form of automated reviewing software (which is much more effective), but this is not actually required for compliance.
  Note: We recommend encrypting the log files — this is covered earlier in Access to Data files.

See 164.308(a)(1)(ii)(d)

(b) Standard: Information system activity review.Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

• Required:Information system activity review
  (Iguana) We recommend regularly reviewing Iguana logs for unauthorized or suspicious access to data — things like overuse of administrator, unknown users, or just unusual access patterns. Ideally you can implement some form of automated reviewing software (which is much more effective), but this is not actually required for compliance.
  Note: This section implies that auditing ePHI access alone is not sufficient for compliance.

4. Integrity: See 164.312(c)(1)

(c)(1) Standard: Integrity. Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.

• Addressable: Mechanism to Authenticate Electronic Protected Health Information
  (Iguana + External) This requirement is very general and open to varying interpretation. Data can be damaged by machine failure or by human failure (error or malice). We will focus on technical solutions that will help reduce corruption or detect changes to data. Here is a list of various things that you can address, what you choose to do will depend on your own risk assessment.
  • Issues you can address directly with Iguana
    • Use Iguana’s builtin AES encryption functions for securing data
    • Use SSL with Iguana’s builtin net functions
    • Write code that uses checksums to verify data
  • Other issues
    • VPN and SSH tunneling — see Transmission Security (below)
    • Protection against viruses and malware
    • Prevention and detection of hacking
    • Network security
      • Preventing unauthorized devices from accessing the network
      • Ensuring authorized devices are safe — no viruses, malware etc.

5. Person or Entity Authentication: See 164.312(d)

(d) Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

• Required: Person or Entity Authentication
  (Iguana) Each person using Iguana will be issued with their own individual Iguana User, see Access Control > Unique User Identification (above).
  Note: Authentication can be further enhanced by using things like key cards or biometrics for physical access and/or logging onto computers

6. Transmission Security: See 164.312(e)(1)

(e)(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.

• Addressable: Integrity Controls
  (Iguana) This requirement overlaps with the Integrity section (above), and is also general and open to varying interpretation. For our purposes we regard it as steps that prevent (undetected) changes to transmitted data. Here is a list of relevant items — all of which were covered previously (as indicated):
  • From: Integrity > Mechanism to Authenticate Electronic Protected Health Information
    • Write code that uses checksums to verify data
    • Use Iguana’s builtin AES encryption functions for securing data
    • Use SSL with Iguana’s builtin net functions
  • From: Audit Controls
    • Regularly review Iguana logs for unauthorized or suspicious access to data — things like overuse of administrator, unknown users, or just unusual access patterns.
• Addressable: Encryption
  (Iguana + External) There are numerous ways to encrypt transmitted data. All methods will require some degree of cooperation between yourself and the party you are communicating with. See Secure Protocols for a discussion of the available options. Some solutions require only administration changes, others will require code changes. For example:
  • Administrative solutions
    • VPN tunneling
    • SSH tunneling
    • Using SFTP or FTPS instead of FTP
  • HL7 using LLP with TLS or SSL
    LLP with the TLS (Transport Layer Security) or SSL (Secure Socket Layer) cryptographic protocol is a standard supported by the IHE. Iguana has native support built into the LLP channels. We recommend using this if the application you are communicating with supports it — in practice this method is not used much as it is not well supported.
  • Coding Solutions — previously addressed in Integrity > Mechanism to Authenticate Electronic Protected Health Information
    • Use Iguana’s builtin AES encryption functions for securing data
    • Use SSL with Iguana’s builtin net functions

Instructions [top]

This section lists the steps needed to meet the Technical Safeguards section of the HIPAA Security Rule.

Note: Each item is prefixed with (Iguana) if it is implemented within Iguana, (External) if it is implemented external to Iguana or (Iguana + External) for a combination.

1. Access to Data files: See 164.308(a)(4)(i).

   All data files should have should have only the minimum access granted to allow your users to do their jobs. This includes all files containing patient data and files used by Iguana. File permissions are controlled by the operating system,  contact your system administration staff.

   1. Required: Restrict File Permissions:
      (External)
      1. The Iguana Windows Service user (or Daemon user in Linux etc.), will need access to all files used by Iguana:
         • Full access is required for the Iguana install directory.
         • Access to data files etc used by channels should be restricted to the minimum required.
      2. Access to the Iguana log access should be restricted to the Iguana Windows Service user (or Daemon user in Linux etc.).
      3. The system user that runs your backup software will need read access to the log files.
      4. Iguana users should only be granted read access to files needed to do their jobs.
      5. Identify all files containing patient data and ensure that access is restricted as much as possible.
      6. An administrative user with full access should be available for “emergency” use only by the Iguana system administrator.
         Note: We strongly recommend not giving full access to a personal user logon to prevent accidental file changes or deletions.
2. Access Control: See 164.312(a)(1).
   1. Required: Unique User Identification:
      (Iguana)
      1. Issue each person that uses Iguana with their own individual Iguana User.
      2. Implement standards to ensure that secure passwords are used.
   2.  Required: Emergency Access Procedure:
      (External)
      1. Implement backup and restore procedures.
      2. Mission critical systems should also implement an Iguana failover server for high availability (HA).
         Please contact us at support@interfaceware.com if you need to implement an HA solution.
   3.  Addressable: Automatic Logoff:
      (Iguana)
      1. Set the Session Timeout entry in the Web Server settings  to specify how long a user can be inactive before being logged out.
         Note: We suggest around 5-10 minutes, the exact delay will vary depend on your own security requirements.

   4. Addressable: Encryption and Decryption:
      (External)

      All disk files used by iguana should be encrypted at the operating system level. This includes all files containing patient data and files used by Iguana. Encryption is implemented at the operating system level,  contact your system administration staff.

      1. The Iguana log files should always be encrypted.
      2. Local Database files used by any of your channels.
      3. Local message files, perhaps downloaded from FTP or a web service etc.
      4. Any other local files containing patient data.
3. Required: Audit Controls: See 164.312(1)(b) and 164.308(a)(1)(ii)(d):
   (Iguana)

   Iguana includes a built-in Logging System that contains all the necessary information for auditing.

   1. (No action) Logging is included within Iguana.
   2. We recommend regularly reviewing Iguana logs for unauthorized or suspicious access to data — things like overuse of administrator, unknown users, or unusual access patterns.
4.  Integrity: See 164.312(c)(1).

   This requirement is very general and open to varying interpretation. Data can be damaged by machine failure or by human failure (error or malice). We will focus on technical solutions that will help reduce corruption or detect changes to data. Which issues you you choose to address will depend on your own risk assessment

   1. Addressable: Mechanism to Authenticate Electronic Protected Health Information:

      (Iguana + External)

      1. Issues you can address directly with Iguana:
         • Use Iguana’s builtin AES encryption functions for securing data
         • Use SSL with Iguana’s builtin net functions
         • Write code that uses checksums to verify data
      2. Other issues:
         • Protection against viruses and malware
         • Prevention and detection of hacking
         • Network security
           • Preventing unauthorized devices from accessing the network
           • Ensuring authorized devices are safe — no viruses, malware etc.
5. Required: Person or Entity Authentication: See 164.312(d):
   (Iguana)

   Each person using Iguana will be issued with their own individual Iguana User, this is already covered by step 2 Access Control. Authentication can be further enhanced by using things like key cards or biometrics for physical access and/or logging onto computers

   1. (No action) Issuing Iguana Users is already covered by step 2.
   2. Use fingerprint readers (or other biometrics) for logging onto computers, if it is available.
6. Transmission Security: See 164.312(e)(1).
   1. Addressable: Integrity Controls:
      (Iguana)

      This requirement overlaps with the Integrity section (above), and is also general and open to varying interpretation. For our purposes we regard it as steps that prevent (undetected) changes to transmitted data. This area is already covered by actions taken in steps 3 and 4 — see Transmission Security in the previous section Iguana HIPAA Best Practices for more information.

      1. (No action) This area is already covered by actions taken in steps 3 and 4.
   2. Addressable: Encryption:
      (Iguana + External)

      There are numerous ways to encrypt transmitted data. All methods will require some degree of cooperation between yourself and the party you are communicating with. See Secure Protocols for a discussion of the available options. Some solutions require only administration changes, others may require code changes.

      1. Administrative solutions:
         • VPN tunneling
         • SSH tunneling
         • Using SFTP or FTPS instead of FTP
      2. You can use LLP with TLS or SSL for HL7 messages (if it is supported by the applications you are communicating with):
         1. For incoming HL7 messages select “Use SSL” in the LLP Listener component and enter the SSL Certificate, Private key and Certificate file details.
         2. For incoming HL7 messages select “Use SSL” in the LLP Client component and enter the SSL Certificate, Private key and Certificate file details.
      3. Coding Solutions:

         Previously addressed in step 4 Integrity: Use Iguana’s builtin AES encryption functions for securing data, and Use SSL with Iguana’s builtin net functions.

         1. (No action) This already covered in step 4.

More information [top]

• hhs.gov HIPAA pages
  • HIPAA for Professionals
  • The Security Rule
  • Security Rule Guidance Material
  • Security 101 for Covered Entities – PDF
  • Technical Safeguards – PDF