Author: dondennison

Article – mHIMSS executives say FDA regulation won’t hold back app innovation

dondennison Healthcare IT , ,

This short Q&A article discusses the role and impact of FDA regulation, as well as the new medical device excise tax.

Some thoughts…

  • Someone explain to me how applications accessed on a tablet or smartphone are so much different than a desktop app being accessed on a netbook on Wifi. A tablet is a computer, typically without a keyboard and mouse. The user input method varies slightly and we have a whole new class of device? I don’t get it. If an application is collecting clinical data (e.g. dermatology photo), it should be subjected to appropriate regulations regardless if the user is using a mobile computer or a full desktop to run the application. This seems to me like a lack of understanding of computing by policy makers.
  • I believe the driving issue are mobile app developers getting into healthcare rather than registered medical device manufacturers getting into building mobile apps. Those familiar FDA regulations (and similar ones in other jurisdictions) generally know the rules. It is the mobile app developers unaware of the FDA regulations that are likely facing the greater challenge (mostly learning the requirements of being a medical device manufacturer). Providing the right guidance to the app developer community could be a growing opportunity for experienced regulatory affairs contractors/consultants.

Article – At Healthcare Experience Design conference, designers rethink ‘broken processes’

dondennison Product Management , ,

In this article, the topic of user experience design in Electronic Medical Record (EMR) applications is explored. They also briefly discuss the use of EMR technology by patients.

Some thoughts…

  • The fact that EMR user interfaces are often hard-to-use, and are undesirable by the user community they are intended to serve, is not news. EMRs are often, at their core, records management systems, presenting medical records generated by other systems, or by users typing data into the EMR. It is no surprise that information is presented like a big electronic filing cabinet. Niche players are trying to layer solutions on top of the EMR to present the information relevant for a given interaction in a more meaningful way. Often, if the EMR is not built with an open architecture (with APIs for external applications to discover and access information), a copy of (some of) the data is kept in a secondary system. Hopefully, IHE FHIR succeeds and enables an integration ecosystem for EMR add-ons that is tantamount to the platform needed to have an “App Store”.
  • Designing applications for trained medical professionals is hard enough. Trying to build a user interface that makes sense to, and it optimized for the use by, both an Oncologist and my grandmother is near impossible. Medical terminology alone is enough to confuse most patients. Then consider the questions and concerns of the patient as they start to review their CT images and wonder what that little whitish spot might be. In this article, many of the docs surveyed expressed concern over patient access to their own electronic medical records (which is why Personal Health Records were created, friends).

Article – The Obamacare Revolt: Physicians Fight Back Against the Bureaucratization of Health Care

dondennison Policy

Politics aside, this article provides some numbers on the actual costs of some healthcare procedures in the U.S., comparisons to the reimbursement amounts for these, and the “horse trading” to make some procedures more affordable (performed at a loss), while others are allowed to be more expensive (higher margin to subsidize the other procedures).

Medical imaging (MRI) is mentioned on the second page.

Too Many, Too Few …Just Right

dondennison Healthcare IT

One thing I have noticed (and was commented on by an esteemed panelist at the SIIM Regional meeting) is the wide disparity of the number of IT and Admin staff working on medical imaging systems among similarly sized facilities. One hospital has 10 FTE, while a peer has 2 FTE. I can’t imagine that there are productivity differences to account for such a variation. I have to think that one is simply doing more work (quality control, systems integration, user support and training, etc.).

This begs the question: how many FTE is the right amount?

I have not seen anyone come up with a ratio of the number of FTE per exam volume amount, modalities, etc.

PACS Challenges – A Perspective from the SIIM Regional Meeting

dondennison Healthcare IT ,

SIIM Reg Meeting Mar-2013 - PACS Challenges

“PACS” is used well beyond radiology; how can they still own it? It is being decomposed into discrete services, but it still has to come together and be fast and reliable (software is only valuable if it is available and responsive when needed).

Integrating patient records (different patient ID domains, order schema, different procedure codes, etc.) is critical to a patient’s imaging record interoperability, whether it is to consolidate records to a shared system (e.g. imaging studies in a VNA), or at access time (on demand cross indexing when viewing studies from different patient ID domains).

For all the pages of must have features that fill a PACS RFP, most people I talk to would trade most of them for a fast PACS that never crashes.

SIIM Regional Meeting in Philly

dondennison Healthcare IT ,

I am attending the SIIM regional meeting in Philadelphia. Keeping the sword sharp by listening to experts talk about challenges in radiology and informatics. Good turnout. Great to see some friends.

Noted some increasingly commonly reported trends…

  • Funds for PACS expansion, upgrades, and replacements are threatened by the focus on EMR adoption.
  • Enterprise imaging is becoming a focus for informatics professionals; a VNA is the most common place sought to store these images.
  • In addition to the VNA taking the “A” out of PACS, it seems most people are looking to PACS add-ons (“PACS Apps?”) to solve problems over looking for a solution engineered into their PACS. I wonder if this is because of the focus that a smaller vendor can apply to the problem space, or that PACS vendor resources are consumed with managing the installed base, or that they are strategically reducing R&D investment as the PACS market become saturated and radiology revenues decline.

SIIM Blog: Part 2 – Organizing Concepts to Focus Learning Efforts

dondennison Change Management , , ,

Part 2 of 2 of a SIIM blog post. Enjoy.

I have been discussing what it would take to create a “check list” of sorts (a scorecard?) to assess ones facility’s capabilities and strategies along the proposed themes listed. Would be fun to work on, but would need lots of help from people with bigger brains than mine. Stay tuned for a bonus Part 3, maybe? 🙂

P.S. Part 1 is here.

Plug-ins vs. APIs

dondennison Technology ,

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.