Get Moving – New Kinect SDK from Microsoft

Using a Microsoft Kinect (motion, voice) as a healthcare application interface input (e.g. navigating images without touching a computer in the operating room) made a lot of press, but those folks that actually developed for it found the initial device release lacking an a mature API for PC application developers. Microsoft has since released a software developer kit (SDK), but it still required extra coding to have the device recognize desirable gestures. An update to the SDK was recently released and it adds several new gestures that can be recognized and made available to application developers through the SDK.

Check it out.

So, for those many Rads that played the clip from Minority Report (where Tom Cruise interacts with images and video by moving his hands around) during their talks at SIIM and elsewhere, we are one step closer to realizing your dream. 🙂 Though, do try and wave your arms around for a 4 to 8 hour workday and let me know how it goes—eye fatigue will be the least of your worries, my friends.

Plug-ins vs. APIs

Without endorsing the product represented (I have not looked at it at), I think this blog post is covering some important points (and is well written, so do have a look).

Some thoughts, though…

Pet peeve of mine: The smartphone app metaphor is a bit overused in enterprise software that manages personal healthcare information. When a physician is making a life-altering decision about my (or my loved ones’) care, I would hope that they are relying on something with a bit more vigilance around it than something that they downloaded along with a Kanye West tune. I want something that is “battled tested” and properly integrated in the enterprise (see ITIL Change and Configuration Management) before being used clinically in the hands of healthcare providers. Call me paranoid.

Look, I get it. Users like downloading and using “apps”. But, the expression of desire for “apps” is properly translated in a desire for more flexibility and responsiveness from their healthcare IT vendor(s)–people like the personal experience of the control that downloading apps provides them and speed of innovation (with a decent platform, apps can be developed with massive parallelism–think Army of Nerds) , but if Angry Birds makes a mistake, no one dies (well, a bird, I suppose–never played the game so I am only guessing).

I may get some flame mail from respected friends for this one: open source applications are also not the (complete) answer. Sure, its fun to be able to change and extend source code (and to become a hero by fixing bugs yourself instead of waiting for a fix from your vendor), but for every “coder” I have met only a small percentage that really understand the full scope of work of professional software development required to produce an application to the quality we need in healthcare. Don’t get me wrong: I love hackers. They break through barriers and solve problems with practical methods. But, their output typically needs a lot more work to make something that is production ready. Great power, great responsibility, and all that.

The reality is: we don’t need a bunch of user-downloadable apps or developer-modifiable source code. We need APIs. Good ones. REST-based Web service APIs. Documented, well-designed and tested. Supported. Unbreakable, secure ones.

When done right, APIs are contracts. Promises. They aren’t some side-door or limited set of functions added as an afterthought. They become the language by which applications speak to each other, even internal parts of an application.

Healthcare standards like DICOM and HL7 standards include APIs, just ones based on older technologies and protocols. The information model is still pretty solid, I would argue, so we don’t need completely new “words”, just some different ways to communicate.

Oh, and products with great APIs are generally higher quality because it is much easier to write automated tests to beat the crap out of them before unleashing them on to the world.

More on this topic later.