HIE

Article – CIOs push for patient ID progress

dondennison Policy , , , ,

For those of you faced with connecting patient records with different patient ID domains across enterprises, or within an enterprise, this article is worth a read.

Some thoughts…

  • The need/want for privacy is not the real issue. The issue is the general lack of understanding in patient ID management and strategies for dealing with them.
  • I am interested to see what the ONC (through their new Patient Matching Initiative) does to solve this issue. Many enterprises have invested heavily to implement solutions (technical and staffing and policies) for dealing with multiple patient IDs. A new solution, however novel, will not be enthusiastically embraced by organizations that are committed to a path already.
  • Beyond cost and technical issues, there are societal ones. Not all people will be willing to be assigned a number by their government to track all their health data.
  • I believe observations that “nobody under 30 cares about privacy” are misguided and just wrong. It is true that younger people are more open about their social lives and personal interests, but that does not mean they want their sensitive health (or banking) information in the public domain.

Article – New HIPAA rule could change BAA talks

dondennison Policy , , , , , , ,

As this article explains, the rules of accountability need to apply to all parts of the delivery chain, from the healthcare provider to the infrastructure vendor.

It is my experience that the readiness of the vendor to provide the necessary security controls (technical, policy, etc.) is usually not the issue. It is often the healthcare provider staff that lacks the knowledge of appropriate and effective controls that prevents proper security from being in place.

For example, even when proper single sign-on (SSO) methods are available in systems, rather than taking the time to implement this between systems (which often requires some learning), staff will often default back to wanting to simply pass a user ID and password (often a generic one) from one system to the next, because that was all they could do 10 years ago to avoid having the user log into multiple systems.

Key Images are… well, key!

dondennison Healthcare IT , , , , , , ,

As I discuss key images with vendor and healthcare provider staff, I have come to the realization that they are not well understood. Let’s see if we can correct that.

What are key images?

In most contexts, they are images within a medical imaging exams that the Radiologist reviewing the exam wishes to indicate for others, such as the referring physician and clinicians, that they are important in understanding the diagnosis.

In other context, they may represent important images for teaching purposes, quality control, surgical planning or other purposes.

In any case, they serve some importance over other images in the exam and the user wishes to communicate this. That’s why they are ‘key’.

Who creates key images and how?

In the digital world, any authorized user can mark an image as a key image on any system that supports this function. Typically, this function is restricted to authorized users like Radiologists on systems like PACS; however, they may also be created by Technologists/Radiographers on modality workstations or clinical imaging systems, like an Enterprise Viewer in an EMR.

Key images are normally created in one of two ways:

  • Manually by selecting an image and choosing a key image method
  • Automatically by creating some other form of markup or measurement on the image (implying that it has some importance)

The latter capability is important as getting Radiologists to take the time to mark images as key is often difficult. And if they are not created, the consumer does not benefit from them.

Special case: In systems that allow the user to create spine labels, these should not result in automatic key image creation.

Pages: 1 2 3

Quebec EHR …the difference 2 years makes

dondennison Healthcare IT , , , , , , ,

The news from today (May 2013) “Quebec to expand $1.6 billion EHR“. And, from 24 months ago (May 2011), “Quebec’s EHR late and over budget, AG says“.

One thing is for sure: implementing an EHR of that size and scale (with public funds), is not for the faint of heart.

Apps for Health 2013 at Mohawk College

dondennison Healthcare IT , , , , , , , , , ,

Mohawk1

I had heard good things about this one-day conference, so I decided to take the drive down to Hamilton, ON to check it out. I am glad I did.

Apps for Health has 3 tracks. One focused on Technology, one on Health, and another on Education. They also had keynote speakers to open and close the day of sessions.

To be honest, I was fearing that the recurring trend was going to go something like this: “Healthcare is broken! I love the App Store! Why can’t we get more apps faster!?!” …but the speakers were polished and came with insight and data.

Topics ranged from the needs for a “prescription” for a set of apps for different patient conditions, different levels of safety and risk that apps represent (for physicians and patients), regulatory challenges, privacy, security, and development approaches.

A collection of small and not-so-small vendors had table top displays set up, and attendees (and students) seemed to be routinely interacting with the vendor staff.

Having never been to Mohawk college before, I have to admit that I was quite impressed with the facilities. The buildings are very modern. Everywhere you look, you see technology—on the walls, in the classrooms, in the library, in the hands of the students …everywhere.

One of the more enjoyable parts of my excursion to The Hammer (nickname for Hamilton), was a tour of the Mohawk MEDIC lab. The students demonstrated a complete workflow of a patient’s journey through a referral from her family doctor, to an exam with a specialist (an allergist), and an unfortunate skiing accident in a remote area.

They showed how an EMR—in this case, the open source OSCAR EMR—could accept the referral and share it with the specialist by using an IHE XDS infrastructure. They then showed how the specialist could perform the exam and share the results back to the EMR using the same methods. They also showed the use of mobile technology by EMT and ER staff to review the patient’s records before administering treatment, thus avoiding a potential adverse incident (the allergist report found her allergic to penicillin and other drugs).

Mohawk is serving its students well. They are not only learning about the real world challenges facing healthcare, they are learning about how to build and apply open solutions, and use the latest tools to do it. And they are doing it in a fantastic facility. If you know someone thinking of going there, at least go for the tour—you won’t regret it.

Review of Stage 2 Meaningful Use Test Procedure for Image Results …and other MU tests

dondennison Healthcare IT , , , , , ,

I was just checking out the draft test procedure (PDF) for access of image results under Meaningful Use stage 2, §170.314 (a)(12).

This is the test that vendors seeking certification of their EHR products must complete and provide evidence of passing.

Often, EHR vendors get imaging wrong, but I think the authors of the test procedure got it mostly right. At least in terms of the requirements.

Essentially, the EHR must allow an authenticated and authorized user to be able to discover that exam images for a patient are available, and access the images (and associated “narrative”) in the EHR, or integrated systems, without requiring the user to re-authenticate, or search for the patient or exam.

Said another way, the system must have some form of Single Sign On (SSO) with the imaging system (or subsystem, if part of the EHR), and share the existing patient and exam context from the EHR to the imaging system.

A couple of comments…

  • I have seen SSO done well and poorly (read as: insecurely) between EHRs and imaging systems. When done poorly, it if often due to technical limitations in the EHR and/or imaging systems. Or, it is simply because the integration and/or IT staff lack the knowledge or effort to do it right (read as: securely). I have found that HIE and portal vendors and enterprise viewers are generally better equipped to properly handle SSO than EHR and PACS products (probably because they are generally based on newer technology and are often deployed in multi-facility environments that demand interoperability).
  • Integration from the EHR to a patient folder or specific exam has been around since PACS was first launched from an EHR well over a decade ago. What often gets lost is that users often want to compare exams side-by-side (e.g. pre-op and post-op). So, the imaging system may need to expand the context beyond a specific exam to allow this. As long as EHRs keep behaving like filing cabinets, the imaging viewer vendors will have to solve this.
  • The typical method of having an EHR be aware that an exam’s images are available for viewing is to push a modified HL7 ORU message, containing info about the exam, from the image manager to the EHR. The EHR then normally parses the info and uses it, along with a URL (or similar) string template, to create a context-sensitive link that can launch the viewer and present the desired exam. Some EHR can provide multiple exam identifiers, when the imaging viewer supports it, to show more than one exam in a single view. More modern methods for an EHR to discover the availability of an exam’s images is to use a REST-based query method, much like defined in DICOM‘s QIDO-RS (Query based on ID for DICOM Objects by RESTful Services) standard (in development).
  • An additional note on the URL to launch the viewer in context mentioned above: check out IHE’s work on the new integration profile Invoke Image Display (IID).

Some other test procedures that could be related to imaging…

  • Here (PDF) is the test procedure on authentication, access control, and authorization. And here is one on automatic log-off. I would have liked to see some requirements for SSO, like Kerberos or OAuth.
  • This test procedure on integrity requires a hash to be calculated and validated. This may (should) also be required for image exchange.
  • For the requirement for emergency access, if the imaging system does not allow the EHR to securely manage this (this can be done, by the way), the imaging system may have to also provide an emergency access override function (which means that the unique identity of the user had better have been passed securely to the imaging system, or it will have no idea to whom it is granting access).

Article – DoD yanked from health records project

dondennison Healthcare IT , , , , , , ,

This article is intriguing (and a bit depressing).

First, because it shows once again that the amount of money (say like, US$1 billion) that you throw at a problem does not assure success. Aligning goals and system design principles—and getting firm commitment from all stakeholders—is critical, and it doesn’t seem like that happened here.

Also, there is no mention of the use of commercial HIE technology for record exchange. The article mentions the exploration of commercial EMR technology vs. a custom (“home grown”) EMR, like the VA’s VistA. How is the ONC—a government agency—promoting the use of HIE solutions as part of their patient record evolution, but the VA and DoD not looking at the same approach?

Finally, the vision of an open system is not flawed. And by open, I mean interoperable with modern Web-based APIs. It could even mean open source.

Article – CHIME presses HHS for HIE certification

dondennison Healthcare IT , , ,

This makes sense.

If we are going to certify EMR technology, HIE should be held to the same standard. Especially as more physicians turn to their HIE to provide basic EMR-like access to patient records (mostly because the HIE interface is better than their own EMR’s, the collaboration tools are better, and there is more of their patient’s data from more sources in the HIE).