Presentation by Dr. Alan Kaye (Advanced Radiology Consultants) at ACR 2013 Imaging Informatics Summit, quoting Dr. Rawsson: “It’s hard to put the patient at the center of the universe if you’re sitting there yourself.”
Interoperability
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.
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.
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.
FDA and New Cybersecurity Regulations
A friend forwarded this post to me.
Links worth checking out…
- Network World Article: US FDA calls on medical device makers to focus on cybersecurity
- FDA: Content of Premarket Submissions for Management of Cybersecurity in Medical Devices – Draft Guidance for Industry and Food and Drug Administration Staff
- FDA: FDA Safety Communication: Cybersecurity for Medical Devices and Hospital Networks
Here are my thoughts…
- Frankly, security in healthcare devices ranges from embarrassing to terrifying—especially at the interface point between devices/systems. As more devices become network enabled, the level of risk is exponentially increased. Too often, software in medical devices are built by clinically focused developers, or hardware engineers tasked also with the software layer. Developing for security (and performance) is a specific skill set within software development, and it is not commonly found in the average developer. I have found that developers with experience in Web-based consumer applications (that manage personal data) and those with banking application experience generally “get it” more than others, but that’s just my experience. Also, product managers need to get a lot smarter about security and make it a priority in the product scope.
- Regulations are brought in when industry fails to protect the public interest, and that is what is happening here. If the medical device industry was better at doing proper risk-based design and validation—which security and protection of data would certainly be an area of focus—and including risk mitigation controls in their designs, the FDA would not need to issue regulations. But, here we are. Now we get to see if government regulators can produce effective regulations, and keep pace with the ever-evolving security model best practices and methods.
- Where the HIPAA Security and Privacy rule applies to the healthcare provider organization (that is, it is their responsibility), FDA regulations apply to the registered device manufacturer. Regulatory Affairs staff working for the vendor community are going to have to learn a lot more about cybersecurity. Most of the professionals in this field that I know, know very little about this topic. If you are a cybersecurity consultant that knows even a little about healthcare IT application design patterns and existing medical device regulations, this is a goldmine. Hmmm, maybe I will study this FDA stuff in more detail. 🙂
Post-SIIM 2013 Annual Meeting Reflections
Another great SIIM annual meeting is behind us and it was great, as always. I am going to post some thoughts and reflections this week.
Today, I have been thinking about analytics and, in particular, the use of a workflow engine and a standardized set of terms and definitions (such as what is being defined in SWIM) to ensure analysis of workflow events (type, timing, relationships, patterns, etc.) consistently across systems.
There were several great talks by Dr. Brad Erickson and Chris Meenan and others on the topic and these were followed by a large turnout of engaged attendees for a SWIM demo (see pic below).
My thoughts…
- The use of a mature, off-the-shelf (open source or commercial) workflow engine has been considered by PACS and RIS vendors, with some attempting to use them in their product. It has not been widely adopted for two main reasons (I believe)…
- Most PACS from large vendors were bought, not built by them—the risk of replacing the built in logic with an external engine without introducing functional regression is high (read as: it would be expensive);
- Unless the workflow engine spans several systems, it would not have the full benefit (see more on this below).
- The workflow examples cited often started with the arrival of the image objects from the modality (initial event that starts the workflow channel). Ideally, the workflow engine extends to before the order is placed, managing the order placement, decision support to ensure the right procedure is ordered, scheduling, protocoloing, and acquisition, along with the reading and post-processing steps. It should also span to the results distribution and archiving, managing the timing and destinations of the report and the lifecycle of the historic imaging data.
- One of the limitations of using a parallel image management pipeline (e.g. sending images through a system before arriving in PACS) in order to detect the event that triggers the workflow can introduce some points of failure. Consider if the system integrated with the workflow engine goes down and images don’t get to the PACS—this outage would limit the value of the integrated image management and workflow engine system. A possible solution is to extend PACS and other systems, such as the RIS, EMR, CDS, VNA, Enterprise Viewer, document management system, etc. to expose the event information. This would allow the workflow engine to apply the desired workflow rules and orchestrate the data flow and work steps without being a potential bottleneck.
More thoughts from SIIM later. Stay tuned.
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).
Quebec EHR …the difference 2 years makes
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.
More from Apps for Health 2013
As I mentioned last week, there was some valuable info shared at the Apps for Health event at Mohawk college in Hamilton.
The keynote speaker, William Falk (@willfalk), shared some valuable statistics, along with a proposal for how to envision different types of apps, using a pharmacy dispensing different types of drugs, as a metaphor.
He has also shared his slides, which are well worth a look. Enjoy.
Article – Readers Write: 256 Shades of Grey(scale): The Dirty Little Secrets of Radiology and PACS
Contrary to what the title suggests, this article debates whether radiology has succeeded in solving the problem of going digital (by using PACS).
I believe that PACS solved the initial problem that it was intended to solve: get rid of film. Whether it provided more value than that had a lot to do with the design of the PACS, and who was managing it.
But, the value of PACS has a lot more to do with how it is deployed, configured and managed. If a PACS owner fails to use informatics and operational best practices, they and their users will suffer. If they fail to invest in and manage the infrastructure—such as the networks, servers, and storage—they will suffer.
I have seen too many PACS operators with too heavy of a dependence on their PACS vendor. Radiology and IT too often lack staff that understand informatics, integration best practices (e.g. as defined by IHE), or how their system operates. I have seen two hospitals with the same software application doing very similar exam volumes, and one experienced high levels of user satisfaction and operational excellence, while the other had chronic issues.
I would argue that in today’s mature PACS market, it is not what you buy, but how you use it. Provider staff need skills and knowledge about best practices. They need to know more about PACS in general, and be less constrained to knowing only what their PACS vendor tells them. And one of the best places to develop these skills and broad knowledge is SIIM.
I’ll be at the SIIM meeting—stop and say ‘hi’ if you see me.
Apps for Health 2013 at Mohawk College
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.
Infographic – Healthcare Providers and Health Information Technology
A picture is worth a 1,000 words …or about US$19 billion, in this case.
Check out this USA Today-style (or theonion.com, if you prefer) infographic from the ONC.
Here is some fun with numbers….
A couple of months ago, I posted on a survey on doctors’ satisfaction with their EHR. An excerpt from the article about the survey…
“In 2012, about one-third were “very dissatisfied” with the ability of their EHR to decrease workloads, up from only one-fifth in 2010, according to the survey. Gripes were seen elsewhere, too. Thirty-two percent were dissatisfied with EHR features and functionality in 2012, compared with 20 percent in 2010, while 37 percent in 2012 were not pleased with their product’s ease of use, up from 23 percent in 2010.”
In the infographic, the ONC claims that “85% of physicians who have adopted an EHR system reported SATISFACTION with their system” (47% “somewhat”, and 38% “very” satisfied).
So, somewhere between 15% (ONC’s numbers) and about 33% (survey’s findings) is about right, I guess.
The survey and the ONC did agree on one area…
- ONC: “8 in 10 of physicians reported that EHR use enhanced overall patient care”
- Survey: “One-fifth were also highly displeased with the technology’s ability to improve patient care last year, compared with one-tenth in 2010″
Don’t get me wrong: I believe in the value of an EHR. I just bet that those using them 10 years from now wish that they could send us a message about what ended up really mattering.
Don K Dennison 