I've recently written about decision support and speculated on the ways we can transform data to information to knowledge to wisdom.
Over the past few weeks, I've seen a convergence of emerging ideas that suggest a new path forward for decision support. Application Service Providers offer remotely hosted, high value Software as a Service applications at low cost. I believe we need Decision Support Service Providers (DSSP), offering remotely hosted, low cost knowledge services to support the increasing need for evidence-based clinical decision making.
BIDMC has traditionally bought and built its applications. Our decision support strategy will also be a combination of building and buying. However, it's important to note that creating and maintaining your own decision support rules requires significant staff resources, governance, accountability, and consistency. Our Pharmacy and Therapeutics Committee recently examined all the issues involved in maintaining our own decision support rules and you'll see that it's an extensive amount of work. We use First Data Bank as a foundation for medication safety rules. We use Safe-Med to provide radiology ordering guidelines based on American College of Radiology rules. Our internal committees and pharmacy create and maintain guidelines, protocols, dosing limits, and various alerts/reminders. We have 2 full time RNs just to maintain our chemotherapy protocols.
Many hospitals and academic institutions do not have the resources to create and maintain their own best practice protocols, guidelines, and order sets. The amount of new evidence produced every year exceeds the capacity of any single committee or physician to review it. The only way to keep knowledge up to date is to divide the maintenance cost and effort among many institutions.
A number of firms have assembled teams of clinicians and informatics experts to offer these kinds of knowledge resources. UptoDate maintains world class clinical information with thousands of authors reviewing literature and providing quarterly revisions. Safe-Med has a large team of experts codifying decision support rules and building the vocabulary tools needed to make them work with real world clinical data. Medventive provides the business intelligence tools needed to create physician report cards and achieve pay for performance incentives.
However, none of these firms can plug directly into an electronic health record in a way that offers clinicians just in time decision support.
Here's a strawman for the way a Decision Support Service Provider should work:
a. A hospital or clinic selects one or many Decision Support Service Providers based on clinician workflow needs, compliance requirements and quality goals
b. Electronic health record software connects to Decision Support Service Providers via a web services architecture, including appropriate security to protect any patient specific information transfered to remote decision support engines. For example, an EHR might transfer a clinical summary such as the Continuity of Care Document to a Decision Support Service Provider along with a clinical question to be answered.
c. A clinician begins to order a therapy or diagnostic test. The patient's insurance eligibility and formulary are checked via a web service. The patient's latest problem list, labs, and genetic markers are compared to best practices in the literature for treating their specific condition. A web service returns a rank ordered list of desirable therapies or diagnostics, based on evidence, and provides alerts, reminders, or monographs personalized for the patient.
d. Clinicians complete their orders, complying with clinical guidelines, pay for performance incentives and best practices.
e. The decision support feedback is realtime and prospective, not retrospective. Physicians get CME credit from learning new approaches to diagnosis and treatment.
In order to do this, EHR vendors must work with Decision Support Service Providers to implement the uniform architecture and interoperability standards needed to integrate decision support into EHR workflow. I would be happy to host a Harvard sponsored conference with all the stakeholder companies to kick off this work.
Of course, some may worry about the liability issues involved in using a Decision Support Service Provider. What if clinicians comply with flawed guidelines or fail to comply with suggested therapies and bad outcomes occur?
An excellent summary of Information-Based Liability and Clinical Decision Support Systems is available on the Clinical Informatics Wiki.
Based on my review of the literature, I believe decision support liability is a new area without significant case law. The good news is that there are no substantive judgments against clinicians for failing to adhere to a clinical decision support alert. As a licensed professional, the treating clinician is ultimately responsible for the final decision, regardless of the recommendations of a textbook, journal, or Decision Support Service Provider. However, as Clinical Decision Support matures and becomes more powerful and relevant, I believe that there could be greater liability for not using such tools to prevent harm.
This blog entry is a call to action for EHR vendors and emerging Decision Support Service Provider firms. It's time to align our efforts and integrate decision support into electronic health records. Working together is the only affordable way for the country to rapidly implement and maintain high quality decision support.
Rabu, 30 April 2008
Selasa, 29 April 2008
Integrating the Electronic Record
This is the third blog in my series of 2008-2009 areas of personal focus - clinical documentation, decision support, and the integrated electronic record .
At BIDMC, we buy and we build applications. We've purchased vendor systems for Lab, PACS, anesthesia documentation, ICU charting, and cardiology data management. We've built our electronic health record, provider order entry and our portals, which means that we create the enterprise front ends used by clinicians. All our home built applications share one fully integrated database. However, we must integrate data from dozens of vendor applications with our home built applications, which we've done via a service oriented architecture. Further, we have to integrate data from multiple outside organizations to reconcile medications and ensure continuity of care. Our strategy is to converge all viewing, ordering, documentation, and sign on to a single application - our self built electronic health record called webOMR. Of course, some departments such as the lab will use purchased applications such as the laboratory system for their internal departmental workflow, but the clinicians will never know that we have a purchased lab system, since all their work will be done via webOMR. Here are the top 40 ways we integrate data among our various applications.
1. WebOMR displays laboratory and radiology results from our community hospitals - Beth Israel Deaconess Needham, Mt. Auburn, and New England Baptist using real time integration from Meditech via a service oriented architecture.
2. WebOMR supports full ambulatory order entry with automated electronic routing of radiology, cardiology and laboratory for our affiliated community hospital, BID Needham.
3. WebOMR will soon display an indicator on the patient summary if community hospital data is available for viewing, reminding clinicians to look for these external results.
4. WebOMR includes viewing of all endoscopy reports and photos from our Gcare endoscopy system.
5. WebOMR includes viewing of all echocardiology reports from our Encor echo reporting system.
6. We've built a 'popup' version of WebOMR for eClinicalWorks and CareTracker users, so private clinicians in the community can view all BIDMC data on their patients without having to leave their office EHR.
7. We've also included ordering of BIDMC labs and radiology diagnostics within the 'popup' version.
8. WebOMR displays all problems, medications, allergies, visits, notes/reports, and labs from the Joslin clinic, an affiliated but separate institution.
9. WebOMR includes viewing of allRadiology images from GE Centricity PACS.
10. WebOMR includes viewing of Radiation Oncology Reports from Impac.
11. WebOMR includes viewing of Electrophysiology Reports from GE Cardiology applications.
12. WebOMR includes viewing of Anesthesia flow sheets from Philips Compurecord.
13. WebOMR will include viewing of IMDSoft ICU Charting later this year.
14. WebOMR will include Enterprise Image viewing of all non-radiology imaging modalities by next year.
15. WebOMR will include viewing of scanned inpatient papers records by June 2008.
16. WebOMR includes integration of pediatric immunization records from our community health centers.
17. WebOMR displays inpatient discharge meds from Provider Order Entry and offers one click conversion of inpatient medications to outpatient medications.
18. WebOMR includes full e-prescribing integration to our statewide eRx Gateway including eligibility checking, formulary enforcement, routing to retail and mail order pharmacies, and community-wide medication history with drug/drug and drug/allergy checking.
19. WebOMR pushes discharge summaries to community clinicians via our statewide Clinical Data Exchange Gateway.
20. WebOMR offers a single point of entry to all other systems including all inpatient functions such as POE. Single signon enables clinicians to logon once to use all functions.
21. Webomr and Provider Order Entry share and exchange data such as immunizations, allergies, and health care proxies. Our Perioperative Management System (OR Management) also shares allergies and health care proxies.
22. Our Cardiology systems consolidation (planned for 2009-2010) will include full webOMR viewing of cardiology data.
23. Inpatient documentation including Medication reconciliation, History and Physicals, Sign out/Team Census enhancements, and Discharge enhancements planned for 2009-2010 will ensure that all inpatient documentation is available elecronically in webOMR.
24. Our transplant record will soon be fully integrated into webOMR
25. Our Perioperative Information Management system offers fully integrated OR workflow management. We are planning PACU documentation and its integration with ICU documentation now.
26. Our ED Dashboard offers fully integrated viewing of all outpatient and inpatient data about the patient in one place
27. Our Oncology Management System offers fully integrated Heme/ONC Management incorporating all lab, medication and history data for both outpatient and inpatient settings in webOMR.
28. Our Radiology Portal offers fully integrated radiology services supporting key clinical, quality assurance, and administrative workflow functions in one place.
29. Antibiotic precautions (e.g., MRSA, VRE) are displayed in our admitting and outpatient scheduling systems.
30. Perioperative Information Management, Appointment Scheduling and Admitting all share information to eliminate duplicate data entry as an operating room case and its associated admission and pre-admission testing appointment are scheduled.
31. Appointment scheduling integration with webOMR includes printing the webOMR med list at appointment check in, prompts for diabetic ophthalmology screens in scheduling, reports of missing and unsigned notes within scheduling, and webOMR display of recent and future appointments.
32. Admitting/Emergency Department integration with webOMR includes displaying recent Emergency Department and inpatient visits.
33. Registration integration with webOMR includes displaying insurance summary, Medicare D coverage, and medication assistance counseling alerts to assist with prescribing in webOMR.
34. Our physician billing application, ETicket, automatically adds patients to providers’ censuses for operating room cases after patients are entered into the Perioperative Information Management System.
35. ETicket automatically adds patients to providers’ censuses after encounters in Labor and Delivery Triage and OB/Gyn triage.
36. All our electronic payer transactions for eligibility, referral/authorization, claims, and remittance are fully integrated into our scheduling, registration and billing systems.
37. Our capacity Dashboard integrates real time utilization data from admitting, Emergency Department, Provider Order Entry, Cath Lab, Transfer Log, and ICU Callout systems.
38. Our Diabetes Registry incorporates data from BIDMC and Joslin to facilitate comprehensive, integrated reporting on diabetic care
39. We maintain data marts for a broad range of clinical systems, including laboratory, microbiology, blood bank, radiology, inpatient pharmacy, outpatient medications, OR, and demographics, admitting and scheduling. These support data mining, research, and quality/performance measurement within and across systems.
40. A web page that tracks the health of all this integration runs 7x24 in our command center, refreshing itself every minute. In addition to monitoring many different infrastructure level parameters, this caretaker also checks on various applications, including integration engine feeds, Medquist (dictation) transactions, and various Emergency Department functions.
From the list above, I hope I've illustrated that interoperability between systems at BIDMC includes human readable data exchange, semantic interoperability for decision support, and process interoperability, linking workflow among various systems.
With this degree of data integration, we're approaching the tipping point which will enable us to transition from a hybird paper/electronic record to a fully electronic record and we have a retreat this Summer to plan for that transition and adjust our governance as needed.
Will we ever be done with 100% integration of every element of data from purchased and built systems? No, but the journey moves fast enough to keep the patients safe and the clinicians satisfied.
At BIDMC, we buy and we build applications. We've purchased vendor systems for Lab, PACS, anesthesia documentation, ICU charting, and cardiology data management. We've built our electronic health record, provider order entry and our portals, which means that we create the enterprise front ends used by clinicians. All our home built applications share one fully integrated database. However, we must integrate data from dozens of vendor applications with our home built applications, which we've done via a service oriented architecture. Further, we have to integrate data from multiple outside organizations to reconcile medications and ensure continuity of care. Our strategy is to converge all viewing, ordering, documentation, and sign on to a single application - our self built electronic health record called webOMR. Of course, some departments such as the lab will use purchased applications such as the laboratory system for their internal departmental workflow, but the clinicians will never know that we have a purchased lab system, since all their work will be done via webOMR. Here are the top 40 ways we integrate data among our various applications.
1. WebOMR displays laboratory and radiology results from our community hospitals - Beth Israel Deaconess Needham, Mt. Auburn, and New England Baptist using real time integration from Meditech via a service oriented architecture.
2. WebOMR supports full ambulatory order entry with automated electronic routing of radiology, cardiology and laboratory for our affiliated community hospital, BID Needham.
3. WebOMR will soon display an indicator on the patient summary if community hospital data is available for viewing, reminding clinicians to look for these external results.
4. WebOMR includes viewing of all endoscopy reports and photos from our Gcare endoscopy system.
5. WebOMR includes viewing of all echocardiology reports from our Encor echo reporting system.
6. We've built a 'popup' version of WebOMR for eClinicalWorks and CareTracker users, so private clinicians in the community can view all BIDMC data on their patients without having to leave their office EHR.
7. We've also included ordering of BIDMC labs and radiology diagnostics within the 'popup' version.
8. WebOMR displays all problems, medications, allergies, visits, notes/reports, and labs from the Joslin clinic, an affiliated but separate institution.
9. WebOMR includes viewing of allRadiology images from GE Centricity PACS.
10. WebOMR includes viewing of Radiation Oncology Reports from Impac.
11. WebOMR includes viewing of Electrophysiology Reports from GE Cardiology applications.
12. WebOMR includes viewing of Anesthesia flow sheets from Philips Compurecord.
13. WebOMR will include viewing of IMDSoft ICU Charting later this year.
14. WebOMR will include Enterprise Image viewing of all non-radiology imaging modalities by next year.
15. WebOMR will include viewing of scanned inpatient papers records by June 2008.
16. WebOMR includes integration of pediatric immunization records from our community health centers.
17. WebOMR displays inpatient discharge meds from Provider Order Entry and offers one click conversion of inpatient medications to outpatient medications.
18. WebOMR includes full e-prescribing integration to our statewide eRx Gateway including eligibility checking, formulary enforcement, routing to retail and mail order pharmacies, and community-wide medication history with drug/drug and drug/allergy checking.
19. WebOMR pushes discharge summaries to community clinicians via our statewide Clinical Data Exchange Gateway.
20. WebOMR offers a single point of entry to all other systems including all inpatient functions such as POE. Single signon enables clinicians to logon once to use all functions.
21. Webomr and Provider Order Entry share and exchange data such as immunizations, allergies, and health care proxies. Our Perioperative Management System (OR Management) also shares allergies and health care proxies.
22. Our Cardiology systems consolidation (planned for 2009-2010) will include full webOMR viewing of cardiology data.
23. Inpatient documentation including Medication reconciliation, History and Physicals, Sign out/Team Census enhancements, and Discharge enhancements planned for 2009-2010 will ensure that all inpatient documentation is available elecronically in webOMR.
24. Our transplant record will soon be fully integrated into webOMR
25. Our Perioperative Information Management system offers fully integrated OR workflow management. We are planning PACU documentation and its integration with ICU documentation now.
26. Our ED Dashboard offers fully integrated viewing of all outpatient and inpatient data about the patient in one place
27. Our Oncology Management System offers fully integrated Heme/ONC Management incorporating all lab, medication and history data for both outpatient and inpatient settings in webOMR.
28. Our Radiology Portal offers fully integrated radiology services supporting key clinical, quality assurance, and administrative workflow functions in one place.
29. Antibiotic precautions (e.g., MRSA, VRE) are displayed in our admitting and outpatient scheduling systems.
30. Perioperative Information Management, Appointment Scheduling and Admitting all share information to eliminate duplicate data entry as an operating room case and its associated admission and pre-admission testing appointment are scheduled.
31. Appointment scheduling integration with webOMR includes printing the webOMR med list at appointment check in, prompts for diabetic ophthalmology screens in scheduling, reports of missing and unsigned notes within scheduling, and webOMR display of recent and future appointments.
32. Admitting/Emergency Department integration with webOMR includes displaying recent Emergency Department and inpatient visits.
33. Registration integration with webOMR includes displaying insurance summary, Medicare D coverage, and medication assistance counseling alerts to assist with prescribing in webOMR.
34. Our physician billing application, ETicket, automatically adds patients to providers’ censuses for operating room cases after patients are entered into the Perioperative Information Management System.
35. ETicket automatically adds patients to providers’ censuses after encounters in Labor and Delivery Triage and OB/Gyn triage.
36. All our electronic payer transactions for eligibility, referral/authorization, claims, and remittance are fully integrated into our scheduling, registration and billing systems.
37. Our capacity Dashboard integrates real time utilization data from admitting, Emergency Department, Provider Order Entry, Cath Lab, Transfer Log, and ICU Callout systems.
38. Our Diabetes Registry incorporates data from BIDMC and Joslin to facilitate comprehensive, integrated reporting on diabetic care
39. We maintain data marts for a broad range of clinical systems, including laboratory, microbiology, blood bank, radiology, inpatient pharmacy, outpatient medications, OR, and demographics, admitting and scheduling. These support data mining, research, and quality/performance measurement within and across systems.
40. A web page that tracks the health of all this integration runs 7x24 in our command center, refreshing itself every minute. In addition to monitoring many different infrastructure level parameters, this caretaker also checks on various applications, including integration engine feeds, Medquist (dictation) transactions, and various Emergency Department functions.
From the list above, I hope I've illustrated that interoperability between systems at BIDMC includes human readable data exchange, semantic interoperability for decision support, and process interoperability, linking workflow among various systems.
With this degree of data integration, we're approaching the tipping point which will enable us to transition from a hybird paper/electronic record to a fully electronic record and we have a retreat this Summer to plan for that transition and adjust our governance as needed.
Will we ever be done with 100% integration of every element of data from purchased and built systems? No, but the journey moves fast enough to keep the patients safe and the clinicians satisfied.
Senin, 28 April 2008
A Field Trip to Dell
From 4/15 through 4/17 my BIDMC team visited the Dell facilities in the Austin area for an executive briefing on several areas of their operations and futures. Today's blog is about their lessons learned.
Data Center Tour
They toured the main Dell data center in Round Rock. This was one of Dell's two Tier III data centers, reduced from the dispersed 16 data center model they used from 2001-2003. Cooling and power were left the way that they had been designed at the time of the acquisition. The system delivers cool air from the ceiling and from the floor. They acknowledged that it was not optimal and are making plans for a re-vamp. More on the plans under the “Data Center Engineering Lab” section below.
The site is a completely "lights out" facility housing over 7,500 servers and associated storage. They use remote control power strips to control the power cycling of systems. They initially used APC Power Distribution Units, but saw a market opportunity and designed their own switchable PDU product. The site was manned by data center manager and security guards.
They have a very stringent access control policy for employees. For an employee to gain access to perform work there must be an active, approved ticket in their tracking system. The employee swipes their badge for access. The guard, using the swiped data, is presented with any tracking tickets the employee may have assigned. There must be a ticket approved, matching the time window they are attempting to access the center for them to gain access. If there is not a match, they do not gain access.
They use an automated build procedure for all of their servers with a standard base image. A key component of that build is their Dell Open Management software agent on all servers.
The Open Management software provides a inventory of physical equipment and running software. This is used for their inventory control and for ensuring disaster recovery currency. In addition to the software based inventory they perform a physical inventory every 3 to 4 months.
Lessons learned
• BIDMC does not fully exploit the value the HP Insight manager/agent we own. Like the Dell management software it can deliver server power consumption graphs, server temperature data and disaster recovery data on the services and applications running.
• BIDMC would benefit from a more tightly controlled process for hardware deployment in which data is recorded in a data base to be compared against the Insight reports and network switch data for cross inventory validation
Manufacturing Tour
They toured the manufacturing plant for servers and gaming systems. The manufacturing process is tightly integrated with the ordering system and is a just in time inventory model. The parts for a system arrive by truck 2 hours prior to being required. The product used for any particular system build is determined by the order placed.
The quality control infrastructure is extensive. Once a machine is built, it is burned in twice. Once briefly at the technician assembly area where it is confirmed the system powers up and the requested Bios and any preloaded software images are applied. It then passes on to a diagnostic rack were it is hooked up and specific diagnostics are run on all of the hardware.
Quality control is also applied to all of the cosmetics from the positioning of the tags on cards and the case to the appearance of the assembled product. If even an external inventory or FCC tag is misaligned the system will be rejected.
They use an interesting system to rank each technician, team, group and plant. Each one of these has their own metrics and the metrics roll up. The more complex the system being built, the more points awarded. The sooner a quality problem is located the fewer points deducted. The later a problem is detected the more points deducted progressively down the chain. This gives a high incentive to catch the a problem as early as possible. If a final Q/A engineer catches the problem the whole plant takes a quality hit.
Lessons Learned
• Dell offers the ability to have all servers ordered pre-imaged with an image the customer supplies and controls. This would seem to be a big time saver for BIDMC.
• The pre-loading of the image would also be beneficial for BIDMC workstations. A base image could be flashed with a script that would run on initial boot up. The script could prompt for the type of system this was to be, point back to a second script and the system initialization would be completed. In that model, the system could be unpacked – moved to the users desk, the tech on connecting the system would answer the initial boot question and walk away.
Data Center Engineering Lab
They met with a representative from the Data Center Engineering Lab to talk about the futures of Data Center design – in particular areas of cooling.
Dell maintains a 1500 sq ft data center to test the different cooling technologies and techniques in. The racks in the test areas are filled with shells of servers that are basically large toasters. They can be controlled to generate amounts of heat to simulate data center load.
The most promising cooling technique is hot aisle containment. There are number of methods to contain and provide cooling. This is the method that they will be using in their own data center. Their studies have shown the techniques provides for smaller foot print, more efficient, targeted cooling which allows the data center ambient temperature to be raised. It also reduces the power used for cooling, and allows for higher power/utilization of the server thus getting the power supply efficiencies that come with higher utilization.
Dell Servers/Blades
Dell is about to begin shipping their next generation blade server technology. Their chassis holds 16 blade servers or combinations of blades and storage as needed. The design objectives and features are similar to other vendors. They claim a 7 to 10 year life cycle for the chassis, the ability to mix and match different generations of blades that might be issued during the chassis life and fully redundant power and embedded switches. Dell also stresses a green theme, highlighting dynamic fan and power supply efficiencies. They have built in some temperature and load sensing to auto adjust the power consumption and shutdown some components.
From a needs perspective Dell stated they see the blade server market as solving three problems 1 – Footprint, 2 – Cabling , 3 – Power issues.
Lessons Learned
•The packaging and engineering of the blade servers is well done The granularity of control for power and components is a nice touch.
• Dell ranks their applications by server need. Based on the applications needs the application is placed in VM, on a blade, or on a standalone server. This requires upfront assessment of an application before deployment.
Summary
• Dell is working to complete their line of services and products to meet enterprise needs. They have made a significant improvement/advancement in their blade servers. They are positioning themselves as leaders in data center design relative to power/cooling.
• Dell has a systems management software package, Open Management. This provides full management services to their and third party products. The interesting features were the recording , graphing, reporting on each servers power consumption and operating temperature. Limits/ranges could be sent for the sending alerts etc.
• There is an opportunity through the use of addressable power strips to use some logic/intelligence to turn off systems when they are not required. The best opportunity is in the evenings to possibly turn off portions of clusters or systems that do not need to be operational during the evening.
A great visit and many lessons learned about data center management in general. Thanks to Dell for their time.
Data Center Tour
They toured the main Dell data center in Round Rock. This was one of Dell's two Tier III data centers, reduced from the dispersed 16 data center model they used from 2001-2003. Cooling and power were left the way that they had been designed at the time of the acquisition. The system delivers cool air from the ceiling and from the floor. They acknowledged that it was not optimal and are making plans for a re-vamp. More on the plans under the “Data Center Engineering Lab” section below.
The site is a completely "lights out" facility housing over 7,500 servers and associated storage. They use remote control power strips to control the power cycling of systems. They initially used APC Power Distribution Units, but saw a market opportunity and designed their own switchable PDU product. The site was manned by data center manager and security guards.
They have a very stringent access control policy for employees. For an employee to gain access to perform work there must be an active, approved ticket in their tracking system. The employee swipes their badge for access. The guard, using the swiped data, is presented with any tracking tickets the employee may have assigned. There must be a ticket approved, matching the time window they are attempting to access the center for them to gain access. If there is not a match, they do not gain access.
They use an automated build procedure for all of their servers with a standard base image. A key component of that build is their Dell Open Management software agent on all servers.
The Open Management software provides a inventory of physical equipment and running software. This is used for their inventory control and for ensuring disaster recovery currency. In addition to the software based inventory they perform a physical inventory every 3 to 4 months.
Lessons learned
• BIDMC does not fully exploit the value the HP Insight manager/agent we own. Like the Dell management software it can deliver server power consumption graphs, server temperature data and disaster recovery data on the services and applications running.
• BIDMC would benefit from a more tightly controlled process for hardware deployment in which data is recorded in a data base to be compared against the Insight reports and network switch data for cross inventory validation
Manufacturing Tour
They toured the manufacturing plant for servers and gaming systems. The manufacturing process is tightly integrated with the ordering system and is a just in time inventory model. The parts for a system arrive by truck 2 hours prior to being required. The product used for any particular system build is determined by the order placed.
The quality control infrastructure is extensive. Once a machine is built, it is burned in twice. Once briefly at the technician assembly area where it is confirmed the system powers up and the requested Bios and any preloaded software images are applied. It then passes on to a diagnostic rack were it is hooked up and specific diagnostics are run on all of the hardware.
Quality control is also applied to all of the cosmetics from the positioning of the tags on cards and the case to the appearance of the assembled product. If even an external inventory or FCC tag is misaligned the system will be rejected.
They use an interesting system to rank each technician, team, group and plant. Each one of these has their own metrics and the metrics roll up. The more complex the system being built, the more points awarded. The sooner a quality problem is located the fewer points deducted. The later a problem is detected the more points deducted progressively down the chain. This gives a high incentive to catch the a problem as early as possible. If a final Q/A engineer catches the problem the whole plant takes a quality hit.
Lessons Learned
• Dell offers the ability to have all servers ordered pre-imaged with an image the customer supplies and controls. This would seem to be a big time saver for BIDMC.
• The pre-loading of the image would also be beneficial for BIDMC workstations. A base image could be flashed with a script that would run on initial boot up. The script could prompt for the type of system this was to be, point back to a second script and the system initialization would be completed. In that model, the system could be unpacked – moved to the users desk, the tech on connecting the system would answer the initial boot question and walk away.
Data Center Engineering Lab
They met with a representative from the Data Center Engineering Lab to talk about the futures of Data Center design – in particular areas of cooling.
Dell maintains a 1500 sq ft data center to test the different cooling technologies and techniques in. The racks in the test areas are filled with shells of servers that are basically large toasters. They can be controlled to generate amounts of heat to simulate data center load.
The most promising cooling technique is hot aisle containment. There are number of methods to contain and provide cooling. This is the method that they will be using in their own data center. Their studies have shown the techniques provides for smaller foot print, more efficient, targeted cooling which allows the data center ambient temperature to be raised. It also reduces the power used for cooling, and allows for higher power/utilization of the server thus getting the power supply efficiencies that come with higher utilization.
Dell Servers/Blades
Dell is about to begin shipping their next generation blade server technology. Their chassis holds 16 blade servers or combinations of blades and storage as needed. The design objectives and features are similar to other vendors. They claim a 7 to 10 year life cycle for the chassis, the ability to mix and match different generations of blades that might be issued during the chassis life and fully redundant power and embedded switches. Dell also stresses a green theme, highlighting dynamic fan and power supply efficiencies. They have built in some temperature and load sensing to auto adjust the power consumption and shutdown some components.
From a needs perspective Dell stated they see the blade server market as solving three problems 1 – Footprint, 2 – Cabling , 3 – Power issues.
Lessons Learned
•The packaging and engineering of the blade servers is well done The granularity of control for power and components is a nice touch.
• Dell ranks their applications by server need. Based on the applications needs the application is placed in VM, on a blade, or on a standalone server. This requires upfront assessment of an application before deployment.
Summary
• Dell is working to complete their line of services and products to meet enterprise needs. They have made a significant improvement/advancement in their blade servers. They are positioning themselves as leaders in data center design relative to power/cooling.
• Dell has a systems management software package, Open Management. This provides full management services to their and third party products. The interesting features were the recording , graphing, reporting on each servers power consumption and operating temperature. Limits/ranges could be sent for the sending alerts etc.
• There is an opportunity through the use of addressable power strips to use some logic/intelligence to turn off systems when they are not required. The best opportunity is in the evenings to possibly turn off portions of clusters or systems that do not need to be operational during the evening.
A great visit and many lessons learned about data center management in general. Thanks to Dell for their time.
Jumat, 25 April 2008
Cool Technology of the Week
This week I led the Spring IT Town meeting at Harvard Medical School and one of the issues we discussed was the difficulty of protecting intellectual property on hard drives we're replacing. How does a drive containing sensitive clinical, financial or research data get sanitized when EMC or other storage vendor replaces a drive that has gone bad?
I found a great overview of the approaches to the data sanitization problem for hard drives.
I also found an article from NIST which lists every type of media (e.g. PDA's, tape, fax, servers, network devices, and more) and the preferred method for sanitizing them.
These articles referred to "secure erase" for ATA drives. I've not heard of this before, but the University of California at San Diego's Center for Magnetic Recording Research describes the protocol in detail. Apparently, it is available in most ATA drives manufactured in the past several years. They also have a free software utility that accesses the secure erase feature on ATA drives. One CIO describes her search for commercial products to address this issue. A commercial appliance is available from Ensconce Data Technology which incorporates the same data sanitization technology.
My cool technology of the week is the secure erase feature on ATA drives, which solves many of our problems for sanitizing data before we return drives to manufacturers.
Given the visibility of identity theft and a focus on securing data in the enterprise, I hope to inventory our disposal methods and the techniques being used to sanitize them. Among the items of interest would be cell phones, blackberry devices, problem disks replaced by EMC, tape, USB drives, and others. I'm seeking to add staff to our security and disaster recovery areas at HMS and this task along with user education/communication will be high on their agenda.
I found a great overview of the approaches to the data sanitization problem for hard drives.
I also found an article from NIST which lists every type of media (e.g. PDA's, tape, fax, servers, network devices, and more) and the preferred method for sanitizing them.
These articles referred to "secure erase" for ATA drives. I've not heard of this before, but the University of California at San Diego's Center for Magnetic Recording Research describes the protocol in detail. Apparently, it is available in most ATA drives manufactured in the past several years. They also have a free software utility that accesses the secure erase feature on ATA drives. One CIO describes her search for commercial products to address this issue. A commercial appliance is available from Ensconce Data Technology which incorporates the same data sanitization technology.
My cool technology of the week is the secure erase feature on ATA drives, which solves many of our problems for sanitizing data before we return drives to manufacturers.
Given the visibility of identity theft and a focus on securing data in the enterprise, I hope to inventory our disposal methods and the techniques being used to sanitize them. Among the items of interest would be cell phones, blackberry devices, problem disks replaced by EMC, tape, USB drives, and others. I'm seeking to add staff to our security and disaster recovery areas at HMS and this task along with user education/communication will be high on their agenda.
Kamis, 24 April 2008
Go Climb a Rock
It's Thursday, so it's time for a personal introspection blog.At times I get quizzical looks for being vegan, playing the Japanese flute, or wearing black. However, the most unusual looks from my peers occur when they see photos like this one of Dark Shadows on Mescalito North in Red Rocks, Nevada.
Winter mountaineering is a good way to get away from your cell phone (the battery life is 2 minutes at -40F), but why climb a rock?
Think of climbing a mountain as a giant Rubik's cube - a wonderful mental exercise. Climbing requires a well orchestrated combination of gear, route finding, movement, and teamwork to make it to the top.
Here's how it's done.
1. Make the approach - some climbs are a 5 minute walk from the road and some are 10 miles through bush, over stream crossings, and up thousands of feet. The Grand Teton is usually a day of hiking followed by a 2am departure which puts you at the base of the technical portion of the summit pyramid at sunrise. The climb to the top takes until 8am or so, enabling a retreat before the usual afternoon thunderstorms hit the summit. Many Yosemite approaches, such as Half Dome, require hours of tricky route finding on poorly marked trails before the climbing begins. Of course, you must carry everything with you - climbing shoes, harness, rope, food, water, and extra clothing during the approach.
2. Prepare to climb - At the base of the climb, you put on your harness, unwind your rope, put on your climbing shoes, and do safety checks with your partner. Safe climbing requires at least two people - one to climb and one to control the rope, catching the leader if a fall occurs. Once gear and knots are checked, climbing can begin.
3. Lead the pitch - The leader uses a combination of footholds, handholds, cracks, and friction to climb up the rock face. Every 10 feet or so, the leader places a piece of protection into a crack and clips the rope to that protection. Modern climbing is "clean climbing" that does not involve pitons or any gear that damages the rock. Spring loaded cams, metal nuts/stoppers, and slings around natural features such as trees provide temporary protection that support the rope so your climbing partner can catch a fall.
If you consider the physics of leading, it's where the bulk of the risk of climbing occurs. If you place a piece of protection every 10 feet, you'll fall 20 feet if you slip off the rock, since 10 feet of rope to the last piece of protection means you'll fall 10 feet below that piece before you stop. A 170 pound climber falling 20 feet generates a lot of force on the climber's body, the rope and the person controlling the rope.
Routes are divided into segments of under 200 feet in length because that is the length of the most common climbing rope.
Route difficulty is graded on a scale from 5.1 (climbing a ladder) to 5.15 (basically climbing an inverted slab of glass with butter on your hands). I lead 5.8 and follow 5.10a, which is climbing a vertical to overhanging wall with dime-sized handholds and footholds.
4. Prepare the belay - Once you've climbed the pitch, you must set up a safe and secure attachment to support your climbing partner as he or she climbs. Typically, I place 3 pieces of protection in the rock for redundancy, then use a 16 foot loop of rope or sling material called a cordelette to provide a secure attachment point for me and my climbing partner. Once I'm safe and I've prepared the rope to support my climbing partner, I give the signal to my partner to begin climbing.
5. Bring up your partner - When your partner climbs, it's called seconding the pitch, since you were the primary or lead climber. Seconding is not particularly risky because you are supported by a rope from above if you fall. Mentally its easier but it has the same physical challenges as leading the climb.
6. Repeat - My climbing partner and I do swinging leads, alternating leading and seconding, so we each take half the risk. We do this until we're at the top of the mountain. Some major climbs in Yosemite can be 15 pitches or more, which can take half a day to climb. We do not typically do "big walls" which require you to sleep on a portaledge strapped onto the face of the mountain. We'd rather have a very long climbing day and then descend before nightfall.
7. Descent - In some ways, descent is the most dangerous part of the climb. Rappelling down the mountain is risky because a gear failure means death or injury. When we're climbing up, we typically do not fall - the gear is there for safety just in case. When you rappel down the mountain, the gear is all that is keeping you from falling. For this reason, we typically walk off most climbs, down hiking trails rather than rappelling. We always carry headlamps and a rain jacket in our packs when doing long alpine routes, just in case we're delayed or trapped by a storm.
Great climbing areas in the Northeast are the Shawangunks in New Paltz, New York; Cathedral Ledges and Whitehorse Slabs in North Conway, New Hampshire; Franconia Notch near Lincoln, New Hampshire; and Rumney near Plymouth, New Hampshire.
In the US, places like Red Rocks, Nevada; Joshua Tree, California; and the Tetons, Wyoming are extraordinary. However, nothing quite measures up to grandeur of Yosemite and the Eastern Sierra. My Yosemite climbing schedule this year is
August 12 Tenaya Peak
August 13 Cathedral Peak/Eichorn Pinnacle - per my New Year's Resolutions, I'll play a Japanese Flute concert from the top of Eichorn Pinnacle if the weather holds.
August 14 Fairview Dome
August 15 North approach to Mt. Conness
August 16 Tioga Crest
Rock climbing is an incredible way to focus the mind, experience the outdoors from a new perspective, build teamwork, and work with technical gear all at the same time. As I age, the routes I'll attempt will likely get easier, but whether they are 5.5 or 5.10a, the joy of a mile of air under your feet is the same!
Rabu, 23 April 2008
Designing the Ideal Electronic Health Record
Yesterday, I keynoted a Veterans Administration meeting via teleconference (part of my effort to reduce travel, improve my carbon footprint, and be increasingly virtual) on the topic of designing the ideal electronic health record.
I was posed a simple question - If I had infinite resources, infinite time, and no legacy compatibility issues, how would I design the electronic health record of the future?
Here's my answer:
General
The web is the way. Given the 24x7 nature of healthcare, the need for physicians to be in many physical locations, and the multitude of clinician computing devices, the ideal EHR should be web-based, browser neutral and run flawlessly on every operating system. I highly recommend the use of AJAX techniques to give physicians a more real time interactive experience. Client/Server may have some user interface advantages, but it's just too challenging to install thick clients on every clinician computing device. Citrix is an expensive and sometimes slow remote access solution. Native web works.
Data in medicine is stored hierarchically i.e. a patient has multiple visits with multiple labs, with multiple results. This is a tree of data with the patient as the root and the lab values as the leaves. Using a hierarchical database such as Intersystems' Cache ensures that data for clinical care is stored in this tree format and thus can be very rapidly retrieved, ensuring fast response times for clinician users. For population health, clinical research, and performance reporting, relational databases work very well. Thus, I recommend a hierarchical database for the clinical care applications and relational data marts for the research applications.
The ideal EHR should incorporate decision support in laboratory, medication, and radiology ordering. EHRs should include "Event Driven Medicine" alerts about critical clinical issues and patient specific reminders about preventative/wellness care. Event Driven Medicine is the transformation of data into information, knowledge and wisdom based on decision support, business rules and timely notification of clinicians.
The EHR should include an easy to read clinical summary of all active patient problems, medications, visits, and labs and should be able to export this summary to personal health records such as Google Health, Microsoft Health Vault and Dossia.
Problem Lists
Problems should be entered via an electronic pick list of vocabulary controlled terms using SNOMED CT. The community of caregivers - PCPs, specialsts, ED physicians and hospitalists should be able maintain this problem list collectively, using social networking type tools. Call this Wikipedia for the patient. All caregivers should be able to associate notes and medications with entries on the problem list, making it easy to filter notes by problem and discontinue medications that are problem-specific when problems are resolved.
Medications
Medication Management features should include e-Prescribing for new medications, automatically linked to payer-specific formularies, electronic real time pre-auth/eligibility for high cost therapies, links to lifetime medication history from retail pharmacy and payer databases, and safety checking for drug/drug and drug/allergy interactions. Pharmacy initiated renewal workflow would reduce calls to the physician's office to refill medications.
Ideally, medication reconciliation features should include pre-population of the medication list based on the lifetime medication history from retail pharmacy, payer databases and personal health record applications. Using the same social networking type approach as mentioned with problem lists, all caregivers should be able to update/change/edit/comment on patient medications to keep them current. One click quick picks of commonly used medications should be available to make ordering Tylenol as easy as ordering books on Amazon.
Allergies
Allergies should be recorded by caregivers using vocabulary controlled entries for therapeutics, foods and environmental substances. Reaction type and severity should be codified as well as the identity of the allergy observer/documentation source i.e. did the patient self report that their Mom saw a rash to pencillin 30 years ago or did an ICU nurse watch the patient anaphylax to pencillin?
Visits
Each visit should be documented with a reason for visit (symptoms or problem), a pre-existing condition flag if the patient has had this before, a diagnosis, a list of therapies given, and the followup arranged.
Notes
Notes should be entered via structured and unstructured electronic forms. All text data should be searchable, so that physicians can easily locate old notes. Templates that are disease specific and macros that are specialty specific should be available to make documenting easier. Voice recognition for automated entry of free text should be available. Workflow for signing notes and forwarding notes to other providers should be easy to use.
Laboratory results
Laboratory results should be displayable in several ways - by date, by class of lab, by single result trended over time and in screening sheet format. Screening sheets are lists of disease specific lab results combined with decision support. For example, a diabetic screening sheet would include glucose, hemoglobin a1c, lipids, recent eye exam results, podiatry consults, and urinalysis. Alerts and reminders should be generated based on disease state, lab value, and trends.
As results are delivered, especially important results, clinicians should electronically sign an acknowledgement of lab result notification, ensuring that appropriate next steps are taken for patient care.
Radiology results
As mentioned in my recent blog on image management, all "ologies" should be stored in one place in the EHR and all should be viewable with a single electronic viewer. Radiology, Cardiology, GI, Pulmonology, Echo, Vascular, and Gynecology images should be easily viewable and these images should be managed according to business rules i.e. retained as required for medical record compliance, archived when no longer relevant etc.
Orders
Electronic ordering should include medications, Oncology Management, Laboratories, Radiology and general care (i.e. ordering home care supplies, wheelchairs etc). Orders should automatically be routed to the department and staff responsible for executing them.
Health Information Exchange
The EHR should be able to retrieve medication lists and clinical summaries from outside institutions as part of local/regional healthcare information exchange. EHRs should be able to send data to personal health records and receive patient entered data, especially telemetry data from home devices like glucometers, from personal health records.
Data Marts
Every night, data from the EHR should be exported to data marts for appropriate use with IRB approval for clinical trials, clinical research, population health analysis, performance measurement, and quality improvement.
At BIDMC, we're continuously improving our systems and we're well on the road to achieving much of this functionality. Of course, we'll never be done because the goal of the ultimate electronic health record is a continuously evolving target.
I was posed a simple question - If I had infinite resources, infinite time, and no legacy compatibility issues, how would I design the electronic health record of the future?
Here's my answer:
General
The web is the way. Given the 24x7 nature of healthcare, the need for physicians to be in many physical locations, and the multitude of clinician computing devices, the ideal EHR should be web-based, browser neutral and run flawlessly on every operating system. I highly recommend the use of AJAX techniques to give physicians a more real time interactive experience. Client/Server may have some user interface advantages, but it's just too challenging to install thick clients on every clinician computing device. Citrix is an expensive and sometimes slow remote access solution. Native web works.
Data in medicine is stored hierarchically i.e. a patient has multiple visits with multiple labs, with multiple results. This is a tree of data with the patient as the root and the lab values as the leaves. Using a hierarchical database such as Intersystems' Cache ensures that data for clinical care is stored in this tree format and thus can be very rapidly retrieved, ensuring fast response times for clinician users. For population health, clinical research, and performance reporting, relational databases work very well. Thus, I recommend a hierarchical database for the clinical care applications and relational data marts for the research applications.
The ideal EHR should incorporate decision support in laboratory, medication, and radiology ordering. EHRs should include "Event Driven Medicine" alerts about critical clinical issues and patient specific reminders about preventative/wellness care. Event Driven Medicine is the transformation of data into information, knowledge and wisdom based on decision support, business rules and timely notification of clinicians.
The EHR should include an easy to read clinical summary of all active patient problems, medications, visits, and labs and should be able to export this summary to personal health records such as Google Health, Microsoft Health Vault and Dossia.
Problem Lists
Problems should be entered via an electronic pick list of vocabulary controlled terms using SNOMED CT. The community of caregivers - PCPs, specialsts, ED physicians and hospitalists should be able maintain this problem list collectively, using social networking type tools. Call this Wikipedia for the patient. All caregivers should be able to associate notes and medications with entries on the problem list, making it easy to filter notes by problem and discontinue medications that are problem-specific when problems are resolved.
Medications
Medication Management features should include e-Prescribing for new medications, automatically linked to payer-specific formularies, electronic real time pre-auth/eligibility for high cost therapies, links to lifetime medication history from retail pharmacy and payer databases, and safety checking for drug/drug and drug/allergy interactions. Pharmacy initiated renewal workflow would reduce calls to the physician's office to refill medications.
Ideally, medication reconciliation features should include pre-population of the medication list based on the lifetime medication history from retail pharmacy, payer databases and personal health record applications. Using the same social networking type approach as mentioned with problem lists, all caregivers should be able to update/change/edit/comment on patient medications to keep them current. One click quick picks of commonly used medications should be available to make ordering Tylenol as easy as ordering books on Amazon.
Allergies
Allergies should be recorded by caregivers using vocabulary controlled entries for therapeutics, foods and environmental substances. Reaction type and severity should be codified as well as the identity of the allergy observer/documentation source i.e. did the patient self report that their Mom saw a rash to pencillin 30 years ago or did an ICU nurse watch the patient anaphylax to pencillin?
Visits
Each visit should be documented with a reason for visit (symptoms or problem), a pre-existing condition flag if the patient has had this before, a diagnosis, a list of therapies given, and the followup arranged.
Notes
Notes should be entered via structured and unstructured electronic forms. All text data should be searchable, so that physicians can easily locate old notes. Templates that are disease specific and macros that are specialty specific should be available to make documenting easier. Voice recognition for automated entry of free text should be available. Workflow for signing notes and forwarding notes to other providers should be easy to use.
Laboratory results
Laboratory results should be displayable in several ways - by date, by class of lab, by single result trended over time and in screening sheet format. Screening sheets are lists of disease specific lab results combined with decision support. For example, a diabetic screening sheet would include glucose, hemoglobin a1c, lipids, recent eye exam results, podiatry consults, and urinalysis. Alerts and reminders should be generated based on disease state, lab value, and trends.
As results are delivered, especially important results, clinicians should electronically sign an acknowledgement of lab result notification, ensuring that appropriate next steps are taken for patient care.
Radiology results
As mentioned in my recent blog on image management, all "ologies" should be stored in one place in the EHR and all should be viewable with a single electronic viewer. Radiology, Cardiology, GI, Pulmonology, Echo, Vascular, and Gynecology images should be easily viewable and these images should be managed according to business rules i.e. retained as required for medical record compliance, archived when no longer relevant etc.
Orders
Electronic ordering should include medications, Oncology Management, Laboratories, Radiology and general care (i.e. ordering home care supplies, wheelchairs etc). Orders should automatically be routed to the department and staff responsible for executing them.
Health Information Exchange
The EHR should be able to retrieve medication lists and clinical summaries from outside institutions as part of local/regional healthcare information exchange. EHRs should be able to send data to personal health records and receive patient entered data, especially telemetry data from home devices like glucometers, from personal health records.
Data Marts
Every night, data from the EHR should be exported to data marts for appropriate use with IRB approval for clinical trials, clinical research, population health analysis, performance measurement, and quality improvement.
At BIDMC, we're continuously improving our systems and we're well on the road to achieving much of this functionality. Of course, we'll never be done because the goal of the ultimate electronic health record is a continuously evolving target.
Selasa, 22 April 2008
Decision Support for Inpatient Systems
I've written about the 10 projects that keep me up at night and published my clinical systems mid year strategic update. In addition, as a physician CIO, I tend to have a few projects that receive more attention and guidance from me than others.
The three areas that are my passion and focus in 2008-2010 are Clinical Documentation, Decision Support, and an Integrated Electronic Record throughout the community. I wrote about Clinical Documentation last week. The Integrated Electronic Record is next week. I've covered Outpatient Decision Support earlier, so this week is an overview of all our Inpatient Decision Support efforts at Beth Israel Deaconess. You'll see that we have thousands of decision support rules, updated regularly, which are fully integrated into our inpatient systems.
Drug interactions and alerts
a) Drug duplicate warnings - Identifies duplicates using chemical component information that is included with First Data Bank (FDB), the commercial drug database underlying our pharmacy and provider order entry systems. Component information is updated via monthly FDB updates.
b) Drug-drug interactions - Identifies interactions using chemical components and rules included with the FDB database. Displays only the classes of alerts identified as clinically significant by Pharmacy, to ensure clinicians are not overwhelmed with minor interactions. Rules are updated via monthly FDB updates. Clinical significance filters are maintained in a dictionary by Pharmacy.
c) Drug-allergy interactions - Identifies interactions using chemical components included with the FDB database. Components are updated via monthly FDB updates.
d) Drug Substitutions – Alerts the ordering provider with suggested substitutions for therapeutic equivalents on the inpatient formulary, which is maintained by Pharmacy.
Default dosing
There are currently 1,545 entries in the Pharmacy Provider Order Entry dictionary with default dosing schemas defined. These are maintained by Pharmacy.
Renal Dosing
Targeted drugs, rules and default dosing are maintained in a dictionary by Pharmacy. There are currently 48 renally dosed drugs.
Diagnosis or Indication based dosing
Target drugs, rules and default dosing are maintained in a dictionary by Pharmacy, such as ciprofloxacin and chemotherapy agents used for non-oncological reasons such as cytoxan.
Geriatric alerts
Beers criteria are used to alert physicians to age-specific medication issues. Information is updated via monthly FDB updates.
Heparin, insulin and enoxaparin
Ordering of these high risk medications is done via automated protocols and guidelines to promote best practice dosing. These are updated as best practices change.
Information Displayed on Medication Ordering Screens
a) Screens display the patient’s most recent relevant labs specific to the drug being ordered. The relationship between drug and lab(s) to display is maintained in a dictionary by the Pharmacy
b) Informational text about ordering parameters for the drug is displayed. These are maintained in a dictionary by the Pharmacy. A link to Micromedex is also available on the ordering screen.
Nurse instructions for drug handling
Custom instructions are displayed on Medication Administration Record labels. These are maintained by the Pharmacy.
Information Displayed on Lab Ordering Screen
a) Messages appear during ordering that inform clinicians about best practices such as guidance for ordering heparin dependent antibodies. These are maintained in a dictionary by the Lab.
b) Links appear to the online lab manual for each test ordered. Thousands of lab tests are documented including all the details on how the specimen is collected and processed. The Lab updates this manual regularly.
Blood bank
Specialized screens appear to provide pertinent clinical information when blood products are ordered.
Total Parenteral Nutrition
Guidelines, relevant labs and prior day’s TPN order appear automatically.
Consequent Orders
a) IV access flush ordering -POE automatically generates the correct flush order when documenting IV status
b) Blood products – POE gives current information about active specimens in the blood bank and can generate a type and screen if necessary
c) Mechanical ventilation- POE automatically suggests mouth care orders after ventilation is ordered
Quick access to reference/informational screens
Specific links to guidelines/web sites appear on many POE screens. For example, a link to the current weaning protocol is available directly on the mechanical ventilation order screen.
Quick access to patient specific data in other clinical systems
Specific links to data in other information systems appear on many Provider Order Entry screens. For example, a link to display transfusion restrictions available in the Blood Bank system appears on the blood product ordering screen.
Alerts and reminders for items such as pneumovax and influenza
Providers are prompted at appropriate points over the course of a hospital admission to order and document outcomes.
Order sets
"Packages" of orders that can be rapidly entered as a group are available to all clinicians. These are updated as clinical practice changes. There are currently 95 inpatient admission, postoperative, transfer and procedure order sets (5 megabyte download) and 195 outpatient chemotherapy regimens.
Hydration protocol to minimize risk of iodinated contrast nephropathy
Provider Order Entry recommends specific IV fluid orders when ordering pre-procedure prep orders.
You can see that the task of providing comprehensive decision support for our inpatient systems involves thousands of rules, kept updated by pharmacy, lab, and IS staff, as guided by our various steering committees. Only through the use of this much decision support can we ensure that data is transformed into information, knowledge and wisdom.
The three areas that are my passion and focus in 2008-2010 are Clinical Documentation, Decision Support, and an Integrated Electronic Record throughout the community. I wrote about Clinical Documentation last week. The Integrated Electronic Record is next week. I've covered Outpatient Decision Support earlier, so this week is an overview of all our Inpatient Decision Support efforts at Beth Israel Deaconess. You'll see that we have thousands of decision support rules, updated regularly, which are fully integrated into our inpatient systems.
Drug interactions and alerts
a) Drug duplicate warnings - Identifies duplicates using chemical component information that is included with First Data Bank (FDB), the commercial drug database underlying our pharmacy and provider order entry systems. Component information is updated via monthly FDB updates.
b) Drug-drug interactions - Identifies interactions using chemical components and rules included with the FDB database. Displays only the classes of alerts identified as clinically significant by Pharmacy, to ensure clinicians are not overwhelmed with minor interactions. Rules are updated via monthly FDB updates. Clinical significance filters are maintained in a dictionary by Pharmacy.
c) Drug-allergy interactions - Identifies interactions using chemical components included with the FDB database. Components are updated via monthly FDB updates.
d) Drug Substitutions – Alerts the ordering provider with suggested substitutions for therapeutic equivalents on the inpatient formulary, which is maintained by Pharmacy.
Default dosing
There are currently 1,545 entries in the Pharmacy Provider Order Entry dictionary with default dosing schemas defined. These are maintained by Pharmacy.
Renal Dosing
Targeted drugs, rules and default dosing are maintained in a dictionary by Pharmacy. There are currently 48 renally dosed drugs.
Diagnosis or Indication based dosing
Target drugs, rules and default dosing are maintained in a dictionary by Pharmacy, such as ciprofloxacin and chemotherapy agents used for non-oncological reasons such as cytoxan.
Geriatric alerts
Beers criteria are used to alert physicians to age-specific medication issues. Information is updated via monthly FDB updates.
Heparin, insulin and enoxaparin
Ordering of these high risk medications is done via automated protocols and guidelines to promote best practice dosing. These are updated as best practices change.
Information Displayed on Medication Ordering Screens
a) Screens display the patient’s most recent relevant labs specific to the drug being ordered. The relationship between drug and lab(s) to display is maintained in a dictionary by the Pharmacy
b) Informational text about ordering parameters for the drug is displayed. These are maintained in a dictionary by the Pharmacy. A link to Micromedex is also available on the ordering screen.
Nurse instructions for drug handling
Custom instructions are displayed on Medication Administration Record labels. These are maintained by the Pharmacy.
Information Displayed on Lab Ordering Screen
a) Messages appear during ordering that inform clinicians about best practices such as guidance for ordering heparin dependent antibodies. These are maintained in a dictionary by the Lab.
b) Links appear to the online lab manual for each test ordered. Thousands of lab tests are documented including all the details on how the specimen is collected and processed. The Lab updates this manual regularly.
Blood bank
Specialized screens appear to provide pertinent clinical information when blood products are ordered.
Total Parenteral Nutrition
Guidelines, relevant labs and prior day’s TPN order appear automatically.
Consequent Orders
a) IV access flush ordering -POE automatically generates the correct flush order when documenting IV status
b) Blood products – POE gives current information about active specimens in the blood bank and can generate a type and screen if necessary
c) Mechanical ventilation- POE automatically suggests mouth care orders after ventilation is ordered
Quick access to reference/informational screens
Specific links to guidelines/web sites appear on many POE screens. For example, a link to the current weaning protocol is available directly on the mechanical ventilation order screen.
Quick access to patient specific data in other clinical systems
Specific links to data in other information systems appear on many Provider Order Entry screens. For example, a link to display transfusion restrictions available in the Blood Bank system appears on the blood product ordering screen.
Alerts and reminders for items such as pneumovax and influenza
Providers are prompted at appropriate points over the course of a hospital admission to order and document outcomes.
Order sets
"Packages" of orders that can be rapidly entered as a group are available to all clinicians. These are updated as clinical practice changes. There are currently 95 inpatient admission, postoperative, transfer and procedure order sets (5 megabyte download) and 195 outpatient chemotherapy regimens.
Hydration protocol to minimize risk of iodinated contrast nephropathy
Provider Order Entry recommends specific IV fluid orders when ordering pre-procedure prep orders.
You can see that the task of providing comprehensive decision support for our inpatient systems involves thousands of rules, kept updated by pharmacy, lab, and IS staff, as guided by our various steering committees. Only through the use of this much decision support can we ensure that data is transformed into information, knowledge and wisdom.
Langganan:
Postingan (Atom)