Understanding Health Insurance Portability and Accountability Act (HIPAA)

What is HIPAA?

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was designed to establish standards and requirements for electronic transmission and storage of certain healthcare information used by healthcare providers, health plans and business entities involved in healthcare.

What are the main objectives of HIPAA ?
  • To allow patients to carry insurance coverage to different plans if they change employment (portability).
  • To establish uniform standards for electronically stored and transmitted healthcare data.
  • To improve efficiency of sharing health information among entities involved in healthcare.
What is the motivation behind HIPAA ?

The first part of HIPAA provides portability of healthcare coverage (moving coverage from one health plan to another).

Portability increases costs with paper-based records. Moving large amounts of information on paper is time-consuming and expensive.

Portability costs can be reduced by using electronic means to exchange healthcare information.

Healthcare information exchanged electronically requires protection. HIPAA rules delineate standards for security and privacy of individually identifiable health information.

Electronic exchange of healthcare information will require standardized transactions among healthcare providers, health plans and other groups that use healthcare information as part of their business.  HIPAA rules delineate standards for electronic transactions.

HIPAA provides a balance between access and privacy.  Unlimited access to information precludes confidentiality while complete privacy hinders access to information.

What rules are defined in HIPAA ?

There are three main rules that outline HIPAA’s implementation requirements.
  1. The Privacy Rule focuses on when and to whom confidential patient information can be disclosed (compliance date: April 14, 2003).
  2. The Transaction Rule addresses technical aspects of the electronic health care transaction process and requires the use of standardized formats whenever health care transactions, such as claims, are sent or received electronically (compliance date: October 16, 2003).
  3. The Security Rule seeks to assure the security of confidential electronic patient information. For psychologists, this usually means addressing administrative, physical and technical procedures such as access to offices, files and computers, as well as the processes a psychologist uses to keep electronic health information secure (compliance date: April 20, 2005)
What is HIPAA Security Rule ?

While the Privacy Rule outlined to whom and under what circumstances a psychologist can disclose
patient information, the Security Rule outlines the steps a psychologist must take to protect
confidential information from unintended disclosure through breaches of security. This includes
any reasonably anticipated threats or hazards, such as a computer virus, and/or any inappropriate uses
and disclosures of electronic confidential information (for example, confidential patient information
e-mailed to the wrong person due to human or technical error). The Security Rule creates standards
that health care professionals must meet to keep electronic health care information confidential and

Like the Privacy Rule, the Security Rule applies when a psychologist transmits information in electronic form in connection with a standard transaction (see Triggers on the next page).
The Security Rule sets administrative, technical and physical standards to prevent breaches of
confidentiality. One distinction to note is that whereas the Privacy Rule applies to all Protected Health
Information (PHI) the Security Rule applies only to electronically transmitted or stored protected
health information (EPHI).

What electronic transactions are covered under the Security Rule ?

The following standard electronic transactions are specified by the Security Rule and trigger the
need to be HIPAA-compliant.
  • Health care claims
  • Health care payment and remittance advice
  • Coordination of benefits
  • Health care claim status, enrollment or disenrollment in a health plan
  • Eligibility for a health plan
  • Health plan premium payments
  • Referral certification and authorization
  • First report of injury
  • Health claims attachments
What is required by the Security Rule ?

The Security Rule requires that steps be taken to ensure.
  • The confidentiality of electronically transmitted or stored protected health information (EPHI).
  • The integrity of EPHI (meaning the information is not changed or altered in storage or transmission)
  • The availability of EPHI (making sure the information is accessible to the appropriate people when needed)
How's the Security Rule organized ?

The Standards are organized into three categories.
  • Administrative Standards : address the implementation of office policies and procedures, staff training, and other measures designed to carry out security requirements.
  • Physical Standards : relate to limiting access to the physical area in which electronic information systems are housed.
  • Technical Standards : concern authentication, transmission and other issues that may arise when authorized personnel access EPHI via computer or other electronic device.
What it takes to be compliant with HIPAA Security Rule ?

Compliance with the HIPAA Security Rule requires that a psychologist undertake a process by which he  or she analyzes and documents each step that has been taken to become compliant. That means that for all Security Rule Standards and Implementation Specifications, psychologists must develop and maintain a policies and procedures document in written or electronic form, that explains how he or she has complied with each step of implementation.

This document must be retained for six (6) years from either the date it was created or the date it last went into effect, whichever is later, and the document must be made available to those persons responsible for implementing the procedures. These Policies and Procedures must be promptly updated to comply with any changes in the law or any changes in how you plan to comply with the Standards.

Who needs to HIPAA compliant ?
  • A healthcare provider that conducts certain transactions in electronic form
  • A healthcare clearing house (payment and reimbursement systems)
  • A health plan (insurance)  
HIPAA Security Rules

Administrative Safeguards
164.308(a)(3)(i) Workforce Security: Implement policies and procedures to ensure that all members of its workforce have appropriate access to electronic protected health information, as provided under paragraph (a)(4) of this section, and to prevent those workforce members who do not have access under paragraph (a)(4) of this section from obtaining access to electronic protected health information.
164.308(a)(3)(ii)(A) Authorization and/or Supervision (A): Implement procedures for the authorization and/or supervision of workforce members who work with electronic protected health information or in locations where it might be accessed.
164.308(a)(3)(ii)(B) Workforce Clearance Procedure (A): Implement procedures to determine that the access of a workforce member to electronic protected health information is appropriate.
164.308(a)(3)(ii)(C) Termination Procedure (A): Implement procedures for terminating access to electronic protected health information when the employment of a workforce member ends or as required by determinations made as specified in paragraph (a)(3)(ii)(B) of this section.
164.308(a)(4)(i) Information Access Management: Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements. 
164.308(a)(4)(ii)(A) Isolating Health Care Clearinghouse Functions (R): If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.
164.308(a)(4)(ii)(B) Access Authorization (A): Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.
164.308(a)(4)(ii)(C) Access Establishment and Modification (A): Implement policies and procedures that, based upon the entity's access authorization policies, establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process. 
164.308(a)(5)(i) Security Awareness and Training (R): Implement a security awareness and training program for all members of its workforce (including management). 
164.308(a)(5)(ii)(A) Security Reminders (A): Periodic security updates.
164.308(a)(5)(ii)(B) Protection from Malicious Software (A): Procedures for guarding against, detecting, and reporting malicious software.
164.308(a)(5)(ii)(C) Log-in Monitoring (A): Procedures for monitoring log-in attempts and reporting discrepancies
164.308(a)(5)(ii)(D) Password Management (A): Procedures for creating, changing, and safeguarding passwords. 
164.308(a)(6)(i) Security Incident Procedures (R): Implement policies and procedures to address security incidents
164.308(a)(6)(ii) Response and Reporting (R): Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes. 
164.308(a)(7)(i) Contingency Plan (R): Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.
164.308(a)(7)(ii)(A) Data Backup Plan (R): Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.
164.308(a)(7)(ii)(B) Disaster Recovery Plan (R): Establish (and implement as needed) procedures to restore any loss of data.
164.308(a)(7)(ii)(C) Emergency Mode Operation Plan (R): Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.
164.308(a)(7)(ii)(D) Testing and Revision Procedure (A): Implement procedures for periodic testing and revision of contingency plans.
164.308(a)(7)(ii)(E) Applications and Data Criticality Analysis (A): Assess the relative criticality of specific applications and data in support of other contingency plan components.
Physical Safeguards
164.310(c) Workstation Security (R): Implement physical safeguards for all workstations that access electronic protected health information to restrict access to authorized users
Technical Safeguards
164.312(a)(1) Access Control (R): 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). 
164.312(a)(2)(i) Unique User Identification (R): Assign a unique name and/or number for identifying and tracking user identity.
164.312(a)(2)(ii) Emergency Access Procedure (R): Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
164.312(a)(2)(iii) Automatic Logoff (A): Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. 
164.312(a)(2)(iv) Encryption and Decryption (A): Implement a mechanism to encrypt and decrypt electronic protected health information. 
164.312(b) Audit Controls (R): Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronically protected health information. 
164.312(c)(1) Integrity (R): Implement policies and procedures to protect electronic protected health information from improper alteration or destruction. 
164.312(c)(2) Mechanism to Authenticate Electronic Protected Health Information (A): Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. 
164.312(d) Person or Entity Authentication (R): Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. 
164.312(e)(1) Transmission Security (R): Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. 
164.312(e)(2)(i) Integrity Controls (A): Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. 
164.312(e)(2)(ii) Encryption (A): Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. 


1. http://www.apapracticecentral.org/business/hipaa/security-rule.pdf
2. http://www.healthisnumberone.com/hipaa.pdf
3. http://www.ama-assn.org/resources/doc/psa/hipaa-tcs.pdf
4. http://health.usf.edu/NR/rdonlyres/2D58EB73-E08A-4EDE-B3BF-2EF77A4AD70C/0/USFHIPAASecurityRuleStandards.pdf

Why OAuth it self is not an authentication framework ?

Let's straight a way start with definitions to avoid any confusions.

Authentication is the act of confirming the truth of an attribute of a datum or entity. If I say, I am Prabath - I need to prove that. I can prove that with something I know, something I have or with something I am. Once I proved my self who I claim I am, then the system can trust me. Sometimes systems do not just want to identify me by just by name. By name could help to identify me uniquely - but how about other attributes of me. Before you get through the border control - you need to identify your self - by name - by picture - and also by finger prints and eye retina. Those are validated real-time against the data from the VISA office which issued the VISA for you. That check will make sure its the same person who claimed to have the VISA enters in to the country. That is proving your identity. Proving your identity is authentication.

Authorization is about what you can do. Your capabilities. You could prove your identity at the border control by name - by picture - and also by finger prints and eye retina - but it's your VISA that decides what you can do. To enter in to the country you need to have a valid VISA that has not expired. A valid VISA is not a part of your identity - but a part of what you can do. Also what you can do inside the country depends on the VISA type. What you do with a B1 or B2 differs from what you can do with an L1 or L2. That is authorization.

OAuth 2.0 is about authorization. Not about authentication.

OAuth 2.0 is about what you can do ( or on behalf of another user) - not about who you are. So - you cannot use OAuth 2.0 it self for authentication.

I hear what you say. We use OAuth 2.0 based Facebook login to log in to plenty of different web applications. So am I lying ?

Let's pick Facebook it self for an example. I got following image from Facebook login developer documentation. It highlights the OAuth flow with authorization code grant type.

User goes to a Web Application. Clicks on the Login button. Gets redirected to the Facebook for authentication and pass the "code" to the client Web Application. Now the Web Application exchanges the code to an access token. Facebook will only issue an access token for a valid code. And - it also will only issue a code after the user been authenticated. So, the Web Application having access to a valid access token means - and it only means - that particular user is from Facebook. That's it. It's like carrying out a valid, stamped VISA to the boarder control with out having any identification information about the user on it. Looking at the access token - the application cannot say who the user is - it can only say where the user comes from. So it does not help the Web Application to identify the end user uniquely. When the same user logs in next time he could bring a different access token - so the Web Application cannot use the access token as a way of identification. That is why OAuth it self is not an authentication framework.

Still you think I am lying? Of course you do.

When you login via Facebook - your application also gets certain claims about you. Like your first name, last name and email address - and also your Facebook Id. How does this happen if OAuth does not bring any identity attributes ?

Once the Web Application gets the access token from the Facebook, to get user attributes - the Web Application can call following API with the access token it got.


This will get the identity information of the user who authorized the access token.

Now - this helps to identify the user - or to authenticate the user. But, keep in mind that the last step is out side the scope of OAuth and that functionality is provided via Facebook's Graph API.

Not just through Facebook's Graph API - even through SCIM we can identify the user. But with the current specification there seems to be a limitation in doing that in a standard manner.

With the current specification to get the details of a specific user we use the following.

 GET /Users/2819c223-7f76-453a-919d-413861904646
 Host: example.com
 Accept: application/json Authorization: Bearer h480djs93hd8

But, just after the OAuth flow - we only have the access token at the client side. No concrete information about the end user. So we cannot use the above.

By having a pre-defined userid say "me" [just like in Facebook Graph API] - cab be made to provide back the logged in user's info.

 GET /Users/me
 Host: example.com
 Accept: application/json
 Authorization: Bearer h480djs93hd8

In the above case - the information about the user corresponding to the provided Bearer token will be returned back. So, based on that, client can identify the end user with it's attributes.

Apart from the above two approaches - OpenID Connect is the best one built on top of OAuth 2.0 to identify the end user.

With OpenID Connect in addition to the OAuth access token - the client or the Web Application also gets an ID token. The ID Token is a security token that contains claims/identity information about the authentication event and other requested claims from the client. The ID Token is represented as a JWT - and it can be used to prove the identity of the end user.