Standard

IEEE WHITE PAPER

Publisert

Merknad: Denne standarden har en ny utgave: IEEE WHITE PAPER

For bestilling og priser av dette produktet ta kontakt med salg@standard.no

Omfang

PURPOSE AND HISTORY OF AUDITING EPHI EHR users worldwide agree that an individual’s ePHI must remain trustworthy and secure. For decades, audit trails have been recognized as a standard of care in electronic information systems to help ensure the authenticity of records and detect both authorized and unauthorized modifications, as well as all accesses. In the healthcare sector, audit data serves multiple purposes. First, they help protect patients from misconduct. For example, ongoing auditing is crucial to maintain security, given the rise in security breaches with severe financial and personal consequences. Next, audit data is needed to conduct root cause analyses following an event that results in a patient’s death, serious injury, or even a near miss [22]. In extreme cases, healthcare providers can face criminal prosecution for medical errors that cause harm to patients [25]. For example, in one Tennessee case, a nurse was found guilty of criminal gross neglect and negligent homicide after a medication error [14]. In another recent case, a provider was criminally indicted after she documented well checks on a patient overnight. After the patient was found to have committed suicide the next morning, surveillance evidence revealed the provider did not actually conduct the well checks. Yet, when a root cause analysis is conducted, it has often revealed that systemic issues, including failures of the institutions to properly staff and implement EHR systems, are at least partly responsible [14]. Furthermore, patients, their representatives, and subsequent providers need access to accurate data to ensure continuity of care. And finally, billing and third-party payers need access to data to verify the services provided, including their timing and duration, to detect fraud, waste, or abuse, and to reconcile documentation and charges. Previously, the records custodian would traditionally monitor the physical medical records of patients within a facility. Today, the EHR serves as the central repository of patient data, receiving input from various systems, including diagnostic tools, documentation software, and wearable device interfaces. These systems transmit information through controlled interfaces. Multiple authorized users can access and update the record simultaneously within the EHR’s framework. This distributed and dynamic environment exceeds individual capacity for manual oversight, making audit trails crucial for digital custodians, ensuring accountability, integrity, and traceability across complex systems. Currently, audit data is represented as audit trails and standardized in the 2018 publication ASTM E2147 [10]. Maintaining a secure and trustworthy EHR has been an ongoing process. The standard, last updated by an ASTM Working Group in 2018, defines audit data and its presentation within an audit trail. Subsequently, ASTM E2147-18 [10] was published and then incorporated into federal law (45 CFR 170.210 [7], 45 CFR 170.299 [8]). In 2018, the ASTM Working group intended for audit trails to contain the following ten minimum data elements: • Date and time of access event: The exact date and time of the access event and the exit event. • Date and time of activity: The time to which the data entered refers, if not contemporaneous with the user’s data entry. • Duration of access: The start and stop times at which each specific data point was accessed. • Access device: Terminal, workstation, mobile device, remote terminal, or other device from which the user obtained access. • Location of access or activity or both: For a fixed non-mobile access device, the specific computer terminal, hardware, or location wherein the patient record is accessed, or actions are performed on the patient’s record, or both. • Patient identification: Unique identification of the patient to distinguish the patient and his/her health information from all others. • User identification: Unique identification of the user of the health information system. • Type of action (for example, creations, additions, deletions, changes, queries, accesses, copy, print, and copy and paste): Specifies inquiry, any changes made (with a pointer to original data state), and a delete specification (with a pointer to deleted information). • Identification of the patient data that is accessed: Granularity shall be specific enough to determine clearly the specific category of health information data content that has been accessed or acted upon. The specific tab or menu category of data content, such as demographics, pharmacy data, test results, and transcribed notes, shall be identified. • Source of access: The identification of the application through which the access occurred. Ultimately, the U.S. Office of the National Coordinator reduced the minimum data elements required to 7.1.1 (Date and time of access event), 7.1.2 (Date and time of activity), 7.1.6 (Patient identification), 7.1.7 (User identification), 7.1.8 (Type of action), and 7.1.9 (Identification of the patient data that is accessed) (45 CFR 170.210(e)(1)(i)) [7].

Dokumentinformasjon

  • Standard fra IEEE_AC
  • Publisert:
  • Versjon: 0
  • Varetype: IS