One of my responsibilities as CIO at BIDMC and HMS includes oversight of Media Services. Historically Media Services produced slides/posters and provided slide projectors, TVs and VCRs. In this digital world, it is now the focal point for streaming, telemedicine, and all digital presentation services including LCD projectors/plasma screens/digital whiteboards. My media services organizations at BIDMC and HMS have been evolving to provide services required by today's digital savvy customer. Strategic questions include:
1. What is our video teleconferencing strategy?
Several years ago, Caregroup acquired bulky Picture-Tel teleconferencing units to link together our hospital executive teams. They were challenging to use, and required engineers to establish and maintain connections. They were not mobile and provided few features other than basic voice and picture connectivity. They were used less than 5% of the time. Today, with H320 (ISDN) and H323 (IP) mobile units, are we seeing more video teleconferencing? For group meetings, telemedicine consultation, and interpreter's Carelink (video delivery of interpreter services to the bedside), we're seeing more interest. To support these initiatives, BIDMC installed a teleconferencing bridge so we can link internal IP teleconferencing to external ISDN teleconferencing units, host video conference calls and provide security for internal to external IP calls. A year ago 90% of our video calls were ISDN, currently 90-95% of our calls are IP, All internal video calls are IP and about 60% of our external calls are IP over the public internet, with very reliable results.
Video teleconferencing is still not a seamless technology, as easy and reliable to use as a telephone. Cisco Teleprescence has amazing clarity and ease of use, but it requires specialized equipment in a dedicated space. BIDMC will embrace video teleconferencing more when desktop to desktop communication becomes easy and reliable.
At HMS, we're running several tele-learning pilots, making lectures at the medical school available in real time to students at Harvard University and linking together outside institutions for collaborative coursework over Internet 2. As with BIDMC, doing each of these requires significant media services resources, so they are not broadly deployed. HMS, along with the other Harvard schools are jointly investigating enterprise licenses for Webex and Elluminate as real time collaboration tools, realizing that the value of a real time video feed is limited.
2. Should we offer full service presentation support or self service classrooms?
I've lectured in numerous auditoriums around the world which are outfitted with sophisticated Crestron equipment. Each one I use has a custom user interface which hides the details of room lighting, screens, curtains, video projectors, and video sources from the user. This may sound like an advantage, but I've had many presentations delayed because the Crestron unit itself becomes unresponsive and no one knows how to reset it. If I had a simple AV switch box, light dimmer, and screen switch, I could operate the room myself with ease. Reseting a projector is just an off/on switch. Cabling is a VGA or DVI connector. However, not all users are completely comfortable with AV equipment, so some prefer Crestron user interfaces.
Do we provide staff at every event to set up and assist all presenters? Do we use complex Crestron programming to make room control easy for the average user? Do we provide a basic set of off/on switches and assume most users can figure it out?
My personal favorite is Extron HideAway desktop PC Interface, which is a basic AV switchbox and VGA cable. It works every time. I think its likely that we'll try to standardize most conference rooms using Extron equipment, ensure most users are familiar with it and staff just large public events or those events with visiting faculty to ensure their success. This means we'll need to invest in our conference rooms to bring them all up to a consistent level. The capital to do that has been challenging to obtain, but I believe striking a better balance between consistent self service infrastructure and staffed presentation support will increase customer satisfaction and better utilize the time of skilled AV staff.
3. What is our video streaming strategy?
We're increasingly asked to host video streaming for grand rounds, resident report, simulations, operating room procedures and continuing medical education. BIDMC does not have internal video streaming hosting. Harvard Medical School hosts video streaming for 1600 courses and has made this infrastructure available to BIDMC on a case by case basis.
Our challenge is what to do with streaming video available to the public. Providing streaming servers and networks with appropriate bandwidth is no problem for a few hundred students, but what about public video streams that could be watched by thousands. We'd used Akamai for public streaming and self hosted infrastructure at HMS for private streaming. HMS uses several tools to automate the video streaming process including AnyStream and Apreso. We currently host Real formats, but in the future we'll likely host additional Flash formats.
4. What is our podcasting strategy?
HMS currently has an audio podcasting infrastructure to support 1600 courses. We're investigating video podcasting but at present, there is limited demand. The value of watching a talking head while listening to a lecture on an iPod is limited. We've recently developed public podcasts too.
5. What is our new media strategy?
Historically, media services at BIDMC provided graphic design for public web pages. This resulted in graphically interesting pages, but designs were so sophisticated that real time revisions were not possible. We're moving our external website to a content management system so that complex HTML coding and graphic design are no longer required. This may result in less graphically interesting pages, but makes real time changes easy. Currently, we do not offer Flash programming services, but we do offer photography, video encoding, and basic graphic design. In the future, it probably makes sense that Media Services will offer services to produce still images, flash animations, and streamline video to support websites using our new content management system.
6. What's the right mix of services to provide?
Creating the right mix of poster services, graphics services, photography, video, and presentation services is challenging. At both HMS and CareGroup, we've thinking about this, realizing that presentation services (both self service and full service) are important, and that various digital graphics services will be increasingly important.
7. What media services do patients expect?
Media services at BIDMC include providing Television services to the hospital. Patients now expect additional services such as movies on demand, video game services, and web access via in room televisions. At present, we offer wireless to all patients at no charge, but do not provide rentable laptops. We're investigating partnerships to provide additional media services to patients.
8. What should we insource and what should we outsource?
Clearly, presentation services are something that we must insource because demand is unpredictable and services are often needed at the last minute. Flash and high end collaboration services might best be outsourced. We're thinking about the best balance of internal and external staff to support basic verses advanced digital media services.
9. How should we divide the role of web content management?
At BIDMC, Corporate Communications has taken the lead in our web content management project. They will lead the governance effort which oversees departmental production of content. Media services has taken a lesser role in web design and daily web content production. In the future, it's likely that content production will be divided between departments, corporate communication, media services, and outsourced high end content providers.
10. How do we optimize management of team?
Given the evolving roles of media services, the need for presentation support, and the increasing customer demand for advanced digital services, how do we manage a forward thinking and agile media services team? At HMS, we're considering adding additional operational team leadership such as an "air traffic controller" to schedule each day's events and ensure all presentation services are well orchestrated. At BIDMC, we're considering the addition of a "new media" specialist.
Working together, the management and staff of Media Services will refine their skill sets, optimize their alignment with customer needs, and evolve to meet the demands of a web 2.0 world.
Selasa, 19 Februari 2008
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.
Senin, 18 Februari 2008
Electronic Health Records for Non-owned Doctors - Planning for Distributed Users
This is the fourth entry in my series about electronic health records for non-owned doctors. Today's topic is about supporting hundreds of clinicians, spread over a wide geographical area with varying levels of IT infrastructure and technology savvy.
CIOs of academic healthcare facilities are used to highly controlled and predictable environments. We oversee the quality of service from end to end. Desktops have a managed image with updated anti-virus software. The network is physically secured in closets we control, using fiber and cables we install. Our teams and our management is optimized to deliver service that are consistent and standardized.
The Electronic Health Record project for non-owned doctors requires a different approach. The initial 300 doctors in 173 physical locations spread over 450 square miles have diverse needs and heterogenous access to infrastructure. Some already have computers, wired and wireless networks. Most do not. Those in rural areas may have limited access to bandwidth, making business DSL their only choice for connectivity.
The alternatives we considered for serving these geographically distributed users was
- Expand our current IS offsite team which currently focuses on BIDMC owned clinicians and those occupying BIDMC leased space. This matrix illustrates the different kinds of physicians we support and the services we currently provide.
- Negotiate group purchasing agreements with vendors and make these available to clinicians, reducing heterogeneity but not providing installation and management of the infrastructure. Physicans could hire local consultants, family members, or do it themselves.
- Outsource the infrastructure of these practices to a firm specializing in managing the IT needs of independent clinicians
We weighed the benefits and costs of each approach and elected to outsource infrastructure to Concordant.
Here's our thinking
-Geographically distributed practices needing 24x7 support would require a large internal team to provide a high service level, weekend coverage and vacation coverage. Although we are currently planning on 300 clinicians, that number might expand to 500 or 1000, hence scaling up with agility would be challenging, especially in a job market where many hospitals are competing for skilled IT professionals.
-Our current offsite group is extremely good and focused on providing infrastructure and application services to sites we operate. Expanding this group to support a very different kind of practice with very different infrastructure would dilute their current focus.
-Enabling these distributed offices to purchase their own equipment and establish their own local infrastructure could be disastrous. Guaranteeing service levels means that we must have an understanding of the network performance, desktop configuration, and local infrastructure (printers, scanners, fax machines) of each office.
Our plan is to operate a highly reliable hosted electronic health record, housed a commercial co-location facility and make it available to each of these practices via the public internet without having to create network or telecom connections ourselves. At each office location, however, the desktops, wired and wireless network will be completely homogeneous and managed by Concordant. We'll leverage the scale of the project to obtain the best discounts possible from hardware vendors. We'll even retire existing office hardware to achieve homogeneity. Help desk services will be staffed by Concordant, so that we will not need to train our existing help desk staff to support these distributed non-owned clinicians.
We elected not to place servers in any clinician offices since physician offices do not have backup power, environmentally controlled server rooms, or appropriate physical security for machines hosting the data. Our plan is to maintain a central hardware depot, assemble all the equipment needed for an office, deliver it, configure and test it. Everyone wants to minimize on-site support, but some on-site service will still be needed for hardware failures and very "high-touch" support. Remote support and monitoring techniques can help, though minimally, since we're implementing a centralized architecture.
It is our hope that a dedicated outsourced infrastructure service, optimized for the needs of the geographically distributed small physician office will work better and cost less than expanding our existing IS teams or enabling physicians to do it themselves. It also enables us to track costs more closely since there is a strict separation between support for owned sites and non-owned sites. Our first non-owned sites go live in June and I'll let you know how it goes.
CIOs of academic healthcare facilities are used to highly controlled and predictable environments. We oversee the quality of service from end to end. Desktops have a managed image with updated anti-virus software. The network is physically secured in closets we control, using fiber and cables we install. Our teams and our management is optimized to deliver service that are consistent and standardized.
The Electronic Health Record project for non-owned doctors requires a different approach. The initial 300 doctors in 173 physical locations spread over 450 square miles have diverse needs and heterogenous access to infrastructure. Some already have computers, wired and wireless networks. Most do not. Those in rural areas may have limited access to bandwidth, making business DSL their only choice for connectivity.
The alternatives we considered for serving these geographically distributed users was
- Expand our current IS offsite team which currently focuses on BIDMC owned clinicians and those occupying BIDMC leased space. This matrix illustrates the different kinds of physicians we support and the services we currently provide.
- Negotiate group purchasing agreements with vendors and make these available to clinicians, reducing heterogeneity but not providing installation and management of the infrastructure. Physicans could hire local consultants, family members, or do it themselves.
- Outsource the infrastructure of these practices to a firm specializing in managing the IT needs of independent clinicians
We weighed the benefits and costs of each approach and elected to outsource infrastructure to Concordant.
Here's our thinking
-Geographically distributed practices needing 24x7 support would require a large internal team to provide a high service level, weekend coverage and vacation coverage. Although we are currently planning on 300 clinicians, that number might expand to 500 or 1000, hence scaling up with agility would be challenging, especially in a job market where many hospitals are competing for skilled IT professionals.
-Our current offsite group is extremely good and focused on providing infrastructure and application services to sites we operate. Expanding this group to support a very different kind of practice with very different infrastructure would dilute their current focus.
-Enabling these distributed offices to purchase their own equipment and establish their own local infrastructure could be disastrous. Guaranteeing service levels means that we must have an understanding of the network performance, desktop configuration, and local infrastructure (printers, scanners, fax machines) of each office.
Our plan is to operate a highly reliable hosted electronic health record, housed a commercial co-location facility and make it available to each of these practices via the public internet without having to create network or telecom connections ourselves. At each office location, however, the desktops, wired and wireless network will be completely homogeneous and managed by Concordant. We'll leverage the scale of the project to obtain the best discounts possible from hardware vendors. We'll even retire existing office hardware to achieve homogeneity. Help desk services will be staffed by Concordant, so that we will not need to train our existing help desk staff to support these distributed non-owned clinicians.
We elected not to place servers in any clinician offices since physician offices do not have backup power, environmentally controlled server rooms, or appropriate physical security for machines hosting the data. Our plan is to maintain a central hardware depot, assemble all the equipment needed for an office, deliver it, configure and test it. Everyone wants to minimize on-site support, but some on-site service will still be needed for hardware failures and very "high-touch" support. Remote support and monitoring techniques can help, though minimally, since we're implementing a centralized architecture.
It is our hope that a dedicated outsourced infrastructure service, optimized for the needs of the geographically distributed small physician office will work better and cost less than expanding our existing IS teams or enabling physicians to do it themselves. It also enables us to track costs more closely since there is a strict separation between support for owned sites and non-owned sites. Our first non-owned sites go live in June and I'll let you know how it goes.
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 Amazon.com. 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
Many commercial CPOE systems are 'some assembly required'. They provide a container for rules, but do not come with an initial set. You can establish internal committees to build best practice rulesets, purchase rules from vendors such as Zynx or First Data Bank, or use rules others have created, such as ours.
8. CPOE decision support is only as good as the data available
Decision support depends upon accurate medical history. Safe drug dosing requires a current medication list, updated allergies, creatinine and other current labs, a problem list, and even genomic testing results. This means that all aspects of the hospital information system must be fully integrated into CPOE to achieve the best result. There is no such thing as a standalone CPOE system and it's best that CPOE be purchased as part of an integrated hospital information system.
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
When I was a resident, I was told that heparin should be dosed as a 5000 unit bolus then an infusion of 1500 units per hour for every patient. I was not taught about relating heparin dosing to body mass index, creatinine clearance or the presence of other medications. Unfortunately, it often took days to get the heparin dosing right because 5000/1500 is definitely not a one size fits all rule. Creating an automated CPOE order for 5000/1500 is not going to improve the safety or efficacy of heparin dosing. Implementing a new protocol for dosing based on evidence that includes diagnosis, labs, and body mass index will improve care. Our experience is that it is best to fix the process, then automated the fixed process. By doing this, no one can blame the software for the pain of adapting to the process change.
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.
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 Amazon.com. 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
Many commercial CPOE systems are 'some assembly required'. They provide a container for rules, but do not come with an initial set. You can establish internal committees to build best practice rulesets, purchase rules from vendors such as Zynx or First Data Bank, or use rules others have created, such as ours.
8. CPOE decision support is only as good as the data available
Decision support depends upon accurate medical history. Safe drug dosing requires a current medication list, updated allergies, creatinine and other current labs, a problem list, and even genomic testing results. This means that all aspects of the hospital information system must be fully integrated into CPOE to achieve the best result. There is no such thing as a standalone CPOE system and it's best that CPOE be purchased as part of an integrated hospital information system.
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
When I was a resident, I was told that heparin should be dosed as a 5000 unit bolus then an infusion of 1500 units per hour for every patient. I was not taught about relating heparin dosing to body mass index, creatinine clearance or the presence of other medications. Unfortunately, it often took days to get the heparin dosing right because 5000/1500 is definitely not a one size fits all rule. Creating an automated CPOE order for 5000/1500 is not going to improve the safety or efficacy of heparin dosing. Implementing a new protocol for dosing based on evidence that includes diagnosis, labs, and body mass index will improve care. Our experience is that it is best to fix the process, then automated the fixed process. By doing this, no one can blame the software for the pain of adapting to the process change.
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.
Kamis, 14 Februari 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.
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.
Selasa, 12 Februari 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.
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.
Langganan:
Postingan (Atom)