I’ve been interested in the new “wearables” segment for a while. I reached out to Cameron Graham, the managing editor at TechnologyAdvice where he oversees market research for emerging technology, to give us some evidence-driven advice about wearables that entrepreneurs, innovators, healthcare providers, and payers can use for decision making. Specifically, what does the current research show and what are the actionable insights for how to incentivize patients to use them and figure out why patients might pay for them? Cameron thinks that wearable health technology could help improve patient outcome monitoring, if insurance companies and providers work together. He elaborated:

Wearable health technology (or mHealth as some call it) is one of the emerging frontiers in medicine. Fitness tracking devices could allow the healthcare industry to better measure patient outcomes, monitor patient populations for emerging trends, and give preventative healthcare advice based on quantitative measurements (such as daily step counts or heart-rate). We surveyed 979 US adults about their fitness tracking habits, in order to determine current the usage rate for this technology. We then further surveyed 419 of those adults, who identified as non-trackers, about what incentives would convince them to use wearable health monitors. Here are some of our takeaways for vendors and providers:

1. The wearable health market remains small, but is growing steadily

In order to gauge how many adults are currently generating personal health data that would be useful in either patient treatment or preventative medicine, we asked a random, nationwide sample of adults whether they currently tracked their weight, diet, or exercise using a fitness tracking device or smartphone app.

74.9 percent of respondents indicated they did not track any of those variables using either a fitness tracker or smartphone app. 25.1 percent reported tracking such stats.

Out of the roughly one quarter of adults who do track their fitness, 14.1 percent said they used a smartphone app, and 11 percent said they used a fitness tracker. There is currently little data on such demographics, although the Pew Internet Research Project conducted a survey in 2012 looking at similar trends. In their report, they noted that seven percent of adults tracked health indicators using an app. Combining these results, we can see that the market for health tracking applications has approximately doubled over the last two years.

As more consumers adopt such technology, and rely on it for monitoring their health, providers need to become involved in the discussion. There is limited data that can be draw from a sample of just 25 percent of a patient population. If providers can encourage adoption among a majority of their patients however, they will gain greater insight into current health habits, and be able to provide more tailored advice.

2. Physicians can play a large role in encouraging tracking but there are are few incentives in place for them to do so

Looking into what incentives could convince non-tracking adults to use such devices, we found great potential for healthcare providers to encourage tracking habits among their patients. It appears patients want their physicians involved more in monitoring but our healthcare system doesn’t have the right incentives or payment structures available to compensate providers.

48.2 percent of adults said they would use a wearable fitness tracker if their physician provided one. While this may be financially unrealistic for smaller practices, wearable activity trackers (like the FitBit or Jawbone UP) will likely become cheaper as more sophisticated, multi-purpose devices enter the market, such as the forthcoming Apple Watch.

If physicians were able to get half of the three-quarters of non-tracking adults to start measuring their fitness with wearable devices, it would create huge amounts of patient-generated data for the healthcare industry to analyze.

The infrastructure for handling this data is largely in place. The most popular electronic health record provider, Epic Systems, recently announced a partnership with Apple that will allow hospitals to easily integrate wearable data through Apple’s HealthKit platform into patient portals and records.

Promoting the use of such devices should now be a goal for physicians looking to gain greater insight into their patient population. The question would be why Physicians would do this without additional compensation either directly from their patients or indirectly through insurers.

3. Insurance companies and providers need to form partnerships

While a significant portion of adults would use physician-provided devices, health insurance companies may be the ultimate key to promoting widespread fitness tracker adoption.

A total of 57.1 percent of respondents said they would be more likely (or much more likely) to wear a fitness a tracker if they could receive lower health insurance premiums. In fact, this was a more compelling incentive than the possibility of receiving better healthcare advice from their physician (just 44.3 percent of respondents said that would make them more likely to use a tracker).

By agreeing to use a fitness tracker, insurance customers would become eligible for special discounts, perhaps for walking a set number of steps each day, or raising their heartbeat for a certain period of time. Discounts could be given out directly or through an employer.

Some companies are already experimenting with such systems. Humana insurance has a new Vitality program that allows employees to opt-in to fitness tracking in exchange for possible discounts. Car insurance companies have also found success by offering lower rates for safe-driving, as measured through in-car tracking devices.

If providers want to encourage fitness and health tracking among their patients, they should evaluate the possibility of providing devices to their patients, either for free or at a reduced cost. At the very least, they should make patients aware of the benefits of such devices, and encourage them to automatically share such data through their patient portal.

Long term, providers will likely need to collaborate with insurance companies in order to establish a data sharing system for such information, which can allow for physicians to better monitor their patient population, and provide more accurate, tailored diagnoses. A universal patient record system would be ideal, although given current interoperability standards, an insurance-provider arrangement is more likely.

{ 0 comments }

MedCityNews invited me to attend their ENGAGE “Innovation in Patient Engagement” Conference and I found the content, speakers, and overall quality quite good. Since I chair several conferences every year I know how hard it is to pull off a good one so I’d like to congratulate MedCityNews for pulling off a great event. I asked HITSphere‘s Vik Subbu, our Digital Health editor that focuses on Bio IT and Pharma IT, to summarize what we learned at the event. Here’s Vik’s recap of the conference:

The goal of the ENGAGE was to highlight the importance of patient awareness and engagement in developing and managing novel digital health innovations. The conference was attended by industry experts from various disciplines ranging from academic hospitals, non-profit organizations, digital health start-ups, venture capital, service providers and pharmaceutical companies. The interactions between product developers and patients proved to be worthwhile as it is often rare to get both ends of the spectrum together. The point of the conference, driven home in almost every session, was that having patient (i.e. customer) input early on shapes better product development decisions and viewpoints.

Top Ten Insights for digital health innovators and providers:

  1. Engage patients upfront prior to developing ANY digital health solution. This seems obvious but it’s not always done well — we just assume patients have various needs without testing our hypotheses.
  2. Healthcare providers need to look at existing information for patient care – let’s use what we already have to improve care. This means innovators should not be creating new data collection or data entry screens if that same information can be integrated from an existing solution (such as an EHR, lab system, etc.)
  3. Stay away from the “hype” – providers do not have the time to test out digital health solutions/applications. Do your homework with patients, payers and providers before embarking on developing a digital health solution. It’s easy to create software, it’s very hard to find clinicians willing to spend time testing your software-based hypotheses.
  4. Clinical work flows will change in the future – consider these changes and integrate your digital health solution into these work flows. This means you should abstract your workflows, protocols, procedures, etc. from the core software into distributed workflow or BPM style systems. Whatever you assume the workflow to be, it’s likely to be wrong as it gets into complex environments like hospitals and health systems. Do yourself a favor and abstract it so that you can flex the software as move from enterprise to another.
  5. Do not compete with physicians – digital health applications should support not supplant physicians. If you’re creating educational systems for patients give them data that they can share with their physicians. If you’re creating diagnostic systems, create them so that the data they generate can easily be shared with clinicians and existing systems.
  6. Enhance the patient experience in the clinical setting through digital health. This can be done in many ways, starting simply as digital signage — going to patient navigators and even as far as digital avatars. Don’t think about the current experience and try to slightly improve it; instead, think of completely new ways of solving old problems.
  7. Consider “slow” technology – design the digital health as you go along while incorporating patient input and reflections and find the right solution, not focus on the technology – the best technology fades into the background. Create solutions with Clayton Christian’s JTBD model in mind — what problem are you really solving?
  8. The common saying that “everyone is a patient” is untrue. There is a clear line between REAL patients with chronic illnesses that have to deal with the day-to-day challenges with our healthcare system vs. someone with a cold/cough
  9. Do not underestimate the importance of patient family groups and caregivers — sometimes your solution for patients might best be targeted at caregivers and not the patients.

Did you attend ENGAGE? What did you learn? Please share your thoughts below.

{ 3 comments }

It’s getting easier and easier to build unregulated software these days but it’s still pretty hard to create regulated/certified systems such as EHRs, medical device software, and government IT. To help create better systems we all know we need better user requirements; however, “heavyweight requirements” efforts have been shunned, especially in unregulated systems, over the past decade in favor of “user stories” and more agile specifications. But, are agile user stories the best way to go in regulated systems where requirements traceability and safety analysis is a must?  I invited Abder-Rahman Ali, currently pursuing his Medical Image Analysis Ph.D. in France, to come back and give us advice on whether there’s room for both user stories and SRSs in regulated industries or if we’re stuck with formal requirements specs. The following is Abder-Rahman’s third installment for this blog and I’m excited he’ll be tackling such an important topic. As always, he can be reached via e-mail or twitter.  Here’s what Abder-Rahman says about User Stories vs. Software Requirements Specifications:

It was on February, 2001, when seventeen practitioners formed what was called The Agile Manifesto. It seems that since then, we started to hear of the term User Story, although, as will be shown below, it seems that the term appeared before that date.

The questions that may pop-up on someone’s head are, is the User Story just a fancy name to the user requirement? Or, it is actually a new mindset of thinking in the way of dealing with user requirements?

Referring to Wikipedia about the history of user stories, I found that user stories originated with Extreme Programming (XP), but, it wasn’t until 2001, when Ron Jeffries proposed the Three C’s formula: Card, Conversion, Confirmation, where the components of the user stories were captured.

But, what are User Stories after all?

I really liked how Mike Cohn described User Stories, when he said:

User Stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

User Stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

Before moving ahead, and comparing User Stories with Software Requirements Specifications (SRS), let us see how SRS is defined. Based on Chambers, SRS describes the essential behavior of a software product from a user’s point of view, where the purpose of SRS is to be a basis for agreement between the customers and the suppliers on what the software product is to do; a basis for developing the software design; a basis for estimating costs and schedules; a baseline for validation and verification; reducing the development effort; facilitating transfer; and serves as a basis for enhancement.

After knowing what they mean, how can we compare User Stories with SRS? I saw that rather than bringing theory to this part, why not monitor some discussions related to this issue? I thus went through some discussions at a Programmers Stack Exchange thread, and came up with the following:

One of the people involved in the discussion mentioned: To be honest, after spending close to two years immersed in Agile development, I still think “User Story” is just a fancy term for “functional requirement”. That person continues: What User Stories almost never capture, in my experience, are non-functional requirements like performance and security. These kinds of requirements are very difficult to write properly and the format of the User Story simply isn’t very good for capturing them, because they’re more about general product quality and mitigating (but not eliminating) risks rather than meeting a specific user’s need. So, I really think of User Stories as a subset of requirements, with a specific formula, and still use the terms pretty much interchangeably. The one major advantage User Stories do have over requirements is that the word “requirement” suggests that a feature is required where it is often just desired. User Stories can in theory be prioritized and slotted in for any release, whereas requirements appear to be a prerequisite for every release.

Other opinions arise mentioning that SRS focuses on “how” the user interacts with the system, and “how” to implement the functionality. On the other hand, User Stories focus on “what” (interaction between user and system) purpose do features have, such that, the task of a User Story would be a functional requirement, and is the expected work product after the functional tasks have all been completed. Thus, they are completely different things.

Requirements assume that the design of the application is done beforehand, and development is considering the implementation of that design.

User Stories insist that the design of the product is done at the last minute, and is a collaboration between a product person and a developer person, and the details are decided during implementation.

So, as can be noticed, the amount of details provided is different using the two approaches, such that, in the User Story for instance, there is a lot of information that is available not available in the requirement, namely, what is we are trying to achieve with the feature.

Others go and mention that a functional requirement is a formal specification that allows one to know exactly if the software works or not. Whilst a User Story is an informal way to describe a need of one of the User Stories, such that, it doesn’t specify a rigid specification to determine if the software is valid or invalid. Although you can test some part of the User Story, its real completion is when the user says : “Yes, this solves my problem”.

We thus realize that the User Story is a huge paradigm shift in the way to approach the work to be done. A contract here is not made, rather, you are trying to help your user to solve a problem. If you don’t see your user stories as discussion tools with a real user, then you are actually not using User Stories.

This post can grow bigger and bigger, and seems that when people attempt describe the notions “User Story” and “user requirement”, such descriptions come from their experience, and how they use each of them. Going through the comparisons above may not reveal clearly the differences between both terms. For that, we chose to interview Agile experts about this issue, for which answers will be shown in the next post.

Stay tuned until then, and don’t hesitate to share your views in this topic, and how you approach those two terms.

{ 16 comments }

By some accounts, almost 30% of EHR users will be interested in replacing their software as they move from Meaningful Use Stage 1 to 2 to 3 over the next few years. Although I’ve written and spoken extensively in the past about how to make sure you pick the right digital health and EHR software, I wanted to put together a new “common sense” type of Do’s and Don’ts list for picking new EHR software. To help me out, I reached out to J.P. Medved at Capterra because of their unique expertise in this area. What follows are the dos and don’ts of each step in the EHR buying process; these tips will guide you when comparing options so you select medical software best suited for your needs.  They may also serve as a guide for software vendors who want to stand out from the crowd. Here’s what J.P. said:

Requirements

DO:

  • Make use cases to nail down your current processes and how they will be affected by a new EHR. For instance, “Currently the office manager handles all customer records in a paper filing system.  Records are checked out by a physician when seeing a patient, and the office manager notes which records are currently checked out in a spreadsheet.  Records are not allowed to leave the practice.”
  • Be deliberate and include the right people in coming up with your list of requirements. This step can save hours of headache later, and will also set you on the research path far ahead of others.  Sitting down with key stakeholders (office managers, physicians, nurses) who will use the software to figure out what they need out of it means you’ll already be armed with your requirements and can ask more educated questions during demos, and not be swayed by flashy features.
  • Be willing to change business processes. While it’s all well-and-good to know and be comfortable with your current processes, knowing when one of them is actually less efficient than one provided by software will prevent teeth-gnashing and costly customization in the future.
  • Consider these following essential EHR features when creating a requirements document: Billing functionality with support for the newest ICD codes, HIPAA compliant security, physician and patient scheduling, e-prescribing, “user friendliness” (which really means: consistent layouts, intuitive task sequences that match existing processes, tabbing support, autopopulating forms, and an uncluttered design), and document management. It’s worth also considering some non-essential, but extremely useful new features like patient portals, mobile access (though be careful with data security here), and voice recognition for note dictation.

DON’T:

  • Fall for flashy features. These include: fancy animations and cool graphics, shiny but proprietary handhelds and gadgets, good-looking but unusable design, and “decision support” pop-ups that waste time.
  • Demo before you’re ready. You should have your requirements document written, use cases detailed, and potential users consulted before reaching out to any vendors.
  • Include too many people in the purchasing decision.  While you should gather requirements from all your potential software users, only a limited number of people should be sitting in on demos and making the actual purchase calls.  According to 2013 research, the more people included in a software purchase decision the longer it takes and the less confident buyers feel during the process.
  • Fail to plan for the future. Your features and requirements should keep in mind how future growth will affect your work processes.

Shortlists
DO:

  • Get peer recommendations. Similar size and specialty practices with actual experience using a specific EHR will be able to provide you the most relevant information about it.  These are also likely to be less biased than vendor-provided references.
  • Use 3rd party directories and other lists of EHR software. When cutting down to a shortlist, you want to first see the whole range of options out there.  You may find a niche product that’s perfect for you which you otherwise would have overlooked.
  • Read online EHR reviews. Plenty of review sites have in-depth, honest reviews of EHR products.  Make sure to find ones that list both pros and cons as the latter is often more instructional.
  • Talk to vendor provided references. Though they may not be as unbiased as peers you seek out yourself, other practices already using the software will still have valuable insight, so long as you ask the right questions.

DON’T:

  • Only look at the most popular EHRs. Yes, they’re popular for a reason.  No, that doesn’t mean they’re the right fit for your medical organization.  With so many specialty EHRs on the market you may find your perfect option is not one of the big players.  Make sure to start out your search with a wide angle lens before narrowing your gaze to a targeted shortlist.
  • ONLY look at peer recommended software. Yes, peer organizations have experience with software you’re considering but, again, the EHR they’re using is not the only software out there.  You’ll miss a lot of great fits if you start out too narrow in your search.

Demos

DO:

  • Stick to 3-5 demos. This is the Goldilocks spot between too many demos to remember, and too few to compare.
  • Have a demo script. Outline ahead of time what functionality you want the vendor to cover in the demo, and make sure they stick to that schedule.  Otherwise you risk wasting time and not learning what you need to about the EHR.
  • Have a standardized demo scorecard for each vendor. A scorecard, with numbers assigned to different areas of functionality and user experience (i.e. “10 for User Interface but only 6 for e-prescribing”)will not only keep your process as objective as possible, but will also help you remember and compare different EHR’s demo performance after the fact.
  • Insist on an individualized, vs. a group demo. An EHR is an important, and costly, purchase.  You should have the opportunity to ask all the questions you need which are specific to your practice and processes.  This is unlikely to happen in a group demo where other physicians take up time with issues that don’t apply to you.

DON’T:

  • Get distracted by flashy features. Vendors like to emphasize what’s latest and greatest in their products, and often forget the importance of core, though more boring, EHR functionality.  Your job is to control the conversation and cover your requirements first and foremost.
  • Forget to take good notes.  Odds are you’ll be making a final decision weeks, or even months after sitting through demos.  If you haven’t taken the time to write down a thorough record of your impression of the software, the vendor, and the demo, you’ll be struggling to recall important distinctions.  Consider adding a notes section to your demo scorecards.

Others?

What other dos and don’ts are worth including in this list?  Have you already gone through the EHR purchase process and wish they did something differently?  As a vendor have you observed buyers making mistakes in their selection research?  Add your thoughts in the comments!

Editor’s note: You can follow J.P. on Twitter at @rizzleJPizzle.

{ 2 comments }

Patient portals have a future as a patient engagement tool if clinicians are on board and encourage their use

I wrote my first patient portal site, built into my first EMR software, back in 1998. At that time I mistakenly thought that portals would take off and patients would embrace them. What I quickly learned was that patient portals aren’t really portals in the sense of Yahoo! or Google but enterprise software’s customer-facing front-ends. The enterprise software in this […]

3 comments Read the full article →

How to improve your SRS by distinguishing between vague and ambiguous requirements in health IT and medical device systems

Because it’s so easy to build software these days we’re seeing a proliferation of healthcare apps — what’s hard to figure out is whether we’re building the right software. Abder-Rahman Ali, currently pursuing his Medical Image Analysis Ph.D. in France, has graciously agreed to give us advice on how to write good software specifications for health and medical […]

2 comments Read the full article →

ENGAGE can help pharma and biotech learn how to benefit from patient engagement

Patient engagement is something that physicians have done for thousands of years as they cared for patients (whether going to their homes or having them come to hospitals or clinics). With new digital health technologies the way providers can engage with patients is changing significantly but we’re not quite sure about the best ways to apply […]

0 comments Read the full article →

The future of medicine and the incredible innovations we can expect by 2064

The Fred Alger Management team reached out to me recently asking what innovative changes I thought the medical and healthcare industry will be going through over the next 50 years. It was for their innovative “Think Further” series: As Yogi Berra famously quipped “It’s tough to make predictions, especially about the future” but Alger’s “Future […]

1 comment Read the full article →

Top Ten Insights for Digital Health Innovators from the Next Generation Point of Care Diagnostics Conference

Cambridge HealthTech Institute (CHI) invited me to attend their Next Generation Point of Care Diagnostics Conference and I came away thoroughly impressed with the content, speakers, and organization. Since I chair several conferences a year I know how hard it is to pull off a good one so I’d like to thank CHI for a […]

1 comment Read the full article →

Encryption at rest and encryption in transit for HIPAA compliance are not easy questions to answer

Given the number of breaches we’ve seen this Summer at healthcare institutions, I’ve just spent a ton of time recently on several engineering engagements looking at “HIPAA compliant” encryption (HIPAA compliance is in quotes since it’s generally meaningless). Since I’ve heard a number of developers say “we’re HIPAA compliant because we encrypt our data” I wanted to […]

2 comments Read the full article →