Article – Insurers will have to change to survive

I have been very interested in the changes to how Radiology revenues will be affected during the shift from volume to value based reimbursement, along with changes to healthcare business models in general. I blogged about it here.

I have also been interested in how Radiology will have to change their behaviors in this new environment of transparency and empowered consumers. I blogged about that here.

In this article, a healthcare investment firm details how insurers will have to change in order to compete for mind share among consumers (with choice).

Another very interesting point they make is about wearables. I agree that they are only used by so called Innovators (from the Innovation Adoption Lifecycle model) today.

But what if insurance companies start offering incentives in the form of reduced policy premiums for people that use them (and share the data with the insurer perhaps). This is much like having a security system on your home lowers the cost of your theft insurance, or smoke detectors lowers your fire insurance premiums. This would create a boom in the mHealth sector, and would likely improve outcomes through early detection and correcting unhealthy behaviors.

I wonder: Will providers and insurers compete for who knows the patient best?

Providers have the EMR data (for encounters with their facility), and perhaps from an HIE (if they are part of one). Insurers have info from payment transactions spanning hospitals, clinics, pharmacies and others.

Where will the data from wearables go? If the insurers are buying (by lowering premiums), I will bet that they get it more often that the provider.

Will wearables and mHealth device vendors be savvy enough to provide it to both? Will consumer-controlled PHR vendors (or information aggregation and brokering tools) have an optimized method for getting data from all a patient’s devices and apps into EMR systems? Will the provider’s EMR or HIE be open enough to receive and store the wearable’s data without manual data entry (or copy-paste)?

Will patient’s be willing to share this personal info with providers and insurers? I will bet: yes.

If I thought the data would help my outcome, and I trusted my provider, I would share it.

If it was certain to lower my premiums, I would share the info with my insurer. If the insurer reserved the right to increase premiums based on info that my wearable provided (i.e. if I sit on the couch too long, my payment goes up), I might reconsider.

Will providers supply no cost (or subsidized) wearable and mHealth devices (or apps) to patients? Will insurers and providers share this cost?

So, how can wearables help in Radiology? Other than sending out reminders on where and when to show up for the exam, and what to do (e.g. eating, etc.) prior to the procedure.

The Value of Hackathons in Healthcare

Having participated in the inaugural SIIM 2014 Hackathon, I can appreciate the diverse expectations that participants have. Some think of these events as a way to learn and experiment, others a competition. Some prefer to work as a team, others alone. Some are interested in integrating existing systems and data in new ways, while others want to invent something completely new.

In any case, I found this article insightful. It explores why the concept of “hacking” is so prevalent in healthcare, and also touches on why new “apps” often struggle to make it past the hackathon stage. It even posits that a hackathon can replace the traditional RFP procurement process for identifying and selecting innovative solutions.

Article – SIIM Hackathon gives DICOMweb a coming-out party

Check out this article in Radiology Business Journal on the recently concluded Hackathon at the SIIM 2014 Annual Meeting in Long Beach, California.

Here are my other observations on SIIM 2014, in case you missed it.

JDI Article Published – Where to build It

Another article I submitted to the Journal of Digital Imaging has been published electronically.

This article compares the pros and cons of building a healthcare IT application in an Established Vendor, a Start-up or a Hospital Lab environment, examining aspects such as access to design input and validation to commercialization and transition to support.

Check it out and let me know what you think.

Favorite Blog Posts of 2013

As the first calendar year of my blog draw to a close, I thought I would compile a list of my favorite blog posts from 2013. I hope everyone has a safe, happy, healthy and prosperous New Year.

  1. 100th Blog Post: What I know about Software Development and Crisis Management
  2. The rise of the mobile-only user …and how this helps the underpriviliged
  3. Review of Stage 2 Meaningful Use Test Procedure for Image Results …and other MU tests
  4. Quebec EHR …the difference 2 years makes
  5. Video – Empathy: The Human Connection to Patient Care
  6. Designing for the ‘Public’ and the ‘Pros’
  7. Articles on Mobile Health Applications and FDA Regulation
  8. Plug-ins vs. APIs
  9. Article from HIMSS: PACS will not remain a self-contained data silo
  10. Blog posts on SIIM Web site (Part 1 and Part 2)

PACS-centric vs. VNA-centric models for including imaging in the EMR

Like many problems, there are more than one valid solution. For the challenge of getting images to both diagnostic consumers (e.g. Radiologists) and clinical consumers (e.g. ordering physicians, EMR users), there are many ways to define a solution architecture, but two are most obvious: PACS-centric and VNA-centric.

PACS-centric

In this model, the PACS is the primary system, interfacing with modalities, providing a client to diagnostic users, as well as access to clinical users though an enterprise client embedded in the EMR. Mobile access may be direct or via a mobile EMR user interface, but it is getting images from the PACS. Enterprise images are captured and stored in the PACS (though storing to VNA and routing to PACS is also possible). The VNA’s role is primarily as an archive to (one or more) PACS.

PACS-centric

VNA-centric

In this approach, the VNA is the primary image management system. The PACS likely still interfaces with modalities (though not always), but captured enterprise images are stored to the VNA, and sent to the PACS when needed/supported. Clinical viewing in the EMR is done by an Enterprise Viewer, which may or may not be provided by the VNA vendor. Mobile access is also through the Enterprise viewer, getting images from the VNA.

VNA-centric

Pros and Cons

As stated, both are valid approaches, but each has some inherent strengths and challenges.

The PACS-centric solution has a high likelihood of having all parts of the medical imaging record being available in both diagnostic and enterprise viewers. Proprietary data (e.g. markups and key images) not provided through standard data objects (e.g. DICOM GSPS and KOS) are more likely to be visible in all clients. There may also be some common application configuration settings across clients, which would reduce administration complexity and cost. Getting the image management and image viewing (diagnostic and enterprise client) all working together is the burden of the vendor (i.e. it is an engineered solution designed to function as a single system).

The VNA-centric solution is better suited to support a multi-PACS environment, providing a common management and viewing platform for enterprise users—only the single Enterprise Viewer is embedded in the EMR (vs. the multiple ones provided by each PACS). Environments with multiple PACS and Mini-PACS benefit as the VNA is the common sharing (and data quality validation) point among them—this allows for a more “pluggable” solution where systems that address niche needs can be used until the primary PACS is able to replace them. In this model, the integration among the components is more complex and places a higher burden on the institution to get it all working (i.e. the informatics and IT staff need to be willing and able to put this together), even with purchased professional services from all the vendors involved.

Assuming both the PACS and the Enterprise Viewer support LDAP (Lightweight Directory Access Protocol) and/or SSO (Single Sign-On), user authentication may be equal in both approaches.

Both a well-designed PACS and VNA (and Enterprise Viewer) can provide effective multiple patient ID management methods (e.g. MPI or IHE Patient Identifier Cross-Referencing), to allow integration/exchange of patient imaging records across patient ID domains, though the VNA and Enterprise Viewer are traditionally more likely than PACS to support flexible models.

In both models, storage for the long term archive is expanded at the VNA.

Article – FCC, FDA, ONC seek input on mHealth regs

I find the topic of this article interesting.

Here’s why…

  • We have had notebooks and netbooks on WiFi accessing Web-based and other types of applications deemed medical devices (e.g. PACS) for years. The essential difference between a tablet and a netbook is the keyboard. They pose the same risk as a client application platform.
  • If this is what regulators are worried about, wait til they get a load of the bigger billy goat coming across the bridge next …mobile apps are one thing, but what about a portal framework that aggregates patient data from distributed sources, in real-time? Imagine a screen where each discrete element of the patient record is managed in a different system. The values used to define and indicate normal and abnormal test results are from a public Web site. Where does the “medical device” start and end? Who is the “manufacturer” responsible if an issue arises? How do you manage the medical device labeling? With mobile, we are simply trying to figure out how to do what, in many cases, we do today, only now without a wire. …regulatory affairs folks are in for a world of change (or healthcare will fall ever farther behind the IT curve).