When I went to my first healthcare technology conference, Health 2.0 (2009), the energy in the air was palpable.  Everyone thought their "remote patient monitoring with a social network so you're always connected with your physician" app was going to revolutionize healthcare delivery.  With hindsight, it's safe to say that the majority of these companies missed the mark.  Although not short on imagination or technology, they missed a fundamental understanding of healthcare technology adoption.  Radical change does not sell to the healthcare masses.  To understand why it's important, look at the mindset of the clinicians and the healthcare organizations.

Right now, clinicians have the same mindset that consumers had when we were using Windows '95; they expect technology to fail.  Not only do they expect it to fail, they expect it to get in the way.  Every new go-live will bring with it hours of training, workflow disruptions, new systems to learn, and added work to their plate.  The healthcare organizations feel the same way as most projects go over budget, cause months of headaches, and lead to upset clinicians.

Radical change is not accepted because everyone has seen what happens with poorly implemented technology.  Instead, what you should be doing is focusing on the one piece that solves a current need for healthcare organizations.  Then do it - really well.  Healthcare organizations can swallow incremental changes because that one piece, done well, will provide them the efficiency, workflow, and quality gains they are looking for.  

Bottom line: Selling incremental change over radical change will greatly increase your likelihood of success.  

Permalink | Leave a comment  »

Healthfinch is looking for a lead developer and lead UI designer to add to our team.  Both jobs are located in Madison, WI but remote is also an option.

Lead Developer

We focus on apps and tools that add-on to electronic medical record to improve patient safety, reduce administrative overhead on clinical staff, and save organizations time and money.  Our ultimate goal is to make lives easier for clinicians and better for patients; it's as simple as that.

We'll hire an intern for the spring, but only if you're able to go full-time after your internship ends.

Requirements include:

• Knowledge of Rails/Javascript/Coffeescript
• Strong experience with modern web development
• Understanding of the MVC design pattern

Extra credit if:

• Starcraft APM 50+
• Experience integrating with EMRs
• Working knowledge of HL7
• Experience designing and testing RESTful APIs
• Interest in working with large amounts of data and analytics

Benefits include:

• Competitive salary
• Stock options
• Great working environment
• And that's just the beginning!

If you think you're up to the challenge send something to jobs@healthfinch.com that proves it. This can be a code sample, github profile, URL for an app you built, or anything else that you're proud of.

Lead UI Designer

At Healthfinch you will be working in healthcare, an industry which is in desperate need of a design revolution.  In fact, that's why we founded Healthfinch because we believe good design can make all the difference.  You will be designing applications and experiences through tools which add-on to the electronic medical record.  Our ultimate goal is to make lives easier for clinicians and better for patients; it's as simple as that.  This could include everything from designing a new portion of our existing application (RefillWizard), coding your new designs, tightening up the copy, creating marketing pages to better convey what we are about, doing a little client work (implementation), or maybe even working in the sales process.  We are going to be expecting a lot out of our designers, so make sure your up to the challenge!

Requirements include:

• Being able to create mockups/sketches
• Performing user testing on those mockups
• Turning those mockups into hi-fi application designs
• Coding those designs in HTML and CSS
• Strong command of the English language
• Willingness to stand by your design decisions
• Passionate about solving problems in healthcare
• Love of Apple products

Extra credit if you:

• Can code in Javascript or have other web development experience (we use Rails)
• Have experience in healthcare IT
• Have ever sold anything
• Read Hacker News

Benefits include:

• Competitive salary
• Stock options
• Great working environment
• And that's just the beginning!

If you think you're up to the challenge send something to jobs@healthfinch.com that proves it.  This can be application designs, mockups, copy, or anything else that you're proud of (don't be shy!).  

Permalink | Leave a comment  »

A while back I mentioned that HIT usability was so problematic, the Government was starting to get involved (See post, "War on EMR usability").  Now, we have a much better ideas of what this mean with the recent release of the NIST document "Technical Evaluation, Testing, and Validation of the Usability of Electronic Health Records".

After reading this, I must start with a question.  What is the purpose of this document? Is the goal of the article to educate vendors on best practices? Will this report serve as a foundation for evaluating usability of EMR systems that will be published to consumers? Without this end point in mind, it’s hard to judge the merit of the report.

Waterfall design, really?

With that said, the methodologies outlined in the report contain little groundbreaking information, but is a rehash of what is considered best practices in the field of human-computer interaction. My major problem with the report is the emphasis placed on a “waterfall model of design” (see Figure #1).

First and foremost good design is a process. It is not something that can done once or injected at the very end of the development cycle. You can’t put “lipstick on the pig” and call your software usable. The best design companies have taken these principles to heart very early in the design process by constantly testing and modifying their product. Design is iterative. When you wait until the very end of the development process to run usability tests with your users you’re going to find problems – lots of problems. At that point, what is a vendor going to do? Miss a shipment deadline or send less “usable” code? I’m going to guess the former. Add to that, the usability testing will uncover major code rewrites often times requiring starting from scratch. Don’t make the mistake of assuming usability is going to uncover only aesthetic problems. This report needs to place a greater emphasis on iterative, rather than a once-through (waterfall) design process.

Developers != Designers

If you’re going to improve vendor design, it has to begin with an internal commitment to value designers and what they contribute to the product development process. They cannot be an afterthought. There are very few companies with this mindset. Almost all HIT companies are developer-driven, so the first thought, and one that is promoted in this report, is to turn developers into designers. This will not work! A developer and a designer require two fundamentally different skill sets that are not easily transposed. Developers are trained to think rationally and analytically; design requires empathy for the user.

Trained designers have a hard enough time in HIT because most of them are not clinicians. It’s much easier for a designer to create a new social network because we have used them. It’s much hardly for HIT designers to judge the value of the solution. That is why it is crucial to have a clinician apart of the design process. They can add the insights that the designer could never see. It’s hard enough for a trained designer to develop useful solutions in the HIT space, yet alone asking a developer to do the same.

I don’t think that vendors are going to change to this designer-centric development process voluntarily, so how is this report going to push them?

Some other thoughts

Why test applications in a sterile user testing environment? One of the biggest problems in HIT is that software is not designed with the clinical workflow in mind. How often have you seen a software tool that supports the interruptions that are common in a clinician’s day? By keeping the software in a controlled environment everything will look fine, but once it's in the wild the problems will show themselves.

The highlight of the report for me, were the HIT examples in the Appendix. They did a great job of capturing healthcare use cases.

When testing task competition times, why not assume expert users? If expert users are assumed then software can be used to model the time to competition based on spacing of buttons, number of clicks, system lag, keystrokes, etc. This will give an accurate, reproducible competition time estimates across vendors. Right now, untrained EMR users will be the test subjects, but as stated in the report EMRs are not “walk-up-and-use applications”. My guess is without training they will have difficultly even completing the tasks!

Permalink | Leave a comment  »

We have been slowly rolling out the public beta of RefillWizard over the past couple weeks and to get everyone up to speed we wanted to put together a short video for how refill protocols work within RefillWizard.

This video is intended for consumption by refill prescribers.  It will discuss how refill protocols are structured and how they can be edited.

Permalink | Leave a comment  »

We all know that HIT moves at a glacial pace, but are there similar industries that have taken a similar trajectory and now with history in their rear-view might provide some insights into the future of HIT?  I think I've found one.

ERP is Born

In 1990, Enterprise Resource Planning (ERP) was born when the Gartner Group first coined the acronym to describe a software package that integrated the entire working of a company into a single application.  The goal was to facilitate the flow of information from all parts of the business including finance, manufacturing, and sales.  The ERP system leapt to the forefront as the Y2K bug approached - legacy systems needed to be replaced and the newly create ERP systems fit the bill.  As the Y2K bug came and went, companies realized these ERP systems, while promising in theory, were far from perfect.  Likewise, ERPs became infamous for negative ROI and implementations which were over budget and took longer than expected (seeing the similarities to HIT yet?).  Digging through archives my favorite article talks about how many of the ERPs installations were delayed to the point of not being able to meet the drop-of-the-ball deadline.  Anyone think this is going to happen as the meaningful use deadlines approach?

In the early years, the ERPs made automating the back office logistics their priority, but as time passed they began to focus more on the front-office functions such as supporting the sales staff via a customer resource management (CRM).  For those unfamiliar, the CRM is an application for documenting interactions with customers.  Or for the more software-oriented, think of ERP as the backend and CRM as the front-end.  However, these front-end applications were constantly victimized by poor usability and fragmentation (how about now?).

A New Age of CRMs

However, it took the internet, and simplification of communication to usher in a new age of CRMs.  One company emerged, Salesforce.  Salesforce leveraged the changing forces in the enterprise market to create a highly popular web-based CRM.  It leveraged the foundation laid by the ERPs, utilized the web and its business models, and promised to end software burden for its users.  What happened next is well, history.  Salesforce has taken off, and as of this writing, they are a $15B dollar company with over 100,000 customers.

As I heard this story, I could not help but make comparisons to healthcare.  Briefly summarizing:

1. The Y2K bug, much like the HITECH Act, will provide the stimulus for an enterprise foundation to be laid.  Although the merits of both of these events can be questioned, the sole fact remains, their respective industries will be changed as a result of this external stimulus.
2. Both current ERP and EMR systems are becoming known for negative ROIs and being over-time and budget.
3. Finally, the front-end systems were both notoriously unusable.

Seems like the perfect storm for the healthcare version of Salesforce.  Who/what will it be?

Note: I've tried my best to convey facts, so if there are any errors below, I apologize.  If anyone out there was involved with any of the companies I mentioned, I would love to hear from you.

Permalink | Leave a comment  »

From my recent talk at the UX Masterclass, a user experience conference put on by the folks at User Centric.  

Permalink | Leave a comment  »

I recently had an opportunity to talk with arguably one of the best software designers in the web space, Jason Fried.  I'm crossing industries here, so for those of you in healthcare (and totally isolated from the tech space) Jason is the co-founder of 37signals, a Chicago-based company focused on building collaborative tools for small businesses.   They build some great products.  We use Backpack on a daily basis to keep track of our internal discussions.  Let's just say if Jason (and 37signals) were focused on healthcare, as an industry we would be much better off than we are now.  I've always admired his laser-focus to his product and making the lives of his users better.  Needless to say, I have quite a bit to learn from him. 

When I first found out I was going to meet with Jason, I figured our meeting was going to be a little Q&A - exchange the typical pleasantries, but Jason would have none of it - he wanted to get to work.  So before I knew it I was in the middle of a design session with Jason Fried.  This is what I learned.

The original design

See the full gallery on Posterous

Below I will give examples which will reference the above designs.  See the updated design at the bottom of the post.

Lesson 1) Too much jQuery == You're doing it wrong

Javascript (in particular, jQuery) is an amazing tool for web developers.  The technology has made the previously unthinkable possible in a couple lines of code.  So what do software designers do?  Use it - too much.  This causes them to to lose focus and overlook the actual purpose of the application.  Instead the designer builds an application to look good, rather than to be usable.  Excessive use of jQuery is indicative that your design is getting too complex.  Case in point...

Example

I needed a way to collect information about the medications from the user.  In order to minimize the screen real-estate, I decided to hide and show input fields based on which medication was selected.  To handle this I created medication cards, which when clicked would display the associated inputs for the particular medication.  The user would have to cycle through all the medication cards to fill out all the information.  I thought it was a clever design...

However, Jason quickly pointed out that this design was likely going to result in major usability problems.  No established convention exists for this design; there is no precedent to click each card.  Rather, the user would likely click the continue button (which leads to the next page), leading to an incomplete form submit.  The other medication cards would go unnoticed.

Jason's thoughts: Most of the "best" applications could be run using technology from 10 years ago.

Lesson 2) Edge cases will show design flaws

Fancy designs are nice, but for them to be functional you have to think about the edge cases.  What's going to happen when your user pushes the application to the extreme?  Does your design scale gracefully or does it fall apart?

Example

Patients often require multiple medications to be refilled at once.  During user testing, we found that medications were commonly refilled in batches of 2 or 3 medications.  Thus, we originally designed it to handle (roughly) that number of medications.  However, we neglected the extremes of the application.

We were limited to only four medications at once.  There was no way to add additional medications to the design without some fancy jQuery animation!  This was not a limit of the technology, but of the design.

Also, when refilling one medication the design fell apart.  The medication card analogy didn't make sense when only one medication was present.

Jason's thoughts: Get rid of the unnecessary design, keep the application design simple.  

Lesson 3) Use English when communicating to your users

Use language to your advantage; it is the common thread that ties all of your users together.  Often times as designers we get too caught up in trying to over simplify the content of our application until we get to the point where it no longer makes sense.

Example

After entering the information about the medication, the results of our application are a set of instructions for the clinician to follow.  Obviously it's very important that we communicate those instructions as succinctly as possible.  Yet, I was using phrases like "Filled by Team" or "Fulfill then Notify", which made sense to me, but to a new user were ambiguous.  

Jason's thoughts: If you were in a conversation and you spoke the text would it make sense?  No?  Then it should not be on your website.

The new, improved design

See the full gallery on Posterous

Based on the suggestions from Jason, I completed a redesign of the three pages.  The first page remains relatively unchanged.  The second and third were completely revamped. 

Following Jason's suggestions I completely eliminated the medication card design and replaced it with a more conventional vertical layout.  The vertical layout allows the user to see all of the required input fields without clicking, and eliminates the ambiguity as to what needs to be clicked.

Rather than using ambiguous section headings, I've replaced the entire screen with a set of instructions.  These instructions are written out as complete sentences, rather than fragments (or headings).  

You can further explore our redesign by checking out our demo.  If you like this, please upvote this on Hacker News.

If you want to keep pace with our redesign of Health IT, follow us on Twitter.

Permalink | Leave a comment  »

Government involvement in usability has been the talk recently at HealthFinch as Lyle is gearing up for his presentation at the NIST Usability Workgroup.  In case you're not aware, EMR usability is so problematic the government is exploring ways to get involved.  As you might imagine the topic is a very sticky subject, especially EMR vendors, as the topic conjures images of committee-centered design and EMRs being worse of then they already are now.  

However, when you think objectively about it, I believe the government can be part of the solution, if done correctly.  I want to lay out my guidelines for government involved in Health IT usability.

Brief Introduction to Usability Testing

Before getting into my recommendations a brief background in usability testing is required.  Usability testing can be roughly broken into three types: (1) heuristic evaluation, (2) expert user testing, and (3) novice user testing.  Although each of these are not explicitly "usability" testing, for the sake of simplicity I'm going to lump them together.  

Heuristics

Goal: General software usability

Usability heuristics, or discount usability testing, is a process developed by Jakob Nielsen to rapidly and cost effectively test the usability of a user interface.  In this method, Nielsen defines ten "rules of thumb" for all interfaces whether it's a game on an iPad or a state-of-the-art enterprise EMR system.  Remarkably these suggestions have held through years of scrutiny.  In a heuristic evaluation, a usability expert performs a detailed evaluation of the user interface to find heuristic violations.  Next, the violations are given a severity rating to prioritize the fixes for the developer team.  Some of the most commonly violated heuristics in HIT include:

• Recognition rather than recall - Minimize the cognitive load on the clinician by storing more information in the system, rather than in the head of the user.
• Aesthetic and minimalist design - If it is not important, don't put it on the screen!  I can't tell you how many times I've seen lab results, problem lists, or a medication interaction listed in a table format with poor information display.  Rather than taking up screen space with this low information density data, it's better to use techniques such as Edward Tufte's sparklines.
• Error Prevention - User interfaces should prevent errors from occuring in the first place.  What happens when this heuristic is not followed?  Alert fatigue.

Expert User

Goal: Quantitative prediction of task completion time

Using a technique called User Performance Modeling, the time it will take for an expert to complete a task on a particular user interface can be determined.  These models predict the completion time based on parameters such as button size/spacing, number of clicks, and load times.  The best tool I've used for this modeling is CogTool from Carnegie Mellon.

Novice Testing

Goal: Learnability, Find major design flaws

Novice testing is the process of asking a new user to complete a given task.  It generally goes like:

1. Find a representative task for your system (e.g. fill a new order for Lipitor, refill the prescription, change the prescription)
2. Ask a novice user to perform the task
3. Tell the user to "think aloud" (e.g. verbalize their thought process)
4. Record major breakdowns in the process (e.g. can't find a button, unfamiliar wording, etc.)

Don't let the relative simplicity of this process fool you, it can be very powerful for finding flaws in design.  In the design of our newest application to automate medication refills, we went through a major redesign after each round of our user testing.

Usability Heuristics for Government Intervention 

Do not design EMR software

Let's take that off the table immediately.  Although platform oversight on software design can work (Human Interface Guidelines from Apple), design is not a core competency of the government.  Putting government regulation on the design process would inhibit rather than promote usability.  As such, any government involvement in usability cannot present an "ideal EMR" and require evaluation against that "ideal EMR".

Evaluate objectively, not subjectively

This goes hand-in-hand with the previous recommendation, but if the government is going to evaluate usability (ala KLAS), then all metrics need to be objective rather than subjective.  A common misconception is that usability is subjective.  In fact, it's not.  Usability is a fairly exact science.  User experience, which is often confused with usability, deals with more the subjective measurements, such as more the "look and feel", rather than objective measurements.  Good evaluation criteria would be metrics such as heuristic violations or task completion time.

Don't allow for over-optimization

Give an engineer a metric to optimize, and they will optimize it, potentially to the detriment of the overall system.  What this means for usability testing, is that you cannot test on a single metric such as "time to complete a new order".  If you're going to test on completion time then the tasks need to changed so that over optimization does not occur.

Open the eyes of consumers

The most important outcome of a government intervention in usability is to promote consumer level awareness.  If clinicians are aware of usability problems, vendors are going to compete on usability.  It might be wise to piggy back on existing consumer satisfaction surveys, such as the reports from KLAS to increase consumer awareness on usability.

Let the market flourish

Let's face it, in a properly functioning market, the customer will pick the best products, and the winners will rise to the top.  Do you ever hear Steve Jobs complaining about the usability of iOS Apps?  From the lack of usable HIT products, you could assume potential innovators are being left on the outside looking in.  If you want usability (and innovation) to flourish, open healthcare environments such as SMART Platforms, need to be continually pushed.

Focus on the "big five tasks"

Clinicians spend the majority of their days completing five tasks - orders, results, messages, prescribing, and notes.  If you make these processes more usable, clinicians are going to be happier and more productive.  Whatever intervention is selected, it would be wise to focus on these particular need areas.

The EHR Usability Report Card 

I've taken the liberty of complying all of these suggestions into a potential usability report card for EMRs.  The report card highlights the heuristic violations of three fictitious vendors in the "big five tasks".  The greater the number of violations the poorer the overall usability of the system.  While this report is not perfect, I believe it best exemplifies the processes the government needs to take in its "War on EMR Usability."

Permalink | Leave a comment  »

If you buy that healthcare can be improved by IT (an argument for another day), then the time to set the foundation for the future is now. Healthcare is notoriously slow to innovate, but why?  From the eyes of a company trying to do just that, let's look at why the normally fast-paced world of IT gets brought to a halt in healthcare.

Traditional HIT applications are difficult to deploy. 
From the business-end alone, it takes business partnerships, integration contracts, HIPAA agreements, and service contracts to get an application into the hands of users.  On top of that, implementation costs are orders of magnitude more than it cost to originally design the product.  Software licenses can run 10% of the entire application cost, with the remaining 90% going to implementation, support, and hardware [1].  For big vendors with the available resources these costs can easily be passed off to the customer, but the small vendor with the limited resources can not afford to take on these responsibilities.  Therefore they must either partner, give up, or find the money to proceed.  While this model is making some vendors wildly profitable, it puts incredible barriers on potential HIT innovators.

HIT Apps need patient data.
Any application worth purchasing is going to require patient data.  The days of being able to build a successful medical reference application have come and gone.  The future of HIT innovation will be fueled by patient data.

The problem is we have made data difficult to get.  The industry is littered with potential options such as CCD, HL7, data warehouses, and HIEs which developers can use to power their application.  The problem is they're all flawed, and this flaw will inhibit the growth of your product moving forward. 

In conclusion,
High deployment costs + No Data = No innovation

After receiving the SHARP grant, the Harvard team led by Kohane and Mandl set out to solve this problem through the creation of a technology they coined, SMArt Platforms.

What is a SMArt Platform?
The best way to think about SMArt is as a wrapper around existing electronic medical record systems.  No matter the underlying system being wrapped around, the same data gets exposed to the developer.  Rather than having to integrate with an Epic system, then revamp that integration for Cerner, the SMArt wrapper maintains the connection.  The developer builds the application to be SMArt-compliant once, then as long as the vendor has SMArt you can easily plug-and-play.

Once completed, SMArt is proposing to build an App Store for Healthcare that will serve as a point of deployment for HIT developers.  Once a hospital agrees to use the App Store, the developer now has a distribution channel in place.

Now lets look at our equation:
Low deployment costs + Available data = Innovation

Imagine the future where all it takes is a developer (and a clinician) to work together, then release an app to the App Store, and SMArt handles the rest.  Apple has shown it, and hopefully SMArt will embrace it - take the burden off the innovator and innovation will flourish.

[1] Wang et al. A cost-benefit analysis of electronic medical records in primary care. Am J Med (2003) vol. 114 (5) pp. 397-403

Permalink | Leave a comment  »

Being on the front-lines, Lyle experiences the problems with HIT first-hand.  With these insights from Lyle, we are able to understand the problems clinicians are facing, then we can focus on creating technology which solves those problems.

The first time we heard about Lyle Berkowitz was at the Mayo Clinic Transform conference where he talked about the death of EMR 1.0.

With Lyle we were fortunate to find a physician that held the same core beliefs as the original HealthFinch team.  So moving forward, our mission remains unchanged - we will continue to develop medical software which makes the jobs of clinicians easier.

The first application we will be releasing as a new team is RefillWizard, an application which assists clinicians in automating the cognitive processes associated with medication refills.  Lyle speaks to this problem at 7:34 in the above video.  Medication refills are a common but under-addressed problem in HIT (PCPs can receive up to 15 per day).  Without adequate solutions, administrative tasks, such as medication refills, are increasingly consuming the time of clinicians.   

The goal of RefillWizard is to capture the refilling protocols of clinicians and translate them into application logic.  With this logic, the application can become the facilitator rather than the inhibitor of a more effective clinical practice.  Using the application, we hope the clinical staff can become empowered to help in the process, lessening the burden on the physician.

We are currently accepting requests to become beta users for RefillWizard.  If you're interested let us know here.  Follow our blog, as well as our twitter feed to stay up-to-date on the latest updates on RefillWizard.

Permalink | Leave a comment  »

We let the cat out of the bag with our previous post, we will be presenting during HIT X.0: Iron Programmer during HIMSS '11, but we left your a little short on the details.  Here are the basics:

Permalink | Leave a comment  »

The excitement for HIMSS'11 is beginning to heat up (especially after the snowpocalyze we received in Madison last week), and here at HealthFinch we could not be more excited.  To anyone who is a follower of our twitter account, you may have heard that HealthFinch has been selected to appear at the HIT X: Iron Programmer Challenge during HIMSS '11 in Orlando.  During the next couple weeks leading up to HIMSS'11, we will be chronicling our preparation.

The Agile Manifesto

At its core, the Iron Programmer session is about agile development. Agile development was started when a group of 17 programmers went to a ski resort and decided that software development could be done better.  The result of their work was the agile development manifesto.  The manifesto can be summarized in four points:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

While all of the items on the right are valuable, when they come into conflict with the items on the left, we choose to value those items more. 

Agile development comes in many forms, Extreme Programming, SCRUM, DSDM, Pragmatic Programming, among others are all variations on the theme of Agile Development.  Agile, as its commonly known throughout the industry, is not so much about writing code or dreaming up designs, but is more of a focus around the management of a development practice. 

This means turning the traditional value structure in managing HIT on its head.  It means changing the focus of a large development effort onto many smaller efforts. 

The Traditional Approach

I’m sure many of you are familiar with the traditional approach to developing software in HIT.  That is, start with a needs definition, write out specifications, documenting the entire process from start to finish, then having developers methodically write out each piece of the project.  By the time the developers actually start writing the code, the needs of the project have broadened, the specification has become unwieldy, and the developers are writing software at a much slower pace than anticipated. 

This is endemic even when contractors are brought in to help with a project.  Needs change, the contract then has to be renegotiated, timelines change, budgets change, etc…, until the entire project needs to be scrapped.  Then once the memory of the failed project leaves the institution, a similar project is started up again to meet with the same fate. 

If this scenario brings out a sense of déjà vu, you’re not alone.  This isn’t the way programming ought to be done. 

A project on Agile

With agile development, the focus changes to cycles of iteration. Instead of developing out a full spec, the programming team focuses on delivering an incomplete version of the project in a set development cycle.  As the project develops, the needs change, and by starting with a set increment, clients and customers can prioritize which of their needs must be met most urgently.  As their needs change, the project builds upon each iteration cycle to encompass a broader goal. 

Agile methodologies focus on preventing customers from making irrational demands, and instead focus on tradeoffs for any particular goal. As the project develops, since business people and developers have been moving toward a common goal, the trust in organizations build, and organizations are able to become more innovative and collaborative. 

Even in the situation where an outside firm is contracted with Agile practices in place, the focus is not on the contract as needs are continuously expected to change, and developers have been working to collaborate with the client to achieve the intent behind the project, not simply the spec, which may or may not fulfill the client’s needs. 

The Agile Methodologies

1. The focus in Agile Development relies on developing a project with the following twelve principles:
2. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
3. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
4.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
5. Business people and developers must work together daily throughout the project.
6. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
7. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
8. Working software is the primary measure of progress.
9. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
10. Continuous attention to technical excellence and good design enhances agility.
11. Simplicity--the art of maximizing the amount of work not done--is essential.
12. The best architectures, requirements, and designs emerge from self-organizing teams.
13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

To demonstrate the process, we will be developing a small application in the next couple weeks using Agile techniques. Throughout this series of posts, we will demonstrate how to apply these principles to HIT.  

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

This post was written in response to our intern job posting, where we asked potential interns to write a blog post on any topic in healthcare, technology, or design/usability.

Over the past several years, the media and users of Facebook have identified and voiced concern over multiple issues related to the privacy of personal information. This includes concerns over the longevity with which Facebook will store and “own” the information shared by its users and how individuals and other applications can access this information. Facebook made efforts to reduce these concerns by giving more power to users to control their privacy settings on an individual basis. The momentum in healthcare IT will lead to similar situations where privacy controls will need a major overhaul given the advancements in integration and ease of information sharing.

Currently, there is not a clear standard for how patients determine what is an acceptable amount of sharing of their personal health information. One thing is clear though – we want control over who is legally allowed to get their hands on this data. Patient Privacy Rights, with the help of Zogby International conducted a survey and one consistent trend emerged. Over 90% of respondents answered that they want control to limit or enable individual people and their ability to view and use electronic personal health information. This is something Facebook accomplished as it grew from college-exclusive “networks” to now include those same college students’ parents, grandparents, and unborn children.

Last year, Facebook announced the ability for users to control who can see each piece of information contributed to the site. Prior, users could only control this level of privacy using “networks”. These privacy settings greatly affect the willingness of users to contribute to the site. Issues of trust recently emerged again with the social network giant when reports developed that third party apps were transmitting information that should otherwise be kept private, breaking Facebook’s own rules.

When comparing a user of social media to a patient, there are several obvious differences. The patient is not necessarily a “user” of healthcare information contained in medical records. Oftentimes a multitude of healthcare professionals contribute much of the information or medical data to the patient’s record. This information could even be a conglomerate from multiple different applications, mobile or otherwise. This parallels these third party apps that Facebook incorporated into its privacy controls, but often with much larger and serious stakes (yes, yes, I am implying that medication and immunization history is allegedly more important than a quiz-app that can predict your best friend’s favorite color).

Will patients also need to determine which other “applications” can access their health information? It seems this might not be an incredibly simple undertaking, again, something Facebook found out the hard way.

All these factors will make it increasingly important that patients have an easy way to identify what restrictions should apply to their information. We want the information abusers to stay out and at the same time shouldn’t limit cases such as modular health IT systems or research organizations from doing productive and honest things. Facebook has struggled through privacy controls design in a different industry; hopefully some lessons learned can be applied to the world of healthcare as we move to trust technology more and more with the most private details of our lives.

Permalink | Leave a comment  »

I think these innovation conferences have become popular due to recent innovation in the customer industry.  However, there is a disconnect.  These solutions can exist in the consumer world because sexiness alone can sometimes be value enough for adoption.  However, in the clinical world, innovation for the sake of innovation does not cut it.  You can blame clinicians as being risk-averse or slow to adopt, but this is a mis-classification.  Treating patients is the number one concern - using technology is not.  So it follows if new technology does not add value (by improving care) clinicians will not adopt.

Now compare this with AMIA which focuses on fundamentals over innovation.  They are concerned with getting everything right.  They specialize in adding rigor and clinical input to existing technology.  This research is crucial to improve adoption and knowledge of existing technology.

However, due to the differences in these conferences there is a gap that is beginning to form in the middle.  If you imagine a continuum where innovation is on one end and fundamental knowledge is on the other, there is no one in the middle.  Its important that these conferences as a whole draw from each other, as they each have something to bring to the table.  The AMIA-crowd could learn more about innovation, while the innovation crowd could learn how to bring clinical rigor to their technology.  The quicker we close this gap, the quicker we can bring new, innovative HIT technology to market.

Permalink | Leave a comment  »

This post was written in response to our intern job posting, where we asked potential interns to write a blog post on any topic in healthcare, technology, or design/usability.

In 1994 Jeff Bezos revolutionized how consumers shop. He founded Amazon.com. Shortly after, Ebay followed suit—solidifying a paradigm shift that has redefined shopping from an in-person to online experience. In 2004, Facebook capitalized on another trend: individuals were becoming more comfortable sharing personal information online. Interestingly, people did not wake up one morning and decide it would be convenient to shop from home, or that sharing pictures with their friends online could be fun. Rather, in both cases, there has been a sustained movement towards new values and preferences that have fundamentally changed how individuals shop and socialize.

I give the two examples of paradigm shifts above to bridge into a paradigm shift I believe is currently happening in the field of medicine. In the past, medicine was a patient-centered model. In the early days, doctors visited patients in their homes. They were deeply rooted in their communities, and knew their patients on a personal level. Unfortunately, around the turn of the 18th century, there was a shifting point away from a patient-centered model and towards a doctor-centered model. While the shift produced major breakthroughs in medicine, it also created a major disconnect between doctors and their patients. Doctors have become notorious as the ultimate source of knowledge, and only know their patients at an arms length. Since then, the medical institution has grown into a powerful bureaucracy with an affinity for rules and order.

However, there is currently a trend in healthcare against the modern institution of medicine. There is a growing segment of the population who want a personalized, efficient, and affordable healthcare experience. The growth of health tourism and alternative medicine centers support this assertion. Winning healthcare providers will be the facilities that respond to the changing needs and preferences of their patients. Losers will cling to rules that do not make sense. In my opinion, winners will challenge conventional standards and ask questions like:

Why do I have to fill out my previous medical history when I switch doctors, or apply for new medical insurance? There should be a database for that.

Why do I need to take a slip of paper to the pharmacy and wait 30 minutes, instead of my doctor sending it in real time, having the medicine ready for pickup when I get there, and have it automatically charged to my Visa? Why does the doctor need to ask me about allergies when he or she already has it on file? There should be an app for that.

You get the idea. I believe this paradigm shift is a microcosm of a greater trend occurring in society. Structurally, organizations are getting flatter. Trade and travel barriers are lowering. Services and products are becoming more integrated and compatible. Mass customization and personalization of experiences are the norm. People can personalize the color of their Dell laptop computer, make a custom laser engraving on their iPod, so why can’t they personalize their experience with their doctor?

Great value exists for healthcare providers who are willing to leverage technology in their business. Technology can reduce costs and wasteful practices, while attracting incremental patients seeking an exceptional experience. Indeed, it is ironic that leveraging cutting edge technology can bring you back to the basics of a patient-centered healthcare model. 

Paul Fischer

Permalink | Leave a comment  »

This post was written in response to our intern job posting, where we asked potential interns to write a blog post on any topic in healthcare, technology, or design/usability.

One sport that really bothers me is Major League Baseball. Why? It seems as though the hard-headed people calling the shots, and games for that matter, would rather keep their pride than make the right call.

Instant replay is no secret. It isn’t a new, untested technology—its been around since the mid 50’s and every professional sports league uses it with game-changing results, except the MLB. This has annoyed me for awhile now, but not enough to actually bother me until Armando Galarraga of the Detroit Tigers was robbed of a perfect game due to an umpire’s (admitted) error. This feat has only been done twenty times in the history of the league. A man’s legacy was taken from him simply due to the MLB opting not to use the technology it has available. Sure, baseball is only a game, but what if lives were at stake rather than legacies?

Which brings the question: Is healthcare utilizing all the technology available? Why are there rooms of paper health records when they could be stored on servers the size of a refrigerator or even a deck of cards? Why are doctors carrying around stacks of papers when there are tablet computers the size of a notebook that could put those entire previously mentioned rooms at their fingertips? Why does it seem like you have more technology in your pocket than there is in the exam room?

Although there is no definite answer to these questions, I believe it all boils down to one word: usability.

Many clinicians are resisting the implementation of Electronic Medical Records and other forward-thinking technologies because they dislike change, and technology for that matter. This is likely because the technology that is being imposed on them is difficult to use, or doesn’t feel natural to them.

The benefits of implementing EMR systems are exponential, but I’ll save that for another post. First and foremost we need to get the clinicians who will be using them to accept them. Healthcare software should be designed so that it is flexible enough to accomplish all the necessary tasks, yet intuitive enough so that even a veteran physician can navigate it easily and enjoy doing so. This is what we at HealthFinch do best—make healthcare software that is not only effective, but enjoyable to use. We think software should adapt to clinicians, not vice versa.

Clinicians and executives, please keep an open mind about taking the leap into this new digital era. Electronic Medical Records will be to healthcare what instant replay is to professional sports—essential. Do you want your hospital to be like the MLB?

Mark Hendrickson

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »