In the life of an EHII or EHR system, there are a number of key considerations which determine the required functions of the system as well as various aspects of its construction and incorporation of standards. These essentially define the requirements for the procurement process, and have been set out in chronological order below.
Installation: When the system is installed, two databases must be prepared. One is the patient master index: it is essential that the patient/user register can be quickly and efficiently pre-populated with the biodata (names, address, date of birth, ID number etc) of those individuals having records in that institution. The second is the medical records database: it is important that records of care held on legacy systems (or on paper) are migrated into the new system to enable care providers to function. This migration issue arises again, of course, at the end of the life of a system, when the data must be exported to a newer system.
The issues of data formats and structures are discussed below, but at this point the importance of a standardised data import/export facility is self-evident.
Access Control: All those coming into any sort of contact with the system (patients, clinicians, administrators, analysts, technicians etc) must be robustly identifiable. Unless robust identification is incorporated it is impossible to comply with the legal requirements in respect of patient confidentiality and data security. Patient-identifiable data must be secured behind an access control system which lists for each record those identities which have been authorised by the patient to access their data: others may access only de-identified records. The vital issue is that the system must incorporate this level of granularity in its access control infrastructure, as well as logging who accesses which files and for what purposes. Exactly how individuals can identify themselves robustly both locally as well as at a distance, remains a matter of some debate, but the use of identification tokens such as smart or chip cards seems the obvious choice.
Information technology staff create a special challenge and threat to ensuring the security of personal health records. Various issues of system security and information privacy are discussed in a blog soon to follow.
Operation: Different systems will operate and be configured differently – that should be the essence of their appeal to different institutions. However the precise computing platform that is adopted should be of little functional consequence. What matters in terms of the system is the extent to which it relies in critical areas on proprietary technology where the copyright is held by the developer. For example if a new data input protocol is required, or an alternate message output, or an updated data classification and coding system to be incorporated, or a different analysis and reporting format, these must be configurable at a reasonable cost or even in some cases configured by the end-users themselves directly. What is unacceptable is that such minor configurations and adaptations should incur high cost intervention by the developers because of its protection by the proprietary nature of the technology. Such proprietary restrictions should be identified and minimised through contract negotiations.
Communication: One of the key benefits arising out of an electronic information infrastructure is the ease with which information can be accessed and shared both for clinical care as well as for administration, analysis and research. Vital to this functionality is that the data to be communicated is semantically consistent between sender and recipient in other words that the same data elements are present, using the same (or a compatible and cross-mapped) classification system, and where the data definitions are shared in common: these issues are outlined in a blog soon to follow.
Some data will be passed (eg to research collections and data warehouses) in bespoke formats that have been agreed between the parties. However for most peer-to-peer communication (eg primary to secondary care clinician, clinician to laboratory or pharmacy etc) a messaging environment such as HL7 will be adopted: HL7 has invested considerable effort in defining standard messages for data exchange. Having an HL7 compliant interface built-in would be useful, but, where it is not actually incorporated, having a data import/export interface whose specification is open and/or in the public domain, will permit data interchange between systems with little difficulty and without proprietary costs.
Enhancement: At various stages there will be a need to make significant enhancements to the system during its service life, for example removing entire modules and sub-systems, and replacing them, or adding significant new or altered functionality. The replacement system(s) may not necessarily be sourced from the same vendor, at which point the need for adoption of standard interfaces between systems within the system infrastructure becomes evident. If a system that is being considered for acquisition does not comply with interface standards, it may be sufficient for the nature and technical specification of the interfaces which have been adopted between modules to be declared and any proprietary elements negotiated away: in this way any new modules can be configured by their developers to interface with the legacy system without having to pay exorbitant interface configuration fees to the legacy system vendor.
Decommissioning: The issues identified under the heading of installation arise again when a system is to be decommissioned and replaced. There must be a ready method for exporting patient indices and records in bulk and in a format that can accepted by a new system (possibly after minor editing or adjustment).
To summarise, the core issues are:
- The presence of a fully configurable data import/export facility
- Incorporation of access control functionality which is granular to the extent of defining who may have access to each personal data file, including logging for audit
- Configurability such that local IT staff can upgrade and reconfigure lists, tables, coding systems, protocols, outputs, analyses etc
- Compliance with semantic standards (discussed elsewhere) and data messaging standards (eg HL7)
- Internal interfaces that are declared to enable exchanges of modules
- Identification of where proprietary issues arise, and negotiation about these intellectual property rights prior to purchase to ensure that they do not add unreasonable costs.
Course:
Diploma in Health Informatics (DipHI) students at www.health-informatics.co will cover ‘ehealth information infrastructure’ topics in HI203-11 “Systems Acquisition – Specification, Selection and Contracting” and HI203-12 “Systems Implementation and User Support”. Certificate in Health Informatics (CHI) students will have it introduced in HI201-04 “Procurement and Implementation of Information Systems”.