architecture and database relationships considerations for the EHR for Emergency Departments

fundamentals of an EDIS

  • 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.
it/edis_architecture.txt · Last modified: 2011/08/26 12:22 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki