ED systems need to have a good balance of security, accountability, accessibility and usability while allowing version control or similar to ensure a state of the data at any given time can be recreated for medico-legal purposes.
security via switching systems as per Citrix-model for changing user logon is NOT recommended in a busy ED environment, particularly when clinical handovers on a multitude of patients are taking place for which different users will alternate in accepting patient care responsibility and documentation.
patient identifier
this data is typically stored in a patient master index file (PMI) within the EDIS database
in general, staff would need to first search the hospital's main patient master index to determine if a patient already exists and their identifier, and if not, create a new identifier.
patient persistent data
this refers to perpetual data that is independent of episodes of care, although, often will need to be updated and made current at each new episode of care
includes:
social history
demographic data
next of kin data
care provider data
lifestyle eg. ivdu
family history
problem list
pregnancy status
current medications
alerts such as medication allergies
patient episode of care
each patient episode of care is assigned an episode identifier so that all events relating to that episode can be linked appropriately.
when considering EHR the type of episode becomes important (eg. ED presentation, hospital admission, outpatient appointment)
ideally an EHR could display episodes by type or date range
potential for confusion, particularly with scanned medical record systems, is the creation of campus-specific ED episodes of care derived from the individual campus EDIS database episode identifier which in itself may not be unique across campus databases.
it is common practice that persistent data such as demographics, NOK, LMO, etc are also stored as a link to the episode to provide an historical record of changes, and to ensure that data relating to an episode remains contemporaneous with that episode.
injury surveillance data is recorded linked to the episode when appropriate
patient events
each event is linked to both the patient identifier and the episode identifier
examples of events:
care episode
pathology or radiology investigation
clinical procedure
consultations
staff contact history
location history
vital observation
clinical status
episode-specific alerts
episode careplan
episode streaming of care and patient flow status (eg. timestamping bed requests, etc)
medications prescribed during episode and upon discharge
clinical documentation records
episode discharge
data correction audit trail - record of reason for correction if critical data
critical inter-relationships with external systems
integrated access to alerts
with ability to read and write to an enterprise patient alert system
having the main alert system in a clerical tool such as iPM which clinicians rarely access is NOT conducive to reliable documentation
rapid access to pathology, radiology and other investigational database systems
preferably an EDIS can display when such data is now available rather than rely on end users continually having to search to find if it is available.
this suggests the need for a data repository of such data so that third party systems throughout the enterprise can make effective use of this.
furthermore, critically, there needs to be an enterprise-wide interface so that all such systems can update a centralised result checking documentation and audit tool.
rapid access to scanned medical record system if in use
integrated enterprise-wide clinical documentation and electronic prescribing
there is little value in an EDIS allowing “paperless” clinical documentation if the electronic version is not available hospital-wide when admitted, and thus forces end users to print a multitude of pages of paper to ensure ward staff have access to it.
a smarter technology would integrate the EDIS clinical record within a hospital-wide clinical record, but only if it still remains efficient and effective.
access to inpatient clinical roster and staff paging system with ability to automatic send a page or SMS text and record and timestamp that it has been sent as a consultation request
access to clinical guidelines relevant to the patient's presenting condition
access to clinical decision support systems
accessibility and usability
the more clinical functions that are made electronic, the greater the need for electronic access
most ED's have very limited physical space for desktop PC's, while patient-centric wall-mounted PC's or computers on wheels (COWs)lack ergonomics and privacy, and current tablet PC's are just too big and heavy for staff to carry all shift.
it would seem that WiFi tablets such as the Apple iPad may be increasingly required to make the increased reliance on e-health workable in ED's.
unfortunately, current Windows based software does not work natively on an iPad, and requires a remote desktop service such as Citrix to even get it working - but Windows apps running in Citrix on an iPad are currently clunky, do not allow modern vector graphics powered applications to function, and do not make the best use of the iPad's features.
new software will need to natively target the iPad and similar devices to ensure ease of use, efficient and effective bedside documentation.
the alternative, approach to create in CSS and HTML5 may not be effective for speed of use and complexity of ED software requirements.