Healthcare Technology Vendor News

ONC Proposes New Rule to Advance Care Through Technology and Interoperability

The HHS’ Office of the National Coordinator of Health IT has proposed a new rule that is intended to advance care through technology and interoperability. The new rule – Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing (HTI) – implements certain provisions of the 21st Century Cures Act and makes enhancements to the ONC Health IT Certification Program.

The aim of the new rule, which runs to 556 pages, is to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information which will help to promote innovation and improve data security. The updates cover the movement of health information, introduce new data standards, improve electronic case reporting to support the response to a public health emergency, ensure greater transparency of artificial intelligence algorithms, and changes to improve patient privacy.

Implementing the Electronic Health Record Reporting Program

The new rule implements the 21st Century Cures Act requirement to establish an EHR Reporting Program condition and maintenance of certification under the ONC Health IT Certification Program. ONC proposes the adoption of nine reporting measures for developers of certified health IT, which initially focus on interoperability and emphasize individuals’ access to electronic health information, public health information exchange, clinical care information exchange, and standards adoption and conformance. Other categories specified in the 21st Century Cures Act will be addressed in future years, namely security, usability, and user-centered design, conformance to certification testing, and other categories to measure the performance of EHR technology.

New Data Standards to Encourage and Improve Data Sharing

The rule will establish a new baseline version of the United States Core Data for Interoperability (USCDI v3) to promote the establishment and use of interoperable data sets of electronic health information for interoperable health data exchange, ensuring that data that enters and leaves a system can be understood. The rule proposes USCDI v1 will expire on January 1, 2025.

USCDI v3 will increase the amount and types of data that can be used and exchanged through health IT to capture more comprehensive and complete patient characteristics reflective of patient diversity, which will help to address disparities in health outcomes and help providers identify gaps in care. The new version also supports the concept of health equity by design.

USCDI v3 will also help with the gathering, use, and sharing of data in public health emergencies and emergency response. The new rule also adopts health IT standards for certified Health IT Modules to support electronic case reporting.

Improved Transparency of Artificial Intelligence for Clinical Decision Support

Artificial intelligence algorithms could help to improve care delivery, cut costs, and improve patient outcomes, especially in areas such as clinical decision support. AI algorithms are trained on very large datasets to recognize patterns and then make recommendations. For example, they can be trained using medical images to look for signs of cancer and to identify potential adverse medication interactions. The new rule will provide greater transparency about AI algorithms that interface with certified health IT used for patient care and make that information available to providers through EHRs.

The new rule aims to improve the transparency and trustworthiness of clinical decision support tools. Under the new rule there will be a different certification class for clinical decision support algorithms and certified EHRs that enable or interface with the software will allow users to review information about additional source attributes. Developers of health IT modules would also be required to undergo risk management practices for all decision support interventions they interface with, just as healthcare providers are required to conduct regular risk analyses under the HIPAA Security Rule.

Application Programming Interface Improvements

The proposed rule updates the application programming Interface (API) Conditions of Maintenance and Certification to further ONC’s efforts to standardize APIs and help providers and patients to securely access their electronic health information through the broader adoption of standardized APIs. The rule will also foster competition by advancing foundational standards for certified API technology to improve legally permissible EHI sharing among clinicians and help individuals connect with their healthcare information through a new ecosystem of health applications.

Improvements to Respect Patient Privacy

Patients may request restrictions on certain uses and disclosures of PHI under HIPAA, such as reproductive health information and substance use information. The new rule adds new ways that developers of health IT can honor patient requests to restrict uses and disclosures, such as introducing new implementation alternatives for flagged data in health IT applications to prevent it from being added to a patient’s summary of care record, which may be viewable through patient portals or shared via an application programming interface.

New Information Blocking Provisions

The proposed rule makes several information blocking enhancements to advance interoperability, improve transparency, and support the access, exchange, and use of electronic health information. These enhancements include a definition of what it means to offer health information technology or offer health IT for purposes of the information blocking regulations, which narrows the applicability of the health IT developer of certified health IT definition. The health IT developer of certified health IT definition has been updated to make it clear that healthcare providers who self-develop certified health IT would continue to be excluded from this definition.

Organizations that participate in the voluntary Trusted Exchange Framework and Common Agreement will be provided with new information blocking flexibilities. The new condition means that if a TEFCA participant offers to fulfill a data sharing request from another TEFCA participant through the framework, they would not be required to offer the data in any other way.

The Infeasibility Exception has been revised to include two new conditions and one revision to clarify when an actor’s practice of not fulfilling a request for access, exchange, or use of EHI meets the uncontrollable events condition, and the two new conditions cover the denial of a third party’s request to enable the use of EHI in order to modify EHI, and when an actor has exhausted the manner exception.

Request for Public Comment

The proposed rule will be available for public inspection on April 18, 2023, and ONC is requesting public comment by June 20, 2023.

“In addition to fulfilling important statutory obligations of the 21st Century Cures Act, implementing these provisions is critical to advancing interoperability, promoting health equity, and supporting expansion of appropriate access, exchange, and use of electronic health information,” said Micky Tripathi, Ph.D., national coordinator for health information technology. “We look forward to reviewing public comments on ONC’s proposed rule.”

The post ONC Proposes New Rule to Advance Care Through Technology and Interoperability appeared first on HIPAA Journal.

FTC and HHS Update Online Compliance Tool for Mobile Health App Developers

Developers of mobile health apps may be required to comply with certain federal laws such as the FTC Act, FTC Health Breach Notification Rule, Children’s Online Privacy Protection Act (COPPA), Health Insurance Portability and Accountability Act (HIPAA), Federal Food, Drug and Cosmetics Act (FD&C Act), the 21st Century Cures Act, and the ONC’s Information Blocking Regulations.

To help mobile health app developers avoid compliance missteps, the Federal Trade Commission (FTC), in conjunction with the Department of Health and Human Services’ Office for Civil Rights (OCR), Office of the National Coordinator for Health Information Technology (ONC), and the Food and Drug Administration (FDA), developed an online tool to help developers determine which federal laws and regulations they need to comply with.

The online tool asks a series of questions about the nature of the app, the service it provides, the information it collects, and how that information is collected, shared, and used. Based on the answers to the questions, the tool will direct the developer to the relevant federal regulatory privacy, security, and breach notification laws and regulations that may apply.

The tool should be used by any developer of a mobile app that accesses, collects, shares, uses, or maintains information related to an individual’s past, present, or future health. Even if a health app has not been developed for use by a HIPAA-covered entity, there may be one or more federal laws or regulations that apply. The tool will point developers to resources where they can find out more information about their compliance obligations, along with best practices to help them deliver a safe and accurate service while ensuring the privacy and security of the health information of app users.

On December 7, 2022, the HHS announced that the online Mobile Health App Interactive Tool has been updated. The updated version can be found here.

The post FTC and HHS Update Online Compliance Tool for Mobile Health App Developers appeared first on HIPAA Journal.

Amazon Ends Support for Third Party HIPAA-Eligible Alexa Skills

Amazon has announced that it will stop support for third-party HIPAA-eligible skills for its Alexa devices, which means developers will no longer be able to create Alexa skills that collect data covered under the Health Insurance Portability and Accountability Act (HIPAA).

Amazon launched its HIPAA-compliant Alexa feature in April 2019, with skills added for patients of Atrium Health, Boston Children’s Hospital, Cigna, Express Scripts, Livongo, and Swedish Health Connect. The HIPAA compliance support meant healthcare organizations could use Alexa skills that collected HIPAA-protected data and could transmit that information in a HIPAA-compliant way. The decision has now been taken to end that support. HIPAA-eligible skills are now part of the Alexa Smart Properties for Healthcare business unit, and those skills can only be developed with first-party support.

“We regularly review our experiences to ensure we are investing in services that will delight customers. We are continuing to invest heavily in developing healthcare experiences with first and third-party developers, including Alexa Smart Properties for Healthcare,” explained Amazon in a statement.

Amazon has now written to all third-party developers to advise them that support for Alexa 3P HIPAA-eligible skills comes to an end this week and has advised them to remove their HIPAA-eligible skills from the skills store. Any developer that fails to remove the skill from the store will have it removed automatically on December 9, 2022, and the use of that skill will be suppressed. Any protected health information associated with that skill will be deleted and if any user attempts to use a HIPAA-eligible skill after it has been suppressed, they will receive a message that the skill is no longer supported. Amazon has confirmed that it will not be notifying users of the skills directly to advise them that support is ending.

The ending of support for third-party HIPAA-eligible skills does not mean that all healthcare-related Alexa skills will be suppressed, only those that collect protected health information. Any healthcare-related Alexa skills that do not collect data protected under HIPAA will be unaffected.

The post Amazon Ends Support for Third Party HIPAA-Eligible Alexa Skills appeared first on HIPAA Journal.

OCR Confirms Use of Website and Other Tracking Technologies Without a BAA is a HIPAA Violation

The HHS’ Office for Civil Rights has issued a bulletin confirming that the use of third-party tracking technologies on websites, web applications, and mobile apps without a business associate agreement (BAA) is a HIPAA violation if the tracking technology collects and transmits individually identifiable health information. Even with a BAA in place, the use of the tracking technology may still violate the HIPAA Rules

The bulletin has been issued in response to the discovery earlier this year that Meta Pixel tracking code was being extensively used on the websites of hospitals and that the code snippet transferred data to Meta, including sensitive patient data. These privacy breaches came to light during an investigation by The Markup and STAT, which found Meta Pixel had been added to the websites of one-third of the top 100 hospitals in the United States and, in 7 cases, the code had been added to password-protected patient portals. The study was limited to the top 100 hospitals, so it is likely that hundreds of hospitals have used the code and have – in all likelihood unwittingly – transferred sensitive data to Meta/Facebook without a business associate agreement in place and without obtaining patient consent.

Following the publication of the report, several lawsuits were filed against healthcare providers over these impermissible disclosures, with some plaintiffs claiming the information disclosed on the websites of their healthcare providers had been transferred to Meta and was used to serve them targeted advertisements related to their medical conditions. The news came as a shock to healthcare providers, triggering investigations and recent data breach notifications; however, despite so the widespread use of the tracking code, only a handful of hospitals and health systems have reported the breach and have sent notifications so far. The bulletin from the HHS is likely to trigger a flurry of breach notifications as providers realize that the use of Meta Pixel and other tracking code constitutes a HIPAA violation.

What are Tracking Technologies?

Tracking technologies are commonly snippets of code that are added to websites, web applications, and mobile apps for tracking user activity, typically for determining the journeys of users while using websites and monitoring their on-site interactions. The data collected by these technologies can be analyzed and used to improve the services provided through the websites and applications and enhance the user experience, which benefits patients. While there are benefits to individuals from the use of this code, there is also considerable potential for harm to be caused, as in addition to providing a HIPAA-regulated entity with useful information, the data collected through these technologies is usually transmitted to the vendor.

For instance, if a female patient arranged an appointment on the website of a healthcare provider to discuss the termination of a pregnancy, the tracking technology on the site could be transmitted to the vendor, and subsequently disclosed to other third parties. That information could be provided to law enforcement or other third parties. Information disclosed in confidence by a patient of a website or web application could be transferred to a third party and be used for fraud, identity theft, extortion, stalking, harassment, or to promote misinformation.

In many cases, these tracking technologies are added to websites and applications without the knowledge of users, and it is often unclear how any disclosed information will be used by a vendor and to whom that transmitted information will be disclosed. These tracking technologies often use cookies and web beacons that allow individuals to be tracked across the Internet, allowing even more information to be collected about them to form detailed profiles. When tracking technologies are included in web applications, they can collect device-related information, including location data which is tied to a unique identifier for that device, through which a user could be identified.

All Tracking Technologies Must be HIPAA Compliant

There is nothing in HIPAA that prohibits the use of these tracking technologies, but the HIPAA Rules apply when third-party tracking technologies are used, if the tracking technology collects individually identifiable information that is protected under HIPAA and if it transmits that information to a third party, be that the vendor of the tracking technology or any other third-party. If the tracking technology collects any identifiers, they are classed as protected health information because the information connects the individual to the regulated entity, indicating the individual has received or will receive health care services or benefits from the regulated entity, and that relates to the individual’s past, present, or future health or health care or payment for care.

There is an elevated risk of an impermissible disclosure of PHI when tracking technology is used on patient portals or any other pages that require authentication as these pages usually have access to PHI. If tracking code is added to these pages it must be configured in a way to ensure that the code only uses and discloses PHI in compliance with the HIPAA Privacy Rule, and that any information collected is secured in a manner compliant with the HIPAA Security Rule. Tracking code on unauthenticated pages also has the potential to have access to PHI. The same applies to tracking technologies within a HIPAA-regulated entity’s mobile apps, if it collects and transmits PHI. OCR confirmed that only mobile apps offered by healthcare organizations are covered by HIPAA. HIPAA does not apply to third-party apps that are voluntarily downloaded by individuals, even if the apps collect and transmit health information.

“Regulated entities are not permitted to use tracking technologies in a manner that would result in impermissible disclosures of PHI to tracking technology vendors or any other violations of the HIPAA Rules,” explained OCR in the bulletin.

The OCR bulleting confirms that if tracking technologies are used, the provider of that code – which includes Meta Platforms (Meta Pixel) and Google (Google Analytics) – would be classed as a business associate and must enter into a business associate agreement (BAA) with the HIPAA-regulated entity before the code can be added to a website or application. The BAA must state the responsibilities of the vendor with respect to the PHI and specify the permitted uses and disclosures of that information. If the vendor will not sign a BAA, PHI cannot legally be provided to that vendor, therefore the code cannot be used or must be configured in a way that it does not collect or transmit PHI. OCR also confirmed that if a vendor states that they will strip out any identifiable information prior to saving or using the transferred data, such a disclosure to the vendor would still only be permitted if a BAA was signed and if the HIPAA Privacy Rule permits such a disclosure.

Other potential violations of HIPAA could occur. If any PHI is disclosed to a vendor, it must be in line with the organization’s privacy policy and be detailed in their Notice of Privacy Practices. It is important to note that simply stating that tracking technology is used in a notice of privacy practices is not sufficient by itself to ensure compliance. In addition to a BAA, any disclosure of PHI for a purpose not expressly permitted by the HIPAA Privacy Rule requires a HIPAA-compliant authorization from a patient, giving their consent to disclose that information. Website banners that ask a website visitor to consent to cookies and the use of web tracking technologies do not constitute valid HIPAA authorizations.

Actions HIPAA-Regulated Entities Should Take Immediately

In light of the bulletin, HIPAA-regulated entities should read it carefully to make sure they understand how HIPAA applies to tracking technologies. They should also conduct a review of any tracking technologies that they are using on their websites, web applications, or mobile apps to ensure those technologies are being used in a manner compliant with the HIPAA Rules. If they are not already, website tracking technologies must be included in a HIPAA-regulated entity’s risk analysis and risk management processes.

It is important to state that a tracking technology vendor is classed as a business associate under HIPAA, even if a BAA is not signed. As such, any disclosures to that vendor would be classed as an impermissible disclosure of PHI without a BAA in place, and the HIPAA-regulated entity would be at risk of fines and other sanctions if PHI is transmitted without a signed BAA.

If during the review a HIPAA-regulated entity discovers tracking technologies are being used in a manner not compliant with the HIPAA Rules, or have been in the past, then the HIPAA Breach Notification Rule applies. Notifications will need to be sent to OCR and the individuals whose PHI has been impermissibly disclosed.

The post OCR Confirms Use of Website and Other Tracking Technologies Without a BAA is a HIPAA Violation appeared first on HIPAA Journal.

Healthcare Organizations Warned About Maximum Severity Vulnerabilities in Illumina Devices

Five vulnerabilities that require immediate patching have been identified in the Illumina Local Run Manager (LRM), which is used by Illumina In Vitro Diagnostic (IVD) devices and Illumina Researcher Use Only (ROU) instruments. The affected devices are used for clinical diagnostic DNA sequencing and testing for various genetic conditions, and for research use. Four of the vulnerabilities are critical, with three having a maximum CVSS severity score of 10 out of 10.

The vulnerabilities affect the following devices and instruments:

Illumina IVD Devices

  • NextSeq 550Dx: LRM Versions 1.3 to 3.1
  • MiSeq Dx: LRM Versions 1.3 to 3.1

Illumina ROU Devices

  • NextSeq 500 Instrument: LRM Versions 1.3 to 3.1
  • NextSeq 550 Instrument: LRM Versions 1.3 to 3.1
  • MiSeq Instrument: LRM Versions 1.3 to 3.1
  • iSeq 100 Instrument: LRM Versions 1.3 to 3.1
  • MiniSeq Instrument: LRM Versions 1.3 to 3.1

A threat actor could exploit the vulnerabilities remotely, take control of the instruments, and perform any action at the operating system level such as modifying the settings, configurations, software, or data on the instrument. It would also be possible to exploit the vulnerabilities to interact with the connected network through the affected product.

The vulnerabilities are:

  • CVE-2022-1517 – A remote code execution vulnerability due to the LRM utilizing elevated privileges, which would allow a malicious actor to upload and execute code at the operating system level. The vulnerability has a CVSS v3 severity score of 10 (critical)
  • CVE-2022-1518 – A directory traversal vulnerability that allows a malicious actor to upload outside the intended directory structure. The vulnerability has a CVSS v3 severity score of 10 (critical)
  • CVE-2022-1519 – The failure to restrict uploads of dangerous file types. A malicious actor could upload any file type, including executable code that allows for a remote code exploit. The vulnerability has a CVSS v3 severity score of 10 (critical)
  • CVE-2022-1521 – A lack of authentication or authorization in the default configuration, which would allow a malicious actor to inject, replay, modify, and/or intercept sensitive data. The vulnerability has a CVSS y3 severity score of 9.1 (critical)
  • CVE-2022-1524 – A lack of TLS encryption for the transmission of sensitive information, putting information – including credentials – at risk of interception in a man-in-the-middle attack. The vulnerability has a CVSS v3 severity score of 7.4 (high severity)

The vulnerabilities were reported to Illumina by Pentest, Ltd. Illumina has developed a software patch that will prevent the vulnerabilities from being exploited remotely as an interim fix while a permanent solution is developed for current and future instruments.

The U.S. Food and Drug Administration and the Cybersecurity and Infrastructure Security Agency (CISA) have issued security alerts urging immediate action to be taken to address the vulnerabilities.

The patch for Internet-connected instruments is available here. If the instruments are not connected to the Internet, users should contact Illumina Tech Support.

The post Healthcare Organizations Warned About Maximum Severity Vulnerabilities in Illumina Devices appeared first on HIPAA Journal.

Study Identifies Risks Associated with 3rd and 4th Party Scripts on Websites

A recent study by Source Defense examined the risks associated with the use of third- and fourth-party code on websites and found that all modern, dynamic websites included code that could be targeted by hackers to gain access to sensitive data.

SOurce Defense explained that websites typically have their own third-party supply chains, with those third parties providing a range of services and functions related to site performance, tracking and analytics, and improving conversion rates to generate more sales.

The inclusion of third- and fourth-party code on websites also introduces security and compliance risks. On the compliance side, tracking code has the potential to violate data privacy laws such as the EU’s General Data Protection Regulation (GDPR) and from a security perspective, the code included on websites may have vulnerabilities that can be exploited by threat actors to gain access to sensitive data, including protected health information.

To explore the risks associated with third- and fourth-party code, Source Defense scanned the top 4,300 websites based on traffic and analyzed their results to identify the scale of the digital supply chain, how many partners are involved on a typical website, whether the inclusion of code by those partners leaves websites exposed to cyberattacks, whether sensitive data is being exposed, and the types of attacks that could be conducted on websites that take advantage of the digital supply chain.

The findings of the analysis are detailed in the report, Third-Party Digital Supply Chain Risk: Exposing the Shadow Code on Your Web Properties. Source Defense explained that there would be little point in a threat actor compromising a script on a static webpage; however, if scripts were included on webpages that collect sensitive data, threat actors could add malicious code to steal sensitive data. The researchers found that, on average, there were 12 third-party and 3 fourth-party scripts per website on web pages that collected data, such as login pages, account registration pages, and payment collection pages.

They identified six features on websites that could be exploited by threat actors that were commonly found on websites: Code to retrieve form input (49%), button click listeners (49%), link click listeners (43%), code to modify forms (23%), form submit listeners (22%), and input change listeners (14%). Every modern, dynamic website assessed for the study was found to contain one or more of those features.

An analysis was conducted of between 40 and 50 websites in industries where there is a higher-than-average risk. The researchers found that higher-risk industries such as healthcare had more than the average number of scripts. Healthcare websites had an average of 13 third-party and 5 fourth-party scripts on sensitive pages.

There may be a legitimate reason for including these scripts on the pages but adding that code introduces risk. “For example, a script might allow form fields to be changed or added on the fly to provide website users with a more personalized experience,” explained Source Defense in the report. “However, a threat actor could exploit this capability to add additional fields asking for credentials and personal information, which would then be sent to attacker’s website.”

“This data makes it clear that managing risk inherent in third- and fourth-party scripts is both a very necessary and a very challenging task,” explained the researchers, who recommend assessing websites for third party code, educating management about the risks, implementing a website client-side security solution, categorizing and consolidating scripts, and finding ways to recuse exposure and compliance risks.

The post Study Identifies Risks Associated with 3rd and 4th Party Scripts on Websites appeared first on HIPAA Journal.

Five Eyes Intelligence Alliance Warns of Increase in Cyberattacks Targeting Managed Service Providers

The Five Eyes intelligence alliance, which consists of cybersecurity agencies from the United States, United Kingdom, Australia, New Zealand, and Canada, has issued a joint alert warning about the increasing number of cyberattacks targeting managed service providers (MSPs).

MSPs are attractive targets for cybercriminals and nation-state threat actors. Many businesses rely on MSPs to provide information and communication technology (ICT) and IT infrastructure services, as it is often easier and more cost-effective than developing the capabilities to handle those functions internally.

In order to provide those services, MSPs require trusted connectivity and privileged access to the networks of their clients. Cyber threat actors target vulnerable MSPs and use them as the initial access vector to gain access to the networks of all businesses and organizations that they support. It is far easier to conduct a cyberattack on a vulnerable MSP and gain access to the networks of dozens of businesses than to target those businesses directly.

When MSP systems are compromised, it may take several months before the intrusion is detected, during which time threat actors may conduct cyber espionage on the MSP and its customers or prepare for other follow-on activities such as ransomware attacks.

The Five Eyes agencies provide recommendations for baseline security measures that MSPs and their customers should implement and also recommend customers review their contracts with MSPs to ensure that the contracts specify that their MSPs must implement the recommended measures and controls.

Steps need to be taken to improve defenses to prevent the initial compromise. Cyber threat actors commonly exploit vulnerable devices and Internet-facing services and conduct phishing and brute force attacks to gain a foothold in MSP networks. The Five Eyes agencies recommend MSPs and their customers:

  • Improve the security of vulnerable devices
  • Protect internet-facing services
  • Defend against brute force and password spraying
  • Defend against phishing

It is vital to enable or improve monitoring and logging processes to allow intrusions to be rapidly detected. Since threat actors may compromise networks for months, all organizations should store their most important logs for at least six months. “Whether through a comprehensive security information and event management (SIEM) solution or discrete logging tools, implement and maintain a segregated logging regime to detect threats to networks,” suggest the agencies in the alert.

It is important to secure remote access applications and enforce multi-factor authentication as far as possible, and ensure MFA is implemented on all accounts that allow access to customer environments. Customers of MSPs should ensure that their contracts state that MFA must be used on accounts that are used to access their systems.

The Five Eyes agencies also suggest

  • Managing internal architecture risks and segregating internal networks
  • Applying the principle of least privilege
  • Deprecating obsolete accounts and infrastructure
  • Applying software updates and patches promptly
  • Backing up systems and data regularly and testing backups
  • Developing and exercising incident response and recovery plans
  • Understanding and proactively managing supply chain risk
  • Promoting transparency
  • Managing account authentication and authorization

MSPs and their customers will have unique environments, so the recommendations should be applied as appropriate in accordance with their specific security needs and appropriate regulations.

The post Five Eyes Intelligence Alliance Warns of Increase in Cyberattacks Targeting Managed Service Providers appeared first on HIPAA Journal.

BD Discloses 2 Vulnerabilities in its Pyxis, Rowa, and Viper LT Products

Becton, Dickinson and Company (BD) has self-reported two vulnerabilities that affect its BD Pyxis automated medication dispensing systems, BD Rowa pouch packaging systems, and BD Viper LT automated molecular testing systems.

Both vulnerabilities are due to the use of hard-coded credentials. If exploited, the vulnerabilities could allow an unauthorized individual to access, modify, and delete sensitive data, which could include electronic protected health information (ePHI).

The most serious vulnerability, tracked as CVE-2022-22765, affects all versions of the BD Viper LT system from 2.0. The vulnerability has been assigned a CVSS severity score of 8.0 out of 10.

BD is currently working on a fix for the vulnerability, which will be included in the upcoming BD Viper LT system Version 4.80 software release. In the meantime, BD has suggested implementing compensating controls, such as ensuring physical access controls are in place, only permitting authorized individuals to access the system, disconnecting the system from the network access where possible, and if it is not possible to disconnect the system from network access, to implement industry-standard network security policies and procedures.

The second vulnerability, tracked as CVE-2022-22766, affects the BD Pyxis range of products and BD Rowa Pouch Packaging Systems. The vulnerability has been assigned a CVSS severity score of 7.0 out of 10. If exploited, an attacker could gain access to the file system and exploit application files that could be used to decrypt application credentials or gain access to ePHI.

Credentials are BD managed and are not visible to or used by customers to access or use BD Pyxis devices. That means that in order to exploit the vulnerability, threat actors would have to gain access to the hardcoded credentials, infiltrate a facility’s network, and gain access to individual devices.

BD said it is in the process of strengthening credential management capabilities in BD Pyxis devices. In the meantime, compensating controls can be implemented for the affected products. These include limiting physical access to authorized personnel, tightly controlling the management of BD Pyxis system credentials provided to authorized users, isolating products in a secure VLAN or behind firewalls, and monitoring and logging network traffic. The Pyxis Security Module for automated patching and virus definition management is provided to all accounts. Users should work with their BD support team to ensure all patching and virus definitions are up to date.

“BD is committed to transparency with our customers and makes product security information, including vulnerability disclosures, available through the BD Cybersecurity Trust Center,” said BD in a statement. “As part of this commitment, BD posted product security bulletins about the use of hardcoded credentials… Hardcoded credentials are not used directly by customers or end-users to access these systems.”

There have been no reports of the vulnerabilities being exploited in clinical settings. BD self-reported the vulnerabilities to the FDA, ISAOs, and CISA for maximum awareness.

The post BD Discloses 2 Vulnerabilities in its Pyxis, Rowa, and Viper LT Products appeared first on HIPAA Journal.

Celo Launches Healthcare Messaging Platform for Teams

Celo has launched a new healthcare messaging platform for teams in the United States, with U.S. operations run from its Seattle, WA headquarters and led by Celo’s chief growth officer, Jack Clough.

Healthcare organizations have been slow to adopt modern communications technologies compared to other industry sectors and pagers, faxes, and email are still extensively used for communication between care teams, even though these outdated modes of communication are inefficient. In other industry sectors, instant messaging solutions have been widely adopted and have been shown to improve collaboration between individuals and teams and improve communication efficiency.

There are problems with using generic business messaging products and services in healthcare. The solutions tend to lack the features required by healthcare organizations and many lack the required privacy and security measures to allow healthcare data to be communicated via the platforms and are a compliance risk. Secure messaging app providers are classed as business associates under HIPAA, and many messaging app providers are unwilling to enter into business associate agreements with HIPAA-covered entities.

The Celo secure messaging platform was designed by a medical doctor and has been built specifically to meet the needs of the healthcare industry. The Celo healthcare secure messaging platform allows messages to be sent securely through the platform and appropriate safeguards have been implemented to ensure compliance with HIPAA and the HITECH Act.

At the core of the solution is a secure messaging app that includes an on-call feature that allows users to instantly communicate with the right on-call professionals. The solution includes a reporting dashboard that provides insights into areas where improvements can be made, such as resource allocation and process enhancements. The platform also includes a rostering optimization feature, that allows users to send role-based messages rather than having to find specific providers from the directory and a broadcast feature that allows administrators to send mass messages and see in real-time which staff members have received and read the messages.

The platform is compatible with iOS, Android, and can be accessed via the web. The platform can be used free of charge by individuals and teams, with the full-featured product available for a recurring fee with its Premium and Enterprise packages.

The platform has already been adopted by more than 800 healthcare organizations in the United States, United Kingdom, and New Zealand – countries that have strict legislation covering the transmission of sensitive healthcare data – to improve communication efficiency, worker productivity, and optimize clinical workflows.

The post Celo Launches Healthcare Messaging Platform for Teams appeared first on HIPAA Journal.