Wednesday, April 22, 2015

What’s new at HIMSS2015?

It was quite busy, especially on Monday
The largest Healthcare IT conference in the world was held in the windy city of Chicago this year. Fortunately, the weather was not too bad, except for an early rain shower, which still allowed the close to 40,000 participants to enjoy a comfortable evening stroll on the “magnificent mile,” i.e. Michigan Avenue.

The overriding theme of HIMSS 2015 was interoperability, and the picture is actually not that pretty. After having spent more than  $28 billion on incentives to implement electronic health records, the US government is discovering that information silos still exist, making exchanging information among EMR’s, and between EMR’s and Health Information Exchanges (HIE’s) or other institutions persistently troublesome.

Vendors advertise that they provide connectivity but when it comes to implementation, they are either dragging their feet and/or charging a premium to provide this capability. As a matter of fact, not only is the Office of the National Coordinator (ONC) getting very concerned, even the FTC (Federal Trade Commission) is getting involved as it now sees "potential threats to competition from high switching costs, data lock-in, and misguided standard-setting activities."

The concern about interoperability was widely shared by attendees, based on the turnouts for relevant talks during the show, for example, the presentation by officials from ONC about the recently published interoperability roadmap for 2015 drew more than 500 people, filling up the room to the max. It will likely require increasing pressure from ONC to get vendors to act and open up their systems to allow for interoperability at little or no extra cost.

The interoperability showcase booth
was bigger and busier than ever

The quest for interoperability was also addressed at the Interoperability Showcase, which demonstrated several use cases that were defined using the IHE (Integrating the Healthcare Enterprise) profile definitions. This area was bigger and busier than ever, showcasing 17 scenarios. The increasing emphasis of interoperability in the Meaningful Use stage 2 and 3 requirements probably also have something to do with it.

Dedicated area to security
Part of the HIMSS exhibition was dedicated to the so-called Cyber Security command center demonstrating how to deal with the increasing threat by hackers who are after personal information stored in electronic health records. As evidenced by the recent Anthem security breach whereby more than 80 million records were stolen, healthcare is the next main target for hackers now that financial institutions are harder to get into. Knowing that a record containing personal information such as social security number, birthday, etc. goes for $5 to $10 on the black market, you can do the math on how much a data breach at Anthem would have profited the hackers. Many vendors showed their solutions to thwart potential intruders. Note that the best way to start is to do a security risk analysis/audit, which is actually required by HIPAA regulations anyway.

Lots of innovative heakthcare IT toys
telerehab using gaming console
There also was an innovation pavilion dedicated to new IT solutions, which potentially could have a major impact. One of the gadgets I liked the most was using a Kinect box (i.e. consumer gaming console) for tele-rehabilitation. The box will track body movements, similar to the tracking used in a video game of golf or baseball, but in this case it is used to assist people in physical therapy. There is even a special sock provided that has sensors and can track gait, foot pressure, etc. and send it using blue-tooth to a receiver. A person will do his daily exercises, which can be tracked and displayed on the TV screen, following an instructor. This will allow many to do their exercises and rehabilitation in their homes instead of having to visit or stay at a rehab center.

drug cap talking with your phone
Talking about sensors, another cool gadget that was demonstrated is an intelligent drug dispenser. It either counts when the cap is removed or, even better, now there is a version that sends that information to a smart app, which can than update a personal health record to register that a person took the medication. This technology could help with compliance and potentially prevent unnecessary medical interventions due to a patient not taking his or her drugs.

One of the fun parts of the show are the many giveaways. This year vendors were not as
my favorite give-away: Vespa
extravagant as they were a few years ago when they were raffling off cars (I remember even a BMW being a prize), but there were prizes ranging from iPads and iWatches all away up to jet skis, and, my personal favorite: a Vespa scooter. I guess it was nostalgia as this was my primary means of transportation when I was in college, which seems eons ago.

In conclusion, plenty of novel new technologies, gadgets and toys, but coming back to the main issue of interoperability, there is still a lot of improvements to be made by vendors. Hopefully ONC (and possibly the FTC) will do due diligence and coerce vendors into opening up their systems and making the connection between EMR’s a reality.

Monday, April 6, 2015

XDS Implementation Issues part 4

The previous three parts discussed how the IHE Cross Enterprise Document Sharing (XDS) profile
fits into the IHE technical framework, its relationship with other ITI profiles that are needed to provide the infrastructure to make XDS work, and its “variations” including XDR, XDM, XCA, XCPD and their imaging implementations. In this part we are going to concentrate on the metadata and corresponding issues. Also note that there is an extended version in video format available of this presentation.

Metadata literally means “data about data.” For example, one could consider a “DICOM header” metadata as it has information about the image or other object, its context information such as patient and equipment information, and instructions on how to decode the pixel or other data such as the greyscale or color encoding. In addition, we also have a metadata definition as part of the DICOM standard that describes a DICOM object when it is stored on a CD or other exchange media, aka “Group 0002,” which tells a receiver about the file encoding such as whether it is compressed, the type of object, e.g. a CT image, and who created the file.

The metadata that is stored with each DICOM object has served us well in managing the information at a department level as certain attributes, such as name, ID, sex, accession number, modality, and UID’s, are used to identify the object uniquely and relate it to its series and study. It is typically stored in a database allowing for querying and information management. However, this metadata is not sufficient if we need to manage these objects across multiple domains and/or communities. For example, the accession number is only unique at a local level, and important to be kept, but cannot be used to uniquely identify the study. In addition, it is important to know which specialty created the study, for example, was a CT scan created in radiology, or was it a cardiac CT created in cardiology, or was it a CT taken in oncology to create a therapy simulation? Information about the institution where the document or image was created with the so-called author role and name is important as well.

Why do we need additional metadata? It is important for pre-fetching and display, i.e. browsing a document source database so a practitioner can determine what information to retrieve. Pre-fetching the relevant prior studies based on body part, modality, time of creation, etc, is important, as the information might have to be retrieved from various sources, which are connected with a relatively slow connection. Matching the body part, for example, can be especially hard not only because every vendor uses an encoded attribute such as defined by the usual coding schemes, but also because of “combo” procedures, such as an “abdomen-pelvis” CT. It is critical that the metadata that is part of the header is consistent and normalized, if so needed before any data is stored in a data repository. Some vendors call this normalization “tag morphing” as it cleans up the data and replaces it with consistent terms and/or codes so that proper pre-fetching and browsing can take place. Some of the metadata in the DICOM header is not always correct, and therefore, most data repositories also use the original order information for the procedure information, which is typically available as a HL7 transaction.

In addition to metadata consistency, the actual contents of the metadata file, which by the way is exchanged as part of the XDS protocol, is still not quite cast in stone. Early implementations find that additional or other data elements are needed in addition to the ones that are part of the original XDS specification. The reason is that information sharing across enterprises is still relatively new and different workflows depend heavily on the practice settings, regions and healthcare systems that are very different for each country. That is why most vendors who provide XDS solutions are still in the process of adding and configuring the metadata contents depending on the specific user requirements.

In summary, XDS has been widely implemented and early results for connectivity events such as connectathons have demonstrated that it can work in theory. However, the number of installations using these profiles, including the several variations (XDR, XDM, XCA and XCPD) have been limited. The reason is the lack of infrastructure to make XDS work, the presence of many proprietary solutions for information exchange, the fact that the metadata still needs refinement, and a lack of education among customers and potential users. Hopefully, this will change as the early adopters of this technology begin to share their success stories.