The records management and evidentiary support functional profile standard is a subset of functions and conformance criteria from the HL7 EHR-S Functional Model standard. The standard was created specifically to address requirements and criteria for basic record management functionality in EHR systems.
The excerpt below outlines the standards for entity authentication (IN.1.1); information attestation (IN.1.8); pending manager record states (IN.126.96.36.199); amended, corrected, or augmented manager record states (IN.188.8.131.52); and document succession management and version control (IN.184.108.40.206). The criteria can be used to develop proposals for selecting an EHR system or as a checklist to evaluate current applications for basic record management functionality.
Information Infrastructure Security Section
IN.1.1 Entity Authentication
Statement: Authenticate EHR-S users and/or entities before allowing access to an EHR-S.
Description: Both users and applications are subject to authentication. The EHR-S must provide mechanisms for users and applications to be authenticated. Users will have to be authenticated when they attempt to use the application, the applications must authenticate themselves before accessing EHR information managed by other applications or remote EHR-S. In order for authentication to be established a Chain of Trust agreement is assumed to be in place. Examples of entity authentication include:
- digital certificate
- secure token
Authentication data/information should be securely stored in the system protected by access controls at a minimum. Logging access to authentication data is recommended. More stringent security measures (encryption, password protection, etc.) could also be applied as appropriate for the organization and situation.
Legal Rationale: Authentication is a critical component to maintaining the legal integrity of the health record contained within the EHR-S. One of the foundational underpinnings of the validity of the record is identification of the users and assurances that they are accurately identified. As a result, the method used by the organization is very important.
|1. The system SHALL authenticate principals (i.e. users, entities, applications, devices, etc.) prior to accessing an EHR-S application or EHR-S data. |
|2. The system SHALL securely store authentication data/information (e.g. passwords, biometrics, etc.). |
|3. The system SHALL prevent access to EHR-S applications or EHR-S data to all non-authenticated principals (i.e. users, entities, applications, devices, etc.). |
|4. The system SHALL prevent viewing and access after a period of inactivity by terminating the session or by initiating a session lock that remains in effect until the user reestablishes access using appropriate identification and authentication procedures. |
|5. The system SHALL provide the ability to protect against invalid, possibly malicious, user authentication attempts based on configurable conditions and rules. An example of such a rule is exceeding a specified number of consecutive invalid login attempts. |
|6. The system SHOULD provide the ability to implement a Chain of Trust agreement. |
|7. The system SHALL authenticate principals using at least one of the following authentication mechanisms: username/password, digital certificate, secure token, biometrics or other SDO approved authentication standard. |
|8. IF passwords are used, THEN the system SHALL prevent the reuse of passwords previously used for a configurable timeframe or number of password changes. |
|9. IF username/passwords are used, THEN the system SHALL support password strength rules that allow for a minimum number of characters and inclusion of alpha-numeric complexity (e.g. as defined by current acceptable industry standards). |
|10. The system SHALL NOT transport or display passwords in plain text. |
|11. IF passwords are used, THEN the system SHALL NOT display passwords while being entered. |
IN.1.8 Information Attestation
Statement: Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with incoming or outgoing information.
Description: The purpose of attestation is to show 1) authorship and assign responsibility for an act, event, condition, opinion, or diagnosis; and 2) locking an entry which requires amendment or correction procedure for changes. Every entry in the health record must be identified with the author and should not be made or signed by someone other than the author unless they have authority to do so. For example, a resident may author a record, but the person taking legal authority for the content is the “attester”—both individuals should be identified.
- Author: All users who create or contribute content and have a role in the development of an entry. Some entries may be created by an author whose role is a student, transcriber or scribe.
- Attester: A user who takes legal authority for the content of the entry. The attester is often the same as the author, but they may also be an individual with authority to take responsibility for the content of the entry created in whole or in part by another author(s) (e.g. student, scribe, transcriber).
Attestation is required for (paper or electronic) entries such as narrative or progress notes, assessments, flow sheets, and orders. Electronic signatures (e.g. ESIGN, biometrics, use of a PIN or action to attest an entry) may be used to implement document attestation. For an incoming document, the record of attestation is retained if included. Attestation functionality must meet applicable legal, regulatory and other applicable standards or requirements.
Systems must be able to accommodate complex attestation scenarios. This includes entries with multiple authors or contributors and the ability to link the content to the originating author. Another scenario includes identification of an author (one who created the content) and an attester (one who formally takes responsibility for the entry). An example of an author and attester includes an intern or student and the individual responsible for their work.
Attestation is linked to function IN.220.127.116.11 (Pending State). When an author attests their entry they are moving the entry from a pending state to a completed state. Once an entry is attested (complete), changes are then made via proper amendment and correction procedures (IN.2.5.3).
Legal Rationale: Legally it is critical that the author of an entry (including all contributors or co-authors) be accurately identified and that every entry has an author who is responsible for the content. Over time it is anticipated that the bar will be raised and that stronger authentication/attestation processes will be required to prevent someone from refuting that they were the author.
|1. The system SHALL conform to function IN.1.1 (Entity Authentication). |
|2. The system SHALL conform to function IN.1.2 (Entity Authorization). |
|3. The system SHALL provide the ability to associate any attestable content added or changed to an EHR with the content's author (for example by conforming to function IN.2.2 (Auditable Records). |
|4. The system SHALL provide the ability for attestation of attestable EHR content by the content's author or authors. |
|5. The system SHALL indicate the status of attestable data which has not been attested (conform to IN.18.104.22.168 Pending State) |
|6. IF the attester is different than the author(s), THEN the system SHALL provide the ability for attestation as allowed by users’ scope of practice, organizational policy, or jurisdictional law. |
|7. IF more than one author contributed to the EHR content, THEN the system SHALL provide the ability to associate and maintain all authors/contributors with their content. |
|8. IF EHR content was attested by someone other than the author, THEN the system SHALL maintain the author(s) and attester. |
|9. IF EHR content was attested by someone other than the author, THEN the system SHALL provide the ability to present (e.g. view, report, display, access) the author(s) and attester. |
|10. IF a record is completed by multiple authors, THEN the system SHALL allow for multiple-attestations linking the content completed to the appropriate author. |
|11. The system SHALL provide the ability to display the name and credential of the author including on outputs (e.g. display, reports, etc.). |
|12. The system SHOULD provide the ability to use digital signatures as the means for attestation. |
Information Infrastructure Health Record Information and Management Section
IN.22.214.171.124 Manager Record States—Pending
Statement: Health record information may be started, updated, but not completed. The records, although not complete, can represent an important piece of healthcare information particularly if viewed for patient care purposes.
Description/Legal Rationale: To assure timeliness support, a system requires means to identify pending documents and to apply user-configured time limits for the system to close incomplete documents. The system should notify the author or designee that a document has not been finalized and will be closed after a set period of inactivity or pending state. The author or surrogate should be notified prior to the note being closed and allowed to update the status
If pending information is used by a clinician to make decisions, for reports, or for decision support the pending version should be retained. The issue of viewing for patient care can be challenging and may not be possible in all systems. One option may be to use access logs to determine whether the pending note was viewed as a threshold to determine retention. Metadata and audit records will be important to help determine the use of the data when it was in a pending state.
The system will then allow the automatically closed document, with the author identified, noting the author and dates of each update, to be available in the EHR.
|1. The system SHOULD provide the ability to define the length of time a document or note can be in a pending or inactive state before being administratively closed. |
|The system MAY provide a notification to the author or designate that a pending document will be administratively closed after a designated period of time. |
|2. The system MAY display pending notes in accordance with the organization’s business rules. |
|3. IF the system displays pending notes, THEN it SHALL clearly identify that a note is pending (incomplete). |
|4. The system SHOULD allow the author the option to update the status: |
- complete the note,
- complete but retain
- the incomplete version of the note if viewed for patient care or used by the system,
- mark the note as erroneous and retain if used for patient care or by the system, or
- discard the note if never viewed for patient care purposes.
|5. The system SHOULD administratively close a note after a period of inactivity in accordance with its business rules and clearly identify that the note was administratively closed. |
|6. The system SHALL apply a date/time stamp and identify the author each time the note was updated including when opened, when updated, with the signature event and when officially closed. |
IN.126.96.36.199 Manager Record States—Amended, Corrected or Augmented State
Statement: Updates to health record information made after finalization (or the signature event/attestation) will be handled as an amendment, correction or augmentation.
Description/Legal Rationale: Clinicians need the ability to correct, amend or augment notes or documents once they have been completed. When an amendment, correction or augmentation has been made, principles for documentation practices require that the original documentation must be accessible, readable, and un-obliterated. A user must have a clear indication that modifications have been made to the entry. There is optionality in how a system may identify an entry/record that has been corrected or amended—a flag or indicator could be displayed, the text could be in a different font, etc. The original entry is not required to be displayed, but can be linked or traced back. The original note or document should be retained for the legally prescribed timeframe as defined by organizational policy.
|1. The system SHALL provide the author or a designee the ability to enter an amendment, correction or augmentation to a note or document. |
|2. The system SHALL allow the author to indicate whether the change was an amendment (additional information), a correction of erroneous information and the reason, or an augmentation to supplement content. |
|3. The system SHALL record and display with the amendment, correction or augmentation the date, time and user of the amendment, correction or augmentation. |
|4. The system SHALL provide the ability to indicate that an amendment or correction has been made to a note or document when it is viewed or printed. |
|5. The system SHALL retain the prior version(s) of a note or document before the amendment, correction or augmentation. |
|6. The system SHALL provide a link or clear direction for accessing the original version of the note or document. |
IN.188.8.131.52 Manager Record States— Document Succession Management and Version Control
Statement: A system shall retain previous versions of a document and manage document succession.
Description/Legal Rationale: The system must have a mechanism to handle versions and succession of records (such as a preliminary and final lab reports, amended or corrected documents). Versioning and succession management is based on a document’s content and/or status change over time.
A version of a document is one of the following:
- A completed and attested document
- A document completed and attested which has been modified one or more times
- A document that has been viewed for clinical decision-making purposes by an individual other than the author
- A document that has been captured in an incomplete state per organization business rules and updated over time (i.e., a preliminary lab test).
- A document that electively, according to the author, must be preserved in the current state at a given point in time (i.e., History and Physical).
Certain types of records are typically handled in versions, for example:
- Lab results (preliminary and final)
- Dictated reports
- Work ups (over course of days)
The prior version of notes or documents should be retained for the legally prescribed timeframe as defined by organizational policy.
|1. The system MAY provide the ability to specify documents and notes that will be handled as a version when the record state changes (e.g. augmented, amended, corrected, etc.). |
|2. The system SHALL provide the author or a designee the ability to create or revise a document or note and save it as a version. |
|3. The system SHALL record and display the date, time and user f or the original and updated version. |
|4. The system SHALL manage the succession of documents |
|5. The system SHALL retain the prior version(s) of a note or document before the changes were made. |
|6. The system SHOULD provide an indication that there is a prior version(s) of a note or document when it is viewed and/or reported. |
|7. The system SHALL provide a link or clear direction for accessing the original version of the note or document. |
|8. The system SHALL provide the ability to identify the most current version. |