Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space.
Andy also writes often for O'Reilly's Radar site (http://radar.oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first part of this series of articles laid out the difficulties of securing devices in the Internet of Things (particularly those used in the human body). Accepting that usability and security have to be traded off against one another sometimes, let’s look at how to make decisions most widely acceptable to the public.

The recent FTC paper on the Internet of Things demonstrates that they have developed a firm understanding of the problems in security and privacy. For this paper, they engaged top experts who had seen what happens when technology gets integrated into daily life, and they covered all the issues I know of. As devices grow in sophistication and spread to a wider population, the kinds of discussion the FTC held should be extended to the general public.

For instance, suppose a manufacturer planning a new way of tracking people–or a new use for their data–convened some forums in advance, calling on potential users of the device to discuss the benefits and risks. Collectively, the people most affected by the policies chosen by the manufacturer would determine which trade-offs to adopt.

Can ordinary people off the street develop enough concerned with their safety to put in the time necessary to grasp the trade-offs? We should try asking them–we may be pleasantly surprised. Here are some of the issues they need to consider.

What can malicious viewers determine from data? We all may feel nervous about our employer learning that we went to a drug treatment program, but how much might the employer learn just by knowing we went to a psychotherapist? We now know that many innocuous bits of data can be combined to show a pattern that exposes something we wished to keep secret.

How guarded do people feel about their data? This depends largely on the answer to the previous question–it’s not so much the individual statistics reported, but the patterns that can emerge.

What data does the device need to collect to fulfill its function? If the manufacturer, clinician, or other data collector gathers up more than the minimal amount, how are they planning to use that data, and do we approve of that use? This is an ethical issue faced constantly by health care researchers, because most patients would like their data applied to finding a cure, but both the researchers and the patients have trouble articulating what’s kosher and what isn’t. Even collecting data for marketing purposes isn’t necessarily evil. Some patients may be willing to share data in exchange for special deals.

How often do people want to be notified about the use of their data, or asked for permission? Several researchers are working on ways to let patients express approval for particular types of uses in advance.

How long is data being kept? Most data users, after a certain amount of time, want only aggregate data, which is supposedly anonymized. Are they using well-established techniques for anonymizing the data? (Yes, trustworthy techniques exist. Check out a book I edited for my employer, Anonymizing Health Data.)

I believe that manufacturers can find a cross-section of users to form discussion groups about the devices they use, and that these users can come to grips with the issues presented here. But even an engaged, educated public is not a perfect solution. For instance, a privacy-risking choice that’s OK for 95% of users may turn out harmful to the other 5%. Still, education for everyone–a goal expressed by the FTC as well–will undoubtedly help us all make safer choices.

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space.
Andy also writes often for O'Reilly's Radar site (http://radar.oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

Are you confused about risks to privacy when everything from keystrokes to footsteps is being monitored? The Federal Trade Commission is confused too. In January they released a 55-page paper summarizing results of discussions with privacy experts about the Internet of Things, plus some recommendations. After a big build-up citing all sorts of technological and business threats, the report kind of fizzles out. Legislation specific to the IoT was rejected, but several suggestions for “general privacy legislation” such as requiring security on devices.

Sensors and controls are certainly popping up everywhere, so the FTC investigation comes at an appropriate time. My senator, Ed Markey, who has been a leader in telecom and technology for decades in Congress, recently released a report focused on automobiles. But the same concerns show up everywhere in various configurations. In this article I’ll focus on health care, and on the dilemma of security in that area.

No doubt about it, pacemakers and other critical devices can be hacked. It could be a movie: in Scene 1 a non-descript individual is moving through a crowded city street, thumbing over a common notepad. In Scene 2, later, numerous people fall to the ground as their pacemakers fail. They just had the bad luck to be in the vicinity of the individual with the notepad, who implanted their implants with malicious code that took effect later.

But here are the problems with requiring more security. First, security in computers almost always rests on encryption, which leads to an increase in the size of the data being protected. The best-known FTC case regarding device security, where they forced changes for cameras used in baby monitors, was appropriate for these external devices that could absorb the extra overhead. But increased data size leads to an increase in memory use, which in turn requires more storage and computing power on a small embedded device, as well as more transmission time over the network. In the end, devices may have to be heavier and more costly, serious barriers to adoption.

Furthermore, software always has bugs. Some lie dormant for years, like the notorious Heartbleed bug in the very software that web sites around the world depend on for encrypted communications. To provide security fixes, a manufacturer has to make it easy for embedded devices to download updated software–and any bug in that procedure leaves a channel for attack.

Perhaps there is a middle ground, where devices could be designed to accept updates only from particular computers in particular geographic locations. A patient would then be notified through email or a text message to hike it down to the doctor, where the fix could be installed. And the movie scene where malicious code gets downloaded from the street would be less likely to happen.

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space.
Andy also writes often for O'Reilly's Radar site (http://radar.oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The first part of this article looked at the basic idea of devices and computer systems that can deal with loosely connected actors, human and mechanical. This part takes it further into current experiments in health care.

These are obviously very different goals–and the device used for pulse oximetry will also be used in different ways. In a risk monitoring situation, samples may be taken less often than during a healthy fitness workout. At the minimum, a device should be configurable so that it gives the timing and accuracy needed in a particular setting. It should also be easy to turn a device on and off if it is needed for a limited time period, such as a workout.

Diego Alonso, a researcher at MD PnP, points to analgesia (the administration of pain killers) in the hospital as an example of competing needs that must be reconciled by a supervisor, human or machine. So long as the patient is stable, the pain killer should be administered. But if a monitor notices a drop in the patient’s vital signs, the painkiller’s dose must be reduced.

A popular standard for exchanging data among devices is the Data Distribution Service (DDS). The standard is rich and complex, typical of those produced by the Object Management Group. But among its virtues are an ability to specify how often you want data from a particular device. OpenICE uses DDS, among many other systems.

In short, the frequency and accuracy of data collection should be configurable. As patterns of human behavior are better understood, devices may become even more responsive to the contexts in which they are needed.

Even before the current move to standards, Capsule Tech managed to get devices to talk to EHRs through the grueling effort of interpreting the inputs and outputs of each system and crafting protocols to make them work together.

Started in 1997, the company has recently expanded from merely sharing data to developing useful tools based on data, such as alerts and a modest amount of analytics. Some of these tools demonstrate a kind of adaptability reminiscent of a human-agent collective.

For instance, alerts are crucial in any hospital environment, but notorious for crying wolf–90% can be false. In addition to sending data to the EHR, Capsule’s SmartLinx’s Medical Device Information System sends near-real-time alarm data to its Alarm Management System. This helps hospitals manage their alarms, in line with the Joint Commission’s National Patient Safety Goals.

SmartLinx does not suppress any information, but when reporting it through the Alarm Management System to the clinician’s mobile device, includes some context to help the clinician decide whether the alert needs a response. Some context involves basics such as who, where, when, and which device was activated. Other context can consist of physiological data such as the patient’s heart rate and how long the alarm has been sounding.

Additionally, to provide actionable, timely information that aids in human decision making, Capsule has built an early warning scoring system application that uses vital sign information to calculate an immediate general health status score for patients and to identify those likely to deteriorate. The application also guides the care team through appropriate actions. This may be the beginning of an intelligent, integrated health system.

Computer Systems Must Be Sensitive to Bad Input and Failure

An unfortunate tenet of human-agent collectives is that agents can’t be trusted. The most basic example is system failure. If you don’t hear from a device, does that mean the patient is fine or that the device’s battery has run out of power? DDS offers a handshake or heartbeat, the common way for distributed computing systems to determine whether part of the system has gone bust.

Provenance is another requirement for collaborative environments. This means recording when a measurement was taken, and what person or device was responsible. There must also be ways to protect against data that arrives late or is assigned the wrong timestamp. When data is entered by humans, errors can be assumed as a matter of course, even in something as simple as spelling the name of a medication manufactured by your company.

More subtle is input from inexact devices, and worse still is the potential for malicious manipulation. I heard of instances where people who got rewards by their employers for reporting exercise put their fitness devices on their dogs. Using analytics, a health care system should be able to tell that a series of sudden 20-mile-per-hour rushes interrupted by inactivity are not a human activity.

Ethical and Technical Considerations

Lots of issues come up as simple human-computer interaction evolves into collaboration among agents. I’ve already mentioned error detection and provenance. Other issues include flexibility in computers taking or relinquishing control (agile teaming), legal responsibility, providing each agent with the right incentives, considering when to engage the user’s attention (instead of taking action behind the scenes), and offering the proper interface to do so. Connected health is a deep concept offering a lot to explore, and technologies will get better as we understand more of it.

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

ONC’s Agenda – February 2-3, Washington, DC

Next Monday, ONC holds its annual meeting in downtown DC. I’m going, one small advantage of living here. Here’s the agenda. To see day two, click on the agenda header.

I’m particularly interested in these topics:

Adverse event reporting,

Interoperability standards,

Meaningful Use program’s future, and

Usability.

Looking at the agenda, I should stay busy with one exception. There isn’t much on usability. The word’s only on the agenda once. Not a surprise since ONC has pretty much relinquished any role to the vendors.

How important do you think the ONC meeting and also the ONC run Healthdatapalooza now that meaningful use has kind of run its course? Will these two meeting gain steam and influence or will organizations start to go other places? I’ll be interested to watch that trend as I attend the event.

If you can’t attend, you can follow on various webcasts and twitter. If you do plan to attend, I’d love to see you there. To email me, click on my name in my profile blurb, or at carl@ehrselector.com.

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I’ve been covering a lot of wearables and sensors over on Smart Phone Healthcare through the years. It’s been great to see the evolution and I still think we’re just at the very beginning of what is going to be possible with these health sensors. However, the leaks in the damn are starting to appear and soon we’ll have a tidal wave of amazing health data from these health sensors.

Don’t believe me? Check out this story on Gizmodo about a Rub On Tattoo that measures a person’s blood glucose levels. For those too busy to click over, here’s an excerpt:

Pricking your finger for a blood glucose test will never, ever be fun. Thankfully, scientists have been hard at work on a bloodless and needleless alternative: a rub-on temporary tattoo that, as weird as it sounds, gently sucks glucose through the surface of the skin.

The thin, flexible device created by nanoengineers at UCSD is based on the much bulkier GlucoWatch, a now-discontinued wristband that worked through the same glucose-sucking principal. But the electric current GlucoWatch used to attract glucose to the surface of the skin was too high, and wearers were not keen on the discomfort. This temporary tattoo gets around the problem by using a gentler but still effective current.

Unfortunately, we’re still a few years out from this becoming a market ready product, but it’s another illustration of the kind of research and ingenuity that’s being put into the health sensors marketplace. I’m personally concerned about my risk for diabetes, and so I’m extremely excited about new developments around diabetes. However, this is just one of many more developments that are going to change the world of healthcare as we know it.

What do you think of this new wave of sensors? How will the medical establishment integrate all this new data? What other changes are happening which we should keep an eye on? I don’t think most doctors, practices, hospitals, EMR companies, etc are ready for what’s happening.

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

As I described in my first blog post on Adverse Events, these reports are both a record of what went wrong and a rich source for improving workflow, process and policy. They can nail responsibility not only for bad acts, but also bad actors and can help distinguish between the two. The FDA gathers AE reports to look for important health related patterns, and if needed to trigger recalls, modifications and public alerts.

EHRs generate AEs, but the FDA doesn’t require reporting them. Reporting is only for medical devices defined by the FDA and EHRs aren’t. However, users sometimes report EHR related AEs. Now, there’s proposed legislation that would preclude EHRs as medical devices and stop any consideration of EHR reports.

MEDTECH Act’s Impact

EHRs are benign software systems that need minimal oversight. At least that’s what MEDTECH Act’s congressional sponsors, Senators Orrin Hatch (R- Utah) and Michael Bennett (D- Colorado) think. If they have their way – and much of the EHR industry hopes so – the FDA can forget regulating EHRs and tracking any EHR related AEs.

EHRs and Adverse Events

Currently, if you ask MAUD, the FDA’s device, adverse event tracking system about EHRs, you don’t get much, as you might expect. Up to October, MAUD has 320,000 AEs. Of these about 30 mention an EHR in passing. (There may be many more, but you can’t search for phrases such as “electronic health,” etc.) While the FDA hasn’t defined EHRs as a device, vendors are afraid it may. Their fear is based on this part of the FDA’s device definition standard:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

…[I]ntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals…

I think this section clearly covers EHRs. They are intended for diagnostic, cure, mitigation, etc., of disease. Consistent public policy in general and a regard for protecting the public’s health, I think, augers for mandatory reporting of EHR caused AEs.

Why then aren’t EHRs devices that require AE reporting? In a word, politics. The FDA’s been under pressure from vendors who contend their products aren’t devices just software. They also don’t want their products subject to being criticized for failures, especially in instances where they have no control over the process. That may be understandable from a corporate point of view, but there are several reasons for rejecting that point of view. Consider what the FDA currently defines as a medical device.

Other Devices. The FDA captures AE reports on an incredible number of devices. A few examples:

Blood pressure computers

Crutches

Drug dose calculators

Ice bags

Lab gear – practically all

Robotic telemedicine devices, and many, many more.

ECRI on EHR Adverse Events

The respected patient safety NGO, the ECRI Institute, puts the issue squarely. Each year, it publishes its Top Ten Health Technology Hazards. Number one is inadequate alarm configuration policies and practices. Number two: “Incorrect or missing data in electronic health records and other health IT systems.” Its report says:

Many care decisions today are based on data in an electronic health record (EHR) or other IT-based system. When functioning well, these systems provide the information clinicians need for making appropriate treatment decisions. When faults or errors exist, however, incomplete, inaccurate, or out-of-date information can end up in a patient’s record, potentially leading to incorrect treatment decisions and patient harm. What makes this problem so troubling is that the integrity of the data in health IT (HIT) systems can be compromised in a number of ways, and once errors are introduced, they can be difficult to spot and correct. Examples of data integrity failures include the following:

Appearance of one patient’s data in another patient’s record (i.e., a patient/data mismatch)

Clock synchronization errors between different medical devices and systems

Default values being used by mistake, or fields being prepopulated with erroneous data

Inconsistencies in patient information when both paper and electronic records are used

Outdated information being copied and pasted into a new report Programs for reporting and reviewing HIT-related problems can help organizations identify and rectify breakdowns and failures.

ECRI spells out why AE reporting is so important for EHRs:

…[S]uch programs face some unique challenges. Chief among these is that the frontline caregivers and system users who report an event—as well as the staff who typically review the reports—may not understand the role that an HIT system played in an event…

Most industry chatter about the act has been its exempting EHRs and others from the ACA’s medical device tax. However, by removing FDA’s jurisdiction, it would also exempt EHRs from AE reports. Repealing a tax is always popular. Preventing AE reports may make vendors happy, but clinicians, patients and the public may not be as sanguine.

The act’s first two sections declare that any software whose main purpose is administrative or financial won’t come under device reporting.

Subsection (c) is the heart of the act, which exempts:

Electronic patient records created, stored, transferred, or reviewed by health care professionals or individuals working under supervision of such professionals that functionally represent a medical chart, including patient history records,

Subsection (d) says that software that conveys lab or other test results are exempt.

There are several problems with this language. The first is that while it goes to lengths to say what is not a device, it is silent about what is. Where is the line drawn? If an EHR includes workflow, as all do, is it exempt because it also has a chart function? The bill doesn’t say

Subsection (d) on lab gear is also distressing. Currently, most lab gear are FDA devices. Now, if your blood chemistry report is fouled by the lab’s equipment ends up harming you, it’s reportable. Under MEDTECH, it may not be.

Then there’s the question of who’s going to decide what’s in and what’s out? Is it the FDA or ONC, or both? Who knows Most important, the bill’s negative approach fails to account for those AEs, as ECRI puts it when: “Default values being used by mistake, or fields being prepopulated with erroneous data.”

Contradictory Terms

The act has a fascinating proviso in subsection (c):

…[P]rovided that software designed for use in maintaining such patient records is validated prior to marketing, consistent with the standards for software validation relied upon by the Secretary in reviewing premarket submissions for devices.

This language refers to information that device manufacturers file with HHS prior to marketing. Oddly, it implies that EHRs are medical devices under the FDA’s strictest purview, though the rest of the act says they are not. Go figure.

What’s It Mean?

The loud applause for the MEDTECH act coming from the EHR industry, is due to its letting vendors off the medical device hook. I think the industry should be careful about what it’s wishing for. Without effective reporting, adverse events will still occur, but without corrective action. In that case, everything will seem to go swimmingly. Vendors will be happy. Congress can claim to being responsive. All will be well.

However, this legislative penny in the fuse box will prove that keeping the lights on, regardless of consequences, isn’t the best policy. When something goes terribly wrong, but isn’t reported then, patients will pay a heavy price. Don’t be surprised when some member of Congress demands to know why the FDA didn’t catch it.

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Lately, there’s been a lot of debate over whether data from wearable health bands is useful to clinicians or only benefits the consumer user. On the one hand, there are those that say that a patient’s medical care could be improved if doctors had data on their activity levels, heart rate, respirations and other standard metrics. Others, meanwhile, suggest that unless it can be integrated into an EMR and made usable, such data is just a distraction from other more important health indicators.

What hasn’t come up in these debates, but might far more frequently in the future, is the idea that health band data can be used in personal injury cases to show the effects of an accident on a plaintiff. According to Forbes, a law firm in Calgary is working on what may be the first personal injury case to leverage smart band data, in this case activity data from a Fitbit.

The plaintiff, a young woman, was injured in an accident four years ago. While Fitbit hadn’t entered the market yet, her lawyers at McLeod Law believe they can establish the fact that she led an active lifestyle prior to her accident. They’ve now started processing data from her Fitbit to show that her activity levels have fallen under the baseline for someone of her age and profession.

It’s worth noting that rather than using Fitbit data directly, they’re processing it using analytics platform Vivametrica, which uses public research to compare people’s activity data with that of the general population. (Its core business is to analyze data from wearable sensor devices for the assessment of health and wellness.) The plaintiff will share her Fitbit data with Vivametrica for several months to present a rich picture of her activities.

Using even analyzed, processed data generated by a smart band is “unique,” according to her attorneys. “Till now we’ve always had to rely on clinical interpretation,” says Simon Muller of McLeod Law. “Now we’re looking at longer periods of time to the course of the day, and we have hard data.”

But even if the woman wins her case, there could be a downside to this trend. As Forbes notes, insurers will want wearable device data as much as plaintiffs will, and while they can’t force claimants to wear health bands, they can request a court order demanding the data from whoever holds the data. Dr. Rick Hu, co-founder and CEO of Vivametrica, tells Forbes that his company wouldn’t release such data, but doesn’t explain how he will be able to refuse to honor a court-ordered disclosure.

In fact, wearable devices could become a “black box” for the human body, according to Matthew Pearn, an associate lawyer with Canadian claims processing firm Foster & Company. In a piece for an insurance magazine, Pearn points out that it’s not clear, at least in his country, what privacy rights the wearers of health bands maintain over the data they generate once they file a personal injury suit.

Meanwhile, it’s still not clear how HIPAA protections apply to such data in the US. When FierceHealthIT recently spoke with Deven McGraw, a partner in the healthcare practice of Manatt, Phelps & Phillips, she pointed out that HIPAA only regulates data “in the hands of, with the control of, or within the purview of a medical provider, a health plan or other covered entity under the law.” In other words, once the wearable data makes it into the doctor’s record, HIPAA protections are in force, but until then they are not.

All told, it’s pretty sobering to consider that millions of consumers are generating wearables data without knowing how vulnerable it is.

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of EHRSelector.com, a free service for matching users and EHRs. For the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manger doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst.

Eric Duncan’s Ebola death in Dallas was, to say the least, an adverse event (AE). Famously now, when he had a high fever, pronounced pain, etc., he went to Texas Health’s Presbyterian Hospital’s ER, and was sent home with antibiotics. Three days later much worse, he came back by ambulance.

In the aftermath of Duncan’s death, the hospital’s EHR, EPIC, came in for blame, though it was later cleared. Many questions have come from Duncan’s death including how our medical system handles such problems. Articles often use the term adverse event, but rarely mention reporting. I think it’s important to take a direct look at our adverse event reporting systems and where EHR and AEs are headed. This blog post looks at AE systems. The next will look at where EHRs fit in.

The FDA: Ground Zero for Adverse Event Reports

HHS’ Food and Drug Administration has prime, but not exclusive, jurisdiction over adverse reports breaking them into three classes:

Medicines

Medical Devices, and

Vaccines.

Four FDA systems cover these classes:

FAERS. This is FDA’s system for drug related adverse reports. It collects information for FDA’s post marketing for drug and biologic product surveillance. For example, if there’s a problem with Prozac, it’s reported here.

MAUDE. The Manufacturer and User Facility Device Experience reporting system. If an X-Ray machine malfunctions or lab equipment operates defectively, this is where the report goes.

MEDSUN. This is voluntary, device reporting system gathers more detailed information than MAUD. It’s run by as a collaboration of the FDA and several hundred hospitals, clinics, etc. (Disclosure: My wife was MAUD project system developer.) MEDSUN captures details and incidents, such as close calls or events that may have had a potential for harm, but did not cause any. MEDSUN has two subsystems, HeartNet, which is for electrophysiology labs and KidNet for neonatal and pediatric ICUs.

MEDSUN Reporting Poster

State Adverse Event Reporting Systems

Several states require Adverse Event reporting in addition to FDA reports. Twenty-seven states and DC require Adverse Event reports, with varying coverage and reporting requirements. Some states, such as Pennsylvania, have an extensive, public system for reporting and analysis.

Patient Safety Organizations

Added to federal and state organizations are many patient safety organizations (PSOs) with an Adverse Event interest. Some are regional or state groups. Others, are national non profits, such as the ECR Institute.

The Safety Reporting Paradox

If you delve into an Adverse Event reporting systems, you’ll quickly see some institutions are more present than others. That doesn’t necessarily mean they are prone to bad events. In fact, these may be the most safety conscious who report more of their events than others. Moreover, high reporters often have policies that encourage AE reporting to find systemic problems without punitive consequences.

Many safety prevention systems work this way. Those in charge recognize it’s important to get all the facts out. They realize adopting a punitive approach drives behavior underground.

For example, the FAA has learned this the hard way. Recently on vacation, I met two air traffic controllers who contrasted the last Bush administration’s approach to now. Under Bush’s FAA errors were subject to public shaming. The result was that many systemic problems were hidden. Now, the FAA encourages reporting and separates individual behavior. The result is that incidents are more reported and more analyzed. If individual behavior is culpable, it’s addressed as needed.

In the next part, I’ll look at how EHRs fit into the current system and the congressional efforts to exempt them from reporting AEs, a move that I think is akin to putting pennies in a fuse box.

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

It’s little wonder. After a few years of uncertainty, it seems pretty clear that the wearables market is taking off like a rocket. In fact, 21% of US consumers own such a device, according to research by PricewaterhouseCoopers. That’s slightly higher that the number of consumers who bought tablets during the first two years after they launched, PwC reports. Not only Microsoft, but Apple and Samsung, as well as smaller players with a high profile — such as Fitbit — are poised to take the sector by storm.

Microsoft’s new entry is called Microsoft Health, a platform letting users store health and fitness data. The date in question is collected by a Microsoft Health app, available on Android, iOS and Windows Phone. The platform also gathers data generated from the Microsoft Band, a smart and designed to work with Microsoft’s new platform.

The idea behind pulling all of this data into a single platform is to integrate data from different devices and services in a smart way that allows consumers to generate insights into their health. The next step for Microsoft Health, execs say, is to connect all of that data in the platform to the tech giant’s HealthVault, a Web-based PHR, making it easier for people to share data with their healthcare providers.

Other tech giants are making their own wearables plays, of course. Google, for example, has released Google Fit, a fitness-based app designed to help users track physical activity. Google’s approach is Android smart phones, relying on sensors built into the smart phones to detect if the user is walking, running or biking. Users can also connect to devices and apps like Noom Coach and Withings.

Apple, for its part, has launched HealthKit, its competing platform for collecting data from various health and fitness apps. The data can then be accessed easily by Apple users through the company’s Health app (which comes installed on the iPhone 6.) HealthKit is designed to send data directly to hospital and doctor charts as well. It also plans to launch a smart watch early next year.

While there’s little doubt consumers are interested in the wearables themselves, it’s still not clear how enthusiastic they are about pulling all of their activity onto a single platform. Providers might be more excited about taming this gusher of data, which has proved pretty intimidating to doctors already overwhelmed with standard EMR information, but it remains to be seen whether they’ll find fitness information to be helpful.

All told, it looks like there will be a rollicking battle for the hearts and minds of wearables consumers, as well as the loyalty of providers. As for me, I think it will be a year or two, at minimum, before we get a real sense of what consumers and providers really want from these devices.

John Lynn is the Founder of the HealthcareScene.com blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of InfluentialNetworks.com and Physia.com. John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

On my ride to the airport after the Dell Healthcare Think Tank event, we had an interesting and engaging conversation about the FDA when it comes to EHR software. Some of the discussion was around whether the FDA would start regulating EHR software.

Shahid Shah suggested that it was extremely unlikely that the FDA would touch EHR software at least until meaningful use was complete and the current President was out of office. He rightfully argues that this administration has hung their hat on EHR and the FDA wasn’t going to step in and stop that program. Plus, Shahid suggested that ONC wouldn’t let the FDA do it either. Janet Marchibroda from the Bipartisan Policy Center was hopeful that Shahid was right, but wasn’t as confident of this analysis.

After hearing them discuss this, I asked them the question:

What would happen to the EHR Market if the FDA started regulating EHR?

Shahid quickly responded that the majority of EHR vendors would go out of business and only a small handful of companies would go through the FDA clearance process. Then, he suggested that this is exactly why the FDA won’t regulate EHR software. FDA regulation of EHR would wipe out the industry.

This is a really interesting question and discussion. The reality is that there are a lot of similarities between EHR software and medical devices. One could make a really good case for why the FDA should regulate it like medical devices. One could make a case for the benefit of some rigor in the development of EHR software. However, there’s no appetite for such a change. In fact, the only people I’ve seen calling for it are those who think that EHR is unusable and potentially harmful to patients. I’m not sure FDA regulation will make them more usable though.

Now, juxtaposition the above conversation with this post by William Hyman titled “A Medical Device Recall of an EHR-like Product” In this case, the FDA announced McKesson’s voluntary recall of it’s Anesthesia Care system. This software was tightly integrated with other FDA regulated medical devices. I wonder what this means for other EHR software that is starting to integrate with a plethora of FDA cleared medical devices and other non FDA cleared medical devices.

I’m personally with Shahid in that I don’t think the FDA is going to touch EHR software with a long pole. At least, not until after meaningful use. After meaningful use, I guess we’ll see what they decide to do.