The Healthcare IT Guy

Yesterday I wrote about the doc in Switzerland who was excited about using his iPod for viewing medical images and I commented about the potential for sensitive information getting out. I got lots of attention for that article via e-mail asking for a bit more information on clinical data theft so I looked through my notes and saw this article on medical data theft.

Just in time for Halloween, here’s one scary scenario (sort of blackmail):

Consider a recent case at a university hospital in California, where the doctor’s notes from a patient visit were first sent to a transcription service company in Florida, which decided to subcontract to another firm in Texas. The Texas firm subcontracted the work yet again, ending up with a woman in Pakistan. This Pakistani woman became upset because her payments for her services were late, so she decided to send an e-mail to the university hospital, threatening to post the medical records on the Internet if she was not paid immediately. It might sound like a nightmare, but it is the reality of outsourcing today.

Even if The Exorcist movie didn’t scare you, the following should make you keel over:

In a recent undercover operation, reporters successfully purchased personal information from employees at an Indian outsourcing firm for only $7.00 each. These data sellers clearly did not understand the importance of confidentiality for those to whom these data belonged.

Duh!

All our secrets for $7. I thought I was worth at least $10.50.

We’ve all suspected the cell phone ban in hospitals makes about as much sense as banning cell phones on aircraft. Here’s an interesting take on the topic in in an audio format at Future Tense. Jon says:

Many hospitals and clinics across the U.S. forbid the use of cell phones in rooms containing medical equipment. No-phone polices were borne of fear that phones will cause electrical interference that could cause medical devices to malfunction. Cell phone restrictions can be an inconvenience to patients, their family and friends.

But researchers at Mayo Clinic say they’re close to concluding that today’s cell phones do NOT interfere with medical equipment, and probably never have.

Mayo cardiologist David Hayes has just published a new study - his second on the topic - that fails again to find any significant problem with cell phone interference.

I just saw this scary article “I use my iPod to store medical images” on CNN.com. Given that an iPod is just a giant portable hard drive with MP3 encoding software, I’m sure it’s very easy to put medical records and other images onto the device. But what happens when your iPod gets stolen? According to the Washington Post,

Across the Washington area, thefts of digital music players are rising, police say, putting [victims] through the emotional trauma of losing something that has become an increasingly important and personal part of their lives. Victims said they felt the thieves got an illicit glimpse at their musical tastes and even their “souls.”

Now, instead of getting a glimpse of an owner’s “soul” an iPod thief could have access to medically sensitive information. I think most docs in the US are smarter than tossing sensitive information onto iPods.

In my career I’ve spent many years consulting for the American Red Cross, which is a great organization to work for if you want to feel that everything you do on daily basis counts for something in your fellow Americans’ real lives. I worked as a senior engineer for a few months, several years as a team lead, and then several more as a chief systems architect on the National Biomedical Computer System (NBCS), which is one of the world’s largest FDA-relgulated 510k medical devices. NBCS manages the blood collection and distribution workflow for Red Cross’ blood donation program. The entire hardware, software, and communications infrastructure which included millions of lines of code and dozens of servers is covered under the 510k. When I saw this “Judge Rules Against FDA in Landmark Medical Device Manufacturing Case” press release come across my desk it brought back memories of the kind of struggles we went through trying to get and maintain FDA approval on the projects I worked on. The following quote from the release is especially familiar:

This is a landmark decision that clearly shows that medical device companies need to comply with the relevant regulations, not the subjective demands of FDA personnel,” said McKenna Long & Aldridge attorney Dan Jarcho. “This ruling is a common sense breath of fresh air that affirms that regulated companies can turn to the courts when the FDA refuses to act fairly.”

The 510k submission process, while covered under CFR, is indeed quite subjective (especially for something as complex as a software device). This ruling against the FDA will probably the first of many cases where small and large device manufacturers will be able to question FDA personnel, which may or may not be a good.

Another interesting snippet of the PR is the following

At issue was a disagreement over how the company sought to meet QSR requirements in the areas of adequately validating its manufacturing process, validating its software and uniform complaint handling process. In August 2004 the FDA sought to shut down the operation of Utah Medical’s 160-person facility in Midvale, Utah.

Keep in mind that FDA can, and sometimes does, shut down operations of a facility for lack of paperwork and other subjective reasons, regardless of whether or not there is actual evidence of any flaw in the device. This action keeps manufacturers diligent with respect to paperwork, sometimes costing significant amounts of time and money, which may take away time from actual engineering and validation concerns.

Another interesting aspect of the article is on the word ‘nitpicking’, something which almost all manufacturers can sympathize with (imagine showing a unit test result or formal code review document to a legal or government official who knows nothing about coding).

…the FDA’s case, which he characterized as “extended and in some instances ‘nitpicking,’” arose “in part because of the general nature of the regulations themselves, which have the virtue of generality and the vice of imprecision. This endemic problem is perhaps augmented by decision-makers who themselves rely too much on inspectors’ reports without taking a fresh look themselves at ongoing changes made by Utah Medical in response to questions raised.”

As a veteran working on a complex system that took years to gain and maintain a 510k medical device status, I am a bit torn by the ruling. I think that it’s good that subjective ‘nitpicking’ can now be questioned but it’s also going to weaken the FDA a bit to where they may not be able to do their job properly unless they are able to have substantive say in how a medical device is validated. Only time will tell what this case means but if a small company like Utah Medical Products can beat the FDA, the precedent can sure be used by larger firms with more resources. Now, instead of spending time fighting FDA on the grounds that validation practices, test plans, and devices are sound medical devices the courts may accidentally become a way for vendors to get around strict rules and regs.

If you’re interested in the case, the full legal opinion is available.

When the conversation turns to Clinical Information Systems (CIS or EMR) you can almost feel the polarization in the room. Ask two different groups of health care professionals these two key questions and you’ll walk away with the answer - a resounding “maybe”.

• Does the implementation of a clinical information system decrease the time clinicians spend on documentation of care?
• Does the implementation of a clinical information system increase the quality of care by allowing clinicians to spend more time with patients instead of paperwork?

It’s not that the profession is wishy-washy on the subject. It’s more like the correct answer depends upon who you ask and what specific experience they’ve had with a particular CIS. One thing is for sure; hardly anyone has “no opinion”. Here’s why:

New Attitudes, Broad Latitudes

The introduction of any new technology into the workplace causes some degree of stress among those who must adapt. It is not unusual to see an overall decline in productivity as new work patterns evolve and as the cultural resistance begins to give way to the “ah ha” factor.

As with any major computerization effort, success is more about managing people and their expectations than it is about hardware and software. In the early stages of adaptation even the best CIS is going to be an order of magnitude more difficult for health care professionals to get their hands around than paper-based notes and charts are. It’s up to the organization’s major stakeholders to see that a transition plan is put in place and that it works.

And therein lies the rub. For organizations who have successfully implemented a CIS program, and who measure that success by the amount of time that health care practitioners have to spend with patients as well as the increase in the quality of care that those patients receive, the answer to the two questions posed earlier are a resounding “Yes”. At least according to Siemens, a CIS vendor who reported the following statistics after a 2003 CIS implementation at the Cincinnati Children’s Medical Center:

• Generation of complete, unambiguous, legible care orders
• Reduced clinician and service provider pages and phone calls to clarify orders
• Eliminated transcription errors in medication orders
• A 35% reduction in all medication errors
• An overall 52% improvement in medication turnaround times
• A 50% improvement in response time for urgent x-ray
• A 24% reduction in verbal orders for controlled substances
• 100% compliance with pain assessment documentation requirements defined by state regulatory agencies

For those who would answer our two questions “No”, it is very likely that their organizations failed to take the necessary steps to mitigate these most common points of CIS implementation failure as reported by a Journal of American Medicine special report entitled “Determinants of Success of Inpatient Clinical Information Systems : A Literature Review”

• System development problems
• Implementation process problems
• Failure to address the culture and characteristics of the organization.

It seems that in the end, the health care profession is more or less the same as any other when it comes to computers in the workplace. If you match the system to the user’s requirements, and you properly prepare and train the users, the end result will be an increase in productivity and an increase in the quality of service level commitments.

Tim over at Medical Connectivity Consulting has a nice article morning entitled Cisco’s Medical Grade Network Provides New Connectivity. He introduces the article by saying the following:

On October 11th, Cisco broadcast a live webinar to introduce their Clinical Connection Suite (press release). Of course Cisco makes the same network boxes for health care as they do for every other vertical market, but they create a vertical market spin with alliances, marketing and distribution. Cisco has done a service to the industry by highlighting solutions to important problems in health care and growing the overall connectivity market.

Read on…

When I worked on one of my first healthcare applications back in 1994 it was designed for TTY (UNIX terminal) use. The state of the art at the time was full-screen GUIs like Windows 3.1 but in the helathcare world we’re always years behind (for good reason sometimes). One thing I’ve noticed is that modern healthcare UI designs circa 2005 are no more “usable” than designs 10 years ago.

We’ve moved to Windows and web technologies but ultimately everything has just been about data entry, pick lists, tabs (and more tabs), etc. Every vendor claims their applications are “intuitive” to use but with such complex workflows and business processes in the healthcare world it’s unclear what intuitive means.

We need more people who know how to interpret what users say into language that developers will understand. The “requirements team” is not the same as an expert in UI design. Most firms will end up using systems analysts for the purpose of designing UIs or hire a “graphics guy” to do their graphics and assume that’s the UI. What they don’t understand is that user experience in a complex application has little to do with the way things look and more to do with how they work.

If you’re involved with creating UIs for healthcare apps, here are some useful links that may help you learn more about the topic:

• A user-centered framework for redesigning health care interfaces
• Human Factors MD (organization)
• Four Basic Activities to Reach Optimal Usability
• HHS Usability.gov
• Making Medical Device Interfaces More User-Friendly (a little old but still useful)

Ok, I write articles on healthcare IT but I just read a great article on how to reduce medication errors that CPOE (Computerized Physician Order Entry) implementations are still not catching. The author says:

…patients continue to suffer from medication errors. Many of these could be prevented by projects a lot simpler, faster, and cheaper than CPOE. I’m speaking as both a pharmacist and IT director. In addition, these activities can help prepare you organization for eventual CPOE adoption. I’m not even talking about mid-tech projects such as barcoding. These are non-IT steps that require little investment, just unwavering commitment and willingness to do the right thing.

Click here to read the article. I loved how he ended the article:

It’s just amazing that hospitals don’t want to fix bad processes, but they naively expect that CPOE will heal all. Let’s face it: if your staff and docs don’t follow the rules now, they won’t follow it with CPOE either. I’ll bet you have bunches of policies on order scheduling, abbreviations, legibility, order dating and signing, restricted drugs, and many others that are completely ignored. How are you going to build this random interpretation and illogical processing into a CPOE-driven automated environment? Answer: you aren’t. Before you get your hopes up for CPOE, clean up your existing house first. You just might save a few patients while you wait for that magic wand.

Most clinical systems developers, like those creating electronic medical records (EMR) management systems, think the most important user in the system is the doctor. Doctors often are on the boards, they are often founders, they are probably interviewed ad nauseum to help create the EMRs. However, in my experience working with nurses is often times a better of way of getting the details squared away and then getting the doctors involved with pieces that might have been missed. The situation is pretty clear: if nurses don’t use the EMR, the EMR will only have partial information. And if an EMR only has partial information it may be actually more dangerous than not having an EMR at all.

Don’t get me wrong, the docs are crucial but we as clinical application architects and designers shouldn’t forget the nurses that also need to use the EMRs. Here’s an article on the subject written a few months ago that sheds some light on how to write clinical software that cater to nurses’ needs.

Clinical data aggregation has been around for a long time but given near-ubiquitous availability of thin client computing devices across hospitals, it has been picking up steam for some time now. medGadget reports on UCLA’s recent implemenation of GCQ’s technology in its hospitals.

Today’s front page Wall Street Journal article Medical Companies See Troubling Side Of Chinese Market is a very interesting and timely one. Note: WSJ registration is required to view this article.

Timely because many of the healthcare problems and opportunities we have in the US with only 300 million people will be available in China’s massive 1 billion population.

So, if you’re looking to make money in the Chinese medical industry, now is the time to get involved but the WSJ article warns in the subheading “As U.S. Makers Aim to Profit From Boom, Some Find Doctors Expecting Bribes”.

Health/medical informatics is a 55 year old industry; in fact, some of the first applications written for computers in the 1950’s and 60’s were for managing healthcare data. Throughout that history, thousands of applications have been written, rewritten, and thrown away. What always remains, though, is data. Databases of healthcare information created decades ago are still available and some are still in use.

The traditional approach to healthcare software development, which continues to this day, has been application focused: a need was identified and a program was written to address that need. This stove-pipe (disintegrated) process continued for the wide variety of needs within the healthcare space to such an extent that today, on average, U.S. hospitals have more than forty distinct information systems, handling information for different departments and divisions, and fewer than 25 percent of these systems regularly share information with other systems. And, any information that is not shared needs to be recreated or duplicated in other systems, all of which require roughly the same patient, organization, prescription, charts, and other data.

With each application acting as a silo and without the information tools supporting integration of data, users are left to fend for themselves, resulting in lost information, difficulty finding what is needed, creation of “dirty� data, error-prone duplication of entry, and, perhaps worst of all, a system where the lack of information sharing for drugs or clinical information jeopardizes human lives.

Consider a typical healthcare organization with typical information management requirements: people (care providers, patients), organizations (clinics, hospitals, departments), relationships between people and organizations, characteristics and attributes of people and organizations, etc. If we cataloged the information management requirements, even for fairly diverse constituents in the healthcare industry, the majority of the requirements would be similar if not identical. What this means is that each application that manages patient data would duplicate that data and not work with a master database of patients. An application that managed drug inventory would duplicate patient data again just to track prescriptions. An application that managed schedules would duplicate patient data just to manage appointments.

The problems with the application-focused approach become clear in a practical operating environment. The typical healthcare user must interact with a number of different applications. For example, a private practice physician must interact with applications for scheduling to check on patient load, managing an electronic medical record, writing orders, dictating a transcription, reviewing claims submissions, patient emails, and continuing medical education. A nurse will have to maintain the schedule, handling the ICD/CPT coding, billing, intake and out-processing of patients, phone calls, medical record management, follow-ups, and her own continuing education. It is obvious that their jobs and responsibilities require that they access information that crosses the boundaries of each of these applications. And each time they have to move from one application to another (or from a paper-based way of doing things to the computer), they waste time in reentering information or retrieving duplicate information.

To integrate data and keep from duplicating functionality and information capture what is needed is a way to model and create common services instead of applications. Services in this context are referring to pieces of computer code that are small, reusable, and focused granules of functionality instead of large monolithic applications. For example, any application that needs to register a patient or edit patient demographics would use a common patient registration service; an application that needed to discover what prescriptions a patient have would use a common patient medications service; and, an application that needs access to a care provider’s credentials would use a centralized credentialing service. These are all examples of healthcare services that been written as computer code once and then reused across dozens of applications.

Modern patient-centric service-oriented applications will need to orchestrate and deliver end-to-end business processes across multiple users and channels by leveraging existing legacy systems. Such applications enable healthcare companies to convert existing IT assets into business Services and orchestrate these Services into business processes.

Most of my clients and friends who want to get into healthcare IT often ask me about which books I would recommend. Given that the healthcare landscape is so vast and broad, it’s hard to answer that question so I’ve come up with a brief list to get people started.
Read more »

In an attempt to answer the question “How will mobile communications change healthcare in the future?” and make some big bucks in the process, The Medical Records Institute is hosting a conference on mobile healthcare in San Diego December 12-14. According to their website the conference will focus on the following:

* e-Prescribing: experience reports, successes, time comparisons, the e-prescribing challenge, point-of-care computing and order management
* Interoperability: sending messages and documents between medical devices, EMR systems, phones, and other communication devices
* Device Communication
* Strategies For Telecommunications: Understanding the options for a hospital to select a communications partner
* Analysis Of The Current Mobile Healthcare It Market: WiFi vs. Broadband and Blue Tooth; how to integrate them; what is the best strategy?
* Areas Of Growth In The Healthcare It Market
* Mobile Healthcare It And Workflow

HealthLine, a new search engine that translates regular language into medical terms and helps refine broad terms into more specific ones, launched today.

As any good search engine architect knows, searches that returns too many terms can be improved with visualization so the HealthLine folks have come up with a nice HealthMaps feature that displays related information visually.

You can take a tour to learn more.

Dr. Mohammad Al-Ubaydli, a Visiting Research Fellow at NLM (NIH), is teaching a course entitled Open Source for Healthcare on November 2-3 from 10a to 12:00p. If you’re in or around NIH you should definitely drop by. Dr. Al-Ubaydli did a one hour lecture at Johns Hopkins in June covering biomedical uses of open source software and it was videotaped and the stream is available.

The Society of Teachers of Family Medicine has just unveiled the Family Medicine Digital Resources Library. They say the purpose of FMDRL is:

To support and enhance the sharing and collaborative development of educational resources among family medicine educators through Digital Library that will include resources for all levels of family medicine education.

I just came across this new Wiki put together by the Association of Medical Directors of Information Systems (AMDIS). The folks at The Informatics Review say this about it:

The Clinical Informatics Wiki is version of a wikipedia devoted to topics in clinical informatics. The goal of this resource is to provide clinical informaticians around the world a place to document and discuss many of the most important lessons they have learned in their day to day activities.

Specialized Customer Relationship Management (CRM) software has been in use (mainly outside the healthcare sector) for over a decade now and has provided organizations a sophisticated means to track customer information to help improve satisfaction and service. Although some forward thinking healthcare companies have customized and adapted traditional CRMs to help manage patient-centric data, managing patient information in CRM software is difficult due to the large volume of information tracking required and the fact that patient privacy is often difficult to protect in current CRM software.

What is needed in our healthcare industry is patient-centric CRM software, or Patient Relationship Management (PRM) systems. PRMs are not widely deployed at this time because of legacy software connectivity requirements and the fact that it’s difficult to come up with software that can adequately track, and keep private, thousands of pieces of medical, clinical, and demographic data elements.

The healthcare sector represents the largest single industry in the world, representing nearly $4 trillion globally. Moreover, this industry manages more information than does any other, with a greater volume and complexity per transaction and series of transactions than seen in other sectors. There are an estimated 90 billing healthcare transactions taking place globally; unfortunately, more than 90 percent are happening via phone, fax, or postal mail.

The complexity of efficiently managing health and clinical information has magnified exponentially during the last decade. As the number of healthcare industry constituents has grown and the relationships between them have increased in complexity, the information management requirements for efficiently managing medical data have become significant. Moreover, the healthcare field is spending much less on IT infrastructure and solutions than most other industries. Roughly 40% of companies spend less than 1.5% of their operating budget on IT and 35% of them spend 2% to 4%.

Although some countries have nationalized healthcare and are able to provide government IT systems for health information management, no single system or even small group of systems can manage the complexity inherent in the United States’ healthcare sector because the US does not have a single payer system. It is common for medical services to be rendered to patients by one organization (a hospital or clinic) and paid by a third party (an insurance firm). In order for healthcare organizations to better manage their new information technology requirements, they require modern tools that are designed to work with legacy infrastructures in a service oriented approach/architecture (SOA) where middleware is able to get information to and from multiple systems and applications that have likely been around for decades.

Even though SOA makes a good deal of sense in the healthcare IT industry, beware of the hype and existing vendors simply “SOA” enabling their existing software suite. It’s not going to be easy to convert closed legacy healthcare systems into open service oriented applications and databases. Cerner or IDX won’t be able to become “service oriented” by slapping on a label. Epic and Meditech can’t become service oriented given that they couldn’t even make the move to object oriented quickly. Eclipsys and Seimans can’t just put in a messaging system and tell you that they’re now service enabled because they can pass messages between systems. Before your existing vendors come to you with their SOA message, have them explain to you what they think about SOA, why they think you should care, and why systems that they’ve had around for years are now, suddenly, service oriented.