Thursday, February 28, 2008

Cool Technology of the Week





Upload your records
Make an Appointment
Securely Email your Clinicians





Tuesday, February 26, 2008

How to be a Bad CIO


1. Start each meeting with a chip on your shoulder

2. Bypass governance processes and set priorities yourself


4. Put yourself first

5. Use mutually assured destruction negotiating tactics

6. Hide your mistakes/undercommunicate

7. Burn Bridges

8. Don't give your stakeholders a voice

9. Embrace obsolete technologies

10. Think inside the box


Dispatch from HIMSS













A great gathering with 25,000 of my closest friends!

Saturday, February 23, 2008

Electronic Health Records for Non-owned doctors - Managing the project





Third Brigade



Scanning Technologies

One of the great things about writing a blog is that I can share my experiences so that other CIOs can avoid mistakes I've made. Over the past 5 years, I'm made several mistakes - not understanding network technology enough to prevent our 2002 network outage, underestimating the popularity of voice recognition dictation systems, and believing that users would migrate to our new intranet site purely based on the advanced technology we implemented. One area where I need to formally state I was wrong is scanning technologies. I have never liked scanned images of medical records. They are not interoperable, they are challenging to store, and they are difficult to navigate because they are not searchable. However, I have recently found a few use cases for scanning technology that have proven me wrong.

1. Inpatient records
Although BIDMC's outpatient records are entirely electronic, our inpatient progress notes, nursing notes,and Input/Output records are still paper-based. In 2008, we're creating electronic History and Physicals that will serve as the foundation for future work on inpatient clinical documentation, but in the meantime we need to make our paper records available electronically for several reasons. Hiring and retaining medical record coders is challenging in the Boston area. If we can make scans of our inpatient records available electronically via a secure web-application, we can hire medical record coders anywhere in the country. Additionally, real estate in the Longwood Medical Area of Boston is very expensive. Storing paper records nearby is just too expensive, so we built a storage facility in Dedham 15 miles away. Retrieving a chart from the storage facility can take a few hours. Having an electronic version of paper records saves time, storage space and energy.

2. Doctor's doodles, outside labs and lab requisitions
In some clinics, doctors make drawings of skin lesions and physical exam findings. Our ambulatory medical record does not include real time graphical input via Wacom tablets or other electronic drawing devices. Hence we need some way to include these doodles as part of the electronic record. Creating a drawing, then bar coding it, makes automated scanning into the right patient's record possible. Also, every day we receive 15 inches of paper from referring clinicians and outside providers. Today, that's all filed in a paper chart. Scanning paper received from outside providers and making it available within our ambulatory record ensures continuity of care. Finally, we receive paper-based lab requisitions from clinicians who want to order BIDMC labs but are not using our electronic health records or provider order entry system. Although we do not consider these requisitions part of the medical record, the lab needs to retain them as proof that the specified tests were performed on the basis of a signed order. Scanning them eliminates the need to store paper and makes retrieving them for audits much easier.

3. Consent workflow
Although we've experimented with automating the consent process, we've found that most consents are done in private clinician offices where we have no control of the technology or workflow. By scanning these paper consents into the record and making them available as part of peri-anesthesia testing, we ensure that all documentation necessary for a successful surgery is available before the patient arrives at the Operating Room.

We're now live with scanning our lab requisitions and inpatient records. We will soon go live with scanning doctor's drawings and outside labs. Consent scanning is planned for next year. The technology we use includes Fujitsu high speed scanners and Captiva image capture software. Our Health Information Management professionals scan any written documentation in the paper record and generate a PDF for each tab in the record, making the electronic version easy to navigate. We've created an automated link to a web-based viewer (screen shot above) that associates the scanned records with the right patient based on a bar code included on the first page of each scan that is optically recognized by Captiva. We've made these scans available to our medical record coders working at home. Homesourcing saves time, reduces real estate costs, and enhances productivity. It's a win/win.

Thus, scanning technology with automated creation of PDFs and web-based viewing organized by document type does work very well during the transition from paper to natively electronic workflows. I stand corrected.

Tuesday, February 19, 2008

Cool Technology of the Week

Storage backup and data recovery is at the top of my list of things that will keep me awake in 2008. In healthcare IT, we need short recovery times with minimal or no data loss. Accomplishing this with once-a-day tape backups is not possible. The Cool Technology of the Week, Data Domain de-duplication storage, solves this problem.

At BIDMC, we generate 28 terabytes of new file and email storage each year. Basic file stores have grown so large that we struggle to copy them within our 24 hour backup window. Additionally, our disaster recovery efforts now require us to replicate our data across two geographic locations.

Tape backup, which has been in use at BIDMC for decades, suffers from a variety of problems. Tape backups are time-consuming. Tapes are fragile and require physical security when transported. The time required to retrieve and recover from tape stresses our service availability objectives. In years past, we considered backup to disk, but the economics did not work. Data Domain de-duplication now makes disk an economical backup media. Here's how.

Instead of making full tape backups, we can backup changes on a sub-block level to disk then compress the result. There is an important distinction between a tape-based, incremental backup and de-duplication. With incremental backups, files that changed since the last backup are copied. A major problem with this approach is that each incremental backup must be recalled in sequence to recover files. This is a slow and complex process that does not detect if the same file was stored in several locations.

De-duplication, on the other hand, has sophisticated methods for identifying changes at the sub-block level. For example, if a spreadsheet has '&date' in the heading, each time you save it, the date in the title will change. An incremental backup will copy the whole document again. De-duplication at the sub-block level will only copy the date change. If multiple copies of the file are sent in email, it will only save one copy.

Over a two year period we examined many products from many companies. Most of them required proprietary hardware, specialized software, new management tools, training, and multiple staff to support the technology 24x7x365. We believe in information life cycle management/hierarchical storage management, but want one set of tools and compliance with the technology standards already in use in our data center. We chose Data Domain because:
  • The product de-duplicates at the sub-block level yielding better reduction ratios
  • The product looks like regular storage supporting NFS and CIFS file mounts
  • The product requires little training since it's completely managed by Data Domain
  • The product is an in-line appliance and does not require installation of server agents
  • The product works with all our existing backup software
  • The product is highly reliable, using RAID 6 SATA drives and built in hardware redundancy
In our pilot, Data Domain averaged 1:20 compression. It worked well with our existing backup software which made the transition from tape to disk easy. We're deploying 15 terabytes of Data Domain disk storage in our production and backup data centers, replicating data between the two over our a private Ethernet link. Through the use of de-duplication and compression, 15 terabytes will hold the equivalent of 300 terabytes in tape storage. Our goal over the next two years is to completely eliminate the need for tape in the data center.

We're so impressed with Data Domain's performance as a backup infrastructure that we're also planning to use it as an archival tool for less frequently accessed files. To do so, we'll first implement file virtualization technology such as Acopia or Rainfinity. This will enable us to move content from one storage medium to another without impacting file shares, our web-based file access tools, or our SSLVPN remote file access applications. The combination of file virtualization and Data Domain will enable us to support three tiers of storage.

Tier 1 - SAN storage with lower density, high performance drives.
Tier 2 - SAN or NAS storage with high density, low performance drives.
Tier 3 – NAS-based, archival storage with high density drives coupled with Data Domain de-duplication and compression.

With these 3 tiers of storage, we'll reduce our cost of information life cycle management while reducing complexity.

After a 2 year journey exploring backup, recovery, and archiving solutions, I feel we've finally found the answer that will let me sleep at night in 2008.

Media Services in a Web 2.0 World


1. What is our video teleconferencing strategy?








3. What is our video streaming strategy?



4. What is our podcasting strategy?


5. What is our new media strategy?


6. What's the right mix of services to provide?


7. What media services do patients expect?


8. What should we insource and what should we outsource?




10. How do we optimize management of team?



Performance Measurement

A few weeks ago, I was asked to describe the way we do performance measurement at BIDMC.

Our strategy is simple - all our clinical systems are built on hierarchical databases and our decision support databases are relational, updated by nightly extracts of our clinical systems.

Clinical data is inherently hierarchical - patients have many visits, with many labs, with many observations. This creates a tree of data - a hierarchy that does not fit nicely into columns and rows. Doctors typically ask questions about individual patients, such as their most current results. Retrieving data the way it is stored, hierarchically, is blazingly fast. We retrieve patient specific date from terabytes of historical information in milliseconds.

Hierarchical data is great for clinical care, but not so wonderful for decision support. Asking a question such as "how many patients in the past 10 years have had a creatinine of 2.0 and a Hemoglobin A1c greater than 9.0" would require that every lab result ever done be examined one at a time.

For population health and performance measurement, querying an indexed relational database that is optimized for reporting makes the most sense. To enable this, we've created numerous data marts based on nightly extracts of our clinical and financial systems. Our current data marts include admissions, ED, outpatient appointments, OR, laboratory, microbiology, blood bank, radiology, cardiology procedures, inpatient pharmacy, outpatient medications, billing and payroll.

We use these data marts for 3 kinds of queries:

1. Expert analysis using relational query tools such as SAS, Access, and SQL Reporting services. We have a team of decision support professionals reporting to the CFO and a team of dedicated IS analysts performing these queries. Creating such queries requires an understanding of the quality of the underlying data, its source, and its meaning. Years ago, I hired a new analyst who noted that the average length of stay in the operating room was 120 days. The person did not know that the length of stay in ORs is measured in minutes

2. Parameterized web-based reports that can be run by anyone. When a new report has been developed by an analyst and is ready for broader distribution, we go through a process to make it available via our web-based Performance Manager tool. This typically involves developing result rollups to enhance performance, writing parameterized stored procedures, and developing a web page interface that allows users to select parameters via dropdowns and checkboxes and to easily navigate drilldowns and trending. Performance manager has over 150 web-based reports which allow untrained users to create accurate reports and explore results at the touch of a button. Reports include financial performance (discharged not final billed, ED and inpatient volumes, gross patient services revenue by cost center), clinical performance (antibiotic resistance and sensitivity, ED throughput) and even IS uptime.

3. Self service queries via a drag and drop tool. In 2008, we're launching a graphical tool which enables user defined queries of our datamarts for clinical research. This tool will returns counts of patients that can be used for pre-research investigation such as ensuring enough data is available to conduct an actual study. IRB approval would be required for any more detailed information. The drag and drop interface includes enough metadata to limit the queries to those data elements which make logical sense, building in the expertise of our analysts but allowing untrained researchers to do patient de-identified data mining, protecting patient confidentiality.

Using these three methods, we provide the data needed to empower our quality reviews, our process improvement efforts, and clinical research. Of course, we do not sell data or ever release data to third parties without patient consent. All our secondary uses of data are reviewed by our privacy officer, our IRB, and our security professionals. In this way, we ensure that all data in our enterprise is used on a need to know basis, following HIPAA to the letter of the law.

Monday, February 18, 2008





The alternatives we considered for serving these geographically distributed users was





Here's our thinking







Provider Order Entry

Last week, I served on a panel to discuss the Massachusetts Technology Collaborative's release of its study about the benefits of Computerized Provider Order Entry (CPOE).

The study concluded that one in every 10 patients admitted to six Massachusetts community hospitals suffered serious and avoidable medication mistakes. This has created a new urgency for all hospitals in the state to install CPOE.

At BIDMC, we implemented CPOE in 2001 and have not had a handwritten order in most areas (we are just launching inpatient chemotherapy POE, planning NICU POE and discussing prep-Op holding area POE since these have very specialized workflows) , except for the 2 days of our network outage in 2002. Implementing CPOE is challenging and requires significant planning to do it right. Here's my top 10 lessons leanred about CPOE implementation based on 7 years of doing it.

1. Bad software, implemented badly, can cause bad results

You're probably familiar with the Cedars Sinai CPOE rollout failure and the Pediatrics article linking CPOE to increased mortality.

These studies are not about the failure of CPOE, they are about the failure to deliver software that meets clinician needs. Clinicians need easy to use, intuitive software that enhances their workflow. In the case of Cedars, the software was slow and cumbersome. The workflow was so confusing that nurses did not know when when orders were placed and asked doctors to place orders multiple times. In the case of the Pediatrics article, the software was archaic and challenging for physicians to use correctly. At BIDMC, we took a lesson from If you can order a DVD in one click, why should a renal dosed antibiotic, heparin or insulin be any different? We engineered a quick picks system that enables a doctor to click on a drug name, then have it dosed, interaction checked and routed to the pharmacy in one click. Pick the right patient from a dashboard, click the drug name, done. We've not seen any errors using web-based, intuitive software that automates a logical workflow.

2. CPOE is a platform not a product

Shortly after going live with CPOE, we established the Provider Order Entry Triage Committee (POET), to prioritize new development. Everyday we're asked to add new features that support new workflow, clinical resource management, research, and compliance requirements. Every change must be analyzed for its impact on clinicians. For example, if a new clinical trial requires that we capture the hair color of every patient on every order, we'll add hundreds of keystrokes to every provider's day. The POET committee ensures the right balance between safety, compliance, functionality, and clinician impact. Assume that your CPOE system will be very dynamic, with continuous revision of the decision support rules. CPOE Governance committees can

- Manage clinician expectations regarding their suggested changes to programs and the availability of resources to make the changes.

- Work with a clinical practice committee so that the CPOE committee does not bog down in adjudicating clinical issues, or creating a fix for one group of docs, only to find that another stakeholder group does not agree.

- Consider human factors to insure the learned responses hold true across applications-- e.g., if there is renal dose adjustment for one type of drug, does the adjustment happen for all renally excreted drugs?

- Anticipate and build in reports from POE-- topic, questions and recipient of report. Our data from the transfusion screen was extremely powerful for the Transfusion Committee to improve practice because we were able to capture overrides in monthly reports and target education where appropriate.

3. Clinicians will not go to training

Clinicians are time bankrupt. Requiring them to go to a half day CPOE training will cause resentment and will not result in much knowledge retention. The right way to train clinicians is in the field as they are using the system. When we rolled out CPOE, we staffed our nursing stations with roving IT professionals 24x7 for 6 weeks. As doctors entered orders, these trainers were available to help them with real patients, resulting in a successful first time ordering experience. You only have one chance to make a good first impression and having trainers elbow to elbow with clinicians is the best way to achieve a positive outcome.

4. Doctors will feel a loss of autonomy

Experienced clinicians note that medicine is art and science. Cookbook medicine which follows strict guidelines may not be personalized care. During implementation, some clinicians will feel a loss of autonomy as protocols, care paths and order sets replace handwritten orders. Our experience is that 85% of orders suggested by CPOE are accepted by clinicians without revision. Once clinicians realize they can create customized pick lists and that the computer provides value added decision support, the feelings of loss of autonomy disappear. It's important that the decision support be tuned just right - having thousands of rules that warn physicians about every potential minor side effect will cause 'cry wolf syndrome' - doctors will ignore the decision support. Having too few rules will make the doctors question the value add of the system. In our case, we've used a few hundred rules that seem to strike an appropriate balance.

5. Big Bang IT never works

Going live with CPOE across an entire hospital in one day would be a nightmare. The degree of training, communication and management of workflow change really requires a phased rollout. We picked logical clusters of related units to implement together i.e. medicine floors, surgical wards, related specialty floors, ICUs, the ED etc. This worked well because our staff could be present to train clinicians real time, coordinate additional hardware rollouts where needed to enhance workflow, and ensure any software issues were resolved rapidly. It did create some inconvenience during the transition. If a patient was transfered from a medicine service (on CPOE) to an Ortho service (not on CPOE) and back, the interns on the teams had to move the patient from electronic to paper to electronic workflows. This was a small price to pay for the 100% clinician acceptance of CPOE we achieved through a phased rollout.

6. CPOE must be a system created by the clinicians, not inflicted on them

One of the major problems with the Cedars Sinai rollout was that the administration created the software and then forced doctors to use it. Even worse, the administration planned to resell the software once the doctors had worked the bugs out. The doctors revolted and refused to use the system, which was perceived as a moneymaker for administrators. At BIDMC, we engaged key thought leaders from the medical executive committee, nursing, pharmacy, social work, lab, and radiology in the design of the system, so it was perceived as the clinician's system, not administration's system. When it went live, many doctors were eager to show off 'their system'. The Medical Executive Committee even voted to require use of the system as part of hospital practice, since it was widely perceived as improving safety without burdening the clinicians.

7. Many CPOE systems are a toolkit without rules




9. Infrastructure must be reliable

Before CPOE, we could schedule downtimes on Sundays between 2am-4am for maintenance. After CPOE, no downtime is acceptable, since downtime implies that orders for medications, labs, radiology, transfer etc. cannot be placed. We've implemented redundant networks, redundant servers, clustered databases and even redundant data centers to ensure CPOE is available 24x7x365. A note to CIOs - implementing CPOE means that you'll now be carrying a pager to ensure real time response to any interruption of service.

10. Automating a bad process does not improve anything


Our experience with CPOE over the past 7 years is that it has reduced medication error by 50%, it paid for itself within 2 years, and clinicians have embraced it. In 2008-2009 we're completing the bar coding for all our unit dose medications (including repackaging every dose of Tylenol in bar coded baggies) so we can scan the patient wrist band, scan the medication, and scan the nurse, achieving a completely automated medication administration record. Once this is complete, the last causes of medication error will be removed from our hospital and we hope to achieve a truly zero rate of adverse drug events.

Thursday, February 14, 2008

Cool Technology of the Week

This is a somewhat unusual Cool Technology entry.

Last night, three bloggers - Paul Levy , Jessica Lipnack , and I were invited to attend a performance of Shakespeare's Julius Caesar at the American Repertory Theatre (ART) in Cambridge, Massachusetts.

Paul wrote about the leadership lessons learned from the play's theme and dialog.

Jessica wrote about the network of people who made the ART production happen.

This leaves me to talk about the engineering behind this Avant-garde production.

The scenery was pure 1960's, reflecting the surroundings of the Loeb Theater, which was built in 1964. The set included two-tone leather couches and a dinette complete with moon chairs. The backdrop mirrored the banked seats of the theater, blurring the distinction between stage and audience.

The set changes included dynamic transitions of the background, with curtains falling into place to create the perfect 1960's pied de terre, right out of an Austin Powers film. Just how do curtains, walls, lights, microphones, and furniture move around during productions like Julius Caesar? The answer is a theatrical fly system.

A fly system is a collection of ropes, counterweights, pulleys, and other such tools within a theater designed to quickly move objects on and off stage by 'flying' them in from the area above the stage, known a flyspace, flyloft, fly tower, or fly gallery. In this case, the entire theater backdrop rose and fell, and walls of curtains were raised and lowered as needed to create different room views. To think that all these seamless movements were accomplished with ropes and pulleys is pretty cool.

Another interesting technology was used to create the Quentin Tarantino-like spattering of blood as Julius was asssasinated and the conspirators covered their hands in his blood. Just how does Hollywood (or Shakespearan theater) create the illusion of injury and bleeding? They use a technology called Blood Squibs . Balloons filled with blood are exploded using small electrically activated explosives. The conspirators in Julius Caesar eventually meet their own bloody ends and the production did a remarkable job with creating subtle but sanguine changes in clothing throughout the final act using blood squibs.

In the final act of the play, an entire Cadillac limousine is lowered from the ceiling, in homage to the 1960's era Ant Farm performance art installation of the Cadillac Ranch , an artwork which included several images of JFK. The juxaposition of 1960's era Kennedy themes with the assassination of Julius Caesar was striking.

Just how does a theater raise and lower a Cadillac limousine from the ceiling? The answer is 4 one ton winches mounted in the ceiling.

Theatrical flies, blood squibs, and high powered winches - cool technologies when "The play's the thing!"

Rapid Application Development with Facebook

"Rapid Application Development" and "Extreme Programming" are buzzwords for new ways to deliver software that meets initial user requirements and continues to improve based on customer feedback. These approaches turn the IT department into an agile and forward thinking service provider.

The typical approach to software selection - requirements definition, an RFP process, pilots, implementation, integrated testing, and go live - can take 18 months and by the time the software is in use, the initial requirements may have changed. For some applications, the notion of rapidly prototyping a solution then iteratively releasing new versions can deliver more functionality faster than traditional approaches. Given the budgets, staffing, and integration challenges challenges facing most IT departments, the notion of an agile response to organizational imperatives is challenging. Is there a disruptive technology solution to this?

However odd this sounds, the answer may be Facebook.

A case in point. BIDMC is enhancing its external website and is currently preparing an RFP for online giving software. At 8am last Sunday, our BIDMC CEO, Paul Levy, created an online giving page using the Facebook Causes application

It's already been used by hundreds of people and the funds are beginning to roll in.

The IT department did not need to be involved, other than to offer support that the experiment was safe, secure and worth doing.

Facebook is a perfect example of a rapid application development platform that empowers users to help themselves. It includes tools for creating of groups, forums, multimedia uploads, viral marketing, fund raising, and group mailing lists using any web browser, on any operating system, for free.

Should CIOs embrace it as a short term solution to many of the user requests for collaboration technologies?

The answer is yes, with caveats. Facebook is not a HIPAA business associate nor covered entity, so protected healthcare information should not be placed on Facebook. There is no service level agreement/quality of service guarantee, so it may be go down without notice (unlikely, but possible). It does not integrate with enterprise single signon based on Active Directory or LDAP.

However, these issues are not real barriers to supporting the ad hoc collaborations that are often needed by organizations to start projects, create a social network of internal staff, or support a discussion forum.

Should CIOs try to replicate Facebook functionality on internal portals? For some circumstances that involve patients, the need for a guarenteed application availability, and integration with existing systems, the answer is yes. But for others, there is an important reason why Facebook should be considered as part of rapid application development:

So many people are using Facebook at this point (60 million), that many users will resist using any other social networking software. They may even demand Facebook in lieu of corporate solutions so that all social networking activity - inside and outside the office - is integrated in one place.

In my next generation of portal frameworks, I will support our own versions of all the Web 2.0 functionality (forums, wikis, groups, multimedia uploads) that is in Facebook, but I will also ensure that Facebook itself is used strategically. Staying agile and responsive to my customers requires that I embrace Facebook, not resist it.

Tuesday, February 12, 2008

Biometric Authentication

Last week, my BIDMC CEO Paul Levy posted a question in his blog about the utility of fingerprint biometrics for USB storage drives. This raises the more global issue of the usefulness of biometric authentication in hospitals.

Today, authentication at BIDMC and Harvard Medical School is done with a strong username and password - the usual alphanumeric/mixed case password which must be changed frequently, cannot be repeated, is not an English word etc. Using complex passwords is great on desktops, but works less well on mobile devices without keyboards or in crisis situations. Trying to type an 8 character password on a tablet while the patient is crashing can be very anxiety provoking.

Over the past 5 years, I've worked with various biometric technologies including fingerprint scanning, iris scanning, hand geometry, and facial recognition. My experience has been mixed. In general, biometrics have been

-immature, hard to support technology
-challenged by false positive (granting access inappropriately) /false negative issues (denying access inappropriately), impacting user acceptance of the technology
-characterized by lack of integration with existing enterprise security systems

However, new products are being introduced which have caused us to re-evaluate biometrics.

Clinicians find the fingerprint an easy to use authentication method when they are in a hurry. It has 3 positive attributes
-you're unlikely to forget your finger at home
-although identify theft of a fingerprint is theoretically possible, we can "reset" the password by selecting another finger (it's like having 10 different passwords)
-Since laptop data theft is a highly visible problem, protecting laptop logins with a fingerprint scan seems like a good security practice.

There are issues
-As we further deploy this technology, we'll have to review our policies and procedures. For example, if biometrics were used to encrypt corporate issued laptops, the employee termination procedures would need to be changed to ensure access to the “finger” is available to recover the system.
-Recovery of a "lost" fingerprint (due to injury or absence) can be problematic for an institution. -Non-contact biometrics might be better in healthcare settings for infection control

We've tested Omnipass in the Emergency Department as a way to accomplish authentication using multiple methods - fingerprint or username/password, all linked to our enterprise Active Directory (AD). Omnipass supports central storage of fingerprint scans and maps them to AD users. It also provides secure authentication of web pages.

The issue we had in our pilot is the multi step process to log into Omnipass, then log into our ED dashboard application, then log out of Omnipass. For a workflow where the user has the tablet for hours, this wouldn't be a problem. For Emergency Department workflow, the user picks up the tablet, uses it for 3-5 minutes, then puts it down. A 1 minute login/logoff process eliminates the time savings of using a portal device.

For those seeking early experimentation with biometrics, I recommend a pilot of fingerprint scanning. Iris scanning requires more expensive hardware, hand geometry is harder to deploy, and facial recognition is much more experimental technology.

Saturday, February 9, 2008

Electronic Health Records for Non-owned doctors - Cost modeling



Initial Costs
1. Startup costs to be funded by the hospital
Legal costs
Hosting Site hardware and operating system software

Software licensing fees
Technical Deployment services and Workflow design services
Project Management costs
Training costs
Interface costs
Data conversion costs

3. Practice implementation costs to be funded entirely by the practice
Hardware local to the practice

Ongoing costs
1. Maintenance costs to be funded by the hospital
Hosting Site staffing and hardware lifecycle maintenance

2. Support costs to be shared per Stark
Help desk
Practice consulting support

3. Support costs to be funded entirely by the practice
Hardware service and support
Network connectivity




Friday, February 8, 2008

Always Look on the Bright Side

Every day as a CIO, I inevitably receive unpleasant emails. I truly wish I could receive emails like

"The network and the servers have been running flawlessly for the past year. Congratulations on zero downtime"

but alas, no one is likely to send such an email.

The CIO has the challenge of delivering flawless operational performance while also managing constant change. It's a bit like changing the wings on a 747 while in flight.

I have an appropriate budget which is prioritized by excellent governance committees, and a yearly operating plan that is only occasionally interrupted by the "Tyranny of the Urgent" due to compliance, quality, or strategic opportunity mandates, but I still receive daily complaints such as:

"The Spam filters are too lax since I still receive some junk mail, but by the way, you need to let my eBay transactions through"

"My brother in law will offer me an Owuga 3000 desktop computer at a cheaper price, why are you using Dell and Lenovo hardware?"

"I need to surf pornography sites as part of an NIH funded research study and you should not restrict my academic freedom"

"My application, although not funded and not reviewed by any governance process, is your highest priority"

"I did not tell you that we needed network, telephones, desktops, and new applications by next week but now it's your emergency. I'm headed out to my vacation, let me know how it goes."

To all such complaints, a kneejerk response might be:

"Your bad planning does not constitute an emergency on my part"


"Every project is function of funding, scope, and time. You've provided no funding, so your project will either have zero scope or take infinite time"

but the CIO needs to respond

"Thanks so much for your thoughtful email. There is a process to evaluate your request and I will personally supervise your request during that process. Your peers and the clinical leadership of the entire organization will evaluate your request based on

Return on Investment
Staff/Patient/Clinician impact
Strategic importance"

Every time I have responded to angry email with emotion I have regretted it. Although it may feel good to respond to a negative email with a venomous answer, emotion is never appropriate. I tell my staff that if they ever feel emotion while writing an email, "save as draft". Get someone else to review the response first. Send it after a day of rest.

Rather than judge the quality of every day based on the negative email I receive, I ask about our trajectory. Have we moved forward on our yearly and five year plan? Has today had 10 good things and only 5 bad things? Do I have my health, my family, and my reputation?

No matter how bad the week, the answer to all of these questions is always yes. Our trajectory is always positive.

With a positive trajectory in mind, a non-emotional response to every issue is easier. If a CIO ever uses profanity, a raised voice, or escalation to the CEO, the CIO diminishes himself/herself.

You can always recover from a bad day, but you cannot always recover from a bad email. Just ask Neal Patterson.

Thus, keep a stiff upper lip, have a thick skin, and run each day based on your trajectory not the position of your ego. And remember, "save as draft."

Wednesday, February 6, 2008

Cool Technology of the Week









Web Content Management Systems



Our requirements for a CMS were
  • Authentication via our LDAP/Active Directory systems






Monday, February 4, 2008

My Top 10 rules for Schedule triage

In previous posts, I've described my approach to email triage.

Here's my approach to triage of my daily schedule.













Electronic Records for Non-Owned Doctors - Governance

As promised last week, I will blog each week about the 10 critical aspects of our project to provide a hosted electronic health record solution for non-owned clinicians, one of the most challenging projects facing hospitals nationwide. This week's entry describes our project governance.

The needs of many stakeholders must be balanced to ensure the success of this project. The hospital wants to support as many clinicians as possible using its capital budgets most efficiently. Community clinicians want to minimize the financial and operational impact of the project on their practice. IT staff must manage their hospital-based projects and infrastructure while expanding their scope to new offsite locations.

Governance is critical to establish priorities, align stakeholders, and set expectations. To support this project we created two governance committees - a steering committee and an advisory committee.

The steering committee is comprised of senior executives from the hospital and physicians' organization, since it is truly a joint effort of Beth Israel Deaconess Medical Center (BIDMC) and the Beth Israel Deaconess Physicians' Organization (BIDPO). BIDMC representatives include the CFO, the CIO, the SVP of Network Development and the IT project manager. Physicians' organization members include the President, the Executive Director, and the Chief Medical Officer of BIDPO. This committee provides oversight of legal agreements, financial expenditures, project scope, timelines, and resources. It is co-chared by the CIO and Executive Director of BIDPO, who jointly sign off on all expenditures. The BIDMC and BIDPO boards provide additional oversight of the committee chairs.

The advisory committee is comprised of prospective community physician users of the electronic health record system. Since our community network is comprised of 300 non-owned Boston-based physicians, clinicians in the western suburbs and clinicians in the southern part of the state, we have representatives of each group sitting on the committee. The committee focuses on making the project really work for the practices, but also to meet the needs of the physician organization's clinically integrated network model. The role of the committee is to review our "model" office templates, help us prioritize the implementation order of practices, and make recommendations on policies. As with every project, we use our standard project management tools including a charter for each committee.

Since this project is so challenging and requires a precise blend of economics, information technology and politics, the governance committees are the place to ask permission, beg forgiveness, and communicate progress on every milestone. This is especially true to the complex cost model which shares expenditures equally between the hospital and physician's organization for implementation, subsidizing private clinician costs to the extent we are able based on Stark safe harbors. As you'll see in next week's EHR blog entry, the costs are diverse and deciding who pays/how much they pay cannot be done alone by IT, the hospital, or the physicians. It's truly a role for transparent, multi-disciplinary governance committees.

Managing Consulting Engagements


Consulting engagements

Here's the structured approach I recommend to manage consultants










