CMT Movie HIPAA DICOM Home       Site Map       French      
  IHE      
About CMT Products Images Quality Customer Support News & Events Careers Contact Us

HIPAA Compliance  
     DICOM / IHE / HIPAA » HIPAA Compliance

 

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) has several objectives, among which is to “Protect the health information of individuals against access without consent or authorization”.
The HIPAA law affects “systems that transmit health information in electronic form in connection with standard transactions”.
The United States government realized that by mandating patient records be sent over digital networks there would be fear that patient privacy could be compromised. To address this fear the Department of Health and Human Services developed a standard set of security and privacy regulations to which the SmartRAD & SmartSPOT PrimaX systems must adhere.

CMT products (SmartRAD & SmartSPOT PrimaX) are supporting compliance with the requirements of the HIPAA law, by providing the System Administrator of the Radiology department, the tools to define a list of authorized users and their specific access/operation rights.

By properly configuring the HIPAA related parameters, the System Administrator can implement the internal regulations in compliance with HIPAA requirements.

HIPAA requirements "at-a-glance"
  • Privacy and Security Concepts of HIPAA
    Data privacy deals with controlling who is authorized to access Protected Health Information (PHI). The privacy regulation defines very specific rights that patients have. In order to maintain these rights, security measures must be implemented such as the ability to control access to data, protect it from accidental or intentional disclosure to unauthorized persons, and guard it against unauthorized alteration, destruction, or loss.
    To increase the security provided for electronically handled data, different measures are required which can be split into Confidentiality & Integrity categories.
    • Confidentiality
      The most fundamental function of security is to guarantee that information is disclosed to authorized individuals only. Measures must be implemented so to grant access only after the person requesting the information has been properly identified and authenticated.
      The access rights of each individual must be restricted to only the information they need to access in order to perform their job, without interfering with proper care of patients.
      Confidentiality can be implemented in various ways such as authentication procedures.
    • Integrity
      The HIPAA law states that a system that handle electronic information have to ensure that unauthorized modification to the information cannot be made without being noticed. Any time information is used or electronically communicated there needs to be a high level of confidence that the information is accurate. As a result, authorized modifications to final records must be tracked.
      Users and systems need to be careful about where they send patient information and from where it comes. The issue is to manage data exchanges so they occur only between authorized entities whose identification has been authenticated and who are authorized (e.g. by using DICOM Verification). This authentication process ensures that rogue data cannot come into a system and masquerade as authentic data.

  • Security Measures Required by HIPAA
    The security requirements outlined in the legislation lead to complex implementations of technical measures that must be implemented in systems, to protect patient data stored, processed, or exchanged between them.
    The following security measures belong to this category.
    • Authentication
      All systems that store, process or protect patient data need to implement access controls in order to manage where this information is allowed to flow and who is allowed to create, view or change it.
      Authentication follows identification of a user and may be accomplished by a secret password. If the authentication attempt fails then access has to be blocked. In the event of a healthcare emergency, the “Emergency” account is provided to allow access in the event of an authentication failure. All attempts to gain access to a system must be logged for later investigation.
      To prevent misuse by other users, if a system is left idle for a period of time, then access to it has to be blocked. The idle time is a variable set by the user in accordance with their own security policies. When the idle time threshold is crossed the display must be cleared of any patient identifiable data and a new authentication required.
    • Authorization
      After the authentication process has identified the person accessing the system and authenticated the claimed identity, an authorization mechanism needs to determine what data the user is allowed to access and what functions may be performed. The mechanism can be based on a role a person fulfills in the organization, e.g., Administrator (“super-user”), Field Engineer, doctor and operating technician.
      Authorization is an important security function that protects sensitive information from individuals who have no job-related need to access it.
      Authorization has to be implemented at the lowest level possible to ensure that all access to patient information is correctly managed. Along with other required security services, such as identification, authentication, and individual accountability, it must be non-bypassable to ensure that all access attempts are controlled and that no one, e.g., system managers, can circumvent it. However, in the case of a crisis, a procedure for emergency override access has to be provided (“Urgent Patient”).
    • Accountability
      All requests for and access granted to stored information must be logged for review and possible investigation. Logging should include such items as a date/time stamp, the identification of the user, the type of access rights, the success or failure of the request, and identification of the data acted upon.
      The accountability function must be protected by the system access control mechanism. In this way the system can manage need-to-know and need-to-do of users attempting to access the audit record (log files), and to prevent changes and deletions. It needs to have the same robustness and non-bypassability as other security mechanisms.
    • Secure Transfer
      It is assumed that transferring of patient data for storage using DICOM Store service is a transfer which can be trusted from the modality (SmartRAD & SmartSPOT PrimaX) point of view, as indicated in the DICOM standard (PS 3.15-2001, par. 1):
      “This Standard assumes that the Application Entities involved in a DICOM interchange are implementing appropriate security policies...
      When Application Entities agree to interchange information via DICOM through association negotiation, they are essentially agreeing to some level of trust in the other Application Entities. Primarily Application Entities trust that their communication partners will maintain the confidentiality and integrity of data under their control.”