Do you develop software that has even the remote possibility of being used by a HIPAA (Health Insurance Portability and Accountability Act)[1] covered entity? If so, what should you know about the HIPAA security rule when developing software? Most of the security rule standards are increasingly becoming “good programming” and may already be incorporated in the systems development cycle of software vendors. However, there are some HIPAA security concepts that need to be emphasized to software developers, should their software be used by businesses that are considered “covered entities” under HIPAA security regulations.
PHI -Related Software Development
HIPAA defines protected health information (PHI)[2] as “any information, whether oral or recorded in any form or medium” that
- “[i]s created or received by a health care provider, health plan, public health authority, employer, life insurer, school or university, or health care clearinghouse”; and
- “[r]elates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; or the past, present, or future payment for the provision of health care to an individual.”
In short PHI is information that is identifiable to a certain person that includes health information. PHI data is the target of protection, as covered by the security rule. The security rule for PHI only applies if the PHI data is electronically transmitted or received by a covered entity. If the data is covered by HIPAA security rule then the law requires the customer (covered entity) to: “Implement technical policies and procedures for electronic information systems that maintain electronic PHI to allow access only to those persons or software programs that have been granted access rights as specified”. Thus the covered entity is mandated to protect the PHI while allowing only authorized access, as needed.
Covered entities have been advised by the HIPAA regulators to work with their software vendors in producing software that will help their security rule compliance efforts. Therefore, when performing the requirements analysis phase of systems design, you may be prompted by customers, who are covered entities, to provide an explanation of how your system design features map to various HIPAA security rule standards. In other cases, software applications will have to be redesigned or modified to fit specific security compliancy objectives of individual covered entities. In many cases, HIPAA security rule technical standards compliance will be gained by small adjustments to existing security posture of the covered entity. In such cases, the ability to integrate into existing security architectures will be a key to effecting compliance.
If you are developing PHI related software applications one person on the client side who will probably have input into the design requirements is the Information Security Officer (ISO). Covered entities are mandated by HIPAA to designate someone as the ISO, the person responsible for implementing HIPAA security rules. The ISO can be someone with a security background or can literally be anyone designated as such, regardless of experience. ISO responsibilities include setting up user accounts, controlling authorization and access controls, and emergency access contingency plans. These will be major discussion points in developing requirements for software systems that must be comply with the HIPAA security rule.
Reasonably Anticipated Threat Protection
It is impossible to build a system that is completely secure. The stated objective of the security rule is to establish standards to ” protect against reasonably anticipated threats or hazards and improper use or disclosure.” Viruses, malicious code, password cracking, social engineering, and other threats that are common to most business networks must be considered in designing PHI-related software systems. The HIPAA security rule provides criminal and civil liability in cases where covered entities experience security breaches due to not implementing whatever required standard as proscribed by the security rule. Healthcare-informed software developers will understand that this reason, along with the anticipated savings opportunity, will be a major reason for the covered entities to seek compliance. Keep in mind that the security rule sets the minimum standard of securing data. Good security practice generally provides for much more protection than is simply covered by the security rule. Likely, HIPAA security rule compliance, in some cases, will be a subset of an already existing organizational security policy and architecture.
Software developers should be aware of the goals of the HIPAA security and privacy rules, that of providing confidentiality, integrity, and availability of protected health information. PHI data must be accessible to authorized entities and persons, kept private from unauthorized viewing and must be protected from unauthorized modification or deletion.
Also, note that are 18 technical security standards and 36 implementation specifications that developers should be aware of.[3] Security Rule implementation specifications contain more detailed instructions on either required implementation steps or optional choices in implementing a HIPAA security standards. When working with PHI related customer applications be aware that some implementation specifications are required and some are addressable. Addressable means that implementation of an implementation specification is an option. Covered entities are given flexibility in implementation depending on such factors as the security risk involved, size of the organization, cost of the procedures to comply, technical infrastructure, and capabilities.
What does this mean to software developers? It is because of this flexibility, covered entities in the same line of business may have different implementations of the same standard. The important point is that during the early phase of software design think in terms of risks associated with the application, reasonably anticipated threats to the security of the application, and flexibility of implementation specifications based on unique requirements of covered entities.
- Health and Human Service Center for Medicare and Medicaid Services
- Definitions of PHI
Or see page 8374 of Federal Register Vol. 68 No. 34, of Part 160. - Rule Standards and Implementation Specification
About the Author
Keith Pasley, CISSP is an information security professional with over 20 years of experience in the information technology industry. He has designed security architectures and implemented security strategies for both government and commercial sectors. Pasley has written articles on various security related subjects.
