Category Archives: Risk management

Killed by code – back to the future

Back in 2011, I thought it’s only a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device).

Fast forward to Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.

At risk:

  • Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

I’ve been talking to our medical device customers about mobile security of implanted devices for over 4 years now.

I  gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 ago and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.

But – ICD are the edge, the corner case of mobile medical devices.  If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.

Mobile medical devices are becoming a pervasive part of the Internet of things; a space of  devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.

There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)

The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that:

  • are intended to be used as an accessory to a regulated medical device, or
  • transform a mobile platform into a regulated medical device.

Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document  provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix A, Appendix B and Appendix C.

Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York  that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of  an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.

Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:

Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:

  • Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
  • Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
  • Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
  • Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.

At  Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.

Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).

The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of  the threat by industry groups like The Advanced Medical Technology Association is not constructive.

Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses”  this is a strident wakeup call to medical device vendors  to  implement more robust protocols  and tighten up software security of their devices.

Tell your friends and colleagues about us. Thanks!
Share this
safeguard your head office small business

How to secure your data when firing employees

 

What kind of risk are you creating when you fire the IT security officer?

When a company decides to fire a big piece of it’s work force – it’s to reduce costs in anticipation of reduced revenues. Risk management and IT governance runs a distant second and third when it’s a question of survival. The IT department is often in the line of fire, since they’re a service organization. The IT security staff may be the first to get cut since  companies view information security as a luxury, not as a must to run the business.

There is nothing in the information security policy of any organization that I have seen that talks about how to manage risk when 300 employees are being fired in a short period of time in a business unit.

What is your risk appetite?

A key part of formulating and establishing information security   policies for your organization is in deciding how much risk is   acceptable and how to minimize unacceptable risk.

This process initially involves undertaking a formal risk assessment which is a  critical part of any ISMS.  However – it’s a mistake to assume that risk assessment is a static process when the business is a dynamic process.  Risk assessment must be dynamic and continuous, moving at the front line of the business not as an after though or not at all.

The ISO 27000 standards provide some guidance on how this  risk assessment process is to be undertaken.  This guidance is   summarized and annotated below:

  • Use systematic approach to estimate magnitude of risks (risk  analysis)
  • Compare estimated risks against risk criteria to measure the  significance of the risk (risk evaluation)
  • Define the scope of the risk assessment process to improve  effectiveness (risk assessment)
  • Undertake risk assessments periodically to address changes in  assets, risk profiles, threats, safeguards, vulnerabilities and risk  appetite (risk management)
  • Risk measurement should be undertaken in a methodical manner to  produce verifiable results (risk measurement)

The stumbling block to doing continuous risk assessment is both world view (“hire a consultant once every 2 years to check us out”) and technical (“the cost of said consultant”).  We have a great  free ISO 27001 risk assessment software that can automate the process, save you money and help you respond fast to changes in the business. The software is based on the popular PTA (practical threat analysis) Professional risk assessment tool.

Tell your friends and colleagues about us. Thanks!
Share this
hipaa cloud security

How do you know that your personal health data is secure in the cloud?

Modern system architecture for medical devices is a triangle of Medical device, Mobile app and Cloud services (storing, processing and visualizing health data collected from the device).  This creates the need for verifying a chain of trust: patient, medical device, mobile app software, distributed interfaces, cloud service software, cloud service provider.

No get out of jail free card if your cloud provider is HIPAA compliant.

We specialize in medical device security and as I’ve written here and here and here – and there is no silver marketing bullet.

Medical device vendors must implement robust software security in their device, app and cloud service layers and implement regulatory compliance in people and technical operations. If you are a medical device vendor, you cannot rely on regulatory compliance alone, nor can you rely on your cloud provider being HIPAA compliant.  I’ve written here and here how medical devices can be pivot points for attacking other systems including your customers’ and end users devices.

Regulatory compliance is not security

There are two notable regulatory standards relating to medical devices and cloud services – the HIPAA Security Rule and the FDA Guidance for Management of cybersecurity in medical devices. This is in addition to European Data Protection requirements and local data security requirements  that a particular country such as France, Germany or New Zealand may enforce for protecting health data in the cloud.

The American security and compliance model is unique (and it is typically American in its flavor) – it is based on market forces – not government coercion.

Complying with FDA Guidance is a requirement for marketing your medical device in the US.

Complying with the HIPAA Security Rule is a requirement for customers and covered entity business associates to buy your medical device.   You can have an FDA 510(K) for your medical device and still be subject to criminal charges if your cloud services are breached.   HHS has announced  in the Breach Notification Rule and here that they will investigate all breaches of 500 records and more. In addition, FDA may enforce a device recall.

But – compliance is not the same as actual enforcement of secure systems

Verifying the chain of trust

Medical device vendors that use cloud services will generally sign upstream and downstream business associate agreements (BAA) but hold on:

There is an elephant in the room:  How do you know that the cloud services are secure?  If you have a data breach, you will have to activate your cyber-security insurance policy not your cloud providers sales team.

Transparency of the cloud provider security operations varies widely with some being fairly non-transparent ()and others being fairly transparent (Rackspace Cloud are excellent in their levels of openness before and after the sale) in sharing data and incidents with customers.

When a cloud service provider exposes details of its own internal policy and technology, it’s customers (and your medical device users) will tend to trust the provider’s security claims. I would also require transparency by the cloud service providers regarding security management, privacy and security incident response.

One interesting and potentially extremely valuable initiative is the Cloud Trust Protocol.

The Cloud Trust Protocol (CTP) enables cloud service customers to request and receive data regarding the security of the services they use in the cloud, promoting transparency and trust.

The source code implements a CTP server that acts as a gateway between cloud customers and cloud providers:

  • A cloud provider can push security measurements to the CTP server.
  • A cloud customer can query the CTP server with the CTP API to access these measurements.

The source code is available here on Github.

 

 

Tell your friends and colleagues about us. Thanks!
Share this
convoluted laws of privacy and security

What is PHI?

Software Associates specialize in HIPAA security and compliance for Israeli medical device companies – and 2  questions always come up: “What is PHI?” and “What is electronically protected health information?”

Of course, you will have already Googled this problem and come to one conclusion or another by surfing sites like Hipaa Compliance Made Easy or the Wikipedia entry on HIPAA.

But you may ask – “Can I entrust my security and compliance implementation to Dr. Google?” And – the answer is no.

 

Most of the content on the Net on this topic is unclear, outdated and predate the implementation of the HIPAA Final Rule in October 2013 and many articles confuse privacy and security. Much of the content is blatantly self-serving marketing collateral for security products like this plug for a firewall product and this pitch by Checkpoint to register on their web site.

Then, there is a distinct American flavor to the Final Rule which makes it even more confusing for non-American readers who have to try and grasp why payment in cash is related to privacy. (Hint – in Europe, privacy is a fundamental human right unrelated to money).

When individuals pay by cash they can instruct their provider not to share information about their treatment with their health plan.  The final omnibus rule sets new limits on how information is used and disclosed for marketing and fundraising purposes and prohibits the sale of an individuals’ health information without their permission.

But – although Congress low-balled the cost to the American healthcare industry for compliance in order to get the bill approved – for all of the law’s American peculiarities, the HIPAA Final Rule is well thought out and a good example of how to use free market forces to enforce security and compliance.   That however – will be a topic for another post.

For now we want to find a precise answer to the questions “What is PHI?” and “What is EPHI?”

Careful reading of the law itself clearly shows 2 things:

A. PHI (Protected health information) is health / clinical data mixed with PII (personally identifiable information, which is basically having enough information to steal someone’s identity in the US) stored and transmitted verbally or on paper.

B. EPHI (Electronic Protected health information) is PHI transmitted and/or stored electronically.

Simple indeed.

See HIPAA Administrative Simplification
Regulation Text 45 CFR Parts 160, 162, and 164
(Unofficial Version, as amended through March 26, 2013)

Notes – definitions of PHI

Electronic protected health information means information that comes within
paragraphs (1)(i) or (1)(ii) of the definition of protected health information
as specified in this section.

(1) Protected health information means individually
identifiable health information that is:
(i) Transmitted by electronic media;
(ii) Maintained in electronic media; or
(iii) Transmitted or maintained in any other form or medium.

(2) Protected health information excludes individually identifiable health
information:

(i) In education records covered by the Family Educational Rights
and Privacy Act, as amended, 20 U.S.C. 1232g;
(ii) In records described at 20 U.S.C. 1232g(a)(4)(B)(iv);
(iii) In employment records held by a covered entity in its role as employer; and
(iv) Regarding a person who has been deceased for  more than 50 years.

Individually identifiable health information is information that is a subset of
health information, including demographic information collected from an
individual, and:
(1) Is created or received by a health care provider, health
plan,employer, or health care clearinghouse; and
(2) Relates to the past,
present, or future physical or mental health or condition of an individual; the
provision of health care to an individual; or the past, present, or future
payment for the provision of health care to an individual; and
(i) That identifies the individual; or
(ii) With respect to which there is a reasonable basis to believe the
information can be used to identify the individual.

 

 

 

 

Tell your friends and colleagues about us. Thanks!
Share this
skin mounted medical devices

Shock therapy for medical device malware

Israel has over 700 medical device vendors.  Sometimes it seems like half of them are attaching to the cloud and the other are developing mobile apps for all kinds of crazy, innovative applications like Healthy.io ( Visual Input Turned Into Powerful Medical Insight – translation: an app that lets you do urine analysis using your smart phone).

But – let’s not forget that many Medical devices  such as bedside monitors, MRI, nuclear medicine and  catheterization devices all reside on today’s hospital enterprise network.

An enterprise hospital network is a dangerous place.

Medical devices based on Microsoft Windows  can be extremely vulnerable to attack from hackers and malware who penetrate the hospital network and exploit typical vulnerabilities such as default passwords.

More importantly – medical devices that are attached to a hospital network are a significant threat to the hospital network itself since they may propagate malware back into the network.

While a thorough software security assessment of the medical device and appropriate hardening of the operating system and user-space code is the best way to secure a medical device in a hostile hospital network – this is not usually an option for the hospital once the medical device is installed.

Taking a page out of side-channel attacks and using the technique to detect malware, University of Michigan researchers have developed WattsUpDoc, a system designed to detect malware on medical devices by noting small changes in their power consumption.

The researchers say the technology could give hospitals a quick way to identify medical devices with significant vulnerabilities.

The researchers tested WattsUpDoc on an industrial-control workstation and on a compounder, which is used to mix drugs.

The malware detector first learned the devices’ normal power-consumption patterns. Then it tested machines that had been intentionally infected with malware. The system was able to detect abnormal activity more than 94 percent of the time when it had been trained to recognize the malware, and up to 91 percent of the time with previously unknown malware. The researchers say the technology could alert hospital IT administrators that something is wrong, even if the exact virus is never identified.

For the full article see WattsUpDoc

 

Tell your friends and colleagues about us. Thanks!
Share this
risk-driven medical device security

Health Information Technology Patient Safety Action & Surveillance Plan

This is a quick update on two new documents released by the HHS and the IMDRF:

 Health Information Technology Patient Safety Action & Surveillance Plan

The US Department of Health and Human Services published on July 2, 2013 the Health Information Technology Patient Safety Action & Surveillance Plan. The FDA belongs to the HHS.

The plan defines several types of action in three categories: Learn, Improve, Lead.

·       Learn – focuses primarily on monitoring of safety of Health IT in the field.

·       Improve – includes investigating adverse events and taking corrective action. Also included are setting safety priorities and incorporating safety into certification criteria for Health IT.

·       Lead – encourages the private sector leadership for Health IT Safety and develops a risk-based regulatory framework for Health IT.

The plan is found at http://www.healthit.gov/sites/default/files/safety_plan_master.pdf .

 Standalone Medical Device Software: Key Definitions

The International Medical Device Regulators Forum, a medical device-focused regulators-only successor group to the Global Harmonization Task Force (GHTF), has released a new document for consultation regarding the definition of standalone software used for medical purposes.

The document, Standalone Medical Device Software: Key Definitions, was released on 1 July 2013 and is being coordinated by the FDA.

As the document explains, “Software for medical purposes is becoming increasingly important and … can appear in many forms and on many computing platforms.” For example, some software is embedded into a type of medical device, while others are sold as stand-alone software meant to work on a variety of devices (e.g. mobile devices) or settings (e.g. cloud-based computing or local networks).

A major issue with respect to regulators is the fast pace at which the technology is progressing. Accordingly, this leads to problems in understanding what is required and what is expected (note: what is required is not necessarily what is expected and what is expected is not necessarily what is required).

The document provides a detailed analysis and definition of standalone medical device software (SMDS). According to the IMDRF, medical device software – which is defined as a medical device — “may include but are not limited to” the following characteristics:

·       capable of running on general purpose (non-medical purpose) computing platforms

·       not necessary for a hardware medical device to achieve its intended medical purpose

·       may be used in combination (e.g., as a module) with other devices

·       may be interfaced with other medical devices, including hardware medical devices and other standalone medical devices software

Software that meets the definition of SMDS and is part of another software, regardless if the other software has a medical purpose or not, is still considered as a SMDS.

The document is found at http://www.imdrf.org/docs/imdrf/final/consultations/imdrf-cons-sskd-130701.pdf.

If there are any questions, please contact us.

 

Tell your friends and colleagues about us. Thanks!
Share this
selling security products with fear, ignorance and online marketing

Why security defenses are a mistake

Security defenses don’t improve our understanding of the root causes of data breaches

Why is this so? Because when you defend against a data breach – you do not necessarily understand the vulnerabilities that can be exploited.

If do not understand the root causes of your vulnerabilities, how can you justify and measure the effectiveness of your defensive measures?

Let me provide you with an example.

Conventional IT security practice says that you must install a firewall in front of a server farm.

Firewalls prevent the bad guys from getting in. They don’t prevent sensitive data assets from leaving your network during a data breach.

If you have a dozen servers, running Ubuntu 12.04 with the latest patches, hardened and only serving responses to requests on SSH and HTTPS services not only is there no added value in a firewall but installing and maintaining a firewall will be a waste of money that doesn’t defend against a data breach.

First of all – defenses are by definition, not a means of improving our understanding of strategic threats. Think about the Maginot Line in WWI or the Bar-Lev line in 1973. Network and application security products that are used to defend the organization are rather poor at helping us understand and reduce the operational risk of insecure software.

Second of all – it’s hard to keep up. Security defense products have much longer product development life cycles then the people who develop day zero exploits. The battle is also extremely asymmetric – as it costs millions to develop a good application firewall that can mitigate an attack that was developed at the cost of three man months and a few Ubuntu workstations. Security signatures (even if updated frequently) used by products such as firewalls, IPS and black-box application security are no match for fast moving, application-specific source code vulnerabilities exploited by attackers and contractors.

Remember – that’s your source code, not Microsoft.

Third – threats are evolving rapidly. Current defense in depth strategy is to deploy multiple tools at the network perimeter such as firewalls, intrusion prevention and malicious content filtering. Although content inspection technologies such as DPI and DLP are now available, current focus is primarily on the network, despite the fact that the majority of attacks are on the data – customer data and intellectual property.

The location of the data has also become less specific as the notion of trusted systems inside a hard perimeter has practically disappeared with the proliferation of cloud services, Web 2.0 services, SSL VPN and convergence of almost all application transport to HTTP.

In summary – before handing over a PO to your local information security integrator – I strongly suggest a systematic threat analysis of your systems. After you have prioritized set of countermeasures – you’ll be buying, but not necessarily what he’s selling.

Tell your friends and colleagues about us. Thanks!
Share this
epidermal electronics

Software in Medical Devices – Update

We have previously written about various aspects of the software development process, especially, the verification and validation activities in implanted and invasive medical devices.

Here is  an update on what is happening in the regulatory arena and how the regulatory groups are checking up on what we are doing.

Software Recalls 2012

The estimate for software recalls by the FDA for 2012 is 173. The software recalls for 2011 were 177 and for 2010 were 76. So far there are quite a few software recalls in 2013.

There are a number of new guidances and standards released and soon to be released – it’s worth getting up to speed if you are developing software for medical devices and concerned about reliability and software security:

  1. 21 CFR 880.6310, Medical Device Data Systems, FDA – released. This standard relates to hardware or software products that transfer, store,convert formats, and display medical device data. This application can be defined as a medical device which is a Class I device instead of the classification of your system. It has been used by a number of companies to define gateways between systems.
  2. ISO 82304-1, Healthcare Software Systems – Part 1: General Requirements For Product Safety – to be released maybe later this year. There is a draft copy out. This relates to medical devices that are only software. 
  3. MEDDEV 2.1/16, January 2012 – Guidelines on the qualification and classification of standalone software used in healthcare within the Regulatory framework of medical devices 4) ISO/IEC TIR 80002-1:2009, Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software – refers to the risk analysis on the software. This is an interesting aspect as we tend to analyze the risks on a system level.  If you have any questions please contact us. 
  4. ISO/IEC TR 80002-02, Medical device software – Part 2: Validation of software for regulated processes – to be released maybe later this year. This refers to software used in the all other aspects in the organization. 
  5. IEC 80001-1:2010, Application of Risk Management for IT Network incorporating Medical Devices – This is the risk management doctrine for hospitals, etc. employing medical devices on the network. If you supply your system to a hospital, you may be requested to let the hospital know if you are 8001 compliant. Once we know more on this, we’ll update you. 
  6. AAMI TIR45:2012, Guidance on the use of agile practices in the development of medical device software – This is a technical report from the AAMI on the use of Agile in the software development.
  7. AAMI/ANSI SW87:2012, Application of Quality Management System concepts to Medical Device Data Systems (MDDS) – provides guidance for Application of Quality Management System concepts to Medical Device Data Systems (MDDS) 
  8.  AAMI TIR on Guidance on Health Software Safety and Assurance – future release
  9.  AAMI TIR on Classification of defects contributing to unacceptable risk in health software – future release

Click here to download the full article on FDA standards and guidance and software in medical devices  Software Update 020613

Courtesy of my colleague Mike Zeevi

Tell your friends and colleagues about us. Thanks!
Share this
Cyber warfare pentagon cyberwar

Is cyber security and mobile device management important in the healthcare industry?

Is cyber security and mobile device management important in the healthcare industry?

Healthcare and technology go hand in glove more than almost any other sector in today’s business world. This statement is true today and will remain so into the future. Patient records form just one element of the vast mountain of data that is stored and processed everyday by all healthcare providers be they a local GP’s surgery or a teaching hospital. These records are some of the most sensitive data there is, protecting this data from accidental or malicious access is becoming increasingly difficult.

Just think of the many and varied mobile devices there are today designed to either plug-in, wirelessly connect or Bluetooth connect to your network or computer system. Can we police and manage these connections? After all when access is required, by bona fide healthcare professionals, this ease of connection and access is a very desirable requirement. But the security of this access is paramount not least because there is a legally enforceable duty of care to protect this sensitive data.

In an ideal world the holder of any sensitive data would be able to control and audit the sharing of that data throughout its lifetime. That touches on another valid concern, that of when is data irrecoverably deleted, we should look at this issue in another blog. If we accept the premise that no amount of added security can be totally full proof what we need is away of mitigating the risk. The use of encryption technology seems to be the answer. If data is encrypted when at rest or during transportation between two points it is less lightly to be compromised.

At this point we should consider the implications for the individual data user. Any security system that alters the users normal working practices will be resisted and subverted wherever possible. Human nature is not normally predisposed to thinking security. The average user in the course of their normal day’s work will access many different data sources, may transfer data between differing media devices and share that data with other users, all quite legitimately. If at every stage of this data interaction they are challenged or required to do something extra that takes time, thought or additional actions the system will not be adopted or accepted.

The latest generation of security systems has taken note of this human response to security. It has acknowledged the fact that we as users are quite willing to pay lip service to the need for robust security providing it doesn’t affect our daily lives in an obtrusive way. In just the same way as you would expect your passage to be controlled within a secure building so your access to data will be, according to your personal privileges, the key being your authentication at the front door or access point. Once inside your set of privileges dictates your access to and actions that can be performed to the data. All of this will be audited for later analysis. These personal privileges should, in a well designed system, be dynamic. By this I mean that your privileges can be modified in real time, what you can do today you might not be able to do tomorrow. Keeping data available on a need to have access basis help limit the possibility of compromise.

And what of that data that you shared? Where is it now and is it still being controlled securely? Just because it has left your system has it suddenly become less sensitive? Unlikely! The system should be capable of extending it’s security to that data that has been shared beyond the network. Email or thumb drives are just two easy routes for the leaking of sensitive data. Be sure the system you consider has taken this into account.

I hope this very brief blog has shed some light on the various issues that confront those responsible for the security of the data they hold. You can find out more about cyber security here

Tell your friends and colleagues about us. Thanks!
Share this
risk-driven medical device security

The facts of life for HIPAA business associates

If you are a biomed vendor and you collect any  kind of PHI (protected health information) in your medical device or store information in the cloud (including public cloud services like Google Drive and Dropbox) you need to be aware of US healthcare information privacy regulation.

As a medical device vendor selling to healthcare providers, hospitals, physicians and health information providers in the US, you may be directly liable for violations of the HIPAA Security Rule for impermissible use and disclosure of PHI (protected health information) in any form, paper or digital.

You cannot hide behind your contract with the covered entity or sub-contract your services to another entity.

You must now comply with the HIPAA Security Rule yourself.

In the past you could rely on your business contract with your covered entity customer as a business associate.

The Final Rule makes business associates of covered entities directly liable for Federal penalties for failures to comply.

The Security Rule’s administrative, physical, and technical safeguards requirements in §§ 164.308, 164.310, and 164.312, as well as the Rule’s policies and procedures and documentation requirements in § 164.316, apply to business associates in the same manner as these requirements apply to covered entities; business associates are now civilly and criminally liable for violations of these provisions.

When a breach of patient privacy occurs, business associates and their sub-contractors must notify HHS if more than 500 records have been disclosed.

The HIPAA Final rule becomes effective March 26, 2013. Everyone has to comply by September 23, 2013.  That includes medical device vendors like you.

 I’m a small biomed startup – what should I do?

Smaller or less sophisticated  biomed vendors may not have engaged in the formal safeguards required by the HIPAA Security Rule, and may find the Final Rule and even intimidating new territory .

Software Associates specialize in software security and HIPAA compliance for biomed. We use a robust threat modeling process that  analyzes multiple threat scenarios and generates best-fit cost-effective safeguards  in a  highly effective way of achieving robust software security and HIPAA compliance

We will help you achieve HIPAA compliance and implement the right safeguards for your product.

Please feel free to contact us at any time and ask for a free phone consultation.

 

Tell your friends and colleagues about us. Thanks!
Share this