Section 4 Implement System Build - 1

Section4.8 Implement

Section 4 Implement—System Build - 1

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 Build / Vendor Responsibility / Client Responsibility
Gather existing or improved work flows and process maps, policies, and procedures / Reviews work flows, processes, policies, and procedures with client to determine how the new HIT will impact - ideally – your improved work flows and processes, policies, and procedures / Works with vendor to adopt new workflows and processes or request assistance in customizing the product to meet alternative workflows and processes
Interface scoping and design / Requests client assistance in determining what data must be interfaced from one system to another, and in developing the interface specifications. For example, what patient demographic data elements stored today in perhaps a billing system need to be transmitted to EHR. / Needs a thorough understanding of existing systems and data needs of new systems
Data conversion scoping / Requests client assistance in determining what data from an old system needs to be converted to a new system. Vendors will often have recommendations. / Needs a thorough understanding of data needs and reporting requirements
Master file and table build / Every function of an application has master files and tables to be pre-populated with the client’s unique values for the variables in the tables. Some vendors obtain this data from the client and enter the data for the client. Other vendors supply the client with a wizard and expect the client to enter the data using that tool. / Needs to supply the vendor with the values of specific variables to be included in the application. Vendors typically give the client worksheets or other tools on which to record this information. Frequently the source of the information for this purpose is various forms, procedures, or other 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 reports it automatically generates. Some vendors may charge for any modifications or additional reports. Other vendors may provide an opportunity to make modifications to the canned reports and to add a limited number of additional, special reports during implementation. Vendors who support modifications and additions during implementation may ask the client to supply sample reports currently generated or for specifications of new reports needed. The vendor generates reports from these. / Needs to supply vendor with all reports desired to be produced by the new application, including any printouts of documentation. Some vendors expect the system to be maintained in electronic form only. If you are not ready to go paperless, or will need to print out a representation of the chart (e.g., in response to a subpoena), you will need to assure that you can generate print outs as the legal health record. Note, that if not developed at the time of system build, any new report desired in the future will need to be developed either by the client using a report writer tool, or by the vendor for additional fees. Clients should check their contracts to 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
View build / The extent of changes able to be made to screens varies by vendor and product. Most systems require at least some work to design placement of various data entry capabilities and presentation of information. An important element of screen build is to assure the ability to enter data needed to generate (a) the data you must document, (b) the data you need to generate the various reports, and (c) the data you need for clinical decision support.
The process of view build is very similar to screen build, but enables a screen to be presented with more than one view, if that functionality exists in the product and desired by your organization. / Needs to review screen designs and offer modifications based on known preferences, if they are able to be accommodated by the vendor. This is an opportunity for the client to ensure usability, but also puts the client as some risk for increasing cost if many changes are desired and they were not included in the original contract.
Many EHRs are now enabling users to create their own dashboard views and in some cases design other screens to meet their personal preferences. You may want to determine the extent users are allowed to set these preferences and the ease with which such preferences can be made and weigh these against the value to decide how much leeway to offer your users.
Dictionary build / All vendors start with a data dictionary that is a list of all of the variables the system uses to collect data values. Some parts of the data dictionary draw from external code sets. Other parts of the dictionary will be proprietary codes. Some vendors permit the client to maintain the data dictionary, updating, adding to it, and deleting from it. Most home health vendors maintain it themselves. This is not so much a matter of vendor preference, but cost 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. / Needs to understand the nature of the data dictionary and the impact it has on overall system maintenance. The extent to which the client is involved in maintaining the data dictionary is entirely driven by the vendor. At the point of implementation, the vendor will need the client to review the screens and outputs so it may assure that the data elements the client needs to document and generate reports and clinical decision support are present.
Edits build / Edits are checks built into the system to help ensure data entry and data transmission accuracy. For example, an edit may be that the birth date is not a date later than today’s date. Some 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 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. / Needs to understand the edits that exist and be able to respond to the vendor’s request for their review, modification, additions, and deletions as may be feasible given the nature of the product.
Alerts build / Similar to edits build, alerts are the rules that generate various reminders, prompts, and clinical decision support (CDS). As with all other elements of system build, the extensiveness of the alerts and their ability to be modified varies by vendor and product. However, if any alerts exist in the product, the vendor should ask the client for review. Clinicians must understand the source of the alerts (i.e., to generate trust in them) and to have some ability to modify them–or to evaluate the need to turn an alert off or on. (While alerts are very important, some products go overboard with such alerts. Too many alerts of any kind is referred to as “alert fatigue,” and often results in clinicians ignoring all alerts.) / Reviews all alerts, especially those for CDS. If the system provides very robust CDS, it may only be feasible to review all classes of rules. For example, if there is drug-drug contraindication alert capability built into a medication management application, no one expects to review every possible drug-drug combination. However, developing use cases that include scripts, or scenarios, can help review an important sample of the alerts. Note: the review of the alerts should occur prior to their testing. The review ensures that the client knows what they are and has the opportunity to modify, change, add, or delete rules, where testing is a step after that to make sure they work properly.
Template build / Template build is similar to screen build and view build, but takes the functionality one step further in sophistication. A screen is generally static. A view may alter the screen’s appearance and general content specific to a user, but templates are dynamic. Templates will change based on the data being entered. In other words, templates are context sensitive. 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. / Reviews all templates and provides input, although being aware that modifying dynamic templates is much more of an intricate programming process than modifying a static screen. During system build is an ideal time for the client to understand the extent to which the product enables customization of templates and how they can be kept current.

Section 4 Implement—System Build - 1