igia

igia

  • Documentation
  • Stay Informed
  • Community

›igia

igia

  • Platform Overview
  • Getting Started
  • Architecture
  • How To Create An App
  • FAQ
  • Contributing
  • Licensing
  • Healthcare Disclaimer
  • HIPAA Support
  • Component List
  • Releases

    • Release-0.3.1
    • Release-0.3.2
    • Release-0.3.3
  • Known Issues
  • Acknowledgements

Sample App

  • Sample App API
  • Sample App UI

Microservice Platform

  • Microservice Gateway
  • Key Cloak (OAuth)

    • README
    • Usage
    • Introduction
  • Orchestrator

SMART on FHIR

  • Overview
  • FHIR API Example
  • FHIR API HAPI Config

    • README
    • Usage
    • Introduction

    SMART Launch App

    • README
    • Usage

Care Management

  • Overview
  • Care Management
  • Camunda Workflow Engine

Data Integration

  • Overview
  • Data Integration App
  • Data Integration Config
  • Data Integration Worker

Tools

  • igia Common Libs
  • Docs Website
  • Data Masking

I2b2 & CDI

  • Overview
  • CDI Usage

HIPAA Support

DISCLAIMER: The platform does not guarantee HIPAA compliance. It is up to each developer to create and deploy applications that adhere to any applicable regulatory requirements like HIPAA. Below are some suggested steps for configuring with HIPAA in mind. These suggestions are not intended to be complete nor represented to be up to date. Users should refer to the latest standards provided by the U.S. Department of Health & Human Services.

Developers should have adequate test plans to confirm that all features required for HIPAA compliance, e.g., auditing/logging, function correctly within their specific deployment environment.

Platform and HIPAA

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a US federal law that governs many aspects of health insurance portability and health data exchange. One component of the law, the Administrative Simplification portion (under Title II) is broken down into several rules, including the Privacy Rule and the Security Rule, which describe how we limit Protected Health Information (PHI) from a privacy and security perspective.

The HHS.gov page for Professionals has the standards for the HIPAA Privacy and Security Rules that need to be followed by covered entities and business associates. The Privacy Rule protects all "individually identifiable health information" held or transmitted by a covered entity or its business associate, in any form or media, whether electronic, paper, or oral. The Security Rule requires covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting electronic PHI (ePHI). These restrictions do not apply to de-identified health information.

Any covered entity deploying the platform is expected to follow the additional required administrative and technical standards defined in 45 C.F.R Part 164 not covered here (e.g., § 164.308(a)(1)(ii)(B) Risk Management, § 164.308(a)(1)(ii)(C) Sanction Policy, etc.). For completeness, please see the Part 164 Standards Matrix (external download) outlining required and addressable standards.

Risk Analysis (§ 164.308(a)(1)(ii)(A))

The Risk Analysis implementation specification requires covered entities to "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity."

In order to fulfill the Risk Analysis HIPAA requirement, the projects must undergo code scanning at defined intervals minimally before each release. While not a HIPAA requirement, we recommend penetration testing be performed against applications built using .

Technical Safeguards (§ 164.312)

The Security Rule defines technical safeguards in § 164.304 as "the technology and the policy and procedures for its use that protect electronic protected health information and control access to it."

ACCESS CONTROLS (§ 164.312(a)(1))

The Security Rule defines access in § 164.304 as "the ability or the means necessary to read, write, modify, or communicate data/information or otherwise use any system resource. (This definition applies to "access" as used in this subpart, not as used in subpart E of this part [the HIPAA Privacy Rule])." Access controls provide users with rights and/or privileges to access and perform functions using information systems, applications, programs, or files. Access controls should enable authorized users to access the minimum necessary information needed to perform job functions.

The Minimum Necessary Requirement is meant to limit unnecessary or inappropriate access to and disclosure of protected health information. The principle of least privilege needs to be applied to both the application and the PHI stored by the platform. The platform provides a feature for creating different roles associated with access privileges that can be assigned to users.

UNIQUE USER IDENTIFICATION (Required) - (§ 164.312(a)(2)(i))

The Unique User Identification implementation specification states that a covered entity must: "Assign a unique name and/or number for identifying and tracking user identity."

The application microgateway can integrate with a covered entity's authentication mechanisms (e.g., LDAP, Active Directory, SAML, etc.) to support unique user identification. Associated with unique user identification is user activity monitoring. Any activity related to ePHI by a user needs to be written to an audit log.

Access control to microservices can be configured using the microgateway.

EMERGENCY ACCESS PROCEDURE (Required) - (§ 164.312(a)(2)(ii))

This implementation specification requires a covered entity to: "Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency."

A covered entity needs to define emergency procedures covering applications built using including limiting access just to administrative users. The microgateway has the ability to allow for administrator access via a local user configured with an administrator role. We recommend users of implement further safegaurds in the event of infrastructure outages.

AUTOMATIC LOGOFF (Addressable) - (§ 164.312(a)(2)(iii))

Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity."

Any application user interface built using should have an automatic logoff procedure that complies with a covered entity's requirements.

ENCRYPTION AND DECRYPTION (Addressable) - (§ 164.312(a)(2)(iv))

Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement a mechanism to encrypt and decrypt electronic protected health information."

PHI data at rest needs to be encrypted and retained following the covered entity's data retention requirements. There is no HIPAA data retention requirement, but each covered entity and business associate needs to minimally follow their jurisdiction's data retention requirements.

does not provide a specific feature for encrypting data at rest, but application developers should configure data storage to support this requirement.

AUDIT CONTROLS (§ 164.312(b))

The Audit Controls standard requires a covered entity to: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

Applications, including those implemented using , must maintain audit logs for any activities related to ePHI. The microgateway provides a feature which can be configured for tracking PHI access via microgateway requests, storing the audit trail in a database.

For access to patient data stored in internal databases:

Existing audit standards include the IHE-ATNA Audit record definitions, originally from RFC 3881, and now managed by DICOM (see DICOM Part 15 Annex A5).

Additional info can be found in HL7's Security and Audit Tutorial.

ASTM E2147 – Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems. This is deprecated but contains a good summary of data considered standard for audit events.

  1. Audit Log Content
    7.1 Audit log content is determined by regulatory initiatives, accreditation standards, and principles and organizational needs. Information is needed to adequately understand and oversee access to patient identifiable data in health information systems in order to perform security oversight tasks responsibly.
    Logs must contain the following minimum data elements:
    7.2 Date and Time of Event
    7.3 Patient Identification
    7.4 User Identification
    7.5 Access Device (optional)
    7.6 Type of Action (additions, deletions, changes, queries, print, copy)
    7.7 Identification of the Patient Data that is Accessed(optional)
    7.8 Source of Access (optional unless the log is combined from multiple systems or can be indisputably inferred)
    7.9 Reason for Access (optional)
    7.10 If capability exists, there should be recognition that both an electronic "copy" operation and a paper "print" operation are qualitatively different from other actions.

See http://build.fhir.org/auditevent.html for a data model.

INTEGRITY (§ 164.312(c)(1))

The Integrity standard requires a covered entity to: "Implement policies and procedures to protect electronic protected health information from improper alteration or destruction."

MECHANISM TO AUTHENTICATE ELECTRONIC PROTECTED HEALTH INFORMATION (Addressable) - (§ 164.312(c)(2))

Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner."

PERSON OR ENTITY AUTHENTICATION (§ 164.312(d))

This standard requires a covered entity to: "Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed."

TRANSMISSION SECURITY (§ 164.312(e)(1))

This standard requires a covered entity to: "Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network."

Any application built using should encrypt data in transit containing ePHI and PII using secure encryption mechanisms.

INTEGRITY CONTROLS (Addressable) - (§ 164.312(e)(2)(i))

Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of."

ENCRYPTION (Addressable) - (§ 164.312(e)(2)(ii))

Where this implementation specification is a reasonable and appropriate safeguard for a covered entity, the covered entity must: "Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate."

External References

  • A look at HIPAA technical safeguard requirements
  • Guidance on Risk Analysis
  • NIST Cyber Security Framework to HIPAA Security Rule Crosswalk - PDF
  • Clarifying the HIPAA Retention Requirements
Last updated on 7/29/2019
← Healthcare DisclaimerComponent List →
  • Risk Analysis (§ 164.308(a)(1)(ii)(A))
  • Technical Safeguards (§ 164.312)
    • ACCESS CONTROLS (§ 164.312(a)(1))
    • UNIQUE USER IDENTIFICATION (Required) - (§ 164.312(a)(2)(i))
    • EMERGENCY ACCESS PROCEDURE (Required) - (§ 164.312(a)(2)(ii))
    • AUTOMATIC LOGOFF (Addressable) - (§ 164.312(a)(2)(iii))
    • ENCRYPTION AND DECRYPTION (Addressable) - (§ 164.312(a)(2)(iv))
    • AUDIT CONTROLS (§ 164.312(b))
    • INTEGRITY (§ 164.312(c)(1))
    • MECHANISM TO AUTHENTICATE ELECTRONIC PROTECTED HEALTH INFORMATION (Addressable) - (§ 164.312(c)(2))
    • PERSON OR ENTITY AUTHENTICATION (§ 164.312(d))
    • TRANSMISSION SECURITY (§ 164.312(e)(1))
    • INTEGRITY CONTROLS (Addressable) - (§ 164.312(e)(2)(i))
    • ENCRYPTION (Addressable) - (§ 164.312(e)(2)(ii))
igia    igia
Enabling the development, deployment, and sharing of healthcare technology.

Logo Design By GillFishmanDesign.com Cambridge, Massachusetts

Copyright © 2020
"igia" is a trademark of the igia.io project.
Documentation
Getting StartedLicenseDisclaimerFAQ
Community
Discussion ForumPlatform Users
Contact us at
More
GitHubStar