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:



  • 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.


  • 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.


  • 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.


  • 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.



  • 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.


  • 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.


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.


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 case is of course an EHR and the customers are the patients. If patients are the consumers then their expectations are that they can conduct “business” with the practice through the portal. This means messaging, getting questions  answers, scheduling appointments, reviewing all records, etc. are minimal value propositions for a patient portal. However, even though portals are terrific opportunities for patient engagement, most portals’ technology architecture do not provide significant enough value for patients. I reached out to Cameron Graham, Editorial Coordinator at TechnologyAdvice, about what he’s seeing in the marketplace when it comes to portals. Cameron oversees market research for healthcare IT, business intelligence, and other emerging technologies and here’s what he had to say about how vendors and clinicians can encourage patients to use their respective portals:

Patient portals have the potential to simplify practice operations and reduce physician costs, but only if patients adopt and use them. We surveyed 430 people who had recently visited their primary care doctor in order to gauge how patients wish to communicate with their physician. Here some of the key takeaways from our survey for vendors and practices.

1. Physicians need to raise awareness about patient portal availability and benefits.

In our survey, 39.9% of patients said they didn’t know whether their primary care physician offered patient portal software. Given the high rates of EHR adoption among primary care physicians, and the increasing amount of EHRs that contain integrated portals, this is likely due to a lack of marketing. The responsibility for such marketing falls on physicians. Practices should consider implementing in-office programs to walk patients through available portal software, or deliver clear instructions to them prior to an appointment. Physicians should not assume that patients will investigate their websites or find such software on their own, even if told about it. At the very least, physician’s should provide each patient with an instruction sheet at the end of an appointment. Meaningful Use stage 2 requires that five percent of a practice’s patients utilize such a service. This threshold will only rise going forward, making effective promotion of such tools even more important.

To help promote increased patient awareness, vendors should consider investing in their own marketing campaigns, outside of any physician-led campaigns. Vendor involvement with EHR and health IT software is usually limited to the installation phase. However, it is in vendor interest to encourage patient awareness of such technology. Supplying practices with marketing materials, providing post-implementation support for customers, or even compiling an online list of each practice using their software could go a long way toward boosting awareness.

2. Patients still prefer hearing from physicians by phone, rather than through a portal, but younger patients are open to online appointment scheduling.

Our results found that just 13.6 percent of patients want to be contacted through a patient portal for general communications, while 14.1 percent wish to receive lab results and diagnoses through such a site. On the other hand, 42.7 percent want their doctor to deliver test results over the phone, and 42.9 percent want to receive general communication by phone as well. These preferences were consistent between age groups, except when it came to online appointment scheduling. 63.6 percent of patients aged 18-24 said they preferred using an online calendar to schedule appointments, while only 15 percent of respondents over the age of 65 chose the same.

These results suggest that physicians and vendors need to provide more incentive for patients to use online resources, if they want to move to a digital-first practice model. This could be done through increased marketing to consumers by vendors, or through physician led campaigns touting the benefits of online systems. Alleviating any security-concerns patients may have about posting health information online will likely need to be priority in these efforts. Younger patients may also be more receptive to portals, as they already prefer to schedule their appointments online.

Vendors should also place greater emphasis on the usability and intuitiveness of their patient portal interfaces. This would lower the barrier-to-entry for patients who are unfamiliar with features such as online appointment scheduling, or digital messaging. If vendors can ensure a positive first experience, it will also encourage patients to share their experiences with others, increasing patient portal awareness.

3. Almost half of patients report that their physician did not follow up with them after their visit. This is a significant opportunity for incentivizing patient portal usage.

47.9 percent of patients reported that their physician did not follow up with them after their last visit (outside of payment invoices). Of the physician’s that did follow up with patients, only 9.1 percent did so through a patient portal. Given the importance of patient engagement in modern healthcare, this represents an area for significant improvement.

Once physicians have shown patients how to use a portal, they still need to provide incentive for them to log on. Following up with each patient through these portals (which can automatically alert the patient by email that they have a new message to view) would help accomplish this goal. One of the ways for providers to meet the patient portals requirements for MU Stage 2 incentives is to have patients send them a secure message. The post-visit follow up provides a great opportunity for physicians to accomplish this goal.

To better encourage physician-patient communication (and therefore increased patient engagement), vendors can build in more robust automation capabilities, and place a larger emphasis on this during their training. Offering best-practice guides for engagement could also be a step in the right direction. If physician’s can easily automate the follow-up procedure based on information from the patient’s visit and the electronic health record, engagement rates (and portal usage) will likely increase.

Note: You can Connect with Cameron on LinkedIn or Google+.


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 technology solutions. Some of you are probably rolling your eyes and thinking that software requirements specifications (SRS) are old and “tired” and we should be writing agile user stories instead. The reality is that in regulated and safety critical environments we still rely on SRS documents but the complex nature of systems of systems is making even those documents difficult to write. So, we’ll be talking requirements instead of user stories for now. The following is Abder-Rahman’s second installment, focused on vague and ambiguous requirements. He can be reached via e-mail or twitter

Sometimes, when we pass by a software requirement that is not clear enough, we may say it is vague, and in another occasion, we may say it is ambiguous. Yes, we added such two features to that same requirement by that same person. But, did that person just use those two terms to refer to that that requirement was unclear? Does he just use those two terms interchangeably? Well, the bottom line, do vague and ambiguous mean the same at all? Or, they refer to two different things? This is what we will investigate in this article of our series.

Before beginning this topic, let us see how dictionaries define the terms vagueness and ambiguous.

Of the ways how Merrian-Webster dictionary defines the term vague is as follows:

Not clear in meaning: stated in a way that is general and not specific

Not thinking or expressing your thoughts clearly or precisely

Not completely formed or developed

Whereas, if we see how the same dictionary defines the term ambiguous, some of how it defines it is as follows:

Able to be understood in more than one way: having more than one possible meaning

I like how Diana Santos distinguishes between those two terms in her book, where she argues that vagueness is related to the language system, and thus, is considered systematic, and is a frequent property of the language. Whereas ambiguity is considered an unsystematic and accidental property.

Diana also stresses that for an expression to be vague between A and B, there should be a shared content. That is, having the same linguistic object doing double duty. In this case, we can consider the cases of “either A or not A” as an instances of vagueness. This Vagueness is automatically reflected in the speaker’s performance since it is an essential property of the linguistic system. But, if we go towards ambiguity, most ambiguities produced by speakers go unnoticed, since as we mentioned, it is considered unsystematic.

Put in another way, invitation to critical thinking takes us to the following; If we want to say that a term or expression is ambiguous, is to say that it has more than one conventional meaning. That is, it can be conventionally understood in more than one way.

Let us take an example. If you hear the word “bank”, what would it mean? Some of the meanings for “bank” are as follows:

  • a noun for piled up mass, such as snow or clouds
  • a noun for the slope of land adjoining a body of water
  • a value for the action of putting something of value away in safekeeping

The book also points out that for a term to be vague means that it is not entirely clear what it does and doesn’t apply to.

Cognitive Linguistics: Basic Readings, sums the above up, by mentioning that the difference between ambiguity and vagueness is a matter of whether two or more meanings associated with a given phonological form are distinct (ambiguous), or united as non-distinguished subcases of a single more general meaning (vague). An example for ambiguity as we mentioned is the term “bank”, where the meanings are quite separate. An example of vagueness is “aunt”, where it can mean “father’s sister” or “mother’s sister”, thus, the meanings are united into one meaning, that is, “parent’s sister”. So, the bottom line is that ambiguity corresponds to separation of different meanings, and vagueness corresponds to unity of different meanings.

So, I think we should now start admitting that there really exists a difference between those two terms, shouldn’t we?

Let us come back to software requirements. As Ben Rinzler mentions, the requirements statements must define a specific and testable outcome. That is, a way to measure that the requirement has been met has to be provided. But, such precision will diminish with vague and ambiguous requirements.

Rinzler continues; a vague requirement is that requirement that does not include enough information to establish exactly how to meet the requirement. On the other hand, an ambiguous requirement can have multiple meanings. Such requirement may sound precise, but defines the desired result in terms that can be interpreted in more than one way.

Let us take an example on both vague and ambiguous requirements to make this more clear.

An example of a vague requirement is the following:

The system shall be able to read updates from MedImg

The above requirement is considered vague since what will be “read” and what happens to the data was not specified.

This requirements can be improved as follows:

The system shall be able to import new tumor patient data supplied by MedImg to the radiology management system, for evaluating the tumor to be malignant or benign

An example of an ambiguous requirement is the following:

The system shall be able to provide historical reports

Here, we have to specify what we mean by “historical reports”.  Thus, the requirement can be improved as follows:

The system shall be able to provide patient tumor data for the past five calendar years

We will end up the article here at the moment, so it doesn’t grow bigger for the reader. The main point to remember is that vagueness and ambiguous refer to two different terms, and they are factors that diminish the requirements’ precision and its ability to be measured and evaluated.

Stay tuned for the next articles, where we will dig more deep on how to deal and work with such uncertain requirements, and how can we present them in a precise manner.



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 that technology. This is why I’m looking forward to attending’s ENGAGE conference next week in Washington, DC. Most of these kinds of conferences focus on providers but I think that biotech, med device, pharma, payers, and others have much to learn as well. I reached out to our Digital Pharma Editor Vik Subbu to tell us what pharma and biotech can learn about patient engagement at ENGAGE. Here’s what Vik said:

The term “digital health” for some pharmaceutical and biotechnology companies has traditionally focused on supporting marketing strategies for their product launches, branding and access to providers.

However, with the incentives provided through the Affordable Care Act – patients, payers and providers are increasingly adopting mobile health solutions to coordinate patient care activities. As a result, mobile health solutions have transformed into effective patient engagement platforms enabling the seamless, multi-dimensional connectivity amongst these key stakeholders to provide a holistic view of patient care. Such platforms can help provide real time feedback and management of a patient’s episodic events, chronic illnesses and general health and well-being.

Why should pharma and biotech look beyond just sales when it comes to patient engagement?

Pharma and biotech companies should consider looking beyond pure sales and marketing uses and become more engaged in the development of mobile health solutions alongside payers, providers and most importantly patients. Being engaged early on can potentially provide meaningful insights on patient care and therapy use that can help better design future products and clinical trials. For example, understanding patient unmet needs based on lifestyle patterns, adverse event reporting from therapies, developing better inclusion/exclusion criteria etc.,

How will pharma and biotech companies benefit in the future from patient engagement?

Remote monitoring, wireless sensors, e-prescribing, social media provide direct patient access and a vast amount of data. If captured and structured appropriately from the outset, pharma and biotech companies can leverage the insights gained from this data for effective, real-time product and business decisions. Patient engagement platforms can be viewed via a connected approach as follows (1) patient gets prescribed a therapy (e-prescribing) (2) patient is able to provide real-time physiological updates to his/her physician (remote monitoring) and (3) the patient is able to share his/her experiences on a particular therapy with fellow patients (social media). Such real-time actionable patient engagement can enable pharma and biotech to observe key datasets related to patient care and in turn make meaningful and actionable business decisions.

As a newcomer in the digital health space with vast experience in life sciences, I envision that digital health will play a vital role on a number of fronts (research, clinical, new products, revenue sources etc.,) for pharmaceutical and biotech industries in the coming years.

The ENGAGE conference provides a perfect forum to initiate this understanding.


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 →

How to tackle vague requirements in health IT and medical device software using fuzzy logic and storytelling

These days it’s pretty easy to build almost any kind of software you can imagine — what’s really hard, though, is figuring out what to build. As I work on complex software systems in government, medical devices, healthcare IT, and biomedical IT I find that tackling vague requirements is one of the most pervasive and […]

5 comments Read the full article →

Learn how to operationalize new health IT wisdom at HealthIMPACT Midwest in Chicago on September 8

Our vision of providing a series of packed one day events focused on practical, relevant, and actionable health IT advice were very well received in Houston, NYC, and Santa Monica earlier this year. Our next event is in Chicago and we’re going to continue to eschew canned PowerPoint decks which limit conversations and instead deliver on the […]

0 comments Read the full article →

To improve patient satisfaction, hospital supply chain units need better IT and next generation technology

I’ve been looking at hospital supply chain automation and the IT surrounding it for a number of years now. Starting with Cardinal Health but then moving on to help a number of other vendors in the space, I’ve felt that there’s not been enough next-generation tech being applied to the low margin, high volume business of hospital […]

1 comment Read the full article →