1. HIMSS 2012 is focusing on mHealth with several sessions and will have a kiosk on the vendor floor which features speakers on the mobile aspect of healthcare
2. AAMI has published in their IT World column a synopsis of mHealth (requires login credentials)
3. Here in Europe, the Mobile World Congress, Barcelona Feb 2012, sponsored by the GSM Association, has a track devoted to mHealth (filter for Mobile Health), a day of demonstrations and a specific plan on embedded mobile medical functionality.
4. Additionally, the FDA has come out with draft guidance and has promised final guidance regarding mobile medical apps.  The European Commission has entered into an MOU with the HHS to work together on the regulatory aspects of healthcare.  I wouldn’t be surprised if they come out with similar regulatory guidance regarding mHealth as that promulgated by the FDA.
5. Lastly, from a market perspective, “The mobile health market has a year-over-year growth rate of around 17% since 2010 and is estimated to be worth $2.1 billion at the end of 2011. The report also said the mobile health market is expected to grow …. nearly 22% from 2012 to 2014.”

One might ask, what is mHealth?  It has many different definitions and from a product offering perspective could range from texting information on a mobile phone to a provider and/or specifying a provider geographical location to a patient to bi-directional interaction with a medical device to/from an electronic medical record application via mobile phone or telecommunications frequencies (or the medical device could be embedded with the mobile telecommunication appliance).  As with the traditional Healthcare industry, as one progresses up the interaction functionality chain, the design and interoperability gets more complex.  Most of the latest news items I read about successful mHealth applications describe the ‘easier’ applications:  texting, scheduling, location, etc.  There is still growth and development in the marketplace for interactive medical-device integrated/connected products.  Additionally, from a market perspective, most of the current product offerings are proprietary in nature and vertically integrated.

Mobile telecommunication vendors are keenly interested in providing for the healthcare market.  They are closely watching as well as working to influence the regulatory environment.  From a provider perspective, this means adding another large player to the mix.  You may already provide some internal mobile telecommunications support, but providing healthcare monitoring over that infrastructure changes the rules of the game.  In addition, the mobile telecommunications market plays to the consumer market, which has faster turnaround times, and higher customer expectations.  The consumer market expects the ability to smoothly transition service when changing a ‘product provider.’  In addition, with social media, the pressures are higher; witness the recent policy and product turnaround of Verizon to a charge for customers using a specific billing mechanism.  The healthcare provider is not used to this type of oversight or pressure yet.

Down in the healthcare provider trenches, testing remote monitoring and the use of mobile telecommunications offerings continues.  Here in Europe there are two larger projects that are interested in demonstrating the efficacy of remote monitoring.  One, the Whole System Demonstrator based in England and their National Health System (NHS),  has just published its preliminary results.  Another, Renewing Health, is based on a nine European country pilot for remote monitoring of chronic diseases. In the case of the Whole System Demonstrator, initial results have been very positive for the clinical outcomes regarding the use of remote monitoring models for chronic disease management with a “15% reduction in A&E visits, a 20% reduction in emergency admissions, a 14% reduction in elective admissions, a 14% reduction in bed days and an 8% reduction in tariff costs” along with a “45% reduction in mortality rates.”

Renewing Health is still in its trial period, however, the initial technical results have been published.  A basic summary of the technical aspects of the nine solutions follows:

1. All pilots sites used proprietary solutions,
2. The most widely used standards were protocol and telecommunication standards, but even with some of those standards, there were issues with product development and rol-lout.  This has resulted in some technology system re-design as well increased expenditure on patient education.
3. Moreover, the market has dealt some variables, by either not continuing distribution of a mobile phone model or changing the implementation of a medical device transport protocol.  Additionally, intermittent wireless coverage and/or limited bandwidth for a teleconferencing function have led to design changes or required infrastructure upgrades.
4. The market has a dearth of standards-based products for purchase.  In Europe this is complicated by language requirements (most of the countries have healthcare systems which specify that products be purchased which have markings and documentation in their national language – this is for ease of use as well as cultural preservation goals).
5. Another big issue is system ergonomics with respect to patient cohort.  Mobile phones with small screens and small input interfaces (small mobile phone keyboards) don’t work well with more elderly patients.

This project will be ongoing until 2013 and at the end the results are hoped to strengthen the hypothesis that well designed remote monitoring programs for chronic disease management is as or more effective than care delivered in the traditional manner.  There should also be some interesting results from a technical perspective.  The market is slowly moving towards providing more standards-based products, however, for the purposes of this project, timing did not allow more adoption of those types of products.

So, with all of the activity described above what should healthcare providers do?  I suggest the following:

1. Keep current on the mobile telecommunications arena both in product offerings and regulatory oversight.  With the MDDS and the draft mobile medical apps guidance, the FDA has signaled they will be interested in regulating some aspects of healthcare delivery.   If you as a healthcare provider adopt mHealth solutions, this will increase the complexity of providing and servicing/maintaining healthcare products from the provider.  You control your enterprise, but as the information goes outside the enterprise to the shared infrastructures, you lose that control.  Therefore, you may not be able to guarantee the types of performance or response that may be the norm within your enterprise.  Agreements with the third party infrastructure entities will become paramount to ensure good performance and in the end good relationships with your customers:  the patients and clinicians.  Moreover, in light of the recent FDA guidance, understanding the infrastructure path of your mHealth solutions so that you meet any regulatory burden will become even more important as you embark outside of your enterprise.
2. Consider specifying standards for data and communication across each interface (example: Continua Guidelines, IHE-PCD) in your acquisition documents.  As with traditional medical device connectivity in your enterprise, the more you can decouple the medical device choice from the other parts of a connectivity solution, the more flexibility you have to make decisions based on the quality of the different parts of the system.  In the future, this may avert having to redesign, augment and/or replace the whole system from medical device to electronic medical record application due to a technology refresh of one of the manufacturers in the system.
3. Providers are under a lot of pressure to control healthcare costs in all parts of the world.  As remote monitoring pilot results become more prevalent, it will be expected that providers adopt some of these mobile health solutions.  Timing of your adoption will become very important as this is a fast moving train.  The product cycles for mHealth can be 6 months to 1 year.  This is much faster than your usual IT infrastructure refresh cycle which is already faster than your medical device/technology refresh cycle.  Although many of the traditional medical device companies are migrating to a software based solution and a refresh cycle similar to that in the IT industry, they may not be as ready for the mHealth refresh frequency cycle.  This may slow down in the US and Europe due to more regulatory oversight, however, the development outside those areas of the world does not have as much regulatory oversight, so some of the more interesting products may be developed outside of the geographical areas we’ve become accustomed to in the US and Europe.  If you have a ‘wandering clinician’ or patient, they may be the one who introduces or demands a specific functionality to your enterprise from their wanderings.
4. If your mHealth solution implementation is successful, be prepared to expand.  It is estimated that 80% of healthcare costs are borne by 20% of the population and most of this is due to the management of chronic diseases.    Remember, as with most endeavors, more is demanded of you once you succeed.

So is 2012 the year of mHealth?  Perhaps.  If anything, it will be another exciting year for mobile technology and the convergence of the consumer and healthcare industries.  It will be bumpy, but in the end, it should be better for the consumer who usually also happens to be the patient.

Bridget A. Moorman, CCE, is president of BMoorman Consulting, LLC, providing consulting to healthcare providers, standards promulgation organizations and medical device and information technology companies regarding their medical device integration strategies.  She can be reached via email  or at her website.

Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.

•    Most implementations up to now have been in very specific care areas such as the ICU and OR.

•    Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.

•    In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators – but vents to a much lesser degree than monitors.

•    In the OR, the key devices are typically patient monitors and anesthesia/gas machines.

•    Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.

•    For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.

•    The device workflow – that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7.  Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.

But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are now starting to look beyond departmental connectivity solutions (i.e. the tactical approach) and are now evaluating their enterprise needs. Looking at an entire healthcare enterprise requires a more comprehensive evaluation of the healthcare organizations’ goals and requirements – and this requires more strategic thinking and planning in a number of areas. Hospitals that attempt to extend their departmental connectivity strategies and technology platforms in ad-hoc fashion, will hit the wall at some point. And in the end, I believe those hospitals will likely spend a lot more time and resources (not to mention money) unwinding what they have in place in order to achieve the level of results that most hospitals are looking for.

In the past, patients on general medical-surgical floors did not have biomedical devices. But over the past five to ten years, the acuity level of general ward patients in many hospitals has increased significantly. Now these patients often have one or more IV pumps and patients are always at least periodically monitored via spot check monitoring every 2-4 hours. And there is a shift towards continuous monitoring in the general ward, mainly to provide caregivers an early warning of rapid decline in state. Rapid response teams are being formed in many hospitals as a means for dealing with early intervention to prevent patient crashes. In all of these cases, the connectivity requirements are distinctly different as compare to a high-acuity (i.e. ICU) environment.

I am beginning to see more and more hospitals recognize this situation, and as a result they are starting to assess connectivity requirements across their entire healthcare enterprise. In addition to increasing acuity levels across all care areas, hospitals are also thinking about some of the challenges around their EMR. Many institutions have one main EMR vendor but many of them have to also deal with the fact that they have several “point EMR solutions” in specialty areas. For example, many times a hospital will have a different vendor in the OR for the anesthesia charting application, and another in the ED for emergency department management. This adds both complexity and confusion for the hospital trying to evaluate their medical device connectivity options, mainly because their departmental applications often come with their own niche solution for solving device connectivity in the specialty care environment.

There are three main use models or categories of medical devices and this has an impact on the connectivity solution and workflow.

•    Category #1 includes the fixed devices – such as anesthesia machines in the OR, or a patient monitor mounted to the wall in a patient’s ICU room. These devices are not going anywhere so managing connectivity tends to be a little easier (sometimes via networks gateways).

•    Category #2 includes devices that can move from patient to patient periodically, but once moved, they remain with the new patient until the patient is transferred or discharged. These would be devices like patient-worn telemetry, IV pumps, and ventilators.

•    Category #3 is transient devices that come and go and move from patient to patient on a frequent basis. Unlike category 1 and 2, these devices could contain data for more than one patient. Examples of these include POC blood testing devices and vital signs spot check monitors used on general medical-surgical floors.

Hospitals are also starting to recognize that there are workflow and patient safety implications — i.e. data from a medical device going to the wrong patient’s record, or alarms from a device not getting to the appropriate caregiver.  Perhaps the largest area for potential gains in both workflow and patient safety can be realized by implementing common methods (the workflow steps) for managing the clinician interaction with medical devices, regardless of device type, make/model, category (as described above), or care environment. The process of managing patient ID and association to medical devices is one key area where standardization needs to be thought about and planned for.

For all of these reasons, hospitals have started to realize that implementing connectivity from separate vendors in different care areas (depending on which vendor application is installed in that particular care area), is a recipe for lots of problems. And this practice will only make it harder and ultimately much more expensive to create any standardization when the hospital is ready.

Here is an analogy that may resonate with some of you. Think of how many remote controls you have on your coffee table at home and how problematic it is to train someone unfamiliar with your equipment and setup – just to watch a basic cable-TV program. Perhaps you have addressed this problem and made life easier by investing in a good universal remote? If you did, then you would have realized that the end result is easier training, less steps (think workflow), and less mistakes. And I am only talking about something as simple (or should be anyway) as your home audio-video equipment. Now think about how non-standard all of the bedside equipment is and how the clinical staff can function without making mistakes.

I would be interested in knowing what hospitals are doing to look at connectivity more strategically and how they are going about assessing their situation and requirements. Let me know what you think?

Medical device interoperability and standardization is a hot topic, and with the efforts surrounding adoption of the 11073 standard, IHE and patient care device frameworks, and the drive towards implementing electronic medical records, the field has become essential to the future of the healthcare industry. Yet, as we look to realign medical devices and their communication mechanisms away from proprietary intercommunication and towards standards-based communication, we should think “outside the box” to other fields, technologies and technical disciplines for inspiration and guidance on best practices. Perhaps an obvious one that comes to mind is the USB 2.0 standard. The simple idea being proffered is the ability to plug a medical device into a computing platform and have it recognized and joined automatically to the operating system. While we are a long way from this vision as a universal standard, there is ample evidence to demonstrate its feasibility in the existing Windows and MAC OS architectures today.

Driver Bundling

Key to the seamless and universal use and acceptance of USB devices is the bundling of device drivers delivered as part of base operating systems. When a new device is developed, it could be adopted for incorporation within the base Windows and Mac operating system environments. However, even before that adoption, manufacturers of these drivers could consider bundling them as part of hardware delivery. The drivers could be installed at run time or prior to usage and, from there, no other special attention would be required: attaching a medical device to an accompanying computing platform would automatically result in that device “joining” with the base operating system. The challenge, of course, is how best to develop drivers that support consistent and common access to data. While the common Patient Care Device (PCD) framework fosters such an idea, it has yet to be realized as a universal standard.

One theme embodied by the IHE medical device connectivity demonstrations featured at HIMSS 09 (pdf) in Chicago was that of following a patient from admission through a critical care room, in which patient information was gathered at the bedside from and to the various medical devices present there, including infusion, bed, monitor, and mechanical ventilation. The ability to collect and integrate these data into a bedside electronic health record was accomplished in concert among the several medical device manufacturers through access to the communication frameworks peculiar to the many vendors participating in the demonstration. The bundling of device drivers and publishing of a common syntax required to communicate with the various devices could provide a starting point for enabling universal biomedical device communication.

It’s about the patient

One possible approach to embrace is the concept of open source development to support creation of such driver bundles. Of course, device manufacturers will have to go along with this approach. But, I believe it is key to recognize that providing access to information seamlessly ultimately enhances business cases.

To maintain restrictions on access under burdensome license agreements may, in the short term, seem to protect the intellectual property base. Yet, this misses a much larger opportunity: it is not about access to the data, it is about what those data do and how they can be used to support and guide the treatment of the patient clinically. This is the proverbial low-hanging fruit.

The access to the data through hardware ports is a distraction that we must get past, collectively, as an industry. Restricting or limiting access to data impacts the healthcare organization but also constrains the ability of a medical device hardware manufacturer to expand into the larger environment that is the healthcare enterprise. The “commoditization” of the medical device interface is precisely the wrong model we should be promoting–it’s about the patient and the data brought to bear to make clinical decisions that will be of ultimate benefit.

Open-source frameworks

To this end, one possible “model” would be to create an open-source framework analogous to existing open software development frameworks that could be managed or licensed in a manner comparable to GPL. Now, the challenges are clearly there: how do you control, test, qualify, certify, regulate, and secure such software? All valid and important questions. Yet, let’s not dismiss the approach out of hand.

Existing regulatory mechanisms for certifying software exist and can be extended to ensure that appropriate quality controls are applied to such software and device drivers. Controlled development, deployment, and evaluation of software related to medical devices is certainly more challenging because of the very nature and use of those software applications. The development of the drivers themselves and their “care and feeding” can be guided in accord with quality control mechanisms already in place and maintained by individual manufacturers. But, the use of those drivers, their access, and the ability to suggest customization could be in the purview of the open source community. This would not only assist in development, but would also cause the acceleration of key features leading to better, more functional interface products.

Ideation

Having worked in the medical device, healthcare, and other commercial industries these past 24 years I do not come to these suggestions naively. I, too, have developed and brought medical devices to market and have experienced my fair share of the complexities involved, including issues surrounding quality and regulatory certification. The model that allows any device to be identified by simply plugging it into a base operating system makes logical sense and is a growing trend. Furthermore, by employing simple and common query and response syntax (perhaps rudimentary english commands), device information could be retrieved without relying on proprietary commands. This vision, I believe, is key to this evolving field and is necessary to support the larger ideas of personalized medicine and patient-centric healthcare that must come about in order to improve the overall quality of patient care.

Just what is a medical device? The legal definition of a medical device is,

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

• recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, [i.e., a drug]
• intended 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, or
• intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.

According to the New Oxford American Dictionary, a contrivance is “a thing that is created skillfully and inventively to serve a particular purpose.” So a medical device can be made out of anything, as long as it falls under at least one of the three bullets above.

Who Is Impacted?

The first group are those  targeting remote monitoring and Healthcare Unbound applications, many of which are facing the FDA for the first time (see the membership roster of the Continua Health Alliance for examples). These companies include wireless carriers, cell phone and consumer electronics manufacturers.

The  FDA’s proposed rule on Medical Device Data Systems (MDDS) impacts a different group.  This rule signals the market that the FDA is going to pursue enforcement against those that don’t comply with the regulations for certain types of medical devices. This includes any company that acquires data from medical devices that are used in the diagnosis and treatment of patients (health and wellness does not apply, but chronic disease management does). Also impacted by the MDDS rule are “secondary” alarm notification vendors and vendors providing surveillance and/or data integration of medical device data with data from other sources.

A brief email exchange with a contact at the FDA last week hinted that they’re busy working on either the final rule or another draft — either way the rule seems to be moving forward. You can read more about the proposed MDDS rule and what it means here.

The third major group potentially facing new regulatory hurdles are infrastructure vendors. Here the issues are mostly about how FDA regulations impact sales and marketing. Getting computers, networks and other products approved by the FDA is also an issue in some cases.

Amongst the first and second groups, there is a divide between vendors and health care provider organizations. The FDA can only regulate “manufacturers.” Qualifying as a manufacturer depends on what you do, rather than what you call yourself. Health care providers who do certain things risk being defined a manufacturer by the FDA.

Provider organizations sometimes “rolling their own” solutions. They write software from scratch, modify existing hardware and software products they’ve purchased, and sometimes modify or create medical devices. When these are unregulated systems (i.e., not medical devices), like patient accounting software, there’s no risk the FDA might show up for an impromptu inspection. But when those activities center around regulated medical devices, that’s a whole different story.

To date, the FDA’s used their regulatory discretion to ignore much of what providers do that might otherwise full under the FDA’s purview. Providers who make minor modifications or develop modest devices for their own use are at least risk of stirring up the FDA. A provider who heavily modifies life critical systems is at greater risk. Providers who make medical devices that they then sell or distribute in some way can expect a knock on the door. The big risk here is that the FDA can change their mind at any time and pursue enforcement actions against a provider — even retrospectively.

The  Problems

Manufacturers facing the prospect of FDA regulatory oversight have two main choices: get with the FDA’s program or withdraw their product. If their products are part of a multi vendor system they may find a third party who’s already regulated that can get regulatory approval. This third party must promote and sell the regulated system, although the original manufacturer could become a distribution channel for the regulated manufacturer. This third way results in lower regulatory costs and risk, but also lower revenue. Finding the right partner and structuring a deal that’s acceptable to everyone is the challenge.

If you provide just part of the solution, say a gateway, mobile phone, or network, what are your risks in being part of a regulated device, and what can you do to make yourself a more attractive supplier? Dealing with this scenario also means getting pretty deep into the FDA’s world. You may not submit products for regulatory approval, but your component customer will have other hoops for you to jump through.

A secondary but important problem revolves around the FDA’s regulations on how approvals are granted. Under the law, only one manufacturer can gain regulatory approval and sell the resulting solution. If you’re providing part of the overall solution that’s regulated, who assumes the regulatory burden and also gets to sell the solution? It is currently not possible to get regulatory approval as one part of a total solution. For example, in remote monitoring there are 3 market segments: sensors, gateway and information management system. The “product” is a system made up of all three. Some vendors do all three, and others specialize in just one or two segments. The ways out of these kinds of conundrums are neither obvious or straight forward.

Besides the fact that multi vendor solutions can only be sold by the  manufacturer who gets regulatory approval, a similar requirement applies to promotion and labeling.  Labeling includes what’s affixed to the product, product packaging, directions for use (DFU or user/service manuals) in addition to printed and electronic sales and marketing materials. Labeling can even extend to emails to customers and what comes out of sales reps mouths.

The regs state that only the vendor that gains regulatory approval for a medical device can market and sell it. Now this becomes an issue when the “device” is in fact a complex system using products as components from a multiplicity of manufacturers. Only one of those vendors that make up the regulated system can get approval to market and sell the system. If you’re a wireless LAN infrastructure vendor and want to market a (soon to be) regulated device like medical device connectivity or alarm notification, you can’t. Period. Not even as part of an “industry solution.”

Is your head spinning yet? While all of the above can be figured out for any given company or situation, the biggest problem here is that first timers to the FDA regulatory party lack lack both detailed knowledge of the regulations and a frame of reference for developing a regulatory strategy and making decisions on risk.

Solving the Regulatory Puzzle

Regulatory people, whether consultants or employees, are like lawyers. In fact many regulatory affairs folks are lawyers (not that there’s anything wrong with that). Presented with a problem, lawyers strive to formulate a solution that minimizes risk for their clients — with little or no regard for, you know, running a profitable business. Once you have your legal opinion, it is up to senior management to determine the level of risk the business is willing to accept in that situation. Sadly, there is no such thing as a risk-free world, even if you let lawyers run your company.

Regulatory affairs folks will seek solutions in much the same way as lawyers. Their goal is to minimize regulatory risk as much as possible. For example, one company facing FDA regulations has a large factory where only a very small portion is used to manufacture a product that may get regulated. They were told by a regulatory consultant that they would have to apply GMPs (good manufacturing processes, a part of the FDA regs) to the entire manufacturing plant — all the production lines, for every product line. That is a legitimate minimum-risk proposal, if not a very practical one.

Like legal risk, regulatory risk must balance compliance with the law and the practical demands of running a business. “The law is the law!” you may say. But like much of the law,  regulatory risk is not black and white. Nor are the FDA’s regulations prescriptive. The FDA is all about  systems and process that ensure safety and effectiveness, and not telling you how to run your business. How you meet the FDA’s regulatory requirements is variable. The FDA Modernization Act of 1997 includes provisions for supporting the “least burdensome approach” to major sections of the regulations.

Consequently, regulatory decisions require a frame of refererence that can balance risks to arrive at a decision that allows profitable operations without unduely risking the company. Organizations new to health care and FDA regulations lack the information necessary to make those risk trade off decisions.

It is important for companies to have someone who can identify the “absolute minimal risk.” This can be an outside consultant, an employee, or a contractor. Just as important, a company needs someone who can bring the company to a realistic balance between risk and practicality. In the example above, there is no explicit regulation that requires an entire factory floor conform to the regs because a part of that factory is used to make medical devices. An alternative solution (with little increase in risk) is to apply the GMP to just the production line that makes the regulated device, leaving the rest of the facility unchanged.

So how do you bring that balance between risk and practicality into the regulatory equation? These are clearly senior management level decisions. With experience running a regulated business, division or product line, this skill will accrue to your management team. Until you build up that experience, you can rent this skill. Any prospective regulatory consultants for this role must be experienced in “combination products,” systems made up of embedded devices, software running on general purpose computing platforms, and connectivity.

There are two temptations here to avoid. First, don’t place your regulatory affairs manager in both positions of defining “absolute minimal risk” and the approach that is the best balance between risk and practicality. The responsibilities of regulatory affairs will always steer them heavily towards the absolute minimal risk position (and that’s a good thing). It is also a temptation to hire a connectivity product manager and give them responsibility for ensuring regulatory decisions reflect the optimal risk/practicality balance. Because product managers have no real authority, these decisions will always end up with senior management who, when lacking sufficient regulatory experience, will take the safe route and side with regulatory affairs. Both of these approaches will increase your R&D costs and time to market, placing your company at a competitive disadvantage.

Regulatory Strategy

There’s a somewhat involved process in becoming regulated. You have to do things like register with the FDA as a manufacturer. Then you must define and then implement a bunch of specific policies and procedures throughout your company. If you already support some international quality system standard like ISO 9001, you’re probably more than halfway there. Regardless, you will need a business plan, budget, training, and monitoring to be ready for your first FDA inspection. These steps lay the foundation for doing business in a regulated environment.

While you’re laying your foundation, you’re going to need a regulatory strategy for each of your products. These strategies are implemented on top of your company wide regulatory foundation mentioned in the preceding paragraph. Product regulatory strategy is the balance between intended use (or marketing claims), product specifications, risk analysis and design approach. Product regulatory strategy  has a big impact not just on regulatory costs, but also overall product development costs and time to market.

Until things are worked out to better support the regulation of multi vendor system products (like the sensor/gateway/information system example above) you will need to work with your development partners or suppliers to craft a strategy that conforms to the current regulations. If you want a fancy name for this process, I like calling it a “regulatory business development strategy.” Here you work among the partners/suppliers of your system solution to shift the regulatory burden around and get alignment between that and your promotional plan. Whoever gets the regulatory approval is who gets to promote and sell the solution. But there is some wiggle room in certain situations where some of the marketing claims can be spread along with the regulatory burden.

UPDATE: According to mobihealthnews, the FDA’s Don Witters presented at TEPR+ this past February. Witters started the session with a definition of medical device. This was an early exchange as reported by Brian Dolan:

At times during the session, the tension in the room was palpable. Witters declared that the FDA has jurisdiction over any device that diagnoses, treats or prevents a disease. This led to one question from the audience: “So an MRI app for an iPhone is a wireless medical device? Or a patient reporting their blood glucose level by text messaging their physician who then adjusts their insulin dosage with a return SMS?” Witters initial response was “No, I think that’s getting into information exchange–that’s different.” After the questioner thanked him and said that people probably just breathed a sigh of relief, Witters doubled-back. “Well, I think the real answer is ‘We don’t know.’ That’s why I’m here today to begin this dialog and see where [the FDA] fits.” So, the FDA could really be interested in inspecting iPhones for use as “wireless medical devices”? You bet.

A determining factor for whether a device a regulated medical device is the intended use. Software that is intended to display and process MRI images for a radiologist to use to make a diagnosis are regulated medical devices. The ability to squirt a representative image to a referring physician (the doctor that order the exam) just for their info or for them to show their patient is not a medical device.

If a patient uses their cell phone to create and send an SMS to their doctor, the phone is clearly not a medical device, but a means for “information exchange.” But if the patient has a glucometer integrated with an iPhone where the software generates and sends data to the physician, the entire system is a medical device — including the software running on the iPhone. You can see more examples of how regulations might apply to the iPhone here.

Brian closes his post with this quote from Witters:

“When it comes to the FDA people think of us more like the IRS,” Witters said. “You don’t talk to the IRS unless they call you and then you call your lawyer or accountant or somebody. That’s not really the way systems work or ought to work. It should be a much more open process. It goes over the edge, though, when you start marketing [an unapproved wireless medical device] and it’s a money-making proposition and it has real issues with it. That’s where bad things start to happen.”

There is no one product that best fits every customer’s requirements, yet the goal of product management is to develop product requirements that addresses the greatest portion of the market possible. Of course, it is neigh impossible to create a solution that is optimal for every customer. This raises a couple interesting questions. For any given project, how much of the addressable market’s requirements can be met? How are such trade-offs made, and what is the role of sales in all this?

Security As a Requirements Trade-off Example

A good frame of reference for requirements trade-offs is wireless security for medical devices. There is a plethora of security standards, and the target is always moving; new standards are implemented, some of which have varying degrees of reverse compatibility with previous generations of hardware, and some require upgrades or replacements to work. Likewise, different markets have different requirements. For example health care has HIPAA, the credit card industry has the PCI data security standard, and other industries have their own requirements. Next, individual customers make security choices based on the infrastructure installed, how current their infrastructure is (is it currently sold by the vendor, is no longer sold but still supported, or is it discontinued), and what security standards they chose to adopt and enforce (sometimes chosen capriciously, often enforced vociferously) in their enterprise.

Like the workflow automation that wireless connectivity enables and the necessary security required to support it, there is a finite degree of requirements variability that can be practically implemented — systems can’t be everything to everyone. Creating a product that address 100 percent of the target market is virtually impossible. Trade-offs must be made so that a product can also reach cost of goods, design budget and time to market objectives.

The flip side of this is the fact that a product must offer a certain threshold of features if it is to meet the sales forecast associated with the R&D project. Much of the eventual success of a new product is dependent on the quality of trade-off decisions that are made. Following a certain process can increase the likelihood of good trade-off decisions that maximize your addressable market. First, a solid understanding of market requirements is needed. For workflow, use cases is frequently the best method for requirements gathering. Features like security can be gathered by straightforward research, customer surveys and interviews.

Requirements Variability: Trade-offs Done Right

In any requirements gathering effort, the majority of requirements will be found to apply to virtually the entire market. Also a subset of requirements will vary noticeably from site to site. This variability must be quantified if you hope to determine the percentage of addressable market available to your resulting product, i.e., the financial impact of your trade-off decisions. Many of these variable requirements can be realistically supported in the resulting product if they are properly identified (by designing in multiple ways to do things). Sometimes though, you have to draw the line and exclude certain options or features due to practical considerations – you know, like meeting budget and release dates.

These variable feature trade-offs are easier to make when you can show an association to the trade-off and the portion of the market that is impacted. A variable that affects 40 percent of your target market is probably hard to justify as a trade-off. But without the data — design and time to market impact on one hand, and how much of the addressable market is effected on the other — a rational trade-off decision becomes a guess. All too often, these decisions are poorly informed and the resulting product fails to meet forecast.

Sales Impact of Trade-offs

Sometimes these trade-offs become account qualification issues. In this case the prospect that requires a feature you traded-off becomes disqualified as a sales prospect. In other cases, the trade-off creates sales objections that must be overcome to win the sale. This is an important distinction that’s rarely identified and built in to launch plans, marketing and sales training. In the case with some connectivity features, overcoming the objection raised by the feature trade-off requires knowledge and expertise frequently not held by the sales rep. These situations require a sales support specialist.

Let’s look at wireless networking security for an example. A couple weeks ago I did a security workshop for a group that included several folks from the same medical device company’s R&D group. They had a released product with security features that was acceptable to 80 percent of their  addressable market. The remaining 20 percent were hospitals that had quirky or outdated security requirements that were traded-off by the vendor during the design process. At least some of these outlier requirements were traded-off, not because they were difficult to implement but because they were deemed insufficient to meet HIPAA security requirements by the industry in general (hint: here’s an example of leverage to overcome some unmet requirements as sales objections).

This R&D group is under pressure from sales and marketing to “fix” their product’s security so that it can also meet the requirements of this 20 percent of the market. After some discussion to dig into the details, it turns out that there are many different security features that made up 20 percent of outliers, and the cost to meet those requirements exceeded the budget available (not to mention opportunity costs).

More discussion revealed that security issues were a common sales issue across all the companies and industries represented in my workshop group. Best practices discussed for overcoming  security sales objections were early qualification and addressing the objection quickly in the sales process — often before a competitor can get in and muddy the water. Another best practice was using a resource to over come security objections that is knowledgeable enough to “speak the language” of IT security.

We determined that this medical device vendor didn’t so much have a feature shortfall, as their sales force lacked the resources with the appropriate knowledge to successfully overcome the objection. This company had a couple European based security experts in their R&D group that were frequently pulled to the field to overcome these objections worldwide. Needless to say, this was both expensive and often deprived R&D of this important resource.

Trade-offs and the Necessity of Sales Support

Lots of medical device vendors use application specialists to support the sales process. These are often clinicians who’ve gone to “the dark side” to do product demos and training. Health care IT vendors also make frequent use of application specialists, due to workflow complexity and specialization. Adding connectivity to a product creates similar needs for expertise that falls outside the sales rep’s sphere of knowledge. Networking, systems integration and security are three common technical areas where sales reps need support. Insufficient levels of support will negatively affect sales, specifically the percentages of deals won.

So, here are the take-aways:

1. When gathering requirements, identify those requirements that are variable across your market. Work those variables until you know just how variable they are, and have a handle on the major permutations.
2. Associate your variable requirements with addressable market. Like a lot of product management this is as much art as science — few have the budget or time to market to invest in developing statistically relevant data on each element of every variable requirement. Guessing or winging it is not art, just poor practice.
3. Now make informed trade-off decisions. Apply R&D and time to market estimates to the addressable market impact of specific variables. You rarely have the chance to recast your projects forecast numbers, so choose wisely.
4. Document the consequences of all trade-off decisions, especially those that impact how the product is best marketed and sold.
5. Be sure your marketing and sales training tackles both kinds of trade-offs, those that disqualify a prospect and those that need to be treated as sales objections.

For this discussion, interoperability refers to the ability of a medical device to be controlled by another medical device or third party information system. Medical device systems from a single vendor frequently include interoperability between the medical devices and applications running on general purpose computers, but since all the components are from the same vendor I’m excluding them from this discussion.

Like everything else, medical device interoperability will walk before it runs. In a recent comment, JimW suggests that MD FIRE’s focus is on driving the adoption of, “tightly coupled, low latency, deterministic connection[s].” I beg to differ; I found the MD FIRE text to be very general and that it avoided any kind of design solution whatsoever. Further, it is interesting that what little multi vendor interoperability that is actually on the market, is based on “tightly coupled, low latency, deterministic connection[s].” The example that comes to mind (actually the only one I can think of right now) is the use of CANopen to integrate radiographic equipment with contrast injectors in diagnostic imaging. Perhaps someone can provide additional examples.

Jim is right that such interoperability presents considerable product design and verification challenges, which is why I think that a different kind of interoperability will broad gain market traction before designs with tightly coupled deterministic connections. If you’ve heard Julian Goldman speak on this topic, he provides numerous examples of interoperability that revolve around simple safety interlocks like:

• Using a patient monitor to cease therapy delivery (and sound an alarm, of course) on a PCA pump when respiratory arrest is detected,
• Linking a heart lung machine and ventilator in surgery to ensure that one is turned on when the other is turned off, and
• Linking diagnostic imaging with a ventilator to ensure ventlation is restarted after it is stopped to reduce motion artifact during imaging.

A portion of the 500 patients who die unnecessary deaths every day in U.S. hospitals are killed because simple safety interlocks like these don’t exist. Why? Clearly such interoperability is not rocket science.

Barriers to Adoption

A conventional approach to interoperability (not to mention a lot of connectivity) is to create one-off systems integrations. For the patient monitor/PCA pump example above, this means that each individual patient monitor vendor must approach each individual PCA pump vendor and and negotiate an agreement where both vendors undertake a separate product development projects to design and test the required interoperability. Such an approach is crazy.

R&D Considerations

Let’s start with looking at potential impacts on R&D:

• Let’s say there are 3 patient monitor vendors and 3 PCA pump vendors, this equates to 18 R&D projects – 9 projects, each pairing 2 vendors, with two projects (one for each vendor) for each connection.
• Given that the technical demands of such an effort are pretty straight forward, let’s peg the cost at $1 million  per project, for a total R&D spend of $18 million. The first development effort of each vendor will cost more, but costs will go down for subsequent projects based on experience. The absence of industry standards means that each integration will be custom and unique; what could be done once with industry standards has to be repeated 18 times without standards.
• Time to market would be measured in years using the conventional approach. Each project will take 8 months, with no one vendor doing more than one project at a time (which means that no more than 6 projects can occur simultaneously, resulting in just 3 actual cross vendor integrations). This equates to a minimum elapsed time of 24 months, but more likely 36 to 48 months. Oh, and don’t forget the 4 to 6 months vendors will need to negotiate the terms of their collaborations before a product manager or engineer lifts a finger. That’s a minimum of an additional 15 months elapsed time.
• Medical device vendors rarely go back and do major R&D on existing products. Because a project like this would likely fall outside what a vendor would consider sustaining engineering, they would probably wait to undertake this interoperability project when they design a new product. The life cycle of medical devices is 5 to 7 years, and sometimes much longer. This reticence to make major enhancements to existing products exists for both pump and patient monitoring vendors. For the stars to align and result in an interoperability project, both vendors would have to have some degree of overlap in their new product development schedules. Fortunately, a vendor wouldn’t have to delay the launch of their new product by more than a year or so to include interoperability. Vendors have from time to time released new products with a basic feature set, and followed that up with additional features a year or two later. A two phase release would enable device vendors to begin to recoup their R&D investment while releasing the interoperability feature in a second release. So now the time to market estimated above is extended by additional years.
• Now that our patient monitoring and PCA pump vendors have one-off integrations (3 for each vendor in our example), let’s talk sustaining engineering for real. Every time a vendor changes their product, a risk analysis must be done to determine if the changes will impact the interoperability feature. (Potentially both the vendor making the change and the vendor on the other side of the integration could have to do a risk analysis, depending how their integration deal was structured, how they designed their feature, and how much they trust the other guy.) If they’re lucky, this risk analysis might result in one or both vendors having to repeat verification test of the safety interlock. Worst case, one or both vendors would have to modify the feature and do a new release. Remember, there are 18 halves of the 9 integrations that must be maintained and supported. If this feature was implemented only on new product releases, sustaining engineering projects will be more frequent, as they always are for brand new products. If the feature is added to a more stable and established product, sustaining would be less. Let’s guess another $2 to $5 million per interface half over 5 years, for a total sustaining cost of $36 to $90 million for all vendors. Gulp. This makes the initial R&D costs seem like a bargain.
• The final fly in this buggy R&D ointment is the question of vendor ROI. What kind of return could a vendor expect for enabling such an interoperable safety interlock? Remember the monetary value extracted from the customer has to be split between the two vendors. Can two separate vendors receive the same, more, or less value when the solution is split between two purchases? How does framing the sale primarily as an existing product replacement purchase compare to a buying a new patient safety capability impact the customer’s willingness to pay? These are difficult (and expensive) questions to answer with any certainty.

Regulatory Implications

Another important consideration is how cross-vendor interoperability would be regulated. Current law dictates that a single vendor must “own” the regulatory burden for the entire regulated device. No King Solomon “cutting the baby in half” here. While each vendor may develop their half of the interoperability, and both may verify and validate the entire resulting solution, only one vendor can assume the regulatory responsibilities and receive the approvals that enable them to make the marketing claims. This means that only one of the two vendors can promote and sell the resulting solution.

Distribution using a systems integrator to create the interoperability is problematic too. Each custom system integration would be a one-off medical device requiring each customer engagement to follow the FDA’s quality system regulation (QSR) and seek regulatory approval for each installation. This doesn’t seem very practical.

Summary

Current medical device vendor distribution strategies are designed for selling proprietary end to end solutions. Hospitals are notorious for preferring “single vendor solutions,” so would they accept buying pieces of a solution separately from vendors – not to mention receiving fragmented service and the inevitable finger pointing?

Other industries with similar distribution challenges use indirect channels, systems integrators or resellers, who represent products from numerous vendors that come together in broad based solutions. All this reminds me of the medical device dealers that were the predominate distribution model over 20 years ago.

An interesting problem, isn’t it? Okay, it’s really  more depressing than interesting.  But we need to face these issues squarely if we’re going to solve the problem of interoperability. Our only alternative is to forego the capabilities offered by interoperability and continue to let patients die unnecessarily. No one wants that, right? Because  this post is already too long, I’ve saved the parts on how the interoperability market might actually evolve for another post.

The following are some notes from some of the more interesting presentations – be sure to keep scrolling, this is a long post! I’ll follow this up with a post on my presentation at this year’s conference, “How the Network Effect Impacts Adoption of Healthcare Unbound Technologies,” and a wrap-up post.

At 8 am Monday morning, Teri Louden kicked things off. She started her career at Baxter Travenol in the 1970s. Referring to The Graduate, Baxter’s innovative technology of the day was plastic IV bags. Today, things have come a long way from plastics to Healthcare Unbound.

There have been few breakthrough industry segments over time – disease management, home infusion therapy, outpatient surgery – and Healthcare Unbound (HU) is an important pioneering new industry segment.

Teri prognosticated that many of the really breakthrough solutions in health care will come from companies outside of health care – mentioning Intel, Qualcomm, and other electronics and communications companies.

Using CardioNet as an example, Teri described how a new type of solution presents substantive challenges for adoption and effective use. The CardioNet value proposition was unique and required new ways of selling, patient use, and reimbursement.

She introduced Vince Kuraitis and David Kibble, and their topic: The Personal Health Information Network (PHIN): Opportunities and Implications for Healthcare Unbound

The Personal Health Information Network (PHIN): Opportunities and Implications for Healthcare Unbound

Vince introduced the topic with a classic example of the network effect, phones. He asked, what is the value of a single phone? The health care industry is currently the equivalent of two phones representing one to one solutions. The real value comes to the fore when many phones are interconnected, allowing users to contact many other users whenever they want.

Today personal health information is scattered and static. It is not accessible using computing and Internet standards. That data is frozen.

Using a prototypical patient as an example, he introduced the following concepts:

• Portability (can I take my data with me),
• Interoperability (can different applications exchange information – can Cerner’s EMR exchange data with Google Health?), and
• Data liquidity (the degree of freedom with which data from difference sources are permitted to move over networks).

Possible routs to portability/interoper/data liquidity (which can be complementary):

• Maintain the status quo
• Legislative mandates
• NHIN+RHIOs
• PHIN

The PHIN platform companies include Microsoft HealthVault, Google Health, Dossia, and others to follow. Future platform vendors could be affinity ogranizations like AARP, banks, health insurers, large provider organizations and others.

The PHIN could be made up of multiple interoperable platforms. One one side are patients with intermediary applications or direct access to what Vince called “consumer access services.” These “middle” services are currently HealthVault, Google Health and Dossia. Interoperability is assumed between these various middle services (but by no means assured). Without interoperability it is like trying to use your Visa card at a retailer that only takes American Express. Interoperability would be like the phone system, where calls go across all carriers. On the other side are all the various providers in health care: payors, hospitals, physicians, labs, pharmacies, etc.

There are several challenges that PHINs must overcome. These are described as “conventional wisdom” or the status quo, and potential market responses.

Conventional wisdom #1: “It’s our data” where players in health care (payors, providers, etc.) consider their patient’s data as their data. Certainly patients can have a paper copy of data (for a charge), but the liquid flow of that data is purposely restricted. The emerging reality is that patients say, “Its my data, hand it over, now!” This means personally controlled health records. This transformation has no real legal changes. What’s missing is the ability to get that data electronicallly in an interoperable form.

Conventional wisdom #2: Proprietary IT and business models are sources of competitive advantage. This is the traditional proprietary product strategy. Market pressures are causing a small but growing number of vendors to move to common platforms to take advantage of a network effect.

Conventional wisdom #3: Building  NHIN/RHIOs with a “big bang” approach where an entire community or region ties everthing together in one big move. In reality, interoperability and data liquidity can be achieved incrementally, obviating the need for the perfect soluition in a single step. Vince sees business models being built around high value incremental applications.

Conventional wisdom #4: Personal health records (PHRs) done by patients won’t work; patients don’t understand, don’t care. Vince suggested that in fact, patients are getting it. More importantly,  PHR applications can be enabled for patients provided you have the data liquidity, automation and patient permissions.

Conventional wisdom #5, where the media positions this as a zero-sum battle between Google and Microsoft. The reality is that the competition is between electronic means versus the persistence of paper records where competitors like Google and Microsoft cooperate enough to grow the market.

At this point, David Kibbe took over to ask, “How is all this disruptive?”

If you were interested in being a participatnt in health care over the next 10 or 20 years, what would you need to be thinking about? Here are some key issues:

•  Health is personal, healthcare is not
• The PHIN-empowered patient is no longer simply an object for institutional medical process, but the locus of change
• We can’t expect government to “fix” healthcare (they haven’t fixed much of anything else)
• Consider the power of Wikinomics, community, collaboration, soelf-organization of health information
• “We’ve tried the experts, and it’s not working. Let’s try the wisdom of crowds.”

Transparency and openness will be key. Most of health care is closed. All along the supply chain, health care is made up of oligopolies and alliances. Outright secrecy about methods, pricing and data is used to gain competitive advantage.

The PHIN creates new opportunities for non-experts to access health data and knowledge, and to use it without (as much) need for experts.

Continuity is control. The patient needs to be the integrating agent in the system, and not the other way around.

We are at the dawn of an era of new tools and capabilities that can link a person’s health experience in time and space.

Coaches, caches, continuity, control are the watchwords. These tools will be expert systems for use by non-experts, and therefore must be designed to be used by patients.

The public benefit matters. There is a common interest, a public interest, in improving the health status of Americans. Kebbe promotes socialized health care.

Vince wrapped things up talking about the migration of multi parameter remote patient monitoring. This transition will be from high costs and proprietary systems (bound by low volumes and unnecessary duplication of capabilities that adds little or no value) to openness that provides the free flow of patient data throughout the health care system.

Next up was Liz Boehm, principal analysist Forrester Research. Her topic, creating a culture of wellness rather than illness.

Healthcare Everywhere – How the New Culture of Wellness Is Opening the Door for Healthcare Unbound

In 2002 Forrester was defining the HU market with focus on technology. In 2004 they sized the market and came up with growth projections. (She noted we’re getting uncomforably close to that hockey stick with little uptick in growth rate.) In 2005 they identified early adopters of HU. The “network” was the focus in 2006 – the ecosystem with Continua, HealthVault and Google. In 2007 Forrester looked at design elements and market requirements for seniors. Today we’re looking at culture versus biology.

We’re up against a culture that in some ways is antithetical to what we’re trying to achieve, i.e., wellness. Boehm went on to paint a pretty negative picture of society in the U.S. today.

In the U.S. our culture is about the here and now. We’re about profits rather than ethics, about near term costs versus long term costs – destroying our environment rather than hair shirt environmentalism. Simplicity (e.g., feedlots) compared to the complex (polycomplexity farming). Convenience (food that’s easy to find, tastes good) rather than health (foods that are more challenging to put together). Today’s pressure versus tomorrows consequences – smoking, sedentary lifestyles, etc. Her conclusion: Healthcare Unbound is antithetical to U.S. culture.

If were relying on consumers to suddenly gain an interest in health and wellness, we’re in for a long slog. HU is about prevention, management, outcomes and consequences.

Are there signs that times are changing? Perhaps.

Priorities are shifting in increased consumer interest in whole foods, and hybrid cars (although I would argue that’s only because of short term pain – $4 a gallon gas). In health care, consumers are bombarded with choices – type of coverage, primary care physician or specialist, community or teaching hospital, hospital ED or walk-in clinic, etc. Consumers also wonder if a PHR is safe, and is it worth the effort?
Patients are struggling with what they don’t know. Awareness of the actual impact of behavior is low. Perception: is healthy behavior worth the trade off? Psychology of loss versus gain: why does gaining a pound feel so much worse than losing a pound feels good?

Culture changes occurs at all levels, nationally, ethnic culture, at the family level, and at the corporate level.

Forrester surveyed corporations about HU. The top interests were preventive health, cost sharing with employees and wellness management. Wellness prevention investments have grown the most within corporations. But employers are still struggling with how to measure the impact of their efforts in this area. Employers want to measure things like drug compliance, health outcomes and wellness participation.

Employers are looking for one stop shopping, or to put it another way, they want whole product solutions rather than a few tools.

Consumers are looking for convenience.

HU vendors need to provide solutions rather than tools, and build on existing tech infrastructure (rather than waiting for PHRs). Boehm suggested using Boomers to get to their parents, i.e., drive adoption among seniors.

Behavioral Economics Goes Pop

Mike Barrett’s talk was, Behavioral Economics Goes Pop, is based on research that goes in sharply divergent directions. Behavioral economics was founded by psychologists and is now dominated by economists. Current research continues to use insights from psychology to challenge traditional “rational actor” assumptions. Two years ago, Mike introduced behavioral economics to HU. Last year, Mike dug into loss-aversion and associated negative information, with heightened risk of loss.

In the last 12 months, behavioral economists have pushed for a popular audience. Two books have come out, Predictably Irrational and Nudge, targeting the mass audience. Both books have done well. These behavioral economists are also getting proscriptive, suggesting solutions to the problems they’ve identified.

The focus of behavioral economics looks at the decision-making that departs from rational actor expectations. The focus is on heuristics and biases: framing effects, excessive optimism, status quo bias, lose aversion, anchoring, conformity effects, etc.

“Dual personality” conflicts like the id versus the super ego, becomes an exploration of the doer versus the planner, the human versus the economist and reflexive responses versus reflective responses.

Incentive effects are being explored, focused on monetary versus non monetary incentives.

The bottom line is that we are far less rational than standard economic theory assumes. The good news is that the irrational behaviors are predictable.

In the book Nudge, the author developes a construct called “choice architectures.” Anyone responsible for organizing the context in which people make decisions are “choice architects.” And this context is never neutral.

These behavior economists have developed a political frame work and justification for consciously creating choice architectures that they call “libertarian paternalism.” The libertarian part is leaving the ultimate choice up to the individual. The paternalism comes in how the economist creates the choice architecture.

A key concept in choice architectures how the question is framed. Humans are wired for context and this is where choices are framed.

Behavior economists recommend “social engineering” to correct for the distortions caused by heuristics and biases by putting those heuristics and biases to work in a good cause. Because there is no such thing as neutral design, defaults need to be tweaked to produce better choice architectures and outcomes.

Some interesting questions:

• Can payors be trusted as choice architects? Can politicians?
• Who plays the role of choice architect in social networks and patient communities?
• What is the right role for financial incentives?
• Who organizes the context in which people make decisions at home?

Mike provided the example of personal care robots and their ability to greatly influence choice architectures.

The notion of a PHIN is based on the assumption that patients reliably do the right thing – something that behavior economists show does not happen.

How Can Healthcare Unbound Avoid the “DM ROI Trap”

After the break, Gordon Norman of Alere Medical, presented “How Can HU Avoid the “DM ROI Trap.” Gordon admitted that he came today, not with answers, but with a series of questions.

The DM (disease management) ROI trap refers to the question, “does DM work?” Proving the value of DM once it is generally accepted and nearly ubiquitous becomes very challenging. And proof hurdles differ between academics, government and corporations.

In the early days, DM referred to the minority of the population that drives the highest levels of health expenditures. Employers who come into DM on the buyer side have an additional issue, presenteeism – employees who are present but not fully productive. Many employers are looking for someone to effectively address this much larger segment of the population. This extension of DM now includes wellness programs and health coaching, in addition to the traditional acute chronic disease management.

Now, DM means population health improvement to virtually the entire population.

The implied question is, does DM always work for every condition in every population? “Working” typically means short term savings and ROI. This assumes that DM is some monolithic invention, unlike the specific medical interventions applied to more acute chronic disease management.

Some better questions to ask:

• Does DM ever work for any condition in any population?
• Which outcomes are impact and in what sequence, over what time frame?
• How important is personalization of DM?

Due to different apporaches, policy wonks reach the conclusion that there is no proof that DM works, while employers and the health care industry concludes that DM does indeed have compelling justification.

In spite of this “absence of proof” DM is used in over 90% of health plans. Yet CMS remains skeptical. This issue continues to be worked out between CMS, industry and the DMAA.

Gordon ask if the medical home model and DM will converge. He suggested that the two are very complimentary. Since three fourths of patient practices have inadequate resources to implement the medical home model, DM firms could compliment those smaller practices.

Researcher Don Berwick once observed that, “the RCT is an impoverished way to learn.” A better model might be the CMO model (context + mechanism = outcome).

From Mainframe to Personal Healthcare:  A Progress Report on Addressing Technology, Policy, and Cultural Challenges

Eric Dishman, of Intel Digital Health, talked about the transition from mainframe to personal health care. The medical mainframe borrows from the concept of the mainframe computer. This highly centralized form of computing shifted to personal computers and smart phones.

Eric drew the analogy to health care, and posited that the current acute care delivery system – the mainframe – can’t effectively provide things like chronic disease management, wellness and prevention. Demographics and a constrained acute care delivery system will force the adoption of personal health care.

How do we create a vibrant personal health industry in response to and in order to prepare for the age wave? His solutions:

• Look beyond the acute care setting
• Enable care networks to drive healthy life styles, improved detection, etc.
• Focus on behavior markers (diet, exercise, weight, etc.)

The medical mainframe is all about biology, but behavior and how care is delivered are just as important.

His case study, fall detection, was based on the 3 Es: ethnography, evidence, and ecosystem.

• Ethnographic – Understanding falls, fall risks, and fear of falls in elderly homes;
• Evidence – capture baseline of falls and movement data; deploy to in-home pilots to prove prevention;
• Ecosystem – share common research platform of hardware, software, and data; collaborate to build 10,000 home testbed.

The emerging competition, oriented towards proprietary solutions, frightens Eric because without a certain common ecosystem underpinning the market, there will be no market for anyone.

Intel is working through the Technology Research for Independent Living to create a broad platform for research. The goal is to take university research to large population studies. Software is made available to researchers for free to facilitate research.

Real Time Incorporated is now the commercial provider for a common platform for wireless sensors called Shimmer.

Another missing piece is the R&D ecosystem for HU.

He asked, “Have you regularly used a PHR for more than 6 months and gotten medical/personal value from it?” Very few in the audience had. Eric’s conclusion: there is no market place. You’d have to hire a systems integrator to put all this together.

The good news:

• Products based on the Continua spec v 1.0 will be released soon
• More universities are doing work on personal health
• Conferences are abounding
• Press coverage is growing
• The CAST congressional vision video is increasing interest
• Early products are arriving
• Bits and pieces of legislation are popping up
• Some coalitions/non-profits are banding together

The downside:

• Very few products so far
• There is no channel or shelf space for these products
• Not enough value to warrant making a lot of money (and thus motivating entrepreneurs or corporations)
• Many corporate labs are small, barely hanging on
• Academic labs at risk; no publications, reviewers, tenure or scale
• Very little progress on prevention, behavior change
• Advocacy groups fighting for small bills and members
• The health care mainframe is fighting back

His advice for the industry:

• Get real – get out of denial about the thinking there’s no market
• Get large – create the ecosystem to drive sufficient value to grow the market
• Get loud – stop battling one another, join voices and work together

Q: How do we get through the mire in methods patents. A: Eric noted this as a huge issue with no obvious or short term solution. It’s gotten so bad that he’s finding it harder to negotiate with universities than companies like Microsoft.

The Internet of Bodies

Don Jones with QualComm, presented “the Internet of Bodies,” where he explored potential and actual successful wireless Healthcare Unbound applications.

Don started his talk with an overview of the wireless industry. There are now more than 625 million 3G subscribers world wide. Mobile services are becoming central to modern lives. Don’s group at QualComm is focused heavily on the body area network (BAN).

Don mentioned the Amazon Kindle as a device that’s really a cell phone that’s positioned as something completely different. The potential for non-cell phone looking HU technologies based on cell phone technology is considerable.

His summary of sensor platform requirements:

• Ultra low power
• Security
• Integration with sensors – prcoessing, essy configuration
• Smart nodes

Once the sensors capture the data and it is sent on by a gateway, you have to have data management.
A discussion of remarkably successful health and wellness products included the Wii Fit and Nike Plus described as the two most successful digital health products. The Wii Fit sold over 1 million units in a month – in Japan alone.

The challenge is the decentralized patient view and the standards for interoperability so products from different vendors all work together in support of the patient.

The Wireless-Life Sciences Alliance was noted as a forum for vendors to come together to build market awareness and create platforms for HU solutions.

The health care market is a very big – wide and deep – black hole. They see  very select rifle shots as having the best chance of success.

When asked about the patent situation, Don noted that the cell phone industry works on a “patent pool” approach to grow the market.

There was also a question about research on running life critical applications on cellular networks. Don’s response was that any product’s design must identify and mitigate all communications risks.

Google Health Overview

Jerry Lin, product manager at Google, presented Google’s perspective on personal health technologies. He suggested that the patient may be in the best position to manage information on things like redundant lab test results – or actually pointing to the previous lab test, precluding the need to have that duplicative test.

Semantic interoperability was noted as a major requirement. Alignment of incentives has a big impact on the adoption of semantic standards.

Jerry noted “long tail” applications, and providing their service for free (foregoing transaction fees) to drive adoption. They do see opportunities for third parties to provide valuable services from which they could generate revenue.

He went on to demo Google Health, showing the importation of data from third parties (Beth Israel Deaconness) and how patients could view and manage that data.

Q: What’s your strategy for driving adoption? A: By creating more value for the user.

Q: Issues were raised regarding Google’s current business model and whether that’s a fit for a service like this. Specifically, an account break in to Gmail and Google’s lack of the means to respond to individual situations, security, and normalizing data in the front end. A: Jerry had a rather unfulfilling boiler plate answer for this question.

Q: What’s Google Health revenue model? A: There is no revenue right now. They have yet to figure out how to monitize it.

Q: How doe they limit access to the data from internal Google employees. A: Patient data is encrypted and a limited number of employees have access.

Continua Health Alliance Update

Next up, Dave Whitlinger, director of healthcare device standards at Intel, with an update on Continua’s activities. Dave is also the president and board chair of the Continua Health Alliance.

Continua’s mission is to establish an ecosystem of interoperable personal health systems – as opposed to the usual proprietary end-to-end solutions. The three categories of personal tele health targeted by Continua are health and wellness, disease management, and aging independently. Continua aims to provide interoperability between sensors, gateway devices and the back end information systems. He noted the WiFi Alliance as an example of the desired cooperation between competitors with the goal of increasing market growth.

Version one of Continua’s device connectivity standards includes 11073 standards (just finishing up) running on Bluetooth and USB. The standard for connectivity to providers is HL7. Starting late this year and early next year, we’ll start to see new products with Continua logos.

Continua has about 500 modules of member written source code that can be downloaded by member companies. They’re paying contractors almost $1 million to finish up a common software library for connectivity. The code is “reference” only, and written for a generic reference platform, rather than optimized for a specific device. The reference is Windows XP, X86-based hardware, written in C/C++. The library will implement all the mandated features. The library modules include a common API. They estimate member companies can save $500k to $600k in R&D costs.

Use case voting for version 2 occurred earlier this year – a total of 16 use cases. It takes roughly 18 months to 2 years to go from use case selection to commercially available product.

Work is progressing on a project plan for companies to use Continua certified solutions in trials of remote monitoring products. There is also a global policy working group and regulatory user group working in their respective areas.

Continua has also pushed strong internal involvement, with meetings in Europe, Asia and elsewhere.

Dave sees the IHE as the key entity focused on interoperability in acute care.

Emerging Technologies Help Consumers Enjoy Higher Healthcare Standards

David Cerino is general manager, consumer engineering, health solutions group, at Microsoft. His presentation was titled, “Emerging Technologies Help Consumers Enjoy Higher Healthcare Standards.” David applied his experience in the market’s adoption of electronic banking and travel. He had some great suggestions about how consumers will shape HU, and similarities with electronic baking and travel.

He showed geographically based health care communities calling them silos, where providers take their best educated guess based on the knowledge they have. They want to put the patient in the middle to connect all their information together.

Microsoft took the platform approach. Health care is so big and complex, automating this industry is beyond any one vendor – collaboration is a requirement. Health care is always changing as science advances.

Microsoft’s position is that HealthVault is not a competitor to Google Health’s PHR, and that they should be interoperable.

A key differentiator of HealthVault is the Connection Center where device vendors can create interfaces so data from their devices automatically flows into HealthVault.

David compared and contrasted HealthVault with PayPal to illustrate how HealthVault is a platform. Both are data exchange platforms where the user experience is driven by partners. (The HealthVault team is not even marketing to consumers yet.)

HealthVault is not a PHR. A PHR’s end point is to store data. HealthVault stores data so that it can be shared with other entities in the health care delivery system.

The revenue model for HealthVault is based on search engine ads and lifting other Microsoft business.

Disruptive Healthcare Innovation – Changing the Rules of Diabetes Management by Marrying Wireless and Clinical Innovation in the Healthcare Ecosystem

Anand Iyer, president and COO of WellDoc, presented on “Diabetes Management and Emergin Wireless Solutions.” Technology as an enabler can make two key contributions in improved outcomes and lower costs.

Anand used an imaginary diabetic, Frank, to illustrate how WellDoc’s technologies can improve chronic disease management.

Traditional healthcare levels include disease management, pharma innovation, device innovation, and healthcare plan design. These levers have resulted in the status quo. Emerging innovation levers include health and wellness management, pharmokinetic innovation, solution innovation, and value chain design. The heart of this innovation is real time information distributed across a common network.

WellDoc’s solution is chronic disease management and welness coaching over cell phones using simple text messages. How interactions are designed and implemented has allowed a ubiquitous technology – cell phones and text messaging – to be used in a new and very effective manner.

How Health Plans Leveraging Active Biometrics Can Drive Member and Provider Engagement to Help Improve Health Outcomes and Lower Costs

Larry Leisure, North American president for iMetrikus talked about “How Health Plans Leveraging Active Biometrics Can Drive Member and Provider Engagement to Help Improve Health Outcomes and Lower Costs.” Employers impact plan design and health plans influence behavior.

Larry did a great job of laying out an approach to improving HU’s traction in the market to grow the industry.

Anand Iyer asked a question that showed a clear understanding for MVAs (multi vendor alliances, like Continua). Larry thinks the best trends will be driven by large employers.

Wireless Technology – Direct Connect to Influencing Consumer Behavior

Sherri Dorfman with Stepping Stone Parnters chaired this panel discussion. Richard Adler, Institute for the Future, lead things off starting with key mobile health trends:

• Evolution of wireless networks (3G networks currently, WiMax coming)
• More powerful handsets (multi modal radios)
• Smaller, more capable sensors
• Longer lasting batteries/lower power consumption
• Eventual adoption of EHR/PHR
• Development of effective behavior change algorithms.

Vince McNeil, Product Line Manager, Wireless Connectivity, Medical Business Unit, Texas Instruments, reviewed the “usual subjects” in wireless HU technologies – Zigbee, Bluetooth, GSM/GPRS, etc. The first proposed TI corporate pilot is a weight management wellness project. They’re going to use Body Media to monitor activity to track effectiveness in behavior modification. Next they will do a chronic disease pilot.

Aaron Goldmuntz, director of business development at Cardionet, described their mobile cardiac outpatient telemetry. Beyond their existing diagnostic service, Cardionet presented a atrial fibrillation disease and therapy management application. This would include correlation of HR trend and AF burden graph. This application can also be used to evaluate AF therapy efficacy by monitoring the patient be fore and after ablation.

Beyond patient management and self care, Cardionet has been successful in providing tools to cardiologists.

Silviu Chiricescu, principal engineer at Motorola Labs, talked about a planned trial. Targeting an independent living facility, a variety of sensors (glucometer, weight scales, NOBP, SpO2) will be used to manage a variety of chronic diseases. The study will have use a control group and will last a total of 2 years.

Paul Hedtke, from QualComm, talked about consumer perceptions on a diabetic self-management application. The solution aimed to be convenient (data logging, data capture), personalized (data driven, tailored assistance) and persistent (always there, integrated with phone). Solutions from t+Medical and WellDoc have shown to be effective – if you can get patients to use them.

Half of diabetics in the study expressed significant interest in a personal diabetics management service delivered via their cell phone. Interest levels were higher among newly diagnosed and those newly on insulin therapy.

Key features by level of interest:

• Converged devices (phone and measurement device)
• Auto logging of measurements
• On demand emergency assistance
• On demand live diabetes management advice
• Automatic medication management
• Automatic electronic diabetes management advice
• Integrated PHR
• Physician access to measurement data (QualComm was surprised that consumers ranked this so low)

Q: Wireless sensor band-aids, are those real today? A: Vincent noted that there are presently no released product like this. Paul suggested that adhesives may be the biggest R&D challenge to this application.

Q: Cellphones are quickly becoming the de facto ambulatory gateway; what do you see as the standard gateway for home use – will it also be the cell phone?  A: Aaron notes that cell phone coverage, especially in the home is still problematic. Cardionet has a home based gateway that plugs into the land line to complement wireless carrier networks. Silviu suggested that WiFi and set top boxes provide alternative gateways at home.

Q: Silviu was asked what vendors offer standards protocols for their wireless sensors. A: Silviu noted that the protocols are standard transport protocols, but they are going to be using products coming out of Continua’s version 1 work.

Doug McClure, transtioned the panel to consider business models.

Paul Hedtke noted that chronic conditions require a continuum of care that cannot be cost effectively delivered by the taditional health care delivery model. Potential models include:

• Provide tools that allow traditional health care providers to extend the “point of care”
• Provide tools that allow traditional disease management providers to provide more robust services
• Leverage technology to provide chronic condition management tools and services directly to consumers at consumer price points

The business model has to be more than instrumenting patients, with data now flowing into the physician’s office. For example, Cardionet built the platform to sell a service in order to relieve the cardiologist with a burden that they really weren’t able to cover.

LifeCOMM (QualComm’s announced MVNO) is a direct to consumer model experiment. They plan to bundle health services with typical cell phone services, employing a subscription business model. These services will be tailored for specific chronic diseases. They will build these services through collaboration with “brand authority” partners and market direct to consumers. They plan to sell through health product and services relevant channel partners

Richard explored the pros and cons of mobile as a health platform. It’s personal, portable, ubiquitous, connected and intelligent. The downside is that it is a heterogeneous environment (multiple operating systems), networks operate as walled gardens, its a rapidly changing environment, there appears to be a mismatch between the mobile and health care industry.

The most promising applications include: remote monitoring, reminders (appointments and medications), clinical trial communications, patient behavior change, and remote consultations.

In the long run, a very interesting HU platform is SMS texting. Over 95% of phones are text-capable. More than 100 million of 253 million U.S. subs use SMS. 41 mil Americans text “almost every day,” generating about 1 billion text messages are sent daily. At least 3 of the above 5 applications are well supported by SMS texting. There are even some provocative trials showing the ability to change behavior using texting. An evolution in the technology is MMS, multi media messaging service, for texting messages with still and motion pictures. (Richard also mentioned a low cost SMS application intended for NGOs.)

The future of mobile health care 5 key trends:

• Continuous monitoring (MD Keeper, RFID band-aid with temp, Body Bug, free swimming nano tech sensor)
• Continuous support – personal coaches for asthma, I Buy Right that reads packaged goods barcodes that provides additional neutritional and ecological footprint data, and an advanced pattern matching application that identifies your location and provides warnings.
• Remote consultations – the service shown is in the UK; patient competes an intake form on the Internet and then
• Mobile personal health record
• Merging of mobile and social media – Qwitter instead of Twitter to help stop smoking, Daily Strength and Patients Like Me patient support web sites.

Nowadays, patients show up for an office visit with research from the Internet, in the future they may come with their own support group with whom they will filter physician therapies.

Silviu is confident appropriate models will emerge – there is no one single model for everything.

Vince sees consumer electronics and preferences having a growing influence. The key will be not the what, but how best to use it.

Aaron noted that there’s tremendous enthusiasm about the consumer electronics market, but we’re in an environment where patients aren’t used to paying for health care and business models that better fit into the current health care market will be more successful in the near term. While some potential business models have huge long term potential, fitting them into the current health care industry is important.

Paul believes that new technologies will drive new business models. He suggested that if we let the health care providers dictate how to use new technology, only a small fraction of the potential of this new tech will be realized. Doug, who works for a large provider organization, agreed.

Twenty years ago, the thought of doing all your banking without ever facing a bank teller was inconceivable. Today most bank customers rarely interact with tellers.

Q: Is any one working on the meta analysis medical device? A: Aaron reported that there’s lots of interest, but there is an incremental approach being taken.  Paul referred to advances in automobiles; 10 to 15 years ago RPM was about the only thing continuously sensed on your car, now there are many parameters being continuously monitored and recorded. HU technologies are moving in the same direction. Vince sees the same requirements, but because these capabilities are new the market’s working out to use the new data (e.g., combining ECG and auscultatory data or gait data).

Q: What about the challenge in getting buy-in from physicians? For Cardionet, what challenges and success have you had in that area? A: Aaron noted that there are several things. First, they offer a service that takes a lot of the load off the physician. In terms of convincing payors, there is some intuitive persuasion but the heavy lifting comes from clinical trials.

Customers Want More than the Box

There are many barriers to entry in health care: regulatory hurdles, entrenched competitors and gatekeepers like group purchasing organizations (GPOs). Increasingly, connectivity is becoming a barrier to entry – or perhaps a new price of admission. There are few medical device product categories that don’t have some connectivity requirements. (More on the actual requirements below.) But besides buying the embedded device, providers are increasingly interested in buying whole product solutions.

Coined by Geoffrey Moore, a whole product solution is just that, all of the components and services required to fully realize the potential of the overall solution. Thus if one of your connectivity requirements is integration with an EMR for electronic charting, just putting a serial port on your device is not a whole product solution. Of course neither do you have to do the whole solution yourself. Frequently the best strategies entail providing part of the solution directly (developed yourself, outsourced, licensed, etc.) and creating the rest through business development and alliances with other vendors.

Connectivity As Competitive Advantage

Sometimes connectivity can be leveraged to gain competitive advantage. Point of care testing (POCT) startup EPOCAL is a great example. This company has apparently done an exemplary job in recognizing market requirements and formulating a design that maximizes connectivity features and capabilities, while minimizing development costs and time to market. If this new system is successful, established competitors will have to scramble to catch up.

CardioNet is another startup that leveraged connectivity from the get go.  The acquisition of ECG signals is pretty routine. The algorithms for analyzing ECGs are also well understood, but continues to yield occasional innovations. Besides superior ECG analysis algorithms, CardioNet implemented a near-continuous connection with a remote service center that wirelessly acquires and reviews patient ECG waveforms – during the diagnostic test. This continuous recording and analysis contrasts with conventional holter monitors that record a batch of heartbeats (typically 24 or 48 hours) that are read at the end of the study. This unique connectivity enabled workflow provides CardioNet with unique clinical capabilities that have resulted in much higher diagnostic confidence than conventional holters – and a sustained competitive advantage.

The Answer to the Ultimate Question About Connectivity

A new product is an answer to a problem. And for entrepreneurs, that answer is a product design – some novel way to solve the problem. You can’t design something until you have requirements. For entrepreneurs, their focus on finding the answer to the customer problem results in a good understanding of requirements – so the overall design or answer to the customer’s problem becomes self evident. Admittedly figuring out how to realize the answer, say determine the level of conscience sedation, can be more challenging.

Designing a new product or technology without adequate requirements is a common mistake. The resulting solution becomes a “solution in search of a problem.” Commonly referred to as a “technology push,” vendors frequently turn to consultants to help them figure out how to shoehorn their solution into the most attractive market problems. The end result is usually marginal (and it’s no fun being put in a position to deliver bad news). The best time to bring in outside expertise is at the requirements stage, when changes to the solution or business model are easiest and least expensive.

When the question shifts to connectivity, the focus moves way beyond the scope of initial problem to be solved to questions about how the resulting device will be used and integrated into patient care. This shift of focus veers off into an area for which the start up has no requirements – and thus struggles with finding “the answer.”

Much like solving the original problem with the innovative product design, finding an answer to the connectivity problem starts with asking the right questions. Many entrepreneurs, anxious to find the answer, start to make trade-off decisions before they have a handle on requirements or the scope for meeting those requirements.

The good news is that if you go about it the right way, solving the connectivity problem is relatively quick and easy. And the sooner you start, the less incremental work it represents.

Finding the Answer

The key to quickly zeroing in on your connectivity solution is to iterate.

1. Start at a high level and capture the complete workflow that surrounds your product. Cast a wide net in order to define the entire landscape in which your product will exist. Don’t worry about the details of every bit of workflow, just get the big picture.
2. Compare the resulting workflow with your product’s key value proposition – not just what it does, but what it means to the buyer and why they will buy it. For example, customers will not buy your POCT device because it allows them to do tests at the bedside. They’ll buy because you offer a better (or the first practical) way to shorten length of stay, improve patient outcomes, and avoid unreimbursed “hospital acquired conditions.”
3. Discard the portions of your global workflow assessment that don’t directly contribute to your key value propositions.
4. Now dig in a bit more, and capture enough workflow information to consider some design options and get a feel for scope. Rank the resulting connectivity features by how well they support your key value propositions (this becomes your priority list).
5. Evaluate the the resulting estimated scope of effort and development costs with your existing budget and time to market. Cut those items that rank lowest on your priority list. Depending on the relative gap between your priority list and the time and money available you can go one of two ways.
6. Repeat steps 4 and 5 to winnow down your list of connectivity features further, or jump to the next step. There’s a difference between workflow that does not contribute to your product’s value, and workflow that does. You want avoid the former and do as much of the latter as you can. If you postpone developing essential connectivity features, be sure to create a well considered roadmap so you don’t end up redesigning early connectivity features to accommodate later additions.
7. Evaluate various design options for your list of connectivity features (that is, the entire roadmap). This process optimizes your implementation approaches for your connectivity features, ensuring the biggest bang for the buck and shortest time to market. Options include build it yourself, subcontract, or license technology. There are some innovative new “best practices” that are greatly reducing both time to market and total cost for some connectivity features. Your options also include business development and alliances with other vendors.
8. You may need to repeat steps 4, 5 and 7 again.
9. When you’ve balanced your ability to help the customer justify their purchase of your solution (the connectivity features) against available schedule and budget, start your PDP (product development process) by documenting your requirements. You should complete requirements documents for connectivity capabilities you build, buy or get through bus dev and alliances.

If you’re in a hurry, you should be able to go through the above process in 1 to 3 weeks (not including travel time, review cycles, delays scheduling meetings, etc.). If you’re not in a hurry because you didn’t wait til the last minute, or connectivity is a major focus for your product – like EPOCAL – complete this process in sync with the product’s development cycle.

With the core technology of your product, many of the solutions to feasibility and productization challenges seem self evident in hindsight. This hindsight is the result of knowing now what you didn’t know at the beginning. With connectivity, remember that you don’t know what you don’t know. Nor do you really want to gain that knowledge through hindsight, since connectivity has been figured out before. There’s little or no value to be gained in reinventing this wheel, and besides, you’ve got a product to launch.

There are many ways to skin the connectivity cat, so be sure to look beyond what your direct competitors are doing. Besides, what your competitors are doing could be wrong.

Common Connectivity Applications

Connectivity is workflow automation through the integration of the medical device and information systems. Here’s a quick survey of the most common types of workflow automation for medical devices.

Research

In some ways, this may be the most important connectivity application for innovative medical devices. First let’s start with how research benefits the vendor. The more novel a new medical device, the greater the need to verify specifications, validate the intended use and demonstrate the claimed benefits. This process starts in the feasibility phase and only increases as the product is launched. Peer reviewed studies are highly sought after to justify buying the product. The sooner a start up has “clinical evidence” – published studies – the faster sales will increase.

How does making research easier benefit buyers? The greater the level of innovation in a new product, the more likely that early adopters will be researchers and teaching hospitals. Many of these guys and gals live by their research. Think for a minute about what big pharma does to facilitate research for their clinicians, and contrast that with what medical device vendors provide. Pretty sad, isn’t it? Now imagine a luminary physician looking at a new medical device that’s not only way cool and new on the market, but comes with everything needed to capture and analyze data.

When phasing in connectivity features, this may be a good place to start. This basic connectivity and support for research can be extended to multi-site  studies, and post market surveillance of the device. With a bit more work remote diagnostics, service and even uploading new firmware are possible – operational efficiencies rarely available to a start up.

Device Use – Operational Workflows

Connectivity features really start with the automation of these basic activities that represent the workflow most closely associated with the operation of the device. Get these requirements right, and you’ve added considerable value to your product and laid a good foundation for additional connectivity down the road. Get these basics wrong (or skip them) and your ability to meet connectivity requirements is greatly impaired.

Medical devices typically aren’t used without a physician’s order, configuration of the device, and the necessary documentation. These are the basic  workflows essential to the operation of the device.

These workflows include establishing patient context where data generated by the device is associated with the correct patient. Patient context frequently includes capturing the caregiver and device identification.

Device configuration is manual for most devices, although many devices capture and log how the device is configured. The market is slowly moving to interoperability, an initial application has an order automatically configure the device. This may occur first with smart pumps. In the absence of industry standards, this interoperability will represent a significant new barrier to entry for start ups.

Documentation is an essential activity related to device use. Diagnostic devices must document their results – ideally to a signed final report; monitoring and therapeutic devices must document a variety of things as they occur (alarms, start/stop of therapy) and on a periodic basis (like vital signs).

As EMRs and paperless charting proliferates, the requirement to automate these basic operations increases. In fact, in some market segments this level of connectivity is a standard feature for all mainstream products.

Data Analysis

Connectivity is an attractive avenue for implementing some medical device features because writing software for a general purpose computing platform is frequently quicker than developing it for an embedded system. Also software engineers experienced with general purpose computing platforms are much more prevalent than embedded systems software engineers.

Most data analysis fundamental to the medical device occurs in the embedded system. Sometimes optional features, like arrhythmia analysis, are implemented on general purpose computing platforms using connectivity, rather than in the embedded system itself. There is also a meta level of data analysis related to most medical devices.

The workflow that supports the use many devices includes trending data over an extended period of time – the entire length of stay, or even multiple episodes of care for frequent fliers. Preferences for which variables are trended, and over what periods of time vary by patient and clinician. And trending only tells part of the story.

Many clinicians want to “look back in time” to see the retrospective data generated earlier in the shift or over the weekend. Accessing this data is frequently done by events like alarms or the start/cessation of therapies. Because the data management capabilities in embedded systems are limited, these features are implemented on general purpose computing platforms.

Another key reason for moving data analysis off the embedded device is when the data comes from multiple devices. Many patient safety and outcomes features require retrospective data from all the patients in a unit or institution. Implementing this on an embedded devices would be most impractical.

Visualization

Visualization is really another category of data analysis, except the data is displayed visually like in diagnostic imaging or with tools like calipers for ECG analysis. Like data analysis, essential visualization of  data produced by the medical device is done on the device itself.

Depending on the analysis and visualization requirements, processing power and/or display size and resolution may make implementation on the embedded device too expensive. Secondary visualization techniques such as alternative ways of looking at the patient’s data, visualization of retrospective data, or visualization tools packaged as options are frequently implemented off the embedded device using connectivity.

Alarm and Alert Notification

This category entails both life critical alarms and lower priority alerts, and can be sent to caregivers or clinicians. Both patient monitors and acute therapy delivery devices require effective alarm notification. Conventional alarm notification – local alarms or central stations – frequently result in alarm fatigue and failure to rescue. Simply generating a local alarm is the bare minimum required for acute conditions. It is possible to include innovative alarm notification capabilities into a new product offering without a huge impact on time to market or R&D budgets.

Innovative new medical devices frequently produce data that can greatly impact the quality of care and patient outcomes. To achieve this worthy goal, the data must be actionable – meaning the data must get to the individual who is best able to take the action that will result in an improved outcome. Facilitating the process of getting that alert to the right person and making it easy to implement and use is critical to driving market adoption of an innovative solution. Remember, providers want solutions, not tools that they have to forge into solutions themselves.

Surveillance

Many medical device use scenarios benefit from the display of device data separte from the device itself. Miniaturized devices with small displays can benefit from larger secondary displays right at the point of care. These displays can also serve as user interface devices through the use of touch screens. Surveillance beyond the point of care is also a frequent requirement, especially in patient care areas where caregivers are not always at the bedside.

Many health care actors removed from the immediate delivery of care have an interest in device generated data. Whether pharmacists and infusion pumps or busy caregivers and patient monitors,the ability to see a summary of device data – or a representation of the actual display – can greatly impact the use and performance of a medical device.

Event Review

Data generated by the medical device, in full resolution and fidelity, can be valuable long after the data has scrolled off the screen. This data, frequently displayed as waveforms, is used to review a patient’s changing condition over time. Events are typically used as markers to quickly find clinically relevant data.

To provide this capability on the embedded device would require transforming the device into a general purpose computer – an expensive and time consuming option. This data is frequently reviewed away from the point of care, and there is frequently a requirement to view this data in remote locations via personal computers or smart phones.

Quality Assurance

Many diagnostic systems require some sort of quality assurance activity. To the extend that this can be automated, the adoption and use of the device is greatly enhanced.

These types of applications are very specific to the device in question, and connectivity best practices play a major role in time to market, development cost, and customer satisfaction.

Remember, it’s not the nuts and bolts of connectivity that’s critical to product success, but the features and workflow automation that result from connectivity.

A Word About Connectivity Design Solutions

Connectivity is challenging. It is not easy to do and can be expensive and time consuming to implement. In market segments where connectivity is new, prospective buyers can’t articulate requirements for something they’ve never done before. Nor do buyers want to pay a premium for connectivity, although they will pay a premium for clinical applications enabled by connectivity.

Despite all this, connectivity has a major influence in a solution’s usability and customer satisfaction – key success factors for adoption. Connectivity has played a major role in the success of companies like Alaris, Abbott Precision, CardioNet and others.

Design options for connectivity are changing rapidly. Architectures, technologies and methods that were standard just a couple years ago, have been superseded by new approaches with shorter times to market and lower development costs. Workflow automation that once required a dedicated server can now be implemented on silicon and embedded into the medical device. Open source software is also impacting connectivity.

Proprietary communications protocols add significant costs and time to market for the systems that incorporate that connectivity.  In the near total absence of standards for medical devices (outside diagnostic imaging and DICOM) implementing connectivity with other vendor’s systems is difficult, a situation that greatly advantages large established vendors. The approach to communications protocols is changing right along with connectivity design approaches.

There you have it, a partial answer to the ultimate question about connectivity – specifically for startups.

• Is the potential buyer or prospect really going to buy anything – from anybody?
• Will my product be a serious contender for the sale, or am I simply cannon fodder to help justify a sales process with a foregone conclusion?
• And if I am a serious contender, how does my product match up against the competition relative to the specific needs of this prospect?
• Who all is involved in making the decision of what to buy? (More on this in a future post on Selling Connectivity)

A common problem in markets where connectivity is new or dramatically innovative is avoiding prospects who are more interested in being educated than really buying anything. In situations like this, sales reps can get appointments to talk to prospective buyers very easily because they all hope to learn something interesting. The problem is that few of these prospects intend to buy anything, thus taking valuable time away from actually selling stuff.

Sales Strategy

The solution to this problem is an effective sales strategy. A sales strategy is like a cook book recipe that details precise steps that result in a successful sale and satisfied customer. A good sales strategy describes the quickest and most reliable process for starting with a prospect and winning the sale. Effectively selling connectivity and overcoming the qualification challenge requires a good sales strategy.

There are many ways to think about sales. One useful way is to consider how reps approach the process of winning sales. Some reps seem to feel their way to a sale with an uncanny intuitive empathy. These reps seem to have Jedi-like power over prospects, situations – even competitors. This qualitative approach contrasts with the quantitative sales rep. This rep knows how many phone calls it takes to get an appointment, how many appointments to get a demonstration, and how many demonstrations to win a sale. They take a scientific approach to sales, collecting data on sales outcomes and changing variables in a controlled manner.

When selling embedded systems, either sales approach works because the sales process is tightly focused around the characteristics of the box and the specific needs of the customer. Because connectivity deals with workflow automation beyond the device, and can be highly variable from account to account, sales reps can waste much of their time on prospects who just want education or are a poor match for the rep’s connectivity solution. An effective sales strategy can quickly exclude unqualified prospects, greatly improving sales reps productivity.

Some vendors run their sales departments in a very laissez-faire fashion and some do not. Back in the day, Marquette Electronics’ reps managed their sales territories like their own small businesses (the qualitative approach). Reps had tremendous latitude on how they sold their products, all they had to do was make quota. Marquette’s approach contrasted with Hewlett Packard whose approach at that time was very controlled, with a detailed sales strategy consistently applied across the sales force. Both vendors were successful. Marquette succeeded mainly on the strength of their innovative products. HP succeeded on solid, but less glamorous products, and a scientific approach to sales applied consistently across the entire sales force.

Qualification

When faced with a market that’s more interested in learning about new technologies than it is in buying those new technologies, vendors need a sales strategy that quickly separates the tire kickers from the serious buyers – as early in the process as possible. Someone looking to get educated will gladly take up their sales rep’s time sitting through sales presentations and product demonstrations. So, after the initial sales call the next step in the sales strategy should be a qualification step, an event that clearly demonstrates the prospect’s intent to buy. For example, requiring the sales prospect to include peers and management above them (who would naturally be involved in a real purchasing situation) in the qualification event. Tire kickers can rarely line up busy attendees like medical directors, the CNO and CIO just to get educated.

In the late 1980s I had the privilege of working with a master quantitative sales rep, Sam Phillis. Sam was the one that worked out the initial sales strategies at our small start up connectivity software company. We had a new solution that previously had only be available to large university teaching hospitals, and was the first such product available to “mere mortal” hospitals. After the first meeting with the department director (who was almost always interested in learning more) the next step of the sales strategy was a formal sales presentation – with a twist. The twist was that the presentation would only happen if the meeting was attended by the department’s medical director, CIO and hospital administrator over that department. An unqualified prospect could rarely interest these additional attendees for something they had no intention of buying.

To ensure full participation, Sam would contact each attendee before the presentation. If any of them backed out, he would cancel the presentation. Once when I was traveling with Sam, we arrived at a hospital a couple hours before the qualification event. We visited each attendees’ office to confirm their attendance. The administrator over the department told Sam that he would be unable to attend. Sam’s response was to cancel the meeting – and noted that he would be investing his now free time with the hospital down the road. After picking my chin up off the floor, we went to the cafeteria for lunch – and who should come by but the administrator’s admin, confirming her bosses attendance. The qualification event did come off. The administrator was late , and Sam did not start until he arrived (he may never have arrived if Sam had started without him). The hospital went on to make a purchase, from Sam.

Sam spent a major portion of his time fighting battles like this. This was the only way he could justify investing his limited time in an account, and he could only run his numbers and optimize his selling process if he consistently followed his sales strategy. Not everyone has the personality to pull off Sam’s bold account management tactics, but the need to manage the sale remains.

Let’s close by noting that educating the market is largely the responsibility of the vendors with the innovative products. This education is really in their best interest, because uneducated markets are slow-growth markets. While various factors can become barriers to adoption, the lack of understanding about new solutions is a frequent issue with connectivity based products. The job of educating the market falls squarely on the shoulders of marketing. The job of sales is to generate revenue, which they can’t do if they’re educating the market (one account at a time). Over the years I’ve tried many ways to educate the market (and sales reps), some worked brilliantly and some were utter failures. Hmm, sounds like a good blog post topic…

NOTE: This post was going to be about qualification, the next item on the list of Selling Connectivity topics. After digging in it quickly evolved into a discussion of qualification within the context of a sales strategy.

The next installment in this Selling Connectivity series will cover new decision makers. You can read the first of this series here.

The barrier to effectively applying the intuitively obvious to connectivity results from fundamental differences between embedded system devices (i.e., conventional stand alone medical instruments) and the methods and technologies used for connectivity (i.e., general purpose computing technologies). This dichotomy in the application of the different technologies used in both embedded systems and connectivity, extends from product design to regulatory, manufacturing, marketing, sales, installation, service and support. For the vendor, the entire business delivery system is affected. Provider processes – needs assessment, vendor selection, implementation and ongoing internal support – are impacted as well by these differences.

So how are embedded systems different from connectivity? Embedded systems embody the following concepts:

1. The embedded system is a black box in which the vendor controls everything.
2. As many variables as possible are striped from the embedded system to simplify design, improve safety and reliability, and to improve serviceability.
3. Cost of goods (COGs) and the bill of material (BOM) are supremely important as they determine product costs and factory margin (most device vendors’ factory margin targets for a new product is 80% or higher).
4. Because they are a black box, selling embedded systems are all about the box – the user interface on the box, how the device attaches to the patient and the data that comes out of the box (e.g., diagnostic image quality, accuracy of arrhythmia analysis, elimination of motion artifact in NIBP or SpO2, etc.) – rather than the customer. There is some focus on the customer’s clinical practice and how that matches the embedded device’s features, but the focus is still box centric.
5. The sphere of vendor focus extends no further than attaching their product to the patient, the user interface and resulting usability. Installation involves uncrating the device, plugging it into a wall outlet, and training the caregiver and/or techs who will use it.
6. Selling the embedded system entails a limited degree of account qualification to identify the characteristics of the device that are most important to the prospect, presenting the general features (usability, powering options, mobility, size and weight) along with clinical capabilities.
7. Servicing the embedded system device entails diagnosing the black box itself and any external sensors connected to the device. To the frustration of biomedical engineers, the service model for customers has evolved to from board repairs, to swapping components, to swapping entire embedded system devices.

While buying or selling embedded system devices is not a cake walk, notice how each of the areas above are focused and constrained – inwardly focused – as a black box should be.

Before we get into a similar list for connectivity, remember that connectivity is more than just the ability to connect the device to a third party information system, that’s the easy part. Effective connectivity – that caregivers and techs will actually use after you’ve bought it – results in the automation of specific workflows that occur around the use of the medical device. Already we’ve moved from constrained and inwardly focused embedded system model to the (by comparison) amorphous mystical realm of connectivity.

So, here’s how connectivity impacts the principals noted above:

1. With connectivity, the vendor is inexorably forced to give up the rigid control they enjoy with their black box and support the standards and typical options of the general purpose computing world. When implementing network connectivity on the embedded device, the vendor can’t just support one method of network configuration (for example only supporting static IP addresses). The vendor must support all the general enterprise IT conventions for communications and integration.
2. Supporting a myriad of IT conventions (network integration, authentication, encryption, LDAP/Radius integration, QoS, the list goes on…) adds a considerable number of what seem to be “unnecessary” variables to the device vendor. For sales, this opens a whole new area for account qualification, negotiation, and how the solution is quoted. The clinical buyer is between a rock and a hard place: they don’t understand their IT department’s requirements (and which ones are reasonable/unreasonable) and they have to trust the vendor who doesn’t know any more about this stuff than they do.
3. New costs associated with connectivity, like installation, systems integration, service and support, frequently overshadow what were once simple unambiguous decisions impacting COGs. Conventional IT features (say 802.1x authentication) that are stripped out to “keep COGs in line” can result in lost sales if the buyer uses a missing feature in their IT infrastructure. Holding the line on COGs and causing your warranty reserve to balloon or missing revenue projections are two frequent outcomes. With connectivity there are no “easy” COGs driven decisions.
4. Connectivity fundamentally changes how the medical device is bought and sold. When you automate workflow around the use of a specific device, the impact of your choice of devices extends beyond the immediate use of the device itself. A great example is the point of care where medical device connectivity system decisions interact with those made for wireless phones, nurse call, and messaging middleware like Emergin or Ascom. The resulting workflow is impacted by multiple purchase decisions made over time involving a number of apparently unrelated vendors. Even the configuration of a single system impacts usability and workflow across all of the integrated systems.
5. The sphere of vendor focus must now extend into multiple directions. As noted above, connectivity extends workflow automation. Product managers must extend their skills to capture these new workflows in a way that engineers can reliably implement into the product. The vendor must extend their knowledge into the general IT sphere to create competitive products, and successfully install, service and support them. This means new skill sets at significantly higher pay grades for certain positions in numerous departments.
6. Sales must evaluate a prospect’s workflow, compare it to their product’s capabilities, and effectively position their solution against the competition – or judge the prospect unqualified due to a workflow mismatch. Buyers must evaluate their own workflow and the workflow support provided by each vendor under consideration, and accurately rank vendors on the quality of match between workflows. The same process is required for IT requirements like network configuration, authentication, encryption.
7. In my experience, service is one of the areas hardest hit by the adoption of connectivity. There are significant new skill sets required, skills that have a higher market value than those of the typical embedded system field engineer or support tech. Since little of this change is anticipated and budgeted in advance (remember, you don’t know what you don’t know) service – and the customer along with their internal advocate, sales – learns these lessons the hard way. The result is frequently poor service responsiveness and quality, which improves (too slowly for sales and the customer) over time.

The nature of workflow automation, long the principal focus of IT, is new to embedded device vendors. For the sales rep, the guy or gal who is at the pointy end of the spear, this is a scary proposition. While internalizing connectivity is a job challenge for everyone else in the organization, the sales rep will measure the success of their company’s adoption of connectivity by their income. Is it any wonder they get exercised when promised features don’t materialize, things work poorly (or not at all), or customers are left in the lurch?

The next installment in this Selling Connectivity series will cover qualifying prospects. You can read the first of this series here.