6 things physicians wish health IT developers knew

Input from physicians and patients is vital to the development of successful digital health solutions, but what are some of the top things developers need to know to start this process? Physicians, developers, professors, bloggers and med students all weighed in last week during a vibrant #AHealthierNation tweet chat on the future of digital health.

Designing the future is an indefinite process. The input of those who will live in that future is critical. Here are six things to take away from Thursday’s tweet chat:

Physician interest exists

Many participants agreed that physicians don’t need a push to get involved in digital medicine.

@jkvedar: “Where I am, many want to innovate—so not too much nudging required.”

@Geneia: Physician involvement “allows for their insight so that solutions fit seamlessly into existing work flow [at the] point of care.”

Physicians embrace new technologies and want to be involved in their development. On the flip side, when these innovations do not fit into practice work flows, they only cause more frustration.

Start with the problem, not the solution

Though digital health products often solve problems, they aren’t always the problems that physicians experience every day.

@BreastDocUK identified the problem: Physicians are “too often presented with a solution for [a] problem we didn’t recognize.”

@Cascadia offered a suggestion: “Have docs identify problems they want solved and do a reverse pitch to [the] tech community.”

Physicians want to be involved from the ground floor, and their voices need to be heard at the crucial moments of development. So where does the door open to this ground floor?

@AmerMedicalAssn pointed to a simple way: “A tangible way for physicians to connect to entrepreneurs is via our new network.” The Physician Innovation Network, which aims to put physicians in direct communication with developers from the beginning of projects based on interests and needs, is part of a recent collaboration between the AMA and Chicago health tech incubator MATTER.

@jkvedar noted another option: There are “lots of hackathons and pitch offs in the Boston area,” but he added that he is “not sure that is the best way.”

@HavasLifeMetro offered a resource to learn more about the effectiveness of hackathons.

Get both physician and patient feedback

There are two kinds of end users when it comes to health IT—physicians and patients. Both must offer feedback and insight in the development of digital health solutions.

@VerbalCare: “As a company designing these solutions, involve physicians AND patients in the dev[elopment]. Take into acc[ou]nt their feedback!!”

@jashenson: “Close the feedback loop. Help doctors see how their feedback leads to new [and] improved digital health tools.”

@drnic: “Build the feedback mechanism into the app/work flow and make it easy.”

Simplicity in design leads to efficiency … and happy end users

In response to the question, “What are the biggest challenges for two very different users: physicians and patients?” the crowd concluded that too much design can stunt the evolution of digital health technology.

@StevenStackMD: “They really need different tools and different designs. EHRs fail by trying to be too many things to too many people.”

Often, overdesign can lead to parallel work flow, which does not solve problems but rather adds additional processes to daily practice.

Michael Hodgkins, MD, via @AmerMedicalAssn: “The common ingredient and most important factor, no matter who the user is, is accurate and easy data/info sharing.”

Physician-patient engagement is a two-way street

Getting patients involved in their own care is a key contributor to satisfaction for both patients and physicians. If patients can see their medical data, better understand results and gain access to more information regarding their health, then a partnership begins, and the relationship sees equal effort from both sides. And that results in even higher quality care.

@Geneia: “Patient engagement & good physician-patient relationship helps involve the patient as a key contributor to their [own] care. ... We’ve found w[ith] remote monitoring when patients see their data, they’re more empowered.”

One physician disagreed that wearables are currently ready for implementation, citing that they need more accuracy and must provide more clinically relevant data in order to avoid the many inaccuracies with wearables that clinicians have seen so far.

Wearables can be mistaken for a trend, but physician adoption and promotion could validate wearables as an added layer to patient engagement.

@BreastDocUK: “We engage patients by showing that we are interested and that they are genuinely central. Give [patients] the tools to lead.”

Developers need to understand physician work flow

Even when physicians are presented with a digital solution that solves one of their most critical problems, often the solution does not fit into their work flow and only adds chaos.

@jashenson: “Need for efficiences is well accepted, but lack of work flow understanding prevents efficient tools.”

So how can developers gain insight into physician work flow? Physician input is the only answer. To avoid another disconnect between development and work flow—like the one we saw with electronic health records—physicians need to speak up, and developers need to listen.

Dr. Hodgkins: “We have a chance to avoid that disconnect with this new wave of technology intended to improve patient care.”

Comments

As usual, physicians complain, AMA feigns sympathy and action, and nothing gets done.<br/> <br/> Having developed medical software, and participated in two highly successful software companies, I've gained considerable insight into how to approach software development. When the developer of the product is a practitioner or expert who comes from the subject field rather than the IT universe, the end product is much more useful and succinct than one developed by IT "experts" who utilize samplings of practitioners' inputs. <br/> <br/> In other words, physicians should be the "Developers". It is a lot easier for physicians to learn about software architecture than for programmers to learn about medicine and healthcare delivery.