The system SHALL manage each Record Entry as a persistent, indelible (unalterable) data object, including its revision history.

The system SHALL manage (persist) each Record Entry for its applicable retention period according to scope of practice, organizational policy, and/or jurisdictional law.

The system SHALL manage (persist) the full set of identity, event and provenance Audit Metadata for each Record Entry, conforming to lifecycle events in function [[RI.1.1]] (Record Lifecycle) and metadata requirements in function [[TI.2.1.1]] (Record Entry Audit Triggers).

The system SHALL manage (persist) the attestation/signature event (e.g., digital signature) of each Record Entry conforming to function [[RI.1.1.4]] (Attest Record Entry Content).

The system SHALL manage Record Entries with data content in standard and non-standard formats.

The system SHALL manage Record Entries containing both structured and unstructured data.

The system SHOULD manage Record Entry content with tagged or delimited elements including data formatted as text, documents, images, audio, waveforms, in ASCII, binary and other encodings.

The system SHOULD manage Record Entries in clinical and business contexts.

The system SHOULD provide the ability to manage sets of clinical and business context data, to be captured in or linked to Record Entries.

The system SHOULD provide the ability to extract all available elements included in the definition of a legal medical record (including Audit Log Entries and the decoded translation of anything stored only in code form) according to scope of practice, organizational policy, and/or jurisdictional law.

The system MAY provide the ability to tag specific Record Entries for deletion according to scope of practice, organizational policy, and/or jurisdictional law.

IF allowing tags for specific Record Entry deletion, THEN the system SHALL provide the ability to manage the set of tagged Entries, allowing review and confirmation before actual deletion occurs according to scope of practice, organizational policy, and/or jurisdictional law.

IF allowing tags for specific Record Entry deletion, THEN the system SHALL provide the ability to delete Entries according to scope of practice, organizational policy, and/or jurisdictional law.

IF allowing tags for specific Record Entry deletion, THEN the system SHALL provide the ability to render confirming notification that the destruction occurred according to scope of practice, organizational policy, and/or jurisdictional law.

The system MAY provide the ability to maintain Record Entries by undeleting the Record Entries according to scope of practice, organizational policy, and/or jurisdictional law.

The system MAY transmit record destruction date information along with existing data when transmitting Record Entries (or extracts) to another entity.

The system SHOULD manage health care information for organizations that have multiple facilities according to scope of practice, organizational policy, and/or jurisdictional law.

The system MAY tag and render patient information that has been not been previously presented to the clinician.

IF the system tags patient information from internal or external systems that has not been previously presented to the clinician, THEN the system MAY present a notification to that clinician in accordance with user role and according to scope of practice, organizational policy, and/or jurisdictional law.