The Era of Epic


In the Boston marketplace, Partners Healthcare is is replacing 30 years of self developed software with Epic.   Boston Medical Center is replacing Eclipsys (Allscripts) with Epic.   Lahey Clinic is replacing Meditech/Allscripts with Epic.  Cambridge Health Alliance and Atrius already run Epic.   Rumors abound that others are in Eastern Massachusetts are considering Epic.  Why has Epic gained such momentum over the past few years?   Watching the implementations around me, here are a few observations

1.  Epic sells software, but more importantly it has perfected a methodology to gain clinician buy in to adopt a single configuration of a single product.   Although there are a few clinician CIOs, most IT senior management teams have difficulty motivating clinicians to standardize work.  Epic's project methodology establishes the governance, the processes, and the staffing to accomplish what many administrations cannot do on their own.

2.  Epic eases the burden of demand management.   Every day, clinicians ask me for innovations because they know our self-built, cloud hosted, mobile friendly core clinical systems are limited only by our imagination.   Further, they know that we integrate department specific niche applications very well, so best of breed or best of suite is still a possibility. Demand for automation is infinite but supply is always limited.   My governance committees balance requests with scope, time, and resources.   It takes a great deal of effort and political capital.   With Epic, demand is more easily managed by noting that desired features and functions depend on Epic's release schedule.   It's not under IT control.  

3.  It's a safe bet for Meaningful Use Stage 2.   Epic has a strong track record of providing products and the change management required to help hospital and professionals achieve meaningful use.  There's no meaningful use certification or meaningful use related product functionality risk.

4.  No one got fired by buying Epic.   At the moment, buying Epic is the popular thing to do.   Just as the axiom of purchasing agents made IBM a safe selection,   the brand awareness of Epic has made it a safe choice for hospital senior management.   It does rely on 1990's era client server technology delivered via terminal services that require significant staffing to support, but purchasers overlook this fact because Epic is seen in some markets as a competitive advantage to attract and retain doctors.

5.  Most significantly, the industry pendulum has swung from best of breed/deep clinical functionality to the need for integration.   Certainly Epic has many features and overall is a good product.   It has few competitors, although Meditech and Cerner may provide a lower total cost of ownership which can be a deciding factor for some customers.   There are niche products that provide superior features for a department or specific workflow.   However,  many hospital senior managers see that Accountable Care/global capitated risk depends upon maintaining continuous wellness not  treating episodic illness, so a fully integrated record for all aspects of a patient care at all sites seems desirable.  In my experience, hospitals are now willing to give up functionality so that they can achieve the integration they believe is needed for care management and population health.

Beth Israel Deaconess builds and buys systems. I continue to believe that clinicians building core components of EHRs for clinicians using a cloud-hosted, thin client, mobile friendly, highly interoperable approach offers lower cost, faster innovation, and strategic advantage to BIDMC.  We may be the last shop in healthcare building our own software and it's one of those unique aspects of our culture that makes BIDMC so appealing.

The next few years will be interesting to watch.   Will a competitor to Epic emerge with agile, cloud hosted, thin client features such as Athenahealth?   Will Epic's total cost of ownership become an issue for struggling hospitals?   Will the fact that Epic uses Visual Basic and has been slow to adopt mobile and web-based approaches provide to be a liability?

Or alternatively, will BIDMC and Children's hospital be the last academic medical centers in Eastern Massachusetts that have not replaced their entire application suite with Epic?   There's a famous scene at the end of the classic film Invasion of the Body Snatchers, which depicts the last holdout from the alien invasion becoming a pod person himself.  At times, in the era of Epic, I feel that screams to join the Epic bandwagon are directed at me.

Image Exchange

Last week, the Clinical Operations Workgroup of the HIT Standards Committee held its third hearing on image exchange, seeking testimony from Hamid Tabatabaie, CEO of LifeImage and Michael Baglio, CTO of LifeImage.

He made several important points
1.  We should think of image exchange as having two major categories - local and long distance.    DICOM works well for modality to PACS connectivity within an enterprise (local).   DICOM was never designed for internet-based cross organizational image sharing.   DICOM images tend to be large, including a vast amount of metadata with every image object in a study.    DICOM was also never designed to work well with the kind of firewalls, load balancers, and network security appliances we have today.

2.  Two image exchange architectures have been used in the marketplace to date, which Hamid called "iTunes" and "Napster",  classifications first suggested by Dr. Keith Dreyer.

iTunes refers to the centralization of images into a single repository or what a appears to be single repository - it may actually be a clearinghouse to other image stores, but the user never knows that.   Query/response transactions against this central repository can be straightforward, using standards such as Blue Button Plus/Direct for share, access, download.

Napster refers to a decentralized, federated model in which images are not placed in a single repository -    an index of images and their location is all that is centralized.   Typically, query/response is done with standards such as XDS-i.   XDS itself was never designed for image exchange and is incomplete.  It can be challenging to search for a single exam on a known date of a known modality type.

3. Current standards do not include any privacy metadata and security is not built in.  Future standards should enable applications to restrict image flows based on consent/patient preferences.

4.  We need a web friendly method for visualization that does not require the download of a proprietary viewer, one that is often operating system specific.   Consumers should be able to view thumbnails of images on a smartphone, tablet, or the device of their choosing without special software.   If the full DICOM object is needed (patient mediated provider to provider image exchange), download and transmission should be enabled using standards such as REST, OAUTH2/OpenID, and secure email.

5.  Hamid made a forward looking statement that should be carefully considered as we plan the lifecycle of existing Radiology Information Systems (RIS) and Picture Archiving and Communication Systems (PACS) systems.   He is seeing EHR features expand to cover many aspects of RIS workflow.   If scheduling, image viewing, report construction with templates/front end voice recognition, and easy exchange of reports with clinicians are supported by the EHR, maybe radiologists (some of which want to qualify for meaningful use payments) will start using increasingly capable EHRs instead of RIS.   Vendor neutral archives (VNA) which store images of all "-ologies"  and enable easy search and retrieval may replace PACS.   Imagine 5 to 10 years from now when RIS/PACS no longer exists and is replaced by EHR, HIE,  and VNA.   Interesting possibility.


Great testimony.    In the past when I've suggested DICOM is not ideal for internet-based multi-organizational exchange, I've been criticized.   In the past when I've suggested that DICOM has issues of vendor-specific proprietary metadata extensions, cumbersome viewers, and heavy payloads, I've been challenged.   It's refreshing to hear from someone doing the hard work of high volume image sharing that current standards not ideal.  We need new approaches to move payloads efficiently on the internet, view images via web-browsers, facilitate easy searching, support security, and enable multiple provider/patient/group sharing use cases.

Building Unity Farm - The Barn Swallows of Unity Farm


One of the side effects of creating the orchard at Unity farm was opening about 2 acres of airspace adjacent to our pasture.  This has attracted  many new species of birds which now dance and dive in the clearing between our woodland and marsh.   Since adding the orchard we've seen a significant increase in our barn swallow population.  Throughout the day, at least 5 adults dash at high speed around their own open air playground, eating mosquitos and enjoying their social community of birds.

Our barn has two sliding doors which open to the male and female paddocks.  The swallows retreat to the barn for shelter at night and during the rain.   Recently a mating pair built a nest on top of a porcelain light socket.   We use LED lightbulbs in the barn, so the socket does not get hot.   The nest is a delicate combination of mud, sticks, great pyrenees fur, and feathers from our chickens/guinea fowl, pictured above.

This week, 4 swallow babies are fledging.  Two are pictured below balanced on a barn door rail.   Watching the parents feed them for the past several weeks, I've read a great deal about swallows and can now answer some lifelong questions I've had since 1975, when King Arthur first had a dialog about swallows with the guardian of the bridge.


1.  Are the swallows of Unity Farm considered European or African?

European swallows are migratory and are widespread throughout the Northern Hemisphere.   African swallows are non-migratory and are typically found in in Botswana, Republic of the Congo, Democratic Republic of the Congo, Gabon, Lesotho, Malawi, Namibia, South Africa, Zambia, and Zimbabwe.    Thus, if asked, you can definitively answer that the barn swallows of Unity Farm are European.

2.  Much of the day the adult swallows gather insects to feed to their young.  I've watched them busily carrying food and nesting materials as the cruise through the paddocks and into the barn.     When they're done feeding their babies and reinforcing the nest, they fly above the paddock turning and twisting at high speed before deftly returning to the barn.   Watching them makes me wonder - just how fast do they fly when unencumbered i.e. What is the airspeed velocity of an unladen swallow (European)?

Luckily much research has been done on this topic.


A 54-year survey of 26,285 European Swallows captured and released by the Avian Demography Unit of the University of Capetown finds that the average adult European swallow has a wing length of 12.2 cm and a body mass of 20.3 grams.

European Swallow flies at cruising speed with a frequency of roughly 15 beats per second, and an amplitude of roughly 22 cm.   However, some other researchers have measured a lower frequency of 7-9 beats per second among some swallows.

Because wing beat frequency and wing amplitude both scale with body mass and flight kinematic data is available,  we can  estimate airspeed (U).

Graham K. Taylor et al. show that as a rule of thumb, the speed of a flying animal is roughly 3 times frequency times amplitude (U ≈ 3fA).

Based on wing beats per minute, body mass, and amplitude, the answer for our swallows appears to be 24 miles per hour (11 meters per second).   So if on your quest to visit Unity farm, you are asked the airspeed velocity of an unladen swallow (European), you know the answer!



The July HIT Standards Committee


The July HIT Standards Committee included a robust discussion of Benefits and Formulary standards, a brief overview of our work on image exchange thus far, preparations for the July 23 HITSC Implementation Workgroup and HITPC Meaningful Use and Certification and Adoption Workgroup joint hearing on Implementation and Usability, an overview of ONC S&I Framework activities, and a discussion of the CMS electronic submission of medical documentation planning.

We started the meeting with a presentation from Kim Nolen and John Klimek reviewing the final recommendations for enhanced formulary and benefit standards.   While short term incremental improvements are important, the committee was more focused on the Stage 3 trajectory for formulary and benefits transactions.   Ultimately, the committee made 5 recommendations

1. We endorse the adoption of RxNorm as the preferred medication substance vocabulary in formulary and benefits transactions
2. We support standardizing content on NCPDP Formulary and Benefits version 3.0 to simplify current batch formulary import implementations in the short term but prefer the certification criteria for stage 3 focus on the real time transactions described in recommendation #5
3. We recommend that batch formulary transport standards move from FTP to Direct/XDR to align better with existing Meaningful Use transport standards
4. We recommend that patient matching to pharmacy benefits utilize PCN/BIN/Group Number to more accurately reflect the benefits of the patient's plan.
5. ONC should facilitate development of national standards for real time lookup of patient specific drug/dose benefits by prescribers at the point of care including estimated patient out of pocket cost at the time of the prescription order.

Also, I provided this image exchange update.  We will continue our hearings with more expert testimony this Friday.

Next we heard from Liz Johnson and Cris Ross about their planned July 23 implementation and usability hearing.   Their group has prepared great questions for its four panels - Eligible Professionals, Eligible Hospitals, Health Information Exchange/Interoperability, and Usability

Doug Fridsma provided a comprehensive update about the S&I framework activities, identifying all the current and planned deliverables for the many groups working on these important future looking projects.   Especially interesting was the data accress framework project which incorporates many of the previous point solution projects like QueryHealth and targeted query ("pull" of medical records from multiple sources).

Jodi Daniel offered this ONC Policy and Program Update focusing on the Health IT Patient Safety Action & 
Surveillance Plan.

Finally Melanie Combs-Dyer from CMS and Bob Dieterle presented the roadmap for fully electronic closed loop CMS medical documentation submission to support medical review by Medicare Administrative Contractors (MACs), Medical Review (MR) Departments,
Comprehensive Error Rate Testing Contractor (CERT), Payment Error Rate Measurement Contractor (PERM), and Medicare Recovery Auditors (formerly called RACs).   The digital signature provisions which provide provenance and integrity protections generated the most discussions and these will be reviewed by the HITSC Privacy and Security Workgroup and Clinical Operations Workgroup.

In my introductory remarks to the meeting, I stressed the importance of focusing our standards work on those items which will support the hard work of hospitals and professionals to achieve all phases of meaningful use, ICD-10, Accountable Care, and compliance/regulatory mandates.   Formulary support, image sharing, "pull" based health information exchange,  ensuring are EHRs are safe, and supporting Medicare review workflows definite fall into that category.

As the meeting closed, we thanked MacKenzie Robertson for her work as our FACA facilitator.   She will be replaced by Michelle Consolazio.


The Healthcare IT Applications of Google Glass


Last week I had the opportunity to test Google Glass.  

It's basically an Android smartphone (without the cellular transmitter) capable of running Android apps, built into a pair of glasses.  The small prism "screen" displays video at half HD resolution.  The sound features use bone conduction, so only the wearer can hear audio output.   It has a motion sensitive accelerometer for gestural commands.    It has a microphone to support voice commands.   The right temple is a touch pad.  It has WiFi and Bluetooth.   Battery power lasts about a day per charge.

Of course, there have been parodies of the user experience but I believe that clinicians can successfully use Google Glass to improve quality, safety, and efficiency in a manner that is less bothersome to the patients than a clinician staring at a keyboard.

Here are few examples

1.  Meaningful Use Stage 2 for Hospitals - Electronic Medication Admission Records must include the use of "assistive technology" to ensure the right dose of the right medication is given via the right route to the right patient at the right time.   Today, many hospitals unit dose bar code every medication - a painful process.   Imagine instead that a nurse puts on a pair of glasses, walks in the room and wi-fi geolocation shows the nurse a picture of the patient in the room who should be receiving medications.  Then, pictures of the medications will be shown one at a time.  The temple touch user interface could be used to scroll through medication pictures and even indicate that they were administered.

2.  Clinical documentation - All of us are trying hard to document the clinical encounter using templates, macros, voice recognition, natural language processing and clinical documentation improvement tools.     However, our documentation models may misalign with the ways patients communicate and doctors conceptualize medical information per Ross Koppel's excellent JAMIA article.  Maybe the best clinical documentation is real time video of the patient encounter, captured from the vantage point of the clinician's Google Glass.   Every audio/visual cue that the clinician sees and hears will be faithfully recorded.

3.  Emergency Department Dashboards - Emergency physicians work in a high stress, fast paced environment and must be able to quickly access information, filtering relevant information and making evidence-based decisions.    Imagine that a clinician enters the room of a patient - instead of reaching for a keyboard or even an iPad, the clinician looks at the patient.   In "tricorder" like fashion, vital signs, triage details, and nursing documentation appear in the Google Glass.   Touching the temple brings up lab and radiology results.  An entire ED Dashboard is easily reduced to visual cues in Google Glass.    At BIDMC, we hope to pilot such an application this year.

4.  Decision Support - All clinicians involved in resuscitation know the stress of memorizing all the ACLS "code" algorithms.   Imagine that a clinician responding to a cardiac arrest uses Google glass to retrieve the appropriate decision support for the patient in question and visually sees a decision tree that incorporates optimal doses of medications, the EKG of the patient, and vital signs.  

5.  Alerts and Reminders  -  Clinicians are very busy people.   They have to manage communications from email, phone calls, patients on their schedule, patients who need to be seen emergently, and data flowing from numerous clinical systems.   They key to surviving the day is to transform data into information, knowledge and wisdom.   Imagine that Google Glass displays those events and issues which are most critical, requiring action today (alerts) and those issues which are generally good for the wellness of the patient (reminders).    Having the benefits of alerts and reminders enables a clinician to get done what is most important.

Just as the iPad has become the chosen form factor for clinicians today, I can definitely see a day when computing devices are more integrated into the clothing or body of the clinician.    My experience with Google Glass helps me understand why Apple just hired the CEO of Yves Saint Laurent to work on special projects.  

Ten years ago, no one could imagine a world in which everyone walked around carrying a smartphone.   Although Google Glass may make the wearer appear a bit Borg-like, it's highly likely that computing built into the items we wear will seem entirely normal soon.

I will report back on our Google Glass experiments as they unfold.