Recently I had the privilege of attending User Interface Conference 17 over in Boston where I met some really interesting and talented people. I attended some outstanding sessions and workshops to help us improve and innovate our design process over here at Voalte. One session that resonated with me was Luke Wroblewski's talk on 1st person user interfaces where he spoke about the current trend in touch-based interfaces and how augmented reality and the use of sensors in everyday items will become the interfaces of tomorrow, paving the way for natural interaction interfaces over learned voice or esoteric device specific commands (swipe to delete anyone?).

Being part of such a saturated market, where the new buzz word 'HIPAA-compliant text messaging' is being slapped on everything like a 'Gluten-free'' label, means we constantly have to keep one eye on the goal and one toward the future. This talk got me thinking about some of the cool new ideas we could use to improve healthcare communications in the future.

Imagine being able to use your phone's altimeter (or interpolated location based on WiFi access points) to trace a nurse's route throughout the hospital. You could automatically set them as 'busy' when they enter the cafeteria or the break room and forward alarms to their backup.

There is also the concept of wearables, where users affix an unobtrusive device to their clothing which records information from a built-in GPS, altimeter, pedometer, gyroscope, accelerometer, temperature sensors, and more! We would be able to tell if a physician is sleeping, driving their car, or out on a hike, and look through their backup list to try and not disturb them if another physician is readily available.

New tools and paradigms like this will allow us to gather information about a user's surroundings and let the software work for you, naturally, as you would expect it to. As a software developer and user interface designer, it is a very exciting time to be in the healthcare communication market. 

Remember the “Pass the secret” game we all played as kids? What went in on one side was never what came out the other because each person acted as a filter, misconstruing and warping the original message. You would be lucky if the intent made it all the way through the barrage of improper memory-mapping and malicious intent. We face the same dilemma today in Healthcare I.T., with interoperability and interfaces to and from the Electronic Medical Record (EMR) systems, communication vendors, and various other middle-ware solutions. It amazes me sometimes that it works at all. Mapping back and forth between discrete and non-discrete entry fields, through automated systems, and sometimes by temp analysts, is a recipe for disaster.

All too often, vendors produce mass-marketed solutions that don’t interact friendly with third-party systems. Because of this, inaccurate interfaces are erroneously created by third parties or inside of the hospital by their own IT staff to link these sub-systems together. These interfaces remain the weakest link in a hospital’s IT infrastructure which can lead to patient safety issues by reporting on inaccurate or incomplete patient information.

EMRs see their system as a central repository for all hospital data, and I tend to agree. We already see this complexity just getting data back into the system with back-end lab systems and flubbed interfaces, and the same complexity is seen with data coming out. How does a third-party system display that clinical data in an efficient and effective way? That burden must be on the EMR vendor to provide a more efficient way to display patient data and they must become more draconian about how their data is presented. As third-party vendors, we must start thinking of ourselves as a supplementary applications and a passive consumer of that data.

The same rules apply when duplicating data across systems. Every additional duplication is another failure point in the system. Hospital roles and assignment are a primary example of this problem. Many of our competitors duplicate roles and assignment, already found in the EMR system, into their own database repository. This is an inefficient and error-prone way of pulling information across hospital systems.

In summary, as a hospital IT developer, we need to find a better, more efficient way to reach across boundaries and communicate with a hospital’s EMR vendor. Data should become centralized with as little redundancy as necessary and we should rely on the EMR systems to display patient data, it shouldn’t be cannibalized by other systems.