April 4, 2019

Who, What, Where? A free template to help you create a master support list for your HIS system

Given the level of complexity found in today’s Healthcare Information Systems (HIS), the increased number of peripheral system integration points and the increased responsibility of in-house resources, it is difficult to know who is responsible for any given issue, especially if the issue doesn’t happen often.

For most provider organizations, there are Information Technology (IT) staff members who share roles and responsibilities across the entire system operation. Knowing where one’s responsibility ends and another team member’s responsibility begins can be difficult to determine if a clear and detailed support tree has not been established or published. You may be reading this and thinking, why wouldn’t they already know who is responsible for what? They interact with peers and team members every day, wouldn’t they already know who does what?

Creating a Support Tree Diagram and HIS Documentation

Having a detailed list of systems and their appropriate support person is an excellent tool for expediting solutions and understanding who your contact is for resolving any issues that may arise. Below are recommendations to include in your support tree document/diagram, as well as key variables for your organization.

Systems Support Information Criteria “Must Haves”

• Primary System: List name, mnemonic, or abbreviation of your primary system(s). Example: Epic, MEDITECH.
• Application/Module/Sub-System: List name, mnemonic, or abbreviation of the sub-system. A sub-system is part of a primary system. Example: REG, MM, ORM, which are modules of MEDITECH’s Client Server EMR. (REG = registration, MM = Materials Management, ORM = Operating Room Management).
• Purpose: Define what is the purpose of this application/module and describe its key functions.
• Application/Module Category: Is it “remote hosted” = web site (URL), “server based” (local servers), “workstation based” (isolated to individual computers)?
• Department Owner: Which department does this application belong to? Who uses it the most?
• Department Consultant: Who, within the organization, owns the application? Who is the main support person, SME, other vendor customer support person or team?
• Data Owner: Who owns the data within the module? This may differ from the owner. Example: A clearinghouse vendor may be the department consultant for the product but Patient Financial Services owns the data.
• Data Stored: Where are the data sets stored? In the Cloud? Local server? Desktop (C:\)? Applications/modules may live in the cloud, but is the data stored and shared locally?
• Personal Health Information (PHI): Does the application/module contain PHI? Most healthcare technologies will include PHI, and it is critically important that staff always understand the compliance component of technologies and the need to protect PHI diligently.
• Confidentiality Level: What is the level of confidentiality (i.e. classified, sensitive, internal, public)?
• Criticality Level: Understanding the criticality of a system is vital. To determine the importance of the application, ask yourself: “what happens when/if the system goes down?” Does downtime affect patient flow, care delivery, data integration between your EMR and peripheral systems or billing? Care delivery and patient safety should be rated the highest. Any application that can slow or stop patient flow and/or care delivery at a production level are always consider “critical” applications and must be prioritized above ancillary systems.
• Recovery Document: Is there a recovery document on file in case the application/module goes down? Is the data backed up? Does it need to be backed up? Who is responsible for backups? In worst case scenarios, providers should have a plan for collecting data during downtimes (such as hard-copy registration forms, charge requisitions, and case notes that can be keyed into the EMR once it’s backed up and running).

• Vendor Information
  • Company Name: What is the name of the company?
  • Company Address: What is the company’s address?
  • Web Site: What is the company’s website?
  • Company Support Number: What is the phone number to call for application/module support?
  • Contact Name & Number: Who would be the direct contact at the company and the associated phone number?
  • Contract Info: What information from the contract is needed for support?
  • Business Associate Agreement (BAA): is there a BAA on file?
  • Scope of Work (SOW): The SOW is key to delivering on promises and measuring performance. Whenever possible, SOWs should be available to support staff. If questions arise related to scope, expectations, and level of support limits, the SOW should clearly define the expectations of both provider support teams and vendor.
  • Vendor Access: If the vendor must access the system, how do they access the system (web-based, VPN, etc.)?
• Support Details
  • Server/Hardware Support: Who is the contact for server/hardware support?
  • Application Support: Who, within the organization, would be contacted for application support? Each application should be indexed with clear support assignments.
  • Server(s) & IP Address(es): What is/are the name(s) of the server(s) and/or IP address(es) for the specified application?
  • Installation & Troubleshooting: Who is responsible for installing and troubleshooting installation issues?
  • SFTP Configuration: What is the SFTP configuration? Login and password information related to sftp should be available to all applicable staff members. Never allow a single user to control login and password info related to critical support systems and sftp protocols.
  • Accounts: What accounts are setup within the application? Account examples can be used to clearly describe the roll of such products and systems.
  • Backup Required: Is backup required for the application?
  • Backup Retention: How long does backup information need to be maintained?
  • Nightly operation, Midnight Run, or Off-Hours Automation: A detailed schedule of all off-hour processes should be listed. If there are specific times associated to processes, create and make available to support staff a typical nightly process—noting any area with greater likelihood of issues.
  • Comments: Any additional comments that would be helpful.
• File Transfers
  • Files Inbound: If there are inbound files, what is the workflow from the outside vendor to the destination within the organization? What elements are included in the file? Describe the primary purpose of the vendor file and integration to your EMR.
  • Files Outbound: If there are outbound files, what is the workflow from within the organization to the outside vendor? What elements are included in the file? Describe the primary purpose of the file and how it integrates to your EMR.
  • Files Internal: What is the workflow of files that need to be moved internally? Where do they live?

The Importance of Documenting Your HIS System

The reality is not every person or team of will know the right contact or support person responsible for handling an issue that may occur. Knowing specifically who the primary support person is for any given production level issue will accelerate the solution and allow other contingent processes to resume.

For those organizations who do have IT staff that are responsible for and know the minutia of every technical operation within their organization, there is a risk associated with that person leaving the organization or when they call in sick. Someone should be able to pick up the ball and work to resolve the issue.

The collection of data for this type of documentation should be a collaborative effort between your IT staff, as well as individual department staff, and the information obtained should cover all necessary data needed for any type of issue that may arise.

The suggested place to store this information would be on an organizational intranet site, so any and all individuals who need to refer to the information will have access. This will also prevent any individuals outside of the organization from obtaining this information.

RevSpring is Here to Help

Too busy or don’t have the resources to evaluate and document your HIS systems? Contact learnmore@revspringinc.com to get in touch with RevSpring’s consulting team who specialize in analyzing, documenting, and maximizing HIS systems within healthcare organizations.