May 2017

Sun Mon Tue Wed Thu Fri Sat
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

« What is a Patient-Centered Medical Home? | Main | EMR in Canada Part III — A Developer’s Perspective »

Comments

Shawn Vincent

I really enjoyed reading this -- it's a refreshing perspective. Nice to see pragmatic, modern technology techniques discussed in a HIT context.

I especially enjoyed the nod to NoSQL databases. In my years with medical record systems, I've come to the same conclusion. The contortions you need to make to force semistructured medical record data into relational tables is nuts. NoSQL provides a very promising way forward: indexed semistructured document storage seems like a really good fit for medical records data. Has anybody heard of one of these databases used in production for an EMR?

I loved your comment "There are many ways to display more information". I refer interested readers to the life-changing essay "Magic Ink" by Bret Victor for what this could mean: http://worrydream.com/MagicInk/

One additional wrinkle I'd like to point out with UI design. Modern task-driven (or, as my HMI expert likes to say "information space analysis-driven") UI design is key, as you point out.

With vertical market software like EMRs, you end up in a "long tail" situation: 80% of the tasks and workflows are shared, and 20% are not, but those "special" 20% are critical to each user. There are many kinds of physicians and related care providers, and many types and sizes of care settings. A specialist in a large clinic environment with medical students has different workflows than a general practitioner in a small clinic with just a nurse and a receptionist out front.

These various workflows result in different data fields being captured, different requisition workflows, etc.

It is important to capture the commonalities of all of these clinics (it's true that users tend to think that their workflows are more unique than they are in practice), that covers off the 80% use cases and workflows. The remaining 20% use cases tend to be specialized.

The four ways I know to resolve this are: (1) limiting your market to a small subset of the market, (2) lowest common denominator, which makes your product a lot less appealing, (3) being everything for everyone, which ends up with a crazily complex UI, or (4) allowing customization or specialization for private workflows.

I prefer (4), although I could probably be convinced that (3) with a really good UI designer combined with some limitations of market could be pulled off.

Entertainingly, financial apps (like in insurance companies) have this same issue. In practice, these kinds of institutions tend to have IT staff that can custom write or otherwise customize their software. EMR software has different economics: the typical clinic can't afford to get software customized (although this approach is indeed possible, if you've got the cash or skillset).

Excellent article, thank you very much! I look forward to reading the next part!

-Shawn Vincent.

--
VP R&D, MD Practice Software LP


Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

Your Information

(Name and email address are required. Email address will not be displayed with the comment.)