CST project: North York General Hospital site visit assessment ...

1

CST Project:

North York General Hospital Site Visit

Assessment Summary

Document Author: Dr. Jeremy Theal, Sonia Pagliaroli, Donna Alfoja, and Derrick Kwan

CST Contributors: Shaina Reid, Amr Kabesh, Prab Gill, Shannon Malovec, Bruce Long, Alain Gagnon, Grant McCullough, Donna Stanton, Kelle Payne, Vicky Crompton, David Nichol

Date: October 6-10, 2014

2

Table of Contents 1.0 Document Purpose, Executive Summary & Summary of Recommendations .................................. 1

1.1 Purpose ......................................................................................................................................... 1 1.2 Executive Summary ....................................................................................................................... 2 1.3 Summary of Recommendations from all sections ...................................................................... 12

2.0 Site Visit Schedule ........................................................................................................................... 20

3.0 Key Decisions .................................................................................................................................. 21

3.1 CDG Decisions ............................................................................................................................. 21 3.2 PSC Decisions .............................................................................................................................. 21 3.3 PDG Decision ............................................................................................................................... 21 3.4 DDG Decisions ............................................................................................................................. 22 3.5 Other Key Decisions .................................................................................................................... 22

4.0 Key Strategy & Governance Topics ................................................................................................. 22

General Recommendations on Project Structure & Timeline .................................................................... 22

4.1 Interdisciplinary Documentation ................................................................................................ 23 4.2 Order Sets ................................................................................................................................... 25 4.3 Alerts/Clinical Decision Support.................................................................................................. 26 4.4 Dose Ranges ................................................................................................................................ 27 4.5 Quality Assurance/Design Validation .......................................................................................... 28 4.6 Message Centre .......................................................................................................................... 28 4.7 Strategy to Identify and Quantify Impact to Operations ............................................................ 28 4.8 Mandatory Documentation Requirements ................................................................................. 29 4.9 BMDI ........................................................................................................................................... 29 4.10 Charge Capture ........................................................................................................................... 30 4.11 Enterprise Build versus Localization Build .................................................................................. 31 4.12 Reporting..................................................................................................................................... 31 4.13 Operational Planning: Sustainment/Structure/Continuous Improvement ................................ 32 4.14 SNOMED / ICD 10 ........................................................................................................................ 33

5.0 Key Workflows ................................................................................................................................ 34

6.0 Design Teams .................................................................................................................................. 35

6.1 Provider ....................................................................................................................................... 35 6.2 Clinical Documentation / Maternity / Orders and Results ......................................................... 36 6.3 Medication Management ........................................................................................................... 38 6.4 Emergency Department .............................................................................................................. 41 6.5 Health Information Management / Scanning ............................................................................. 42 6.6 Medical Imaging .......................................................................................................................... 42 6.7 Registration / Scheduling ............................................................................................................ 43 6.8 Surgery ........................................................................................................................................ 44 6.9 Core ............................................................................................................................................. 45

7.0 Technical Teams .............................................................................................................................. 46

8.0 Clinical Transformation ................................................................................................................... 48

9.0 Implementation .............................................................................................................................. 49

3

10.0 Relevant documents ....................................................................................................................... 51

11.0 Appendix A: CDG Decisions ............................................................................................................. 52

12.0 Appendix B: PSC Decisions .............................................................................................................. 55

13.0 Appendix C: PDG Decisions ............................................................................................................. 58

14.0 Appendix D: DDG Decisions ............................................................................................................ 59

15.0 Appendix E: Other Key Decisions .................................................................................................... 63

16.0 Appendix F: Meeting Agendas ........................................................................................................ 65

1

1.0 Document Purpose, Executive Summary & Summary of Recommendations

1.1 Purpose This document is intended to provide a summary of the overall feedback as a result of the North York General Hospital (NYGH) site visit to Vancouver as part of the CST Project, occurring the week of October 6, 2014. The purpose of the site visit is for NYGH to provide their perspective, experience, and lessons learned from a project and operational support perspective on specified areas of the CST Project outlined below. In each section below the NYGH lessons learned, content shared and key recommendations from each session are summarized. For full session minutes, please request from the CST PMO.

2

1.2 Executive Summary

Overview

This executive summary highlights key findings from the week-long consulting visit conducted by NYGH at the CST project offices from October 6 to 10, 2014. A comprehensive review process was undertaken, in which the NYGH team met with executives, directors, managers and other project personnel to gain a broad perspective of current project state.

In the opinion of the consultants, some aspects of the project have been proceeding well; however, important risks to project success were also identified. These risks are organized into four main themes:

1) Project scope and roll-out strategy; 2) Project governance structure and workforce; 3) Clinical content design and clinician engagement; 4) Data governance

The themes define the sections of this report, in which both the identified risks and suggested mitigation strategies are outlined.

Positives of CST Project Current State

- Robust governance structure - Extensive clinician engagement in design - Economy of scale – creating design and build for multiple facilities in one project

1. Project Scope and Roll-Out Strategy

Due to the magnitude of organizations, and various system replacements included in scope, Big Bang makes sense as it supports a clean end of one system and start of a new. Attempting a phased approach would be challenging and could not be replicated across organizations, as systems being replaced may differ.

Risk #1:

During our meetings, we had noticed that project scope was not always clearly defined. When considering what to include in scope, determine workflows that could potentially be fragmented or result in lost efficiency if not included. For example, never break apart closed loop medication administration process, CPOE and eMAR must go together.

3

Suggested Mitigation Strategies:

- Perform an inventory of current processes (automated and manual) and future processes and solutions to be used. This will inform change management strategies and aid in the definition of scope. Our experience is that it requires more change management effort when moving clinicians from an existing system than moving from paper to electronic.

- Consider excluding physician documentation from scope. CPOE introduces enough change, which should be the primary focus. Often current physician documentation processes are based on dictation, and therefore already accessible to all on line. Our experience shows significant time and resource commitments are required in iterative physician documentation design to maximize workflow efficiencies, capture meaningful and standardized discrete data, and ensure clinician adoption.

- Consider including Bedside Medical Device Interface (BMDI) as it offers significant efficiencies in clinical documentation which in turn supports positive clinician adoption. The effort in setting up this technology is well work the benefits gained.

- Cardiology requires thought out strategy prior to integrating components within this implementation. Some components can be integrated into project scope, but if the plan is to procure a complete Cardiology Information system, then decisions made today may result in rework later.

Risk #2:

With a project of this magnitude and with the complexities of multiple organizations and existing systems, projecting a realistic rollout strategy is a “shot in the dark”. For the purposes of project and resource planning, estimated timelines can be developed, however when communicating go live dates to end users, it should be a firm date in order to avoid loss of confidence.


- Your first implementation will set the tone of all future implementation. Make sure it is not rushed. Wait to define your go live date until after clinicians have had an opportunity to “kick the tires” in design validation. This will provide an accurate pulse of effort still remaining and considerations that may have been overlooked.

- There will be many lessons from the first go live that you will need to correct prior to rolling out to subsequent organizations. Allow time in the plan to apply these lessons. We recommend at least 4-6 months (2 months support, 2-4 months to make necessary adjustments). Once you have replicated seamlessly to a new site, only then can you expedite rollout.

- Senior leadership needs to support an “All hands on deck” model minimizing all other competing

initiatives.

4

Risk #3:

Big-Bang go-live requires a well-defined support structure. With all new systems going live at once throughout the organization, all staff will be facing changes and will require support.


- We recommend 4-6 weeks, 24x7 on-site supports. Support should include peer to peer support wherever possible specifically physician “at the elbow” support.

- Need to segregate Clinical Informatics “builders” from front line support so they can manage issue resolution and process urgent change requests. It will be tempting to have them work with front line support since they are often most familiar on how application works, but this will result in delayed issue resolution and potential resource burnout as they are pulled in every direction.

- See detailed report for recommendations regarding setting up Go-Live command centre.

Project Governance Structure and Workforce

Risk #1:

The NYGH team observed that CST project structure has resulted in design and decision-making processes that are siloed. The working groups have overlapping accountability, there is no Cerner system build expertise at the table to guide design decisions. It also appears there is lack of clarity in project deliverables for each group. This approach can lead to three risks: 1) design/build/future state workflow that does not meet all clinical needs (for example, medication build might work well for the pharmacy team that designed it, but is unintuitive for nurses and physicians to use); 2) time is wasted because clinical groups are requesting or suggesting build that is not technically possible within Cerner or not best practice (clinicians would have to wait until their decisions are turned down by builders, then have to meet again to discuss options); and 3) without a central team to co-ordinate design/build decisions coming from different areas, there is a risk of inconsistency of build, duplicate build or missing items that will result in an unintuitive, inefficient and possibly unsafe system design.


- Consider developing a “Core” group that has representatives from all working groups and all disciplines that discuss all design decisions that cross working groups. Have a document management solution that is open and transparent that all working groups can view to see design decisions made and how they could impact their work.

- Develop standards and guidelines for build components. Examples include; o set definitions for when order tasks should and should not be used o if new orders/nomenclature need to be built, request rationale for deviation from original

data set o determine standards for order formats so display in orders tab is consistent

5

o centralized ESH role to ensure clinical events are not duplicated, nomenclature standards are followed and similar content is grouped appropriately for clinical consumption.

- Recommend CST Provider and Orders Team have more cross-over moving forward. Those with orders build/content knowledge need to help inform the order set design/build group what is and is not possible. When new orders are requested by the Provider team for build into order sets, they will need to be reviewed by the orders build group before they can be added to the order catalogue. If everyone is at the same table, this dialog will happen appropriately without being “lost in translation” later.

- When reviewing clinical workflows, representation must be at the table from all groups/scopes of

practice that the workflow affects. During process redesign, identify suboptimal workflow in current state and correct it in future state (e.g. med admin FMEA). Consider what is important to patients and staff (e.g. safety, quality, efficiency, patient experience). Consider how this will “mesh” with use of the new system. Each site may have workflow variations, so don’t assume that a workflow that has been reviewed at one facility will be exactly the same at another facility.

Risk #2:

The CST project has been successful in communicating that the project is not an IT project, but rather a clinical transformation project as clearly stated in the project name. There are clinical leaders engaged throughout the project committees but what was not clear to us was whether they had clinical operational responsibilities or whether they were clinical leaders put into a specific project role. In order to ensure engagement at the practice level, operational leaders need to be engaged in the system design and implementation.


- Ensure clinical leaders with current accountabilities to direct healthcare delivery are on project leadership committees.

- Clinical Team/Unit Managers have a special role in communicating system benefits to front line staff. Without their buy-in and support, expect a lack of adoption and resistance to change.

Risk #3

The CST project is heavy with consultants driving design and build. The risk is that once project is live, the knowledge of design considerations and build techniques are lost. Those left to support the system are lacking fundamental understanding of design decisions, rationale, and knowledge of system build for maintenance purposes. There is also a risk that decisions will be made for short term success but are not realistic to manage long-term.


- It is very important to build your own internal team of individuals with clinical and technical build

6

knowledge (similar to Clinical Informatics at NYGH). Select individuals from amongst your staff who have a clinical background and an aptitude for informatics. Send them for training from Cerner so that you can create a team that has in-house technical build knowledge. Once trained, these people should be directly involved in meetings with clinicians to make design decisions and validate build. Since these people know what truly is possible and not possible within the constraints of the vendor software, they can help to focus clinician design/validation discussions only on the truly implementable options. If these individuals are not involved in clinician meetings, the concern is that clinical requirements will be “lost in translation” and the build team will not be able to create a solution that truly meets clinician needs – either because they don’t understand what is needed, or because what the clinicians requested simply isn’t possible within the vendor software design constraints.

- Rely less on consultants (they don’t have a vested interest in decisions, your team won’t be able to support after they leave)

Clinical Content Design and Clinician Engagement

Risk #1:

The CST project has been structured so that many different aspects are underway simultaneously: clinical engagement and workflow review, design, build, device selection, development of training materials, and so on. This approach is not recommended, even though it may appear to be more efficient. Significant dependencies exist between these elements which require some of them to be completed sequentially. If instead they are completed simultaneously, there is a risk to effective design, proper clinical validation, optimal build, training and adoption. Examples of simultaneous work noted by the NYGH team included: building order sets while the custom order catalogue is still being built and clinically reviewed; starting testing while clinical validation of system design and content is still underway or not complete; selecting devices for clinical use without system design/build being finalized; and planning work for training without project scope and final design being completed.


- Ensure project components with dependencies are sequenced in time so that they are after the components they are dependent upon. For example, do not build order sets until each facility’s custom order catalog has been built and clinically validated; do not start unit testing until after system build is complete and has been fully clinically validated; complete future state workflows before selecting devices for clinical use, and so on.

- Clinicians need to review and validate build before moving forward to testing. Do not rush

design, as sub-optimal product will not result in adoption.

7

Risk #2:

The original development methodology outlined in the consultant contracts signed by PHSA was that system design and build would be completed in stages, with frequent opportunities to see build prototypes and for clinicians to provide feedback along the way. Instead, due to difficulties with consultants completing the build, no prototypes have been made available and clinicians have not been able to see how their design decisions will look in the system. This is a major risk to project success. It is almost 100% certain that clinicians will not be happy with the first version of the build that they see in the system. Consultants on the CST project are pushing for “sign off” on build and starting testing.


- System development must be approached using an agile and iterative process of: initial design (by core project Clinical Champions working with builders) build prototype demo to front-line clinicians refine build based on feedback repeat demo further refinement based on feedback, and so on until clinicians are comfortable with the build and the accompanying future state clinical workflows. This process is essential to success because in our experience, clinicians will not be able to adequately visualize future state and give appropriate feedback until they can see and use actual system build in a demo environment.

- While compiling design decisions and working on system build, the project team will become aware of certain items on which it will be difficult for clinicians to reach consensus because Cerner does not support an ideal workflow (for example, the process of issuing “suggested orders”). In this case, before engaging front-line clinicians it is best for the project team “do their homework” in advance – research different options for a solution, then for each potential solution summarize pros/cons, and build prototypes for clinicians to view in a demo environment. Then, when meeting with the clinicians, it will be easier and more efficient to reach consensus on the best option. The conversation will be focussed on options that are realistically possible within the constraints of the Cerner software, and clinicians will be able to understand the options because they will see a demonstration of each.

- The project team should never make crucial design decisions without first demonstrating the

implications to clinicians in a demo environment, because clinicians are unlikely to arrive at an optimal decision if they cannot visualize the system they will be using in future state.

- No matter how much pressure there is from consultants to meet a certain timeline, do not sign

off on any build or start any testing until build has been demonstrated to clinicians, there has been opportunity for multiple rounds of clinical feedback and build adjustment, and the project team is comfortable that final build has been fully validated by clinicians.

Risk #3:

System design specification documents (such as “Design Decision Matrix” or similarly-named spreadsheets) were/are being completed by front-line clinicians at PHSA. This is not recommended because: 1) Front-line clinicians usually do not have the system build knowledge to completely understand the meaning or implications of design decisions they are being asked to make, resulting in

8

suboptimal decision-making; and 2) Clinicians can become disengaged from the project when being asked to complete documents with a lot of technical jargon that does not seem clinically relevant to them.


- Instead of involving front-line clinicians, the recommended approach for completion of system design decision documents is a co-operative effort between core project Clinical Champions and builders who have technical system knowledge. Core project clinician champions have better familiarity with Cerner terminology and functionality than front-line clinicians. Working together with builders, they will have the time and the patience required to develop a deep understanding of the implications for each design decision. Sometimes, there may be more than one viable design option. In these cases, the Clinician Champion can distill the main design questions down into simple clinical scenarios, which can be demonstrated in a meaningful and efficient way to front-line clinicians, optimizing decision-making.

- Be careful not to rely solely on Cerner content such as START and MethodM documents. START content usually does not come even close to meeting real clinical needs; often starting from scratch is required. MethodM documents (including Design Decision Matrices) often leave out important workflow and design decisions – these will need to be identified, compiled and addressed by your project team.

Risk #4:

The NYGH team observed that the order set build process has been rushed ahead using a generic order catalogue, because the custom PHSA order catalogue is not yet complete or clinically validated. Also, there are deficiencies in the custom order catalogue build/validation process. This is a major risk to project success because: 1) An order catalogue that has not been properly designed and clinically validated will lead to adoption and safety risks. Clinicians will be frustrated because orders will be unintuitive to find and use. They may inadvertently select incorrect orders because they cannot find what they need. 2) Front-line clinicians are reviewing order set content that will not match the final version they will use in Cerner (since all generic orderables will need to be changed to match the custom order catalogue when it is complete). This presents a safety risk since the clinical meaning of orders may change in the final version of order sets based on the new catalogue, and represents an adoption risk because clinicians are not reviewing on a “what you see is what you will get” process.


- Stop the order set build process until the first version of the custom order catalogue is completed and has been clinically validated.

- It is well worth the additional time to develop a robust order catalogue build and validation process, which should include:

o An interdisciplinary team of builders familiar with Cerner, Clinical Champions as well as

9

front-line clinicians for periodic validation. When orders affect multiple departments, ensure individuals from each of the involved departments are included in order design and review.

o Create a style guide for order development, which should include acceptable abbreviations, standard terminology and code sets for OEF fields, decisions on use of range dose/range frequency, and so forth. All orders, regardless of department or facility, should adhere to this style guide. Form a small core of central project staff that are responsible for review of all orders build against the style guide.

o Careful examination of every orderable to ensure: 1) the root name of the order is intuitive for clinicians to find based on common clinical language; 2) there are synonyms for each order so that each is easily findable based on multiple different search terms; 3) the order entry formats have been reviewed to minimize un-necessary fields (e.g. orders should not be used as documentation), minimize un-necessary mandatory items, ensure that choices within fields are standardized using code sets where possible; and that no fields are missing

o Mock-up of orders in a Cerner demo domain, with validation by clinicians. Be sure to involve physicians with specialty knowledge of the orders being reviewed (e.g. Cardiology orders reviewed by Cardiologists, Orthopedics orders reviewed by Orthopedic Surgeons, etc.).

- Once most orders have been completed and validated in Cerner, version 1 of the custom order

catalogue should be exported from Cerner and uploaded to Zynx. Order set build can then resume. Zynx should be used as the main tool to build and review order sets.

- Any remaining unfinished orders awaiting final review/validation in Cerner can be exported incrementally to Zynx when completed. Order catalogue development will be an iterative process, with several successive catalogue uploads required over time. This is because need for new orders and changes to orders will be identified as order sets are being built and reviewed. For this reason, do not expect the order catalogue to be “final” the first time – this would delay starting order set build in Zynx. Instead, placeholder terms can be built as required in Zynx for orders pending final build, to assist clinicians in seeing orders as they should eventually appear in Cerner.

Risk #5:

In the CST project there has been a good level of engagement with clinicians to discuss order set content. However, there is an insufficiently robust methodology to determine order set scope, include and maintain evidence in order sets, as well as obtain adequate clinician review and validation of order sets once built. Zynx evidence links have not been included in CST order set build, which results in lost opportunity for clinicians to discuss evidence in the order set review process (risking poor consensus), lost opportunity for clinicians to use evidence in the course of clinical care (potentially reducing quality and safety), and increased difficulty in maintaining order sets with new/updated evidence over time.

10


- For each facility, determine order set build scope by doing a “Gap Analysis”. This requires obtaining a year’s worth of retrospective discharge data, rank ordering the diagnoses in descending sequence by volume of cases per year, then taking the top 80% of the diagnoses from the list. The number of order sets in this 80% by volume list, after subtracting the number of matching electronic order sets already created (e.g. from other facilities) will be the “gap” – the number of order sets required to build at that facility before go-live.

- There should be a core order set team at each facility that is comprised (at a minimum) of Clinical Champions, pharmacists, and Clinical Informaticists who specialize in order catalogue build and order set build. It is important that builders are “at the table” in order set meetings, so that clinicians understand what can and cannot be built.

- Develop and adhere to a standardized style guide for all order sets. This should include

conventions for abbreviations, sorting of order categories, orders and order sentences within an order set, standards for linked evidence and evidence documents (e.g. use of static links such as PubMed), conventions for order defaults, and so on.

- Avoid using Multi-Phase PowerPlans at initial go-live. They are complicated and time-consuming

to build, and are confusing for inexperienced clinicians to use.

- Do not allow the option for PowerPlan Favourites (i.e. allowing physicians to customize order sets by adding or deleting options or changing defaults, and then saving to their Favourites folder). This will completely undermine efforts to standardize care and will compromise the ability to improve quality and safety, since updates to facility-wide order sets will not be reflected in physician-customized “Favourite” plans.

- Consider asking Zynx to come to PHSA and assist in creating the first 12 to 24 order sets. They

provide this service for free, and it will help to train your order set staff to work independently using effective methodology.

- We recommend employing a standard 5-step method for all order set development:

1. PROTOTYPING: Start with order set content from Zynx if available, and include the associated Zynx evidence links. Also consider order sets from the Canadian CPOE Toolkit library, which are available in Zynx for free. Paper order sets from PHSA are an important resource, but should never simply be converted into electronic form since: 1) this will leave out Zynx evidence links; 2) some content on the paper version may be out of date; 3) paper orders are fundamentally different from electronic ones. Always build order sets using your custom PHSA order catalogue, extracted from Cerner into Zynx.

2. REVIEW BY NON-PHYSICIAN CLINICIANS AND DIAGNOSTIC SPECIALTIES: Use Zynx Viewspace.

3. REVIEW BY PHYSICIANS: Use Zynx Viewspace. Ensure physicians with subject matter expertise for each particular order set are involved (e.g. Orthopedics for hip fracture, Cardiology for Congestive Heart Failure).

4. CONSOLDIATION OF REVIEW COMMENTS: Make changes in the order sets based on reviewer ViewSpace suggestions, unless there is disagreement among reviewers, in

11

which case meeting(s) with a small group of individuals may be required to reach consensus.

5. APPROVAL OF ORDER SETS: Requires clearly written policy outlining the accepted order set approval and update process. Consider involvement of MAC or an arm’s length committee of MAC.

Data Governance

Risk #1:

With archived data from old systems and new content being developed in new systems, now is the time to define a data governance model. This can be closely tied to risk in project governance where deliverables need to be more discretely defined. At the point of defining specific content deliverables to each working group, data stewards can also be identified.


- Develop a data governance model. This model will define owners of data and hold people and/or groups accountable for monitoring of data quality, integrity, adherence to standards and reporting requirements.

- Consider developing data auditing tools to be used for go live performance metrics and ensure staff are using the system appropriately. It is better to correct bad practices early.

- Identify and engage data stewards early in system design. These resources will be critical in

understanding data analytic capabilities and can offer input into key indicators that need to be integrated into system design.

12

1.3 Summary of Recommendations from all sections Key Recommendations/NYGH Success Factors: • Ensure your project governance structure places clinical champions and clinical directors in

prominent leadership positions that are directly responsible to the success of the project; similarly, these same people should continue to be active in the regular operation of their clinical departments, so that they are aware and accountable to project impacts on their people and processes. In addition, each clinical leader should be partnered with a senior leadership-level sponsor (e.g. Vice-President) so that leadership is constantly aware of project progress, challenges and risks. This structure will lead to operational buy-in and help the organization feel that success is their entire responsibility, not just the project’s responsibility. See NYGH’s eCare project structure as an example.

• Have an iterative design / build is required to be successful and clinicians need to review the full build before moving forward to testing. Do not rush design, as sub-optimal product will not result in adoption.

• Extend the planned stabilization period between go-lives, the planned 6 weeks is not a long enough between sites. See executive summary for recommended timelines.

• Each organization needs to prioritize the project work and ensure it is the main focus, particularly during the final two months before go-live, and during the post go-live support period. All other corporate initiatives must be cleared off the calendar during this time; it is “all hands on deck” to maximize chance of project success. During the pre go-live period, executive sponsors, directors, managers and clinical champions must focus on building positive anticipation for the project, schedule training and backfill of clinical positions (where needed) for go-live. The post go-live period requires regular project status meetings which executive sponsors, directors, managers and clinician champions must attend. Executive sponsors should plan to do “gemba walks” to evaluate effect of the go-live on clinical operations first-hand, while offering coffee and snacks to clinicians to show their support.

• It is very unlikely to get buy-in and adoption of clinical documentation in critical care, maternity or surgical areas without BMDI. NYGH big win in these areas was BMDI.

• When you release a new system, you need to determine the capacity for some clinicians to soak up the slack from any other group of clinicians who are going through a significant process change. For example, at NYGH we implemented nursing/allied health clinical documentation separately from CPOE and closed-loop medication administration. The advantage was spreading out the impact to nursing over time, reducing the risk of overwhelmed nurses and freeing them up to better support physicians during CPOE go-live. There is a risk that implementing a broader scope all at once will increase strain on clinical processes and endanger patient safety as well as clinician adoption.

• Very important to build your own internal team of those with clinical and technical build knowledge (Clinical Informatics at NYGH). Select individuals from amongst your staff who have a clinical background and an aptitude for informatics. Send them for training from Cerner so that you can create a team that has in-house technical build knowledge. Once trained, these

13

people should be directly involved in meetings with clinicians to make design decisions and validate build. Since these people know what truly is possible and not possible within the constraints of the vendor software, they can help to focus clinician design/validation discussions only on the truly implementable options. If these individuals are not involved in clinician meetings, the concern is that clinical requirements will be “lost in translation” and the build team will not be able to create a solution that truly meets clinician needs – either because they don’t understand what is needed, or because what the clinicians requested simply isn’t possible within the vendor software design constraints.

Interdisciplinary Documentation • Recommend de-scoping Provider documentation, or going deep in a couple of areas in great

detail. Provider Documentation Requires a lot of work, and you need to get it right with the right tools

• Without voice recognition and significant tool development you are not going to have high adoption.

• Recommend clearly communicating to clinicians to document by exception and that they do not need to fill out everything, but they need to complete only what they assessed.

• START content is not typically valuable; use as a bench mark to see what to include but most documentation is all started from scratch.

• Use iView if information needs to be trended, PowerForms otherwise.

Order Sets • Need to build off of customized and clinically validated PHSA Cerner order catalogue, not off of

vanilla Zynx or Cerner order items, to ensure the order sets can be loaded back into Cerner and that clinicians are able to review content in Zynx exactly as it will appear in the electronic record at go-live.

• Never simply take paper order sets and make them electronic – it is never that simple. Many aspects of electronic ordering are different than on paper. The paper order set serves only as a starting point to which evidence, electronic order catalog items and newly optimized clinical workflows are added.

• Recommend not allowing the creation of favourite order sets “PowerPlan favourites” (this allows Providers to personalize and save their own ordersets with orders added or deleted). There will be issues with maintaining standardization of care, because every time an institutional order set is updated with new evidence or other changes, the custom saved PowerPlans that physicians have put in their own folders will not be updated. Creates a huge maintenance issue, and prevents physicians from basing their practice on standardized, evidence-based content.

• It is okay for Providers to save standard order sets to favourites folders however since these would still update when changed at the institutional level.

• Recommend not going live until majority of order sets that are required for a site or clinical area are built.

• Determine number of order sets to be built for go-live by covering 80% of discharge diagnoses

14

(rank-ordered by volume) based on a year’s worth of data – also called a “Gap Analysis”. • Do not have a hybrid ordering practice. All orders need to be entered in Cerner via individual

orders or order sets. • Recommend building off of Zynx standard order sets to retain best practice evidence. There can

be a liability if the evidence is not kept up to date. If Zynx content is not used at the outset, then the links in each order set that prompt the build team that new evidence is available will not be visible.

• Recommend bringing in Zynx resources to help and train us (since they don’t charge extra for this service, and know their product and recommended development workflows best).

• Recommend having Zynx help build the first 12 to 24 or order sets until your local build team is comfortable on the recommended methodology.

• Ensure a thorough clinical review of order sets is done – including validation of each “finished” order set by clinicians in that specialty – before importing into Cerner for use. Zynx ViewSpace is an efficient tool to use for this purpose.

• Recommend a change log being used for any changes to order sets. • Recommend CST Provider and Orders Team have more cross-over moving forward (those with

orders build/content knowledge need to help inform the order set design/build group what is and is not possible). Conversely, new orders requested for build into order sets will need to be reviewed by the orders build group before they can be added to the order catalogue. If everyone is at the same table, this dialog will happen appropriately without being “lost in translation” later.

• Ensure clinicians have run through real-life scenarios with order sets before go-live (“usability testing”).

Alerts/Clinical Decision Support • Make conscious decisions around alerting levels. • Monitor your alerting levels and tweak after go-live if necessary to prevent alert fatigue. • Spend time on the Sepsis Alert to build properly and continue to monitor and tweak. • Duplicate therapy alerting may be too primitive.

Dose Ranges • Review NYGH Book chapter on decision support for many recommendations.

Quality Assurance/Design Validation • Quality Assurance and validation of design needs to be an iterative process. • Recommend that Unit Testing should not occur until the design and build is complete and

validated. • Recommend not signing off design until we see the full build. • Need physicians to be able to review so changes and tweaks can be made. • You can use prototype or mock-ups (physicians aren’t going to get it until they see it). You may

need to go back and demo different versions – or demo 2 or 3 options in one session, if a clinical decision is needed on which option best meets clinical needs.

• Workflow is a key element to validating design. Recommend not creating/reviewing a workflow

15

without everyone involved that the workflow affects. • Recommend being cautious about making changes for the right reasons, do not make them to

reduce a perceived possibility of resistance to change. • Recommend developing a good policy defining criteria to justify and triage requested system

design changes – such as impacts on patient safety, quality, new evidence that has become available, formulary or clinical policy changes, etc.

• Recommend building capacity into clinicians schedules for review design, because design hasn’t been seen, they need to be prepared to have time to review.

Mandatory documentation requirements • If there are report requirements, plan that from the beginning and build around it. • Data Analytics will need to be involved in mandatory documentation discussions. • Use Favourite lists for Problems & Diagnosis. BMDI • Re-evaluate CST decision on BMDI, there will not be buy-in for Maternity, O.R./Anaesthesia and

Intensive Care without it, as it is essential. • Anesthesiology management should not be implemented without integration. • Recommend Cerner completing a review of our device inventory to determine which devices are

Cerner certified. Alternatively, give Cerner a list of devices and ask them to say which are Cerner certified.

• Recommend Cerner completing a technical readiness assessment for us. • Recommend using connectivity engines where possible, as Cerner owns the support for these

and we can direct all issues to Cerner if required, to avoid finger pointing (versus using third party).

• Dedicated PHSA BMDI staff resources are recommended.

Charge Capture • Charge Capture should be included as part of the RadNet build, it is not a separate module in

itself. • Recommend building charge capture through orders rather than documentation, as through

documentation it may result in drops of the charge for procedures not completed, which are difficult to reconcile later. Only want to confirm charges once the procedure is done – upon signing.

Enterprise Build versus Localization Build • Build Preference Cards based on location and schedule • Orders are different by each site and would be localized - Can use Cerner virtual views Reporting • Recommend including clinical resources and operational IT resources who know Cerner involved

in the selection of the analytics tool, to ensure knowledge of clinical requirements and the Cerner data model are included in selection.

16

• Recommend building a good report inventory based on current state reports. • Recommend running reports off standby database – not off Production • Ensure you look into the current state process around ORSOS and reporting to ensure we are

not automating bad process. Need someone with good understanding of current state to be involved in the transition to Cerner

• Surginet Report builder reporting tools are robust and can be used to build a lot of reports rather than CCL. This can be done by Application team.

• Power Insight - NYGH have not used it much, but recommend viewing the demo

Operational Planning: Sustainment/Structure/Continuous Improvement • Include in your project structure an Executive Sponsor who is directly responsible to the people

who are directly accountable for the clinical areas. • First implementation will set the tone for all subsequent implementations so it is critical to get it

right the first time. If you can pause now, DO IT. • Clinicians need to see the build to better understand their design decisions. There is value in

building internal capacity to iteratively make build changes and resolve issues. • Send your clinicians to Cerner maintenance training so they fully understand how to build which

will inform full functionality. • Make significant changes to MethodM methodology. Do your maintenance training first in the

process to ensure you are prepared internally to support. • Consider fee for service in situations when you can manage work required. When scope is not

well defined, fixed fee quote will often come in high and additions to scope will be expensive.

SNOMED / ICD 10 • Use Favourite lists for Problems & Diagnosis – customize these lists based on physician specialty

and practice patterns. Key Workflows • For Sepsis workflow, build out the rules and monitor sensitivity by running alerts in the

background and auditing appropriateness. Once the team is confident with the validity of sepsis alert, then turn on and audit effectiveness. How many false positive? How many patients admitted to CrCU and work back to see when alert triggered. Should it have prompted earlier?

• For standard practice have orders that trigger on admission, but for specific orders to patients, they should be entered in the system separately through communication orders.

• If you can avoid discharging patient, per your policy, avoid it, as order management is much simpler with the transfer process.

• Many alert requests may come forward to ensure alignment with standards. Make sure there is a team who will apply good judgement on which alerts are worth building. If the practice being recommended for alert is standard practice, then an alert is not the best tool. Reserved for critical practices that have significant safety implications if missed.

Provider • Align the orderset design/build with Zynx standards and best practices • Maintain Zynx as your source of truth for all order set content • Ensure you have a robust order catalogue to support the orderset design and build

17

• Ordersets need to be reviewed by their respective provider specialities • Orderables’ primary names should be intuitive to clinicians, and synonyms must be built to

support the ordering process. • When designing your order entry formats, consider the following:

o Mandatory fields design o Cross departmental agreement on the order entry format fields o Do not use order entry formats as a documentation tool

• If circumstances where Zynx Evidence Links is not sufficient, ensure you have a policy in place to review, approve, and manage custom links

• Use of favorite ordersets, but not the use of favorite PowerPlans • Do not use PowerPlan subphases, which can be very confusing to clinicians who are still learning

the Cerner tools

Clinical Documentation / Maternity / Orders and Results • Build a style guide for IPOCs, including standards of care before you initiate the build • Do not rely on rules and alerts to support clinical workflows where clinical judgement is

necessary • A rule should never automate a clinical action without first informing the responsible clinician

and obtaining acknowledgement/consent for the action, e.g. a rule that is about to cancel an order needs to clearly inform the user of the order it is about to cancel.

• Do not rely on tasks for aspects of routine clinical workflow. Overtasking can impede workflow. • Identification of key operational resource to act as the point person to support the build and

maintenance of the ESH as well as security positions. • Minimize the use for “Carry Forward” functionality as part of clinical documentation • Minimize dropping charges through documentation, but rather use orders to drop charges.

Medication Management • Medication dispensing and administration workflow will change significantly. Consider running

a 2P event to map current state, define standard practice, map future state and consider a FMEA to gain trust in clinicians that all potential points of failure have been considered and mitigated.

• Ensure thorough review and appropriate revisions are made to Medication ordering and administration policies and procedures

• Look closely at workflow and lessons learned on Pass medications • Consider revising approach currently designed around TPN medication ordering to use proper

Cerner tools to order TPN (i.e. PowerPlan Order Set not PowerForm) • Immunization tools are not that valuable if source of truth for all immunizations is not stored

there – i.e. Panorma • Build out high-risk non-formulary medications as specific orderables instead of using non-

formulary order form

Emergency Department

18

• Do not carrying forward a lot of information for transfers o Really evaluate if you want to carry anything forward – this is not best practice. If

practice is so common that data is carried forward, consider why it is being charted so frequently. Carry forward clutters clinical results review with duplicate results.

o Should really be charting only what you assess and must make sure what you carry forward is accurate before you sign it

• Use PowerForms for things you want to assess once and IView for continuous assessments or elements that will be trended.

• Recommend WOWs as best device for Emergency department as there is flexibility on where and how they can be used

Health Information Management / Scanning • Use document bar codes to support batch document scanning. This will help automatically

identify document types, and flag any unmatched ones • Message Centre deficiencies fall off after 90 days. Develop a process to mitigate this risk Medical Imaging • Considering the use of more group ordering.

o When scheduling a procedure we can group in other orders, so once scheduled it can kick off other orders.

• Using Discern Analytics to run existing MI reports first, before building custom CCL reports. Give Medical Imaging the responsibility of running their own reports in Discern Analytics.

• Build a comprehensive strategy for Cardiology solution • Must build charge services in Cerner for Medical Imaging

Registration / Scheduling • Build the Registration rules on the new Person Management rules engine • Implement the Appointment Tab in PowerChart to support the viewing of appointments at the

patient level • When designing the Discharge and Transfer project, approach it with the following concept “if

you don’t have to discharge the patient, do not discharge the patient”.

Surgery • Identify the ORSOS and ORMIS data quality issues now before implementing SurgiNet • Do not implement the Anesthesia module without BMDI • Recommend evaluating what intra-op medications nurses are administering and decide how

that will be charted (irrigation, eye drops, etc. might not choose to chart on eMAR) • Determine a solution/workflow for issue around parsing of scanned multiple barcodes for

implants, which is currently not supported by the Cerner solution

Core • App groups should be built by function and not by position

19

• Build out all Document Types individually in the ESH to allow users to easily find the correct document. If continuing to use telephone dictation in some areas of the organization, this will require review and revision of dictation codes entered by users (they may need to be more granular in order to support the system identifying and separating different documents as unique in the ESH).

• One or two key operational resources to support the build and maintenance of the ESH. Resources should be experienced Core, and all work funnels through them

• One or two key operational resources to support the build and maintenance of positions. Resources should be experienced Core, and all work funnels through them

• When building the access model, you should consider the following levels of access criteria: i. Module/Apps

ii. Functionality within Apps - Exception groups – impact security outside of the position - Privileges/Preferences

iii. Task Groups (Order tasking/Documentation tasking) iv. Discern rules (rules to specific clinicians) v. Access to registration conversations

vi. Access to reports vii. Declaration of a relationship

Technical Teams • CST should outline workflow differences in medication administration between sites • Complete an FMEA with Quality and Safety experts before go-live to review device workflow • In addition to mapping workflow, CST should consider what is important to patients, staff

(various positions), and the organization when designing medication administration process; this will give insight into what should be considered in process redesign

• CST should consider where errors are occurring in current state medication administration workflows and use this knowledge to address these steps in future state workflows

• CST should have vendors give sample devices so clinicians have a better understanding of devices in order to determine functional requirements

• CST should finalize workflows before asking clinicians to choose devices; it is very difficult to ask clinicians to select a device if they do not know the future state workflow

• Do not break up COPE and eMAR; can cause an overall loss in value and an increase of chance for errors

• Purchase battery monitoring tools for the WOWs that allow you to run reports on battery usage

Clinical Transformation • Provide discussions on changes to practice during training. • If training in groups, it is important they see information relevant to them otherwise they get

caught up in content if it doesn’t relate to them (e.g. Orthopedic cases for Orthopedics) • Never say the system will be easier or faster, say it can improve patient safety with safer

workflows, it provides evidence based standardized care, etc. • Review current workflows for professional practice issues, as you do not want to build a system

22

3.4 DDG Decisions Please review and comment on decisions outlined in Appendix D.

3.5 Other Key Decisions Please review and comment on decisions outlined in Appendix E.

4.0 Key Strategy & Governance Topics

General Recommendations on Project Structure & Timeline Key Recommendations/NYGH Success Factors: • Ensure your project governance structure places clinical champions and clinical directors in

prominent leadership positions that are directly responsible to the success of the project; similarly, these same people should continue to be active in the regular operation of their clinical departments, so that they are aware and accountable to project impacts on their people and processes. In addition, each clinical leader should be partnered with a senior leadership-level sponsor (e.g. Vice-President) so that leadership is constantly aware of project progress, challenges and risks. This structure will lead to operational buy-in and help the organization feel that success is their entire responsibility, not just the project’s responsibility. See NYGH’s eCare project structure as an example.

• Have an iterative design / build is required to be successful and clinicians need to review the full build before moving forward to testing. Do not rush design, as sub-optimal product will not result in adoption.

• Extend the planned stabilization period between go-lives, the planned 6 weeks is not a long enough between sites. See executive summary for recommended timelines.

• Each organization needs to prioritize the project work and ensure it is the main focus, particularly during the final two months before go-live, and during the post go-live support period. All other corporate initiatives must be cleared off the calendar during this time; it is “all hands on deck” to maximize chance of project success. During the pre go-live period, executive sponsors, directors, managers and clinical champions must focus on building positive anticipation for the project, schedule training and backfill of clinical positions (where needed) for go-live. The post go-live period requires regular project status meetings which executive sponsors, directors, managers and clinician champions must attend. Executive sponsors should plan to do “gemba walks” to evaluate effect of the go-live on clinical operations first-hand, while offering coffee and snacks to clinicians to show their support.

• It is very unlikely to get buy-in and adoption of clinical documentation in critical care, maternity or surgical areas without BMDI. NYGH big win in these areas was BMDI.

• When you release a new system, you need to determine the capacity for some clinicians to soak up the slack from any other group of clinicians who are going through a significant process change. For example, at NYGH we implemented nursing/allied health clinical documentation separately from

23

CPOE and closed-loop medication administration. The advantage was spreading out the impact to nursing over time, reducing the risk of overwhelmed nurses and freeing them up to better support physicians during CPOE go-live. There is a risk that implementing a broader scope all at once will increase strain on clinical processes and endanger patient safety as well as clinician adoption.

• Very important to build your own internal team of those with clinical and technical build knowledge (Clinical Informatics at NYGH). Select individuals from amongst your staff who have a clinical background and an aptitude for informatics. Send them for training from Cerner so that you can create a team that has in-house technical build knowledge. Once trained, these people should be directly involved in meetings with clinicians to make design decisions and validate build. Since these people know what truly is possible and not possible within the constraints of the vendor software, they can help to focus clinician design/validation discussions only on the truly implementable options. If these individuals are not involved in clinician meetings, the concern is that clinical requirements will be “lost in translation” and the build team will not be able to create a solution that truly meets clinician needs – either because they don’t understand what is needed, or because what the clinicians requested simply isn’t possible within the vendor software design constraints.

4.1 Interdisciplinary Documentation NYGH Lessons Learned

• It took over 8 months to get 2 Ambulatory clinics live on Provider documentation. That is the only significant Provider documentation NYGH has live. Required voice recognition as an element of this strategy – to allow for narrative sections of the chart (so as not to lose the patient story or provider impressions).1

o Training for voice recognition alone required one-on-one 2 hour training sessions with each physician

o In order to get good adoption, there needs to be a lot of hand holding to assist physicians through the macros, auto-text, and any speech recognition.

• NYGH created a Communications flowsheet rather than an MPage as the landing page. It is a custom tab that allows providers to communicate with other clinicians on key pieces of information

• Physicians preferred to have Allied Health documentation as a textual rendition of OT and PT notes rather than reviewing in flowsheet format for ease of legibility.

• NYGH uses a Clinical Informatics feedback form which is a website in which end users can submit feedback that goes to directly to Clinical Informatics

o If allied – goes to the PPL for that discipline

1 The reason why it took so much effort is because they were focusing on areas that required very detailed structured templates (e.g. endoscopy) that they were building from scratch. Other documentation items such as inpatient medical progress notes would require much less effort. But even in the case of progress notes, careful consideration of workflows and design decisions (such as whether to allow copy-forward) must be undertaken

24

o If nursing – goes to Nursing informatics working group o If physician – gets reviewed at eCare Core meeting, forwarded to order set team, or

CMIO (depending on content of specific feedback) • Nursing Educators do all communications about changes to their clinical information system. • Use PowerNotes, PowerForms and iView – have not transitioned to Dynamic Documentation.

NYGH is considering DynDoc for documentation in specific clinical areas, but there are three limitations to DynDoc: it is unable to handle multimedia content such as pictures, cannot handle Macros built for PowerNotes, and doesn’t permit the same level of structured guidance to clinicians that PowerNote does.

• Did not use Message Center for clinical messaging at all. It is not good for real time communication for inpatient care, because providers prefer to see clinical messages in context of the patient chart while making rounds (not out of context in the Message Center). Message Center clinical messaging is much more useful in an ambulatory setting.

o Not live with much Ambulatory yet and recognize there is more value in Ambulatory • Problems and Diagnosis can be a potential pitfall

o Have seen sites that opened up access to document Problems to different kinds of clinicians and it can cause a large mess of information. Recommend relegating the Problems and Diagnosis dialog to physicians only. If opened up to other scopes of practice, the dialog may be cluttered with diagnoses that are not relevant to physicians and potentially incorrect (e.g. non-physician diagnoses a patient with “hypertension” when really the patient was just having temporary pain, increasing blood pressure).

o NYGH is cautiously introducing Problems and Diagnosis in a gradual fashion. All diagnoses are required to be encoded in SNOMED-CT. Clinical documentation templates such as physician PowerNotes have been designed by NYGH with custom clickable lists of diagnoses that directly populate the Problems and Diagnosis dialog with SNOMED-CT terms (automatically, and without any extra steps in the provider workflow). Further rollout will be undertaken this year, with specialty-specific Favourites folders of SNOMED-CT terms in the context of inpatient Progress Notes. Need rules to ensure someone is maintaining the problem list – for example, alerts that help physicians add diagnoses that are relevant to a signed order set (diagnosis of CHF when CHF order set is signed). Also consider mandatory rule to have physician clean up problem list before the discharge order can be signed.

• Near real-time scanning o They have some paper- inpatient areas physicians are still writing or dictating. o Scanning is done centrally in Health Records and charts are picked up daily and in ED

multiple times per day. Content Shared:

• Communications flowsheet screenshot - from landing page • Share screenshots of all powerforms – have done a similar sharing with PEI • NYGH to send their document pick up schedule for scanning

25

Key Recommendations: • Recommend de-scoping Provider documentation, or going deep in a couple of areas in great

detail. Provider Documentation Requires a lot of work, and you need to get it right with the right tools

• Without voice recognition and significant tool development you are not going to have high adoption.

• Recommend clearly communicating to clinicians to document by exception and that they do not need to fill out everything, but they need to complete only what they assessed.

• START content is not typically valuable; use as a bench mark to see what to include but most documentation is all started from scratch.

• Use iView if information needs to be trended, PowerForms otherwise.

4.2 Order Sets

NYGH Lessons Learned:

• NYGH realized a reduced mortality rate by 45% for patients admitted for pneumonia or COPD exacerbation if CPOE was used, versus traditional paper processes

o Found an additional 56% reduction in mortality if the correct order set was used on admission by the physician – that matched discharge diagnosis

o 36% of patients before go-live were admitted using a standard paper order set – after go-live >97% had electronic order sets on admission, showing very strong adoption of evidence-based order sets by physicians

Content Shared

• NYGH to provide presentation on HIMSS 2014 – presentation on reduction of mortality rates

Key Recommendations:

• Need to build off of customized and clinically validated PHSA Cerner order catalogue, not off of vanilla Zynx or Cerner order items, to ensure the order sets can be loaded back into Cerner and that clinicians are able to review content in Zynx exactly as it will appear in the electronic record at go-live.

• Never simply take paper order sets and make them electronic – it is never that simple. Many aspects of electronic ordering are different than on paper. The paper order set serves only as a starting point to which evidence, electronic order catalog items and newly optimized clinical workflows are added.

• Recommend not allowing the creation of favourite order sets “PowerPlan favourites” (this allows Providers to personalize and save their own ordersets with orders added or deleted). There will be issues with maintaining standardization of care, because every time an institutional order set is updated with new evidence or other changes, the custom saved

26

PowerPlans that physicians have put in their own folders will not be updated. Creates a huge maintenance issue, and prevents physicians from basing their practice on standardized, evidence-based content.

• It is okay for Providers to save standard order sets to favourites folders however since these would still update when changed at the institutional level.

• Recommend not going live until majority of order sets that are required for a site or clinical area are built.

• Determine number of order sets to be built for go-live by covering 80% of discharge diagnoses (rank-ordered by volume) based on a year’s worth of data – also called a “Gap Analysis”.

• Do not have a hybrid ordering practice. All orders need to be entered in Cerner via individual orders or order sets.

• Recommend building off of Zynx standard order sets to retain best practice evidence. There can be a liability if the evidence is not kept up to date. If Zynx content is not used at the outset, then the links in each order set that prompt the build team that new evidence is available will not be visible.

• Recommend bringing in Zynx resources to help and train us (since they don’t charge extra for this service, and know their product and recommended development workflows best).

• Recommend having Zynx help build the first 12 to 24 or order sets until your local build team is comfortable on the recommended methodology.

• Ensure a thorough clinical review of order sets is done – including validation of each “finished” order set by clinicians in that specialty – before importing into Cerner for use. Zynx ViewSpace is an efficient tool to use for this purpose.

• Recommend a change log being used for any changes to order sets. • Recommend CST Provider and Orders Team have more cross-over moving forward (those with

orders build/content knowledge need to help inform the order set design/build group what is and is not possible). Conversely, new orders requested for build into order sets will need to be reviewed by the orders build group before they can be added to the order catalogue. If everyone is at the same table, this dialog will happen appropriately without being “lost in translation” later.

• Ensure clinicians have run through real-life scenarios with order sets before go-live (“usability testing”).

4.3 Alerts/Clinical Decision Support NYGH Lesson Learned

• NYGH uses Multum medication and allergy alerts and Dose range checking along with some

custom alerts. • Multum drug /drug alerts – started off at go-live with only MAJOR alerts firing to physicians, to

avoid alert fatigue. INTERMIDIATE and MINOR alerts fire only to pharmacists. NYGH CMIO tested adding INTERMEDIATE alerts to his Cerner profile, but quickly turned it off because there were too many annoying alerts. These alerts were never tested on other physicians in a live environment.

• NYGH alerts on missing allergies in all clinical areas, but not missing height/weight (except Pediatrics).

27

• Duplicate therapy alerting is too primitive – these fire only to pharmacists in PharmNet. Not enough customizability in Cerner yet to make the alerts useful to physicians without alert fatigue.

• IV Heparin prescribing was problematic – therefore built Custom rules – to adjust dose if bolus or infusion dose were too high.

• VTE Prophylaxis – did not turn it on at go-live – turned it on after about 3 months – clear benefit on this one.

• C-difficile alert is a custom one that looks back 6 months and looks for positive C. diff result, then alerts if new antibiotics are ordered by any provider (to prevent relapse of C.diff).

• Sepsis alert has been a lot of work, tweaking and monitoring to get it to work o Their tool walks the nurse through steps to force them to think about it, not a score but

a criteria o Supports nurse to follow some medical directives

• Banner bar: NYGH built custom code for banner bar for disease and process alerts, as well as code status and patient isolation status; Antibiotics resistance in not part of NYGH banner bar.

Content Shared • Sepsis alert and content shared • NYGH Book Chapter on Alerting & Clinical Decision Support

Key Recommendations • Make conscious decisions around alerting levels. • Monitor your alerting levels and tweak after go-live if necessary to prevent alert fatigue. • Spend time on the Sepsis Alert to build properly and continue to monitor and tweak. • Duplicate therapy alerting may be too primitive.

4.4 Dose Ranges NYGH Lesson Learned

• Range Doses/Frequencies

o Removed range frequencies and did not build range doses for standard medication orders

o Kept range frequencies for PRN medications o For high risk meds (Opiates) –the lowest dose is the default amount o For low risk meds- default is the high range dose o ISMP recommendations based on paper world risks, not always translatable to

electronic • Dose range checking alerts

o In the beginning of CPOE NYGH built approx. 10 meds with alerts and 50 pediatric alerts o Built age specific dose range checking alerts against a matrix for the pediatric specific

ranges, and for certain drugs (e.g. antipsychotics) in the elderly range o Set a maximum for single dose, or total cumulative dose in 24-hr period o Follow Hospital for Sick Kids formulary for pediatric prescribing

Content Shared • NYGH Book Chapter on Alerting & Clinical Decision Support

28

Key Recommendations

• Review NYGH Book chapter on decision support for many recommendations.

4.5 Quality Assurance/Design Validation NYGH Lessons Learned

• NYGH has a Core team that includes nursing professional, Allied health, Clinical Informatics, Physicians and Pharmacy that review changes – Clinical and Technical expertise around the table

Key Recommendations

• Quality Assurance and validation of design needs to be an iterative process. • Recommend that Unit Testing should not occur until the design and build is complete and

validated. • Recommend not signing off design until we see the full build. • Need physicians to be able to review so changes and tweaks can be made. • You can use prototype or mock-ups (physicians aren’t going to get it until they see it). You may

need to go back and demo different versions – or demo 2 or 3 options in one session, if a clinical decision is needed on which option best meets clinical needs.

• Workflow is a key element to validating design. Recommend not creating/reviewing a workflow without everyone involved that the workflow affects.

• Recommend being cautious about making changes for the right reasons, do not make them to reduce a perceived possibility of resistance to change.

• Recommend developing a good policy defining criteria to justify and triage requested system design changes – such as impacts on patient safety, quality, new evidence that has become available, formulary or clinical policy changes, etc.

• Recommend building capacity into clinicians schedules for review design, because design hasn’t been seen, they need to be prepared to have time to review.

4.6 Message Centre Deferred to Provider Team discussion.

4.7 Strategy to Identify and Quantify Impact to Operations NYGH Lessons Learned • NYGH CEO noticed a significant shift of nurses moving away from patients, and spent more time

with the computer after go-live – major concern – took a few months for things to go back to normal.

• NYGH had a 4 weeks 24x7 support model post go-live for each phase of eCare • NYGH Clinical Informatics department is responsible for project and operations (different from

our structure)

29

4.8 Mandatory Documentation Requirements NYGH Lessons Learned • Included mandatory documents in their workflows • Built in time stamps for mandatory report requirements from ED • Some reporting they did not build in • Cerner was not a valid place for some of this data - kept some as a standalone for that reason • NYGH decided to relegate ICD-10 to back-end coding purposes, and SNOMED-CT was chosen for

encoding diagnoses and clinical findings in the front-end patient record (Cerner). SNOMED-CT was used for this purpose as per Canada Health Infoway recommendations.

• Medication Reconciliation: o Original % complete was 8% on inpatient volume on Medicine units – went up to 70%

on discharge but only 40% on admit Found the cause of Med Rec on Admit % low was due to the workflow in ED -

physician on call didn’t have the best med history and had time constraints – they entered what they could, but often couldn’t complete MedRec. The following morning, the receiving ward-based physician wasn’t doing the MedRec because they incorrectly assumed it was already done in Emergency the previous day by the on-call physician.

To mitigate this issue NYGH added new custom alert (Logic: Are you attending physician, are you opening chart, is admit med rec not done, is bpmh already done?)

This caused a significant improvement, such that now the rate of admission MedRec has surpassed discharge med rec (about 85%).

Key Recommendations • If there are report requirements, plan that from the beginning and build around it. • Data Analytics will need to be involved in mandatory documentation discussions. • Use Favourite lists for Problems & Diagnosis.

4.9 BMDI NYGH Lessons Learned

NYGH ran an RFP for BMDI and Cerner won the bid. Through that process they leveraged the ability to do a full assessment and inventory of the devices for costing.

NYGH found that the big win in Critical Care, O.R./Anaesthesia and Maternity areas was BMDI. Without it, clinicians would have been burdened with too many items to enter, taking them away from patient care. Instead, with BMDI, areas requiring frequent entry of trended data such as vitals and ventilation parameters now actually have more time for patient care than when they were documenting on paper.

NYGH built room-specific connectivity engines in each room. Plug devices into that connectivity engine and associate the patient to that room, (i.e. PACU, ICU, OR).

NYGH did not find any major impact on network or infrastructure due to BMDI.

30

No impact on wireless infrastructure because generally bedside medical devices are wired, not wireless

Licencing costs are not significant for BMDI. Support: Biomed is now under IT at NYGH – shared support model for BMDI between BioMed

and IT.

Key Recommendations

• Re-evaluate CST decision on BMDI, there will not be buy-in for Maternity, O.R./Anaesthesia and Intensive Care without it, as it is essential.

• Anesthesiology management should not be implemented without integration. • Recommend Cerner completing a review of our device inventory to determine which devices are

Cerner certified. Alternatively, give Cerner a list of devices and ask them to say which are Cerner certified.

• Recommend Cerner completing a technical readiness assessment for us. • Recommend using connectivity engines where possible, as Cerner owns the support for these

and we can direct all issues to Cerner if required, to avoid finger pointing (versus using third party).

• Dedicated PHSA BMDI staff resources are recommended.

4.10 Charge Capture NYGH Lessons Learned

• NYGH still has some manual processes for billing (i.e. patient to billing for crutches in ED) • Clinical informatics builds charges - 1 person is responsible for the Charge Capture build for all

modules • NYGH builds charge capture through orders rather than documentation

Content Shared

• NYGH to send Export of charge capture catalogue

Key Recommendations

• Charge Capture should be included as part of the RadNet build, it is not a separate module in itself.

• Recommend building charge capture through orders rather than documentation, as through documentation it may result in drops of the charge for procedures not completed, which are difficult to reconcile later. Only want to confirm charges once the procedure is done – upon signing.

31

4.11 Enterprise Build versus Localization Build NYGH Lessons Learned

• Additional complexities if you have patient flow to different places with different orders available

• You can hide DTAs based on location in iView • Orders/order sets can be displayed based on facility using virtual views.

Key Recommendations

• Build Preference Cards based on location and schedule • Orders are different by each site and would be localized - Can use Cerner virtual views

4.12 Reporting

NYGH Lessons Learned

• NYGH analytics tool (Cognos) doesn’t support all of their clinical reporting needs, due to its capabilities. Clinical Informatics has to pick and choose which data to send to the data warehouse. For example they can’t monitor Sepsis easily with current BI tool.

• NYGH uncovered a lot of data quality issues with their transition from ORSOS to Cerner • Discern Analytics is used by Pharmacy and Finance and some other non-IT areas, no issues with

this. Most people teach themselves or quick training if they have some IT skills already. However, it can cause performance issues to run reports in Discern if too large a data set is run.

• Approximately equal numbers of reports are CCL versus run from the data warehouse (Cognos)

Key Recommendations

• Recommend including clinical resources and operational IT resources who know Cerner involved in the selection of the analytics tool, to ensure knowledge of clinical requirements and the Cerner data model are included in selection.

• Recommend building a good report inventory based on current state reports. • Recommend running reports off standby database – not off Production • Ensure you look into the current state process around ORSOS and reporting to ensure we are

not automating bad process. Need someone with good understanding of current state to be involved in the transition to Cerner

• Surginet Report builder reporting tools are robust and can be used to build a lot of reports rather than CCL. This can be done by Application team.

• Power Insight - NYGH have not used it much, but recommend viewing the demo

32

4.13 Operational Planning: Sustainment/Structure/Continuous Improvement NYGH Lessons Learned • High-level Organizational Structure

o VP’s responsible for and accountable for: Pharmacy, Medical Informatics and Professional Practice They are directly impacted by the project operationally

o Project leads are Director Level responsible for the operations of key area going live and report to VPs

o At NYGH, Project manager reports Clinical Informatics, but indirect report to Project leads

o Expectation is that the project lead ensures all stakeholders are kept informed. o NYGH does not have a project management department. This is primarily due to the size

of the organization and other departments that take on various project management roles.

• Clinical Informatics Structure o NYGH has 18 FTE in Clinical Informatics including manager. Of the 18 staff, 14 are

clinical professionals (primarily nurses). o Responsible for system design, build, ongoing maintenance, support, training and report

writing. o Report up to CIO o No link to professional practice but tight working relationships with professional groups o Various clinical 12 application consultants/builders, 3 trainers, 1 integration analysts,

and 1 CCL programmer o Same team for project and operations work o All Communications about system changes go through the Clinical Nurse Educators o Often operational support and maintenance goes on hold when they do projects. Only

urgent changes are addressed during implementation. • User Provisioning:

o Helpdesk oversees provisioning process for AD, and email access One ticket for on-boarding from human resources with tickets that spawn from

that to other areas Hand out email accounts when they come to orientation

o As staff gets hired they have staff orientation and training for clinical applications set-up prior to orientation. No access without training.

• Governance Structures: o eCare CORE – meets weekly – any process that touches multiple groups, reviews change

requests that impact multiple groups still meets post project for ongoing system maintenance decision. Core team includes pharmacy, informatics, PP, allied, nursing, MD

o eHealth Steering – makes decisions about capital investments. o Nursing Informatics Working Group- group of front line nurses and educators o Allied Working Group - people for all allied health disciplines o Order Set Committee – order set team – CMIO, order set physicians, informatics,

pharmacy. • Central vs. Decentralized Scheduling

o Registration processes are centralized, but scheduling is de-centralized

33

o They manage scheduling templates internally o Clerks can change the slots, but they can’t create appointment types o They have appointment type standards- usually tied to reporting type o It is a lot of workload to manage templates o Don’t want to leave it open to anyone as when a clerk leaves, you might not remember

what the appointment type is Content Shared: • NYGH to provide the Org structures diagrams shown • NYGH to provide CPOE framework document

Key Recommendations • Include in your project structure an Executive Sponsor who is directly responsible to the people

who are directly accountable for the clinical areas. • First implementation will set the tone for all subsequent implementations so it is critical to get it

right the first time. If you can pause now, DO IT. • Clinicians need to see the build to better understand their design decisions. There is value in

building internal capacity to iteratively make build changes and resolve issues. • Send your clinicians to Cerner maintenance training so they fully understand how to build which

will inform full functionality. • Make significant changes to MethodM methodology. Do your maintenance training first in the

process to ensure you are prepared internally to support. • Consider fee for service in situations when you can manage work required. When scope is not

well defined, fixed fee quote will often come in high and additions to scope will be expensive.

4.14 SNOMED / ICD 10 NYGH Lessons Learned

• NYGH decided to relegate ICD-10 to back-end coding purposes, and SNOMED-CT was chosen

for encoding diagnoses and clinical findings in the front-end patient record (Cerner). SNOMED-CT was used for this purpose as per Canada Health Infoway recommendations.

Content Shared • NYGH to share their SNOMED and ICD 10 favourites folders

Key Recommendations • Use Favourite lists for Problems & Diagnosis – customize these lists based on physician specialty

and practice patterns.

34

5.0 Key Workflows NYGH Lessons Learned Sepsis workflow • Specialized workflows such as their Sepsis workflow took a lot of tweaking. • NYGH chose one symbol/character to indicate reference text throughout their forms as part of

their style guide. By clicking this symbol it will take the user out to their intranet and to the PDF of their policy.

Admission workflow • NYGH chose not to automate Pre-admission orders to prevent floating orders.

Orders/PowerPlans get associated with encounters once the PowerPlan is initiated. • For all new admissions, NYGH created a rule that triggers a careset of orders including standard

documentation tasks and assessment, e.g. Admission assessment, Adult Shift Assessment, Adult pt history, Braden score, ADL etc. This careset is customized to patient type – med/surg, paeds, mental health.

• They set up alerts to be triggered from Nursing orders, e.g. Safety Alerts: Danger to Self, Danger to Others, Falls Risk, Wandering or Elopement, Withdrawal Alcohol or Drugs, No Blood Products

• For Antimicrobial stewardship, there is an alert that looks for the last 3 months for results and fires if patient has a positive result for cDifff and ordering specific antibiotics that can trigger relapse. Other discern analytic reports have been created to support antimicrobial stewardship.

Transfer workflow • If different organization, then discharge: all orders are discontinued and new orders are

required – this is the case for mental health inpatients. • If within the same organization, but different level of care, then clinician needs to review orders

and manually discontinue what is no longer needed order, reconcile the orders, change the MRP, new admission orders

• Cross-encounter functionality- Brand new functionality, needed to take code for it o Used for "Discharge and readmit" because patient being moved to a different organization o Pulls all other order categories other than medications, select the orders you want to

move, orders go into a proposed status (holding area), then when the new encounter is created, physician signs them, and now they are attached to the new encounter.

o Physician can modify proposed orders, nurse can only initiate pending orders Discharge workflow • Depart is only given to physicians at NYGH, it includes: free text boxes, med rec that is pulled in,

lab results pulled from a smart template and DI can be cut and pasted from reports. Other notes • NYGH does not use the Microviewer tab – wasn’t ready for use yet Content Shared: • Sepsis Policy and rules and a screenshot of PowerForms • Screen shot of "order entered secondary to patient admission" for standard patients and for

peds • Screenshots of Discharge Planning PowerForms • NYGH to provide workflow or document for Transfers NYGH to provide specifications of the rule

for Cdiff and reference documentation (handbook) that currently lives as a link in the Orderset • Screenshots of the Pneumonia Orderset

35

• Screenshot of the PowerForm of the BPEWS • Screenshots of Discharge Planning PowerForms • Screenshot of DC Planning Specialty Flowsheet


• For Sepsis workflow, build out the rules and monitor sensitivity by running alerts in the background and auditing appropriateness. Once the team is confident with the validity of sepsis alert, then turn on and audit effectiveness. How many false positive? How many patients admitted to CrCU and work back to see when alert triggered. Should it have prompted earlier?

• For standard practice have orders that trigger on admission, but for specific orders to patients, they should be entered in the system separately through communication orders.

• If you can avoid discharging patient, per your policy, avoid it, as order management is much simpler with the transfer process.

• Many alert requests may come forward to ensure alignment with standards. Make sure there is a team who will apply good judgement on which alerts are worth building. If the practice being recommended for alert is standard practice, then an alert is not the best tool. Reserved for critical practices that have significant safety implications if missed.

6.0 Design Teams The CST Project Design is being developed by various Clinical Design Teams comprised of Clinical Leads and subject matter experts (SMEs). An initial review of each design team has occurred to determine key areas of concern in preparation for this review. Meetings have been set up with each design team to review their design and build, focusing on the focus topics outlined below.

6.1 Provider NYGH Lessons Learned • Determine number of order sets to be built for go-live by covering 80% of discharge diagnoses

(rank-orded by volume) based on a year’s worth of discharge data – also called a “Gap Analysis” • Set the following process to review orderset build with our providers:

o Orderset was prototyped in Zynx o Orderset in Zynx Viewspace to be reviewed by providers and other groups (nursing, lab,

radiology, pharmacy, allied health, then physicians) o Feedback provided using Viewspace is collated o Meeting setup with stakeholders to discuss feedback, if required due to disagreement

on content or review comments o Approval - used to be Medical Directives and Order Sets Committee, but now they go to

MAC MAC have the power to veto until it is fixed, but they aren’t really required to

approve They more so ensure policies for order sets are being followed (e.g. Enough

36

reviewers – 3 MD’s per order set at a minimum, with subject matter expertise) • They tried to avoid non-static URLs for custom evidence links • They discovered that Message Center Messages and Reminders made sense to implement in an

Ambulatory setting, but not in an Inpatient setting • Outpatient results were taken out of Message Centre, because MD’s were having to endorse

both paper and electronic copy (couldn’t turn off result printing since not whole hospital is live on Cerner yet). Inpatient results were never built in Message Center since physicians review these results already on daily rounds.

• They only used Zynx paper ordersets to support Downtime ordering procedures. They didn’t want users to get used to ordering using paper.

Content Shared: • NYGH to provide the Style guide and policy guide, order sets development policy – From CPOE

Document • NYGH to send us an extract of the Zynx order catalogue document (code-set 200 etc.)


• Align the orderset design/build with Zynx standards and best practices • Maintain Zynx as your source of truth for all order set content • Ensure you have a robust order catalogue to support the orderset design and build • Ordersets need to be reviewed by their respective provider specialities • Orderables’ primary names should be intuitive to clinicians, and synonyms must be built to

support the ordering process. • When designing your order entry formats, consider the following:

o Mandatory fields design o Cross departmental agreement on the order entry format fields o Do not use order entry formats as a documentation tool

• If circumstances where Zynx Evidence Links is not sufficient, ensure you have a policy in place to review, approve, and manage custom links

• Use of favorite ordersets, but not the use of favorite PowerPlans • Do not use PowerPlan subphases, which can be very confusing to clinicians who are still

learning the Cerner tools

6.2 Clinical Documentation / Maternity / Orders and Results

NYGH Lessons Learned:

• NYGH did not use the handoff communication MPage. They found that a combination of a communication PowerForm and displaying the communication results on a custom flowsheet,

37

was a better method of interdisciplinary and end of shift handoff communication. • NYGH built tasks for regular assessments to ensure ease of access to those • NYGH built multiple specialty flowsheets to support clinician viewing for results documented in

PowerForms and IView. • They built the order catalogue in an iterative approach. Each order was designed with clinician

input, then mocked up and presented to clinicians for validation in Cerner. Clinicians with subject matter expertise were asked to validate orders pertaining to their specialty (e.g. Cardiology orders by Cardiology, Orthopedics orders by Ortho, etc.). Once the standard order catalogue was reasonably well defined, it was exported from Cerner and imported into Zynx for order set development and review. It was expected that not every order would be finalized on the first attempt; orders pending further design/approval were given “placeholder” names in Zynx until they were finalized in Cerner. Then, subsequent order catalog extracts from Cerner to Zynx allowed these remaining orders to replace the placeholder names in Zynx.

• They did not use the Depart Process to produce the final discharge summary, since: 1) it could only be copied to one external provider at a time, and 2) it was not possible to lock it down so that changes to the report body could not be made after the patient was discharged. However, we still use the Depart Summary as an interim document to give to the patient and auto-fax to the family doctor at discharge, since we have designed it to contain a summary of discharge medication reconciliation, discharge lab values and imaging test results, follow-up appointments and further patient instructions.

Content Shared:

• NYGH to send a screenshot of ESH • NYGH to send List of orderable equipment • NYGH to send List of charges • NYGH to send custom CCL for pregnancy summary • NYGH to send Discharge summary document(s) of a maternity patient.

38


• Build a style guide for IPOCs, including standards of care before you initiate the build • Do not rely on rules and alerts to support clinical workflows where clinical judgement is

necessary • A rule should never automate a clinical action without first informing the responsible

clinician and obtaining acknowledgement/consent for the action, e.g. a rule that is about to cancel an order needs to clearly inform the user of the order it is about to cancel.

• Do not rely on tasks for aspects of routine clinical workflow. Overtasking can impede workflow.

• Identification of key operational resource to act as the point person to support the build and maintenance of the ESH as well as security positions.

• Minimize the use for “Carry Forward” functionality as part of clinical documentation • Minimize dropping charges through documentation, but rather use orders to drop

charges.

6.3 Medication Management NYGH Lessons Learned Key changes related to policy and procedures • NYGH added instruction in the medication administration policy to check orders and eMAR

every 2 hours minimally. • Added high-risk double checks for;

o Took a small subset from ISMP and took those high volume and high risk to develop dose range checking

o Nurse witness for specific meds and independent double check for some o Insulin, heparin, PCA, PCEA have workflow maps to clarify administration process.

• NYGH pulled list of meds (had PharmNet prior) from med ordering o For med admin, NYGH changed/added guidelines around med admin times, staggering

doses, how to get patients back to regular schedule; med ordering policy was modified and had procedures for administration

• NYGH has not had an issue with nurses removing armbands (and attaching to clipboards, for example) from patients and have not required to have a policy around this.

o There is a policy on re-printing of armbands • NYGH has a policy for the management and approval of policies. Pharmacy and Therapeutics

(P&T) approves formulary additions. • Non-stop medication policy that was issued for eCare Project – previously, all meds had soft

stops at 30 days requiring renewal. o New process to have all home meds documented within 24 hrs of admission. o Most meds can go on indefinitely except some (opioids, etc. which have hard stops)

• Pediatric meds auto-stop policies o There are pediatric-specific policies and dose standardization policies o There is no difference between adult and pediatric schedules

39

o Dose rounding occurs at the Provider level (Provider chooses “apply standard dose” (default) - Provider can also apply custom doses but Pharmacy can override these

Integrated Medication Process • Non-formularies are captured in NYGH policy as well as pass meds. • Pass meds are ordered through CareSets; physician notes when they are leaving and returning

and they can define meds through this timeframe; must put PRN in free text fields so pharmacy and dietary receive messages so all teams are in the loop;

• “Patient out on pass” message is distributed to all relevant parties; “PRN medications” will pull from meds and will be automatically filed out and then can be changed/adjusted by provider; scripts pull PRN meds, done by changing rank number, this is a CCL report; consult to pharmacist but how CST uses multi-patient task list has not been defined (demo done on-screen)

• Non-formularies o At NYGH, only high risk non-formularies are in system with an icon because we want

non-formularies to be checked o For all other non-formularies (NF) not in the system, you need to use NF template as an

order entry form method; NYGH added fields asking physicians for rationale for using non formulary

o Physicians are not asking for additional non-formularies to be built in; NYGH currently has around 100 non-formularies build in to the system

o Non-formulary diabetic medication is a separate non formulary template so they can display on diabetic flowsheet.

o Provider must choose “non-formulary diabetic med” instead of “diabetic med” to ensure medications and blood sugar are tracked appropriately; name of meds are entered by free-text when provider chooses “non-formulary diabetic med”

• Ward stock vs. Pharmacy supplied varies by unit; however, pharmacy usually dispenses majority of unit dose meds for all patients except in CrCU and ED where floor stock is more prevalent.

TPN • NYGH does not use PowerForms for any medication orders – all orders are done through

PowerChart and typically in PowerPlan (Order Sets) • NYGH does TPN in PowerPlan so labs can be ordered at the same time

o CST Med Mgmt team has decided to use PowerForms for TPN order entry and then Pharmacy inputting TPN orders in PharmNet

o CST chose to go with PowerForms due to ease of entry for users and the capability to add additional reference data including images and pdfs (for instructions)

o Currently no interface planned with PharmNet and BAXA compounder • NYGH uses Baxa label and Cerner dispense label with barcode; Cerner label is not as detailed as

the Baxa label o CST pharmacy is going to do double order entry; we are looking to use PharmNet to

build out a TPN label instead of using the Baxa label because we want to use Cerner label on TPN bag instead of Baxa label

• NYGH advised that their method of using PowerPlans seems easier for the physician and pharmacy users but NYGH is doing a small number of TPNs per day (2 – 10)

• If you use an orderset in PowerPlan, any alerts will pop up for the provider but in PowerForms, alerts will show to Pharmacist so there is no interaction checking for additive ingredients; electrolyte fields are like free text so there will be no interaction checking

Immunization and vaccinations

40

• NYGH has not used Cerner immunization schedule tool because they are only one hospital and the volume of entry is too much; if family physicians, etc. were updating the immunizations, there would be value; currently NYGH forces providers to enter administered vaccination details on the eMar as medications

o CST needs to keep in mind the context for Panorama; there is double-entry in keeping Cerner and Panorama up to date and there is no planned interface at this point; Panorama is the planned source of truth for vaccinations; Panorama does not interface with CareConnect in current state

Narcotics printing and Pre-drawn Syringes • NYGH does not have specific requirements for narcotics prescriptions; orders go on regular

paper with other orders • Pre-drawn Syringes

o Pharmacy has premade vials with the non-patient specific barcodes on the vials o Nurse has to write down the dilution on separate labels, stored where medication is

stored o Pre-drawn syringes are only available in certain areas, where procedures are done o NYGH has to indicate dilution on CareMobile scanner before medications are

administered o NYGH did not have an order profile going to Omnicell so new functionality regarding

patient-specific barcodes has not been investigated Pharmacy Multi-Patient Task List • NYGH has one multi-patient task list for Pharmacy that users can filter based on location • At NYGH, pharmacists try to close off forms in the day and do a lot of pharmacist follow up • If required, there is a note to follow up and the next pharmacist on the unit checks the task list

and follows up • Physician requests for consults are also on task list Content Shared: • NYGH to provide med ordering policy and guidelines around med administration • NYGH to send screenshots of pass medication ordering screen • NYGH to send a sample of pre-drawn syringe label and procedure around pre-drawn syringes • NYGH to send a complete list of standardized dose medications • NYGH to further investigate the mechanism of alerting for TPN • NYGH to find out which third-party vendor NYGH uses for pre-drawn syringe labels • NYGH to send a sample of pre-drawn syringe label, and procedure • NYGH to send Medication Administration Policy • NYGH to find out how Pharmacy tracks inventory if not using Pharmacy Supply Chain module • NYGH to send complete list of standardized dose medications

Key Recommendations • Medication dispensing and administration workflow will change significantly. Consider running

a 2P event to map current state, define standard practice, map future state and consider a FMEA to gain trust in clinicians that all potential points of failure have been considered and

41

mitigated. • Ensure thorough review and appropriate revisions are made to Medication ordering and

administration policies and procedures • Look closely at workflow and lessons learned on Pass medications • Consider revising approach currently designed around TPN medication ordering to use proper

Cerner tools to order TPN (i.e. PowerPlan Order Set not PowerForm) • Immunization tools are not that valuable if source of truth for all immunizations is not stored

there – i.e. Panorama • Build out high-risk non-formulary medications as specific orderables instead of using non-

formulary order form

6.4 Emergency Department NYGH Lessons Learned

• Only Cerner use in ED is Registration – Triage and ED tracking is in another system - Everything else is in paper and orders transcribed into Cerner

• Clinicians do use Cerner to view results • Order entry needs to be streamlined for ED as pay for performance indicators are critical for

funding and anything that introduces inefficiencies will not be tolerated. Content Shared: • NYGH to send a screenshot of the tracking board for consults in ED • NYGH to provide screenshots of what they have in WellSoft


• Do not carrying forward a lot of information for transfers o Really evaluate if you want to carry anything forward – this is not best practice. If

practice is so common that data is carried forward, consider why it is being charted so frequently. Carry forward clutters clinical results review with duplicate results.

o Should really be charting only what you assess and must make sure what you carry forward is accurate before you sign it

• Use PowerForms for things you want to assess once and IView for continuous assessments or elements that will be trended.

• Recommend WOWs as best device for Emergency department as there is flexibility on where and how they can be used.

42

6.5 Health Information Management / Scanning NYGH Lessons Learned: • NYGH added a disclaimer on printed documentation stating “Not part of the legal record if

printed from Cerner” • They use ROI to support external chart requests, e.g. lawyers • NYGH only scan clinical documents, no personal documents e.g. driver’s licenses • They give their researchers view only access to Cerner. Approval for researcher access goes

through the Privacy Officer • NYGH use Lock Box functionality – a custom solution to a support a deficiency in Cerner’s

functionality. The custom solution alerts the user attempting to access the patient’s chart when a Lock Box order is placed on that patient’s chart.

Content Shared: • NYGH to share their Legal Health Record Policy • NYGH to share policy regarding forms control • NYGH To send their Downtime procedure • Request the HIM scanning process package

Key Recommendations: • Use document bar codes to support batch document scanning. This will help automatically

identify document types, and flag any unmatched ones • Message Centre deficiencies fall off after 90 days. Develop a process to mitigate this risk

6.6 Medical Imaging NYGH Lessons Learned:

• Outpatient requisitions come in via fax, which are added into a request list that clearly displays the priority and encounter type (inpatient versus outpatient) in scheduling. The request list is filtered by Modality.

• Medical imaging department is centralized scheduling, which makes it easier to book across modalities (which is done by the same group).

• They protocol sheets and coding is all done on paper. • Still working out a process for protocolling. Orders are currently documented on a coding sheet

and verbally communicated to the unit. Ideally, we’d like it viewable in PowerChart. We are beginning to develop Order Sets to support this (such as prep for CT enterography).

43

• Currently the protocol sheets are scanned into PACS but not Cerner. NYGH is trying to change this to have these documents scanned into PowerChart.

• Temptation to think that CPOE is going to replace clinical communication, but it cannot. Some things still need to be communicated between unit and MI e.g. when patient needs to come down.

• If orders more complex, MI physician will put in the order set as a suggested plan and then the most responsible physician authorizes, and the nurse needs to be communicated to

• Challenges getting radiologusts to go into PowerChart, when they are used to being in PACS and RadNet

• They have thick installs at NYGH for all Radiologists to help them log-in for Citrix • They do not currently document medications that are given in Nuclear Medicine. We are looking

to keep as procedural medications, rather than having it as an order. • Charges are dropping in Cerner and are sent out to a third party billing system • NYGH built ops jobs to run Medical Imaging reports at certain times of the day • Patient Alerts print off the requisitions, but they are adding alerts to the banner bar (not sure if

it can be done for RadNet).

Content Shared:

• NYGH to send example of the coding sheet for MI • NYGH to provide more information about launching both PACS and Cerner • NYGH to Send a spreadsheet of DI charges and how they have them set up by procedure


• Considering the use of more group ordering. o When scheduling a procedure we can group in other orders, so once scheduled it

can kick off other orders. • Using Discern Analytics to run existing MI reports first, before building custom CCL reports.

Give Medical Imaging the responsibility of running their own reports in Discern Analytics. • Build a comprehensive strategy for Cardiology solution • Must build charge services in Cerner for Medical Imaging

6.7 Registration / Scheduling NYGH Lessons Learned:

• NYGH design for Registration conversations included their reporting requirements. • NYGH do not use Waitlists or Requests lists with the exception of Medical Imaging; instead they

use a web form to request referrals. • They centralized the ongoing support and maintenance of Scheduling Templates • For patients coming in for surgery, since there are no encounters to attach the orders to, orders

44

are written on paper and sent to the booking clerks.

Content Shared:

• NYGH to provide medical service code set (Code set 34)


• Build the Registration rules on the new Person Management rules engine • Implement the Appointment Tab in PowerChart to support the viewing of appointments at

the patient level • When designing the Discharge and Transfer project, approach it with the following concept “if

you don’t have to discharge the patient, do not discharge the patient”.

6.8 Surgery NYGH Lessons Learned:

• Change management for anesthesiologist was not an issue, since they were fully engaged and drove the design of the module

• The move from ORSOS to SurgiNet proved to be more challenging than expected. Switching systems was a more difficult change management exercise than transitioning from paper to electronic, because users were attached to the way they used to do things in the old ORSOS system

• For narcotics discrepancies, the nurse educators run audit reports and follow-up • For intra-op medication administration documentation:

o Going from eMar to SurgiNet and back is not a good flow o If not systemic, then documented in eMar, if systemic, charted in Surginet o Suppository- Physician gives It and charts it and nurse references Physician’s record

• For the implant barcode scanning parsing issue, they devised the following solution: o Nurses scan the implant barcode into a third party application which parses out the

barcode, and nurses copy and paste the codes into Cerner. o Back-up is to keep the stickers on paper

• WOWS provide flexibility in PACU, tablets are too small • Do not think doing Q5 in recovery without BMDI is possible, too difficult • They developed a PACU quick assessment band for quick procedures • They used ORNAC standards when designing the intra-operative documentation • NYGH aligned definitions of surgery start and stop time with finance start and stop time Content Shared: • NYGH to provide a summary list of their surgical reports, including how they supported each of

45

them (Report Builder, CCL, Discern Analytics, etc.)

Key Recommendations: • Identify the ORSOS and ORMIS data quality issues now before implementing SurgiNet • Do not implement the Anesthesia module without BMDI • Recommend evaluating what intra-op medications nurses are administering and decide how

that will be charted (irrigation, eye drops, etc. might not choose to chart on eMAR) • Determine a solution/workflow for issue around parsing of scanned multiple barcodes for

implants, which is currently not supported by the Cerner solution.

6.9 Core NYGH Lessons Learned: • When deciding whether to combine 2 or more positions, consider the risk. If there is no risk

associated with combining positions, then proceed. • As long as users are trained on the functionality, and safety is not a concern, give the users the

access required to support their workflow without creating duplicate positions. • They use usergroups functionality to support credentialing, admitting privileges, and provider

searches • For maternity beds and bassinettes, we put the babies in the same rooms as the moms, but the

babies are registered in their own bed (different from their mom).

Content Shared: • NYGH to send set up of physicians and mid level providers document • NYGH to send ESH and event codes– Exports of it (can do both from the backend)

46

Key Recommendations: • App groups should be built by function and not by position • Build out all Document Types individually in the ESH to allow users to easily find the correct

document. If continuing to use telephone dictation in some areas of the organization, this will require review and revision of dictation codes entered by users (they may need to be more granular in order to support the system identifying and separating different documents as unique in the ESH).

• One or two key operational resources to support the build and maintenance of the ESH. Resources should be experienced Core, and all work funnels through them

• One or two key operational resources to support the build and maintenance of positions. Resources should be experienced Core, and all work funnels through them

• When building the access model, you should consider the following levels of access criteria: viii. Module/Apps

ix. Functionality within Apps - Exception groups – impact security outside of the position - Privileges/Preferences

x. Task Groups (Order tasking/Documentation tasking) xi. Discern rules (rules to specific clinicians)

xii. Access to registration conversations xiii. Access to reports xiv. Declaration of a relationship

7.0 Technical Teams NYGH Lessons Learned: • Closed loop medication administration

o NYGH established a working group made up of clinicians to map out current state medication administration and mapped out future state closed loop medication administration to find any issues or gaps.

o Quality & Safety group led a failure mode and effects analysis (FMEA) a few months before go-live to find any risk area in the process and identify mitigations. Was a great engagement and change management exercise with a key learnings that were found

o NYGH issued RFP for devices and asked vendors to drop off samples before device selection occurred; workflows were simulated using sample devices which gave rise to functional requirements (e.g. size of cassettes for WOWs so manipulation of medication sets in cassettes would not be necessary)

o Once standard workflows were developed, they created ranking criteria for devices. o For FMEA, every possible point of error was documented and ranked based on

probability and severity; score was combined, points for error were ranked, and mitigation plans were actioned; examples include: installing lights on WOW’s, raising the height of power outlets, purchasing wider monitors, revising policies, increasing education and training, creating tip sheets, etc.; these improvements increased buy-in

47

from clinicians • WOW’s

o Purchased WOW’s with lithium batteries and 22-inch monitors o Can be raised and lowered for user ergonomic comfort o Nurses prepare meds on the carts outside rooms, then go into rooms with CareMobile

device – Motorola MC75 o eMAR should always be reviewed on the WOW monitors, not on CareMobile device;

CareMobile is only good for reviewing 1 med at a time due to screen size o Safety value of Omnicell is absolved when you have CareMobile at the bedside;

Omnicell can still be used for ward stock but most medications are stored in cassettes in WOW’s; NYGH does not have monitors at Omnicells because they want to avoid nurses using Omnicells for general med dispensing

o In CareMobile, if faulty barcodes are found they are put in bin for Pharmacy to investigate. Meds can always be administered on eMAR if scan not working.

o If the wrong patient is scanned, nurse has to start med administration process again o Other positive effects of WOW’s include decrease in falls, increase in patient

interaction o NYGH implemented a campaign with signage asking people to not disturb the nurses

when they are preparing meds o All scheduled patient doses are in the WOW’s; there is very little bulk in the Omnicell

because drugs are individually packaged • Go-live strategy

o All of inpatient medical/surgery areas (250 beds) went live at once (2/3 of hospital) o Analysed flow of patients and included these areas in initial go-live, to not break CPOE

and eMAR as this would reduce the value and increases transcription by nurses o NYGH found that if you are not going live with all modules at once, an analysis needs to

be done to determine which modules are linked; for example, if you go-live with PharmNet, you also have to go-live with Registration

o There can be more risk than benefit to separate the go-lives per module • Tablets

o Initially, clinicians wanted tablets so NYGH purchased tablets but they are not being used due to: Small screen size (mounted C5) Large computer screens are preferred Clinicians like to use a mouse Tablets were implemented in PACU for post op assessments but not used.

They have since been removed. • Nurse-Mixed Infusions

o Barcode represents the whole vial so users must enter dose administered o System will alert nurse they are administering too much or too little of a medication

dose. o If nurse scans all vials required for a mixed infusion, changes concentrations, then

nurse can proceed to “to be signed” screen on scanner o Label printed is just a regular medication label and nurses write on it to indicate partial

dose.

48

Content Shared: • To send HIMSS presentation outlining clinician engagement device workshop

Key Recommendations • CST should outline workflow differences in medication administration between sites • Complete an FMEA with Quality and Safety experts before go-live to review device workflow • In addition to mapping workflow, CST should consider what is important to patients, staff (various

positions), and the organization when designing medication administration process; this will give insight into what should be considered in process redesign

• CST should consider where errors are occurring in current state medication administration workflows and use this knowledge to address these steps in future state workflows

• CST should have vendors give sample devices so clinicians have a better understanding of devices in order to determine functional requirements

• CST should finalize workflows before asking clinicians to choose devices; it is very difficult to ask clinicians to select a device if they do not know the future state workflow

• Do not break up COPE and eMAR; can cause an overall loss in value and an increase of chance for errors

• Purchase battery monitoring tools for the WOWs that allow you to run reports on battery usage

8.0 Clinical Transformation NYGH Lessons Learned

• NYGH found that nurses required two day training on system, as they found they focused on

how their practice would change rather than the details of the system. • NYGH modified training to have clinical nurse educators provide a 1 hour presentation on

practice changes and expectation for the first hour of training. This way, nurses could focus on learning functionality rather than being overwhelmed with expectation.

• Simulation rooms were set up with scenarios that nurses could work through in attempt to begin to “paint the picture” of what future state will look like.

• NYGH made training mandatory for all staff – could not work unless trained. • Online training was available for physicians. They were required to pass an in-class test to prove

they understood the system and completed the training. • Promoted physician adoption through communications during department meetings, demos of

ordersets, and involvement in orderset review. • Provided managers/leaders with key messages about the project, their roles and

responsibilities, tips and tools around access and training, and communications strategies. • Offered courses for those who self-identified as needing help with basic computer skills. • NYGH found that implementing a solution will amplify professional practice issues that exist. • NYGH found that they could have spent more time on change management, getting providers

on the system earlier.

49

Content Shared: • NYGH to share their journey presentation • NYGH to provide their posters for Go-Live prep • NYGH to share the presentation shown through Clinical Transformation discussion. • NYGH to share the screenshot of the portal they visited during presentation (process and

workflows page- quick reference guides, specific processes for orders) • NYGH to send available documents from their courses and learning curriculum. • To provide Manager Handbook • NYGH 1-pager, key messages about the project • NYGH to provide the Handout for Patients they developed • To provide Roles & Responsibilities document (mentioned it had R&R from Senior Leaders to

front line staff) • NYGH Go-live support plan • NYGH Physician education strategy • NYGH Communication Strategy • Staff education strategy and education materials, learning curriculum for staff • Workflow education strategy (if any?) • Quick Reference Guide for nurses • Template for your Icons/Placemats, Icon cards (for reference)

Key Recommendations: • Provide discussions on changes to practice during training. • If training in groups, it is important they see information relevant to them otherwise they get

caught up in content if it doesn’t relate to them (e.g. Orthopedic cases for Orthopedics) • Never say the system will be easier or faster, say it can improve patient safety with safer

workflows, it provides evidence based standardized care, etc. • Review current workflows for professional practice issues, as you do not want to build a

system on workflows that are broken. • Develop a solid change request process and tools for feedback. • Ensure there is a clear presence of leadership (CEO and VPs) during go-live.

9.0 Implementation NYGH Lessons Learned • Go-live support

o On every desktop there is a custom program that has a lifesaver icon that allows users to report a problem. The program takes a screenshot and user can attach a message directly to the ticket created. An email is sent out to the group with info on who is logged in and who the patient is.

50

o If a front line nurse has a problem, they call to service desk. o 24/7 floor and command center support during 6 week go live o Operational clinical resourcing - allowances were made for decreases in productivity o Scheduled backfill for nurses and double-upped physicians with one-to-one support for

start of shift o No other projects were allowed to be active during 3 month period o Clinical Informatics put blocks on vacation o Could not come to work If you have not been trained - Worked with unions on this o Role of Unit clerk changed, but job was not eliminated

Content Shared

• NYGH to share unit clerk responsibilities • NYGH to send the RDDS they used for cutover • NYGH to provide the detailed cut-over plan

Key Recommendations • Have a dedicated physician phone line - prioritized to the top of the queue. • During Go-live support grant the Clinical Informatics/support team with the ability to remote

into desktops to help see what the provider is seeing and guide them through issues. • Provide clear messaging every day from one command centre (open issues, concerns, etc.). • Use a broadcasting solution for communications on-site, such Vocera. • Have clinical person with deep Cerner knowledge in the call centre at all times during peak

go-live. • Provide physician to physician support for their first CPOE shift.

51

10.0 Relevant documents Please include a list with attachments of any relevant reference materials or documents that you feel we may find valuable.

Content Shared

• NYGH Process diagrams (management of clinical content, change control) • NYGH Provisioning • NYGH Organizational structure • NYGH Governance structure

53

EDR12 When we evaluated the role of unit clerks across our organization, we quickly learned that their work was not standardized. Some clerks did more order entry while others did

none. We discussed with union types of tasks that fit within their job description. It is then up

to the manager to assign work.

EDR16 See information provided by pharmacy

EDR15 Do not understand decision.

EDR30 We use US.

EDR22 The recommendation is that there is standardization throughout all units within the three HOs to one Intake and Output start time. This will allow for improved system performance. The recommendation at this time is to have Intake and Output start time be 0600 and 1800. The recommended time is reflective of what most clinicians practice in relations to the majority of shift change times and would help support contemporaneous charting.

Our I&O is standard across org. 0700-1500, 1500-2300, 2300-0700.

s. 21(1)

54

EDR23 Recommendation from the Clinical Documentation team is to not have patient sign that they receive education. Patient signing for education does not ensure or confirm that knowledge translation has occurred. Clinicians will still need to document that patient education and additional details have been done. Education/workshops should be developed for and made available to clinicians on how to provide patient education, and how to assess if knowledge translation has occurred. Standardized policy should be created for patient education to avoid discrepancy in future state.

No, not a requirement for us. The clinician does chart method of education and assessment of learning.

EDR43 It depends on situation. If duplicate patients are created and order or clinical doc has been added to both persons, the combine must occur immediately.

EDR44 No, we do not require this.

EDR29 Yes, recommend one order catalog and use virtual view to manage which orders are viewable in each facility.

s. 21(1)

56

EDR5

SME’s Recommendation: Create a “Miscellaneous Drug” selection within the drug allergy catalogue, with selection of this listing resulting in a free text box being available for the user to enter the drug name. This “Miscellaneous Drug’ option would be available for all providers (physicians, pharmacists and nurse practitioners).

SME perspective: The proposed allergy documentation process during the Allergy integrated session (April 29, 2014) does not allow the prescriber to enter an allergy for any medication not found in the drug listing. A process is needed for this information to be captured for patient safety when subsequent prescribers initiate drug therapy. A “Miscellaneous Drug” option would allow the prescriber to free text the name of the drug so this is captured.

We have blocked free text allergy entry. We have some coded allergies that allow the clinician to free text details. Free text disabled.

s. 21(1)

57

EDR13 Yes, templates managed by IS. Slots can be added by end users.

EDR17 Yes

s. 21(1)

60

EDR24 Yes, header and footer can be customized. Yes, this is an option. We have this for certain reports. We do not display address. Site is included in report content.

EDR34 Not sure what COMET is.

EDR35 Not sure what SYSCOMMON is.

s. 21(1)

61

EDR36

EDR37 Yes. Cerner uses Multum.

EDR38 Cannot comment

s. 21(1)

62

EDR45 After further discussion the team decided that that the assignment of this centralized group needs to be determined at a leadership level as there are multiple factors to consider

The HIM, Patient Registration, Patient Scheduling and Core teams met to discuss the process to manage downtime MRN and encounter numbers in the case of planned or unplanned downtime. It was decided that as a result of the large number of locations that create MRNs and encounter numbers and the need to ensure data quality that a Centralized Group should manage and assign downtime MRN's and encounter numbers. This will ensure the tracking of information and data integrity. The area that will primarily be impacted by this process will be Registration, Medical Imaging and Outpatient Scheduling

Yes, this is managed by our central registration department. Cerner 24/7 or Cerner Read-only allow look ups of MRN to ensure downtime MRNs are assigned appropriately.

s. 21(1)

64

Medication Reconciliation

Decided to complete manual entry of history of orders. Integrated with the provincial system.

• What is the process for manual entry of historical medications?

• Do you have any integration with pharmacy sources?

• Do you have a recommendation for adoption strategies of historical orders to enable med rec?

• Any further suggestions regarding med rec?

In order to be successful in MedsRec, home meds need to be entered in a timely manner. Home meds also aid in adoption in CPOE and prescription writing if appropriate build of outpatient order sentences.

65

16.0 Appendix F: Meeting Agendas

16.1 Key Strategy and Governance Topics 1

Interdisciplinary Documentation The CST Project team is struggling with strategy and tools for interdisciplinary documentation, given the division of the Clinical Documentation team that is focusing on Nursing and Allied Health documentation and the Provider team that is responsible for Provider documentation, per the TIBM methodology. Here are some of the questions the teams are interested in:

• Did you use start content, to what extend did you customize? • What is the ongoing document management for all documents; structure and process? • How do you manage clinical content management for documents, alerts, etc? • What are the key operational Impacts to moving to electronic documentation? • Describe the document strategy and the utility of building out PowerForms or structured templates formats in light of Dynamic

Documentation (DD) coming with eventual structure out of the box/ • Have you moved towards DD at all? • Is front end dictation used? Utility by what groups? • Are macros and auto-text used frequently? By what groups? • Clinical assessment tools, JPGs, ICU flow sheets, rhythm strips – are they still paper or built? • Scanning – at ward or end of encounter? • Are non-provider groups using Provider formats as a solution – such as power notes?

Order Sets

• What is your strategy and process for order set development and prioritization? • Do you leverage Zynx services, tools? To what extent?

Quality Assurance/Design Validation The CST Project is using a methodology of having clinicians who have been trained on how to complete a DCW, and they have been responsible for the design phase, working alongside TIBM. There are some concerns arising about standardization and quality of design.

66

• Given where we are, ending design and entering testing phase, to what extend should we be validating the design, before entering testing?

• What would you recommend on how to thoroughly and accurately assess and review quality of the design and build? • How do you ensure quality in your build strategy?

Message Centre • Which groups use the message center and for which function? • What is the process for urgent messages versus message center use? • Do learners leave messages here for each other – rounding, team assignments etc. • Where are Radiology discrepancy messages left – in RADNET or message centre?

Strategy to Identify and Quantify Impact to Operations With all the design decisions that have occurred, there is bound to be decisions that impact our operations in terms of: time allotment, human resources, and other financial considerations. CST is tracking decisions at both the governance and design team level for impact.

• From your experience where there any decisions you made that surprised you in terms of their operational impact? If any, what were they? How did you address them?

• Given our stage in the project, is there a more appropriate stage to understand these operational impacts? If so when? What is your recommended approach to these issues?

• Having reviewed our decisions, are there any decisions that we have not identified that will have impact to our Operations? If so, which decisions, and what are their impacts?

Cardiology Challenge is that we have different hospitals with different workflows, maturity of electronic system implementation and we are trying to standardize across various hospitals. What do you do when you are trying to standardize an Electronic system across the enterprise and at the same time you need to standardize the business to accommodate that change as Cerner standardization will not fit because the business processes and systems are different?

• What is your strategy for addressing Cardiology workflows? • Do your Cardiology areas use RadNet or PowerChart? • What are your recommendations around Cardiology?

67

Mandatory documentation requirements o What is your approach around ensuring mandatory documentation requirements (ie. Ministry of Health requirements) are included in the

design of your Cerner system?

16.2 CMIO Lessons Learned

Alerts/Clinical Decision Support

• What is your strategy and process for alerts and other clinical decision support tool development? • When you first implemented med order entry what level of alerting did you have? • Did you use customized alerts versus out of the box when you first went live with CPOE? • What are the pros and cons about a big bang versus methodical approach to alerts? • What are the key custom alerts that you have invested in? • Any other key lessons learned about alerting

Dose Ranges The CST project is experiencing challenges in coming to consensus regarding options for design of Dose Ranges in Cerner.

• When you first went live with CPOE did you implement dose range checking? To what degree? • Provide understanding with regards to the rationale for your dose range decision ( include implications for orders for each dose in the

range) • Provide understanding of how your decision has worked in the clinical setting from both and Nursing and Physician perspective: (

comment on: workflow, alert fatigue, human factors, medication safety, adoption as examples) • Anything you would recommend doing differently in your approach? ( comment on design, and policy as examples) • Anything you would recommend avoiding? (comment on design, and policy as examples)

BMDI

16.3 Key Strategy and Governance Topics 2

Charge Capture Key questions around charge capture:

68

• What is NYGH strategy around charge capture? • What is NYGH strategy and build around billing? • What charges are captured in Cerner electronically? • What lessons learned does NYGH have around Charge Capture/Charge Services?

Enterprise build versus localization build Given the size of the CST project deployment scope there is a localization phase planned as additional build needed prior to each unique site deployment.

o What would NYGH define as localization build versus enterprise build? o Examples: Schedules, Preference cards

Reporting Key questions around reporting:

o What is NYGH strategy, governance and sustainment model around Reporting? o What Cerner tools are used (Clinical Reporting/XR, CCL, Discern Analytics, other data warehouse)? o How are report requirements gathered, prioritized, implemented and sustained? o What is the composition of project and operations team around reporting? o Do you use CCD? Any recommendations on this toolset? o What other lessons learned around reporting does NYGH have?

16.4 Operational Planning Meeting: Sustainment/Structure/Continuous Improvement The CST Project is entering into planning for activation, localization, optimization and sustainment phases. Given the size and organization of the project, a change in structure is likely necessary to ensure sustainment and continuous improvement.

o What does NYGH org chart look like? o Where do the following groups report in your organization:

o Change Management, Communications, Training, Policy, Clinical Informatics o What is your User Provisioning process? o What is your operational governance and decision making structure and process? o Other specifics questions:

o Central versus de-centralized scheduling – what role does Health Records play in scheduling?

69

16.5 Key Workflows CST project is looking for recommendations on system and process design on the following workflows. Please include NYGH’s perspective, experience, and lessons learned on the following. A meeting has been scheduled to review these collaboratively and document the outcomes. Meeting schedule: Wednesday, Oct. 8, 9:00am-12:00pm 1. Admission (ED to Inpatient, Pre admission for Day surgery, Direct Admit)

• Specific question: Duplication of questions between Registration, Triage and Nursing • Specific question: Handling of orders

2. Transfer - with/without level of care change (include internal/external) • Specific question: Handling of orders • Specific question: For external transfers, how do you handle the patient’s chart?

3. Depart Process - (whole discharge process) Discharge Readiness included. • Specific question: Where do you document discharge planning sessions? • Specific question: How are you documenting patient education for discharge readiness?

4. Downtime process - Global strategy workflow - scheduled, unscheduled • Specific question: Would you be able to share your Global Downtime procedures?

5. Care of the patient with - potential infection, history of Violence and Aggression. • Specific question: How have you addressed Care Plans in your system design? • Specific question: Are you using Infection Control module?

6. Care of a deteriorating patient - Rapid Response & Code Blue • Specific question: Do you own/use the Cerner Rapid Response Module? Or did you create custom rules to address Mews/Pews?

7. Care of the patient at risk for aspiration and urinary retention (RNIA). (CPOE order - insert indwelling urinary catheter and related documentation, allied health - Swallowing assessment, IPOCs)

• Specific question: How have you designed Nursing activities that are initiated without orders (that is within their scope of practice)? 8. Care of a surgical patient (Pre/Intra/Post Op process (Inpatient, Day Surgery) 9. Scanning/ CPDI – centralized or decentralized 10. Medical student order entry 11. Problem/diagnosis - Problem list review and management - interdisciplinary 12. Patient Information Search in Legacy Viewers through matching in EMPI and the unmatched viewer. 13. Document Distribution Flow and Printing

70

14. Access to Patient Information by Non-Cerner End Users eg. Researchers 15. CPOE

16.6 Design Teams The CST Project Design is being developed by various Clinical Design Teams comprised of Clinical Leads and subject matter experts (SMEs). An initial review of each design team has occurred to determine key areas of concern in preparation for this review. Meetings have been set up with each design team to review their design and build, focusing on the focus topics outlined below.

16.6.1 Provider Meeting schedule: Tuesday, Oct. 7, 4:00pm-5:00pm Meeting Agenda:

1. Best practices building order sets 2. Order Set Style Guide

a. Standardization of build across specialty 3. Use of Sub-phases 4. Clinical Categories build 5. Build of Pediatric Order sets and IV Fluids 6. Engagement with Zynx and use of methodology 7. Transition period with both paper based order sets and electronic order sets 8. Message Centre

a. Scope of deployment, usage, maintenance, privacy 9. Key operational impacts 10. Workarounds

16.6.2 Clinical Documentation Meeting schedule: Monday, Oct. 6, 12:00pm-2:00pm Meeting Agenda:

1. Clinical Documentation Style Guide 2. IPOC

a. Ongoing maintenance of IPOC 3. MPages

71

a. How did they decide what MPages, etc., which were useful? b. What content (USA vs. CA)?

4. Design impacts, intersections and gaps between other design teams 5. Mental Health and Allied Health documentation 6. Key operational impacts 7. Workarounds

16.6.3 Maternity Meeting schedule: Monday, Oct. 6, 12:00pm-2:00pm Meeting Agenda:

1. Design Review 2. Maternity MPages 3. Key Operational Impacts 4. Workarounds

16.6.4 Orders and Results Meeting schedule: Monday, Oct. 6, 12:00pm-2:00pm Meeting Agenda:

1. Style guide for Orders 2. How to organize Order Sets 3. Standardization of Order catalogue 4. Depart Process 5. Referral Orders 6. Queuing requisitions – how to prioritize 7. Hybrid nature of orders received on Radiology 8. Intersections between inpatient and outpatient 9. Point of Care Testing 10. Virtual Views 11. Event Set Hierarchy – Results (internal vs. external) 12. Microviewer 13. Charge Capture

72

14. Interfacing with Lab (Sunquest) – aliases, etc. 15. Crosswalk of orders to order sets 16. Key Operational Impacts 17. Workarounds

16.6.5 Medication Management Meeting schedule: Friday, Oct. 10, 9:00am-10:00am Meeting Agenda:

1. Policy & Procedure Changes • If available, share NYGH’s modified policies and procedures.

2. Integrated Medication Process (Med order entry, pharmacy verification, medication dispensing from pharmacy (ADC), Barcode Medication Administration, documentation)

3. Cerner TPN functionality- We have not been able to identify a site that uses it. 4. Immunizations and vaccinations -the use of the immunization schedule 5. Narcotics printing 6. Advanced Dispense Routing (for first dose, fill batches, PRNs)

• We want to know that if an item is in a cabinet and is ordered regularly (ie. acetaminophen 325 mg TAB is in the Omnicell/Pyxis cabinet with an order of acetaminophen 650 mg PO QID) would we be able to include it in a regular fill batch cycle.

7. Pharmacy Multi-Patient Task List / Clinical Pharmacy tools 8. Inventory Management / Charges-Crediting 9. Weight-based dosing

16.6.6 Pharmacy Supply Chain Meeting schedule: Friday, Oct. 10, 9:00am-10:00am Meeting Agenda:

10. Medication Barcoding 11. Key Operational Impacts 12. Workarounds

16.6.7 Emergency Department Meeting schedule: Thursday, Oct. 9, 11:00am-12:00pm Meeting Agenda:

1. Design Review

73

2. Style guide for tracking board a. Standardized use of icons

3. Key Operational Impacts 4. Workarounds

16.6.8 Health Information Management / Scanning Meeting schedule: Thursday, Oct. 9, 1:00pm-2:00pm Meeting Agenda:

1. Hybrid Chart Policy 2. Scanning Practices

a. Ambulatory versus Acute 3. Key Operational Impacts 4. Workarounds

16.6.9 Medical Imaging Meeting schedule: Monday, Oct. 6, 2:00pm-3:00pm Meeting Agenda:

1. Hybrid nature of inpatient versus outpatient ordering practices a. How is this handled?

2. Alignment of order catalogue with orders and results 3. Room standardization 4. RadNet functionality

a. Where orders originate from (Radiology/Cardiology, Scheduling/Surgery) 5. Charge Capture 6. Style guide for order capture 7. Key Operational Impacts 8. Workarounds

16.6.10 Registration Meeting schedule: Thursday, Oct. 9, 9:00am-11:00am Meeting Agenda:

1. Medical Service

74

a. How to standardize medical service across sites? 2. Key Operational Impacts 3. Workarounds

16.6.11 Scheduling Meeting schedule: Thursday, Oct. 9, 9:00am-11:00am Meeting Agenda:

1. Building and maintenance of schedules 2. Management of Scheduling templates build 3. Strategy around bulk load of historical appointments 4. Standardization of Appointment types

a. Implications for reporting 5. Orders vs. Resource build 6. Data quality (DCW quality review) 7. Key Operational Impacts 8. Workarounds

16.6.12 Surgery Meeting schedule: Thursday, Oct. 9, 8:00am-9:00am Meeting Agenda:

1. Wait list management 2. Workflow for a Surgeon to booking office 3. Data quality (DCW quality review) 4. Preference cards

a. Standards/Style Guide b. Maintenance

5. Key Operational Impacts 6. Workarounds

16.6.13 Core Meeting schedule: Thursday, Oct. 9, 2:00pm-3:00pm Meeting Agenda:

75

2. Access/ Core Security a. How were the access model and Core security matrix developed

3. Location maintenance 4. Providers maintenance 5. Event Set Hierarchy development methodology 6. Key Operational Impacts 7. Workarounds 8. Maternity/Bassinette Build

16.7 Technical Teams General questions/topics to be responded to in text (no meeting scheduled):

o Did you have to upgrade your wireless (wifi) infrastructure prior to go-live? o For site assessment and technical readiness, do you have any processes or checklists that you are willing to share? o What tool or strategy did you use to capture hostnames and printers for WTSLocation?

o Any example documentation would be appreciated. o Do you have any key lessons learned that are related to device selection/ implementation? o During the device selection strategy, were there any devices that did not meet user expectations? o What medication delivery carts are you using? o For closed loop medication administration, which barcode scanners are you using?

o Would you switch models, or do you have any recommendations? o Are you using Imprivata or any other single-sign-on technology? Do you have any recommendations or lessons learned from this? o Do you use 724, if so how far back do you synchronize your data? Do you have any other lessons learned on 724? o What are key technical operational changes that were required with further reliance on Cerner as your EHR?

76

16.8 Clinical Transformation A session with the Clinical Transformation team has been scheduled to discuss the project responsibilities that fall within their domain including the following. Meeting schedule: Wednesday, Oct. 8, 1:00pm-3:00pm

Learning & Staff Education Strategy 1. What was the education strategy?

o How did they approach workflow education? o Can we have access to their course and learning curriculum? o Did they utilize online learning and was classroom education mandatory for all staff? o What recommendations do they have, resources, and shared learning that we can build on?

2. What was the physician education strategy? o How did they promote physician and adoption, particularly with CPOE? o Do they provide CME credits for training? Is competency required to maintain hospital privileges? (Add to questions below about

Physician education strategy) 3. What was the approach for computer literacy and clinical informatics prior to roll out of education? 4. Were there any professional practice issues, and how did they mitigate against these with the roll-out? 5. Cerner Application Use:

o Do they use Cerner LearningLIVE? Is the content helpful / Does it need to be customized? o Are they using Cerner Lights On to monitor adoption and tailor ongoing support for learners? If so, who has access, how are they

using it and what training was provided? 6. Was there much difference between their initial course offering and their ongoing course offering? How has their learning strategy

evolved?

Communications Strategy 1. How did they communicate/raise awareness with frontline staff who don’t read emails or newsletters? 2. How did they communicate with physicians? 3. In hindsight, were there any gaps in communication?

Change Management Strategy 1. Peer networks – did they use them? What was effective? What would they do differently?

77

2. Physician adoption? What was the key to success? What should we be particular 3. Tools that were must have for leaders

Evaluation Strategy 1. How are you evaluating your implementation of Cerner and what have you found so far? 2. If you could do it over, is there anything you'd do differently 3. Can you share your list of indicators? 4. What kinds of expertise did you include in your evaluation team and/or evaluation advisory committee?

Access & Support 1. User Access

o What is the user enrolment process and turnaround time for account provisioning? o What, if any, special exceptions/processes do they have in place for Residents, Fellows and students training and

access? Academic faculty? Researchers? 2. Support

o What is the ratio of operational Cerner “How-To” support staff to end users? Are they specialized or generalists? o Were you able to transition your project training team into an operational team after go-live?

16.9 Implementation A session with the Activation and Operational Readiness leaders has been scheduled to discuss the implementation phase of the project including the following.

Meeting schedule: Wednesday, Oct. 8, 4:00pm-5:00pm 1. Activation/Go-live 2. Project Turn-over to Operational Support 3. Site readiness

CST project: North York General Hospital site visit assessment ...

Documents

Transcript of CST project: North York General Hospital site visit assessment ...