Two New Challenges to a Healthcare Cybernetic Utopia: Yet More Hurdles Exposed

At "2009: a Pivotal Year in Healthcare IT" I concluded that 2009 had proven to be a critical year in HIT, due to authoritative publications on HIT difficulties and related issues that appeared that year.

It was good to see the critical thought processes and the scientific methods inherent in modern medicine applied to the irrational exuberance and marketing-dominated field of healthcare IT.

It seems in 2010 the trend may continue.

Two new very interesting publications have recently come to my attention regarding the complications that can, and are, introduced by HIT.

These complications are worsened by the "boatload of cash," as one author expressed it, that is helping fuel what I term an irrational exuberance, or purchased exuberance, in this technology and its use in social re-engineering in medicine.

-----------------------

The first publication of note is a newsletter "Medical Risk Management Advisor" from ProAssurance Indemnity Company, Inc. and affiliates, a provider of medical insurance for clinicians. It can be downloaded here (PDF). It advises:

On choosing an EHR system:

Be sure to obtain physician input and review of the software prior to purchase to ensure it meets the needs of your practice. Consider talking to other medical practices already using the software, not only to assist in your decision, but to anticipate flaws or errors existing users may have encountered. Lastly, establish a process to address problems discovered after implementation.

"Anticipating flaws or errors existing users may have encountered" seems to be at odds with nondisclosure clauses in heathcare IT contracts, but this insurer seems to have gotten the message that HIT is not a perfected technology by a long shot.

On Alert fatigue:

Physicians may ignore e-prescribing alerts for a variety of reasons (e.g., excessive alerts or alerts that are not clinically useful). Again, input from physicians prior to implementation can help prioritize and choose alerts appropriate to the practice.

That the advice has to be given by an insurance company to healthcare organizations that "input from physicians prior to implementation" is crucial reflects a pathology, whose root is within the paternalistic and patronizing IT culture.

This culture and occupation has invaded medicine and supplied endless predictions of utopia for at least the past thirty years, in a domain it generally understands at the level of a layperson.

On "additional features" creating risk: [HIT incurs risk? How can the tool touted to revolutionize medicine incur risk? - ed.]

For example, some software programs require a diagnosis listed with each prescription. Consider the following: a patient is on Depakote for bipolar and seizure disorders, but the e-prescribing system only notes bipolar disorder because of its one-diagnosis limitation by design.

Subsequently, the patient becomes manic and the on-call psychiatrist starts the patient on lithium for the bipolar disorder. Checking the e-prescribing system, he notes Depakote was prescribed for bipolar disorder so he titrates the Depakote to discontinuation.

The patient has a seizure during the titration which leads to death.

The on-call psychiatrist assumed the patient was on Depakote solely for bipolar disorder and not seizures. If the diagnosis feature had been more extensive or had not been used with the software, the on-call psychiatrist might have explored further before discontinuing the Depakote.

Again, input from physicians prior to implementation may help prevent potential risks.

(According to Socky the Meditech Sockpuppet, such events are impossible.)

On Interoperability:

Another issue is whether your e-prescribing system fully integrates with pharmacy systems. Using the previous example, what if the diagnosis was changed in the psychiatrists’ system, but the pharmacy system did not automatically update this information? Be sure to investigate the compatibility of your system with others in your area. Not all pharmacies have e-prescribing capabilities. Many rural areas do not have the broadband internet access required.

It is unfortunate that the HIT vendor community is based on a business-computing model. That culture is extremely territorial. Seamless interoperability will be a long time in coming in HIT.

On Medication Reconciliation:

Physicians and pharmacies may find it difficult to trust the completeness and currency of the medication history and reconciliation, since medication histories often derive from multiple sources. Continue to verify medication histories with patients, and update records accordingly.

What? Actually not rely on the computer? What kind of extremist anti-health IT Luddite advice is this insurer proffering?

On Indemnity or "Hold Harmless" agreements:

Finally, be cautious about entering into hold harmless agreements with software vendors. Your ProAssurance policy excludes from coverage liability assumed under any contract or agreement, unless the liability would be imposed by law in the absence of the contract or agreement. It covers only the insured’s professional liability and not the liability of another party that the insured may assume through an indemnity agreement. If you are asked to sign such an agreement, you should have your attorney carefully review the agreement and your insurance policy.

I did not think of this issue when I wrote my July 2009 JAMA letter to the editor and a fuller posting on this issue at my Drexel HIT difficulties website here.

In addition to violating their fiduciary responsibilities and Joint Commission Safety Standard obligations, hospital executives signing nondisclosure and hold harmless agreements may be putting their organizations under undue financial risk if a HIT-related catastrophe occurs.

-----------------------

The second publication of note is an article from the IEEE (Institute of Electrical and Electronics Engineers). A Jan. 6, 2010 IEEE Spectrum article entitled "More Hurdles Appear in U.S. Electronic Health Record Adoption" has been published. I would actually have entitled it "More Hurdles Exposed in U.S. EHR Adoption", but that's not important now.

What is important, once again, is the Management Information Systems (business computing) approach to healthcare IT. The typical convoluted licensing arrangements for this software (really a virtual clinical tool that happens to reside on a computer) has created this fine mess:

The first was a story from a few months back that [the IEEE author] ran across recently from the Washington State Spokesman-Review about Inland Northwest Health Services suing the owner of Deaconess Medical Center, which the paper said alleged breach of "contracts and bad faith dealings that imperil the region's acclaimed electronic medical records network.

It is a bit complicated, but in essence, in 1994, Spokane's Deaconess Medical Center, Providence Holy Family Hospital, Providence Sacred Heart Medical Center & Children's Hospital and Valley Hospital & Medical Center established the non-profit Inland Northwest Health Services (INHS) as a way to merge competing lines of business and to oversee them. One of the things INHS did was to invest in electronic medical records using MEDITECH's technology. [You mean this Meditech? - ed.]

Apparently, Community Health Systems, a Tennessee company that bought Spokane's Deaconess Medical Center and Valley Hospital & Medical Center in 2007 decided that it was going to start charging INHS $150,000 a month to use the MEDITECH license, claiming that Deaconess Medical Center was owner of the license. INHS says that Deaconess transferred ownership to it years ago.

The Spokesman says some 38 hospitals along with many private practices and clinics are affected by the dispute.

The upshot of all this is that license ownership of the underlying EHR technology will likely be a big issue in the future as more regional health information networks are started, as will be technology lock-in (INHS has been using MEDITECH technology for 13-years, and it moving to another EHR is unlikely to be an easy or inexpensive proposition). Neither issue has appeared much in the EHR literature.

Yes, indeed, except once again I would have written:

The upshot of all this is that license ownership of the underlying EHR technology will likely be a big disaster in the future...

... as the HIT vendors will likely only allow their profitable licensing practices to be pried from their cold, dead fingers (metaphorically speaking, of course).

Then, this on EHR patient data trafficking:

... there was also a story in the American Medical News in late November about the Cleveland Clinic giving $1 million to a start-up company called Explorys to "commercializing the patient database search system Cleveland Clinic developed." The Cleveland Clinic has a very extensive EHR system and data base of patient information that it now wishes to exploit.

As I mentioned last month, there was a report by PricewaterhouseCoopers LLP that found 76% of healthcare executives surveyed felt that all the data being collected in their EHR systems was going to be their organization's greatest asset over the next five years. It also found that the executives only felt they could recoup their investments if they could exploit that information in some way.

The IEEE author largely addresses health IT failure as an impediment to such EHR patient data trafficking. In my Oct. 2009 post "Health IT Vendors Trafficking in Patient Data?" I came at the issue from an ethical and legal angle. I wrote:

This practice [trafficking in EHR patient data] raises numerous questions:

• Meaningful informed consent issues: as an example, of 1000 patients at one of the facilities using this vendor's HIT products, what percentage would be able to tell me they know their data is being trafficked to pharmaceutical companies and other organizations for profit?

• Healthcare data ownership and stewardship issues: who, exactly, extracts the data for aggregation and sale? Hospital employees properly trained and bonded (i.e., Healthcare Information Management professionals) regarding privacy of patient data? IT personnel lacking such credentials and experience? HIT vendor employees?

• De-identification issues: what processes are being used to de-identify data? Who is performing it? At some point before the data is de-identified, it is protected information in identifiable form. Is access to the data during de-identification audited in any way, and if so, by whom? If not, why not? (Also see article on re-identification below.)
  

• Legal issues: who is, by contract, liable for data breaches that occur in the transfer process?

• Fiduciary issues: as I expressed in my July 22, 2009 JAMA letter to the editor regarding "vendor hold harmless" and IT defects gag clauses, are hospital executives further violating their fiduciary responsibilities by signing HIT contracts that surrender ownership of patient data to third parties? (see my posts "JAMA letter: Health Care Information Technology, Hospital Responsibilities, and Joint Commission Standards" and "Inquiry to Joint Commission on points I raised in my JAMA letter on HIT" for more on those issues.

• Pharma integrity issues: with the many stories on this blog and others about ethically questionable pharma practices such as ghostwriting, manipulation of clinical research, suppression of research, pushing drugs on physicians and patients for unapproved off-label uses, etc., what are these organizations going to do with the data? Who will have access to it, and will their access be audited? Are they going to resell it? Might they try to re-identify data to locate individuals of interest? And so forth.
  

Serious consideration of these issues in vendor-led healthcare data trafficking becomes more imperative in the face of just how easy it is to "re-identify" data:

Ohm, Paul: "Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization" (August 13, 2009). University of Colorado Law Legal Studies Research Paper No. 09-12. Available at SSRN: http://ssrn.com/abstract=1450006

In Dec. 2007 I'd also presented to the IEEE Medical Technology Policy Committee on some of these issues in "To the Moon in a Hot Air Balloon: Why is Clinical IT Difficult?". In response, they introduced me to the term "resilience engineering" in the sense that healthcare IT was lacking in that particular characteristic:

The term Resilience Engineering represents a new way of thinking about safety. Whereas conventional risk management approaches are based on hindsight and emphasise error tabulation and calculation of failure probabilities, Resilience Engineering looks for ways to enhance the ability of organisations to create processes that are robust yet flexible, to monitor and revise risk models, and to use resources proactively in the face of disruptions or ongoing production and economic pressures.

Health IT as a cybernetic miracle? As I've stated before, healthcare is a harsh environment for cybernetics, talent to accomplish the needed IT and medical culture changes essential to successful computerization in medicine is grossly mismanaged by the HIT and hospital industries, and reality is a harsh mistress.

-- SS

Two New Challenges to a Healthcare Cybernetic Utopia: Yet More Hurdles Exposed

At "2009: a Pivotal Year in Healthcare IT" I concluded that 2009 had proven to be a critical year in HIT, due to authoritative publications on HIT difficulties and related issues that appeared that year.

It was good to see the critical thought processes and the scientific methods inherent in modern medicine applied to the irrational exuberance and marketing-dominated field of healthcare IT.

It seems in 2010 the trend may continue.

Two new very interesting publications have recently come to my attention regarding the complications that can, and are, introduced by HIT.

These complications are worsened by the "boatload of cash," as one author expressed it, that is helping fuel what I term an irrational exuberance, or purchased exuberance, in this technology and its use in social re-engineering in medicine.

-----------------------

The first publication of note is a newsletter "Medical Risk Management Advisor" from ProAssurance Indemnity Company, Inc. and affiliates, a provider of medical insurance for clinicians. It can be downloaded here (PDF). It advises:

On choosing an EHR system:

Be sure to obtain physician input and review of the software prior to purchase to ensure it meets the needs of your practice. Consider talking to other medical practices already using the software, not only to assist in your decision, but to anticipate flaws or errors existing users may have encountered. Lastly, establish a process to address problems discovered after implementation.

"Anticipating flaws or errors existing users may have encountered" seems to be at odds with nondisclosure clauses in heathcare IT contracts, but this insurer seems to have gotten the message that HIT is not a perfected technology by a long shot.

On Alert fatigue:

Physicians may ignore e-prescribing alerts for a variety of reasons (e.g., excessive alerts or alerts that are not clinically useful). Again, input from physicians prior to implementation can help prioritize and choose alerts appropriate to the practice.

That the advice has to be given by an insurance company to healthcare organizations that "input from physicians prior to implementation" is crucial reflects a pathology, whose root is within the paternalistic and patronizing IT culture.

This culture and occupation has invaded medicine and supplied endless predictions of utopia for at least the past thirty years, in a domain it generally understands at the level of a layperson.

On "additional features" creating risk: [HIT incurs risk? How can the tool touted to revolutionize medicine incur risk? - ed.]

For example, some software programs require a diagnosis listed with each prescription. Consider the following: a patient is on Depakote for bipolar and seizure disorders, but the e-prescribing system only notes bipolar disorder because of its one-diagnosis limitation by design.

Subsequently, the patient becomes manic and the on-call psychiatrist starts the patient on lithium for the bipolar disorder. Checking the e-prescribing system, he notes Depakote was prescribed for bipolar disorder so he titrates the Depakote to discontinuation.

The patient has a seizure during the titration which leads to death.

The on-call psychiatrist assumed the patient was on Depakote solely for bipolar disorder and not seizures. If the diagnosis feature had been more extensive or had not been used with the software, the on-call psychiatrist might have explored further before discontinuing the Depakote.

Again, input from physicians prior to implementation may help prevent potential risks.

(According to Socky the Meditech Sockpuppet, such events are impossible.)

On Interoperability:

Another issue is whether your e-prescribing system fully integrates with pharmacy systems. Using the previous example, what if the diagnosis was changed in the psychiatrists’ system, but the pharmacy system did not automatically update this information? Be sure to investigate the compatibility of your system with others in your area. Not all pharmacies have e-prescribing capabilities. Many rural areas do not have the broadband internet access required.

It is unfortunate that the HIT vendor community is based on a business-computing model. That culture is extremely territorial. Seamless interoperability will be a long time in coming in HIT.

On Medication Reconciliation:

Physicians and pharmacies may find it difficult to trust the completeness and currency of the medication history and reconciliation, since medication histories often derive from multiple sources. Continue to verify medication histories with patients, and update records accordingly.

What? Actually not rely on the computer? What kind of extremist anti-health IT Luddite advice is this insurer proffering?

On Indemnity or "Hold Harmless" agreements:

Finally, be cautious about entering into hold harmless agreements with software vendors. Your ProAssurance policy excludes from coverage liability assumed under any contract or agreement, unless the liability would be imposed by law in the absence of the contract or agreement. It covers only the insured’s professional liability and not the liability of another party that the insured may assume through an indemnity agreement. If you are asked to sign such an agreement, you should have your attorney carefully review the agreement and your insurance policy.

I did not think of this issue when I wrote my July 2009 JAMA letter to the editor and a fuller posting on this issue at my Drexel HIT difficulties website here.

In addition to violating their fiduciary responsibilities and Joint Commission Safety Standard obligations, hospital executives signing nondisclosure and hold harmless agreements may be putting their organizations under undue financial risk if a HIT-related catastrophe occurs.

-----------------------

The second publication of note is an article from the IEEE (Institute of Electrical and Electronics Engineers). A Jan. 6, 2010 IEEE Spectrum article entitled "More Hurdles Appear in U.S. Electronic Health Record Adoption" has been published. I would actually have entitled it "More Hurdles Exposed in U.S. EHR Adoption", but that's not important now.

What is important, once again, is the Management Information Systems (business computing) approach to healthcare IT. The typical convoluted licensing arrangements for this software (really a virtual clinical tool that happens to reside on a computer) has created this fine mess:

The first was a story from a few months back that [the IEEE author] ran across recently from the Washington State Spokesman-Review about Inland Northwest Health Services suing the owner of Deaconess Medical Center, which the paper said alleged breach of "contracts and bad faith dealings that imperil the region's acclaimed electronic medical records network.

It is a bit complicated, but in essence, in 1994, Spokane's Deaconess Medical Center, Providence Holy Family Hospital, Providence Sacred Heart Medical Center & Children's Hospital and Valley Hospital & Medical Center established the non-profit Inland Northwest Health Services (INHS) as a way to merge competing lines of business and to oversee them. One of the things INHS did was to invest in electronic medical records using MEDITECH's technology. [You mean this Meditech? - ed.]

Apparently, Community Health Systems, a Tennessee company that bought Spokane's Deaconess Medical Center and Valley Hospital & Medical Center in 2007 decided that it was going to start charging INHS $150,000 a month to use the MEDITECH license, claiming that Deaconess Medical Center was owner of the license. INHS says that Deaconess transferred ownership to it years ago.

The Spokesman says some 38 hospitals along with many private practices and clinics are affected by the dispute.

The upshot of all this is that license ownership of the underlying EHR technology will likely be a big issue in the future as more regional health information networks are started, as will be technology lock-in (INHS has been using MEDITECH technology for 13-years, and it moving to another EHR is unlikely to be an easy or inexpensive proposition). Neither issue has appeared much in the EHR literature.

Yes, indeed, except once again I would have written:

The upshot of all this is that license ownership of the underlying EHR technology will likely be a big disaster in the future...

... as the HIT vendors will likely only allow their profitable licensing practices to be pried from their cold, dead fingers (metaphorically speaking, of course).

Then, this on EHR patient data trafficking:

... there was also a story in the American Medical News in late November about the Cleveland Clinic giving $1 million to a start-up company called Explorys to "commercializing the patient database search system Cleveland Clinic developed." The Cleveland Clinic has a very extensive EHR system and data base of patient information that it now wishes to exploit.

As I mentioned last month, there was a report by PricewaterhouseCoopers LLP that found 76% of healthcare executives surveyed felt that all the data being collected in their EHR systems was going to be their organization's greatest asset over the next five years. It also found that the executives only felt they could recoup their investments if they could exploit that information in some way.

The IEEE author largely addresses health IT failure as an impediment to such EHR patient data trafficking. In my Oct. 2009 post "Health IT Vendors Trafficking in Patient Data?" I came at the issue from an ethical and legal angle. I wrote:

This practice [trafficking in EHR patient data] raises numerous questions:

• Meaningful informed consent issues: as an example, of 1000 patients at one of the facilities using this vendor's HIT products, what percentage would be able to tell me they know their data is being trafficked to pharmaceutical companies and other organizations for profit?

• Healthcare data ownership and stewardship issues: who, exactly, extracts the data for aggregation and sale? Hospital employees properly trained and bonded (i.e., Healthcare Information Management professionals) regarding privacy of patient data? IT personnel lacking such credentials and experience? HIT vendor employees?

• De-identification issues: what processes are being used to de-identify data? Who is performing it? At some point before the data is de-identified, it is protected information in identifiable form. Is access to the data during de-identification audited in any way, and if so, by whom? If not, why not? (Also see article on re-identification below.)
  

• Legal issues: who is, by contract, liable for data breaches that occur in the transfer process?

• Fiduciary issues: as I expressed in my July 22, 2009 JAMA letter to the editor regarding "vendor hold harmless" and IT defects gag clauses, are hospital executives further violating their fiduciary responsibilities by signing HIT contracts that surrender ownership of patient data to third parties? (see my posts "JAMA letter: Health Care Information Technology, Hospital Responsibilities, and Joint Commission Standards" and "Inquiry to Joint Commission on points I raised in my JAMA letter on HIT" for more on those issues.

• Pharma integrity issues: with the many stories on this blog and others about ethically questionable pharma practices such as ghostwriting, manipulation of clinical research, suppression of research, pushing drugs on physicians and patients for unapproved off-label uses, etc., what are these organizations going to do with the data? Who will have access to it, and will their access be audited? Are they going to resell it? Might they try to re-identify data to locate individuals of interest? And so forth.
  

Serious consideration of these issues in vendor-led healthcare data trafficking becomes more imperative in the face of just how easy it is to "re-identify" data:

Ohm, Paul: "Broken Promises of Privacy: Responding to the Surprising Failure of Anonymization" (August 13, 2009). University of Colorado Law Legal Studies Research Paper No. 09-12. Available at SSRN: http://ssrn.com/abstract=1450006

In Dec. 2007 I'd also presented to the IEEE Medical Technology Policy Committee on some of these issues in "To the Moon in a Hot Air Balloon: Why is Clinical IT Difficult?". In response, they introduced me to the term "resilience engineering" in the sense that healthcare IT was lacking in that particular characteristic:

The term Resilience Engineering represents a new way of thinking about safety. Whereas conventional risk management approaches are based on hindsight and emphasise error tabulation and calculation of failure probabilities, Resilience Engineering looks for ways to enhance the ability of organisations to create processes that are robust yet flexible, to monitor and revise risk models, and to use resources proactively in the face of disruptions or ongoing production and economic pressures.

Health IT as a cybernetic miracle? As I've stated before, healthcare is a harsh environment for cybernetics, talent to accomplish the needed IT and medical culture changes essential to successful computerization in medicine is grossly mismanaged by the HIT and hospital industries, and reality is a harsh mistress.

-- SS

Clinic's medical files vanish

At "Data Malpractice on T-Mobile Sidekick: But Don't Worry, Your Medical Data is Safe", on Oct. 16 I wrote:

One of the promises made about healthcare IT is that your medical data is "safer" in electronic form than in paper form. The Hurricane Katrina example of paper records being destroyed is often used as a poster example of the dangers of paper records.

However, the risk of electronic storage of information, especially the talk of national EMR's stored on the "cloud" (an amorphous term meaning distributed storage "out there" whose physical sites and boundaries are supposedly irrelevant from the user's perspective) has also been under-reported.

Personal customer data had been "lost" from many of T-Mobile USA's Sidekick devices due to a computer malfunction, although the data was apparently recovered eventually, apparently through luck rather than good engineering.

I expressed concern that such mishaps could affect clinical IT. I did not have to wait long for such a case to appear. Less than one week.

Below is a story of a Canadian clinic that lost two years of electronic health records:

Clinic's medical files vanish

By Ryan Cormier, Edmonton Journal

October 21, 2009

During a recent investigation into whether a patient's confidentiality had been breached at the Fairview Medical Clinic, an investigator asked for a log of who had accessed the complainant's file. When the clinic responded that it had automated his records in 2004 but only had files from 2006 on, alarm bells rang.

"That raised a lot of questions," said Leahann McElveen, an investigator with the office of the information and privacy commissioner.

The clinic had permanently lost two years worth of health files that include patient information on visits, prescriptions, lab reports, doctor's notes and other information. The loss happened when the clinic switched from one electronic medical records system to another.

"They were two similar systems intended to do the same thing," McElveen said. "However, they weren't coded the same way behind the scenes. It's not that the records fall into the wrong hands, they just don't exist anymore."

*POOF*.

Deinstallation of one system in favor of another is not uncommon. EHR data may become unavailable due to lack of data portability and the expense of data migration, or in this case apparently due to preventable technical problems.

It is essential for clinical IT users to have robust disaster recovery and business continuity solutions, and take great care when performing actions that can lose large amounts of data very fast. This adds to clinical IT cost, and a concern is that some users might skimp on these capabilities.

This must be discouraged.

(To the reader: do you back up your own PC or Mac reliably?)

-- SS

Private medical records offered for sale

Private medical records have been offered for sale in the U.K.

And quite cheaply, too...

e-Health Insider (Europe)
Private Medical Records Offered for Sale
Oct. 20, 2009

Medical records of patients treated at a private British hospital, The London Clinic, have been illegally sold to undercover investigators.

The revelations were made in ITV’s Tonight Programme report, Health Records For Sale, broadcast last night.

The programme reported that hundreds of files containing details of patients’ conditions, home addresses and dates of birth were offered to undercover reporters for just £4 each by sales executives from India, contacted online.

That's about $6.56 U.S. each. A genuine bargain for those intrepid medical identity thieves, and pesky government death panels ...

The records offered for sale appear to have been medical records that consultants working at the London Clinic, the hospital processes its own records internally, who contracted with a firm called DGL (DGL) Information Technologies UK to digitise their records.

DGL is then claimed to have sub-contracted to another firm, Scanning and Data Solutions (SDS), which scanned them into computers in the UK. SDS in turn is said to have sub-contracted further work on the files to a company in Pune, India, which had signed tight confidentiality agreements.

With all this contracting and subcontracting - four layers? - adding potential security breach possibilities, and if this is not an uncommon practice, perhaps paper is safer than electronic health records?

... The reporters bought more than 100 records belonging to UK patients but were told they could obtain up to 30,000 more on demand. Confidential records were offered by condition such as particular cancers.

Of 116 files bought by ITV, 100 of which were confirmed as genuine, were for patients who had been treated in private hospitals. Although not NHS records they did contain some NHS data, including referral letters from GPs.

The potential abuses resulting from such sales are of great concern. If it happened in the UK, it can happen in the U.S.

One patient whose record was affected by the security breach said in the documentary that the data breach was ‘one step up from grave-robbing’.

I agree with that assessment.

These practices call for the most severe penalties, and if the authorities lack the will, confidence in EMR privacy, confidentiality and security will suffer, along with the physician-patient relationship.

The old ST:TOS line "Sometimes a man will tell his bartender things he'll never tell his doctor" could become too applicable for comfort.

Sometimes a man will tell his bartender things he'll never tell his doctor ... especially if they suspect their data is for sale to the Talosians, Captain ...

-- SS

Data Malpractice on T-Mobile Sidekick: But Don't Worry, Your Medical Data is Safe

One of the promises made about healthcare IT is that your medical data is "safer" in electronic form than in paper form. The Hurricane Katrina example of paper records being destroyed is often used as a poster example of the dangers of paper records.

However, the risk of electronic storage of information, especially the talk of national EMR's stored on the "cloud" (an amorphous term meaning distributed storage "out there" whose physical sites and boundaries are supposedly irrelevant from the user's perspective) has also been under-reported. Excluding frequent reports of data confidentiality breaches, we also have this:

Wall Street Journal, Oct. 15, 2009
Microsoft Recovers Lost Sidekick Data
By ROGER CHENG

Microsoft Corp. said Thursday that it has been able to recover the personal customer data lost from many of T-Mobile USA's Sidekick devices.

The Redmond, Wash., software giant said that most, if not all, customer data was recovered, and that the company would begin restoring data as soon as it has validated it. The company said it will start with personal contacts, and move on to the lost calendar, notes, tasks and pictures as quickly as possible.

The fix comes as Microsoft suffers through a public backlash after mishandling the information found on the Sidekick line of messaging phones, which are popular with teenagers ... Over the weekend, T-Mobile and Microsoft initially warned that the recovery of data would be unlikely, but upgraded their prospects on Tuesday.

They got lucky.

Microsoft blamed a system failure [i.e., an IT system - ed.] for the data loss in the core database and backup system. Microsoft said it had taken steps to strengthen the stability of the Sidekick service and started a more resilient backup process. [More resilient compared to ... what? - ed.]

In IT it's always an apersonal "system failure", not "data malpractice." When medical malpractice occurs, it's the doctor's fault, even if that malpractice occurred secondary to the failure or misdesign of an EMR or other clinical IT by dyscompetent software engineers. When data malpractice occurs, the motto is "We always blame the computer." How about some names of those responsible for this debacle?

... The Sidekick service, run by Microsoft unit Danger [talk about ironic names - ed.], is supposed to be more secure in storing data because it is kept in the "cloud," which involves storing information on the Internet and not one physically vulnerable location, making the temporary loss of data striking.

"Cloud" is a new buzzword du jour to make more appealing a basically bad idea for many fields. Distributing data also distributes risk that some incompetent or careless person or person(s) will cause data corruption or loss (yes, computers are run by people, and either they're in control of their systems, or their systems are in control of them). It also puts organizations storing data on the "internet cloud" at risk of being victims of a network "rainy day" when internet connections might prove unreliable (accidents, sabotage, natural disasters all come to mind).

In healthcare, using the "cloud" for data storage seems to be a bad idea, especially in an era of $99 (retail) terabyte hard drive storage, and corresponding economies in mission critical-grade local mass storage, backup, business continuity and disaster recovery capabilities.

In summary, is electronic medical data more secure when stored electronically than on paper? Only if the underlying CIO's, information stewards, technicians and system administrators are at least as competent and careful as the trained health information management (HIM) personnel in hospital medical records departments and doctors' offices.

Time will tell if that is the case. One mistake, and thousands or millions of records can go *POOF*.

Microsoft and T-Mobile were lucky ... this time.

-- SS

10/26 addendum:

Sometimes, EHR data simply disappears too. At this link is a story of a Canadian clinic that lost two years of electronic health records:

Clinic's medical files vanish

By Ryan Cormier, Edmonton Journal

October 21, 2009

During a recent investigation into whether a patient's confidentiality had been breached at the Fairview Medical Clinic, an investigator asked for a log of who had accessed the complainant's file. When the clinic responded that it had automated his records in 2004 but only had files from 2006 on, alarm bells rang.

"That raised a lot of questions," said Leahann McElveen, an investigator with the office of the information and privacy commissioner.

The clinic had permanently lost two years worth of health files that include patient information on visits, prescriptions, lab reports, doctor's notes and other information. The loss happened when the clinic switched from one electronic medical records system to another.

"They were two similar systems intended to do the same thing," McElveen said. "However, they weren't coded the same way behind the scenes. It's not that the records fall into the wrong hands, they just don't exist anymore."

*POOF* again.

-- SS

EHR's and Scarcity of Public Reviews of the User Experience

I recently downloaded the public beta (incomplete trial version) of Apple's new web browser Safari 4.

I like its user experience and features, presenting a main page "posterboard" of most visited or user-selected sites, a searchable, flip-panel history of visited pages (using the Macintosh OS X Spotlight and Cover Flow paradigms), top located tabs, and other useful features. (Note: I use both Macs and PC's, and hold no financial stakes in Apple whatsoever.)

What struck me was the vociferous online discussions and debates about every facet of the new browser version, down to the level of minutiae. The following review particularly struck me for its level of detail - Observations, Complaints, Quibbles, and Suggestions Regarding the Safari 4 Public Beta Released One Week Ago, Roughly in Order of Importance by John Gruber. It includes minutiae such as this:

... THE TABS

Safari’s new tab layout, placing the tabs directly in the window title bar, is a radical change. There’s no use addressing the specific details — good and bad — of this new arrangement, without first trying to figure out why Apple did this. Again, the designers are behind Apple’s wall of silence, so we’re left to speculate.

Rule out the notion that Safari’s designers undertook this change lightly. This is a major change to an important feature that many users feel strongly about. My guess is that this is an attempt to bring tabbed browsing to the masses. The biggest and most important change is that the interface for the tabs is now far more prominent. In fact, previously, the entire interface for tabbed browsing was not visible in Safari by default — in a window with just one tab, Safari’s default settings were such that the tab bar was not shown.

In Safari 4, there’s a prominent and unique “+” button that is always visible in the top right corner of every window, where the standard tic-tac button for toggling the display of the toolbar usually resides.1 Because the interface to create new tabs is now obvious, I can only assume that the point of this redesign is to encourage more people to use, or at least try, tabbed browsing.

But the problems with this new tab layout are significant.

Conceptually, the basic idea is sound. Browser tabs are, effectively, a collection of separate browser windows grouped together in a single parent window. Safari’s new tab layout makes this a tab is like a sub-window metaphor more explicit. The anchor, the conceptual root, of a standard Mac OS window is the title bar, and in Safari 4, the tabs aren’t just in the title bar, they are the title bar ...

Etcetera and so forth, on and on, as in other reviews easily found online.

In Electronic Health Records and other clinical IT, by way of contrast, reviews at this level of detail are ... nearly nonexistent (I use the term "nearly" because I authored such a review, in general terms, starting here). One reason EHR and other clinical IT user experience and performance debates are so rare is because customers are contractually forbidden to engage in them publicly. Koppel's and Kreda's JAMA paper makes that clear:

Health Care Information Technology Vendors' "Hold Harmless" Clause - Implications for Patients and Clinicians, Ross Koppel and David Kreda, Journal of the American Medical Association, 2009; 301(12):1276-1278

Vendors claim they are protecting their "intellectual property." I'm not exactly sure what IP they are holding as closely as the crown jewels.

Is it their:

• Earth shaking, 22nd century user interfaces?
• Secretive and ingenious widgets that revolutionize user selection from choice lists?
• Hyper-efficient, never before seen data structures and algorithms?
• Artificial intelligence routines that would make Captain Picard and his android sidekick Mr. Data envious?

In other words, what, exactly, is being protected by shielding commercial EHR's from external scrutiny and debate?

Is this the Secret Sauce the commercial EHR vendors seek to conceal?

The loss engendered by such policies is the reduced feedback from, and reduced interaction among endusers. This interaction occurs commonly on the Internet in 2009 on a great number of topics, but EHR user experiences are not one of them.

Companies like Apple and Microsoft, strongly user centric, encourage such debates through release of their beta's, both of enduser tools and of operating systems e.g., Windows 7 Beta. I should note that with these pieces of software, lives are not at stake, unlike with electronic health records systems.

The Veterans Health Administration makes a full working copy of VistA Computerized Patient Record System (CPRS) available as a free public download to anyone in the world here. I use it in my teaching (and am forced to do so, as commercial EHR demos are as available as, say, demos of the National Security Agency's spy and decryption software).

What, exactly, is the commercial EHR vendors' real excuse for the levels of product secrecy they maintain?

Could it be embarrassment and fear of exposure of defects, ill conceived design features and a mission hostile user experience?

-- SS

Let's Deregulate Pharmaceutical Information Technology

... after all, a full Electronic Medical Record/Order Entry/Decision Support system is far more complex, with potential for far more immediate patient impact, then pharma's research IT systems. Yet the former is unregulated.

PhRMA, you should start lobbying to create your own private Certification Commission For Pharmaceutical IT (CCPIT) now. You can start certifying all your IT by going through a checklist of features, and avoid those pesky FDA inspections just as hospital do!

Seriously, my views are identical to that of Hoffman and Podgurski.

They expressed their views in the article "Finding a Cure: The Case for Regulation And Oversight of Electronic Health Records Systems", Hoffman and Podgurski, Harvard Journal of Law & Technology 2008 vol. 22, No. 1, and now have summarized and amplified them in the short piece "Why Electronic Health Record Systems Require Safety Regulation", Bioethics Forum, Sharona Hoffman and Andy Podgurski, March 20, 2009.

Emphases mine:

...In light of these risks to patient care, federal regulations must establish rigorous quality control mechanisms. Currently, initial approval of EHR systems is conducted by a certification program operated by the Certification Commission for Health Information Technology, a private, industry-based organization. Our review of the certification criteria revealed that they are inadequate to ensure the safety and efficacy of EHR systems . For example, testing is conducted in just one eight-hour period , and the criteria do not explicitly address important issues such as safety and usability.

We believe that EHR systems should be scrutinized through a careful premarket approval process, including field testing at several facilities for at least six months. We also recommend local system oversight committees, based on the IRB model , that would oversee field testing and conduct postmarketing monitoring throughout the life of the product. Adverse event reporting would be mandated under this system to ensure that problems are detected and addressed swiftly and that the government intervenes when necessary to safeguard patient welfare.

Federal regulations should also require that all EHR systems meet specific quality standards. Audit trails and capture-replay capabilities should be required to facilitate discovery of both system and user errors, much as black boxes allow the reconstruction of conditions that led to aviation incidents .

... Because EHR systems will manage patient care to a significant degree, they must be subject to government oversight akin to the highest level of scrutiny required, in principle, by the Food and Drug Administration for complex medical devices ... Federal regulations should establish appropriate oversight and quality control through EHR system standards, approval processes, and ongoing monitoring requirements. It is only with careful oversight that providers can be assured of investing in high quality EHR products. And it is only with appropriate safeguards that the benefits of this very promising technology will be maximized–that health outcomes will improve and risks as well as costs will decline.

I do not think these suggestions are unrealistic.

After spending considerable time in pharma, to be consistent I say either we discontinue FDA regulation of pharma clinical IT, or we continue to regulate pharma's IT and add the even more complex provider healthcare IT to the pool of regulated medical devices.

-- SS

A few not so random thoughts on Healthcare IT

A few thoughts for a Wednesday morning:

• I had recently written on some (probably) minor issues about CCHIT, the Certification Commission for Healthcare Information Technology. However, I have more substantive concerns. I would like to know how CCHIT functions differently from a fictional "Drug Certification Commission." Imagine such a Commission founded by PhRMA and other pharmaceutical industry advocates, partly staffed at high levels by pharmaceutical executives, and "certifying" drugs for consumer purchase simply on the basis of their being manufactured under cGMP guidelines (current good manufacturing processes). Imagine this Commission declaring drugs "certified" without clinical trials, impartial regulatory oversight, postmarketing surveillance and in the face of equivocal studies and outright unfavorable studies showing increased risk of adverse events. How is CCHIT conceptually and substantively different from this fictional drug certification commission?
  

• I would also like to know how the irrational exuberance over Health IT, vastly accelerated for reasons unclear to me by the "Economic Stimulus Bill", differs from the Madoff scandal. The "Bernard Madoff" version of HIT reality promotes the point of view that even in the face of flimsy and/or contradictory evidence, billions of dollars in investment in today's HIT is guaranteed to reap massive rewards, no matter what. Worse than Madoff's scam, those clinicians who don't invest will be penalized. In effect, the government has now taken over Madoff's Acme Anvil EMR Securities, Inc. and is forcing everyone to invest - or else.
  

-- SS

Outrageous extremely overpriced ridiculously simple EMR interfaces

This in from a 2005 college graduate working in healthcare IT for almost 3 years, with a technical background only, who has found my site on HIT difficulties. This person's been working with several hospitals and hospital groups to create interfaces to practices and labs as well as master patient index services.

This HIT worker writes:

"...one other thing that I think should be covered is the outrageous extremely overpriced ridiculously simple (I opted to use as many adjectives that came to mind) task of creating an interface in an EMR. After doing a few interfaces myself and working with about a dozen or so EMR vendors the cost is ridiculous for the amount of work they actually do.

The average cost that I've seen is about $4,000 to $6,000 USD, I've seen some that are 'free' I'll explain this one later, some upwards of $40,000+ and some in the realm of a few hundred.

Under this secret shroud of "everything is complicated and takes tons of people and costs an arm and a leg" is really a two person job that takes about three to four hours, or even less if you know what you're doing. To create an interface between two systems one person configures their application to listen on a socket, and the other to configure the application to connect to an IP and a specific socket.

This of course assumes the two systems are maintained by two different people. There is more that goes into creating an interface sure, but from an EMR point of view its two people. I've configured a [Big Vendor] interface with the vendor in 30 minutes. [Big Vendor] charges I think the number was $3,500 to $4,000 for the "Labor charge", [Big Vendor] is the 'free' one once you purchase the application you can create as many interfaces as you want.

I've yet to meet a physician, nurse or office assistant that have the know-how to create an interface. Other EMR's charge per interface as if paying $15,000 for the application wasn't enough a physician must spend another $4,000 to $6,000 for a stinking interface! Yes its important that they have it but WOW! - $4,000 to $6,000 for 30 minutes of work? Some are longer, some interfaces require more configuration's which isn't much, most any worthwhile application already has default configurations and interfaces so one could load those and not go too far over 30 minutes of work, certainly not longer than a few hours though.

Thinking of a typical practice that I've encountered, there are three general feeds:

1. General Labs - This interface would send over your microbiologies,blood tests etc.
2. Transcriptions - This interface would send over, well, transcriptions anything dictated.
3. Radiology - This interface would send over all your radiology transcriptions with the added feature of being able to handle images.

Not that I've actually seen one in action, these are all just claims right now. The sheer size of radiology images dissuades labs from sending them over the system because of bandwidth issues, also because not many interfaces currently support DICOM, or one system in the flow doesn't support DICOM.

So, if we take one of the larger EMR's, your eCW's, GE's, Misys's, Allscripts et cetera, the cost for one of these systems range from $12,000 to $15,000 that I've seen for a small practice. Then if you take the $4000 (lets be nice and give EMR's the lower number) at three interfaces for a total of $12,000 we have a system that costs $24,000 to $27,000. That's ridiculously insane for a broken system that somewhat works.

Another thing that has always got me wound up with looking at these costs are that the EMR's know their application best, they know how the HL7 data should look, but they have no way of mapping the HL7 to be compliant with their systems. So I'm forced to map it for them, I'm lucky if they have specs, and if they do they're likely out dated (I have yet to receive a spec that was not out of date by the way). Reverse engineering an application's interpretation of HL7 is insane. To be fair, some vendors do offer though to do the mapping, then again they also charged $40,000+.

I've tinkered with EMR systems when I can, some were nice, some were trash, most were trash. These applications work and look great for me, but lets face it, I'm no clinician I don't understand most of what is on the screen, I can fumble around though and figure things out. These applications are designed and developed by engineers, these applicationsonly make sense to engineers. These systems are pure trash.

Here's to taking down the shroud and smoke screen HIT has put up the past couple decades.

Feel free to post this in its entirety if it will help take down the smoke screen.

Having been a CMIO, I can vouch for these expense levels charged for interfaces that I knew, also being a computer professional, were quite simple to code.

-- SS

The Malpractices of the Multitudes: the HIT Mission Hostile User Experience, Part 8

More on the origin of this post's title, penned in 1836, below.

(Note: Part 1 is here, part 2 is here, part 3 is here, part 4 is here, part 5 is here, part 6 is here, and part 7 is here.)

This post is part 8, and the finale, of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills.

April 2011 addendum: see what might be considered part 9 at this link.

My college is a member of the iSchool consortium, consisting of schools of information science and technology (notably, not "information technology and science").

The iSchools are interested in the relationship between information, people and technology. This is characterized by a commitment to learning and understanding the role of information in human endeavors. The iSchools take it as given that expertise in all forms of information is required for progress in science, business, education, and culture. This expertise must include understanding of the uses and users of information, as well as information technologies and their applications.

Note the "as well as." Note the primary focus, and that which is secondary. This philosophy parallels that of Medical Informatics well.

This probably sounds like Martian to many in the healthcare and perhaps the broader business IT sector.

One of my colleagues on reviewing this HIT series had this to say:

It's really nice to hear that for once IT professionals have been able to successfully repeat the development lifecycle for healthcare information systems:

• Fail to understand the problem ->

• create a fragmentary and inaccurate requirements definition ->

• design an ambiguous, ignorant and risk-laden user interface ->

• pull all the misguided notions together with baling wire and call it a design->
  

• translate the "design" into an executable form, adding and subtracting design elements at random ->
  

• observe the first output from the system and declare it ready for the healthcare professionals. fini
  

Did I miss anything?

I believe he captured the essense of today's HIT vendor market well.

Here are examples of screen displays of vital patient information, displays that force clinicians to go on wild goose chases and seem designed by true neophytes to the field of information presentation and user interaction design. This is not to single out any one vendor. Many vendor products have deficiencies.

See this display of something as simple (one would think) as blood pressures:

(click to enlarge)

Note the following:

• Diastolic blood pressures in the left column;
• Systolic blood pressures in the roight column;
• An adventure to match them by date;
• No column headers at top.

Which value goes with which? How much energy does it use up to scroll around and connect the two?

This display is so poorly conceived, one wonders why it was included at all in a production system.

There's more. Let's troll for data, shall we?

See the blood oxygen saturation level, circled?

(click to enlarge)

What percentage oxygen was this patient receiving?

It's not there! Where is it?

Scroll down ...

(click to enlarge)

... and down ...

(click to enlarge)

Our answer, at last! Circled. Of course, the corresponding pulse oximetry is now off the screen.

How much attention would it have taken to present the two together?

How much coding would it have taken with today's computers, that execute billions of instructions per second, to dynamically condense the presentation of information, eliminating the absolutely empty cells between the two values?

Similar isses are noted for other biomedically coupled values, such as coumadin dose and blood thinning value (INR).

Screw matching those up, and as my mentor Victor P. Satinsky, MD might have said, your patient's dead.

Speaking about information sparsity, how's this display?

(click to enlarge)

There's one value in the entire screen. What a waste. How much difficulty would it have been to simply present the one row, automatically?

The EHR disperses and fragments vital patient information. How, exactly, is this is supposed to make clinicians more efficient and less error prone?

I am only presenting the easiest to present problems, easiest that is in a static medium such as a blog.

If presented dynamically, we find with some EHR's, for example, that it takes 50 or so mouse clicks across various screens and drop down lists and drop boxes to enter 5 common diagnoses.

It takes selecting from multiple hierarchical lists and buttons across four different screens, multiple times repetitively, to find out how well a patient is eating.

Here is simple advice from J Gen Intern Med 2009; 24(1):21-26.

It is imperative that usability principles are embedded in CPOE design to avoid

• overly complex screens
• poor grouping of like terms
• an inflexible human-computer interface
• mis-use of clinician time

Do the HIT vendors actually read such advice?

I wonder.

Medical Informatics reminds me of dentistry in its early days. B.T. Longbothom, author of the second dentistry book published in the U.S. ("A Treatise on Dentistry", 1802), gave an excellent description in his preface of problems at the time. His observations apply to Medical Informatics in our present age:

The word "dentist" has been so infamously abused by ignorant pretenders, and is in general so indifferently understood, that I cannot forbear giving what I conceive to be its original meaning: viz, the profession of one who undertakes and is capable not only of cleaning, extracting, replacing by transplantation and making artificial teeth, but can also from his knowledge of dentistry, preserve those that remain in good condition, prevent in a very great degree, those that are loose, or those that are in a decayed state, from being further injured, and can guard against the several diseases, to which the teeth, gums and mouth are liable, a knowledge none but those regularly instructed, and who have had a long, and extensive practice, can possibly attain, but which is absolutely necessary, to complete the character of a Surgeon Dentist.

Hardly anyone spoke out.

More than thirty years later, untrained practitioners were as prevalent as ever. One of the leading dentists of the time, Shearjashub Spooner, in his "Guide to Sound Teeth, or, A Popular Treatise on the Teeth" (1836) warned the public of a phenomenon I believe now applies to Medical Informatics and healthcare IT:

One thing is certain, this profession must either rise or sink. If means are not taken to suppress and discountenance the malpractices of the multitude of incompetent persons, who are pressing into it, merely for the sake of its emoluments, it must sink, - for the few competent and well educated men, who are now upholding it, will abandon a disreputable profession, in a country of enterprise like ours, and turn their attention to some other calling more congenial to the feelings of honorable and enlightened men.

I understand that point of view.

And with that, I end this series.

-- SS

Information Technology Makes Healthcare Easier? Is This Industry Trying to Harm Patients? Part 7 of a Series

This post is part 7 of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills.

(Note: Part 1 is here, part 2 is here, part 3 is here, part 4 is here, part 5 is here, part 6 is here, part 7 is here, and part 8 is here.)

Want to make a doctor or nurse miserable?

Want to up the odds for error?

Simply force them to review lab results on a screen as sloppily designed and cluttered as this one:

(click to enlarge)

What technical genius programmed this monstrosity? The clutter is enough to impair the best clinicians who have to use such screens day in and day out on their often substantial patient loads.

How is such a screen better than paper?

Does the clinician really need to see subcomponents of panels such as General Chemistry split up all over the place, into sections of columns? Perhaps monolithic columns and horizontal scrolling would be less cognitively taxing? More columns, of course, could be placed in the available screen width if space were not wasted by ... units and Abn's!

Does the clinician really need to see "Abn" as opposed to, say, "A" for abnormals? (At least the abnormals are actually marked in this application, unlike here in "Warning! No warnings!)

Does the clinician need to see units such as mg/dL (milligrams pre deciliter) and mEq/L (milliequivalents per liter) on each and every lab value? Correction - on ANY lab value?

Could not that information be placed - once - in the column or row headers?

(Oh, wait ... as shown here, those headers in some products have a tendency to scroll away, forcing the "track the value with your finger" method of medical error prevention!)

(click to enlarge)

Then there's this, just in from Down Under on clinical decision support, touted as one of the most important benefits of HIT:

Quality of drug interaction alerts in prescribing and dispensing software

Sweidan et al., Medical Journal of Australia 2009; 190 (5): 251-254

Objective: To investigate the quality of drug interaction decision support in selected prescribing and dispensing software systems, and to compare this information with that found in a range of reference sources.

Design and setting: A comparative study, conducted between June 2006 and February 2007, of the support provided for making decisions about 20 major and 20 minor drug interactions in six prescribing and three dispensing software systems used in primary care in Australia. Five electronic reference sources were evaluated for comparison

Results: Six of the nine software systems had a sensitivity rate ≥ 90%, detecting most of the major interactions. Only 3/9 systems had a specificity rate of ≥ 80%, with other systems providing inappropriate or unhelpful alerts for many minor interactions. Only 2/9 systems provided adequate information about clinical effects for more than half the major drug interactions, and 1/9 provided useful management advice for more than half of these. The reference sources had high sensitivity and in general provided more comprehensive clinical information than the software systems.

Conclusions: Drug interaction decision support in commonly used prescribing and dispensing software has significant shortcomings.

More in part 8.

-- SS

Information Technology Makes Healthcare Easier? Is This Industry Trying to Harm Patients? Part 6 of a Series

(Note: Part 1 is here, part 2 is here, part 3 is here, part 4 is here, part 5 is here, part 6 is here, part 7 is here, and part 8 is here.)

This post is part 6 of a series on the stunningly poor human engineering of production healthcare IT from major vendors, in use today at major medical centers. These devices provide a decidedly mission hostile user experience, yet with an almost religious fervor are being touted as cybernetic miracles to cure healthcare's ills.

During the Sunday morning talk show "Roundtable" this morning, I saw an IBM ad touting the fact that they'd surpassed the petaflop mark (built computers that can perform one thousand trillion floating point calculations per second).

They touted how such computers will enable weather prediction, medical advances, solutions to social problems, and other cybernetic miracles. (Some of these miracles have been promised since the days of ENIAC in the late 1940's.)

Now, I am indeed amazed by such machines, and realize their value when utilized by competent domain experts overseeing equally competent analysts and programmers, ideally along with HCI (human computer interaction) experts who can help humans interact effectively with such computational high performance.

One would think, though, in a culture where we can perform one thousand trillion calculations per second on large machines, and where consumer machines can perform pretty fast as well that we could do better in the human interface to healthcare IT:

As of 2008, the fastest PC processors (quad-core) perform over 37 GFLOPS (Intel QX9775) [that's 37 billion calculations per second - ed.] GPUs in are considerably more powerful, for example, in the GeForce 8 Series the nVidia 8800 Ultra performs around 576 GFLOPS on 128 processing elements ... There are now graphics cards such as the ATi Radeon HD 4870X2 which can run at over 2.4 TeraFLOPS [2.4 trillion calculations per second - ed.]

Amazing. I used to support applications running on IBM POWER-based supercomputers far slower than 1000 trillion FLOPS for drug discovery at Merck, and chatted with those who used these supercomputers in molecular modeling, critical to drug discovery. Today's computing advances are indeed remarkable just a few years later.

Here is where my disappointment arises.

Health IT seems to be back in the TRS-80 days in terms of its failure to utilize these levels of computing power to create a mission friendly user experience and safer medical care.

HIT user experience: trapped in the TRS-80 era?

Below is how a major healthcare IT system forces a user to do even a simple task, changing the starting date and time for a common medication.

Let's count the steps required for what used to require one step: putting the instrument below to paper.



Keep in mind, health IT is touted as improving the quality of healthcare, reducing errors, and reducing costs.

Step one in the world of HIT (a world, as I said, of MIS-inspired inventory systems, not clinical tools for use by clinicians) involves hunting for, and then clicking "frequency" on a scrolling list of possible "order details", seen on the left of the screen below:

(click to enlarge)

The user then clicks on the "ellipsis button" at upper right, which produces a popup to display the "standard times" for B.I.D. (twice a day) meds:

(click to enlarge)

On the popup subscreen is a list of "standard medication adminstration times" or SMAT's. Here the BID times are shown as 0900 and 2100 (9 AM and 9 PM).

To override these times, more screens, more clicks and more work is needed. The user must click on a "requested start date and time," which has defaulted by programmer edict to the CURRENT data and time. The user is warned in the "User Guide" about how to perform this function as follows-

CAUTION: If you do not change the [default] requested start data and time, the first dose will be scheduled for the current date and time.

The "current time" here being 11:28 AM as on left:

(click to enlarge)

Fantastic. The user must then change the requested start data and time to match the SMAT (standard medication administration time) for the first dose. Say they want the first dose to be given at 2100 (9 PM) tonight.

In the screen below, the user changed this to 6/5/2006 at 2100 (9 PM) to match the SMAT time. The first dose is to be given at 2100 (9 PM) on the current night.

(click to enlarge)

But they're not done yet!

After signing the order, the clinician making the change (often a nurse) will need to click the eMAR (Electronic Medication Administration Record) tab. They must verify something called the "eMAR time frame setting" to be certain that this "time frame" is set for something called the "clinical range." See below:

(click to enlarge)

This act comes with a warning in the instruction manual:

CAUTION: Never limit the eMAR to your shift or to today only. Limiting your view of the eMAR may cause you to inadvertently create medication errors. (!)

Inadvertently create medication errors? Really? Should be easy to fix with machines capable of trillions of calculations per second, no?

No. The user is advised that if the eMAR timeframe is not set to "Clinical Range", all they need do is:

Close the patient's chart, and log out of the health IT application. When you log on next time, the time frame will default to Clinical Range.

Simple, no? Something we all want our doctors and nurses to be doing day in, day out for just this one simple function, no?

Who designed such an interface? What kind of user experience is this, exactly? One designed to make clinical work easier?

Perhap the HIT designers might seek a brain transplant or some other procedure to restore brain function, and then utilize the amazing computational power of modern IT and the advances in biomedical informatics, computational lingustics, parsers (used in building computer program compilers), etc. to allow a user to type in a command with an easily learned syntax such as:

> change Amoxicillin bid 0900 2100 start 06/05/2006

and have the computer popup a verification window that asks:

Are you sure you want to change Amoxicillin to twice daily, 0900 and 2100 (9 AM and 9PM), starting Monday June 5 (Yes/no)?

Or are such undergraduate level computer science feats beyond what's "a good business case" for the HIT vendors, thereby banking on the cognitive diligence of healthcare providers to make up for HIT stupidities?

Are these vendors aware of fifty+ years of computer science, information science, biomedical informatics, HCI and other research? Who, exactly, is creating, testing and approving the clinician user experiences I am illustrating?

Clinicians as technophobes when we're talking about poor IT such as presented in this series? My a**.

In part 7 and on we shall start to see the "peek a boo, wild goose chase, go find your lab data" screens I've mentioned.

-- SS