Section 4 Implement System Build - 1

Section 4.8 Implement System Build

Understand the tasks performed during system build for electronic health record (EHR) systems and plan appropriate time and resources to accomplish your responsibilities.

Time needed: 80 – 200 hours Suggested prior tools: Section 1.7 EHR Technology Readiness Inventory, Section 1.8 HIE Technology Readiness Inventory, Section 2.8 Workflow and Process Redesign for EHR and HIE, Section 4.6 Policy Procedure Checklist, Section 4.9 Change Control

How to Use Review the information in this tool before beginning implementation of your EHR or other health information technology (HIT).

System Build System build is a term used to describe the process of configuring an application so it works with your data needs, state-specific requirements, etc. System build for an EHR is like setting your personal preferences in new software applications on your own computer, such as the size and type of font, adding and deleting toolbar elements, and setting up templates for letterhead, memos, etc. These are detailed tasks. Magnify that several times, and you have a sense of what’s involved with system build for EHR. For EHRs, the amount of configuration that is possible depends upon the product. For most skilled nursing facility systems, extensive configuration is not feasible. However, all systems will need some “building” of the data tables that represent your organizational configuration (e.g., staff lists, physician contact information). Although system build is largely performed by the application vendor, it requires agency resources to compile data and approve screens, templates, alerts, reports generated, etc. An overview of the tasks generally included in system build for EHR is provided below. The responsibilities of the client and the vendor will vary by vendor and product.

Overview of System Vendor Responsibility Client Responsibility Build Gather existing or Reviews work flows, processes, Works with vendor to adopt new improved work flows and policies, and procedures with client to workflows and processes or request process maps, policies, determine how the new HIT will impact assistance in customizing the product to and procedures - ideally – your improved work flows meet alternative workflows and and processes, policies, and processes procedures Interface scoping and Requests client assistance in Needs a thorough understanding of design determining what data must be existing systems and data needs of new interfaced from one system to another, systems and in developing the interface

Section 4 Implement—System Build - 1 Overview of System Vendor Responsibility Client Responsibility Build specifications. For example, what patient demographic data elements stored today in perhaps a billing system need to be transmitted to EHR. Data conversion scoping Requests client assistance in Needs a thorough understanding of determining what data from an old data needs and reporting requirements system needs to be converted to a new system. Vendors will often have recommendations. Master file and table Every function of an application has Needs to supply the vendor with the build master files and tables to be pre- values of specific variables to be populated with the client’s unique included in the application. Vendors values for the variables in the tables. typically give the client worksheets or Some vendors obtain this data from other tools on which to record this the client and enter the data for the information. Frequently the source of client. Other vendors supply the client the information for this purpose is with a wizard and expect the client to various forms, procedures, or other enter the data using that tool. documentation. For example, names, credentials, National Provider Identifier (NPI) Drug Enforcement Administration (DEA) number, and contact information for all physicians who provide oversight for patient should be included This currently may be stored on a set of paper forms, or in a word processing system or a credentialing database. If stored electronically today, converting the list to the new application may be possible, although sometimes entering the data directly into the new system is easier and more accurate. Note: over time, some of the data supplied to build the master files and tables will change, so the client will very likely be responsible for making these changes later. Output design The product may have a set of canned Needs to supply vendor with all reports reports it automatically generates. desired to be produced by the new Some vendors may charge for any application, including any printouts of modifications or additional reports. documentation. Some vendors expect Other vendors may provide an the system to be maintained in opportunity to make modifications to electronic form only. If you are not ready the canned reports and to add a limited to go paperless, or will need to print out number of additional, special reports a representation of the chart (e.g., in during implementation. Vendors who response to a subpoena), you will need support modifications and additions to assure that you can generate print during implementation may ask the outs as the legal health record. Note, client to supply sample reports that if not developed at the time of currently generated or for system build, any new report desired in specifications of new reports needed. the future will need to be developed The vendor generates reports from either by the client using a report writer these. tool, or by the vendor for additional fees. Clients should check their contracts to

Section 4 Implement—System Build - 2 Overview of System Vendor Responsibility Client Responsibility Build determine the nature of report development included in the standard implementation of the application, recognizing that every new report cannot be anticipated at the time the product is acquired. Screen build The extent of changes able to be made Needs to review screen designs and to screens varies by vendor and offer modifications based on known product. Most systems require at least preferences, if they are able to be View build some work to design placement of accommodated by the vendor. This is various data entry capabilities and an opportunity for the client to ensure presentation of information. An usability, but also puts the client as important element of screen build is to some risk for increasing cost if many assure the ability to enter data needed changes are desired and they were not to generate (a) the data you must included in the original contract. document, (b) the data you need to generate the various reports, and (c) the data you need for clinical decision Many EHRs are now enabling users to support. create their own dashboard views and in some cases design other screens to meet their personal preferences. You The process of view build is very may want to determine the extent users similar to screen build, but enables a are allowed to set these preferences screen to be presented with more than and the ease with which such one view, if that functionality exists in preferences can be made and weigh the product and desired by your these against the value to decide how organization. much leeway to offer your users. Dictionary build All vendors start with a data dictionary Needs to understand the nature of the that is a list of all of the variables the data dictionary and the impact it has on system uses to collect data values. overall system maintenance. The extent Some parts of the data dictionary draw to which the client is involved in from external code sets. Other parts of maintaining the data dictionary is the dictionary will be proprietary codes. entirely driven by the vendor. At the Some vendors permit the client to point of implementation, the vendor will maintain the data dictionary, updating, need the client to review the screens adding to it, and deleting from it. Most and outputs so it may assure that the home health vendors maintain it data elements the client needs to themselves. This is not so much a document and generate reports and matter of vendor preference, but cost clinical decision support are present. to vendor. A flexible product is going to be much more costly for the vendor to write updates for – and, of course, that cost is passed on to the client. Edits build Edits are checks built into the system Needs to understand the edits that exist to help ensure data entry and data and be able to respond to the vendor’s transmission accuracy. For example, request for their review, modification, an edit may be that the birth date is not additions, and deletions as may be a date later than today’s date. Some feasible given the nature of the product. edits check on dates, some check on pre-specified ranges (e.g., temperature cannot be recorded lower than a certain number or higher than another number), and some compare data

Section 4 Implement—System Build - 3 Overview of System Vendor Responsibility Client Responsibility Build entered against a table (e.g., employee #12345 does not exist as a valid employee in the system). Many edits are those the client would consider accepting without question. Some edits may need to be adjusted for special situations and, if the vendor’s product has extensive editing the vendor may ask the client to review various edits for inclusion. Alerts build Similar to edits build, alerts are the Reviews all alerts, especially those for rules that generate various reminders, CDS. If the system provides very robust prompts, and clinical decision support CDS, it may only be feasible to review (CDS). As with all other elements of all classes of rules. For example, if system build, the extensiveness of the there is drug-drug contraindication alert alerts and their ability to be modified capability built into a medication varies by vendor and product. management application, no one However, if any alerts exist in the expects to review every possible drug- product, the vendor should ask the drug combination. However, developing client for review. Clinicians must use cases that include scripts, or understand the source of the alerts scenarios, can help review an important (i.e., to generate trust in them) and to sample of the alerts. Note: the review of have some ability to modify them–or to the alerts should occur prior to their evaluate the need to turn an alert off or testing. The review ensures that the on. (While alerts are very important, client knows what they are and has the some products go overboard with such opportunity to modify, change, add, or alerts. Too many alerts of any kind is delete rules, where testing is a step referred to as “alert fatigue,” and often after that to make sure they work results in clinicians ignoring all alerts.) properly. Template build Template build is similar to screen Reviews all templates and provides build and view build, but takes the input, although being aware that functionality one step further in modifying dynamic templates is much sophistication. A screen is generally more of an intricate programming static. A view may alter the screen’s process than modifying a static screen. appearance and general content During system build is an ideal time for specific to a user, but templates are the client to understand the extent to dynamic. Templates will change based which the product enables on the data being entered. In other customization of templates and how words, templates are context sensitive. they can be kept current. A simple example is a template for recording an assessment. Once the template has had sex of patient recorded, it will only present questions suitable for the sex of that person. Sophistication of templates varies greatly by vendor and product. Copyright © 2014, Margret\A Consulting, LLC. Used with permission of author.

Section 4 Implement—System Build - 5