Healthcare Information Technology

President Trump Nominates Alex Azar for HHS Secretary

Posted by HIPAA Journal

Former Deputy Secretary of the Department of Health and Human Services, Alex Azar, is tipped to take over from former Secretary Tom Price after receiving the presidential nomination for the role. Azar previously served as general counsel to the HHS and Deputy Secretary during the George W. Bush administration.

President Trump confirmed on Twitter that he believes Azar is the man for the job, tweeting “Happy to announce, I am nominating Alex Azar to be the next HHS Secretary. He will be a star for better healthcare and lower drug prices!”

The position of Secretary of the Department of Health and Human Services was vacated by former Secretary Tom Price in September, following revelations about his controversial use of military aircraft and expensive charter flights to travel around the country.

While there were several potential candidates tipped to receive the nomination, including commissioner of the Food and Drug Administration, Scott Gottlieb, and administrator of the Centers for Medicare and Medicaid Services, Seema Verma, President Trump has made a controversial choice.

Alex Azar is a trained lawyer, but has spent the past ten years working in the pharmaceutical industry – an industry regulated by the HHS. In 2007, Azar joined pharmaceutical giant Eli Lilly taking on the role of senior vice president of corporate affairs and communications before becoming the head of the U.S. division of the firm until January 2017, when he left to start up his own consulting firm.

The nomination of Azar has raised many eyebrows. While President Trump has tweeted that he sees Azar as the man to help lower drug prices, Eli Lilly has attracted considerable criticism in the past for hikes in drug prices, notably for price rises to Insulin, one of the firm’s major pharmaceutical products. President Trump has previously claimed the pharmaceutical industry is ‘getting away with murder’ setting prices for their products.

Democrats have already expressed skepticism about how Azar would be able to help lower healthcare costs, not sharing Trump’s optimistic view that Azar can help drive prices down.

Azar has also been a harsh critic of the Affordable Car Act, sharing President’s Trump’s view that the ACA should be repealed. Despite repeated attempts, the failure to repeal ACA will mean that if appointed, Azar will be responsible for overseeing enforcement of the ACA.

Before Azar can take the helm of the Department of Health and Human Services, he must first be approved by Congress. Azar’s record while serving in the pharmaceutical industry is certain to be scrutinized, as will his commitment to enforcing the Affordable Care Act that he has previously strongly opposed.

The post President Trump Nominates Alex Azar for HHS Secretary appeared first on HIPAA Journal.

In What Year Was HIPAA Passed into Legislature?

Posted by HIPAA Journal

The Health Insurance Portability and Accountability Act or HIPAA was passed into legislature on August 21, 1996, when Bill Clinton added his signature to the bill.

Initially, the purpose of HIPAA was to improve portability and continuity of health insurance coverage, especially for employees that were between jobs. HIPAA also standardized amounts that could be saved in pre-tax medical savings accounts, prohibited tax-deduction of interest on life insurance loans, enforced group health plan requirements, simplified the administration of healthcare with standard codes and practices, and introduced measures to prevent healthcare fraud.

Many of the details of the five titles of HIPAA took some time to be developed, and several years passed before HIPAA Rules became enforceable. The HIPAA Enforcement Rule, which allows the Department of Health and Human Services’ Office for Civil Rights to impose financial penalties for noncompliance with HIPAA Rules, was not passed until February 16, 2006 – A decade after HIPAA was first introduced.

There have been several important dates in the past two decades since HIPAA was originally passed – Notably the introduction of the HIPAA Privacy Rule, HIPAA Security Rule, HIPAA Breach Notification Rule, and the HIPAA Omnibus Rule.

The HIPAA Privacy Rule introduced many provisions to better protect the privacy of patients. The Security Rule was primarily concerned with the security of electronic protected health information. The Breach Notification Rule ensures that all breaches of protected health information are reported, while the Omnibus Rule introduced a broad range of changes, including new requirements required by the Health Information Technology for Economic and Clinical Health (HITECH) Act.

Four key updates to HIPAA legislation are detailed below.

The Privacy Rule of HIPAA Passed into Legislature

The Privacy Rule of HIPAA was passed into legislature on December 28, 2000. The official name of the update to HIPAA is the “Standards for Privacy of Individual Identifiable Health Information.” The HIPAA Privacy Rule compliance date was April 14, 2003.

The HIPAA Privacy Rule details the allowable uses and disclosures of protected health information without first obtaining consent from patients. The HIPAA Privacy Rule also gives patients the right to obtain copies of their health data from HIPAA-covered entities.

The Security Rule of HIPAA Passed into Legislature

The Security Rule of HIPAA was passed into legislature on April 21, 2003, although the effective date was not until April 21, 2005. While the HIPAA Privacy Rule was concerned with all forms of protected health information, the HIPAA Security Rule is primarily concerned with the creation, use, storage and transmission of electronic PHI. The HIPAA Security Rule requires administrative, physical, and technical safeguards to be introduced to keep PHI secure. The Security Rule also introduced requirements for when PHI is no longer required.

The Breach Notification Rule of HIPAA Passed into Legislature

The HIPAA Breach Notification Rule came from the Health Information Technology for Economic and Clinical Health (HITECH) Act, which was passed on February 17, 2009. The HIPAA Breach Notification Rule took effect from August 24, 2009.

The Breach Notification Rule requires HIPAA-covered entities to submit notifications of breaches of protected health information to the Secretary of the Department of Health and Human Services within 60 days of the discovery of a breach if the breach involved 500 or more records. Smaller breaches must still be reported, no later than 60 days after the end of the year in which the breach was discovered. The Breach Notification Rule also requires notifications of a breach to be sent to affected patients within 60 days of the discovery of the breach.

The Omnibus Rule of HIPAA Passed into Legislature?

The HIPAA Omnibus Final Rule was issued on January 17, 2013. The HIPAA Omnibus Rule introduced several changes to the HIPAA Privacy, Security, and Breach Notification Rules.

One of the most important changes affected HIPAA business associates – individuals or entities that are contracted to HIPAA-covered entities to provide services that require access to PHI.

Since the passing of the HIPAA Omnibus Rule, business associates of HIPAA-covered entities, and their subcontractors, must implement safeguards to protect ePHI as required by the HIPAA Security Rule. Since the introduction of the Omnibus Rule, business associates of HIPAA-covered entities can be fined directly for HIPAA violations.

Another important update was clarification of “significant harm.” Prior to the introduction of the Omnibus Rule, many covered entities failed to report breaches as there was determined to have been no significant harm caused to patients as a result of the breach. After the Omnibus Rule, covered entities must be able to prove there was no significant harm if they decide not to report a breach.

Infographic Summary of Milestones in the History of HIPAA

In addition to the above major changes to HIPAA legislation, there have been numerous milestones in the history of HIPAA, which have been summarized in the infographic below. The infographic details legislation changes, clarifications of HIPAA Rules, major enforcement actions, and HIPAA audits – Click the image below to view the graphic in full size.

HIPAA History

The post In What Year Was HIPAA Passed into Legislature? appeared first on HIPAA Journal.

FDA Publishes Final Guidance for Medical Device Manufacturers Sharing Information with Patients

Posted by HIPAA Journal

The U.S. Food and Drug Administration (FDA) has released final guidance for medical device manufacturers sharing information with patients at their request.

Legally marketed medical devices collect, store, process, and transmit medical information. When patients request copies of the information recorded by or stored on the devices, manufacturers may share patient-specific information with the patient that makes the request.

The FDA encourages information sharing as it can help patients be more engaged with their healthcare providers. When patients give their healthcare providers data collected by medical devices, it can help them make sound medical decisions.

While information sharing is not a requirement of the Federal Food, Drug, and Cosmetic Act (FD&C Act), the FDA felt it necessary to provide medical device manufacturers with recommendations about sharing patient-specific information with patients. The guidelines are intended to help manufacturers share information appropriately and responsibly.

The FDA explains that in many cases, patient-specific information recorded by medical devices is shared with the patient’s healthcare providers, and oftentimes the patient is able to obtain copies of that information from their healthcare providers. However, sometimes patients may submit a request to the device manufacturer for a copy of the patient-specific information recorded by the device.

The FDA explains that patient-specific information is information that is unique to a particular patient – or unique to the patient’s diagnosis and treatment – that has been recorded, stored, processed, or derived from a legally marketed medical device. “This information may include, but is not limited to, recorded patient data, device usage/output statistics, healthcare provider inputs, incidence of alarms, and/or records of device malfunctions or failures.”

The FDA notes that patient-specific information does not include labelling, which is covered by the FD&C Act. Labelling covers information such as descriptions of intended use, benefit and risk information, and instructions for use and the sharing of such information is subject to applicable requirements of the FD&C Act.

The FDA encourages device manufacturers to share information with patients when copies are requested, even though data sharing is not a requirement FD&C Act. The FDA also explains that data can be shared with patients at the patient’s request, without the need to undergo an additional premarket review in advance.

Some medical devices record, store, and transmit information in a format that makes it difficult to share the information with patients, or in some cases, information is recorded in a closed system that cannot be accessed by the device manufacturer. The FDA is aware that in such cases it may not be feasible to share data with patients.

When information sharing is possible, device manufacturers should respond to requests promptly and information should be “comprehensive and contemporary.” Data should include all information that is available, up until the point that the request is made.

The FDA points out that its guidance does not establish any legally enforceable responsibilities, and neither does it affect any federal, state or local laws. That includes HIPAA, and specifically the HIPAA Privacy Rule, which will apply if the device manufacturer is a business associate of a HIPAA-covered entity.

The post FDA Publishes Final Guidance for Medical Device Manufacturers Sharing Information with Patients appeared first on HIPAA Journal.

Tips for Reducing Mobile Device Security Risks

Posted by HIPAA Journal

An essential part of HIPAA compliance is reducing mobile device security risks to a reasonable and acceptable level.

As healthcare organizations turn to mobiles devices such as laptop computers, mobile phones, and tablets to improve efficiency and productivity, many are introducing risks that could all too easily result in a data breach and the exposure of protected health information (PHI).

As the breach reports submitted to the HHS’ Office for Civil Rights show, mobile devices are commonly involved in data breaches. Between January 2015 and the end of October 2017, 71 breaches have been reported to OCR that have involved mobile devices such as laptops, smartphones, tablets, and portable storage devices. Those breaches have resulted in the exposure of 1,303,760 patients and plan member records.

17 of those breaches have resulted in the exposure of more than 10,000 records, with the largest breach exposing 697,800 records. The majority of those breaches could have easily been avoided.
The Health Insurance Portability and Accountability Act (HIPAA) Security Rule does not demand encryption for mobile devices, yet such a security measure could have prevented a high percentage of the 71 data breaches reported to OCR.

When a mobile device containing ePHI is lost or stolen, the HIPAA Breach Notification Rule requires the breach to be reported and notifications to be sent to affected individuals. If PHI has been encrypted and a device containing ePHI is lost or stolen, notifications need not be sent as it would not be a HIPAA data breach. A breach report and patient notifications are only required for breaches of unencrypted PHI, unless the key to decrypt data is also obtained.

Even though HIPAA does not demand the use of encryption, it must be considered. If the decision is taken not to encrypt data, the decision must be documented and an alternative safeguard – or safeguards – must be employed to ensure the confidentiality, integrity, and availability of ePHI. That alternative safeguard(s) must provide a level of protection equivalent to encryption.

Before the decision about whether or not to encrypt data can be made, HIPAA covered entities must conduct an organization-wide risk analysis, which must include all mobile devices. All risks associated with the use of mobile devices must be assessed and mitigated – see 45 C.F.R. § 164.308(a)(1)(ii)(A)–(B).

OCR Reminds Covered Entities of Need to Address Risks Associated with Mobile Devices

In its October 2017 Cybersecurity Newsletter, OCR reminded covered entities of the risks associated with mobile devices that are used to create, receive, maintain, or transmit ePHI. HIPAA covered entities were reminded of the need to conduct an organization-wide risk assessment and develop a risk management plan to address all mobile device security risks identified during the risk analysis and reduce them to an appropriate and acceptable level.

While many covered entities allow the use of mobile devices, some prohibit the use of those devices to create, receive, maintain, or transmit ePHI. OCR reminds covered entities that if such a policy exists, it must be communicated to all staff and the policy must be enforced.

When mobile devices can be used to create, receive, maintain, or transmit ePHI, appropriate safeguards must be implemented to reduce risks to an appropriate and acceptable level. While loss or theft of mobile devices is an obvious risk, OCR draws attention to other risks associated with the devices, such as using them to access or send ePHI over unsecured Wi-Fi networks, viewing ePHI stored in the cloud, or accessing or sharing ePHI via file sharing services.

OCR also remined covered entities to ensure default settings on the devices are changed and how healthcare employees must be informed of mobile device security risks, taught best practices, and the correct way to uses the device to access, store, and transmit ePHI.

OCR offers the following advice to covered entities address mobile security risks and keep ePHI secure at all times.

To access OCR’s guidance – Click here.

OCR’s Tips for Reducing Mobile Device Security Risks

  • Implement policies and procedures regarding the use of mobile devices in the work place – especially when used to create, receive, maintain, or transmit ePHI.
  • Consider using Mobile Device Management (MDM) software to manage and secure mobile devices.
  • Install or enable automatic lock/logoff functionality.
  • Require authentication to use or unlock mobile devices.
  • Regularly install security patches and updates.
  • Install or enable encryption, anti-virus/anti-malware software, and remote wipe capabilities.
  • Use a privacy screen to prevent people close by from reading information on your screen.
  • Use only secure Wi-Fi connections.
  • Use a secure Virtual Private Network (VPN).
  • Reduce risks posed by third-party apps by prohibiting the downloading of third-party apps, using whitelisting to allow installation of only approved apps, securely separating ePHI from apps, and verifying that apps only have the minimum necessary permissions required.
  • Securely delete all PHI stored on a mobile device before discarding or reusing the mobile device.
  • Include training on how to securely use mobile devices in workforce training programs.

Penalties for Failing to Address Mobile Security Risks

The failure to address mobile device security risks could result in a data breach and a penalty for noncompliance with HIPAA Rules. Over the past few years there have been several settlements reached between OCR and HIPAA covered entities for the failure to address mobile device security risks.

These include:

Covered Entity HIPAA Violation Individuals Impacted Penalty
Children’s Medical Center of Dallas Theft of unencrypted devices 6,262 $3.2 million
Oregon Health & Science University Loss of unencrypted laptop / Storage on cloud server without BAA 4,361 $2,700,000
Cardionet Theft of an unencrypted laptop computer 1,391 $2.5 million
Catholic Health Care Services of the Archdiocese of Philadelphia Theft of mobile device 412 $650,000

Addressing Mobile Device Security Risks

Mobile device security risks must be reduced to a reasonable and appropriate level.  Some of the mobile device security risks, together with mitigations, have been summarized in the infographic below. (Click image to enlarge)

mobile device security risks

The post Tips for Reducing Mobile Device Security Risks appeared first on HIPAA Journal.

Is AWS HIPAA Compliant?

Posted by HIPAA Journal

Is AWS HIPAA compliant? Amazon Web Services has all the protections to satisfy the HIPAA Security Rule and Amazon will sign a business associate agreement with healthcare organizations. So, is AWS HIPAA compliant? Yes. And No. AWS can be HIPAA compliant, but it is also easy to make configuration mistakes that will leave protected health information (PHI) unprotected and accessible by unauthorized individuals, violating HIPAA Rules.

Amazon Will Sign a Business Associate Agreement for AWS

Amazon is keen for healthcare organizations to use AWS, and as such, a business associate agreement will be signed. Under that agreement, Amazon will support the security, control, and administrative processes required under HIPAA.

Previous, under the terms of the AWS BAA, the AWS HIPAA compliance program required covered entities and business associates to use Amazon EC2 Dedicated Instances or Dedicated Hosts to process Protected Health Information (PHI), although that is now no longer the case.

As part of its efforts to help healthcare organizations use AWS safely and securely without violating HIPAA Rules, Amazon has published a 26 page guide – Architecting for HIPAA Security and Compliance on Amazon Web Services – to help covered entities and business associates get to grips with securing their AWS instances, and setting access controls.

AWS HIPAA Compliance is Something of a Misnomer

Amazon supports HIPAA compliance, and AWS can be used in a HIPAA compliant way, but no software or cloud service can ever be truly HIPAA compliant. As with all cloud services, AWS HIPAA compliance is not about the platform, but rather how it is used.

The Amazon Simple Storage Service (S3) that is provided through AWS can be used for data storage, data analysis, data sharing, and many other purposes. Data can be accessed from anywhere with an Internet connection, including via websites, and mobile apps. AWS has been developed to be secure, otherwise no one would use the service. But it has also been developed to make data easy to access, by anyone with the correct permissions. Make a mistake configuring users or setting permissions and data will be left exposed.

Just because AWS is HIPAA compliant, it does not mean that using AWS is free from risk, and neither that a HIPAA violation will not occur. Leaving AWS S3 buckets unprotected and accessible by the public is a clear violation of HIPAA Rules. It may seem obvious to secure AWS S3 buckets containing PHI, but this year there have been multiple healthcare organizations that have left their PHI open and accessible by anyone.

Amazon S3 buckets are secure by default. The only way they can be accessed is by using the administrator credentials of the resource owner. It is the process of configuring permissions and providing other users with access to the resource that often goes awry.

When is AWS not HIPAA Compliant?

When is AWS HIPAA compliant? When a BAA has been signed, users have been instructed on the correct way to use the service, and when access controls and permissions have been set correctly. Misconfigure an Amazon S3 bucket and your data will be accessible by anyone who knows where to look.

Documentation is available on the correct way to configure Amazon S3 services and manage access and permissions. Unfortunately, since there are several ways to grant permissions, there are also several points that errors can occur, and simple mistakes can have grave consequences.

On numerous occasions, security researchers have discovered unprotected AWS S3 buckets and have alerted healthcare organizations that PHI has been left unprotected. However, security researchers are not the only ones checking for unsecured data. Hackers are always on the prowl. It is far easier for a hacker to steal data from cloud storage services that have had all protections removed than it is to attack organizations in other ways.

One of the mistakes that has been made time and again is setting access controls to allow access by ‘authenticated users.’ That could be taken to mean anyone who you have authenticated to have access to your data. However, that is not Amazon’s definition of an authenticated user. An authenticated user is anyone with an AWS account, and anyone can obtain an AWS account free of charge.

How Common are AWS Misconfigurations?

AWS misconfigurations are very common. So much so, that Amazon recently emailed users who had potentially misconfigured their S3 buckets to warn them that data could be accessed by anyone.

Amazon said in its email, “We’re writing to remind you that one or more of your Amazon S3 bucket access control lists (ACLs) are currently configured to allow access from any user on the internet,” going on to explain, “While there are reasons to configure buckets with world read access, including public websites or publicly downloadable content, recently, there have been public disclosures by third parties of S3 bucket contents that were inadvertently configured to allow world read access but were not intended to be publicly available.”

Some of those public disclosures have been by healthcare organisations, but the list is long and varied, including military contractors, financial institutions, mobile carriers, entertainment companies, and cable TV providers. One data analytics firm left data unprotected, exposing the records of 200 million voters. Verizon exposed the data of between 6 and 14 million customers, and World Wide Entertainment exposed the data of 3 million individuals. Patient Home Monitoring, a HIPAA covered entity, left 47GB of data unprotected.

There is no excuse for these oversights. Checking for unprotected AWS buckets is not only a quick and easy process, software can be used free of charge for this purpose. A tool has been developed Kromtech called S3 Inspector that can be used to check for unsecured S3 buckets.

Is AWS HIPAA Compliant?

So, in summary, is AWS HIPAA compliant? Yes, it can be, and AWS offers healthcare organizations huge benefits.

Can the use of AWS violate HIPAA Rules and leave PHI unprotected? Very easily.

Would misconfiguration of AWS lead to a HIPAA violation penalty? That is a distinct possibility. AWS is secure by default. Only if settings are changed will stored data be accessible. It would be hard to argue with OCR auditors that manually changing permissions to allow anyone to access a S3 bucket containing PHI is anything other than a serious violation of HIPAA Rules.

The post Is AWS HIPAA Compliant? appeared first on HIPAA Journal.

New AEHIS/ MDISS Partnership to Focus on Advancing Medical Device Cybersecurity

Posted by HIPAA Journal

A new partnership has been announced between CHIME’s Association for Executives in Healthcare Information Security (AEHIS) and the Foundation for Innovation, Translation and Safety Science’s Medical Device Innovation, Safety and Security Consortium (MDISS). The aim of the new collaboration is to help advance medical device cybersecurity and improve patient safety.

The two organizations will work together to help members identify, mitigate, and prevent cybersecurity threats by issuing cybersecurity best practices, educating about the threats to device security, training members, and promoting information sharing.

For the past three years, AEHIS has been helping healthcare organizations improve their information security defences. More than 700 CISOs and other healthcare IT security leaders have benefited from the education and networking opportunities provided by AEHIS. AEHIS helps its members protect patients from cyber threats, including cyberattacks on their medical devices, though its educational efforts, sharing best practices, and many other activities.

MDISS now consists of more than 2,000 hospitals and dozens of medical device manufacturers who are working together to improve medical device cybersecurity. MDISS has helped to make medical device risk assessments cheaper, faster, and more accessible, while bringing together regulatory bodies, patient advocates, insurers, security researchers, medical device manufacturers, and healthcare providers to advance best practices in medical device cybersecurity and risk management.

It is hoped that the collective voice of AEHIS and MDISS will help to improve information security practices and ensure patients – and health data – are better protected.

“The scale and reach of AEHIS’ education network is a perfect complement to MDISS’ continuous release of envelope-pushing technologies and best practices,” said Dale Nordenberg, executive director of MDISS. “AEHIS will play a key role in accelerating the adoption of next-generation medical device security assessment platforms like MDRAP.”

“Together, AEHIS and MDISS joining forces to advocate and advance better medical device security will benefit AEHIS members and MDISS stakeholders alike,” said Sean Murphy, chair of the AEHIS collaborative relationships committee and vice president and CISO at Premera Blue Cross.

Key Goals of the New Partnership

  • Educating healthcare organizations about medical device cybersecurity strategies
  • Developing and sharing medical device cybersecurity best practices
  • Promoting the adoption of the NIST’s cybersecurity framework
  • Identifying new best practices for securing medical devices and mitigating vulnerabilities
  • Increasing awareness of medical device vulnerabilities among federal policymakers
  • Determining best practices to engage members in advocacy for cyber protection of medical devices
  • Examining the issues that are preventing the sharing of cybersecurity and medical device vulnerability information and helping to support information sharing through existing or modified information sharing efforts.

The post New AEHIS/ MDISS Partnership to Focus on Advancing Medical Device Cybersecurity appeared first on HIPAA Journal.

Internet of Medical Things Resilience Partnership Act Approved

Posted by HIPAA Journal

The passage of the Internet of Medical Things Resilience Partnership Act has been approved by the U.S. House of Representatives.

The main aim of the bill is to establish a public-private stakeholder partnership, which will be tasked with developing a cybersecurity framework that can be adopted by medical device manufacturers and other stakeholders to prevent data breaches and make medical devices more resilient to cyberattacks.

The range of medical devices now being used in healthcare is considerable and the number is only likely to grow. As more devices are introduced, the risk to patients increases. These devices are currently used in hospitals, worn by patients, fitted surgically, or used at home. The devices include drug infusion pumps, ventilators, radiological technologies, pacemakers, and monitors.

If appropriate safeguards are not incorporated into the devices, they will be vulnerable to attack. Those attacks could be performed to gain access to the data stored or recorded by the devices, to use the devices to launch attacks on healthcare networks, or to alter the function of the devices to cause patients harm. What is certain is that if nothing is done, the devices will be attacked and healthcare organizations and patients are likely to be harmed.

The Internet of Medical Things Resilience Partnership Act was introduced by Representatives Dave Trott (D-MI) and Susan Brooks (R-IN) last week. Rep Brooks said, “It is essential to provide a framework for companies and consumers to follow so we can ensure that the medical devices countless Americans rely on and systems that keep track of our health data are protected.”

“In our nation’s hospitals, technology has helped provide better quality and more efficient health care, but the perpetual evolution of technology – its greatest strength – is also its greatest vulnerability,” explained Rep. Trott.

The bill suggests the working group should be led by the U.S. Food and Drug Administration (FDA), and should include representatives from the National Institute of Standards and Technology (NIST), the HHS’ Office of the National Coordinator for Health Information Technology (ONC), the Cybersecurity and Communications Reliability Division of the Federal Communications Commission (FCC), and the National Cyber Security Alliance (NCSA).

At least three representatives of each of the following groups should also join the working group: health care providers, health insurance providers, medical device manufacturers, cloud computing, wireless network providers, health information technology, web-based mobile application developers, and hardware and software developers.

The group will be tasked with developing a cybersecurity framework for medical devices based on existing cybersecurity frameworks, guidance, and best practices. The working group should also identify high priority gaps for which new or revised standards are needed, and develop an action plan to ensure those gaps are addressed.

The working group will be required to submit its report no later than 18 months from the passing of the  Internet of Medical Things Resilience Partnership Act.

The post Internet of Medical Things Resilience Partnership Act Approved appeared first on HIPAA Journal.

53% of Businesses Have Misconfigured Secure Cloud Storage Services

Posted by HIPAA Journal

The healthcare industry has embraced the cloud. Many healthcare organizations now use secure cloud storage services to host web applications or store files containing electronic protected health information (ePHI).

However, just because secure cloud storage services are used, it does not mean data breaches will not occur, and neither does it guarantee compliance with HIPAA. Misconfigured secure cloud storage services are leaking sensitive data and many organizations are unaware sensitive information is exposed.

A Business Associate Agreement Does Not Guarantee HIPAA Compliance

Prior to using any cloud storage service, HIPAA-covered entities must obtain a signed business associate agreement from their service providers.

Obtaining a signed, HIPAA-compliant business associate agreement prior to the uploading any ePHI to the cloud is an important element of HIPAA compliance, but a BAA alone will not guarantee compliance. ePHI can easily be exposed if cloud storage services are not configured correctly.

As Microsoft explains, “By offering a BAA, Microsoft helps support your HIPAA compliance, but using Microsoft services does not on its own achieve it. Your organization is responsible for ensuring that you have an adequate compliance program and internal processes in place, and that your particular use of Microsoft services aligns with HIPAA and the HITECH Act.”

Configure your account correctly and your data will be secure. Make a mistake and data will be exposed and you could easily violate HIPAA Rules.

Misconfigured Secure Cloud Storage Services

When it comes to secure cloud storage, many organizations believe their cloud environments have been secured, but that is often not the case. How many businesses are leaving data exposed? According to a recent study by cloud threat defense firm RedLock, more than half of businesses have made mistakes that have exposed sensitive data in the cloud.

The report reveals many organizations are not following established security best practices, such as using multi-factor authentication for all privileged account users. To make matters worse, many businesses are failing to monitor their cloud environments which means data is being exposed, but not detected.

The problem appears to be getting worse. RedLock’s last analysis for Q2 revealed 40% of businesses had misconfigured at least one of their cloud storage services – Amazon Simple Storage Service (Amazon S3) for example. A new analysis, published in its latest Cloud Security Trends Report, shows that percentage jumped to 53% between June and September 2017.

Key Findings

  • 53% of organizations have at least one exposed cloud storage service
  • 38% of users exposed data through compromised administrative user accounts
  • 81% are not managing host vulnerabilities in the cloud
  • 37% of databases accept inbound connection requests from suspicious IP addresses
  • 64% of databases are not encrypted
  • 45% of Center of Internet Security (CIS) compliance checks are failed
  • 48% of Payment Card Industry Data Security Standard (PCI DSS) compliance checks fail
  • 250 organizations were found to be leaking credentials to their cloud environments on internet-facing web servers

Cloud Misconfigurations Result in Data Breaches

One need look no further than the widespread misconfigured MongoDB installations that were discovered by hackers in January 2017. Misconfigured databases were plundered, data deleted, and ransom demands issued. More than 26,000 MongoDB databases were hijacked and held for ransom.

Is it not just small organizations that are making errors that are resulting in data exposure and data breaches. The Equifax data breach, which saw the records of more than 143 million Americans exposed, was the result of the failure to address a known vulnerability in Apache Struts; a framework that supported its dispute portal web application. Equifax CEO Richard Smith recently told the House Energy and Commerce Committee that the missed patch was due to a mistake by a single employee.

British insurance giant Aviva found out one of its cloud environments had been ‘hacked’ and was being used to mine Bitcoin. Kubernetes administration consoles were used to gain access to its cloud environment with ease. Its administration consoles lacked passwords.

RedLock is not the only company to report on the problem. IBM X-Force said it has tracked more than 1.3 billion records that were exposed as a result of misconfigured servers up to September 2017.

Training will only go so far. You can train your employees never to leave the firewall turned off, yet occasionally that happens. Bad errors can also occur in the cloud that will similarly lead to data breaches. Leave the door open to hackers and they will infiltrate cloud environments, steal data, and hold organizations to ransom.

What organizations must do is to make sure all doors have been closed and locked. Unless organizations proactively monitor their cloud environments, they will be unaware there is a problem until it is too late.

The post 53% of Businesses Have Misconfigured Secure Cloud Storage Services appeared first on HIPAA Journal.

Amazon Alexa is Not HIPAA Compliant – But That Could Soon Change

Posted by HIPAA Journal

Amazon Alexa is not HIPAA compliant, which limits its use in healthcare, although that could be about to change.

Amazon already supports HIPAA compliance for its cloud platform AWS and is keen to see its voice recognition technology used more extensively in healthcare. However, before the true potential of Alexa can be realized, Amazon must first make Alexa HIPAA compliant.

Alexa certainly has considerable potential in healthcare. Alexa could be used by physicians to transcribe medical notes or as a virtual assistant in physicians’ offices. Alexa is currently used in around 30 million U.S. homes, and the technology could easily be used to remotely monitor patients. The technology could also help to engage patients more in their own healthcare.

Some healthcare organizations have already started experimenting with Alexa. WebMD has developed an Alexa skill to deliver some of its web content to consumers via their Alexa devices at home. Beth Israel Deaconess Medical Center (BIDMC) has run a pilot scheme to test Alexa’s capabilities in an inpatient setting, although not using real patient data. That pilot produced highly promising results. BIDMC plans on using Alexa in a clinical setting, once appropriate safeguards have been incorporated and when Amazon is willing to sign a business associate agreement (BAA).

Boston’s Children’s Hospital (BCH) is also piloting the use of Alexa to provide information to its clinical staff, although, without a BAA, only with non-identifiable health information at present. BCH has also developed an Alexa skill called KidsMD, which allows parents to ask about medical conditions and obtain advice on basic health conditions.

Earlier this year, Amazon challenged developers to come up with new ways of using Alexa to assist patients with diabetes. The Alexa Diabetes Challenge, launched in April 2017, was developed to help improve the lives of patients diagnosed with type 2 diabetes – approximately 27.5 million individuals in the United States.

Effective treatments are available, and along with lifestyle changes, patients can live long and healthy lives. However, self-management of the condition can be difficult, especially for individuals who have recently been diagnosed with the disease. Amazon sought submissions of patient-centric solutions that use Alexa voice recognition technology to assist patients. The winner of the challenge will be announced later this month.

Last month, Oxana Pickeral, Global Segment Leader for Healthcare & Life Sciences at Amazon Web Services, acknowledged that HIPAA was an issue that needs to be overcome before Alexa could be widely used in healthcare.  She explained that the Diabetes Challenge has helped to demonstrate the potential of the technology. Pickeral said, “While Alexa and Lex are not HIPAA-eligible, this [Diabetes Challenge] has provided us an opportunity to envision what is possible.” Amazon is now looking at addressing the requirements of HIPAA for Alexa, as it did with AWS.

Thanks to the work it has done on AWS, all the basics are all in place, but until Alexa, and the Lex platform on which it is based, incorporate appropriate safeguards to meet the requirements of the HIPAA Security Rule, the voice recognition technology will not be able to be used by HIPAA-covered entities in conjunction with protected health information.

Amazon is certainly moving toward making Alexa HIPAA-compliant, but until it is willing to sign a BAA and abide by HIPAA Rules, Alexa cannot be used in a healthcare setting with any identifiable health information.

The post Amazon Alexa is Not HIPAA Compliant – But That Could Soon Change appeared first on HIPAA Journal.