EHR – Checklists & Bayesian Diagnosis

A very interesting recent article by Shiff and Bates published in NEJM proposes a rather ambitious benefit for EHRs.
The article aptly titled “Can Electronic Clinical Documentation Help Prevent Diagnostic Errors?” and aptly presented as a question rather than a statement, is exploring the possibility that EHRs can reduce diagnosis errors. The authors duly admit that there isn’t much evidence to support such forward thinking for the current crop of EHRs.

“Admittedly, evidence to support the existence of such a benefit is currently lacking, and our hypothesis runs counter to the sentiments and claims of many physicians, who argue that electronic documentation in its current incarnation is time-consuming and can degrade diagnostic thinking — by distracting physicians from the patient, discouraging independent data gathering and assessment, and perpetuating errors.”

However, they are envisioning a new breed of electronic documentation that will be capable of fulfilling such lofty goal. Most of the proposed characteristics of this new generation of software are incremental improvements to collection and presentation of information from various sources. This is in line with the national goals of fostering interoperability and the creation of an Electronic Medical Record for every American by 2014. Computerization is also viewed as a solution for the introduction of mechanical errors due mostly to poor handwriting and poor paper based book keeping, such as the benefit provided by electronic prescribing. All in all, the authors’ suggested “top 10” style list of desired improvements to EHR technologies are very sensible and have the potential to improve usability, collaboration and effectiveness.

An interesting aside is that the authors propose more textual data capture and more reliance on voice recognition as opposed to discrete data capture by “ticking boxes”. I hope the authors understand that dictation and free text do not lend themselves very well to “aggregation, trending, and selective emphasis or display of data so as to facilitate rapid judgments”, which are the cornerstone of the approach suggested in the article.

A more interesting suggestion is the use of Checklists for “Providing prompts”:
“Provide checklists to minimize reliance on memory and directed questioning to aid in diagnostic thoroughness and problem solving”

And to go with the checklists there is “Calculating Bayesian probabilities”:
“Embed calculator into notes to reduce errors and minimize biases in subjective estimation of diagnostic probabilities”.

This, of course is the opinion that decision support at the point of care has to become powerful enough to change the imperfect way medicine is practiced today.

“But we envision a redesigned documentation function that anticipates new approaches to improving diagnosis, not one that relies on the putative “master diagnosticians” of past eras. The diagnostic process must be made reliable, not heroic, and electronic documentation will be key to this effort.”

The question in my mind is at what point does decision support become too powerful and begins crippling both physicians and quality of care? And is there such a point?

For an opinion on this subject, I suggest Dr. Jerome Groopman’s excellent book “How Doctors Think”.

Health IT Strategic Framework – Field of Dreams

Health IT is on a binge. Every day we are served with a new acronym, a new committee, a new contract, a new grant and a new goal. Health IT is definitely creating jobs, which was indeed one of the goals. But there was one other stated goal.

It was supposed to help physicians and patients provide and obtain better health care by making pertinent information available at the point of care, by involving patients and their families in their own care and by using computers to improve accuracy of clinical information. It was supposed to benefit patients in a very immediate and tangible way. That was the original meaning of the over used term “patient centric”. It was supposed to be all about the individual patient.

There were secondary goals as well. A byproduct of computerization of Medical Records is, of course, the ability to conduct research to benefit populations and advance the science of medicine, but somehow, in the frenzy of spending federal funds, the byproduct became the main objective.

I am a big fan of Dr. Blumenthal and in perpetual awe of his work at ONC. Today I read the recently published Health IT Strategic Framework. The ONC’s articulated vision, which drives the entire framework, is the creation of a “learning health system”. An excellent vision to be sure; a vision which drives a framework of security, privacy, biosurveillance, data collection public health, medical research and reporting. I have no doubt that in due course, such learning health system will produce evidenbe based information to support cost effective care and benefit future generations of Americans and humanity in general.

How do you build such a learning health system? It seems that ONC is tackling the task head on, by actually building a system from the ground up, complete with a National network (NHIN), localized intermediaries (HIE), individual access points (EHR), education centers (HITREC), standardization (Meaningful Use), certification (NIST, NVLAP, ONC-ATCB, ONC-ACB, ONC-AA), all driven by rulemakings and generous financial awards.
This is the “Field of Dreams” theory (If you build it, they will come), and it does work sometimes, as Kevin Costner can attest.

We could of course try a bottom up approach.

Case 1. 60 year old John Doe presents at the ED with chest pain. What does the attending physician need as far as information is concerned? A good current medications and allergies list and a good current diagnoses list and a little time to listen to John and take a good history of present illness. What does the attending physician not need? John’s growth charts from when he was a baby, John’s immunizations records from high school, John’s record of taking antibiotics for an STD while serving in the Navy 40 years ago, John’s record of taking other antibiotics for a sinus infection 5 years ago, etc. It would be nice if the attending doc could “get online” and download a couple of paragraphs of information from John’s PCP.

Case 2. 55 year old Mary Doe has Diabetes and Hypertension and CAD. She is sitting across from a Cardiologist who is seeing her for the first time. What does the Cardiologist need in order to evaluate Mary? Pretty much the same information the ER attending needed, plus any pertinent test results that her PCP might have ordered. And just like the ER attending, the Cardiologist needs a little time to listen to Mary. Most likely Mary’s PCP already faxed the information over. It would have been nice if the PCP information would “magically” end up in the Cardiologist’s chart and the Cardiologist consult note would end up in the PCP chart. It would also be nice if Mary’s daughter could “get online” and look at everything the doctors are doing, or proposing to do, because Mary may want to discuss her options with her daughter who lives 1000 miles away.

Turns out that patients and doctors can pitch a good game in the backyard with just a bat and ball. So maybe all we need is a few more bats and balls – Internet access, simple file transfer, CCR and some very simple game rules, so no one gets accidentally hurt…..  Let’s get all of us in the game before pretending to be Shoeless Joe Jackson.

How to Health 2.0-ize Your Patient Portal

(Tips for Techie Docs and EHR Vendors)

First, we need to define the terminology. Patient Portals are software or web services accessible in real time by both physicians and patients. Patient Portals come in two flavors: tethered to an EHR and untethered.

Tethered Patient Portals are just a different view of the doctor’s EHR. This is a restricted view of a patient chart and it includes the ability to communicate with the clinic in a secure fashion.  Some EHR vendors provide their own Patient Portals, while others offer full integration with third party Portal vendors. In both cases, physicians use their EHR to communicate with patients.

Untethered Patient Portals are standalone Portals used for secure communications only. Patients can send and receive messages to/from their physician, but they do not have a complete view of their chart. Physicians cannot initiate communications directly from their EHR. Instead they need to log into a separate Portal application.

There is a third type of software/service usually mentioned in this context, and that is the Personal Health Record (PHR). The best known providers of this type of service are Microsoft Health Vault and Google Health. PHRs, however, are directed to aggregation of patient data from multiple sources and less concerned with real time communication between patient and doctor. PHRs are outside the scope of this discussion.

What is Health 2.0? The term derives from the better known Web 2.0 terminology. There are many definitions for Web 2.0, but generally speaking it is the new generation of web applications that are interactive (as opposed to static), collaborative, user centered and very social in nature. The most ubiquitous examples of Web 2.0 and its power are social networks liked Facebook, Twitter, You Tube and even Google Apps.  Health 2.0 means pretty much the same thing for health care oriented applications. The newer EHR technologies that are delivered over the web, the various online patient communities, telemedicine, and remote monitoring devices are all examples of Health 2.0 applications.

A Patient Portal has all the makings of Health 2.0, but it lacks a social aspect. If a Patient Portal could allow the creation of patient communities and facilitate social interaction of patients with similar conditions or interests, it would be the ultimate Health 2.0 application, and much more powerful than larger internet communities of patients. The reason for this is that a Patient Portal community is also a physical community – people who have the same doctor, usually reside within a commutable distance. A Patient Portal Community could create relationships and support systems not just in cyberspace, but in the real world as well. For example, a Diabetes community could bring together folks that may decide to go for walks together every Saturday; dialysis or cancer patients can arrange for carpools; young moms can get together for play-dates or outings at the mall….. The possibilities are endless.

How does a doctor or vendor facilitate such benefits? The answer is very simple: by adding Forum capabilities to your Patient Portal. Forums are websites where one can go and ask questions, receive answers, start a conversation and get to know other people with similar interests. There are multiple options for free Forum software you can download or have hosted for pennies a day (see below). For privacy and security reasons, Forums should not be integrated with your EHR, but should be accessible from your Patient Portal. Even if you don’t have a Patient Portal, you probably have a website for your practice. You can add a link to the Forums right there. The hard part for the doctor is to configure Forums for the conditions you see most often, to encourage your patients to sign up, and actively participate in the conversations, at least initially. Your patients will more than likely take it from there. If you feel up to it, you may even add a blog to your Forums where you can provide guidance and advice, promote health and wellness and empower patients and families to participate in their own care.

While global Internet communities have obvious advantages in their sheer size and diversity, small local communities have the ultimate power of transcending the Internet and affecting real change on the ground, and isn’t that what Family Practice is all about?

Sample Free Forum Software:
PHPBB - http://www.phpbb.com/
SMF - http://www.simplemachines.org/ 
Forum Software Reviews
http://www.forummatrix.org/
http://www.forum-software.org/forum-reviews

A Day at the Beach

(Casual Friday Fun Series)

Since they were toddlers Timmy and Tommy spent their summers together at Liberty Beach. The boys lived far apart on the Mainland, but each summer their parents brought them to Liberty Village for a well-deserved vacation. Since there were no other little boys in the time-sharing community, Timmy and Tommy brought their pails and shovels to the water edge and spent their days together building sandcastles on the beach. As the boys got older and the castles became more elaborate, their play became more contentious.

See, Timmy liked building tall narrow castles, and Tommy preferred the wider, lower and more fortified type. Arguing over the architecture was somehow part of the game and the castles ended up being not too narrow and not too wide, with the boys having great fun and working up a healthy appetite by the time they were summoned home for dinner.

These were the best of times until the summer before kindergarten. Tommy’s parents bought their little boy a brand new shinning metal shovel bigger than ever. Timmy showed up at the water edge with his old plastic shovel and pail. Tommy was hauling sand at an unprecedented rate with his new toy and Timmy wanted to play with the big shovel too. It wasn’t fair. The castle was getting wider and wider with every stroke of Tommy’s shining toy. Timmy, almost in tears, folded his arms across his chest and refused to play. Tommy kept hauling sand trying to get Timmy back into the game. He even added a few really tall turrets to the castle, but Timmy started yelling, screaming and kicking the castle with his bare feet. It wasn’t about the castle anymore; Timmy just wanted a turn at that big shinny shovel. Watching his hard work falling apart, Tommy got angry too.

It was getting late; almost dinner time, so Tommy patched the castle here and there and the boys ran home for dinner leaving behind a half-finished castle and with no appetite for mom’s casserole. Timmy and Tommy did not go back to the beach that summer. On the way home, in the back seat of the Land Rover, Timmy vowed to make his parents buy him the biggest shovel ever, so next summer he would build the tallest sandcastle Liberty Village ever saw. Tommy squished between his sisters in the old Chrysler minivan was clenching his big shovel, which didn’t look so shiny anymore, in his little hands, hoping against all hope that it will last until next summer....

The DEA IFR - Quick Review for ePrescribe

On March 24, the DEA has released its IFR on Electronic Prescriptions for Controlled Substances, which incorporates the public comments received on the NPRM from June 27, 2008. Looking at the current ePrescribe applications on the market today, the DEA IFR will require significant software development, particularly security related. It will also require changes in prescribers' workflows.
Here are the highlights (italicized text is quoted from IFR):

Obtaining Authentication Credentials - Allows remote identity proofing
"DEA is requiring registrants to apply to certain Federally approved credential service providers (CSPs) or certification authorities (CAs) to obtain their authentication credentials or digital certificates. These CSPs or CAs will be required to conduct identity proofing at National Institute of Standards and Technology (NIST) SP 800-63-1 Assurance Level 3, which allows either in-person or remote identity proofing. Once a Federally approved CSP or CA has verified the identity of the practitioner, it will issue the necessary authentication credential."

Two Factor Authentication - Biometrics may substitute for hard token 

"As proposed, DEA is requiring in this interim final rule that the authentication credential be two-factor. Two-factor authentication (two of the following – something you know, something you have, something you are). In the interim final rule DEA is allowing the use of a biometric as a substitute for a hard token or a password." 

Controlled Substances Pending Lists displaying all data elements

"DEA is requiring that the application display a list of controlled substance  prescriptions for the practitioner’s review before the practitioner may authorize the prescriptions. A separate list must be displayed for each patient. All information that the DEA regulations require to be included in a prescription for a controlled substance, except the patient’s address, must appear on the review screen along with a notice that completing the two-factor authentication protocol is legally signing the prescription."

Two step prescribing - Readiness to sign -> Prompt for two factor  authentication -> Sign
Registrants must indicate that each controlled substance prescription shown is ready to be signed. When the registrant indicates that one or more prescriptions are to be signed, the application must prompt him to begin the two-factor authentication protocol. Completion of the two-factor authentication protocol legally signs the prescriptions. When the two-factor authentication protocol is successfully completed, the application must digitally sign and archive at least the DEA-required information."

No paper duplicates allowed, unless transmission fails
"DEA has clarified that the application may print copies of an electronically transmitted prescription if they are clearly labeled as copies, not valid for dispensing. If a practitioner is notified by an intermediary or pharmacy that a transmission failed, he may print a copy of the transmitted prescription and manually sign it. The prescription must indicate that it was originally transmitted to a specific pharmacy and that the transmission failed."

Digital Signatures - Either by the application or Prescriber Private Key 
"When the practitioner uses his two-factor authentication credential as specified in § 1311.140(a)(4), the electronic prescription application must digitally sign at least the information required by part 1306 of this chapter and electronically archive the digitally signed record. If the practitioner signs the prescription with his own private key, as provided in § 1311.145, the electronic prescription application must electronically archive a copy of the digitally signed record, but need not apply the application’s digital signature to the record".

Audit logs need to be augmented
"The application provider and the registrants must develop a list of auditable events; auditable events should be occurrences that indicate a potential security problem. For example, an unauthorized person attempting to sign or alter a prescription would be an auditable event; "

Daily Audit Checks - 24 hours reporting
"The applications must run the internal audit function daily to identify any auditable events. When one occurs, the application must generate a readable report for the practitioner or pharmacist. If a practitioner or pharmacy determines that there is a potential security problem, they must
report it to DEA within one business day."

EHR Data Exchange - Where is the Bang for the Buck?

In the past months I have been religiously dialing in and listening to the ONC  Policy and Standards committees meetings. The amount of work done by the members is nothing short of monumental and the combined knowledge and experience is astounding.

Like most of us in the HIT industry, I have spend many hours poring over the IFRs, NPRMs, Power Point schematics and every work product available, and like most everybody else I am a bit lost in the sea of acronyms, harmonizations and network diagrams.

The bottom line, though is that we are hopeful that physicians will adopt and use EHR technology which is built to the standards defined by ONC. The promise for physicians is that the eventual interoperability will facilitate meaningful exchange of clinical information, which will in turn provide the ultimate ROI in the form of better, less wasteful care.

In order to validate this assertion, let's examine the most common occurrence of the need to exchange clinical information in private practice: Referrals. Below are three diagrams of a typical referral process from PCP to Specialist and back, one for paper offices, one for offices on current EHR software and one for the futuristic EHR capable of exchanging standard driven discrete data.

View larger image [Scribd]

Let's note first that the efficiency offered by Patient Portals or PHRs (shaded in pink) is mediocre today, but should become significant as online patient access to records and bi-directional physician-patient communications become common practice. Meaningful Use is correctly encouraging that.

The gray shaded areas show steps that are made more efficient by the introduction of EHR technology. A conventional EHR for example, eliminates the need for printing, scanning and filing exchanged documents in the physical chart. The futuristic EHR will further eliminate the electronic faxing (directly into the EHR) and replace it with discrete data transfer.

These particular tasks are only a small part of the referral workflow and not even the most time consuming.
None of these tasks are performed by Physicians. 

Of course, there is more to Interoperability than just referrals. There are prescriptions, laboratory tests, radiology and administrative transactions, for which we have pretty good standards. Then there are surgeries, admissions, discharges, transitions of care and more, which need some more work, but just like referrals, basic document transfer is very acceptable from a physician point of view and already electronically occurring in practice.

While the change from paper to the currently available, non standardized,  EHR technology can be shown to provide significant time saving for office staff, the transition to standards based EDI for referrals offers only incremental benefits to the practice, while requiring major and complex technology retooling. Not to mention the elaborate infrastructure of intermediaries  of every form, shape and governance, which deserves its own separate analysis.

Granted, the capture of, and ability to report on, discrete clinical data, promises great advances in research and quality measurement. It may also be offering tangible benefits to a variety of other stakeholders. However, we are asking physicians in private practice, most practicing solo or in very small groups, to make a significant effort, in both time and money, to purchase and use certified EHR technology with all the complexity and expense of harmonized acronyms.

Shouldn't we be able to at least show them where THEIR bang for THEIR buck is?

We are, or could be, Better than Banks!

I try to stay away from Banks as hard as I try to stay away from the doctor's office. Unfortunately I had to visit both recently. A week ago I had to take my son to an orthopedic surgeon (nothing serious), and today I had to go to the bank.

The Bank

Granted, I needed a rather tricky service involving a public notary, but it was not a very complex transaction. I brought with me 3 sets of 5 forms (in duplicate) that I received through regular mail after several phone conversations with another bank. No, there was nothing online for me to fill out and be done. No, they couldn't fax anything over and no, I couldn’t fax it back. eMail? No, we don’t do eMail.

The bright young clerk at my local branch took the forms and after failing to understand the purpose and after asking around for a while, finally called the main office and literally read the forms out loud for the person on the phone.

Since I had plenty of idle time I started looking around. There was a computer on every desk, but there were also wire trays full of forms and yellow folders. This is a fairly new branch of a fairly large bank with lots of marble and glass everywhere.

On the other side of the room, there was another clerk attending to a young couple. I have no idea what they were doing, except that they were told to "sign here... and here.... name and address …..social goes here…yes, you need both…" several times and each time some new form was being presented by the very nice clerk and pulled away upon completion.

I walked out 45 minutes later with my stack of partially notarized forms that I would have to send back to the original bank by regular mail. The remainder required more forms to execute…..

The Doctor

Last week, I called the orthopedic surgeon for a consultation. The front office lady gave me a URL to go to and input my son's information, which I did. I noticed that if we would need more visits, I could book them online.

On the day of the appointment, we walked in and they snapped his picture straight into the EMR. They took my insurance card, slid it through a card reader and my son was told that he could update any changes to his info on one of the two computers in the waiting room (he found a way to get on Facebook instead).

It was a quick visit. The doctor came in chatted for a bit, checked out my kid’s elbow, said to just leave it alone (I love this type of doctor), shook hands and walked out. He never wrote anything. He is probably one of those docs that prefer to document in between patients. I know he read the histories before he came in though, so I assumed (and also verified with the nurse) that his computer is in his office.

We walked out 45 minutes later and as we were walking to the parking lot, I realized that I did not have to touch either a pen or piece of paper. And neither did the receptionist (insurance cards are plastic). And neither did the doctor.

When it comes to paperless office, Healthcare is eons ahead of Banks…..

The HCR Die has been Cast

(Implications for HIT Industry)

On Sunday night, March 21, 2010 the much debated and deeply polarizing Health Care Reform (HCR) bill has been passed by Congress, clearing the way for President Obama to turn it into law by a flourish of his pen.

Whether this makes you happy or distraught, whether you woke up in  a Socialist State this morning, or a Humanitarian one, whether you prefer Tea parties or Starbucks lattes, if you are a Healthcare Information Technology (HIT) professional, today brings with it a wealth of new challenges and opportunities to make a difference.

While ARRA and HITECH tasked the HIT community with the creation of an electronic medical record for every American by 2014, the new HCR bill will demand that HIT does its share to support improvements to the global quality of health care. Some of the quality goals outlined in the bill have been discussed for quite some time and others are being tried out in various clinical settings already.
Roughly speaking, there are four objectives in the HCR bill that will require massive HIT support: administrative streamlining, quality measurement, patient involvement and innovative care models. In these contexts, HIT will need to create real time, online communications between physicians and their patients, between community members, care givers, payers, pharmacists and government agencies. This could be the shining moment of the emerging Health 2.0 movement and a great opportunity for health insurers to redeem themselves by creating web accessible transparency in costs and quality for consumers.
So here is a hopefully comprehensive selection where HIT can have the largest beneficial impact.
All section numbers are from the original Senate Bill - H. R. 3590. My comments in blue.

Administrative
TITLE I—QUALITY, AFFORDABLE HEALTH CARE FOR ALL AMERICANS
Subtitle B—Immediate Actions to Preserve and Expand Coverage
Sec. 1104. Administrative simplification.
Financial and administrative electronic transactions between payers and providers are to be standardized, made more transparent, timely and uniform. This refers to the HIPAA transactions such as eligibility, electronic claims and electronic remittance advice. Hopefully this provision will eliminate, or at least reduce the variations in format and the multitude of the, so called, payer edits.
TITLE II—ROLE OF PUBLIC PROGRAMS
Subtitle H—Improved Coordination for Dual Eligible Beneficiaries
Sec. 2601. 5-year period for demonstration projects.
Sec. 2602. Providing Federal coverage and payment coordination for dual eligible beneficiaries.
Both demonstration projects and the ensuing coordination of benefits will require sophisticated additions to current billing software, both on the provider end and the payer end.
TITLE VI—TRANSPARENCY AND PROGRAM INTEGRITY
Subtitle F—Additional Medicaid Program Integrity Provisions
Sec. 6504. Requirement to report expanded set of data elements under MMIS to detect fraud and abuse.
Subtitle G—Additional Program Integrity Provisions
Sec. 6603. Development of model uniform report form.
More reporting.

Quality Measurement
TITLE III—IMPROVING THE QUALITY AND EFFICIENCY OF HEALTH CARE
Subtitle A—Transforming the Health Care Delivery System
PART I—LINKING PAYMENT TO QUALITY OUTCOMES UNDER THE MEDICARE PROGRAM
Sec. 3001. Hospital Value-Based purchasing program.
Sec. 3002. Improvements to the physician quality reporting system.
Sec. 3003. Improvements to the physician feedback program.
Sec. 3004. Quality reporting for long-term care hospitals, inpatient rehabilitation hospitals, and hospice programs.
Sec. 3005. Quality reporting for PPS-exempt cancer hospitals.Title III. Subtitle A. Part II.
PART II—NATIONAL STRATEGY TO IMPROVE HEALTH CARE QUALITY
Sec. 3014. Quality measurement.
Sec. 3015. Data collection; public reporting.
TITLE VI—TRANSPARENCY AND PROGRAM INTEGRITY
Subtitle D—Patient-Centered Outcomes Research
Sec. 6301. Patient-Centered Outcomes Research.
Sec. 6302. Federal coordinating council for comparative effectiveness research.


Patient Empowerment
TITLE I—QUALITY, AFFORDABLE HEALTH CARE FOR ALL AMERICANS
Subtitle D—Available Coverage Choices for All Americans
PART II—CONSUMER CHOICES AND INSURANCE COMPETITION THROUGH HEALTH BENEFIT EXCHANGES
Sec. 1312. Consumer choice.
The establishment of insurance exchanges will necessitate supporting software both for oversight of exchange activities and mainly to allow consumers to make informed purchasing decisions.
TITLE II—ROLE OF PUBLIC PROGRAMS
Subtitle L—Maternal and Child Health Services
Sec. 2952. Support, education, and research for postpartum depression.
Sec. 2953. Personal responsibility education.
Sec. 2954. Restoration of funding for abstinence education.
Sec. 2955. Inclusion of information about the importance of having a health care power of attorney in transition planning for children aging out of foster care and independent living programs.
TITLE III—IMPROVING THE QUALITY AND EFFICIENCY OF HEALTH CARE
Subtitle F—Health Care Quality Improvements
Sec. 3507. Presentation of prescription drug benefit and risk information.
Sec. 3510. Patient navigator program.
TITLE IV—PREVENTION OF CHRONIC DISEASE AND IMPROVING PUBLIC HEALTH
Subtitle A—Modernizing Disease Prevention and Public Health Systems
Sec. 4004. Education and outreach campaign regarding preventive benefits.
TITLE V—HEALTH CARE WORKFORCE
Subtitle F—Strengthening Primary Care and Other Workforce Improvements
Sec. 5507. Demonstration projects To address health professions workforce needs; extension of family-to-family health information centers.
Multiple patient education and patient involvement efforts that will need to be disseminated and accomplished, more than likely, by electronic means.

Innovative Care Models
TITLE II—ROLE OF PUBLIC PROGRAMS
Subtitle I—Improving the Quality of Medicaid for Patients and Providers
Sec. 2704. Demonstration project to evaluate integrated care around a hospitalization.
Sec. 2705. Medicaid Global Payment System Demonstration Project.
Sec. 2706. Pediatric Accountable Care Organization Demonstration Project.
Sec. 2707. Medicaid emergency psychiatric demonstration project.
TITLE III—IMPROVING THE QUALITY AND EFFICIENCY OF HEALTH CARE
Subtitle A—Transforming the Health Care Delivery System
PART III—ENCOURAGING DEVELOPMENT OF NEW PATIENT CARE MODELS
Sec. 3023. National pilot program on payment bundling.
Sec. 3024. Independence at home demonstration program.
Sec. 3025. Hospital readmissions reduction program.
Sec. 3026. Community-Based Care Transitions Program.
Sec. 3027. Extension of gainsharing demonstration.
Subtitle F—Health Care Quality Improvements
Sec. 3501. Health care delivery system research; Quality improvement technical assistance.
Sec. 3502. Establishing community health teams to support the patient-centered medical home.
Sec. 3503. Medication management services in treatment of chronic disease.
Sec. 3506. Program to facilitate shared decisionmaking.
Sec. 3508. Demonstration program to integrate quality improvement and patient safety training into clinical education of health professionals.
TITLE IV—PREVENTION OF CHRONIC DISEASE AND IMPROVING PUBLIC HEALTH
Subtitle C—Creating Healthier Communities
Sec. 4206. Demonstration project concerning individualized wellness plan.
Subtitle D—Support for Prevention and Public Health Innovation
Sec. 4301. Research on optimizing the delivery of public health services.
Sec. 4302. Understanding health disparities: data collection and analysis.
Sec. 4303. CDC and employer-based wellness programs.
Sec. 4306. Funding for Childhood Obesity Demonstration Project.
TITLE VI—TRANSPARENCY AND PROGRAM INTEGRITY
Subtitle B—Nursing Home Transparency and Improvement
PART II—TARGETING ENFORCEMENT
Sec. 6114. National demonstration projects on culture change and use of information
technology in nurring homes.
A host of pilots and demonstration projects to explore cost reductions and quality improvements through a variety of innovative models such as Patient Centered Medical Homes, Accountable Care Organizations, wellness programs, payment bundling and global budgets. All these projects will require electronic coordination of care and payments and most will also require online patient and community participation.

Now that the dust has settled, or so we hope, I would say that we have our work cut out for us. So let us roll up our sleeves and do our part.

A Century of Medical Records

(HIT Lessons from History)

The Nineteen Hundreds

In 1901 Dr. Henry Stanley Plummer, a very young "techie doc" joined the Mayo Clinic. By all accounts Dr. Plummer had both the peculiarities and the single mindedness of true genius. He was, of course an excellent physician, but his largest contribution to modern medicine was the Medical Record.
In 1907 Dr. Plummer and his assistants deployed a novel way of keeping patient records. Up to that point patient records were kept in ledgers. The multiple offices at Mayo each had its own ledger. Once the initial visit was entered in a ledger, all following visits and procedures were added to that page, sometimes in crowded text on the margins. One patient could have entries scattered across a multitude of ledgers. Dr. Plummer introduced a centralized medical record consisting of a big envelope where all doctors would aggregate all the information regarding a particular patient. Each patient was assigned a unique identifier and his/her own dossier of clinical documents. The medical record would follow the patient everywhere at Mayo and all physicians would have access to all records.
Of course, Mayo was an integrated delivery system, bringing together specialists and surgeons and primary care physicians, all working together for the benefit of the patient. The multi-specialty private group was Drs. Will and Charlie Mayo's contribution to the changing face of modern medicine.
But Dr. Plummer did not stop at creating the patient centric comprehensive medical record. After tinkering with a complex system of cables and pulleys, Dr. Plummer came up with a pneumatic system of tubes and conveyors to rush patient records from one office to another. He also invented a communication system between physicians in exam rooms based on the telephone system and a telegraph ticker.

Dr. Plummer implemented Will & Charlie Mayo's vision of clinical collaboration for the benefit of the patient, using the latest technologies available during his time.

The 21st Century

One cannot but feel humbled when exploring the early history of Mayo, and Dr. Plummer in particular, because one hundred years later, all of us in Health Information Technology are still trying to implement Dr. Plummer's original innovation.
Times have changed and we now have computers and Internet and iPhones on 3G networks. It seems we have all the tools needed to create a collaborative comprehensive patient centered record system, so why don't we have one?

Although Dr. Plummer's patient record has changed very little over the last century, the practice of medicine has seen significant changes. The integrated multi-specialty Mayo model has gained some support, but most medical care in the US is not administered in integrated settings. Hospitals today are much different than the original St. Mary's hospital at Mayo and most are profit centers. And then there is health insurance, which brought concerns of privacy and injected financial considerations into every exam room across the country. Pharmaceutical companies, device manufacturers and health related consumer marketing have acquired immense power over the practice of medicine.
Dr. Plummer's patient record morphed from a tool to benefit patient care, into a legal document and mostly a financial asset.

Legal documents and financial assets are not readily shared. Hospitals are afraid of competition and so are their large firms of IT vendors. Independent physicians are afraid of government, lawyers and insurers scrutiny. Patients are afraid of loss of privacy translating into loss of insurance and even loss of employment. On the other side of the chasm, pharma companies are itching to get their hands on "the data" and the direct marketing channel. Insurers are looking forward to even more details to help with risk assessment. And CEOs of every kind of IT company are looking to "monetize" whatever treasures of "data" they can amass.

It is interesting to notice that in closed autonomous environments, where the legal-financial considerations do not exist, like the VA or Kaiser Permanente, patient records are untethered and collaboratively shared by all involved.

Today we are in the midst of a major HIT push, and maybe on the cusp of health insurance reform, and the conversation revolves around enabling physicians to share information. In other words, we are trying to establish a national system of pneumatic tubes, pulleys and conveyor belts for medical records. The interesting part is that we already know how to do that. The Internet moves terabytes of information at any given moment from one end of the Globe to another. We have the means to implement Dr. Plummer's communication system, and we have the framework to enable collaboration, but we are not using any of this tremendous infrastructure. Instead we are embroiled in lengthy debates on the so called Meaningful Use - a laundry list of minute details that need to be recorded and reported to Government agencies.

I wonder if Dr. Plummer's system would have been equally successful and resilient, if he insisted that every patient record, moving through his pneumatic tubes, had to include a smoking status exactly stating "current smoker, never smoked or former smoker". And I wonder if his system would have ever taken off if he started by requiring that a special subset of the medical record should go to the administration office first. And I wonder why Dr. Plummer never referred to patient records as "data".

We may have Dr. Plummer's plumbing in place, but what we lost is Dr. Will Mayo's belief that "The best interest of the patient is the only interest to be considered...".

How Did We Get Here?

On January 8, 2009 President-elect Barack Obama gave a speech at George Mason University in Virginia, and this is what he said regarding medical records:
"To improve the quality of our health care while lowering its cost, we will make the immediate investments necessary to ensure that, within five years, all of America's medical records are computerized...... This will cut waste, eliminate red tape and reduce the need to repeat expensive medical tests...... it will save lives by reducing the deadly but preventable medical errors that pervade our health-care system,"

Reading the President's words, it seems that making all pertinent information available at all points of care would be the holy grail. The means to achieving such lofty goal would be the humble computer, known for its ability to record, aggregate and disperse information of all shapes and forms.

There can be little argument that physicians armed with the most up to date information for the patient before them, would be able to fulfill Mr. Obama's vision of better medicine at lower costs, both financial and human. One could argue that the cost reductions in the form of less duplication of tests and the error reduction inherent in availability of good comprehensive information, are negligible, but it is hard to argue with the superiority of  a comprehensive readily available record over bits and pieces, or nothing at all.

So the HITECH Act was passed, committees were set up, hundreds of pages of rules and regulations were issued, standards and policies were defined in thousands of power point presentations, and billions of dollars were spent, and are yet to be spent, in the process of.....
In the process of what?

To answer this question, let's look at we've done so far and what we are still intent on doing.

• In the HITECH Act, legislators felt a need to define HOW physicians should use computers in their practice. More accurately, the legislators defined WHO is going to define HOW physicians use computers.

• The ONC then proceeded to create an infrastructure of talent, rarely seen aggregated in such quantities, to work on the HOW.

• CMS and ONC finally produced the criteria of WHAT physicians are supposed to do with their computers, the Meaningful Use.

• Meaningful Use details an array of data points that physicians must record and a much larger array of items where physicians need to crunch all sorts of numbers and report them to the Government, and a few provisions for sharing the recordings with their patients.

• In order to verify that physicians are not just Meaningfully caring for patients, but also Meaningfully using computers, a sophisticated array of testing labs and certification authorities are being set up to validate that docs everywhere have the right buttons to click on.

• And for those clinicians who are not capable of deciding if to order a DES or a triple-DES to complement the MI seen tonight, there are financial incentives to order SOMETHING. And they can start small and sample the menu of approved technologies a-la-carte. The incentive prize money can buy lots of Pepto Bismol.

What ever happened to the President's vision that America's computerized records will "remove red tape"?

The President asked us to get from point A - bits of clinical information stored in paper silos, to point B - patient centric comprehensive medical record readily available to all.
We have a cart and we have horses, and we have great desire to undertake the journey.

Unfortunately we hooked the cart of bureaucracy, standards and regulations in front of the mighty horses of just sharing information and coordinating care by any means necessary to benefit the patient.

A Sign of the Times - Concierge Cardiology

I was reading KHN today, as usual, and I ran across this little story. It seems that a Cardiology practice in California is "fighting back" the proposed Medicare and private insurers cuts in reimbursements to doctors in the Cardiology line of business.
Basically, Pacific Health Institute (PHI) has published a letter to their patients announcing that in addition to what insurers pay them for services, they will require patients to make direct payments to the clinic, on a subscription basis, or face reduced availability of services, starting April 1, 2010.

KHN, describes this as a "vivid example of a phenomenon called "cost-shifting"", which it is, but then KHN goes on to define it as cost shifting from Medicare to private insurers, who would have to raise their premiums as a result: "The premise is that doctors and hospitals charge privately-insured patients higher rates to make up for the lower fees paid by Medicare and other public programs, as well as uncompensated care for uninsured people."

KHN misses the fact that PHI specifically states in their letter that the reimbursement rate changes are not specific to Medicare: "Changing payment policies by Medicare and insurance companies have forced us to reevaluate our practice model", and the requirement for patients to pay more includes Medicare patients: "...we must now charge for uncovered services. You and your insurance (including Medicare) will still be charged for services rendered and tests performed." [Bold font added for clarification]

PHI's subscription plans range from a basic $500 per year to a Concierge plan of $7,500 per year, and they guarantee a menu of services no longer available to non-subscribers, ranging from priority appointments to 24x7 access to a cardiologist.

Also interesting is the list of services that will be scaled back:
"Anticoagulation (Protimes) and pacemaker/defibrillator management will be significantly curtailed and of limited availability."

Of course the actual implantation of pacemaker/defibrillator devices is not on the list of "curtailed services". Those procedures, and a long list of other procedures, are performed by PHI cardiologists at the neighboring St. John's Hospital, which coincidentally is just building a new inpatient pavilion where "[a]ll patient rooms are private and have a 42-inch plasma flat-screen television and wireless Internet access.", amongst other amenities, such as soothing colors and relaxing garden views.

The only cost shifting I see here is the one "shifted" to the patients.

CCHIT & the ONC IFR - Odds & Ends

As CCHIT published its comments to the ONC IFR, I took another look at the Interim Final Rules and I must admit CCHIT is making some very good points. Read the CCHIT comments here.

Here are a few other odds and ends that I believe will cause problems. I don't quite understand why definitions couldn't have been tightened down a bit more prior to publication. These are pretty elementary things.

Medications & CPOE - Tangled Up

For ambulatory providers Medications are addressed in four different criteria:
170.302(a) - Drug-drug, drug-allergy, drug-formulary checks.
170.302(c) - Maintain active medication list.
170.304(a) - Computerized provider order entry. Enable a user to electronically record, store, retrieve, and manage..... (1) Medications;(2) Laboratory;(3) Radiology/imaging; and(4) Provider referrals
170.304(b) - Electronically exchange prescription information

Theoretically, purchasing a CPOE module and one of the available ePrescribers, like Dr. First for example, should satisfy all four criteria. However, the CPOE module cannot obtain certification for 170.304(a) without managing Med lists, which the ePrescriber already does and must do. So either Dr. First starts managing Lab orders, or Lab order modules start managing prescriptions, or Dr. First and the Lab order vendor need to apply for certification together as one product.

Suggested solution: Remove Medications management from CPOE.


CPOE - No Standards

For ambulatory EHR modules CPOE is defined as follows
170.304(a) - Computerized provider order entry. Enable a user to electronically record, store, retrieve, and manage, at a minimum, the following order types:
(1) Medications;
(2) Laboratory;
(3) Radiology/imaging; and
(4) Provider referrals.

There is no specification of any standards to be used for such recording of orders. This will render CPOE modules, certifying under this premise, useless for electronic orders down the road. I guess buyers need to beware!

Suggested solution: Require that Lab and Radiology orders contain the HL7 required fields for each type of test. Medications, as mentioned above, should be dealt with separately.

Smoking Status - What is that all about?

170.302(f) - Smoking status. Enable a user to electronically record, modify, and retrieve the smoking status of a patient. Smoking status types must include: current smoker, former smoker, or never smoked.

Is anybody envisioning a standalone module that records and displays one item? What would a vendor of such module present for certification? A single screen with three checkboxes and an interface to send the data item somewhere, or a database with two columns (one for patient identifier and one for smoking status)?

Suggested solution: If the insurance industry is hell bent to have physicians record this cryptic and clinically lacking data point, it should be added to 170.302(e) - Record and chart vital signs. This is a temporary solution, and not a very good one, until Meaningful Use requires recording of other History items.

Regarding the EHR Module concept in general, the definition that a Module is anything that satisfies at least one criteria doesn't make sense to me. If we are going to certify Modules, and we should, they need to be defined in a more sensible manner. When I think of an EHR Module, I envision an ePrescriber, or a Registry, not a Smoking Status Recorder.

EHR Technology: A Play in two Acts

Casual Friday Fun Series (triggered by a serious post on THCB)

Act I:
A physician practice in Anywhere, USA
Doctor sitting at his desk, writing prescriptions. Pile of charts on table. Enter HIT Expert
HIT Expert: Doc, you should really stop writing prescriptions on paper and get one of those new ePrescribing tools.
Doctor: Eh... I've been doing this for 20 years....
HIT Expert: But, doc, you can make mistakes and kill patients....
Doctor: I don't make mistakes and I haven't killed anybody yet....
HIT Expert: The pharmacist can't read your scribbles. He could make a mistake... and think about all the typing he has to do to enter your scripts, and the patient will love to have the prescription waiting for him at the pharmacy...
Doctor: My patients have no clue which pharmacy they're going to... I can see the pharmacist's problem... (scratching head)
HIT Expert: You should try ePrescribing. You'll love it and it's free and the Government will pay you a couple hundred dollars to use it. What d'you say, doc? Wanna try now?
Doctor (bleary eyed, looking tired): OK, fine... What do you want me to do?
HIT Expert: Here... Log in here....just sign up here... type in a few things about your practice

Doctor typing, HIT Expert looking over his shoulder, Office Manager going in and out with papers, helping Doctor to type...

HIT Expert: All ready to go....Easy... Now write a prescription....
Doctor: Where?
HIT Expert: Right here. First you enter the patient name, and insurance, and pharmacy...
Doctor: I don't know what insurance he has... I just take care of him.... and I told you about not knowing the pharmacy...
HIT Expert: Here, it's in the chart... (leafing through chart) Type this.....(reading out loud BCBS plan and policy numbers)
Doctor: (typing) This is ridiculous.. was that a G or a Z?
HIT Expert: You only have to do this once. Next time the patient comes, it's all in the computer. Will save you lots of time...next time...
Doctor (looking puzzled): But I never had to do this before.....
HIT Expert: Do you want to computerize your records, or not? C'ommon doc, it's the 21st century....

Doctor keeps typing with HIT Expert looking over his shoulder...
Curtain.

Act II
Doctor at his desk, typing on computer. Pile of charts on table. Enter HIT Expert.

HIT Expert: How's it going doc? Like that ePrescriber?
Doctor: It's OK. My typing is much better now....
HIT Expert: I told you it will save you time... and the patients are safe now...
Doctor: I just wish it stopped popping these alert windows all the time...
HIT Expert: Just ignore them... Everybody does... I can show you how to turn them off...here....
(HIT Expert leans over computer and pushes a few buttons)
HIT Expert: Should be fine now... But that's not why I'm here... You need to get a registry, doc... It's the latest rage....
Doctor: That would be helpful... I'd like to see all my diabetics and how they're doing...
HIT Expert: Perfect... Here's one here... Very cheap... Just signup right here...

Doctor typing, HIT Expert looking over his shoulder, Office Manager going in and out with various documents....

HIT Expert: All set, doc.... Now you can track your little diabetics....
Doctor: Where?
HIT Expert: You have to enter them in the registry, doc... Here, you type their name, vitals, diagnosis... here's a place for lab results... and here's a place to type in their meds....wow, you can even type in their goals... and it has alerts too.....neat...
Doctor: But I already typed in their names and meds in the ePrescriber... doesn't the computer have them in there already?  Did you say more Alerts??? I thought you turned them off....
HIT Expert (with a polite laugh): It's technology doc....it will take hours to explain....you'll get used to it.... this here is the best registry out there and this here is the best ePrescriber out there... if you want the very best, and you do doc, trust me.... it takes some doing.... believe me, it will be worth it.... see how you love your ePrescriber now?.... you will absolutely adore your registry..... (walking slowly off stage)
Doctor: Hey, wait a second.... that's a lot of typing here.... why do I have to type the damn meds in there again.... (voice rising)...hey, Mr. Expert, where do I get the labs from? do you want me to type the labs in? and the weight and height too... (screaming).....I don't have time for this.... I have to see patients...

(Office Manager running in and out with piles of charts; Doctor typing furiously; group of angry patients, advancing from left, gesturing silently; HIT Expert running off right stage)
Curtain.

*********

Suggestions for Act III, IV to XXVI: HIT Expert comes back with  a Patient Portal, Lab results portal, Documentation, Quality Reporting, Bio-surveillance, PACS module, CPOE, HIE, NHIN.....

SaaS EHR or Ascension to the Clouds

Most EHR products, or technologies, in both the hospital and ambulatory market are currently deployed through a local client/server paradigm. The client software is installed on users' PCs and the server software, including the data storage, resides on site in the hospital data center or the clinic office.
However, with Web 2.0 and Cloud Computing upon us, web based EHRs, Practice Management and Billing systems are sprouting all around. Is this the future, or is this customary cyclical IT hype?
A little bit of both and, as usual, the real answer depends on accurate definition of terms.

The first term we need to define is Software as a Service (SaaS).
In the classic (legacy) paradigm, software was built using a Client/Server model. The Server software is proprietary and runs on a big server machine. The Client software, also proprietary, usually runs on each user desktop and connects to the Server software via a local network, or a virtual private network if the server machine is located outside the local network (in a remote data center instead of under the lunch counter in the office).
SaaS, strangely enough, also uses a Client/Server model. The Server software is also proprietary and runs on a big server machine. The Client software runs on each user desktop, but it is not necessarily proprietary. In most cases the Client software is nothing more than a browser. Whether the client is a browser, or a proprietary client, SaaS software is accessible on demand over the Internet, and this is the main difference in paradigm. The SaaS Server may reside on site, but usually it resides in a remote data center, far away.... in the Clouds.

So what is a Cloud? A Cloud is a little drawing used in network diagrams to symbolize the Internet. Thus Cloud Computing really means computing over the Internet. It doesn't really matter where your servers are and it doesn't really matter if your client is a browser or a proprietary program. As long as the Client and Server communicate on the Internet, you are engaging in Cloud Computing.
Simple? It should be, but the current hype in the industry creates the illusion that Cloud Computing is a novel idea and somehow has something to do with the Amazon Cloud, or some Google service application.

Not so. Just like in the good old sky, the computer world has many types of Clouds.
First there is the Private Cloud which refers to having your Server on site, in your own data center, or even in a commercial data center where you rent some rack space.
If you don't want to invest in servers and routers and load balancers and lots of techie employees, you can rent all the computing power you need from such folks like AT&T, Amazon and a myriad of other players. For a little extra cash, they will manage your Server software, including updates, patches and everything your, now unemployed, IT guys used to do. These are the famous Clouds, and as you can see there are various degrees of Cloudiness.

When we talk about EHR, the most common type of Cloud is a "Vendor Cloud" - web based EHRs where the vendor manages the Servers in their own data centers, or in rented data centers. This is the athenahealth model and more recently Practice Fusion, Ingenix CareTracker, Quest360 and an ever increasing number of new entrants and old timers transitioning to web delivery systems.

How about the industry veterans who recently began to offer their Client/Server software as SaaS? Are these new products, or questionable advertising? Neither. You should know by now that all software is really Client/Server. All it takes to jettison an application to the Clouds is to remove the Server from the user's office and make it available to the Client on the Internet. And “on the Internet” does not necessarily mean in a browser. That's exactly what folks like eClinicalWorks and Allscripts MyWay and many others are doing now. Just like the purists' SaaS and Clouds, these non-browser based systems are basically renting out computational and IT resources, by hosting the server machines in their very own Clouds, and some, like Synapse EMR, even in the famous Amazon Cloud.

There are differences, of course. Systems built for the web from the get go are able to share resources better and need much less infrastructure. For example a natively browser based systems will store hundreds or even thousands of different customers in one data base and can get by with one instance of the Server running with multiple redundancy and load balancing. The original Client/Server products still require one server per customer, albeit a virtual one these days, and maintenance is no small feat.

So now that we understand the reality of Clouds, which one is better? The simple answer is that how an EHR got to the Clouds does not matter much. In both cases your capital expenses and IT needs are drastically reduced. In both cases you can access your software from outside the office. It may be a bit tricky for the Client/Server Cloud, but it's still doable from most places you would want to use your EHR, and with the advent of mobile access on iPhones and Blackberry, you really shouldn't have to bring out the old laptop on the golf course.

Maybe, the web based EHRs are better suited to the new interoperability requirements? After all they already reside on the web and there's nothing more common than a browser, right? This is only partially correct. Automated exchange of data on the Internet does not occur through browsers. The biggest interoperability advantage web based EHRs have is due to the inherent aggregation of all customer data. Instead of hundreds of data bases, they only have one. Instead of hundreds of "communications" pipes, they only need one. While a web based Cloud needs only one pipe to other Clouds, the Client/Server Cloud needs as many pipes as they have customers. The onus is on the Vendor, not the customer.

Well, how about modularity and choices for the customer? Unfortunately, this is another misunderstanding. Modularity and availability of plug-and-play EHR modules is made possible only if the EHR vendor decides to allow it, be it web based or not. The fact that you can access the EHR through a browser does not mean that you can plug in another piece of software that you can also access through a browser. True, if the EHR vendor decides to open the platform to others, it is easier to create new modules for a browser client than a proprietary client, but only slightly so.

The take away for anyone searching for the perfect EHR is to beware buzz words, Clouds and Vapors in general.

The 800 lb. Gorilla in the Clouds is of course Security and Privacy and peace of mind. We will look at those in a future post.......

Healthcare IT EHR Platforms

Following a comment by Vince Kuraitis regarding EHR modules below, I thought it would be helpful if we expanded a bit on the notion of "Platform" in the context of EHR software technology.

Roughly speaking there are three kinds of "platforms":
(1) Hardware Platforms like the computer you are reading this on or an iPhone
(2) Operating System (OS) Platforms like Windows 7 or Linux or iPhone OS
(3) Software Platforms like salesforce.com or IBM Websphere Portal

We should keep in mind that some OS platforms, particularly everything made by Apple, are tied to a hardware platform. For example, you cannot install the iPhone OS on a Motorola mobile phone. You can however install Windows 7 or Linux on a Dell machine or a Sony laptop.

So which "platform" are we referring to when we discuss EHR modules that are plug-and-play?

Until very recently, best of breed EHR modules, particularly in Hospital settings, could be assembled by users on various hardware platforms and even various OS platforms. The integration of such modules was achieved by interfacing the modules, that is, creating a platform independent connection between the modules and streaming data across. There are well established IT standards for this sort of communication (TCP/IP, FTP) and every OS platform is capable of supporting them. The integration of such modules occurs purely on a data-exchange level. Each module, more likely full blown application, is completely self-contained when it comes to functionality and data storage.
For example let's look at the most common integration in HIT: an EMR interfaced to a Practice Management (PM) system. Both the EMR and the PM are maintaining separate databases of pathents demographics. Both contain different code to implement such functionalities as searching for patients, registering and updating demographics, creating users and privacy and security measures. When a user changes data in one application, the information is updated in the other application through interfaces (data-exchange).

This process is complex, expensive, requires IT professionals to set up and maintain and is prone to failure. If the modules are developed by different vendors, the coordination of software releases and versions is a very delicate process. From a software development perspective, this arrangement is also very slow and wasteful, since each vendor has to reinvent the wheel and program all features and functionality from scratch. This dilemma is not unique to Healthcare IT.

The software world's response to the problem was twofold, but the underlining idea was the same. Create reusable small general functionality and make it available to other programs as a service. Thus the term Web Services was coined, along with Service Oriented Architecture (SOA). Web Services, for a while the holy grail of modularity, proposed complete vendor, language and OS neutrality. Application would look for, discover and employ, services deployed all over the web. So you could locate and use a service providing weather forecasts in your region, or drug-to-drug interactions, or recommendations for immunization schedules for a healthy six year old. This is very much like asking the web a simple question, subject to simple parameters, and receiving a simple response. Theoretically, one could assemble a large application built on this paradigm, but, at least for Healthcare, the complexity of the domain coupled with the lack of financial drivers, limited the use of Web Services for anything more than replacement for old fashioned (TCP/IP) interfaces.

SOA on the other hand is widely practiced by developers building applications on an internal basis. It breaks down large modules of software into small, reusable service chunks that different teams can use without the need to rewrite code. For example, there are many places in an EHR where you need to search for patients, or display medication lists. An SOA architected application would make these functions available as a service to those writing lab modules and those writing billing modules and so on. It saves development time and makes the software much easier to maintain.
Within an SOA architected software platform (here's that word again), disparate development teams can create functional software modules guaranteed to work together, since they are all using the same services building blocks. My favorite analogy is a big bucket of Lego blocks. Each Lego represent a service. Developers pick Legos from the bucket according to specifications documents and assemble large software constructs. As you get better at this, you create more sophisticated and specific Lego blocks for your developers (like adding the Lego Star Wars kits to your old bucket).

Now let's take a leap of faith and imagine that a vendor who built such SOA architected product, decides to publish a list of all the services available along with a manual on how to use them, and to top it off it makes a test environment available to the public, so they can try building their own bundles of functionality and test their creations. salesforce.com did that for the CRM market and a flurry of little modules to enhance or replace the original salesforce.com product parts quickly emerged. These independent developers could sell their new software to other salesforce.com customers, or make it freely available to all. There is only one thing they couldn't do. They couldn't use their modules without subscribing to salesforce.com and they couldn't run their software on another vendor's platform. For salesforce.com, opening its software platform to outside developers made good financial sense.
                                           - - - - - - - - - - - - - - - -
So when we talk about EHR modules and platforms, what exactly are we talking about?

If we are talking about modules interacting through Web Services, then yes, we could subscribe to a variety of vendor independent modules and create an entire EHR that way. However, there are no Web Services out there, right now, that would allow such integration out of the box. The most common module that is available in this fashion is electronic prescribing, but you cannot buy an e-Prescribing service and expect your other EHR modules to just work with it. Usually the EHR vendor performs the necessary tasks for such integration, including testing, and e-Prescribing services are not interchangeable. There is very little financial incentive for software vendors to create general services in this fashion and even less incentive for large vendors to allow consumption of such third party services. If the financial ROI is not there, like it was for salesforce.com, in most likelihood it will not happen.

How about the salesforce.com model then? The Software Platform. Will it work for Healthcare IT? The answer is a resounding yes. Last week Eclipsys Corporation announced that it is opening its Microsoft powered Helios enterprise platform to software developers everywhere, much like salesforce.com did a few years ago. What does this mean?
It means that small vendors can use the Helios services (Lego bucket) to develop plugins for the Eclipsys Sunrise product. It means that medium size vendors can develop modules to replace some Sunrise modules, and it means that large vendors can wrap their own applications in code that will allow seamless integration with Eclipsys Sunrise. And Eclipsys is taking the responsibility to test, validate and guarantee that all these modules from different companies will indeed work together. Securely.
The caveat is of course that you must become an Eclipsys customer to enjoy all these choices of EHR modules, because Eclipsys is the platform owner.
I believe we will see more large vendors taking this approach in the near future.

We can also take the software platform notion one step further. What if a generic Healthcare platform was built that offered no EHR and only very few basic services, like security, communications and other OS related functionality, such as printing and scanning? What if software vendors could be convinced to build modular EHR services and also make them available to other users of this platform? What if such platform were free to develop on and free to the consumer? Not necessarily open source, just free. Would that work? Would that achieve vendor independent, plug and play EHR modularity that would lower costs and improve quality?
There is only one possible answer to this: Not really.

First, software platforms, as their name indicates are made of software. Software needs to be maintained, updated and fixed. This costs money.
Second, in order to ensure true integration, someone has to test all these modules and their interaction, and validate data integrity and proper functionality. This too costs money.
In other words, any software platform requires governance. Without governance, a platform is only useful as an open source tool for professional developers. And governance costs money.

IBM Websphere Portal is one such software platform. By EHR pricing standards, Wesphere is very expensive. The only way, I can see, to create and maintain a Healthcare IT open software platform is for the Government to offer one to vendors and providers for a nominal price, which means that the public is paying for the necessary governance.

EHRs are very complex transactional pieces of software. They are the ultimate challenge in enterprise software. It is not a trivial task to build an EHR and it is not a trivial task to assemble one from prebuilt modules either. There is very little fault tolerance. EHRs can improve efficiency and quality of care, if done right, but they can also harm patients if done wrong.
While I can see patients, or consumers, assembling on the fly iGoogle pages with various widgets to help maintain wellness and mange health, I cannot envision the same ability for a hospital responsible for millions of patient records, hundreds of integrated electronic devices, thousands of staff members and several hundreds of human lives, at any given moment. For them the EHR is Mission Critical Software, and that requires a much different standard than iGoogle.

EHR Certification - Should CCHIT be "it"?

I posted this comment a couple of days ago on the ONC blog here. They finally moderated the comment and posted it this morning, so here it is again. I will have more on the ONC NPRM later....

*****

OK, I can’t believe I’m typing this, but I am.
As anybody that reads things I write, or listens to things I say, knows, I had lots of isrues with the way CCHIT operated in the past and the effects it had on the EHR industry. However, currently CCHIT has a complete certification infrastructure in place ready to service both comprehensive EHRs and EHR modules immediately. No other organization is even remotely close to such capabilities.
I do believe your long term accreditation plan is good and much needed.
However, I would like to suggest that the entire temporary certification program needs to be scratched and that CCHIT be awarded ONC-ATCB status so certification processes can begin now. I don’t really see the value of engaging in a formal lengthy process just to create temporary bodies of certification. I also don’t see how submitting a bunch of forms and documentation to ONC and taking a quiz can provide assurance to both vendors and physicians that these newly accredited temporary bodies really know what they are doing, considering they have never tested an EHR before.
I believe ONC is underestimating the complexity of certification and the infrastructure required for a successful program, even a temporary one. Please remember that if all goes well, there will be a tremendous wave of adoption in the coming year and it will all be done under temporary certification bodies. In order to sustain future expansion of HIT, it is imperative that physicians have a good experience in 2010-2011.
I can easily envision horror stories, particularly regarding EHR modules, created by small underfunded vendors, getting temporary certification and providing nothing but disappointment and financial loss to customers.
In the engineering world, reinventing the wheel is not considered a worthy endeavor. CCHIT is there. It is experienced. It is up to date in it’s infrastructure and readiness. It has created a pared down ARRA certification and kept up with all ONC/CMS changes.
So why not let CCHIT start working on a temporary basis, while ONC begins the long term accreditation process for all applicants? Wouldn’t it serve the market and all our goals better?
It’s the simplest, cheapest, fastest and least risky solution and it’s the right thing to do.

The Advent of EHR Modules

Today, I decided to take the plunge and post on my very own, brand new blog. So let's start with something equally new and rather interesting. Certified EHR Modules.

******

With an eye to encouraging innovation by new entrants to the EHR market, ONC has introduced the notion of certifying not just comprehensive, or monolithic EHR products, but also various smaller pieces of software that can show capability of facilitating at least one of ONC's many Meaningful Use criteria.
Before the advent of HITECH, when CCHIT was the sole certifying body for EHRs, an EHR would either be certified for 100% of the CCHIT defined functionalities, or not be certified at all. That did not mean that an EHR was necessarily built by a single vendor, but it was the vendor's responsibility to assemble all the pieces together into one comprehensive solution for certification, marketing, sales and support purposes.
Leaving aside the merits, or lack thereof, associated with CCHIT certification, physicians looking to purchase an EHR had a very simple choice before them: buy a CCHIT certified EHR guaranteed to have a long list of features, or buy a non-certified solution, in which case it's caveat emptor.
Under the new ONC IFR, a third option is added. A physician can now also purchase a bunch of Certified pieces of EHR and assemble them together in his/her office. The ONC is explicitly placing the burden of such assembly (integration) on the purchasing physician.

The change may appear subtle to some, but it is not an insignificant change. While in the past it was the vendor's responsibility to integrate all pieces prior to presenting a solution to the market, it is now the customer's responsibility to perform the integration. CCHIT, which is currently the only active certifying body and may not remain so for very long, has identified 25 possible standalone modules that could be certified under ONC's definition of an EHR module. Theoretically speaking, a practice, or hospital, could be talked into purchasing 25 products from 25 different vendors in an attempt to achieve Meaningful Use.

For illustration purposes, let's look at a rather simplistic example. One of the possible modules would be a piece of software (or service) that has the ability to record and maintain patient problem lists using ICD9 or SNOMED CT terminology. Let's imagine that I buy this module from Vendor X who has the cheapest price and a very nice user interface and uses a lovely SNOMED CT encoding scheme. I take my new module home and try to fulfill my responsibility to integrate my new bargain with my existing spiffy web based lab ordering module from Vendor Y, which I got for free from my Lab vendor. Hmm, how do I do that? Let's take another leap of faith and assume that both vendors provide some instructions on setup. I set it all up and everything looks good. I now try to order a lab and to my dismay, after multiple failed attempts and several calls to both Vendor X and Vendor Y, I realize that my Lab ordering module only supports ICD9 and I have my problem list  in SNOMED CT. Not going to work. Do I get a refund? Not really, because the problem list module was indeed ARRA certified, and so was my lab ordering module. Certification does not include assurances of integration with other vendors.

Here is another tidbit of information gleaned from many years of systems integration. Unless the integrated system is thoroughly tested, it is possible to have integration looking very good on the surface, while data integrity is consistently compromised (overwritten, deleted, lost) behind the scenes. This of course is a potential patient safety issue.

If the above example looks complex, just imagine the possible combinations when there are 25 pieces that can be combined together in all sorts of fashions.
Also, if there are several hundred of comprehensive EHR products on the market today, how many module vendors will be sprouting up at very short order, considering that it takes only a few weeks of programming to create a module, compared to a few years of programming to create a full EHR?
If physicians have difficulties sifting through EHRs today as they are being bombarded by marketers with Meaningful Use guarantees, how would they navigate the thousands of "Certified" modules?
Are we setting the average physician, in the average practice, up for failure?
Are we about to expose physicians to an emerging "aggressive" marketing environment that will be spinning out of control as we get closer to the Meaningful Use implementation deadlines?
What will the repercussions be?

I wrote this article as I listened to the public meeting of the ONC Standards Committee and I was very encouraged to hear various members raising questions regarding certification of modules. Obviously they are perceiving some difficulty there, particularly regarding security and standards of communications. I am very hopeful that through continued deliberations, the committees will eventually reach a solution favorable to physicians.

Does that mean that we should shy away from modular innovation in HIT? Not at all. It is important to allow small and new vendors to enter the market with new products and new ideas. However, the incorporation of such ideas into a final "EHR solution" should not be delegated to the physician buyer. EHR modules should be integrated by vendors and presented to both certifying bodies and physician buyers as a complete, thoroughly tested and guaranteed solution. The average physician needs to have assurances that whatever he/she is buying will actually work, and at the very least, will not harm patients.