see also:

• Emergency Department information systems (EDIS)
• ACEM submission to NSW eHealth establishment regarding EDIS software 2012 (pdf) - this document is totally independent of the comments below and I was not party to its authorship.

NB. I have referenced my (Gary Ayton's) HASTools third party plugin here only to demonstrate what is possible - you can't buy this from me or anyone else and it is only used within Western Health - but I am happy to consider possibilities to improve ED efficiencies in other networks.

Thus, if I can create this functionality, so should a commercial vendor who has access to much more programming expertise and financial resources than I ever will - if they haven't - you should be asking WHY NOT?

• choosing an EDIS is one of the most important things that can be done for an Emergency Department and its success and indeed the efficiency and effectiveness of an ED is dependent on how well the software and its hardware interfaces fits with your ED environment.

• a critical consideration from the outset is whether you want to go full electronic record or not
  • there are important consequences of a full electronic record - both good and bad - be careful of that which you wish for as you may get it - and when it is too late and the money is spent - you may realise that for YOUR ED such a system is still impractical.
  • a full electronic record may tie all ED staff to computers much more than you would like and worse, it will require each staff member to have ready access to their OWN dedicated computer - being forced to queue to write your medical records, discharge letters, allocate yourself to a patient, check path/Xray results, search for clinical resources to help guide your care - all are time consuming activities on a computer - to add full ED clinical documentation to that load may mean less time for direct patient care and a dramatic increase in the number of computers in the ED with their attendant costs, maintenance issues and space requirement, not to mention potential for theft and damage as they would now need to be in patient care areas.
  • having a paper record of clinical notes in your hands when seeing a patient allows you to jot down important points from your consultation before you forget as well as having the notes as an aide memoir when reviewing patients, particularly those who have been handed over to you. Not having access to this in each patient cubicle may increase clinical risk as important clinical points may be overlooked.
  • of course, the software may allow the full electronic record feature to be disabled so that paper clinical notes are still used.

• as your software is likely to be installed for at least 10yrs, strong consideration should be had for factors such as:
  • computer platform the software was designed on - is this state of art and likely to be kept current for new operating systems - for example, will there be issues running it on MS Windows 7 operating system with its new security features, and can it be ported to other devices such as iPad without having to resort to a clunky Citrix environment, etc.
  • the database system where your valuable data will be stored - is it a standard system such as MS SQL, Oracle, Sybase, etc for which there is a ready availability of IT support within your organisation?
  • the potential longevity of the company and commitment to their EDIS product
  • cost and turn around times for updates and end user requests for new features or modifications, in particular, those mandated each year by State governments for reporting.
  • end user customisation potential - how much can the software be customised by the end user, or at least how responsive is the vendor to modification to manage your rapidly changing business needs?

• although most software has some reporting facilities - often rudimentary, it is critical that in-house users are able to develop reports using their own tools such as:
  • Crystal Reports - although not an easy program for most people to master
  • other reporting tools such as Gary HASTool's reporting engine
  • intranet live data reports so bed managers, etc can be made aware of ED bed requests from anywhere in the hospital, and wards can proactively “pull” patients from ED.
• it is critical that such third party applications have access to the full database - preferably via a live data repository

• there should be an option for either:
  • separate databases for each ED campus
    • BUT this requires the possibility of the software accessing each campus simultaneously to ensure past visit information, unscheduled representations and alerts are available to users of each campus in real time.
    • this is one of the reasons for Gary Ayton's HASTools third party plugin for HASS EDIS as the main software alone does not provide this critical functionality.
  • a single database which combines all ED campuses
    • this makes it easier for the software to display multi-campus information for a patient - but is it adequate?
    • what contingencies will there be in place if the server fails - all ED campuses may lose their IT system at the same time
    • will the increased user demands place too much burden on the server
    • how will reporting be done in a way that it won't further impact the performance of the server

• there are few things more frustrating to staff than a slow software system, the more users on a system, the slower it will get, particularly if a bottleneck situation is reached.
• how slow it gets is dependent on a number of factors including software design, database design, server capabilities, network bandwidth, user computer configuration (is there enough RAM?).

• the more functionality, the more complex the interface can be
• ideally processes should take only a few mouse clicks and access to lookup tables should be rapid and easy
• the user interface should be consistent throughout the software so that users don't have to remember a lot of different ways of doing things.
• does it have dysfunctional features which were not designed with the end-user in mind?

• how well does it work with the hospital's patient registration and admission IT system (PMI), and their pathology/radiology reporting, prescribing, order entry (eg. outpatient requests), staff paging system and perhaps even HR systems?
• it is important that the same information is not required to be manually entered in more than one system.

• see below for a brief listing of critical functionality

• ability to rapidly triage a patient with access to decision support sytems (perhaps intranet-based and linked to complaint codes)
• ability to appropriately allocate patient to a location - hence access to what is happening in the ED (eg. via a department map) as well as assess workload at associated ED campuses to allow redirection if appropriate.
• linking of patient to patient expect details
• linking of patient to specific patient care plans designed for that patient
• display cross-campus alerts relating to that patient (eg. allergies, violent behaviour, etc)
• ability to trigger the injury surveillance data screen if presentation is a injury / poisoning - this feature should be able to be turned off if your ED does not work this way.

• ability to recognise in a timely manner patients needing to be clerked, or admitted
• ability to rapidly allocate a new patient identification number (MRN) or link to an old one
• ability to import prior patient details from the hospital patient IT system

• a visual map of the department showing all cubicles with their allocated patients is an extremely useful tool
• the map should allow it to act as a portal for further computer processing of a patient
• the map should be end-user customisable as the physical locations of your ED and their uses alter.
• it should work on the screen resolutions you will be using now and in the future.

• ability to import all patient personal details if MRN entered
• ability to easily allocate a time for the expected attendance
• ability to rapidly view path/Xray results and cross-campus past visits while the referrer is still on the telephone as you may be able to avert another ED presentation.

• only patients allocated to a certain area or team are displayed - eg. paed vs adult, fast track, short stay observation
• ability to hide records that are pending clerical completion following an IT outage, and who are no longer in the ED but this status has not been updated on the sytem as yet.
• ability to sort on urgency, last name, age, arrival time, location, etc.
• default sort to doctor name then urgency then time of arrival which places those NOT SEEN at the top in order of urgency and time of arrival, so the top patient on the list is NEXT TO BE SEEN. The remaining patients who have been seen are then placed in doctor name order to make it easy for ED doctors to rapidly see who they are attending and respons
• ability to show only those patients seen by YOU (not as critical if the above sort is possible, but may be useful if using a small interface screen).

• triage codes
• whether patient seen or not
• if patient is not seen and approaching or exceeding recommended maximum waiting time for the allocated triage code
• patient alerts are available - this should be cross-campus or organisation-wide alerts preferably.
• if Rx time exceeds 3hr and no bed request has been made
• if Rx time exceeds 8hr and patient still not discharged
• if Rx time exceeds 24hr and patient still not discharged
• unscheduled representations within 48hrs - these patients tend to be higher risk and should probably be seen by senior ED staff
  • for this to work:
    • the triage component must allow for designating whether the presentation is scheduled or not
    • preferably the system should check for presentations at other associated ED campuses as well

• patient alerts - cross-campus or organisation-wide alerts - type of alerts displayed here should be customisable
• senior doctor alert
  • warning that the patient should be discussed with a senior doctor before discharge if high risk such as:
    • baby < 3 months
    • referred by local doctor
    • unscheduled representation
    • triage scale 1 or 2
  • ideally the system should be aware if the allocated doctor is a junior doctor or senior doctor so the alert is only displayed if junior.

• past visits to all ED campuses in the organisation should be immediately displayable as well as discharge letters written (and if full electronic record, then access to full ED clinical notes)

• doctor or nursing staff should be able to go to clinical guidelines related to the triage complaint code as well as those linked to the final diagnosis code

• ability to write electronic discharge letters is critical - these are of enormous timely help in re-presentations
• ability to rapidly access path/Xray/PACS data
• ability to rapidly access patient information sheets linked to the final diagnosis
• ability to rapidly create a patient expect if patient is asked to return for further investigations or Mx
• ability to print sick certificates, carer's certificates, negative breath test forms for road trauma patients.
• ability to fax or email discharge letter to allocated local doctor

• log requests for inpatient consultations (and preferably automatically access the staff paging system)
• rapid bed request process which then alerts the clerical staff to complete
• easy to use short stay observation bed request with selection of care plan and ED consultant for auditing purposes

• clinical handover is one of the high risk activities for patients
• it is imperative that a live summary of important clinical/social/disposition/communication information is documented in an easy to read and access manner
• it is also preferable that:
  • it has a reminder system to ensure:
    • appropriate Mx communications to inpatient units have been made and that they have accepted care
    • usual medications and iv fluids have been ordered
  • there is a system to allow doctors to log outstanding tasks for the given patient and that these are then displayed in an overall task list for all patients whether still in ED or discharged (they would be removed from this list only when marked as task completed)
    • this allows reminders to follow up path/XR results, contact inpatient units or other hospitals, etc.
    • importantly, the task does NOT disappear on discharge, this is very useful for situations when pathology calls the ED doctor to inform of an abnormal culture result, etc and the Ed doctor needs a reliable place to document this and remind whilst awaiting the medical record to be retrieved.
• ability to print out a handover report of all patients in the ED ordered by location with this summary included - particularly useful for the nurse in charge.

• in-built patient management tools such as drug/infusion calculators are very useful although not essential.
• see Gary Ayton's HASTools extensive drug/infusion calculator tools with embedded links to various online resources such as MIMS, therapuetic guidelines, etc.
  • you can right click on a patient and open the tools, and the patient's weight will be estimated based on age (you can over-ride this), and all drugs & infusions are calculated for each of the common clinical scenarios such as resuscitation, seizures, burns, etc.
  • the viewed page can then be printed and taken to the patient's bedside as a reference during resuscitation.
• ability to customise buttons to open user editable URL links to intranet or internet resources

• a critical functionality is the ability to find a patient such as one you have discharged but cannot remember the name or MRN.
• the search tool should thus be able to search according to optional criteria such as:
  • date range
  • MRN
  • last name
  • gender
  • age range
  • triage code
  • triage complaint description (eg. search for all patients with “chest” pain)
  • diagnosis
  • doctor name - the last doctor seeing the patient, although ideally it would be any doctor who attended the patient

• can you print the doctor's notes card automatically as soon as the triage and clerical information has been entered?
• can you print it manually as needed?
• can it be set to be printed by only those computers in a particular “ED team” - so that the record for fast track patients is printed in fast track location and not in the main staff base?
• does it display cross-campus patient alerts and brief summary of the last 5-6 visits to either campus?
• does it display NOK and local doctor names and phone numbers?

• can it print patient BRADMA labels with barcodes for patient identifier AND episode identifier to allow document scanning
• this is useful as doctors generally do not use the hospital patient system and if they need more labels, the EDIS is more familiar to them.

• frequently managers are asked to review incidents and the ability to visualise the list of patients in the ED with their triage priorities, time seen, diagnoses, etc at a given time stamp is very useful.

• ability for individual staff members to create their own logs of:
  • patients they wish to follow up
  • procedures they have performed for their own CME record
• this log book system should be easy to use and integrated into the software interface and the data able to be exported to MS Excel so staff can forward information (with privacy measures in place) to professional bodies for their training certification.

• how does the system allow you to rapidly access these results - do you have to re-enter more passwords to get there and even worse, retype in the MRN number, or is access seamless
• does the system push path/radiology results to you and thus let you become aware they are now available
• is it integrated with PACS radiology image viewing
• can you log that a result has been accepted and acted upon
• will it provide a tool to push results of discharged patients for users to log that they have accepted the result and acted upon it
• in a busy ED, these auditing functionalities are vitally important to be functional and easy to use.
• at Western Health, we have been using the Alcidion Second Screen tool as a standalone software and touchscreen user interface which has made life much more efficient for us but unfortunately still does not have an adequately accountable and efficient abnormal result checking audit tool.

• the software should be ideally be responsible for all government reporting requirements and measures in the contract should ensure that such compliance is maintained.
• it is critical that there is access for third party reporting tools such as Crystal Reports and intranet live data reports.
• I would STRONGLY advise AGAINST purchase of any software that does not allow third party reporting access to YOUR data.
• for instance, Gary Ayton's “HASTools” reporting engine allows:
  • extremely efficient reporting management and development
  • visualisation of EDIS lookup table data to further aid report development
  • easy creation of new reports via copy and pasting existing SQL statements
  • ability to use the one report in a number of ways via its interface which allows:
    • selection of the date range - with automatic limitation of date range to avoid excessive reports crashing the system
    • ability to group data into various time periods such as hour of day, 8hr shifts, day of week, date, year & month for trending.
    • ability to separate into adults vs paeds vs all patients
  • ability to drill down on report results to show actual patients within a row of a report output:
    • eg. if choose a report that gives numbers of patients according to triage category, you can just right-click and choose get patients and you will be able to see all patients in a given triage category.
    • furthermore, you can drill down on a given patient and see past visit information which will help detect ED system errors, etc.
  • ability to filter the report output further
    • eg. if a report by triage code and by hour of day, you could choose to show only those with triage 2
  • ability to export the results to MS Excel for further data manipulation or charting.

• there is often a tendency for clients to request features for their EDIS product and for the right money, the vendor may well be willing to develop them - but sometimes these features are probably best NOT developed in the EDIS.
• hospital-wide electronic solutions require hospital-wide electronic solutions NOT EDIS solutions
• such hospital-wide electronic solutions include:
  • patient administration system - admission/discharge, patient master index (although the EDIS will probably need its own PMI tables which will need to be synchronised with the hospital-wide PMI)
  • pathology/radiology reporting and digital radiology PACS image systems
  • patient electronic document storage system (eg. ECG's, clinical notes that have been scanned, photographs, etc)
  • electronic order entry - booking outpatient appointments, ordering path/radiology investigations
  • clinical decision support systems - the wards need these too!
  • electronic prescribing
• NOW HERE'S THE PROBLEM:
  • while the EDIS should not be creating such systems, it should be able to seamlessly integrate with them to ensure easy efficient use
  • thus if you are upgrading your hospital-wide systems, it may be wise to do that BEFORE purchasing an EDIS system
  • as time goes on, more and more hospital-wide solutions will need to be integrated with an EDIS
    • will your vendor be able to achieve this in a timely and cost-effective manner?
    • if not, will the contract allow a third party to create an interface?