SUMMARY INVENTORY of RECORD ENTRY REQUIREMENTS THROUGH July 15, 2013

Updated throughSeptember09, 2013

Your goal, as a Functional Profile Domain team member, is to turn all the YELLOW background items for your Functional Profile Domain to a GREEN background (on the "Functions" tab). That is, items begin their lives as YELLOW ("yet-to-be-reviewed"); you should turn each item to GREEN after you have reviewed it. This method will make it very easy for you to quickly see all of the items that you still need to tackle. You should mark any troublesome items with RED background (and offer a quick, corresponding note in the NOTE column near the righthand side of your Functional Domain. After each RED item has been adjudicated, it can then be turned GREEN. / This background color means, "Please review me!" / This background color means, "Reviewed and Accepted!" / This background color means, "Question or Issue! See the corresponding note!"

SUMMARY INVENTORY OF RECORD ENTRY REQUIREMENTS THROUGH July 15, 2013

Initial tasks: Stipulated minimum requirements according to SHALLs, SHOULDs, and MAYs in RI Section, noting the inclusion or exclusions from Overarching (OV) section in order to understand and, where necessary, elevate CCs or add CCs for RMES support.

(Bold, underlined, larger fontmeans Core Required as necessary component of Record Entry in all instances (those not bold/underlined and SHALL still must be captured and managed by the system but are supportive to the Record Entry but not integral to (necessarily conveyed as part of any rendering of information internally or externally) NOTE:It is anticipated that working through this list may spur discussions leading to changing of the integral/non-integral state.

Asterisk* means there are Data Quality/”Information Governance” implications listed

All Record Entries: These qualifications appear to apply to every Record Entry, presuming those recording actions on the system such as system configuration, CDS business rules, business rules applying to terminologies, to required vs. elective data capture in templates, template design, etc.
SHALL Supporting (metadata or Content) Elements
Model Section / Item / Meta-data or Content / Conformance criterion statement / Notes
RI.1.1.1 / Name: Originate and Retain Record Entry / Statement: Originate and Retain a Record Entry (1 instance) / Description: Occurs when Record Entry is originated – typically during the course of an Action itself, to document the Action and context.
• Record Entry is persistent evidence of Action occurrence
• An identified Author or Source is responsible for Record Entry content.
• Record Entry contains Metadata about the Action and its circumstances, e.g., who, what, when, where, facts, findings, observations, etc.
• An Audit Trigger is initiated to track Record Entry origination and retention.
Reference: ISO 21089, Section 12.2.2.
RI.1.1.1 (1) / Originate Record Entry / The system SHALL provide the ability to capture (originate) a Record Entry instance corresponding to an Action instance and context. / (Included here as reference only as it does not address detail on data/metadata as other CC’s do)
RI.1.1.1 (2) / Unique Instance Identifier / m / The system SHALL capture a unique instance identifier for each Record Entry. / The system generates an identifier that becomes a permanent part of the RE:
Linked to the encounter – inpatient visit has one encounter. Outpatient linked to the visit. Telephone encounter may be an order and lab. If there are orders or results not linked to an encounter, but the system should create a unique number.
Bobbi-In their systems specific RE types (ex: New Encounter, Telephone encounter)
Gary: Example: Deci-second time useable as identifier
Serafina: Systems exist that do generate instance ID as system-generated number assigned to individual REs.
Kim/Serafina: Synchronization supports important factor.
Reed: Non-patient specific, not PHI have different “unique identifier” specificity requirements that are different from PHI REs.
Bobbi/Serafina: Time synch standards of substantial interest to RMES and do have applicable standards.
Question: Does FM have a Conformance Standard referencing an international standard (Serafina to research, bring back to group. Will also check how it address date and time See FM IN.2.3?).
RI.1.1.1 (3) / Digital signature event*** / M? / The system SHALL capture the signature event (e.g., digital signature) of the origination entry Author, binding signature to Record Entry content. / The “capture the signature event” supportive data/metadata requirement applies only to that unique Record Entry (itself composed of 1 to n individual REs) aggregated into an object that is to be signed. The “signed” objected becomes itself a new RE, with the attributes generated by the signature action. There is no necessary or implied requirement that this action “writes back” additional or new metadata to the individual component Record Entries .
RI.1.1.1 (4) / Signature event and binding RE content / C / The system SHALL capture the signature event (e.g., digital signature) of the origination entry Author, binding signature to Record Entry content. / Questions arise: How is this conceived to work in a setting or for the purposes of reports where multiple authors contribute. This is not intended to prescribe workflow or prerogatives deriving from Professional roles or duties. The latter derive from the policies, procedures, requirements of the user entities.
For a given user setting, where “signature binding” is determined to be the end-use requirements, this stipulates capture of that (signature) event.
RI.1.1.1 (5) / Capture structured and unstructured RE content / The system SHALL provide the ability to capture both structured and unstructured content in Record Entries.
RI.1.1.1 (6) / Capture downtime REs / The system SHALL provide the ability to capture Record Entries from information recorded during system downtime.
RI.1.1.1 (7) / (see Should list)
RI.1.1.1 (8) / Time of Action/Data Collection** / C / The system SHALL provide the ability to capture date/time an Action was taken or data was collected if different than date/time of the Record Entry. / Represents time of entry – does not represent time of event.
(Shoulds, Mays below)
RI.1.1.1.1 / Originate/Retain Record Entry Audit Trigger / Manage Audit Trigger initiated to track Record Entry origination/retention. / Capture Record Entry originate/retain events, including key metadata (who, what, when, where, why).
RI.1.1.1.1 (2) / Organization ID** / m / The system SHALL capture identity of the organization where Record Entry content is originated. / The system generates an identifier that becomes a permanent part of the RE .
Capturing identity of the organization does not, at this stage, specify a requirement for a standardized unique organization identifier. At this point it simply requires capturing the orgs’ own accepted means of self-identification
RI.1.1.1.1 (3) / Patient ID** / m / The system SHALL capture identity of the patient who is subject of Record Entry content. / Capturing identity of the individual does not, at this stage, specify a requirement for a standardized unique patient identifier. At this point it simply requires capturing the orgs’ own accepted means of unique patient identification
Other national domains may have unique identifier rules for individual patients.
RI.1.1.1.1 (4) / Data Source* / C / The system SHALL capture identity of the individual(s) who performed the Action documented in Record Entry content. / Who/what performed the Action (same as or different from Data Enterer, as in use of scribe) (“Capture” means “automatically capture”.)
RI.1.1.1.1 (5) / Data Enterer / m / The system SHALL capture identity of the user who entered/authored Record Entry content. / Who/what executed the Record Entry (RE)
RI.1.1.1.1 (6) / Software application ID**** / m / The system SHALL capture identity of the system application which originated Record Entry content. / Confirmation: There does not exist at this time any standardized registry for software. This will be an ID established by the org itself for identification and may, for example, consist of trade name of the system plus version number plus other information the org deems necessary for assuring future identification of the system used at that time.
RI.1.1.1.1 (7) / IF device is source, then device ID / m / IF the source of Record Entry content is a device THEN the system SHALL capture identity of the device. / Represents date/time the information was sent to the EHR, not the time of event.
If device captures date/time of event then the EHR is set up to receive date/time of event
RI.1.1.1.1 (8) / Capture evidenced Action (?) / m / The system SHALL capture the Action as evidenced by Record Entry content. / “Action” is that real world Event or Activity that the RE is intended to memorialize
RI.1.1.1.1 (9) / Trigger type captured (?) / m / The system SHALL capture the type of Record Event trigger (i.e., originate/retain). / “Trigger is any type of defined system or user action that is intended to generate a Record Entry.
RI.1.1.1.1 (10) / Time of Act/Event** / m / The system SHALL capture date and time of Action occurrence as evidenced by Record Entry content. / Time/date of the Actions/Events reported in the RE content , which may differ from time/date recorded into the system. (See RI.1.1.1 (8), Time of Action/Data collection)
RI.1.1.1.1 (11) / Time of System Capture / m / The system SHALL capture date and time Record Entry content is originated / Time/date the RE was captured into system (Participation time per RIM (?))
RI.1.1.1.1 (12-17) / (12-17 are Shoulds or Mays, see below
SHOULD and MAY Conformance Criteria in RI.1.1.1
RI.1.1.1 (7) / The system SHOULD provide the ability to integrate Record Entries from Information recorded during system downtime. / Gary: Three different times

System time
Capture time for disconnected RE capture
The time of action for an RE capture that may be recorded by a back-up system (such as a disconnected PC-based capture system).

6/24/ 2013 Call: SHALL in an RMES Profile. Normal component for any downtime recovery or disaster recovery.
Also FIND A HOME FOR THIS
Barbara: Charge capture system description (not a downtime function) intended to address information requirements where part of the record belongs in one org domain and another part of the record belongs in a different org domain.
RI.1.1.1 (9) / The system SHOULD capture metadata that identifies the source of non-originated Record Entry (e.g., templated, copied, duplicated, or boilerplate information). / 6/24/ 2013 RMES = SHALL
RI.1.1.1 (10) / The system MAY provide the ability to tag unstructured Record Entry content to organize it according to need, for example, in a time-related fashion or by application-specific groups (such as photographs, handwritten notes, or auditory sounds), or by order of relative importance. / 9/09/2013 Leave at May
RI.1.1.1 (11) / The system MAY capture and maintain a Record Entry encoded as a standards-based data object (e.g., HL7 Continuity of Care or other HL7 CDA R2 Document). / Unclear the intent of this function, please clarify.
Concerns about everything mapping correctly.
Leave at May for now
RI.1.1.1 (12) / The system MAY capture and maintain a standards-based data object to mirror (be duplicate and synchronous with) internal Record Entry representation. / Leave at May
SHOULD and MAY Conformance Criteria in RI.1.1.1.1
RI.1.1.1.1 (12) / The system MAY capture the duration of the Action evidenced by Record Entry content. / How long the item lasted e.g. breathing tx lasted 20 minutes.
Add this statement, but leave this at a MAY.
“According to organizational policy and jurisdictional law.”
RI.1.1.1.1 (13) / The system MAY capture the physical location of the Action evidenced by Record Entry content. / Leave May
RI.1.1.1.1 (14) / The system SHOULD capture identity of the location (i.e., network address, e.g device id) where Record Entry content is originated. / Key piece of data around provenance - make a SHALL
RI.1.1.1.1 (15) / The system MAY capture the rationale for the Action evidenced by Record Entry content. / (e.g. enter an order)
RI.1.1.1.1 (16) / The system MAY capture the rationale for originating Record Entry content. / (e.g. following through with the lab)
RI.1.1.1.1 (17) / IF Record Entry content includes templates (boilerplate information) or copied (duplicated) information, THEN the system SHOULD capture the source of such content. / Shall
Can I see where this information can from in a transparent manner. Add this Shall to the view function.(some system you can hover or change colors – others are much more difficult if at all.

Reminder: ISO Technical Report 21089 Definition for healthcare record entry(section 3.42): Healthcare record entry:dataset, suitably attributed, which forms part of, or a whole, contribution to a health(care) record at one place

Potential Information Governance implications, necessary stipulations

An org will specify requirements for:

Authorship capture and management when the data enterer is not the data source.*
Time capture and management when the system capture time is not the Action/Event time**
Digital signature certificate P&P, maintenance, assignment to Users and Roles***

OV.1 / F / Overarching Criteria / Overarching criteria are those that apply to all EHR Systems. / The Overarching Section contains Conformance Criteria that apply to all EHR Systems and consequently must be included in all EHR-S FM compliant profiles. These criteria are grouped under a single Function. / 1 / The system SHALL conform to function CP.9.1 (Produce a Summary Record of Care).
2 / The system SHALL conform to function CPS.9.3 (Health Record Output).
3 / The system SHALL conform to function CPS.9.4 (Standard Report Generation).
4 / The system SHALL conform to function RI.1.1 (Record Lifecycle) and all child functions.
5 / The system SHALL conform to function RI.1.2 (Record Lifespan) and all child functions.
6 / The system SHALL conform to function RI.2 (Record Synchronization).
7 / The system SHALL conform to function RI.3 (Record Archive and Restore).
8 / The system SHALL conform to function TI.1.1 (Entity Authentication).
9 / The system SHALL conform to function TI.1.2 (Entity Authorization) .
10 / The system SHALL conform to function TI.1.3 (Entity Access Control).
11 / The system SHALL conform to function TI.1.4 (Patient Access Management).
12 / The system SHALL conform to function TI.1.5 (Non-Repudiation).
13 / IF the system transmits data to or receives data from a system outside of a secure network, THEN the system SHALL conform to function TI.1.6 (Secure Data Exchange), to ensure that the data are protected.
14 / IF the system transmits data to or receives data from a system outside of a secure network, THEN the system SHALL conform to function TI.1.7 (Secure Data Routing), to ensure that the exchange occurs only among authorized senders and receivers.
15 / The system SHALL conform to function TI.1.8 (Patient Privacy and Confidentiality).
16 / The system SHALL conform to function TI.2 (Audit) and all child functions.
17 / The system SHOULD conform to function TI.3 (Registry and Directory Services).
18 / The system SHALL conform to function TI.4 (Standard Terminology and Terminology Services).
19 / IF the system manages data for which standard terminologies have been established, THEN the system SHALL conform to function TI.4.1 (Standard Terminologies and Terminology Models) to support semantic interoperability.
20 / IF the system manages data for which standard terminologies have been established, THEN the system SHALL conform to function TI.4.2 (Maintenance and Versioning of Standard Terminologies) to preserve the semantics of coded data over time.
21 / IF terminology mapping is implemented within the system, THEN the system SHALL conform to function TI.4.3 (Terminology Mapping).
22 / IF the system receives or transmits data for which jurisdictionally established interchange standards exist, THEN the system SHALL conform to function TI.5.1 (Application and Structured-Document Interchange Standards) to support interoperability.
23 / IF the system receives and transmits data for which generally accepted interchange standards have been established, THEN the system SHALL conform to function TI.5.2 (Interchange Standards Versioning and Maintenance), to accommodate the inevitable evolution of interchange standards.
24 / The system SHOULD conform to function TI.5.3 (Standards-based Application Integration).
25 / IF the system receives and transmits data with other systems outside itself, THEN the system SHALL conform to function TI.5.4 (Interchange Agreements), to define how the sender and receiver will exchange data.
26 / The system SHOULD conform to function TI.6 (Business Rules Management).
27 / The system SHOULD conform to function TI.7 (Workflow Management).
28 / The system SHALL conform to function TI.8 (Database Backup and Recovery).
29 / The system SHALL conform to function TI.9 (System Management Operations and Performance).

Record Entry excerpts from RI FM R2

RI Record Infrastructure
RI.1 Record Lifecycle
RI.1.1.1 / Originate and Retain Record Entry / Originate and Retain a Record Entry (1 instance) / Occurs when Record Entry is originated – typically during the course of an Action itself, to document the Action and context.
• Record Entry is persistent evidence of Action occurrence
• An identified Author or Source is responsible for Record Entry content.
• Record Entry contains Metadata about the Action and its circumstances, e.g., who, what, when, where, facts, findings, observations, etc.
• An Audit Trigger is initiated to track Record Entry origination and retention.
Reference: ISO 21089, Section 12.2.2. / 0
RI.1.1.1 / 1 / The system SHALL provide the ability to capture (originate) a Record Entry instance corresponding to an Action instance and context.
RI.1.1.1 / 2 / The system SHALL capture a unique instance identifier for each Record Entry.
RI.1.1.1 / 3 / The system SHALL capture the signature event (e.g., digital signature) of the origination entry Author, binding signature to Record Entry content.
RI.1.1.1 / 4 / The system SHALL provide the ability to capture both structured and unstructured content in Record Entries.
RI.1.1.1 / 5 / The system SHALL provide the ability to capture Record Entries from information recorded during system downtime.
RI.1.1.1 / 6 / The system SHOULD provide the ability to integrate Record Entries from Information recorded during system downtime.
RI.1.1.1 / 7 / The system SHALL provide the ability to capture date/time an Action was taken or data was collected if different than date/time of the Record Entry.
R.1.1.1.1 Evidence of Record Entry Originate/Retain Event / Maintain Evidence of Record Entry Originate/Retain Event / Evidence of Record Entry Originate/Retain Event includes key metadata, ensures health record integrity (and trust) and enables record audit. / 0
R.1.1.1.1 / 1 / The system SHALL audit each occurrence when a Record Entry is originated and retained.
R.1.1.1.1 / 2 / The system SHALL capture identity of the organization where Record Entry content is originated.
R.1.1.1.1 / 3 / The system SHALL capture identity of the patient who is subject of Record Entry content.