Tag Archive for: healthcare

In this blog, we discuss key takeaways from a recent whitepaper written in conjunction with Beanstock Ventures on digital health technology.

What is Digital Health?

Digital health merges digital technologies with health, healthcare, living, and society to enhance the efficiency of healthcare delivery to make medicine more personalized and precise.

Digital health is a broad category that includes:

  • Mobile health (mHealth)
  • Health information technology (IT)
  • Wearable devices
  • Telehealth
  • Telemedicine
  • Personalized medicine

Digital health technologies use:

  • Computing platforms
  • Connectivity
  • Software
  • Sensors

RELATED POST: Ensuring FDA Compliance for Your Digital Health Solution

The Rise of Digital Health 

The past decade has ushered in major disruption in all industries, including the medical device and life science sectors. Market disruptors such as smartphones, social media and more transformed the way that people work, play, and manage their health. Software has transformed how doctors practice medicine, how people manage their health, and the fundamental interactions between patients and providers. During this process, the boundaries between digital health and medical devices began to blur.  

According to the Food and Drug Administration (FDA), “Digital health technologies use computing platforms, connectivity, software, and sensors for healthcare and related uses. These technologies span a wide range of uses, from applications in general wellness to applications as a medical device.” These applications are driving a lot of the wearables we see today, like a heart rate monitor running on a smart watch or a mobile application connected to a wearable. Other examples of digital health applications might be something like 23andMe, which uses genetic sequencing data to identify health risk factors.  

The Emergence of Software as a Medical Device (SaMD) 

Traditionally medical devices have been classified as an instrument, sometimes with software running on the actual device itself. 

The lines between digital health technology and medical devices get crossed once the software technology begins to perform a medical function, especially if the technology is not embedded within the medical device. Consider software that determines the right medicine dose for a patient based on his or her personal data, or software that detects and diagnoses a stroke through analyzing MRI images. These are examples of software that could be serving as a medical device. 

As digital health has pushed further and further into the traditional realm of medical devices, an entirely new category was formed and regulated, which is software as a medical device (known as “SaMD”). SaMD is described as “software that performs one or more medical functions. While the software may be embedded in a piece of hardware (as is often the case), it’s the software itself that performs the medical function.” 

With the emergence of software as a medical device, there are questions around risks, regulations and safety. Understanding trends and potential risks can help teams mitigate challenges and navigate forward with greater success. 

To learn more about keys to success and best practices in the digital health medical device market, download the full whitepaper. 


At Google’s I/O developer’s conference in May, Google CEO, Sundar Pichai blew minds by demonstrating Google Duplex, a feature of Google Home and Assistant, which made a simple phone call to book a hair appointment.

If you missed the demonstration, it was an ordinary call made extraordinary because the conversation between Google’s machine and the salon’s receptionist was indistinguishable from one between two humans.

The demo ended up being an incredible, viral moment that highlighted the power of modern Artificial Intelligence for a wider audience. It also helped showcase how we’re only just beginning to glimpse the potential of AI, and there are still plenty of concerns around its abilities.

Forward-thinking minds like Stephen Hawking and Elon Musk have all warned about the consequences of AI, and it’s worth wondering about its imminent application in an industry as crucial to human survival as health care.

As venture capital firm Rock Health notes, health companies are leveraging AI and machine learning and raising a ton of money in the process — $2.7 billion from 2011 through 2017, to be exact.

A lot of the enthusiasm for the burgeoning technology comes from the belief that it has the power to revolutionize a wide range of areas within the industry, from creating cutting-edge medical devices to reducing misdiagnosis, advancing precision medicine to delivering faster, better care to at-risk patient groups.

That’s not to say everyone is jumping on the AI bandwagon blindly. Many are also weighing issues like patient perception, privacy concerns and potential disruption. Plus, the medical industry has seen its share of new, heavily-touted, messianic tech that hasn’t panned out. To gauge the debate, we put together some current pros and cons of artificial intelligence in healthcare.

Pro: Improving Diagnosis
Studies on diagnostic errors in the U.S. report overall misdiagnosis rates range from 5 percent to 15 percent and, for certain diseases, are as high as 97 percent.

Misdiagnosis is an understandable problem for doctors, as the World Health Organization’s International Statistical Classification of Diseases and Related Health Problems (ICD) lists about 70,000 diseases in total, with fewer than 200 presenting actual symptoms.

Assuming it’s been loaded with all the relevant data, an AI-equipped product has the potential to sift through disease data, clinical studies, medical records, genetic information and even a patient’s health records far quicker and more efficiently than a human physician for a more accurate diagnosis.

Con: AI Training Complications
According to Dr. Robert Mittendorff of Northwest Venture Partners, one significant challenge to AI in health care is the lack of curated data sets, which helps in training the technology to perform as requested through surprised learning.

“Curated data sets that are robust and have both the breadth and depth for training in a particular application are essential, but frequently hard to access due to privacy concerns, record identification concerns, and HIPAA,” Mittendorff as says in a recent Topbots article.

Pro: Better Serving Rural Communities
AI could benefit patients living in rural communities, where access to doctors and specialists can be tough. According to Stanford Medicine data, fewer than 10 percent of physicians practice in these communities.

At the Association of Academic Health Center’s 2017 Global Issues Forum, Dr. Yentram Huyen, General Manager, Genomics & Data Exchange, Health & Life Sciences, at Intel said that one way to address that problem is through collaboration for better data.

“Health centers should collaborate on the data, enabling an idea of federated data analytics,” Huyen says, according to Elsevier.com. “It is critical to break down the information silos. We have to think about how we’re going to collaborate and share the data to form [health care] partnerships.”

Con: Change is Tough
The health care community is still somewhat jaded by the last technology that was going to revolutionize the industry, electronic medical records (EMR).

EMRs were supposed to make everyone’s job easier, from the billings clerk all the way to the physicians. For all its benefits though, many found implementation to be a costly and time-consuming disruption to practices. And, as anyone who has experienced a new technology rollout at a company can attest, if things aren’t handled correctly, widespread adoption can be a major issue.

So for AI to be accepted by the medical community at large, it’s going to require, not just proof that it works, but a project plan that includes input from all stakeholders and evidence it’s worth the investment.

As Google’s demonstration showed the world, AI will be capable of handling complex and unexpected questions as long as it has plenty of good data to begin the process of deep learning.

The people serving in health care and those who supply goods and services to the market would be smart to develop and share a mutual understanding of AI. One thing everyone seems to agree on is it’s just a matter of time before we see it implemented in our health care system.

The future of healthcare is evolving rapidly, and companies building forward-thinking medical devices and related-products must also ensure they’re meeting modern quality and compliance standards. Learn how Jama Software can help by reading this profile of RBC Medical Innovations. 

Author Traci Browne is a freelance writer focusing on technology and products. 

As the global population continues to explode, the world’s healthcare systems are straining to keep up with increased demand.

That’s why some outside-the-box thinking is necessary to keep the planet’s population healthy as it inches ever closer to 10 billion people.

Recently, at the second-annual Health++, Stanford’s Health Hackathon, some of the brightest engineering, product design and technology minds in the world came together to put their knowledge and passion to use in an attempt to alleviate some of the world’s heaviest health challenges.

More than 300 flocked from all corners of the globe to Stanford University in Stanford, California, for a caffeine-fueled weekend of coding and prototyping health tech products and apps. The following are six of our favorite innovations to come out of the hackathon.

YourPacifier
One of the hackathon’s winners, YourPacifier is a smart pacifier that monitors an infant’s hydration levels. While in use, YourPacifier continually senses the humidity of a baby’s lips, sending gathered data to an accompanying app.

When an anomaly is detected, the app alerts the parents, prompting them to answer some basic questions, which then determines whether re-hydration or even hospitalization may be necessary. The pacifier even includes an oral rehydration solution, which can be automatically administered in the event the child becomes severely dehydrated.

The team was inspired to create YourPacifier after seeing many children with severe dehydration in hospitals in Asia and the Pacific Islands, and learning that dehydration and diarrhea kill more than half a million children under age 5 each year.

Mobile EMT AppMobile EMT
When faced with a sudden injury, seconds count in determining what steps are necessary to get the appropriate medical attention.

Mobile EMT is a mobile solution that provides doctors with real-time access to your vital signs from anywhere in the world.

The system allows doctors to evaluate patients remotely and determine whether specialist intervention or hospitalization is necessary, or provide general medical assistance.

The idea is to equip EMTs with an app and a wireless device capable of recording vital signs. The device’s findings are then broadcast to doctors who specialize in treating the specific condition afflicting the patient.

MediBot
Chatbots are all the rage this year. MediBot harnesses that technology to give the nation’s 70 million low-income Medicaid patients easy access to detailed information on the program, as well as connect them to a physician who accepts it.

Using a Facebook Bot, patients can send messages 24 hours a day from anywhere to do everything from determine Medicaid eligibility, to find out who to call if you lose your insurance card. It even places automated calls on your behalf to check your Medicaid enrollment status.

The development team chose Medicaid recipients because they felt it’s a population currently underserved by innovators.

NutriLink
NutriLink AppIn the developing world, child malnourishment is a pervasive and deadly problem. In India, a lack of centralization of the government’s nutrition centers limits their usefulness, leaving children in desperate need going without treatment.

NutriLink allows users to locate the nearest government-run nutrition centers across India using Google Maps, displaying all local centers in an easy to read interface.

It can provide real-time information about capacity and bed availability at the centers, as well as contact information and directions.

Alexassist
As the world’s population ages, more people than ever are living with chronic medical conditions that need regular monitoring for the patient to stay healthy and live a longer life.

Leveraging Amazon’s Alexa voice assistant, Alexassist is designed to help patients monitor their chronic health conditions, such as diabetes, with a simple, voice-controlled interface.

The program, built using a Raspberry Pi 3, can even alert relatives if the patient’s health takes a turn for the worse. It acts as a sort of virtual in-home healthcare provider, offering helpful reminders to users to take medication or test their blood glucose levels.

Found in Translation
Effectively communicating with a physician is a critical aspect of patient care, but what happens when the doctor and patient don’t speak the same language?

Enter Found in Translation, an app that acts as an interpreter, providing real-time translation of conversations between doctor and patient.

Using voice recognition and Google Translate, the app allows both parties to communicate freely — in their native languages — to impart critical health information or diagnoses.

These were just some of the products and apps the hackers created at this year’s event. The innovation on display is all the more impressive considering each team built or developed their ideas from scratch over the course of a weekend.

There’s truly some incredible thinking happening in the health tech space, and we expect we will continue to see even greater things to come.

The future of healthcare is evolving rapidly, and companies building forward-thinking medical devices and related-products must also ensure they’re meeting modern quality and compliance standards. Learn how Jama Software can help by reading this profile of RBC Medical Innovations. 

There has been no shortage of press surrounding the HealthCare.gov October 1st release. Much of the debate points fingers at individuals often skewed by political leanings and party affiliation. Regardless of the political circus there are important lessons to be learned that highlight yet another glaring example of the importance of open, iterative collaboration around building products. This is not a new problem, nor is it unique to government. This is a problem faced by some of the world’s largest companies. Both Microsoft and Apple have recently experienced less than stellar rollouts: Surface estimated as a $900 million mistake and Apple Maps, which prompted a $30 billion loss in stock shares.

The fact is that when developing massively complex products in a broken system with insufficient tools, issues will be amplified. In the fallout of the much-anticipated HealthCare.gov release, the typical reactions are taking place; blame the most senior person available and throw tons of last minute resources at the problem in an attempt to fix it. None of this will work because the damage has been done – the source of the problem is cultural and ingrained in the process. Anthony Wing Kosner’s piece in Forbes discusses one aspect of the problem centered around the definition of the requirements themselves. Kosner discusses the fact that an estimated “40% of the defects that make it into the testing phase of enterprise software have their root cause in errors in the original requirements documents” and that government project requirements can be especially difficult to manage.

I have experience working on an implementation that suffered similar issues, and am especially frustrated with the state of HealthCare.gov because since then I’ve been reading about the many initiatives to incorporate Agile or Lean concepts into government software products. There are instances where taking an open, collaborative approach has paid off; one great example is the implementation of Recovery.gov and FederalReporting.gov. The success stories incorporated iterative processes that enabled changes to be more easily and effectively implemented, as opposed to HealthCare.gov, whose architects have cited changes in requirements as a root cause of issues.

Each set of changes created a new version of the document that needed to be shared across many teams. For example, Andrew Slavitt, vice-president of Optum explained to lawmakers about the late decision requiring consumers to register for an account before browsing insurance products. This highlights the typical occurrence of change, but begs the question: is the late decision the problem or is it how that decision is managed and ultimately communicated to the rest of the team? Compounding these problems is the fact that especially in government there are multiple contractors involved that are not incentivized to work together. The success of the their work is more important than the success of the project as a whole because contracts and payments are based on those deliverables. This fosters an environment of CYA as each contractor spends more time making sure that they are covered based on their individual contract and less on the idea of building the right solution.

The sad thing is that it’s hard to blame the contractors, developers, QA or even the government. The problem is in the status quo we all accept. Organizations continue to resist the inevitable need to make overarching changes to their process and tools to move away from such avoidable chaos and lack of communication. Based on this fact and my past experiences, there are 4 key lessons to be learned from the HealthCare.gov story:

  1. Initial expectations and visions are often too vague and lofty. In the instance of HealthCare.gov, acceptance of change was not considered early on. Implementing such a complex system is not as simple as defining a set of requirements and pushing them downstream to be built. It takes a highly coordinated effort full of constant communication and realignment to change. There needs to be a conversation about how to handle unpredictability.
  2. Allow for voices to be heard sooner. If there are no clear paths of communication that connect the business side to the implementation and test side there is an increased risk of misalignment, discontent, frustration, and delays that ultimately create a fast moving train of costly issues.
  3. Allow for innovation to thrive throughout. Were there options to rethink the requirements themselves? One such possibility was the requirement for each user to receive an immediate confirmation based on complex integrations and system checks. Would it have sufficed to let the user know their information was accepted and would be processed over the next 7 business days?
  4. Tools. If those who built HealthCare.gov are anything like many major organizations and companies they were likely relying heavily on Word documents to send requirements. When will we learn that this is an archaic means of communication? This method does not in any way help with managing the constant influx of changes notorious with government contracts.

My own experience working on a government healthcare software project took place 6 years ago when I worked for a contractor who was tasked with designing a state Medicaid eligibility program. The realities and problems my team faced back then have a striking similarity to the failings of the HealthCare.gov rollout. I was a developer at the time and was part of a team that had been put together based on a set of requirements that were written as an RFP and awarded to the contractor. Based on those initial requirements, estimates were created and resources were assigned to the project. As is common in RFPs, a year passed between the award and the final team being assembled, during which requirements changed. This common occurrence is most often the initial point of failure as teams quickly fall out of alignment, while scope and schedule became a constant topic of debate.

As a development team, we worked in a very Agile manner and provided frequent working software to the customer. Still, the complexity and volume of changes made it very difficult to be efficient, the schedule changed often and resources were staffed up in an effort to increase velocity. Luckily we had some flexibility with dates and a lot less visibility nationally.

Why does this status quo continue to dominate and dictate how we implement projects? The government is not alone in the challenges they are facing in so many products and programs. At my company, we often receive RFPs that are frankly outdated and irrelevant. The RFP model is broken and the idea that requirements are to be used as a binding contract that if changed puts both parties at odds, prevents teams from doing what’s right and speaking up if they sense something is wrong. RFPs are not the only culprit, requirements used as a binding contract set the tone. The agile manifesto highlights this point: “Customer collaboration over contract negotiation.” This isn’t to say there isn’t a need for contracts. HealthCare.gov may have failed just as much had there been no contracts involved. It’s easy to say generically that an agile approach would have done better, especially considering many over emphasize the desire to eliminate requirements all together in lieu of complete “we’ll figure it out as we go along” mentality.

The balance is in providing the goals (the requirements) in parallel to a more open, iterative, and collaborative process that is necessary in order to deliver products that fulfill requirements and are completed on time. The requirements and decisions themselves should have been in a place that was available to all that could handle the complexity and balance of requirements that change the speed necessary to make critical decisions when they can’t be changed. We are at a day and age where how we collaborate has fundamentally changed. Organizations need to take advantage of both the concept of agile – keeping in mind the key quote “…while there is value in the items on the right we value the items on the left more.” – and tools and technology built on modern methods of communication.  Had this been in place for HealthCare.gov, changes to requirements would have been clear, communication would have been open, and decisions made would have been communicated immediately. All of that information would have been easy to track and maybe we wouldn’t be in this state of constant blame.