[xls] · web viewcsc global healthcare 301-624-1779 [email protected] mark diehl ... receive and...

453
#REF! Sort by Chapter 92 I.1.2 I 93 I.5.3 I 94 I.6 I Andrew Ury Min - Neg Andrew Ury Stat emen t Maj - Neg Andrew Ury Min - Neg

Upload: hoangkiet

Post on 29-Jun-2018

214 views

Category:

Documents


0 download

TRANSCRIPT

#REF! Sort by Chapter

92 I.1.2 I

93 I.5.3 I

94 I.6 I

Andrew Ury

Min - Neg

Delete ISO from description. Should not directly reference ISO in the standard.

Andrew Ury

Statement

Maj - Neg

Delete the word "reliability" from the description.

Andrew Ury

Min - Neg

Examples in description are poor. Need revision.

B1
: Number of functions in Filtered results.
D1
: Click on the down arrow to filter by Chapter: D=DC; S=Supportive; I=Info Infrastructure; O=Overview

95 I.1 I I.1 NA

96 I.1.1 I I.1.1

Calvin Beebe

Secure the access to the EHR-S and EHR information. Prevent unauthorized use of data, data loss, tampering and destruction.

Calvin Beebe

Maj - Neg

Authenticate EHR-S users and/entities before allowing access to an EHR-S. Manage the sets of access control permissions granted within an EHR-S

97 I.1.2 I I.1.2 NA

98 I.1.3 I I.1.3

Calvin Beebe

Manage the sets of access-control permissions granted to EHR-S users. An EHR-S grantsauthorizations to users, for roles,and within contexts. Acombination of the authorizationlevels may be applied to controlaccess to EHR-S functions or data.

Calvin Beebe

Min - Neg

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

99 I.1.3.1 I Aff-S

100 I.1.4 I I.1.4 NA

101 I.1.5 I I.1.5 Aff-S

102 I.1.6 I I.1.6

Calvin Beebe

I.1.3.1

Enable a healthcare professional to manage a patient’s access to the patient’s personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentially harmful to the patient/subject.

Calvin Beebe

Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated or authorized by that user.

Calvin Beebe

Send and receive EHR data securely.

Calvin Beebe

Min - Neg

Route electronically-exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

103 I.1.7 I I.1.7 NA

104 I.1.8 I I.1.8 Aff-C

105 I.2 I I.2 NA

Calvin Beebe

Manage electronic attestation of documents including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing document.

Calvin Beebe

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Calvin Beebe

Manage EHR information across EHR-S applications by · Ensuring that clinical information is valid according to clinical rules; · Ensuring that clinical information is accurate and complete according to clinical rules; and · Tracking amendments to clinical documents.

106 I.2.1 I I.2.1 Aff-S

107 I.2.2 I I.2.2 Aff-S

Calvin Beebe

Retain, ensure availability, and destroy health record information according to organizational standards. This includes: · Retaining all clinical documents for the time period designated by policy or legal requirement; · Retaining inbound documents as originally received (unaltered); · Ensuring availability of information for the legally proscribed period of time; · Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention period.

Calvin Beebe

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

108 I.2.3 I I.2.3

109 I.2.4 I I.2.4

110 I.3 I I.3 NA

Calvin Beebe

Min - Neg

Maintain synchronization involving: · Interaction with entity directories; · Linkage of received data with existing entity records; · Location of each health record component; · Communication of changes between key systems.

Calvin Beebe

Maj - Neg

Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions can be used to exchange data and provide reports for primary and ancillary purposes.

Calvin Beebe

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

111 I.3.1 I I.3.1 NA

112 I.4 I I.4

113 I.4.1 I I.4.1

114 I.4.2 I I.4.2

Calvin Beebe

Enable system communication with registry services through standardized interfaces and extend to services provided externally to the EHR-S.

Calvin Beebe

Maj - Neg

Ensure consistent terminologies, data correctness and interoperability by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

Calvin Beebe

Maj - Neg

Enable version control according to customized policies to ensure maintenance of utilized standards.

Calvin Beebe

Min - Neg

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

115 I.5 I I.5 Aff-C

116 I.5.1 I I.5.1 Aff-C

117 I.5.2 I I.5.2 Aff-C

118 I.5.3 I I.5.3 Aff-C

119 I.6 I I.6 Aff-C

Calvin Beebe

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Calvin Beebe

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

Calvin Beebe

Provide integration with complementary applications and infrastructure services (directory, vocabulary, etc.) using standard-based application programming interfaces (for example, CCOW).

Calvin Beebe

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Calvin Beebe

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

120 I.7 I I.7 Aff-C

121 I.2.4 I Aff-S

122 I.6 I Aff-S

123 I.1.1 SSHA I

Calvin Beebe

Workflow management functions include both the management and set up of work queues, personnel, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Gavin Tong

Gavin Tong

Statement

Maj - Neg

Authenticate EHR-S users and/or entities before allowing access to an EHR-S. Manage the sets of access-control permissions granted within an EHR-S

Authenticate EHR-S users and/or entities before allowing access to an EHR-S.

124 I.1.2 I Entity Authorization.

125 I.1.2 I Aff-S

126 I.1.6 I Aff-C Secure Data Routing

127 I.1.7 I Aff-C Document Attestation

SSHA-CCAC

Name

Maj - Neg

Manage access control rules.

SSHA-CCAC

Statement

Manage the sets of access-control permissions granted to EHR-S users. An EHR-S grants authorizations to users, for roles, and within contexts. A combination of the authorization levels may be applied to control access to EHR-S functions or data.

SSHA-CCAC

Name

SSHA-CCAC

Name

128 I.1.8 ISSHA-CCAC

Name

Min - Neg

Enforcement of Confidentiality

Enforcement of Privacy Rules in the local jurisdictional context.

129 I.2 SSHA IStatement

Maj - Neg

Manage EHR information across EHR-S applications by • Ensuring that clinical information is valid according to clinical rules; • Ensuring that clinical information is accurate and complete according to clinical rules; and• Tracking amendments to clinical documents.

Manage EHR information across EHR-S applications by • Ensuring that recording of clinical information complies with clinical rules; • Ensuring that recording of clinical information complies with clinical rules; and• Tracking amendments to clinical documents.

130 I.2.2 SSHA I

131 I.5 I

132 I.5 SSHA I Aff-T

Statement

Min - Neg

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

SSHA-CCAC

Name

Min - Neg

Statement

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Provide automated health delivery processes and seamless exchange of key clinical and administrative information.

133 f I Aff-SSSHA-CCAC

Statement

Enforce patient privacy rules as they apply to various parts of the EHR-S through the implementation of privacy mechanisms.

134 I.1.2 I Aff-S

135 I.1.2 I Aff-C

Robert Grant

Statement

. . . An EHR-S grants authorizations to users, . .

. . . . An EHR-S controls authorizations to users, . . .

Robert Grant

Statement

Manage the sets of access-control permissions granted to EHR-S users. . . .

Manage the sets of access-control permissions granted to EHR-S users and/or entities….

136 I.4.2 I

137 I.5 I

Robert Grant

Statement

Min - Neg

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

Map or translate local terminology, codes and formats to standard terminology, codes, and formats to comply with health informatics standards.

Robert Grant

Statement

Min - Neg

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Provide automated health delivery processes and seamless exchange of key clinical and administrative information through standards-based solutions..

138 I.5.2 I

139 I.5.3 I

140 I.1.1 I Aff-S

Robert Grant

Name

Min - Neg

Robert Grant

Statement

Min - Neg

. . . and usethese rules of interaction whenexchanging information with partners. . .

Julie Richards

Statement

Authenticate EHR-S users and/or entities before allowing access to anEHR-S.Manage the sets of access-control permissions granted within an EHR-S

Authenticate EHR-S users and/or entities before allowing access to anEHR-S.

142 I.1.8 I Aff-S

143 I.2 I

Julie Richards

Statement

Enforce patient privacy rules as they apply to various parts of the EHR-S through the implementation of privacy mechanisms.

Enforce DATA privacy and confidentiality rules as they apply to various parts or various jurisdictions whithn the EHR-S through the implementation of access priviledge verification mechanisms.

Julie Richards

Statement

Min - Neg

Manage EHR information across EHR-S applications byEnsuring that clinical information is valid according to clinical notes;Ensuring that clinical information is accurate and complete according to clinical rules andTracking amendments to clinical documents

144 I.2.1 IJulie Richards

Statement

Min - Neg

Retain, ensure availability, and destroy health record information according to organizational standards. This includes: > Retaining all clinical documents for the time period designated by policy or legal requirement; > Retaining inbound documents as originally received (unaltered); > Ensuring availability of information for the legally proscribed period of time; > Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention period.

145 I.3 I

146 I.5.1 I Aff-S Messaging Standards

147 I.5.3 I Aff-S Entity Directory Lookup

Julie Richards

Statement

Min - Neg

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

Julie Richards

Name

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

Julie Richards

Name

148 I.5.3 I Aff-S

149 I.1.2 I Aff-S

150 I.1.2 I

151 I.1.5 I Yes Aff-S "Obfuscation"

152 I.1.8 I Yes Aff-T See Also I6.1

Julie Richards

Statement

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Gavin Tong

Gavin Tong

Statement

Min - Neg

Gavin Tong

Statement

"… including data encryption and both destination …"

Gavin Tong

153 I.1.8 I Aff-S

154 I.1.8 I

155 I.1.7 I

156 I.1.7 I

157 I.1.7 I

Gavin Tong

Statement

Gavin Tong

Statement

Min - Neg

Gavin Tong

Statement

Min - Neg

Gavin Tong

Statement

Min - Neg

Gavin Tong

Name

Min - Neg

158 I.2 I Aff-S

159 I.1.1 I

Gavin Tong

Statement

John Moehrke

Statement

Min - Neg

Add: Entitiy Authentication attempts are auditable events.

160 I.1.1 I

161 I.1.2 I

162 I.1.2 I

Yongjian Bao

Statement

Min - Neg

Manage the sets of access-control permissions granted within an EHR-S

Manage the sets of user accounts, as well as entity identities supported within an EHR-S

John Moehrke

Statement

Maj - Neg

An EHR-S grants authorizations to users, for roles, and within contexts.

An EHR-S grants authorizations to users, for roles.

John Moehrke

Min - Neg

163 I.1.5 I

164 I.1.5 I Add I.1.1 in See Also.

165 I.1.6 Mark Ivie I Secure Data Routing

166 I.2.1 I

John Moehrke

Min - Neg

Yongjian Bao

Min - Neg

Name

Min - Neg

Authenticated Data Exchange

Yongjian Bao

Statement

Min - Neg

Change the term "clinical documents" to "EHR data and clinical documents"

167 I.2.2 I

168 I.2.3 Mark Ivie I

169 I.3 I

John Moehrke

Statement

Min - Neg

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange.

Min - Neg

John Moehrke

Statement

Min - Neg

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

Enable secure use of registry services and directories to uniquely identify and supply links for retrieval; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

170 I.3.1 I

171 I.3.1 I

172 I.3.1 I

173 I.4 I

Yongjian Bao

Name

Min - Neg

Distributed registry access

Distributed registry management

Yongjian Bao

Min - Neg

John Moehrke

Statement

Min - Neg

Conceptually migrate the entity name spaces of the local registry and directory services in an EHR-S with the similar services in other EHR systems through standardized communication interfaces.

Yongjian Bao

Name

Min - Neg

Health Informatics and Terminology Standards

Healthcare Terminology Management

174 I.4 I

175 I.5 I System Interoperability

176 I.5.1 I Interchange Standards Data Interchange

Yongjian Bao

Statement

Min - Neg

…. Vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

…. Vocabularies, code sets and decision support syntax

Yongjian Bao

Name

Min - Neg

Interoperability Standards

Yongjian Bao

Name

Min - Neg

177 I.5.1 I

178 I.5.2 I

179 I.5.2 I Application integration

180 I.5.3 I

Yongjian Bao

Statement

Min - Neg

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. System may refer to EHR systems, applications within an EHR-S or other authorized entities that interact with an EHR-S

Support the ability to interchange discrete and structured health record data and clinical documents, including data send and query / retrieve, with complementary systems by adherence to key interconnectivity standards. System may refer to EHR systems, applications within an EHR-S or other authorized entities that interact with an EHR-S

John Moehrke

Statement

Min - Neg

Similar to standard-based messaging, standard-based application integration requires that the EHR-S application use standardized programming interfaces, where applicable. For example, CCOW may be used for visual integration and WfMC for workflow integration.

Similar to standard-based messaging, standard-based application integration requires that the EHR-S application use standardized programming interfaces, where applicable (For example, CCOW may be used for visual integration).

Yongjian Bao

Name

Min - Neg

Application integration standard

John Moehrke

Statement

Min - Neg

Support interaction with entity directories to determine the recipients' address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Support interaction with entity directories to determine the preferred recipients' address profile and data exchange requirements for use when exchanging information with partners.

181 I.5.3 I Interchange Agreements Entity interchange profile

182 I.6 I Remove this function

183 I.7 I Remove this function

184 I.1 I Aff-C

Yongjian Bao

Name

Min - Neg

John Moehrke

Name

Maj - Neg

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

John Moehrke

Statement

Maj - Neg

Workflow management functions include:…..Workflow definitions and management may be implemented by a designated application or distributed across EHR-S applications.

Corey Dalziel

185 I.1.1 I Entity Authentication User Authentication

186 I.1.1 I

Corey Dalziel

Name

Min - Neg

Corey Dalziel

Statement

Min - Neg

Authenticate EHR-S users and/or entities before allowing access to an EHR-S. Manage the sets of access-control permissions granted within an EHR-S.

Authenticate EHR-S users before allowing access to an EHR-S. Manage access through roll based access-control permissions granted within an EHR-S.

187 I.1.2 I Entity Authorization User Authorization

188 I.1.3 I Entity Access Control User Access Control

189 I.1.8 I Aff-S

Corey Dalziel

Name

Min - Neg

Corey Dalziel

Name

Min - Neg

Statement

Enforce patient privacy rules as they apply to various parts of the EHR-S through the implementation of privacy mechanisms.

Enforce patient privacy rules to support location legislation, if applicable, as they apply to various parts of the EHR-S.

190 I.2.2 I

191 I.1 I Security Security Management

194 I.1.1 I

Corey Dalziel

Statement

Min - Neg

Ellen Anderson

Name

Maj - Neg

Ellen Anderson

Statement

Maj - Neg

Authenicate EHR-S users and/or entities before allowing initial access to the EHR-S and subsequent user sessions. Manage the sets of access-control permissions granted within an EHR-S.

Authenicate EHR-S users and/or entities according to the sets of access-control permissions granted within an EHR-S and respected across all EHR-S modules at initial login, after usage session locks, in events requiring authority check and when one user serves as a delegate for another user when that user is unavailable.

195 I.1.2 IEllen Anderson

Maj - Neg

authorized to use the EHR according to identity, role, work assignment, present condition and/or location.•User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such asprivacy.•Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: nurse, dietician, administrator, legal guardian, and auditor.•Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time,location, route of access, and quality of authentication. In addition to the standard,

Suggested 1st sentence of Functional Description: 'EHR-S users are authorized to use the components of the EHR according to identity, role, work assignment, present condition and/or location according to scope of practice within a legal jurisdiction.' ADD: The sets of access-control permissions are configured through single point or multiple point security administration to accommodate both homogeneous and heterogeneous environments.

196 I.1.3 I

200 I.1.4 I Non-repudiation

201 I.1.7 I Document Attestation Entity Attestation Control

Ellen Anderson

Statement

Maj - Neg

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner. Authorizations control must be synchronized across all EHR modules and respected irregardless of user navigation. Exception user access with documented rationale included.

Ellen Anderson

Name

Maj - Neg

DROP THIS FUNCTION FROM THE MODEL

Name

Maj - Neg

205 I.2 I

208 I.2 I

210 I.2.1 I

211 I.2.2 I

Statement

Maj - Neg

Manage EHR information across EHR-S applications by•Ensuring that clinical information is valid according to clinical rules;•Ensuring that clinical information is accurate and complete according to clinical rules ; and•Tracking amendments to clinical documents.

Manage EHR information across EHR-S applications by•Ensuring that clinical information is valid according to clinical integrity and accountability rules;•Ensuring that clinical information is accurate and complete according to clinical integrity and accountability rules through all state changes; •Tracking amendments to clinical documentation through documentation history link. •Tracking attestation and documentation closure practices to attain record completeness.

Name

Maj - Neg

New subfunction under I.2 NameClinical Concept Dictionary

Maj - Neg

Maj - Neg

212 I.2.3 I Synchronization Record Synchronization

213 I.2.4 I

214 I.3 I

215 I.1.5 I Aff-C

Name

Maj - NegMaj - Neg

Ellen Anderson

Maj - Neg

Peter DeVault

Statement

Exchange of EHR information requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHR-S or external to the EHR-S.

Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHRS entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHRS or external to the EHRS.

216 I.2.3 I Aff-C

217 I.6 I Aff-C Remove

218 I.1.6 I Aff-S Remove

219 I.5.3 I

220 I.1 I I.1 NA

Peter DeVault

Statement

Peter DeVault

Name

Peter DeVault

Name

Floyd Bradd, III, MD

Name

Maj - Neg

Entire item should be removed from the outline.

Harold Solbrig

I.1 I.1 Security

Secure the access to the EHR-S and EHR information. Prevent unauthorized use of data, data loss, tampering and destruction.

221 I.5.1 I

222 I.5.2 I

223 I.5.2 I Application integration

224 I.5.3 I

Yongjian Bao

Statement

Min - Neg

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. System may refer to EHR systems, applications within an EHR-S or other authorized entities that interact with an EHR-S

Support the ability to interchange discrete and structured health record data and clinical documents, including data send and query / retrieve, with complementary systems by adherence to key interconnectivity standards. System may refer to EHR systems, applications within an EHR-S or other authorized entities that interact with an EHR-S

John Moehrke

Statement

Min - Neg

Similar to standard-based messaging, standard-based application integration requires that the EHR-S application use standardized programming interfaces, where applicable. For example, CCOW may be used for visual integration and WfMC for workflow integration.

Similar to standard-based messaging, standard-based application integration requires that the EHR-S application use standardized programming interfaces, where applicable (For example, CCOW may be used for visual integration).

Yongjian Bao

Name

Min - Neg

Application integration standard

John Moehrke

Statement

Min - Neg

Support interaction with entity directories to determine the recipients' address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Support interaction with entity directories to determine the preferred recipients' address profile and data exchange requirements for use when exchanging information with partners.

225 I.5.3 I Interchange Agreements Entity interchange profile

226 I.6 I Remove this function

227 I.7 I Remove this function

Yongjian Bao

Name

Min - Neg

John Moehrke

Name

Maj - Neg

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

John Moehrke

Statement

Maj - Neg

Workflow management functions include:…..Workflow definitions and management may be implemented by a designated application or distributed across EHR-S applications.

273 I.1.1 I I.1.1

274 I.1.2 I I.1.2 NA

Harold Solbrig

I.1.1 I.1.1 Entity Authentication

Maj - Neg

Authenticate EHR-S users and/entities before allowing access to an EHR-S. Manage the sets of access control permissions granted within an EHR-S

Harold Solbrig

I.1.2 I.1.2 Entity Authorization

Manage the sets of access-control permissions granted to EHR-S users. An EHR-S grantsauthorizations to users, for roles,and within contexts. Acombination of the authorizationlevels may be applied to controlaccess to EHR-S functions or data.

275 I.1.3 I I.1.3

276 I.1.3.1 I Aff-S

277 I.1.4 I I.1.4 NA

278 I.1.5 I I.1.5 Aff-S

Harold Solbrig

I.1.3 I.1.3 Entity Access Control

Min - Neg

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Harold Solbrig

I.1.3.1

I.1.3.1 I.1.3.1 Patient Access Management

Enable a healthcare professional to manage a patient’s access to the patient’s personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentially harmful to the patient/subject.

Harold Solbrig

I.1.4 I.1.4 Non-repudiation

Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated or authorized by that user.

Harold Solbrig

Send and receive EHR data securely.

279 I.1.6 I I.1.6

280 I.1.7 I I.1.7 NA

281 I.1.8 I I.1.8 Aff-C

282 I.2 I I.2 NA

Harold Solbrig

I.1.6 I.1.6 Secure Data Routing

Min - Neg

Route electronically-exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

Harold Solbrig

I.1.7 I.1.7 Document Attestation

Manage electronic attestation of documents including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing document.

Harold Solbrig

I.1.8 I.1.8 Enforcement of Confidentiality

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Harold Solbrig

Manage EHR information across EHR-S applications by · Ensuring that clinical information is valid according to clinical rules; · Ensuring that clinical information is accurate and complete according to clinical rules; and · Tracking amendments to clinical documents.

283 I.2.1 I I.2.1 Aff-S

284 I.2.2 I I.2.2 Aff-S

Harold Solbrig

I.2.1 I.2.1 Data Retention and Availability

Retain, ensure availability, and destroy health record information according to organizational standards. This includes: · Retaining all clinical documents for the time period designated by policy or legal requirement; · Retaining inbound documents as originally received (unaltered); · Ensuring availability of information for the legally proscribed period of time; · Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention period.

Harold Solbrig

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

285 I.2.3 I I.2.3

286 I.2.4 I I.2.4

287 I.3 I I.3 NA

Harold Solbrig

I.2.3 I.2.3 Synchronization

Min - Neg

Maintain synchronization involving: · Interaction with entity directories; · Linkage of received data with existing entity records; · Location of each health record component; · Communication of changes between key systems.

Harold Solbrig

I.2.4 I.2.4 Extraction of health record information

Maj - Neg

Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions can be used to exchange data and provide reports for primary and ancillary purposes.

Harold Solbrig

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

288 I.3.1 I I.3.1 NA

289 I.4 I I.4

290 I.4.1 I I.4.1

291 I.4.2 I I.4.2

Harold Solbrig

Enable system communication with registry services through standardized interfaces and extend to services provided externally to the EHR-S.

Harold Solbrig

Maj - Neg

Ensure consistent terminologies, data correctness and interoperability by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

Harold Solbrig

Maj - Neg

Enable version control according to customized policies to ensure maintenance of utilized standards.

Harold Solbrig

Min - Neg

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

292 I.5 I I.5 NA

293 I.5.1 I I.5.1 NA

294 I.5.2 I I.5.2 NA

295 I.5.3 I I.5.3 NA

296 I.6 I I.6 NA

Harold Solbrig

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Harold Solbrig

I.5.1 I.5.1 Interchange Standards

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

Harold Solbrig

I.5.2 I.5.2 Application Integration Standards

Provide integration with complementary applications and infrastructure services (directory, vocabulary, etc.) using standard-based application programming interfaces (for example, CCOW).

Harold Solbrig

I.5.3 I.5.3 Interchange Agreements

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Harold Solbrig

I.6 I.6 Business Rules Management

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

297 I.7 I I.7 NA

298 I.1.1 I Aff-S

299 I.1.8 I Yes Enforcement of privacy

Harold Solbrig

I.7 I.7 Workflow

Workflow management functions include both the management and set up of work queues, personnel, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Joann Larson

Statement

Authenticate EHR-S users and/or other entities before allowing access to an EHR-S. Manage the sets of accesscontrol permissions granted within an EHR-S

Authenticate EHR-S users and/or other entities before allowing access to an EHR-S.

HL7 Australia

Name

Maj - Neg

Enforcement of Confidentiality

300 I.1.8 I

301 I.2.1 I Yes

302 I.2.1 I Aff-S

303 I.2 I

HL7 Australia

Statement

Maj - Neg

Enforce patient privacy rules as they apply to various parts of the EHR-S through the implementation of privacy mechanisms.

Enforce patient privacy rules as they apply to various parts of the EHR-S through the implementation of security mechanisms.

HL7 Australia

Name

Min - Neg

Data Retention and Availability

Data Retention Availability and Destruction

HL7 Australia

Statement

Retain, ensure availability and destroy health record informationaccording to organizational standards. This includes:• Retaining all clinical documents for the time perioddesignated by policy or legal requirement;• Retaining inbound documents as originally received (unaltered);• Ensuring availability of information for the legally proscribed period of time;• Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention

Retain, ensure availability and destroy health record informationaccording to organizational standards. This includes:• Retaining all clinical documents for the time perioddesignated by policy or legal requirement;• Retaining inbound documents as originally received (unaltered);• Ensuring availability of information for the legally prescribed period of time;• Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally prescribed retention

HL7 Australia

Statement

Maj - Neg

Remove statement or create an appropriate function

Not appropriate wording for infrastructure

304 I.6 I

305 I.3 I

306 I.4 I

307 I.1 I

308 I.5 I

309 I.7 I NA

HL7 Australia

Statement

Maj - Neg

Manage the ability to create, update,delete (or disable) and versionbusiness rules including institutionalpreferences. Apply business rules fromnecessary points within the EHR-Sto control system behavior.Audit changes made to businessrules, and audit compliance to andoverrides of applied business rules.

Manage the ability to create, update,delete, disable and versionbusiness rules including institutionalpreferences. Apply business rules fromnecessary points within the EHR-Sto control system behavior.Audit changes made to businessrules, and audit compliance to andoverrides of applied business rules.

HL7 Australia

Statement

Maj - Neg

Remove statement or create an appropriate function

HL7 Australia

Statement

Maj - Neg

Remove statement or create an appropriate function

HL7 Australia

Statement

Maj - Neg

Remove statement or create an appropriate function

HL7 Australia

Statement

Maj - Neg

Remove statement or create an appropriate function

HL7 Australia

310 I.1.3.1 I

311 I.1.3.1 I Aff-S

312 I.3.1 I Aff-S

HL7 Australia

Statement

Maj - Neg

Enable a healthcare professional to manage a patient's access to the patient's personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentially harmful to the patient/subject.

Enable a patient, their guardian or healthcare professional (as apropriate within a particular realm) to manage access to the patient's personal health information. Patient access-management includes restricting access to patient/subject-of-care information which the patient wishes to keep private. In exceptional circumstances a healthcare professional may restrict a patient's access to her/his information if it is potentially harmful to the patient/subject.

Kathleen Connor

Kathleen Connor

313 I.5.3 I Aff-S

314 I.1.4 I Aff-S

Kathleen Connor

An EHR-S will use the entity registries to determine the security, addressing, and reliability requirements between partners and use this information to define how data will be exchanged between the sender and the receiver.

An EHR-S will use the entity registries to determine the security, addressing, reliability parameters, business process specifications, and collaboration protocol requirements between partners and use this information to define how data will be exchanged between the sender and the receiver.

Lenel James

Statement

315 I.5.2 I Aff-S

316 I.1 Mark Diehl I

317 I.1 Mark Diehl I

318 I.5.3 I

319 I.7 I No Aff-T both the managerment both the management

Lenel James

Statement

Provide integration withcomplementary applications andinfrastructure services (directory,vocabulary, etc.) using standardbasedapplication programminginterfaces (for example, CCOW).

Maj - Neg

Throughout the Infrastructure chapter.

Add appropriate text to all function statement and functional description cells.

Maj - Neg

Throughout the Infrastructure chapter.

Add appropriate rationale to all functions.

Michael Hennigan MD

Name

Maj - Neg

Entire item should be removed from the outline.

Eric Rose, MD

Statement

320 I.7 I No Aff-S

321 I.1 I I.1 NA

322 I.1.1 I I.1.1

Eric Rose, MD

Statement

B. Patrick Cahill

Secure the access to the EHR-S and EHR information. Prevent unauthorized use of data, data loss, tampering and destruction.

B. Patrick Cahill

Maj - Neg

Authenticate EHR-S users and/entities before allowing access to an EHR-S. Manage the sets of access control permissions granted within an EHR-S

323 I.1.2 I I.1.2 NA

324 I.1.3 I I.1.3

B. Patrick Cahill

Manage the sets of access-control permissions granted to EHR-S users. An EHR-S grantsauthorizations to users, for roles,and within contexts. Acombination of the authorizationlevels may be applied to controlaccess to EHR-S functions or data.

B. Patrick Cahill

Min - Neg

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

325 I.1.3.1 I Aff-S

326 I.1.4 I I.1.4 NA

327 I.1.5 I I.1.5 Aff-S

328 I.1.6 I I.1.6

B. Patrick Cahill

I.1.3.1

Enable a healthcare professional to manage a patient’s access to the patient’s personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentially harmful to the patient/subject.

B. Patrick Cahill

Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated or authorized by that user.

B. Patrick Cahill

Send and receive EHR data securely.

B. Patrick Cahill

Min - Neg

Route electronically-exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

329 I.1.7 I I.1.7 NA

330 I.1.8 I I.1.8 Aff-C

331 I.2 I I.2 NA

B. Patrick Cahill

Manage electronic attestation of documents including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing document.

B. Patrick Cahill

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

B. Patrick Cahill

Manage EHR information across EHR-S applications by · Ensuring that clinical information is valid according to clinical rules; · Ensuring that clinical information is accurate and complete according to clinical rules; and · Tracking amendments to clinical documents.

332 I.2.1 I I.2.1 Aff-S

333 I.2.2 I I.2.2 Aff-S

B. Patrick Cahill

Retain, ensure availability, and destroy health record information according to organizational standards. This includes: · Retaining all clinical documents for the time period designated by policy or legal requirement; · Retaining inbound documents as originally received (unaltered); · Ensuring availability of information for the legally proscribed period of time; · Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention period.

B. Patrick Cahill

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

334 I.2.3 I I.2.3

335 I.2.4 I I.2.4

336 I.3 I I.3 NA

B. Patrick Cahill

Min - Neg

Maintain synchronization involving: · Interaction with entity directories; · Linkage of received data with existing entity records; · Location of each health record component; · Communication of changes between key systems.

B. Patrick Cahill

Maj - Neg

Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions can be used to exchange data and provide reports for primary and ancillary purposes.

B. Patrick Cahill

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

337 I.3.1 I I.3.1 NA

338 I.4 I I.4

339 I.4.1 I I.4.1

340 I.4.2 I I.4.2

B. Patrick Cahill

Enable system communication with registry services through standardized interfaces and extend to services provided externally to the EHR-S.

B. Patrick Cahill

Maj - Neg

Ensure consistent terminologies, data correctness and interoperability by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

B. Patrick Cahill

Maj - Neg

Enable version control according to customized policies to ensure maintenance of utilized standards.

B. Patrick Cahill

Min - Neg

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

341 I.5 I I.5 NA

342 I.5.1 I I.5.1 NA

343 I.5.2 I I.5.2 NA

344 I.5.3 I I.5.3 NA

345 I.6 I I.6 NA

B. Patrick Cahill

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

B. Patrick Cahill

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

B. Patrick Cahill

Provide integration with complementary applications and infrastructure services (directory, vocabulary, etc.) using standard-based application programming interfaces (for example, CCOW).

B. Patrick Cahill

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

B. Patrick Cahill

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

346 I.7 I I.7 NA

347 I.1 I I.1 NA

348 I.1.1 I I.1.1

B. Patrick Cahill

Workflow management functions include both the management and set up of work queues, personnel, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Rick Haddorff

Secure the access to the EHR-S and EHR information. Prevent unauthorized use of data, data loss, tampering and destruction.

Rick Haddorff

Maj - Neg

Authenticate EHR-S users and/entities before allowing access to an EHR-S. Manage the sets of access control permissions granted within an EHR-S

349 I.1.2 I I.1.2 NA

350 I.1.3 I I.1.3

Rick Haddorff

Manage the sets of access-control permissions granted to EHR-S users. An EHR-S grantsauthorizations to users, for roles,and within contexts. Acombination of the authorizationlevels may be applied to controlaccess to EHR-S functions or data.

Rick Haddorff

Min - Neg

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

351 I.1.3.1 I Aff-S

352 I.1.4 I I.1.4 NA

353 I.1.5 I I.1.5 Aff-S

354 I.1.6 I I.1.6

Rick Haddorff

I.1.3.1

Enable a healthcare professional to manage a patient’s access to the patient’s personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentially harmful to the patient/subject.

Rick Haddorff

Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated or authorized by that user.

Rick Haddorff

Send and receive EHR data securely.

Rick Haddorff

Min - Neg

Route electronically-exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

355 I.1.7 I I.1.7 NA

356 I.1.8 I I.1.8 Aff-C

357 I.2 I I.2 NA

Rick Haddorff

Manage electronic attestation of documents including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing document.

Rick Haddorff

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Rick Haddorff

Manage EHR information across EHR-S applications by · Ensuring that clinical information is valid according to clinical rules; · Ensuring that clinical information is accurate and complete according to clinical rules; and · Tracking amendments to clinical documents.

358 I.2.1 I I.2.1 Aff-S

359 I.2.2 I I.2.2 Aff-S

Rick Haddorff

Retain, ensure availability, and destroy health record information according to organizational standards. This includes: · Retaining all clinical documents for the time period designated by policy or legal requirement; · Retaining inbound documents as originally received (unaltered); · Ensuring availability of information for the legally proscribed period of time; · Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention period.

Rick Haddorff

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

360 I.2.3 I I.2.3

361 I.2.4 I I.2.4

362 I.3 I I.3 NA

Rick Haddorff

Min - Neg

Maintain synchronization involving: · Interaction with entity directories; · Linkage of received data with existing entity records; · Location of each health record component; · Communication of changes between key systems.

Rick Haddorff

Maj - Neg

Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions can be used to exchange data and provide reports for primary and ancillary purposes.

Rick Haddorff

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

363 I.3.1 I I.3.1 NA

364 I.4 I I.4

365 I.4.1 I I.4.1

366 I.4.2 I I.4.2

Rick Haddorff

Enable system communication with registry services through standardized interfaces and extend to services provided externally to the EHR-S.

Rick Haddorff

Maj - Neg

Ensure consistent terminologies, data correctness and interoperability by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

Rick Haddorff

Maj - Neg

Enable version control according to customized policies to ensure maintenance of utilized standards.

Rick Haddorff

Min - Neg

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

367 I.5 I I.5 NA

368 I.5.1 I I.5.1 NA

369 I.5.2 I I.5.2 NA

370 I.5.3 I I.5.3 NA

371 I.6 I I.6 NA

Rick Haddorff

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Rick Haddorff

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

Rick Haddorff

Provide integration with complementary applications and infrastructure services (directory, vocabulary, etc.) using standard-based application programming interfaces (for example, CCOW).

Rick Haddorff

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Rick Haddorff

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

372 I.7 I I.7 NA

373 I.5.3 I

375 I.1.3.1 I Aff-S

376 I.3.1 I Aff-S

Rick Haddorff

Workflow management functions include both the management and set up of work queues, personnel, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Susan Andrews, MD

Name

Maj - Neg

Entire item should be removed from the outline.

Vicki Hohner

Vicki Hohner

377 I.5.3 I Aff-S

378 I

Vicki Hohner

An EHR-S will use the entity registries to determine the security, addressing, and reliability requirements between partners and use this information to define how data will be exchanged between the sender and the receiver.

An EHR-S will use the entity registries to determine the security, addressing, reliability parameters, business process specifications, and collaboration protocol requirements between partners and use this information to define how data will be exchanged between the sender and the receiver.

John Moehrke

Statement

Min - Neg

Add: Entity Authentication attempts are auditable events.

379 I

380 I.1.2 I

381 I.1.2 I

382 y I

383 I.1.5 I Add I.1.1 in See Also.

Yongjian Bao

Statement

Min - Neg

Manage the sets of access-control permissions granted within an EHR-S

Manage the sets of user accounts, as well as entity identities supported within an EHR-S

John Moehrke

Statement

Maj - Neg

An EHR-S grants authorizations to users, for roles, and within contexts.

An EHR-S grants authorizations to users, for roles.

John Moehrke

Min - Neg

John Moehrke

Min - Neg

Yongjian Bao

Min - Neg

384 I.1.6 Mark Ivie I Secure Data Routing

385 I.2.1 I

386 I.2.2 I

387 I.2.3 Mark Ivie I

Name

Min - Neg

Authenticated Data Exchange

Yongjian Bao

Statement

Min - Neg

Change the term "clinical documents" to "EHR data and clinical documents"

John Moehrke

Statement

Min - Neg

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange.

Min - Neg

388 I.3 I

389 I.3.1 I

390 I.3.1 I

John Moehrke

Statement

Min - Neg

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

Enable secure use of registry services and directories to uniquely identify and supply links for retrieval; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

Yongjian Bao

Name

Min - Neg

Distributed registry access

Distributed registry management

Yongjian Bao

Min - Neg

391 I.3.1 I

392 I.4 I

393 I.4 I

394 I.5 I System Interoperability

John Moehrke

Statement

Min - Neg

Conceptually migrate the entity name spaces of the local registry and directory services in an EHR-S with the similar services in other EHR systems through standardized communication interfaces.

Yongjian Bao

Name

Min - Neg

Health Informatics and Terminology Standards

Healthcare Terminology Management

Yongjian Bao

Statement

Min - Neg

…. Vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

…. Vocabularies, code sets and decision support syntax

Yongjian Bao

Name

Min - Neg

Interoperability Standards

395 I.5.1 I Interchange Standards Data Interchange

923 I.1.1 I Aff-S

Yongjian Bao

Name

Min - Neg

Joann Larson

Statement

Authenticate EHR-S users and/or other entities before allowing access to an EHR-S. Manage the sets of accesscontrol permissions granted within an EHR-S

Authenticate EHR-S users and/or other entities before allowing access to an EHR-S.

957 I.1.5 I Aff-C

958 I.2.3 I Aff-C

959 I.6 I Aff-C Remove

Cindy Wenger

Statement

Exchange of EHR information requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHR-S or external to the EHR-S.

Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHR-S or external to the EHR-S.

Cindy Wenger

Statement

Cindy Wenger

Name

960 I.4.1 I

1001 I.5.2 I

David Markwell

Min - Neg

There is a requirement for system audit trails for the following events: 1. Loading new versions of, or changes to, the clinical system;2. Loading new versions of codes and knowledge bases; 3. Changing the date and time where the clinical system allows this to be done; 4. Taking and restoring of backup; Archiving any data; 5. Re-activating of an archived patient record; 6. Entry to and exiting from the clinical system; 7. Remote access connections including those for system support and maintenance activities.

Charlene Underwood

Statement

Maj - Neg

1002 I.5.3 I

1003 I.6 I Aff-S

1004 I.7 I Aff-S Workflow Workflow Management

1022 I.1 I I.1 NA

Charlene Underwood

Statement

Min - Neg

Charlene Underwood

Statement

Charlene Underwood

Name

Paul Carpenter MD

Secure the access to the EHR-S and EHR information. Prevent unauthorized use of data, data loss, tampering and destruction.

1023 I.1.1 I I.1.1

1024 I.1.2 I I.1.2 NA

Paul Carpenter MD

Maj - Neg

Authenticate EHR-S users and/entities before allowing access to an EHR-S. Manage the sets of access control permissions granted within an EHR-S

Paul Carpenter MD

Manage the sets of access-control permissions granted to EHR-S users. An EHR-S grantsauthorizations to users, for roles,and within contexts. Acombination of the authorizationlevels may be applied to controlaccess to EHR-S functions or data.

1025 I.1.3 I I.1.3

1026 I.1.3.1 I Aff-S

1027 I.1.4 I I.1.4 NA

1028 I.1.5 I I.1.5 Aff-S

Paul Carpenter MD

Min - Neg

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Paul Carpenter MD

I.1.3.1

Enable a healthcare professional to manage a patient’s access to the patient’s personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentially harmful to the patient/subject.

Paul Carpenter MD

Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated or authorized by that user.

Paul Carpenter MD

Send and receive EHR data securely.

1029 I.1.6 I I.1.6

1030 I.1.7 I I.1.7 NA

1031 I.1.8 I I.1.8 Aff-C

1032 I.2 I I.2 NA

Paul Carpenter MD

Min - Neg

Route electronically-exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

Paul Carpenter MD

Manage electronic attestation of documents including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing document.

Paul Carpenter MD

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Paul Carpenter MD

Manage EHR information across EHR-S applications by · Ensuring that clinical information is valid according to clinical rules; · Ensuring that clinical information is accurate and complete according to clinical rules; and · Tracking amendments to clinical documents.

1033 I.2.1 I I.2.1 Aff-S

1034 I.2.2 I I.2.2 Aff-S

Paul Carpenter MD

Retain, ensure availability, and destroy health record information according to organizational standards. This includes: · Retaining all clinical documents for the time period designated by policy or legal requirement; · Retaining inbound documents as originally received (unaltered); · Ensuring availability of information for the legally proscribed period of time; · Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention period.

Paul Carpenter MD

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.

1036 I.2.3 I I.2.3

1037 I.2.4 I I.2.4

1038 I.3 I I.3 NA

Paul Carpenter MD

Min - Neg

Maintain synchronization involving: · Interaction with entity directories; · Linkage of received data with existing entity records; · Location of each health record component; · Communication of changes between key systems.

Paul Carpenter MD

Maj - Neg

Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions can be used to exchange data and provide reports for primary and ancillary purposes.

Paul Carpenter MD

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes.

1039 I.3.1 I I.3.1 NA

1040 I.4 I I.4

1041 I.4.1 I I.4.1

1042 I.4.2 I I.4.2

Paul Carpenter MD

Enable system communication with registry services through standardized interfaces and extend to services provided externally to the EHR-S.

Paul Carpenter MD

Maj - Neg

Ensure consistent terminologies, data correctness and interoperability by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture.

Paul Carpenter MD

Maj - Neg

Enable version control according to customized policies to ensure maintenance of utilized standards.

Paul Carpenter MD

Min - Neg

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

1043 I.5 I I.5 NA

1044 I.5.1 I I.5.1 NA

1046 I.5.2 I I.5.2 NA

1047 I.5.3 I I.5.3 NA

1048 I.6 I I.6 NA

Paul Carpenter MD

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Paul Carpenter MD

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S.

Paul Carpenter MD

Provide integration with complementary applications and infrastructure services (directory, vocabulary, etc.) using standard-based application programming interfaces (for example, CCOW).

Paul Carpenter MD

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Paul Carpenter MD

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. Apply business rules from necessary points within the EHR-S to control system behavior. Audit changes made to business rules, and audit compliance to and overrides of applied business rules.

1049 I.7 I I.7 NA

Paul Carpenter MD

Workflow management functions include both the management and set up of work queues, personnel, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

Not

Not

Not

lavender denotes Action Item - maybe combined with Candidate Issue. Blue is Candidate Issue.

Not related - Comment on reference material

Not Related. Author is commenting on functional description, which is reference material.

Better yet, delete this item as automated interface setup is not practical at this time.

Not Persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. It it understood that some functions may not be currently available or simple to implement. As such we still documented functions that are felt to be essential functions in the future or important for relevant care settings. The current wording accurately reflects the intent and meaning of the EHR SIG.

Not related - Comment on reference material

Not Related.  Comment concerns reference materials and author does not provide any new information or offer proposed modifications to the functional description. We welcome your input into enhancing the functional description in the future.

Not no comment submitted

Not

Negative Major Authentication refers to verifying that users are who they say they are. It does not pertain to the set of access control permissions.

Persuasive with Modification

Persuasive with Modification. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Not

Not

Edit Should also refer to the entities

persuasive, clarification - simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Negative Minor Are Applications and sites equivalent to entities?

persuasive

Persuasive - will clarify language to indicate users and entities (including applications, sites, systems)

Not

no comment submitted

Not

Not

Edit Function Name should indicate the access is to medical record informatio. Could be confused with appointment availability.

not persuasive

Not persuasive: Authoring group will define personal health information to provide clarity on this issue in an EHR glossary. Link 99, 276, 325, 351, 1026.

Substantive?

EDIT "Send and receive EHR data securely" should be replaced with "Secure all modes of EHR data exchange"

Persuasive - clarification simple

“ Persuasive. Comments reflect intent of authoring group. Link items 101, 278, 327, 353, 1028

Negative Minor - Superfluous If the scope of coverage is corrected in i.1.3

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Not no comment submitted

Not

Not no comment submitted

Comment How is this different from Entity Access Control? I.1.3

Not persuasive

Not persuasive - Access control deals with the ability to control which functions, modules or types of data an EHR-S user is allowed to utilize or view. Enforcement of confidentialy deals with complying to realm, organization and/or patient specified rules regarding the way in which patient related data is used and who is allowed to see the data. It is possible to have access control that does not enforce privacy rules.

not persuasive

Not

Not

Edit & Comment "proscribed" should be "prescribed". This function seems to only refer to documents, not all data in retention.

Persuasive – minor editorial or typos

Persuasive - Typographical error will be corrected

Comment It would be desirable to separate change/update journal information from access/retreival audit logs. ?definition of resource access and usage.

Persuasive (accept part, reject part)

Persuasive in part: (1) Not Persuasive: Author's suggestion that the function "separate change/update journal information from access/retrieval audit logs" is implementation specific. (2) Persuasive: We will define terms in a glossary. The definition will separate the concept of change-logging from resource access and usage auditing functions.

Not

Not

Not no comment submitted

Negative Minor Does not clearly distinguish patient data syncronization from system table/metadata reference files

Persuasive_W_Mods

Persuasive with Modification. Your comment has merit and will require further review. The authoring groupo will assess your recommendations as part of the upcoming DSTU assessment. We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience. Link 108, 285, 334. 360, 1036.

Negative Major Patient specific data exports are not addressed. The example is misleading with respect to EHR functionality. No provision is cited for IRB or equivalent oversight of the extraction process.

Not_Persuasive

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care and Supportive Sections. D 2.2.1.5 is intended to include IRB or equivalent oversight of the extraction process.

not persuasive

Not no comment submitted

Not

Not

Not

not Persuasive

Negative Major The EHR should provide functionality to utilize standard terminology services. The specification of content should be a decision by the realm.

Persuasive (with modification), minor

Persuasive with Modification: The proposed changes to the function statement reflect the intent of the authoring group. In addition, relevant citations to vocabulary services standards will be added to the citation section. Link 112, 174, 289, 338, 364, 1040.

Negative Major If the previous element focuses on terminology services, issues of maint. And versioning are addressed.

Persuasive_W_Mods

Persuasive with Modification - Issue resolved with changes agreed to in I.4 and with a DSTU assessment review of the description of "version control." Link 113, 290, 339, 365, 1041

Negative Minor The functionality of accomodating mapped terms is in the EHR, the process of mapping itself is external to the EHR.

Not Persuasive

Not Persuasive. Issue resolved with changes to I 4

Not

Not No comment submitted

Not No comment submitted

Not No comment submitted

Not No comment submitted

Edit Replace "automate" with "automated" in function statement

Persuasive – minor editorial or typos

Persuasive minor. Reflects intention of the authoring group

not persuasive

not persuasive

Not No comment submitted

Not

Not

Not

There should be a cross reference to S 2.2

Persuasive (with modification), minor

Persuasive with Modifications, minor. Authoring Group will cross reference to S2.2. During the DSTU we consider all cross references.

There should be a cross reference to Direct Care Clinical Decision Support functions and Supportive Administrative Decision Support functions

Persuasive – clarification simple

Persuasive, clarification simple" The authoring group will add appropriate "See Also" links during the DSTU assessment period.

Authentication is a function that is distinct from that of managing access/control permissions. Authentication is verifying the user's identity as a recognized, trusted user.

Persuasive with Modification

Persuasive with Modification. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail in during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Not

Not

Not

Not

The name does not match the language of the statement.

Persuasive with Modification

Persuasive with Modifications. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. “

There is no reference to "entity" in the Function Statement, although it is in the Function Name. (See above)

Persuasive_W_Mods

Persuasive with Modifications: Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. We will define "entity" in an EHR glossary in accordance with your suggestion.“Link 125, 148, 150, 185, 186, 187, 188

Should this be rolled up under I.1.5?

considered

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

There is a need to appreciate different meanings and constructs of "document" and define functions appropriately for this (i.e., document attestation relating to retaining electronic versions of "traditional" documents vs. document attestation relating to our ability to maintain integrity for data received via electronic message)

Persuasive

Persuasive - name and statement change to indicate that attestation is for information, reflects the intent of the authoring group. Link to item 127

Not

The statement talks about privacy rules, not confidentiality. These are two different concepts.Privacy involves the right to control one’s own personal information, and the ability to determine if and how one’s information should be collected and used. Confidentiality, however, is only one means of protecting such information, usually in the form of keeping that information protected from unauthorized disclosure.Perhaps you need two functions: one for privacy rules and one for confidentiality enforcement.

Persuasive_W_Mods

Persuasive with Modification - Your comment has merit and will require further review during the DSTU assessment. This function deals with enforcement of privacy rules to ensure confidentiality. Authoring group intended to handled privacy rules in I.6 where they are included under business rules, but realm specificity of these concepts needs further analysis during the DSTU assessment. Link 128, 133, 143, 153, 154, 299, 310

Not

Either the Function Statement, Functional Description or both need to be amended to clarify what is meant by valid and accurate in the context of clinical rules. It does not and cannot refer to the validity and accuracy of specific clinical information documented for a particular patient. Only the author can attest to this. It does refer to validity and accuracy within the context of accepted clinical practice for documenting clinical assessment and findings for a particular category of problem or diagnosis e.g. positive findings and relevant negative findings are documented relevant to the body system(s) of interest (validity) and are documented accurately (follow professional guidelines for such documentation).

Persuasive – clarification simple

Persuasive with Modification - Comment reflects authoring group's intent. the authoring group will make changes recommended to the Function Statement. The authoring group will review recommendations about whether to differentiate subfunctions during DSTU assessment. Link 129, 143, 158

Not

Needs a verb Not Persuasive. Link 115, 132

Not

There is no mention here of audits of consent status management, although Consent is a Function included in Direct Care (DC 1.5.1).

Persuasive – clarification simple

Persuasive. Authors' comment " 'There is no mention here of audits of consent status management, although Consent is a Function included in Direct Care (DC 1.5.1)" is a clarification of the authoring group's intent. Link 130, 159, 378

Persuasive

Typo - automate should be "automated"

Persuasive – minor editorial or typos

Persuasive. Reflects intention of the authoring group

Not

The Function Name refers to "confidentiality" but the statement talks about "privacy rules". These are two different concepts.Privacy involves the right to control one’s own personal information, and the ability to determine if and how one’s information should be collected and used. Confidentiality, however, is only one means of protecting such information, usually in the form of keeping that information protected from unauthorized disclosure to third parties.Perhaps you need two functions: one for privacy rules and one for confidentiality enforcement. The function concerning the enforcement of privacy rules/legislation/policies should explicitly acknowlege the need to implement these appropriately in each individual jurisdictional context.

Persuasive with Modification

Persuasive with Modification - Your comment has merit and will require further review during the DSTU assessment. This function deals with enforcement of privacy rules to ensure confidentiality. Authoring group intended to handled privacy rules in I.6 where they are included under business rules, but realm specificity of these concepts needs further analysis during the DSTU assessment. Link 128, 133, 143, 153, 154, 299, 310

Not

Not

A more neutral term for what an EHR application is doing, since it is 'people' who actually grant access. Moreover, revocation of rights is also a part of authorization and that acttion is usual not spoken of as "granting".

persuasvie, clarification simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Inclusions of entities is implied by function name, but should be made explicit here, as it was in section I.1.1. Devices/applications can be authorized, as can users

persuasvie, clarification simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Not

Not

the aggregate function is mapping of terminology + codes + formate. Some applications may do only one or two of these so there should eventually be child sub-functions. Meantime this functional statement should encompass all three components.

Persuasive_W_Mods

Persuasive with Modification: The proposed changes to the function statement reflect the intent of the authoring group. The proposal that the capacity to translate terminology, codes and formats should be specified in sub-functions has merit for DSTU assessment.

What is the intent of this section? It is not clear what functions are being described and how these equate to read-world applications. They vacillate between describing services akin to the terminology and mappping services of the previous sections and functions related to developing technical standards in order to achieve interoperability. Both types of functions are probably needed, but if so should be separate.

Suggest explicity drawing out the technical solutions as separate functions and in each case defining them as standards based to support application interoperability e.g Standards-based API, Standards-based EDI, standards-based connectivity and etc.

Persuasive_W_Mods

Persuasive with modification: The authoring group accepts your proposed wording change for the statement I.5 as it more closely reflects our intention that this function be supported by standards. Your comment about whether to separate interoperability technology standards from standards relating to the interfaces that support interoperability but are also needing management in accordance with health informatics principles and terminology support expressed by I 4 has merit for consideration during DSTU assessment.

Not

Not

Not

Per my remarks on I.5 this function should be named "Standards-based API" or something similar.

Persuasive_W_Mods

Persuasive wiht Mod - Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “ NOTE: Technical Clarification: Standard to Standard-based as the reference is not to any specific standard, but rather an API based on a standard.

What rules? Does this function describe some sort of hybrid authentication and access-control service? If so, the description should be much clearer.

Persuasive with Modification

Persuasive with Modifications - The authoring group agrees with the commenter that this function needs to reference rules and standards, such as the HL7 version 3 Dynamic Model, and include more functional grandularity. We would appreciate commenter's participation in the DSTU assessment of this function to help us develop a clearer function statement.

Persuasive with Modification

Persuasive with Modification. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Not

Not

By protecting the data, the privacy of all parties involved (patient, provider, organization) is addressed.

Persuasive with Modification

Persuasive with Modification - Your comment has merit and will require further review during the DSTU assessment. This function deals with enforcement of privacy rules to ensure confidentiality. Authoring group intended to handled privacy rules in I.6 where they are included under business rules, but realm specificity of these concepts needs further analysis during the DSTU assessment. Link 128, 133, 143, 153, 154, 299, 310

This function combines a multitude of functions into one which makes the whole thing very confusing. Does this function refer to automated clinical information? And data validation at the point where is collected? And consistency across the EHR-S? Is this evaluating the physician decision or the coder? What do they mean "clinical infromation is valid according to clinical notes"?

Persuasive_W_Mods

Persuasive with Modification: Comment reflects authoring group's intent. the authoring group will make changes recommended to the Function Statement. The authoring group will review recommendations about whether to differentiate subfunctions during DSTU assessment. Link 129, 143, 158

Not

Is EHR data supposed to be destroyed or archived? This function appears to combine rather contradictory concepts.

Persuasive_W_Mods

Persuasive with Modification - Authoring group will clarify during DSTU assessment how to capture both the archiving and destruction functions most appropriately, including the need to accommodate the provision of URIs that point to large documents in federated repositories, and the need to standardize record retention for participants in a federation of repositories. This includes purging and movement from on-line to archival storage.

Not

Not

Not

This function statement is very ambiguous and too broad. This function combines the clinically-relevant and admin/financial registries. Is the function to provide secure access or to do the lookup and management of the directories.This function details the generic mechanism for looking up information, not the specific registries. We need to ensure that the supportive functions for patient, provider, and location registration are adequate substitutes. Similarly this function deals with clinical (disease registry) and non-clinical registries. Is this a common mechanism for directory and registry related functions???? Maybe this function should be deleted and Supportive-Clinical Support.

Persuasive_W_Mods

Persuasive with Modification: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.

This function statement describes messaging standards so why not call it that vs introducing a new term i.e. interchange. 1.5.2 Application Integration Standards uses standardized programmig interfaces

Persuasive_W_Mods

Persuasive with Modification - Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “

The name does not match the statement

Not Persuasive

“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the capabilities in the function statement."

Not

not

Not

Not

I6.1 does not exist. Not Persuasive - clarification simple

The word "entity" is used repeatedly and it should be explained as it may mean "user", "patient', "provider", etc.

Persuasive (with modification), minor

Persuasive with Mod - Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. We will define "entity" in a glossary in accordance with your suggestion.“Link 148, 150, 185, 186,187, 188

The specific ISO document referred to by the 3rd bullet should be specified (by ISO #) and this should be captured in the citation.

persuasive, clarification - simple

Persuasive. Authoring group will make the change suggested

The name is "Entity Authorization" but "Entity" is not described in the Functional Statement?

Persuasive with Modificationification

Persuasive with Modification - Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. We will define "entity" in a glossary in accordance with your suggestion.“Link 125, 148, 150, 185, 186, 187, 188

Perhaps a more generic term can be used, such as encryption?

not persuasive

Not Persuasive - Encryption is just one form of obscuring the ability to read data and this function is intended to be more broad.

Persuasive - clarification simple

Not

Not

Not

Not

Not

This statement should include a sentence referencing jurisdiction-specific privacy rules.

persuasive, clarification - simple

Persuasive – clarification simple Link 153, 189, 300

Need to segregate privacy from confidentiality as these are separate, but very important topics.

Persuasive_W_Modifications

Persuasive with Modification - Your comment has merit and will require further review during the DSTU assessment. This function deals with enforcement of privacy rules to ensure confidentiality. Authoring group intended to handled privacy rules in I.6 where they are included under business rules, but realm specificity of these concepts needs further analysis during the DSTU assessment. Link 128, 133, 143, 153, 154, 299, 310

Overly focused on documentation as opposed to the individuals involved.

persuasive

Persuasive - name and statement change to indicate that attestation is for information, reflects the intent of the authoring group. Link to 127 and 157

This should be raised as "Information attestation", we don't feel that the statement as it stands now contains enough information such that a person would know what to do with it?

persuasive

Persuasive - name and statement change to indicate that attestation is for information, reflects the intent of the authoring group.

Overuse/misuse of the word "document" As the EHR grows in prevalence and use, this may be increasingly inappropriate. Needs further explanation. Information Attestation would be a better name.

Persuasive

Persuasive - name and statement change to indicate that attestation is for information, reflects the intent of the authoring group. Link to item 127

Not

Not

Dependant upon whom is allowed to enter data eg if allow patient to supply data, this is important information to know, but according to this document all information needs to be validated "according to clinical rules" (for example allergies disclosed by a patient - how would it be possible to ensure this information according to clinical rules). The use of the word "accurate" may be inappropriate?

Persuasive with Modificationification

Persuasive with Modification - Comment reflects authoring group's intent. the authoring group will make changes recommended to the Function Statement. The authoring group will review recommendations about whether to differentiate subfunctions during DSTU assessment. Link 129, 143, 158

persuasive, clarification - simple

Persuasive, clarification - siimple: Accept the comment that the audit of entity authentication attempts will be added to I.2.2 and is consistent with the intent of the authoring group. Link 130, 159, 378

Not

Not

Not

I.1.1 needs to include two things: 1) Ability to authenticate a user / an entity (establishment of an identity), and 2) ability of manage a database of users and entities, and authentication credentials.

Persuasive with Modificationification

Persuasive with Modificationification. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Context-based authorization is too burdensome. Definition of contexts is too broad (in funct. description)

Not Persuasive

“Not Persuasive. This function may be a stretch-goal, however it is believed that the functions are a superset of all functions that can or should be provided by EHR-S’ (both now and in the future). This function was carefully considered and approved by the SIG and identified as Essential now or Essential Future for one or more care settings/profiles. Author's proposal would adversely affect other functions, which may also be future functions, that depend on, or are related to, this function. Discussion: Context-based authorization is likely needed by some US realm enities to comply wih HIPAA Requirement: § 164.312 Technical safeguards Also see comment on this

Example of user-based authorization is really patient-based authorization - should be changed to user-based example. Patient baed authorization is overly burdonsome at this time.

Not related

Not Related. Author is commenting on functional description, which is reference material. The patient-based authorization is an example of how this function might be applied and not a requirement of how any EHR-S must implement this function.

Not

Not

Not

Not

Secure Data Exchange can take place without strong authentication methods in a secure environment. This function needs to be clear on when it is appropriate to implement strong methods

not related

Not related - comment seems to be directed at description. Authoring group will consider the addition of Strong Methods of authenticiation and the circumstances under which it should be used by the EHR-S.

An authentication is the basis of a secure data exchange.

Persuasive_W_Mod

Persuasive with Modification: Authoring group will add the link to I.1.1 See Also column. Not persuasive: Comment that "an authentication is the basis of a secure data exchange. The authoring group recognizes that authentication is required but recognize that it needs to be coupled with additional features as indicated in current function.

This section covers entity-to-entity authentication. Routing is a term with several meanings, most not accurate in this context.

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG. The authoring group will define the term "routing" in the EHR glossary to clarify its use in this function.

Persuasive – minor editorial or typos

Persuasive- Reflects the intentions of the authoring group. Will make change to statement. link 166, 385

Not

Not

Not

Recording each change to a record is unnecessary for supervisory audit trails. This function should not include forensic style audit trails.

Not Persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning for this ballot. Link 167, 386

Synchronization of health record data across different EHR-S should be better defined in the future (e.g., data ownership).

Persuasive_W_Mods

Persuasive with Modification: Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “ We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience.

Retrieve of patient health record is usually not part of registry and directory services' functions. It needs to be addressed with interchange standards.Location of the resource is overly burdonsome. The location function should not be required in this function.

Persuasive (accept part, reject part)

Persuasive in part: (1) Removing location as overburdonsome is Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function.  Persuasive: The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function. Link 169, 388

Not

Not

Not

Not

There are two aspects: Support distributed registry and directory services across different EHR-S (this might be for cross-link the entities managed in these EHR-S), and standard-based, network access to the services.

Persuasive (with modification), minor

Persuasive with Modification: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. We welcome your participation in our assessment of the DSTU experience with this function. Link 170 to 389 (dup)

(comment on the comment) The retrieve scenario in the example is inappropriate. Registry and directory services usually are implemented separately from the health record data interchange. Retrieve should be one of the functions in I.2.

Resolved in another section or functions

390 dups 171 Not Persuasive because authoring group's acceptance of proposed function statement in Record 169 "'Enable secure use of registry services and directories to uniquely identify and supply links for retrieval" resolves this issue."

Need to consider remote, sometimes connected or stand-alone offices.

Persuasive_W_Mods

Persuasive with modification: We will consider adding concept to function description during the DSTU assessment. Link 172, 391

Let this function focus on healthcare terminology management. Separate functions can be added to health informatics standards (e.g., decision-support algortihm) which may need this function. Clinical document architecture should be scoped into Interoperability standards.

Not Persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning. Link 173 with 392

Not

Not

Not

Standards are available for vocabularies, code sets and decision support syntax. Artifacts and decision support algorithms are not defined sufficiently clearly to allow them to be included in this function. CDA is covered already, in I.5.

Persuasive with Modification

Persuasive with Modification: The authoring group will add "decision support syntax" but will not delete decision support algorithms or clinical document architecture. The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning. By "standards for...decision support algorithms" we are referring to mathematical standards, not standards adopted by standards development organizations. CDA has vocabulary and codes that need to be addressed by this function. Link to 112, 289, 338, 364, 1040

The function is for system interoperability, using industry standards

Not Persuasive

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning.” The Authoring Group believes current wording is consistent with your proposed language.

Not Persuasive - changed in another area

Not Persuasive - (changed in another area) - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” Authoring group intended this function to include technology as well as data standards that support interoperability. For example, BPSS is not a data standard but may be a critical component of many interoperability solutions. Link 176, 395

Not

Not

Not

Not

Remove second bulletin point, which has been addressed in function I.4

Not Persuasive

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.”

Remove workflow integration (WfMC) as this belongs in I.7

Not related

Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of workflow management and application integration capability.

Not Persuasive

“Not Persuasive. Proposed title or statement is not the intent of the function. The authoring group intended that this function should provide standards-based application integration infrastructure for Direct Care and Supportive Functions.

The function can not require that all possible forms of interacting be supported, only that the directory should be used to assist with the picking of the most appropriate mode of interacting that the EHR-S supports.

Not Persuasive

Not Persuasive The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The authoring group feels that the statement captures a function that a specific EHR-S may claim conformance to or not as appropriate.

Not

Not

Not

Not

Not Persuasive

“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the capabilities in the function statement. The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning.”

Business rule management is not an infrastructure function in EHR-S. Business rules may be a function of direct care or supportive care, but the use of a rules engine is an implementaiton detail.

Not Persuasive

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function

workflow is not an infrastructure function in EHR-S. Workflow may be a function of direct care or supportive care, but the use of a workflow engine is an implementation detail. This is clearly into the implementation space as demonstrated by the last sentence of the statement.

Not Persuasive

Dup 227 Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Authoring group intended that this function provide the generic support for decision support functions stated in Direct Care and Supportive. Removing this function would adversely affect associated Direct Care and Supportive functions. Author’s proposal would adversely affect other functions that depend on this function.

Strongly recommend rationale column is filled out to support the requirements under Security.

persuasive, clarification - simple

Persuasive, clarification simple. Your comment reflects the authoring groups intent. We will add rationale. Link 184, 317

Not

Not

If it is felt that an entity such as access control permissions for another system is required, then it should be a separate function specification.

Persuasive with Modification

Persuasive with Mod - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning for this ballot. Authoring group will define the term "entity" in the future EHR glossary to include "users". Authoring group will consider comments during DSTU assessment. Link Action Item 148, 150, 185, 186, 187, 188

If it is felt that an entity such as access control permissions for another system is required, then it should be a separate function specification.

Persuasive with Modification

Persuasive with Mod - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning for this ballot. Authoring group will define the term "entity" in the future EHR glossary to include "users". Authoring group will consider comments during DSTU assessment. Link Action Item 148, 150, 185, 186, 187, 188

Not

Not

Not

If it is felt that an entity such as access control permissions for another system is required, then it should be a separate function specification.

Persuasive_W_Mods

Persuasive with Mod - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning for this ballot. Authoring group will define the term "entity" in the future EHR glossary to include "users". Authoring group will consider comments during DSTU assessment. Link Action Item 148, 150, 185, 186, 187, 188

If it is felt that an entity such as access control permissions for another system is required, then it should be a separate function specification.

Persuasive with Modification

Persuasive with Mod - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning for this ballot. Authoring group will define the term "entity" in the future EHR glossary to include "users". Authoring group will consider comments during DSTU assessment. Link Action Item 148, 150, 185, 186, 187, 188

Persuasive – clarification simple

Persuasive – clarification simple Link 153, 189, 300

Not

Not

Not

Audit trails should include location and/or device of entry, change etc. We find this information helpful in tracking incidents of inappropriate access. Also, audit trails should include viewing rules along with edits and modification rules. Viewing rules should include date, time, length, device / location viewed from and specifics of the information viewed.

Persuasive_W_Mods

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period and augment the description to include additional details as determined by the workgroup. “

I would argue that "security' if NOT a function as it lacks an action word.

Not Persuasive

Not Persuasive. Only Statements must start with a verb. The authoring groups have discretion as to whether a function name begins with a verb.

Authentication has to go beyond the 'initial login' as implied by the original statement.

Seems the 'Manage the sets' sentence would better serve in I.1.3. If it is used here to denote a relationship with the first statement, I would show it directly

Persuasive with Modification

Persuasive with Modification. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Not

PLEASE ADD single pt/multiple pt sec admin back into model.

It is critical that access control permissions be enabled in multiple point security administartion for large health care organizations that have full FTEs devoted to a component part of EHR secuirty administration. Persuasiv

e_W_Mods

Persuasive with Mods. The emergency access is covered under I.1.2. This statement will be augmented to include the concept of access to all components of the EHR-S. Will indicate "see also" link between I.1.2 and I.1.3. Need also to indicate that access may be controlled by OS in addition to application.

Not

Not

Not

Experience has taught us that authorizations control can be missed in building new EHR modules.

Provision made for the occasional or emergency need to access unauthorized EHR content, function, data. Not

persuasive

Persuasive with Mods. The emergency access is covered under I.1.2. This statement will be augmented to include the concept of access to all components of the EHR-S. Will indicate "see also" link between I.1.2 and I.1.3. Need also to indicate that access may be controlled by OS in addition to application.

Non-repudiation is a concept, a quality - not a functional statement. The function employed to achieve this quality is controlled attestation.

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

not persuasive

Not persuasive - this function reflects the author of information - such as a digital signature.

Not

no voter

Not No comment submitted

Clinical integrity, accountability of the mass of electronically stored clinical information is a critical mass in EHRs as are record attestation and closure. These are goals attained via functions listed Statement.

Not Persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.”

Clinical integrity and record accountability is also compromised if new clinical concepts are created for the EHR without concept dictionary and readily available standardized terminology.

Substantive?Substantive?

not Persuasive

Not

Not No comment submitted

Not No comment submitted

Not

The descrition of this function seems to imply record synchornization. If so, I would label it accordingly. I have included statements about many other required EHR synchronizations in my ballot response and need to avoid confusion.

Not Persuasive

Not Persuasive. Author’s proposed function name would alter the function. Authoring group intended synchonization of applications and information artifacts in accordance with Direct Care and Support workflow requirements.

Far too general to ever get a meaningful priority in a profile. I think the intent is that any information that is exchanged should be exchanged securely, but it reads like an EHRS needs to be able to securely exchange its data with another EHRS.

persuasvie

Persuasive - Language can be updated to more clearly reflect intent of authoring group - Information exchanged should be exchanged securely.

Not

Not

Not

Not

No comment submitted

Vague. Unclear whether "in synch" simply means "connected" or something more complex.

Not Persuasive

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.”

Vague and over-reaching. The description indicates that this is really a decision support function. It is in any case far too general and, outside of its decision support related implications, not a core EHRS component.

Not Persuasive

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

It is not clear how I.1.5, secure data exchange, is even possible without secure routing. The functionlity expressed here is simply a subset of I.1.5

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Automated interface set up is over-reaching and not practical at this point.

Not Persuasive

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

Substantive?

Not

Not

Not

Not

Remove second bulletin point, which has been addressed in function I.4

Not Persuasive

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.”

Remove workflow integration (WfMC) as this belongs in I.7

Comment made on reference material – not persuasive

Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of workflow management and application integration capability.

Not Persuasive

“Not Persuasive. Proposed title or statement is not the intent of the function. The authoring group intended that this function should provide standards-based application integration infrastructure for Direct Care and Supportive Functions.

The function can not require that all possible forms of interacting be supported, only that the directory should be used to assist with the picking of the most appropriate mode of interacting that the EHR-S supports.

Not Persuasive

DUP 180 Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The authoring group feels that the statement captures the optionality suggested by the author: "The function can not require that all possible forms of interacting be supported, only that the directory should be used to assist with the picking of the most appropriate mode of interacting that the EHR-S supports."

Not

Not

Not

Not Persuasive

Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the capabilities in the function statement. The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning.”

Business rule management is not an infrastructure function in EHR-S. Business rules may be a function of direct care or supportive care, but the use of a rules engine is an implementaiton detail.

Already resolved, duplicate comment, canned text

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function."  

workflow is not an infrastructure function in EHR-S. Workflow may be a function of direct care or supportive care, but the use of a workflow engine is an implementation detail. This is clearly into the implementation space as demonstrated by the last sentence of the statement.

Not Persuasive

Dup 183 Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Authoring group intended that this function provide the generic support for decision support functions stated in Direct Care and Supportive. Removing this function would adversely affect associated Direct Care and Supportive functions. Author’s proposal would adversely affect other functions that depend on this function.

Not

Not

Negative Major Authentication refers to verifying that users are who they say they are. It does not pertain to the set of access control permissions.

Persuasive with Modification

Persuasive with Modifications. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Edit Should also refer to the entities

persuasvie, clarification simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Not

Not

no comment submitted

Not

Negative Minor Are Applications and sites equivalent to entities?

persuasive

Persuasive - will clarify language to indicate users and entities (including applications, sites, systems)

Edit Function Name should indicate the access is to medical record informatio. Could be confused with appointment availability.

not persuasive

Not persuasive: Authoring group will define personal health information to provide clarity on this issue in an EHR glossary. Link 99, 276, 325, 351, 1026.

Substantive?

EDIT "Send and receive EHR data securely" should be replaced with "Secure all modes of EHR data exchange"

Persuasive - clarification simple

“ Persuasive. Comments reflect intent of authoring group. Link items 101, 278, 327, 353, 1028

Not

no comment submitted

Not

Not No comment submitted

Negative Minor - Superfluous If the scope of coverage is corrected in i.1.3

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Substantive?

Comment How is this different from Entity Access Control? I.1.3

Not persuasive

Not persuasive - Access control deals with the ability to control which functions, modules or types of data an EHR-S user is allowed to utilize or view. Enforcement of confidentialy deals with complying to realm, organization and/or patient specified rules regarding the way in which patient related data is used and who is allowed to see the data. It is possible to have access control that does not enforce privacy rules.

not persuasive

Not

Not

Edit & Comment "proscribed" should be "prescribed". This function seems to only refer to documents, not all data in retention.

Persuasive – minor editorial or typos

Persuasive - Typographical error will be corrected

Comment It would be desirable to separate change/update journal information from access/retreival audit logs. ?definition of resource access and usage.

Persuasive (accept part, reject part)

Persuasive in part: (1) Not Persuasive: Author's suggestion that the function "separate change/update journal information from access/retrieval audit logs" is implementation specific. (2) Persuasive: We will define terms in a glossary. The definition will separate the concept of change-logging from other auditing because this is often provided by different component than auditing, and its administrative requirements are different than what is required for privacy/secuyrity auditing.

Not

Not

Not No comment submitted

Negative Minor Does not clearly distinguish patient data syncronization from system table/metadata reference files

Persuasive_W_Mods

Persuasive with Modification. Your comment has merit and will require further review. The authoring groupo will assess your recommendations as part of the upcoming DSTU assessment. We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience. Link 108, 285, 334. 360, 1036.

Negative Major Patient specific data exports are not addressed. The example is misleading with respect to EHR functionality. No provision is cited for IRB or equivalent oversight of the extraction process.

Not_Persuasive

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care and Supportive Sections. D 2.2.1.5 is intended to include IRB or equivalent oversight of the extraction process.

not Persuasive

Not No comment submitted

Not

Not

Not

not Persuasive

Negative Major The EHR should provide functionality to utilize standard terminology services. The specification of content should be a decision by the realm.

Persuasive (with modification), minor

Persuasive with Modification: The proposed changes to the function statement reflect the intent of the authoring group. In addition, relevant citations to vocabulary services standards will be added to the citation section. Link 112, 174, 289, 338, 364, 1040.

Negative Major If the previous element focuses on terminology services, issues of maint. And versioning are addressed.

Persuasive_W_Mod

Persuasive with Modification - Issue resolved with changes agreed to in I.4 and with a DSTU assessment review of the description of "version control." Link 113, 290, 339, 365, 1041

Negative Minor The functionality of accomodating mapped terms is in the EHR, the process of mapping itself is external to the EHR.

Not_Persuasive

Not Persuasive. Issue resolved with changes to I 4

Not

Not No comment submitted

Not No comment submitted

Not No comment submitted

Not No comment submitted

Edit Replace "automate" with "automated" in function statement

Persuasive – minor editorial or typos

Persuasive. Reflects intention of the authoring group

not persuasive

not persuasive

not persuasive

Not No comment submitted

Not

Wrong word Not

The last sentence is duplicated from I.1.2

Persuasive_W_Mods

Persuasive with Modifications. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Persuasive_W_Mods

Persuasive with Modification - Your comment has merit and will require further review during the DSTU assessment. This function deals with enforcement of privacy rules to ensure confidentiality. Authoring group intended to handled privacy rules in I.6 where they are included under business rules, but realm specificity of these concepts needs further analysis during the DSTU assessment. Link 128, 133, 143, 153, 154, 299, 310

Not

Not

proscribed -> prescribed Not

Not

Change to security mechanisms

Persuasive – clarification simple Link 153, 189, 300

Persuasive – minor editorial or typos

Persuasive - Reflects the intentions of the authoring group.

Persuasive – minor editorial or typos

Persuasive - Typographical error will be corrected

Ditto for all sections at this level

Persuasive (with modification), minor

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 303, 305, 306, 307, 308, 316

Not

Not

Not

Not

Not

Not No comment submitted

The parentheses around 'or disable' inappropriately downgrade this ability.

Persuasive – minor editorial or typos

Persuasive. Does not change intent of function to remove the parens around disable.

Ditto for all sections at this level

Persuasive (with modification), minor

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 303, 305, 306, 307, 308, 316

Ditto for all sections at this level

Persuasive (with modification), minor

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 303, 305, 306, 307, 308, 316

Ditto for all sections at this level

Persuasive (with modification), minor

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 303, 305, 306, 307, 308, 316

Ditto for all sections at this level

Persuasive (with modification), minor

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 303, 305, 306, 307, 308, 316

not Persuasive

Not

Not

Not

The existing wording is very provider-centric and does not fit the broad EHR access control model proposed in Australia where the default position is that the patient will control access to her/his EHR

Persuasive_W_Mod

Persuasive with Modification - Your comment has merit and will require further review during the DSTU assessment. This function deals with enforcement of privacy rules to ensure confidentiality. Authoring group intended to handled privacy rules in I.6 where they are included under business rules, but realm specificity of these concepts needs further analysis during the DSTU assessment. Link 128, 133, 143, 153, 154, 299, 310

While EHR may restrict information from patient access, it must also be available to other providers but be flagged so those providers also do not communicate the restricted information to the patient.

persuasive

Persuasive. Reflects the authoring group's intent. Link 375 and 311

If patient is unconscious while out of town, is there a way to determine which local, regional, or national registry contains the patient record?

Persuasive_W_Mods

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 312, 376

Not

Not

Like other industries, health needs to support electronic business collaboration. Interchange agreements needs to include the ability of distributed systems to establish business-to-business interoperability via registries for collaboration protocol profiles, business process specifications and support for negotiation of collaboration protocol agreements. Without this, the EHR will never support an NHII.

Persuasive_W_Mods

Persuasive with Mod - Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 313, 377

I.1.4 – Non Repudiation – The statement sounds more aimed toward access and transmission than a function of the EHR. I think there also should be a requirement that says an entry made to the EHR must be non-repudiated

Persuasive with Modification

Persuasive and agrees with intent of the authoring group. Can add language to I.1.7 to cover non-repudiation of entered records.

Spell out CCOW Not

Not

Not

Not

Just a typo Not Persuasive - typo

Not Persuasive

Not Persuasive. However, the Functional model should have a glossary that spells out all acronyms , defines the terms and points to resources related to the terms.

There is an inconsistency in text occurring in parent cells of a hierarchy - as in Direct Care. All rows must have sufficient explanatory material to provide a clear understanding.

persuasive, clarification - simple

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 303, 305, 306, 307, 308, 316

A rationale for each function and at all levels of the hierarchy would help clarify and better explain the function. A document with the potential significance to the industry as this one must have the rationale for every function clearly stated.

persuasive, clarification - simple

Persuasive, clarification simple. Your comment reflects the authoring groups intent. We will add rationale. Link 184, 317

Automated interface set up is over-reaching and not practical at this point.

Not Persuasive

DUP 219 Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

Persuasive – minor editorial or typos

Not

Not no comment submitted

Not

Doesn't this belong in the "direct care" chapter? It's not really an infrastructure component any more than the features described in the "direct care" chapter are. It falls, I think, into the "Operations management and communication" section of "direct care"

Not PersuasiveConsidered

“Not Persuasive". The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning. Authoring group intended that this function provide the generic support for functions stated in Direct Care and Supportive. Removing this function would adversely affect associated Direct Care and Supportive functions.

Negative Major Authentication refers to verifying that users are who they say they are. It does not pertain to the set of access control permissions.

Persuasive with Modification

Persuasive with Modifications. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Not

Not

Edit Should also refer to the entities

persuasvie, clarification simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Negative Minor Are Applications and sites equivalent to entities?

persuasive

Persuasive - will clarify language to indicate users and entities (including applications, sites, systems)

Not

no comment submitted

Not

Not

Edit Function Name should indicate the access is to medical record informatio. Could be confused with appointment availability.

not persuasive

Not persuasive: Authoring group will define personal health information to provide clarity on this issue in an EHR glossary. Link 99, 276, 325, 351, 1026.

Substantive?

EDIT "Send and receive EHR data securely" should be replaced with "Secure all modes of EHR data exchange"

Persuasive - clarification simple

“ Persuasive. Comments reflect intent of authoring group. Link items 101, 278, 327, 353, 1028

Negative Minor - Superfluous If the scope of coverage is corrected in i.1.3

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

no comment submitted

Not

Not No comment submitted

Substantive?

Comment How is this different from Entity Access Control? I.1.3

Not persuasive

Not persuasive - Access control deals with the ability to control which functions, modules or types of data an EHR-S user is allowed to utilize or view. Enforcement of confidentially deals with complying to realm, organization and/or patient specified rules regarding the way in which patient related data is used and who is allowed to see the data. It is possible to have access control that does not enforce privacy rules.

not Persuasive

Not

Not

Edit & Comment "proscribed" should be "prescribed". This function seems to only refer to documents, not all data in retention.

Persuasive – minor editorial or typos

Persuasive - Typographical error will be corrected

Comment It would be desirable to separate change/update journal information from access/retreival audit logs. ?definition of resource access and usage.

Persuasive (accept part, reject part)

Persuasive in part: (1) Not Persuasive: Author's suggestion that the function "separate change/update journal information from access/retrieval audit logs" is implementation specific. (2) Persuasive: We will define terms in a glossary. The definition will separate the concept of change-logging from other auditing because this is often provided by different component than auditing, and its administrative requirements are different than what is required for privacy/security auditing.

Not

Not

Not No comment submitted

Negative Minor Does not clearly distinguish patient data synchronization from system table/metadata reference files

Persuasive_W_Mods

Persuasive with Modification. Your comment has merit and will require further review. The authoring group will assess your recommendations as part of the upcoming DSTU assessment. We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience. Link 108, 285, 334. 360, 1036.

Negative Major Patient specific data exports are not addressed. The example is misleading with respect to EHR functionality. No provision is cited for IRB or equivalent oversight of the extraction process.

Not_Persuasive

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care and Supportive Sections. D 2.2.1.5 is intended to include IRB or equivalent oversight of the extraction process.

not Persuasive

Not No comment submitted

Not

Not

Not

not Persuasive

Negative Major The EHR should provide functionality to utilize standard terminology services. The specification of content should be a decision by the realm.

Persuasive (with modification), minor

Persuasive with Modification: The proposed changes to the function statement reflect the intent of the authoring group. In addition, relevant citations to vocabulary services standards will be added to the citation section. Link 112, 174, 289, 338, 364, 1040.

Negative Major If the previous element focuses on terminology services, issues of maint. And versioning are addressed.

Persuasive_W_Mod

Persuasive with Modification - Issue resolved with changes agreed to in I.4 and with a DSTU assessment review of the description of "version control." Link 113, 290, 339, 365, 1041

Negative Minor The functionality of accommodating mapped terms is in the EHR, the process of mapping itself is external to the EHR.

Not Persuasive

Not Persuasive - Issue resolved with changes agreed to in I.4

Not

Not No comment submitted

Not No comment submitted

Not no comment submitted

Not No comment submitted

Edit Replace "automate" with "automated" in function statement

Persuasive - minor editorial or typo

Persuasive. Reflects intention of the authoring group

not persuasive

not persuasive

not persuasive

Not No comment submitted

Not no comment submitted

Not

Negative Major Authentication refers to verifying that users are who they say they are. It does not pertain to the set of access control permissions.

persuasive, clarification simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Not

Not

Edit Should also refer to the entities

persuasive, clarification - simple

Persuasive. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 274, 323, 349, 1024.

Negative Minor Are Applications and sites equivalent to entities?

persuasive

Persuasive - will clarify language to indicate users and entities (including applications, sites, systems)

Not

no comment submitted

Not

Not

Edit Function Name should indicate the access is to medical record information. Could be confused with appointment availability.

not persuasive

Not persuasive: Authoring group will define personal health information to provide clarity on this issue in an EHR glossary. Link 99, 276, 325, 351, 1026.

Substantive?

EDIT "Send and receive EHR data securely" should be replaced with "Secure all modes of EHR data exchange"

Persuasive - clarification simple

“ Persuasive. Comments reflect intent of authoring group. Link items 101, 278, 327, 353, 1028

Negative Minor - Superfluous If the scope of coverage is corrected in i.1.3

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

no comment submitted

Not

Not No comment submitted

Substantive?

Comment How is this different from Entity Access Control? I.1.3

Not persuasive

Not persuasive - Access control deals with the ability to control which functions, modules or types of data an EHR-S user is allowed to utilize or view. Enforcement of confidentially deals with complying to realm, organization and/or patient specified rules regarding the way in which patient related data is used and who is allowed to see the data. It is possible to have access control that does not enforce privacy rules.

not Persuasive

Not

Not

Edit & Comment "proscribed" should be "prescribed". This function seems to only refer to documents, not all data in retention.

Persuasive – minor editorial or typos

Persuasive - Typographical error will be corrected

Comment It would be desirable to separate change/update journal information from access/retrieval audit logs. ?definition of resource access and usage.

Persuasive (accept part, reject part)

Persuasive in part: (1) Not Persuasive: Author's suggestion that the function "separate change/update journal information from access/retrieval audit logs" is implementation specific. (2) Persuasive: We will define terms in a glossary. The definition will separate the concept of change-logging from other auditing because this is often provided by different component than auditing, and its administrative requirements are different than what is required for privacy/security auditing.

Not

Not

Not no comment submitted

Negative Minor Does not clearly distinguish patient data synchronization from system table/metadata reference files

Persuasive_W_Mods

Persuasive with Modification. Your comment has merit and will require further review. The authoring group will assess your recommendations as part of the upcoming DSTU assessment. We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience. Link 108, 285, 334. 360, 1036.

Negative Major Patient specific data exports are not addressed. The example is misleading with respect to EHR functionality. No provision is cited for IRB or equivalent oversight of the extraction process.

Not_Persuasive

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care and Supportive Sections. D 2.2.1.5 is intended to include IRB or equivalent oversight of the extraction process.

not Persuasive

Not no comment submitted

Not

Not

Not

not Persuasive

Negative Major The EHR should provide functionality to utilize standard terminology services. The specification of content should be a decision by the realm.

Persuasive (with modification), minor

Persuasive with Modification: The proposed changes to the function statement reflect the intent of the authoring group. In addition, relevant citations to vocabulary services standards will be added to the citation section. Link 112, 174, 289, 338, 364, 1040.

Negative Major If the previous element focuses on terminology services, issues of maint. And versioning are addressed.

Persuasive_W_Mods

Persuasive with Modification - Issue resolved with changes agreed to in I.4 and with a DSTU assessment review of the description of "version control." Link 113, 290, 339, 365, 1041

Negative Minor The functionality of accommodating mapped terms is in the EHR, the process of mapping itself is external to the EHR.

Not Persuasive

Not Persuasive - Issue resolved with changes agreed to in I.4

Not

Not No comment submitted

Not No comment submitted

Not No comment submitted

Not No comment submitted

Edit Replace "automate" with "automated" in function statement

Persuasive - minor editorial or typo

Persuasive. Reflects intention of the authoring group

not persuasive

not persuasive

Not No comment submitted

Not

Not

Not

Automated interface set up is way ahead of its time.

Not Persuasive

DUP 219 Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

While EHR may restrict information from patient access, it must also be available to other providers but be flagged so those providers also do not communicate the restricted information to the patient.

persuasive

Persuasive. Reflects the authoring group's intent. Link 375 and 311

If patient is unconscious while out of town, is there a way to determine which local, regional, or national registry contains the patient record?

Persuasive (with modification), minor

Persuasive with Mod: Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 312, 376

Not

Not

Like other industries, health needs to support electronic business collaboration. Interchange agreements needs to include the ability of distributed systems to establish business-to-business interoperability via registries for collaboration protocol profiles, business process specifications and support for negotiation of collaboration protocol agreements. Without this, the EHR will never support an NHII.

Persuasive_W_Mods

Persuasive with Mod - Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. Link 313, 377

persuasive, clarification - simple

Persuasive, clarification simple: Accept the comment that the audit of entity authentication attempts will be added to I.2.2 and is consistent with the intent of the authoring group. Link 130, 159, 378

Not

Not

Not

Not

Not

I.1.1 needs to include two things: 1) Ability to authenticate a user / an entity (establishment of an identity), and 2) ability of manage a database of users and entities, and authentication credentials.

Persuasive with Modification

Persuasive with Mod. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Context-based authorization is too burdensome. Definition of contexts is too broad (in funct. description)

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Example of user-based authorization is really patient-based authorization - should be changed to user-based example. Patient bade authorization is overly burdensome at this time.

not persuasive e

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Secure Data Exchange can take place without strong authentication methods in a secure environment. This function needs to be clear on when it is appropriate to implement strong methods

not related

Not related - comment seems to be directed at description. Future DSTU discussion can address addition of Strong Methods of authentication and when it is appropriate.

An authentication is the basis of a secure data exchange.

not Persuasive

Not persuasive - authentication is required but needs to be coupled with additional features as indicated in current function

Not

Not

Not

Not

This section covers entity-to-entity authentication. Routing is a term with several meanings, most not accurate in this context.

Not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Persuasive – minor editorial or typos

Persuasive- Reflects the intentions of the authoring group. Will make change to statement. link 166, 385

Recording each change to a record is unnecessary for supervisory audit trails. This function should not include forensic style audit trails.

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning for this ballot. Link 167, 386

Synchronization of health record data across different EHR-S should be better defined in the future (e.g., data ownership).

Persuasive_W_Mods

Persuasive with Mod. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “ We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience.

Not

Not

Not

Retrieve of patient health record is usually not part of registry and directory services' functions. It needs to be addressed with interchange standards.Location of the resource is overly burdonsome. The location function should not be required in this function.

Persuasive (accept part, reject part)

Persuasive in part: (1) Removing location as overburdonsome is Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function.  Persuasive: The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function. Link 169, 388

There are two aspects: Support distributed registry and directory services across different EHR-S (this might be for cross-link the entities managed in these EHR-S), and standard-based, network access to the services.

Persuasive_W_Mods

Persuasive with Modification - Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development. We welcome your participation in our assessment of the DSTU experience with this function. Link 170 and 389.

(comment on the comment) The retrieve scenario in the example is inappropriate. Registry and directory services usually are implemented separately from the health record data interchange. Retrieve should be one of the functions in I.2.

Already resolved, duplicate comment, canned text

Not Persuasive because authoring group's acceptance of proposed function statement in Record 169 "'Enable secure use of registry services and directories to uniquely identify and supply links for retrieval" resolves this issue." Link 175 and 390

Not

Not

Not

Not

Need to consider remote, sometimes connected or stand-alone offices.

Persuasive with Mode

Persuasive with modification. The authoring group will consider adding concept to function description during the DSTU assessment. Link 172, 391

Let this function focus on healthcare terminology management. Separate functions can be added to health informatics standards (e.g., decision-support algortihm) which may need this function. Clinical document architecture should be scoped into Interoperability standards.

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning. Link 392, 174

Standards are available for vocabularies, code sets and decision support syntax. Artifacts and decision support algorithms are not defined sufficiently clearly to allow them to be included in this function. CDA is covered already, in I.5.

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning. Link 174, 393

The function is for system interoperability, using industry standards

Not Persuasive

Dup 175 Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning.” The Authoring Group believes current wording is consistent with your proposed language. Link 175 and 394

Not

Not

Not Persuasive - changed in another area

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG. Authoring group intended this function to include technology as well as data standards that support interoperability. For example, BPSS is not a data standard but may be a critical component of many interoperability solutions. and meaning of the EHR SIG. Authoring group agrees with suggested change of "Interchange Standards" to "Standards-based Interchange, per discussions during reconciliation. Link 176 and 395

The last sentence is duplicated from I.1.2

Persuasive with Modification

Persuasive with Modifications. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Not

Not

Not

Far too general to ever get a meaningful priority in a profile. I think the intent is that any information that is exchanged should be exchanged securely, but it reads like an EHRS needs to be able to securely exchange its data with another EHRS.

persuasive

Persuasive - Language can be updated to more clearly reflect intent of authoring group - Information exchanged should be exchanged securely. Link Item 215 with 957

Vague. Unclear whether "in synch" simply means "connected" or something more complex.

Not_Persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.”

Vague and over-reaching. The description indicates that this is really a decision support function. It is in any case far too general and, outside of its decision support related implications, not a core EHRS component.

Not Persuasive

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

Not

Not

Persuasive

Persuasive: We will incorporate the concepts in the appropriate section of the I 2.2 description.

Eliminate this "function". As stated it is vaguely-defined and not ready to be part of any standard. Also, requiring standardized application programming interfaces is a procedural programming jargon technique, and is not conformant with OO concepts or other potentially worthwhile technology realization choices. Or enhance to support multiple types of integration appropriate to the process being performed.

Persuasive_W_Mods

Persuasive with Modifications: Your comment has merit and will require further review by the authoring group during the DSTU assessmenet. We are particularly interested in your suggestion that this function be enhanced to support multiple types of integration appropriate to the process being performed and welcome your input into the DSTU refinement of this function. Please note that we include one example of such standards, meaning that there are likely other applicable standards in this area that exist or are under development.

Not

Not

Not

Not no comment submitted

Split this into three functions: establish and maintain registray values, query registry, and negotiatie binding among messaging partners. Allow for in-band and out-of-band binding.

Persuasive_W_Mods

Persuasive with Modifications: Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “ We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience.

These capabilities are covered in other sections, clinical decision support. Either eliminate or reference.

Persuasive (accept part, reject part)

Persuasive. Authoring groups intend to link all dependencies among the Sections. Author's proposal to eliminate the function is “Not Persuasive" because it would adversely affect other functions that depend on this function

Workflow covers multiple concepts and lacks a commonly-accpeted defintion. It is arguably a buzzword.

Persuasive (accept part, reject part)

Persuasive in part. The Functional Name was unclear. Authoring group will make name change. Characterization of function is Not Persuasive. This function may be a stretch-goal, however it is believed that the functions are a superset of all functions that can or should be provided by EHR-S’ (both now and in the future). This function was carefully considered and approved by the SIG and identified as Essential now or Essential Future for one or more care settings/profiles. Author's proposal would adversely affect other functions, which may also be future functions that depend on, or are related to, this function.

Not

Not

Negative Major Authentication refers to verifying that users are who they say they are. It does not pertain to the set of access control permissions.

Persuasive with Modification

Persuasive with Modifications. Your comment reflects the authoring groups intent. We will move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." We will develop definitions of chain of trust agreements and authentication, which are needed for this function. We will consider suggested functional detail during the DSTU assessment. Link 96,123, 140, 160,194, 273, 298, 322, 348, 379, 923, 1023

Edit Should also refer to the entities

persuasvie, clarification simple

Persuasive, clarification simple. Suggestion reflects the authoring group's intent and the language will be updated to reflect users and entities. Link 97, 134, 135, 274, 323, 349, 1024.

Not

Not

no comment submitted

Not

Negative Minor Are Applications and sites equivalent to entities?

persuasive

Persuasive - will clarify language to indicate users and entities (including applications, sites, systems)

Edit Function Name should indicate the access is to medical record informatio. Could be confused with appointment availability.

not persuasive

Not persuasive: Authoring group will define personal health information to provide clarity on this issue in an EHR glossary. Link 99, 276, 325, 351, 1026.

Substantive?

EDIT "Send and receive EHR data securely" should be replaced with "Secure all modes of EHR data exchange"

Persuasive - clarification simple

“ Persuasive. Comments reflect intent of authoring group. Link items 101, 278, 327, 358, 1028

Not

no comment submitted

Not

Not no comment submitted

Negative Minor - Superfluous If the scope of coverage is corrected in i.1.3

not persuasive

Not Persuasive - The wording and concept in question as detailed by your suggestion,  was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG

Substantive?

Comment How is this different from Entity Access Control? I.1.3

not persuasive

Not persuasive - Access control deals with the ability to control which functions, modules or types of data an EHR-S user is allowed to utilize or view. Enforcement of confidentialy deals with complying to realm, organization and/or patient specified rules regarding the way in which patient related data is used and who is allowed to see the data. It is possible to have access control that does not enforce privacy rules.

not Persuasive

Not

Not

Edit & Comment "proscribed" should be "prescribed". This function seems to only refer to documents, not all data in retention.

Persuasive – minor editorial or typos

Persuasive - Typographical error will be corrected

Comment It would be desirable to separate change/update journal information from access/retreival audit logs. ?definition of resource access and usage.

Persuasive (accept part, reject part)

Persuasive in part: (1) Not Persuasive: Author's suggestion that the function "separate change/update journal information from access/retrieval audit logs" is implementation specific. (2) Persuasive: We will define terms in an EHR glossary. The definition will separate the concept of change-logging from other auditing because this is often provided by different component than auditing, and its administrative requirements are different than what is required for privacy/secuyrity auditing.

Not

Not

Not no comment submitted

Negative Minor Does not clearly distinguish patient data syncronization from system table/metadata reference files

Persuasive_W_Mods

Persuasive with Modification. Your comment has merit and will require further review. The authoring groupo will assess your recommendations as part of the upcoming DSTU assessment. We would welcome your participation in our assessment so that we can explore your suggestion in light of DSTU experience. Link 108, 285, 334. 360, 1036.

Negative Major Patient specific data exports are not addressed. The example is misleading with respect to EHR functionality. No provision is cited for IRB or equivalent oversight of the extraction process.

not persuasive

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care and Supportive Sections. D 2.2.1.5 is intended to include IRB or equivalent oversight of the extraction process.

not Persuasive

Not no comment submitted

Not

Not

Not

not Persuasive

Negative Major The EHR should provide functionality to utilize standard terminology services. The specification of content should be a decision by the realm.

Persuasive (with modification), minor

Persuasive with Modification: The proposed changes to the function statement reflect the intent of the authoring group. In addition, relevant citations to vocabulary services standards will be added to the citation section. Link 112, 174, 289, 338, 364, 1040.

Negative Major If the previous element focuses on terminology services, issues of maint. And versioning are addressed.

Persuasive_W_Mods

Persuasive with Modification - Issue resolved with changes agreed to in I.4 and with a DSTU assessment review of the description of "version control." Link 113, 290, 339, 365, 1041

Negative Minor The functionality of accomodating mapped terms is in the EHR, the process of mapping itself is external to the EHR.

Not Persuasive

Not Persuasive. Issue resolved with changes to I 4

Not

Not no comment submitted

Not no comment submitted

Not no comment submitted

Not no comment submitted

Edit Replace "automate" with "automated" in function statement

Persuasive - minor editorial or typo

Persuasive. Reflects intention of the authoring group

not persuasive

not persuasive

Not no comment submitted

Action item - move ISO refernce to citation column and include #

Action Item (1) : move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2) : Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For example, an EHR-S might only allow supervising providers context authorization to attest to entries

Action Item - Change to: "'Verify and enforce access control to EHR information and functions for users and entities (including applications, sites, systems) to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Information"' in the EHR glossary that differentiates types of personal health information and distinquishes clinical from demographic and administrative components such as appointment scheduling and copayments . Propose that the definition be a meaningful combination of definitions used in other realms and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health informationis information that is a subset of healthinformation, including demographicinformation collected from an individual,and: (1) Is created or received by a health careprovider, health plan, employer, or health careclearinghouse; and (2) Relates to the past, present, or futurephysical or mental health or condition of anindividual; the provision of health care to anindividual; or the past, present, or futurepayment for the provision of health care to anindividual; and (i) That identifies the individual; or(ii) With respect to which there is areasonable basis to believe the informationcan be used to identify the individual.

Action item: Change statement to "Secure all modes of EHR data exchange"

Action Item - fix typo

Candidate Issue: During DSTU we will define all relevant types of auditing and clearly distinguish their functions. We will consider whether these functions need to be differentiated in the functional model.

Candidate Issue: This function was a "roll-up" of several initially distinguished functions. During the DSTU assessment, the authoring group will consider whether to create separate functions for the reference data synchronization and patient data synchronization.

Action Item (1): Change the function statement to '"Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support syntax and algorithms, and clinical document architecture. Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification." Commenters will withdraw negatives if these changes are made. Action Item (2): Referred to Publishing: Commenters' reguests that the overview reinforce the notion that the model supports the ability to constrain EHR functions in specific EHR-S. Action Item (3): Add relevant citations to vocabulary services standards to the citation section. Action Item (4): Add CPT and X12 to Functional Descripition: Change description to: "'Examples that EHR-S applications need to support are a consistent set of terminologies such as: LOINC, SNOMED, ICD-10, CPT and messaging standards such as X12 and HL7. Vocabularies may be provided through a terminology service internal or external to the EHR-S."

Candidate Issue: During DSTU we should also consider the following: The term "version control" covers multiple use cases. In its current form, it is a vaguely-defined "function". The use cases need to be stated as separate functions. For example, the functions for accepting and applying updates, mapping among versions, distrbuting changes, query translation to accomodate the existience of mutlple versions, communicating the adoption of new version to central registries, etc. This is simply too large an problem domain to be covered by one functional name with a brief description. Commenters' agree to withdraw negatives.

Action Item - typo

Action Item: cross reference to S 2.2 Candidate Issue. During the DSTU we should also ensure that related functional issues such as asynchronous delayed assembly response and the query, response and response-assembly functions are addressed in this function or as children of this function.

Candidate Issue . Authoring group intends to consider whether to split this function to differentiate the administration of business rules from the query response binding use of business rules.Action Item (1) : move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2) : Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Candidate Issue: Need to evaluate adequacy of the name for the function described in the statement in light of DSTU assessment.

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)."

Action item - Change name to "Information Attestation" and statement to "'Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing information" to indicate that attestation is for information, reflects the intent of the authoring group.

Candidate Issue: During the DSTU assessment, the authoring group will evaluate realm specific meanings for privacy and confidentiality to develop best practices for stating functions in a way that recognizes realm specific usages of these terms. Need to support realm specific rights of patients to manage, access and control their personal health information.

Action Item: Change Statement to: Manage EHR information across EHR-S applications byEnsuring that clinical information entered by providers is a valid representation of clinical notes;Ensuring that clinical information is accurate and complete according to clinical rules andtracking amendments to clinical documents. Ensure that clinical information entered by or on behalf of patients is accurately represented. Candidate Issue: During DSTU assessment, the authoring group will consider whether this function needs to be differentiated into subfunctions in light of commenter's suggestions.

Action Item typographical error will be corrected

Action Item: Change I.2.2 Function Statement to Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange and to audit of consent status management to (to support DC.1.5.1) and to entity authentication attempts. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S.Action Item - Change name to Standards-based Interoperability

Candidate Issue: During the DSTU assessment, the authoring group will evaluate realm specific meanings for privacy and confidentiality to develop best practices for stating functions in a way that recognizes realm specific usages of these terms. Need to support realm specific rights of patients to manage, access and control their personal health information.

Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For

Action Item: Change Function Statement to "'Map or translate local terminology, codes and formats to standard terminology, codes, and formats to comply with health informatics standards." Candidate issue (1): Consider whether the capacity to translate terminology, codes and formats should be specified in sub-functions during the DSTU assessment. Candidate Issue (2): Consider whether there should be a requirement on participating systems that they use a defined set of standard codes/versions to participate in an EHR federation.

Action Item: Change statement to: "Provide automated health delivery processes and seamless exchange of key clinical and administrative information through standards-based solutions." Candidate Issue: During the DSTU assessment consider whether to separate interoperability technology standards from standards relating to the interfaces that support interoperability but are also needing management in accordance with health informatics principles and terminology support expressed by I 4.

Action Item per agreement in San Antonio Reconciliation - Change occurences of "_ Standards" to "Standards-based_" For example, I.5.2 should be changed from "Application Integration Standards" to "Standards-based Application Integration" Ditto for "Interchange Standards" to "Standards-based Interchange" . Candidate Issue: Authoring Group was instructed to roll up the functions for the DSTU, which included roll up of Messaging standards. During the DSTU period we will assess the grandularity by which this function should be conveyed. Authoring group will consider whether the wide range of issues covered in I.5.1's functional description can reasonably be rolled-up into a single function name and statement.

Action Item (1) : move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2) : Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Candidate Issue: During the DSTU assessment, the authoring group will evaluate realm specific meanings for privacy and confidentiality to develop best practices for stating functions in a way that recognizes realm specific usages of these terms. Need to support realm specific rights of patients to manage, access and control their personal health information.

Action Item: Change Statement to: Manage EHR information across EHR-S applications byEnsuring that clinical information entered by providers is a valid representation of clinical notes;Ensuring that clinical information is accurate and complete according to clinical rules andtracking amendments to clinical documents. Ensure that clinical information entered by or on behalf of patients is accurately represented. Candidate Issue: During DSTU assessment, the authoring group will consider whether this function needs to be differentiated into subfunctions in light of commenter's suggestions.

Candidate issue - Authoring group will clarify during DSTU assessment how to capture both the archiving and destruction functions most appropriately, including the need to accomModificationate the provision of URIs that point to large documents in federated repositories, and the need to standardize record retention for participants in a federation of repositories. This includes purging and movement from on-line to archival storage. Authoring group will consider how best to structure this function to meet agreed upon changes. Commenter agreed to withdraw negative

Candidate Issue: During the DSTU, the authoring group will consider whether further differentiation of functions, including those suggested by the commenter, are required in order to fully describe this EHR-S capability.

Candidate issue: Authoring Group was instructed to roll up the functions for the DSTU, which included roll up of Messaging standards. During the DSTU period we will assess the grandularity by which this function should be conveyed. Authoring group will consider whether the wide range of issues covered in I.5.1's functional description can reasonably be rolled-up into a single function name and statement.

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)."

Action Item: List ISO standard 18307 referenced by the decription in the citation. Candidate Issue: During DSTU determine consistent criteria for including citations and a process for refreshing citations entered.

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)."

Action Item: Fix typo

Action Item: Change Statement to: "Enforce applicable jurisdiction's patient privacy rules as they apply to various parts of the EHR-S through the implementation of security mechanisms." [Link to Item 153 and 300, which changed statement language as well]

Candidate Issue: During the DSTU assessment, the authoring group will evaluate realm specific meanings for privacy and confidentiality to develop best practices for stating functions in a way that recognizes realm specific usages of these terms. Need to support realm specific rights of patients to manage, access and control their personal health information.

Action item - Change name to "Information Attestation" and statement to "'Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing information" to indicate that attestation is for information, reflects the intent of the authoring group.Candidate Issue - During DSTU assessment, we will also consider following discussion from reconciliation process: Attestation is one of a class of signature acts that can be done to a docment. Reference ASTM E-1792 for a complete list. I don't think we need a separate function for each of the 18 enumerated signature types in E-1792; we can use this fucntion for all of them *if* we also include the appropriate signature-purpose vocabulary.

Action item - Change name to "Information Attestation" and statement to "'Manage electronic attestation of information including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing information" to indicate that attestation is for information, reflects the intent of the authoring group.

Action Item: Change Statement to: Manage EHR information across EHR-S applications byEnsuring that clinical information entered by providers is a valid representation of clinical notes;Ensuring that clinical information is accurate and complete according to clinical rules andtracking amendments to clinical documents. Ensure that clinical information entered by or on behalf of patients is accurately represented. Candidate Issue: During DSTU assessment, the authoring group will consider whether this function needs to be differentiated into subfunctions in light of commenter's suggestions.

Action Item: Change I.2.2 Function Statement to "Provide audit trail capabilities for resource access and usage indicating the author, the Modificationification (where pertinent), and the date/time at which a record was created, Modificationified, viewed, extracted, or deleted. Audit trails extend to information exchange and to audit of consent status management (to support DC.1.5.1) and to entity authentication attempts. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S."

Action Item (1) : move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2) : Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Candidate Issue: During the DSTU assessment, the authoring group will consider the addition of Strong Methods of authenticiation and the circumstances under which it should be used by the EHR-S.

Action Item: Add the link to I.1.1 See Also column

Action Item: The authoring group will define the term "routing" in the EHR glossary to clarify its use in this function.

Action item - Change I.2.1 to read: "Retain, ensure availability, and destroy health record information according to organizational standards. This includes: Retaining all EHR data and clinical documents for the time period designated by policy or legal requirement; Retaining inbound docum..."

Candidate Issue: During the DSTU assessment, the authoring group will consider whether recording each change to a record is unnecessary for supervisory audit trails and whether this function should not include forensic style audit trails.

Candidate Issue: During the DSTU assessment, the authoring group consider the different use-cases (for example, data ownership, asynchronous operation, and store/forward of synchronization messages to accomodate off-line repositories and registries) that may need to be defined as distinct functions. We understand that it is unlikely that all functional elements would be provided by a single component. We will also consider the need to separate the roles and functions of registries/directories and repositories as they relate to synchronization.

Action Item: Change Statement to "'Enable secure use of registry services and directories to uniquely identify and supply links for retrieval and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes."

Candidate Issue - During the DSTU, the authoring group will consider whether to differentiate two aspects to this function as sub-functions: Support for (1) distributed registry and directory services across different EHR-S (this might be for cross-link the entities managed in these EHR-S), and (2) standard-based, network access to the services.

Candidate Issue: During DSTU, the authoring group will consider whether to conceptually migrate the entity name spaces of the local registry and directory services in an EHR-S with the similar services in other EHR systems through standardized communication interfaces. The authoring group may also consider stating a minimal functional expecation for matching records, e.g., what data fields to use, how to resolve ambiguities, administrative transactions to correct false matches, and propogate matches and corrections to false matches among registries

DUP 394

Action Item: Change the function statement to '"Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support syntax and algorithms, and clinical document architecture. Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification."

DUP 395 Action Item per agreement in San Antonio Reconciliation - Change occurences of "_ Standards" to "Standards-based_" For example, for I.5 replace "Interchange Standards" with "Standards-based Interchange"

DUP 221

Dup 223

DUP 224

DUP 225

Action Item: complete rationales for all II functions: Support delivery ofeffective healthcare; patient safety; improve efficiency

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)." Candidate Issue: During the DSTU assessment, the authoring group will consider whether this concepts within this function should be differentiated.

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)." Candidate Issue: During the DSTU assessment, the authoring group will consider whether this concepts within this function should be differentiated.

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)." Candidate Issue: During the DSTU assessment, the authoring group will consider whether this concepts within this function should be differentiated.

Action Item - Add to Glossary: Use HL7 Definition of "Entity=A physical thing, group of physical things or an organization capable of participating in Acts, while in a role.Discussion: An entity is a physical object that has, had or will have existence. The only exception to this is Organization, which while not having a physical presence, fulfills the other characteristics of an Entity. The Entity hierarchy encompasses living subjects (including human beings), organizations, material, and places and their specializations. It does not indicate the roles played, or acts that these entities participate in. Constraints: It does not include events/acts/actions, or the roles that things can play (e.g. patient, provider)." Candidate Issue: During the DSTU assessment, the authoring group will consider whether this concepts within this function should be differentiated.

Action Item: Change Statement to: "Enforce applicable jurisdiction's patient privacy rules as they apply to various parts of the EHR-S through the implementation of security mechanisms." [Link to Item 153 and 300, which changed statement language as well]

Candidate Issue - During DSTU, authoring group will consider whether audit trails should include location and/or device of entry, change etc. We find this information helpful in tracking incidents of inappropriate access. The authoring group will consider whetheraudit trails should include viewing rules along with edits and modification rules. Viewing rules should include date, time, length, device / location viewed from and specifics of the information viewed.

Action Item (1) : move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2) : Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Action Item (1): Change statement to: "'Verify and enforce access control to all EHR-S components, EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner." Action Item (2) Add "See Also" link between I.I.2 and I.1.3. Action Item (3) Change Description to: "'This is a fundamental function of EHR-S applications. To ensure access is controlled, the EHR-S applications and operation systems will perform an identity lookup of users or application for any operations that require it (authentication, authorization, secure routing, querying, etc.) and enforce the system and information access rules that have been defined.

Action Item (1): Change statement to: "'Verify and enforce access control to all EHR-S components, EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner." Action Item (2) Add "See Also" link between I.I.2 and I.1.3. Action Item (3) Change Description to: "'This is a fundamental function of EHR-S applications. To ensure access is controlled, the EHR-S applications and operation systems will perform an identity lookup of users or application for any operations that require it (authentication, authorization, secure routing, querying, etc.) and enforce the system and information access rules that have been defined.

need clarification

recommendation for change is missing

Action item - Change description to: "'Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHRS entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHRS or external to the EHRS." Candidate issue - Consider clarification requested by the commenter

DUP 177

Dup 223

DUP 180

DUP 181

Action Item (1) : Move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2): Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For

information, including demographic

Action Item - Change to: "'Verify and enforce access control to EHR information and functions for users and entities (including applications, sites, systems) to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.Action item - Include a definition of "Personal Health Information"' in the EHR glossary that differentiates types of personal health information and distinquishes clinical from demographic and administrative components such as appointment scheduling and copayments . Propose that the definition be a meaningful combination of definitions used in other realms and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health informationis information that is a subset of healthinformation, including demographicinformation collected from an individual,and: (1) Is created or received by a health careprovider, health plan, employer, or health careclearinghouse; and (2) Relates to the past, present, or futurephysical or mental health or condition of anindividual; the provision of health care to anindividual; or the past, present, or futurepayment for the provision of health care to anindividual; and (i) That identifies the individual; or(ii) With respect to which there is areasonable basis to believe the informationcan be used to identify the individual.

Action item - Change statement to "Secure all modes of EHR data exchange"

(ii) With respect to which there is a

Action Item - fix typo

Candidate Issue: During DSTU we will define all relevant types of auditing and clearly distinguish their functions. We will consider whether these functions need to be differentiated in the ballot.

Candidate Issue: This function was a "roll-up" of several initially distinguished functions. During the DSTU assessment, the authoring group will consider whether to create separate functions for the reference data synchronization and patient data synchronization.

Authors' agree to withdraw negatives

Action Item (1): Change the function statement to '"Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support syntax and algorithms, and clinical document architecture. Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification." Commenters will withdraw negatives if these changes are made. Action Item (2): Referred to Publishing: Commenters' reguests that the overview reinforce the notion that the model supports the ability to constrain EHR functions in specific EHR-S. Action Item (3): Add relevant citations to vocabulary services standards to the citation section. Action Item (4): Add CPT and X12 to Functional Descripition: Change description to: "'Examples that EHR-S applications need to support are a consistent set of terminologies such as: LOINC, SNOMED, ICD-10, CPT and messaging standards such as X12 and HL7. Vocabularies may be provided through a terminology service internal or external to the EHR-S."

Candidate Issue: During DSTU we should also consider the following: The term "version control" covers multiple use cases. In its current form, it is a vaguely-defined "function". The use cases need to be stated as separate functions. For example, the functions for accepting and applying updates, mapping among versions, distrbuting changes, query translation to accomodate the existience of mutlple versions, communicating the adoption of new version to central registries, etc. This is simply too large an problem domain to be covered by one functional name with a brief description. Commenters' agree to withdraw negatives.

Action Item - typo

Action Item (1) : Move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2): Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Candidate Issue: During the DSTU assessment, the authoring group will evaluate realm specific meanings for privacy and confidentiality to develop best practices for stating functions in a way that recognizes realm specific usages of these terms. Need to support realm specific rights of patients to manage, access and control their personal health information.

Action Item - typo

Action Item: Change Statement to: "Enforce applicable jurisdiction's patient privacy rules as they apply to various parts of the EHR-S through the implementation of security mechanisms." [Link to Item 153 and 300, which changed statement language as well]

Action Item - change name - Data Retention, Availability and Destruction

Candidate Issue: During DSTU assessment, the authoring group will consider how best to structure the II section and whether to differentiate functions contained in this function statement.

Action Item - remove parentheses

Candidate Issue: During DSTU assessment, the authoring group will consider how best to structure the II section and whether to differentiate functions contained in this function statement.

Candidate Issue: During DSTU assessment, the authoring group will consider how best to structure the II section and whether to differentiate functions contained in this function statement.

Candidate Issue: During DSTU assessment, the authoring group will consider how best to structure the II section and whether to differentiate functions contained in this function statement.

Candidate Issue: During DSTU assessment, the authoring group will consider how best to structure the II section and whether to differentiate functions contained in this function statement.

Candidate Issue: During the DSTU assessment, the authoring group will evaluate realm specific meanings for privacy and confidentiality to develop best practices for stating functions in a way that recognizes realm specific usages of these terms. Need to support realm specific rights of patients to manage, access and control their personal health information.

Action item: Change non-normative description to: "A healthcare professional will be able to manage a patient’s ability to view his/her EHR, and to have other providers accessing the EHR alerted to any constraints on patient access placed by this provider. Typically, a patient has the right to view much of his/her EHR. However, a healthcare provider may sometimes need to prevent a patient (or guardian) from viewing parts of the record. For example, a patient receiving psychiatric care might harm himself (or others) if he reads the doctor's evaluation of his condition. Furthermore, reading the doctor's therapy-plan might actually cause the plan to fail."

Candidate Issue: During the DSTU assessment, the authoring group will ensure that the functional model addresses the issue of determining which registry a patient's directory information is located in. This may not be a function of the EHR-S but the EHR-S functional model definitely needs to account for where and how this issue will be resolved in each realm.

Candidate Issue: During the DSTU assessment, the authoring group will consider whether interchange agreements need to include the ability of distributed systems to establish business-to-business interoperability via registries for collaboration protocol profiles, business process specifications and support for negotiation of collaboration protocol agreements.

Action Item- Change statement to include non-repudiation of receipt: " 'Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated, received or authorized by that user." This is expressed in the description but not the statement. Change description to include non-repudiation of entry: " Non-repudiation ensures that an entered or a transferred message has been entered, sent, or received by the parties claiming to have entered, sent or received the message. Non-repudiation is a way to guarantee that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message. Non-repudiation can be achieved through the use of a: > Digital signature -- which serves as a unique identifier for an individual (much like a written signature). > Confirmation service -- which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent and/or received). > Timestamp -- which proves that a document existed at a certain date and time.

Action Item

Candidate Issue: During DSTU assessment, the authoring group will consider how best to structure the II section and whether to differentiate functions contained in this function statement.

Action Item: complete rationales for all II functions: Support delivery ofeffective healthcare; patient safety; improve efficiency

Action Item (1) : Move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2): Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For

Action Item - Change to: "'Verify and enforce access control to EHR information and functions for users and entities (including applications, sites, systems) to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Action item - Include a definition of "Personal Health Information"' in the EHR glossary that differentiates types of personal health information and distinquishes clinical from demographic and administrative components such as appointment scheduling and copayments . Propose that the definition be a meaningful combination of definitions used in other realms and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health informationis information that is a subset of healthinformation, including demographicinformation collected from an individual,and: (1) Is created or received by a health careprovider, health plan, employer, or health careclearinghouse; and (2) Relates to the past, present, or futurephysical or mental health or condition of anindividual; the provision of health care to anindividual; or the past, present, or futurepayment for the provision of health care to anindividual; and (i) That identifies the individual; or(ii) With respect to which there is areasonable basis to believe the informationcan be used to identify the individual.

Action item - Change statement to "Secure all modes of EHR data exchange"

Action Item - typo

Candidate Issue: During DSTU we will define all relevant types of auditing and clearly distinguish their functions. We will consider whether these functions need to be differentiated in the ballot.

Candidate Issue: This function was a "roll-up" of several initially distinguished functions. During the DSTU assessment, the authoring group will consider whether to create separate functions for the reference data synchronization and patient data synchronization.

Action Item (1): Change the function statement to '"Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support syntax and algorithms, and clinical document architecture. Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification." Commenters will withdraw negatives if these changes are made. Action Item (2): Referred to Publishing: Commenters' reguests that the overview reinforce the notion that the model supports the ability to constrain EHR functions in specific EHR-S. Action Item (3): Add relevant citations to vocabulary services standards to the citation section. Action Item (4): Add CPT and X12 to Functional Descripition: Change description to: "'Examples that EHR-S applications need to support are a consistent set of terminologies such as: LOINC, SNOMED, ICD-10, CPT and messaging standards such as X12 and HL7. Vocabularies may be provided through a terminology service internal or external to the EHR-S."

Candidate Issue: During DSTU assessment will consider the following: The term "version control" covers multiple use cases. In its current form, it is a vaguely-defined "function". The use cases need to be stated as separate functions. For example, the functions for accepting and applying updates, mapping among versions, distributing changes, query translation to accommodate the existence of multiple versions, communicating the adoption of new version to central registries, etc. This is simply too large an problem domain to be covered by one functional name with a brief description. Commenters' agree to withdraw negatives.

Commenters will withdraw if following changes to I.4 are done

Action Item - typo

Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For

Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S grants authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For

Action Item - Change to: "'Verify and enforce access control to EHR information and functions for users and entities (including applications, sites, systems) to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Action item - Include a definition of "Personal Health Information"' in the EHR glossary that differentiates types of personal health information and distinquishes clinical from demographic and administrative components such as appointment scheduling and copayments . Propose that the definition be a meaningful combination of definitions used in other realms and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health informationis information that is a subset of healthinformation, including demographicinformation collected from an individual,and: (1) Is created or received by a health careprovider, health plan, employer, or health careclearinghouse; and (2) Relates to the past, present, or futurephysical or mental health or condition of anindividual; the provision of health care to anindividual; or the past, present, or futurepayment for the provision of health care to anindividual; and (i) That identifies the individual; or(ii) With respect to which there is areasonable basis to believe the informationcan be used to identify the individual.

Action item - Change statement to "Secure all modes of EHR data exchange"

Action Item - typo

Candidate Issue: During DSTU we will define all relevant types of auditing and clearly distinguish their functions. We will consider whether these functions need to be differentiated in the ballot.

Commenters will withdraw

Candidate Issue: This function was a "roll-up" of several initially distinguished functions. During the DSTU assessment, the authoring group will consider whether to create separate functions for the reference data synchronization and patient data synchronization.

Commenters will withdraw if changes to I.4 are done

Action Item (1): Change the function statement to '"Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support syntax and algorithms, and clinical document architecture. Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification." Commenters will withdraw negatives if these changes are made. Action Item (2): Referred to Publishing: Commenters' reguests that the overview reinforce the notion that the model supports the ability to constrain EHR functions in specific EHR-S. Action Item (3): Add relevant citations to vocabulary services standards to the citation section. Action Item (4): Add CPT and X12 to Functional Descripition: Change description to: "'Examples that EHR-S applications need to support are a consistent set of terminologies such as: LOINC, SNOMED, ICD-10, CPT and messaging standards such as X12 and HL7. Vocabularies may be provided through a terminology service internal or external to the EHR-S."

Candidate Issue: During DSTU we should also consider the following: The term "version control" covers multiple use cases. In its current form, it is a vaguely-defined "function". The use cases need to be stated as separate functions. For example, the functions for accepting and applying updates, mapping among versions, distributing changes, query translation to accommodate the existence of multiple versions, communicating the adoption of new version to central registries, etc. This is simply too large an problem domain to be covered by one functional name with a brief description. Commenters' agree to withdraw negatives.

Action Item - typo

Action item: Change non-normative description to: "A healthcare professional will be able to manage a patient’s ability to view his/her EHR, and to have other providers accessing the EHR alerted to any constraints on patient access placed by this provider. Typically, a patient has the right to view much of his/her EHR. However, a healthcare provider may sometimes need to prevent a patient (or guardian) from viewing parts of the record. For example, a patient receiving psychiatric care might harm himself (or others) if he reads the doctor's evaluation of his condition. Furthermore, reading the doctor's therapy-plan might actually cause the plan to fail."

Candidate Issue: During the DSTU assessment, the authoring group will ensure that the functional model addresses the issue of determining which registry a patient's directory information is located in. This may not be a function of the EHR-S but the EHR-S functional model definitely needs to account for where and how this issue will be resolved in each realm.

Candidate Issue: During the DSTU assessment, the authoring group will consider whether interchange agreements need to include the ability of distributed systems to establish business-to-business interoperability via registries for collaboration protocol profiles, business process specifications and support for negotiation of collaboration protocol agreements.

Action Item: Change I.2.2 Function Statement to "Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange and to audit of consent status management (to support DC.1.5.1) and to entity authentication attempts. Audit functionality includes the ability to generate audit reports and to interactively view change history for individual health records or for the EHR-S."

Action Item (1) : Move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2): Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Candidate issue - Future DSTU assessment, authoring group will consider whether to augment description per commenter's suggestion: "'Secure Data Exchange can take place without strong authentication methods in a secure environment. This function needs to be clear on when it is appropriate to implement strong methods"

Candidate Issue: During DSTU, the authoring group will consider whether recording each change to a record is unnecessary for supervisory audit trails and whether this function should not include forensic style audit trails.

Candidate Issue - We should consider the different use-cases (for example, data ownership, asynchronous operation, and store/forward of synchronization messages to accomodate off-line repositories and registries) that may need to be defined as distinct functions. We understand that it is unlikely that all functional elements would be provided by a single component. We will also consider the need to separate the roles and functions of registries/directories and repositories as they relate to synchronization.

candidate issue

Action Item: Change Statement to "'Enable secure use of registry services and directories to uniquely identify and supply links for retrieval and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agencies for administrative and financial purposes; health care resources and devices for resource management purposes."

Candidate Issue: During DSTU, the authoring group will consider whether to conceptually migrate the entity name spaces of the local registry and directory services in an EHR-S with the similar services in other EHR systems through standardized communication interfaces. The authoring group may also consider stating a minimal functional expecation for matching records, e.g., what data fields to use, how to resolve ambiguities, administrative transactions to correct false matches, and propogate matches and corrections to false matches among registries

Candidate Issue: During the DSTU, the authoring group will consider whether to differentiate two aspects to this function as sub-functions: Support for (1) distributed registry and directory services across different EHR-S (this might be for cross-link the entities managed in these EHR-S), and (2) standard-based, network access to the services.Action Item (1) : Move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2): Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual;

Action item - Change description to: "'Whenever an exchange of EHR information occurs, it requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHRS entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHRS or external to the EHRS." Candidate issue - Consider clarification requested by the commenter

Action Issues: Add the following to the function description: "'There is a requirement for system audit trails for the following events: 1. Loading new versions of, or changes to, the clinical system;2. Loading new versions of codes and knowledge bases; 3. Changing the date and time where the clinical system allows this to be done; 4. Taking and restoring of backup; Archiving any data; 5. Re-activating of an archived patient record; 6. Entry to and exiting from the clinical system; 7. Remote access connections including those for system support and maintenance activities."

Candidate Issue: During the DSTU, the authoring group will consider whether to enhance to support multiple types of integration appropriate to the process being performed.

Candidate Issue: During the DSTU, the authoring group will consider whether to split this into three functions: establish and maintain registray values, query registry, and negotiatie binding among messaging partners. Allow for in-band and out-of-band binding.

Candidate Issue in part. Authoring Group intends to link all sections during the DSTU assessment period. We will also consider whether to specify three functions: establish and maintain registray values, query registry, and negotiatie binding among messaging partners to allow for in-band and out-of-band binding.

Action Item: Change the function name to "Workflow Mangement". Candidate Issue: Authoring group will consider commenter's suggestion, made during the San Antonio reconciliation process, that this function be split, based on use cases. We will consider whether to functionally split the administration of process flow management from the query/response/binding and scheduling uses of the process management data. We will carefully consider the relationship of this function to Entity Authorization (1.1.2); it needs to be explicitly stated.

Action Item (1) : Move the following portion of the I1.1 to the I 1 Statement: " Manage the sets of access control permissions granted within an EHR-S." Action Item (2): Propose to add to the EHR Functional Model Glossary the following defintions: "Chain of Trust Agreement" is a contract entered into by two business partners in which the partners agree to safeguard in accordance with applicable jurisdictional requirements, any personal health information that they exchange (see defintion of personal health information proposed for glossary in Items 99, 276, 325, 351, 1026: Include Personal Health Information in glossary.) Propose that the definition be a meaningful combination of definitions used in other realms, and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health information is information that is a subset of health information, including demographic information collected from an individual, and: (1) Is created or received by a health care provider, health plan, employer, or health care clearinghouse; and (2) Relates to the past, present, or future physical or mental health or condition of an individual; the provision of health care to an individual; Action Item (1): Change Statement to "'Manage the sets of access-control permissions granted to entities using the EHR-S.  An EHR-S controls authorizations to entities that use the EHR-S, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data." Action Item (2): "Change the Description to: "Entities that use the EHR-S (EHR-S Users) are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. Another is the authorization that a device in the role of telemonitor can access EHR-S for directions.> Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: an application or device, a nurse, dietician, administrator, legal guardian, and auditor Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. For

Action Item - Change to: "'Verify and enforce access control to EHR information and functions for users and entities (including applications, sites, systems) to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.Action item: Include a definition of "Personal Health Information"' in the EHR glossary that differentiates types of personal health information and distinquishes clinical from demographic and administrative components such as appointment scheduling and copayments . Propose that the definition be a meaningful combination of definitions used in other realms and that it encompass the definition of Individually Identifiable Health Information defined in the HIPAA Privacy rule 45 CFR Parts 160 and 164) at § 160.103 Definitions. Individually identifiable health informationis information that is a subset of healthinformation, including demographicinformation collected from an individual,and: (1) Is created or received by a health careprovider, health plan, employer, or health careclearinghouse; and (2) Relates to the past, present, or futurephysical or mental health or condition of anindividual; the provision of health care to anindividual; or the past, present, or futurepayment for the provision of health care to anindividual; and (i) That identifies the individual; or(ii) With respect to which there is areasonable basis to believe the informationcan be used to identify the individual.

Action item - Change statement to "Secure all modes of EHR data exchange"

Candidate Issue - Need to revisit description to reflect that routing is a sub-component of data exchange that involves complexities that warrant a separate function. For example, route not read capabilitites, multi-hop routing, and distribution to multiple parties.

Action Item - typp

Candidate Issue: During the DSTU assessment, the authoring group will define all relevant types of auditing and clearly distinguish their functions. We will define terms in an EHR glossary. The definition will separate the concept of change-logging from other auditing because this is often provided by different component than auditing, and its administrative requirements are different than what is required for privacy/secuyrity auditing. We will consider whether these functions need to be differentiated in the ballot.

Candidate Issue: This function was a "roll-up" of several initially distinguished functions. During the DSTU assessment, the authoring group will consider whether to create separate functions for the reference data synchronization and patient data synchronization.

Authors' agree to withdraw negatives

Action Item (1): Change the function statement to '"Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support syntax and algorithms, and clinical document architecture. Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification." Commenters will withdraw negatives if these changes are made. Action Item (2): Referred to Publishing: Commenters' reguests that the overview reinforce the notion that the model supports the ability to constrain EHR functions in specific EHR-S. Action Item (3): Add relevant citations to vocabulary services standards to the citation section. Action Item (4): Add CPT and X12 to Functional Descripition: Change description to: "'Examples that EHR-S applications need to support are a consistent set of terminologies such as: LOINC, SNOMED, ICD-10, CPT and messaging standards such as X12 and HL7. Vocabularies may be provided through a terminology service internal or external to the EHR-S."

Candidate Issue: During DSTU we should also consider the following: The term "version control" covers multiple use cases. In its current form, it is a vaguely-defined "function". The use cases need to be stated as separate functions. For example, the functions for accepting and applying updates, mapping among versions, distrbuting changes, query translation to accomodate the existience of mutlple versions, communicating the adoption of new version to central registries, etc. This is simply too large an problem domain to be covered by one functional name with a brief description. Commenters' agree to withdraw negatives.

Action Item - typo

ID FunctionID FunctionName

1 DC.2.7.2 Patient knowledge access

2 DC.3

3 DC.3.1 Clinical workflow tasking

4 DC.3.1.1 Clinical task assignment and routing

5 DC.3.1.2 Clinical task linking

6 DC.3.1.3 Clinical task tracking

Operations Management and Communication

7 DC.3.1.3.1 Clinical task timeliness tracking

8 DC.3.2 Clinical communication9 DC.1 Care Management

10 DC.1.1

11 DC.1.1.1 Identify and locate a patient record

12 DC.1.1.2 Manage patient demographics

13 DC.1.1.3 Manage summary lists

14 DC.1.1.3.1 Manage problem list

15 DC.1.1.3.2 Manage medication list

Health information capture, management, and review

16 DC.1.1.3.3 Manage allergy and adverse reaction list

17 DC.1.1.4 Manage Patient History

18 DC.1.1.5 Summarize health record

19 DC.1.1.6 Manage clinical documents and notes

20 DC.1.1.7 Capture key health data

21 DC.1.1.7.1 Capture external clinical documents

22 DC.1.1.7.2 Capture patient-originated data

23 DC.1.2 Care plans, guidelines, and protocols

24 DC.1.2.1Present care plans, guidelines, and protocols

25 DC.1.2.2

26 DC.1.2.3 Manage patient-specific instructions27 DC.1.3 Medication ordering and management

28 DC.1.3.1 Order medication

29 DC.1.3.2 Manage medication formularies

30 DC.1.3.3 Manage medication administration

31 DC.1.4

32 DC.1.4.1 Place generic orders

33 DC.1.4.2 Order diagnostic tests

34 DC.1.4.3 Manage order sets

Manage patient-specific care plans, guidelines, and protocols.

Orders, referrals, and results management

35 DC.1.4.4 Manage referrals

36 DC.1.4.5 Manage results

37 DC.1.4.6 Order blood products and other biologics

38 DC.1.5 Consents and authorizations

39 DC.1.5.1 Manage consents and authorizations

40 DC.1.5.2 Manage patient advanced directives41 DC.2 Clinical Decision Support42 DC.2.1 Health information capture and review

43 DC.2.1.1 Support for standard assessments

44 DC.2.1.2Support for Patient Context-enabled Assessments

45 DC.2.1.3

46 DC.2.1.4 Patient and family preferences47 DC.2.2 Care plans, guidelines and protocols

48 DC.2.2.1

49 DC.2.2.1.1

50 DC.2.2.1.2

51 DC.2.2.1.3

52 DC.2.2.1.4

53 DC.2.2.1.5 Support research protocols

54 DC.2.2.1.6 Support self-care

55 DC.2.3 Medications and medication management

Support for identification of potential problems and trends

Support for condition based care plans, guidelines, protocols

Present standard care plans, guidelines, protocols

Present context sensitive care plans, guidelines, protocolsCapture variances from standard care plans, guidelines, protocols

Support management of patient groups or populations

56 DC.2.3.1 Support for medication ordering

57 DC.2.3.1.1 Drug, food, allergy interaction checking

58 DC.2.3.1.2 Patient specific dosing and warnings >

59 DC.2.3.1.3 Medication recommendations

60 DC.2.3.2 Support for medication administration.

61 DC.2.4

62 DC.2.4.1

Orders, referrals, results and care management

Support for non-medication ordering   

63 DC.2.4.264 DC.2.4.3 Support for referrals

65 DC.2.4.3.1

66 DC.2.4.3.2 Support for referral recommendations67 DC.2.4.4 Support for Care Delivery

68 DC.2.4.4.1 Support for safe blood administration

69 DC.2.4.4.2 Support for accurate specimen collection

70 DC.2.5

71 DC.2.5.1

72 DC.2.5.273 DC.2.6 Support for population health

Support for result interpretation  

Support for referrals   

Support for Health Maintenance: Preventive Care and Wellness

Alerts preventive services and wellness 

Notifications for preventive services and wellness

74 DC.2.6.1

75 DC.2.6.2 Support for notification and response

76 DC.2.6.377 DC.2.7 Support for knowledge access

78 DC.2.7.1

79 S.3.4

80 S.3.5 Subject to Subject relationship

81 S.3.5.1 Related by genealogy

Support for clinical health state monitoring within a population.

Support for monitoring and appropriate notifications regarding an individual patient’s health

Access clinical guidance 

Manage Practitioner/Patient relationships >

82 S.3.5.2 Related by insurance

83 S.3.5.3 Related by living situation

84 S.3.5.4 Related by other means

85 S.3.6 Acuity and Severity

86 DC.3.2.1 Inter-provider communication

87 DC.3.2.2 Pharmacy communication

88 DC.3.2.3

89 DC.3.2.4 Patient, family and care giver education

90 DC.3.2.5 Communication with medical devices92 S.1 Clinical Support

Provider and patient or family communication

93 S.1.1 Notifiable Registries

94 S.1.2 Donor management support

95 S.1.3 Provider directory

96 S.1.3.1 Provider demographics

97 S.1.3.2 Provider's location within facility

98 S.1.3.3 Provider's on call location

99 S.1.3.4 Provider's general location

100 S.1.4 Patient directory

101 S.1.4.1 Patient demographics

102 S.1.4.2 Patient's location within a facility

103 S.1.4.3

104 S.1.4.4 Optimize patient bed assignment

105 S.1.5 De-identified data request management

106 S.1.6 Scheduling

107 S.1.7 Healthcare resource availability

108 S.2

109 S.2.1 Measurement, monitoring, and analysis

110 S.2.1.1 Outcome Measures

Patient's residence related to the provision and administration of services

Measurement, Analysis, Research and Reports

111 S.2.1.2 Performance and accountability measures

112 S.2.2 Report generation

113 S.2.2.1 Health record output114 S.3 Administrative and Financial

115 S.3.1 Encounter/Episode of care management

116 S.3.1.1 Specialized views

117 S.3.1.2 Encounter specific functionality

118 S.3.1.3

119 S.3.1.4 Support remote healthcare services

120 S.3.2 Information access for supplemental use

Automatic generation of administrative and financial data from clinical record

121 S.3.2.1 Rules-driven clinical coding assistance

122 S.3.2.2

123 S.3.2.3 Integrate cost/financial information

124 S.3.3 Administrative transaction processing

125 S.3.3.1 Enrollment of patients

Rules-driven financial and administrative coding assistance

126 S.3.3.2

127 S.3.3.3 Service authorizations

128 S.3.3.4 Support of service requests and claims

129 S.3.3.5

130 S.3.3.6

131 S.3.7 Maintenance of supportive functions

132 S.3.7.1

Eligibility verification and determination of coverage

Claims and encounter reports for reimbursement

Health service reports at the conclusion of an episode of care.

Clinical decision support system guidelines updates

133 S.3.7.2 Patient education material updates

134 S.3.7.3 Patient reminder information updates

135 S.3.7.4 Public health related updates

137 I.1 Security

138 I.1.1 Entity Authentication

139 I.1.2 Entity Authorization.

140 I.1.3 Entity Access Control

141 I.1.3.1 Patient Access Management

142 I.1.4 Non-repudiation

143 I.1.5 Secure Data Exchange

144 I.1.6 Secure Data Routing

145 I.1.7 Document Attestation

146 I.1.8 Enforcement of Confidentiality

147 I.2

148 I.2.1 Data Retention and Availability

149 I.2.2 Audit trail

150 I.2.3 Synchronization

151 I.2.4 Extraction of health record information

Health record information and management

152 I.3

153 I.3.1 Distributed registry access

154 I.4

155 I.4.1

156 I.4.2

157 I.5 Interoperability Standards

Unique identity, registry, and directory services

Health Informatics and Terminology Standards

Maintenance and versioning of health informatics and terminology standards.

Mapping local terminology, codes, and formats

158 I.5.1 Interchange Standards >

159 I.5.2 Application Integration Standards

160 I.5.3 Interchange Agreements

161 I.6 Business Rules Management

162 I.7 Workflow164 Overview165 Care166 Blank

FunctionStatement

Enable the accessibility of reliable information about wellness, disease management, treatments, and related information that is relevant for a specific patient.

Schedule and manage clinical tasks with appropriate timeliness.

Assignment, delegation and/or transmission of tasks to the appropriate parties.

Linkage of tasks to patients and/or a relevant part of the electronic health record.

Track tasks to guarantee that each task is carried out and completed appropriately.

Track and/or report on timeliness of task completion.

Maintain and identify a single patient record for each patient.

Capture and maintain demographic information that is reportable and, where appropriate, trackable over time.

Create and maintain patient-specific summary lists.

Create and maintain patient-specific problem lists.

Create and maintain patient-specific medication lists.

Create and maintain patient-specific allergies and reactions.

Capture, review, and manage medical, procedural, social, and family history including the capture of pertinent negative histories, patient-reported or externally available patient clinical history.

Present a chronological, filterable, comprehensive review of the patient's entire clinical history, subject to confidentiality constraints.

Create, addend, and authenticate transcribed or directly-entered clinical documentation and notes.

Capture, manage, and review key health data by a variety of users.

Incorporate clinical documents and notes from external sources.

Capture patient-provided and patient-entered clinical data.

Present organizational guidelines for patient care as appropriate to support order entry and clinical documentation.

Provide administrative tools for organizations to build guidelines and protocols for use during patient care.

Generate and record patient-specific instructions related to pre- and post-procedural and post-discharge requirements.

Create prescriptions or other medication orders with detail adequate for correct filling and administration by pharmacy and clinical staff.

Provide information regarding compliance of medication orders with formularies.

Present to appropriate clinicians the medications that are to be administered to a patient, under what circumstances, and capture administration details.

Capture and track orders based on input from specific care providers.

Submit diagnostic test orders based on input from specific care providers.

Provide order sets based on provider input or system prompt.

Enable the origination, documentation and tracking of referrals between care providers or care settings, including clinical and administrative details of the referral.

Route, manage and present current and historical test results to appropriate clinical personnel for review, filtering and comparison.

Communicate with appropriate sources or registries to order blood products or other biologics.

Create, maintain, and verify patient treatment decisions in the form of consents and authorizations when required during the ordering process.

Capture, maintain and provide access to patient advanced directives

Offer knowledge-based prompts to support the adherence to care plans, guidelines, and protocols at the point of information capture.

Offer knowledge-based prompts based on patient-specific data at the point of information capture.

Identify specific problems or trends that may lead to significant problems, which may be based on patient data, providing prompts for consideration at the point of information capture.

Capture patient and family preferences at the time of information intake and integrate them into clinical - decision support at all appropriate opportunities.

Identify the appropriate care plans, guidelines and/or protocols for the management of specific conditions.

Identify the appropriate care plans, guidelines and/or protocols for the management of specific conditions that are adjusted to the patient specific profile.Identify variances from standard care plans, guidelines, and protocols.

Provide support for the management of populations of patients that share diagnoses, problems, demographic characteristics, etc.

Provide support for the identification of patients for potential enrolment in research protocols and management of patients enrolled in research protocols.

Provide the patient with decision support for self-management of a condition between patient-provider encounters.

Identify drug-drug, drug-allergy and drug-food interaction warnings at the point of medication ordering.

Identify drug-condition warnings and present weight/age appropriate dose recommendations

Recommend best practice treatment and monitoring on the basis of cost, local formularies or therapeutic guidelines and protocols

Alert providers in real-time to potential administration errors such as wrong patient, wrong drug, wrong dose, wrong route and wrong time in support of medication administration management and workflow.

Identify necessary order entry components for non-medication orders that make the order pertinent, relevant and resource conservative at the time of provider order entry; and flag any inappropriate orders based on patient profile. -

Evaluate results and notify provider of results within the context of the patient’s clinical data.

Evaluate referrals within the context of a patient’s clinical data.

Evaluate patient data and suggest appropriate referrals.

Alert providers in real-time to potential blood administration errors such as wrong blood, wrong cross match, wrong source, wrong date and time, and wrong patient.

Alert providers in real-time to potential specimen collection errors, such as wrong patient, wrong specimen type, wrong collection means, and wrong date and time.

Identify patient specific suggestions/reminders, screening tests/exams, and other preventive services in support of routine preventive and wellness patient care standards.

Notify the patient and/or appropriate provider of those preventive services, tests, behavioral actions that are due or overdue between patient-provider encounters.

Support clinical health state monitoring of aggregate patient data for use in identifying health risks from the environment and/or population.

Upon notification by an external, authoritative source of a health risk within the cared for population, alert relevant providers regarding specific potentially at-risk patients with the appropriate level of notification.

In the event of a health risk alert and subsequent notification related to a specific patient, monitor if expected actions have been taken, and execute follow-up notification if they have not.

Provide relevant evidence-based information and knowledge to the point of care for use in clinical decisions and care planning

Identify relationships among providers treating a single patient, and provide the ability to manage patient lists assigned to a particular provider. >

Capture relationships between patients and others and facilitate access on this basis (e.g. parent of a child) if appropriate.Provide information of Related by genealogy (blood relatives)

Provide information of Related by insurance (domestic partner, spouse, guarantor)Provide information of Related by living situation (in same household)

Provide information of Related by other means (e.g. epidemiologic exposure or other person authorized to see records – Living Will cases)

Provide the data necessary for the capability to support and manage patient acuity/severity of illness/risk adjustment

Support secure electronic communication (inbound and outbound) between providers to trigger or respond to pertinent actions in the care process, document non-electronic communication (such as phone calls, correspondence or other encounters) and generate p

Provide features to enable secure bidirectional communication of information electronically between practitioners and pharmacies.

Trigger or respond to electronic communication (inbound and outbound) between providers and patients or patient representatives with pertinent actions in the care process.

Identify and make available electronically or in print any educational or support resources for patients, families, and caregivers that are most pertinent for a given health concern, condition, or diagnosis and which are appropriate for the person (s).

Support communication and presentation of data captured from medical devices.

Enable the automated transfer of formatted demographic and clinical information to and from local disease specific registries (and other notifiable registries) for patient monitoring and subsequent epidemiological analysis.

Provide capability to capture or receive, and share needed information on potential organ and blood donors and recipients.

Provide a current directory of provider information in accordance with relevant laws, regulations, and conventions.

Provide a current directory of practitioners that, in addition to demographic information, contains data needed to determine levels of access required by the EHR security system.Provide provider location or contact information on a facility's premises.Provide provider location or contact information when on call.

Provide locations or contact information at which the provider practices, in order to direct patients or queries.

Provide a current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions.

Maintain, archive and update demographic information in accordance with realm-specific recordkeeping requirements.Provide the patient's location information within a facility's premises.

Provide the patient's residence information solely for purposes related to the provision and administration of services to the patient, patient transport, and as required for public health reporting.

Enable interaction with a bed management system to ensure that the patient's bed assignments within the facility optimize care and minimize risks e.g. of exposure to contagious patients.

Provide patient data in a manner that meets local requirements for de-identification.

Provide the necessary data to a scheduling system for optimal efficiency in the scheduling of patient care, for either the patient or a resource/device.

Support the distribution of local healthcare resource information in times of local or national emergencies.

Support measurement and monitoring of care for relevant purposes.

Support the capture and reporting of information for the analysis of outcomes of care provided to populations, in facilities, by providers, and in communities.

Support the capture and reporting of quality, performance, and accountability measures to which providers/facilities/delivery systems/communities are held accountable including measures related to process, outcomes, and/or costs of care – may be used in '

Provide report generation features for the generation of standard and ad hoc reports.

Enable system user to define the records and/or reports that are considered the formal health record for disclosure purposes, and provide a mechanism for both chronological and specified record element output.

Manage and document the health care needed and delivered during an episode of care.

Present specialized views based on the encounter-specific values, clinical protocols and business rules

Provide assistance in assembling appropriate data, supporting data collection and processing output from the encounter.

Derive administrative or financial data from the patient's clinical data and include this in administrative and financial reports.

Support remote health care services such as telehealth and remote device monitoring by integrating records and data collected by these means into the patient's EHR for care management, billing and public health reporting purposes.

Support extraction, transformation and linkage of information from structured data and unstructured text in the patient's health record for care management, financial, administrative, and public health purposes.

Make available all pertinent patient information needed to support coding of diagnoses, procedures and outcomes.

Provide financial and administrative coding assistance based on the structured data and unstructured text available in the encounter documentation.

Enable the use of cost management information required to guide users and workflows.

Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care

Support interactions with other systems, applications, and modules to enable enrollment of uninsured patients into subsidized and unsubsidized health plans, and enrollment of patients who are eligible on the basis of health and/of financial status in soc

Support eligibility verification for health insurance and special programs, including verification of benefits and pre-determination of coverage;

Support the creation of requests, responses and appeals related to service authorization, including prior authorizations, referrals, and pre-certification;

Creation of health care attachments for submitting additional clinical information in support of service requests and claims;

Support the creation of claims and encounter reports for reimbursement

Support the creation of health service reports at the conclusion of an episode of care. Support the creation of health service reports to authorized health entities, for example public health, such as notifiable condition reports, immunization, cancer reg

Update EHR supportive content on an automated basis.

Receive and validate formatted inbound communications to facilitate updating of clinical decision support system guidelines and associated reference material

Receive and validate formatted inbound communications to facilitate updating of patient education material

Receive and validate formatted inbound communications to facilitate updating of patient reminder information from external sources such as Cancer or Immunization Registries

Receive and validate formatted inbound communications to facilitate updating of public health reporting guidelines

Secure the access to the EHR-S and EHR information. Prevent unauthorized use of data, data loss, tampering and destruction.

Authenticate EHR-S users and/or entities before allowing access to an EHR-S. Manage the sets of access-control permissions granted within an EHR-S [move to I.1 Statement]

Manage the sets of access-control permissions granted to EHR-S users.  An EHR-S grants authorizations to users, for roles, and within contexts.   A combination of the authorization levels may be applied to control access to EHR-S functions or data.

Send and receive EHR data securely.

Verify and enforce access control to EHR information and functions for end-users, applications, sites, etc., to prevent unauthorized use of a resource, including the prevention or use of a resource in an unauthorized manner.

Enable a healthcare professional to manage a patient’s access to the patient’s personal health information. Patient access-management includes allowing access to patient/subject-of-care information and restricting access to information that is potentiall

Limit an EHR-S user’s ability to deny (repudiate) an electronic data-exchange originated or authorized by that user.

Route electronically-exchanged EHR data only to/from known, registered, and authenticated destinations/sources (according to applicable healthcare-specific rules and relevant standards).

Manage electronic attestation of documents including the retention of the signature of attestation (or certificate of authenticity) associated with an incoming or outgoing document.

Enforce patient privacy rules as they apply to various parts of the EHR-S through the implementation of privacy mechanisms.

·          Manage EHR information across EHR-S applications by > Ensuring that clinical information is valid according to clinical rules; > Ensuring that clinical information is accurate and complete according to clinical rules; and > Tracking amendment

·          Retain, ensure availability, and destroy health record information according to organizational standards. This includes: > Retaining all clinical documents for the time period designated by policy or legal requirement; > Retaining inbound docum

Provide audit trail capabilities for resource access and usage indicating the author, the modification (where pertinent), and the date/time at which a record was created, modified, viewed, extracted, or deleted. Audit trails extend to information exchange

·          Maintain synchronization involving: > Interaction with entity directories; > Linkage of received data with existing entity records; > Location of each health record component; > Communication of changes between key systems.

Manage data extraction in accordance with analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions can be u

Enable secure use of registry services and directories to uniquely identify, link and retrieve records and identify the location of subjects of care and providers for health care purposes; payers, health plans, sponsors, employers and public health agenci

Enable system communication with registry services through standardized interfaces and extend to services provided externally to the EHR-S.

Ensure consistent terminologies, data correctness and interoperability by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document archit

Enable version control according to customized policies to ensure maintenance of utilized standards.

Map or translate local terminology, codes and/or formats to standard terminology, codes, and/or formats to comply with health informatics standards.

Provide automate health delivery processes and seamless exchange of key clinical and administrative information.

Support the ability to operate seamlessly with complementary systems by adherence to key interoperability standards. Systems may refer to EHR systems, applications within an EHR-S, or other authorized entities that interact with an EHR-S. > >

Provide integration with complementary applications and infrastructure services (directory, vocabulary, etc.) using standard-based application programming interfaces (for example, CCOW).

Support interaction with entity directories to determine the recipients’ address profile and data exchange requirements and use these rules of interaction when exchanging information with partners.

Manage the ability to create, update, delete (or disable) and version business rules including institutional preferences. > > Apply business rules from necessary points within the EHR-S to control system behavior. > > Audit changes made to business r

Workflow management functions include both the management and set up of work queues, personnel, and system interfaces as well as the implementation functions that use workflow-related business rules to direct the flow of work assignments.

FunctionDescription SeeAlso

An individual will be able to find reliable information to answer a health question, follow up from a clinical visit, identify treatment options, or other health information needs. The information may be linked directly from entries in the health record, or may be accessed through other means such as key word searching.

DC.3.2.4; S.3.7.2

Since the electronic health record will replace the paper chart, tasks that were based on the paper artifact must be effectively managed in the electronic environment. Functions must exist in the EHRS that support electronically any workflow that previously depended on the existence of a physical artifact (such as the paper chart, a phone message slip) in a paper based system. Tasks differ from other more generic communication among participants in the care process because they are a call to action and target completion of a specific workflow in the context of a patient's health record (including a specific component of the record). Tasks also require disposition (final resolution). The initiator may optionally require a response. For example, in a paper based system, physically placing charts in piles for review creates a physical queue of tasks related to those charts. This queue of tasks (for example, a set of patient phone calls to be returned) must be supported electronically so that the list (of patients to be called) is visible to the appropriate user or role for disposition. Tasks are time-limited (or finite). The state transition (e.g. created, performed and resolved) may be managed by the user explicitly or

Tasks are at all times assigned to at least one user or role for disposition. Whether the task is assignable and to whom the task can be assigned will be determined by the specific needs of practitioners in a care setting. Task-assignment lists help users prioritize and complete assigned tasks. For example, after receiving a phone call from a patient, the triage nurse routes or assigns a task to return the patient's call to the physician who is on call. Task creation and assignment may be automated, where appropriate. An example of a system-triggered task is when lab results are received electronically; a task to review the result is automatically generated and assigned to a clinician. Task assignment ensures that all tasks are disposed of by the appropriate person or role and allows efficient interaction of entities in the care process.

Clinical tasks are linked to a patient or to a component of a patient's medical record. An example of a well defined task is "Dr. Jones must review Mr. Smith's blood work results." Efficient workflow is facilitated by navigating to the appropriate area of the record to ensure that the appropriate test result for the correct patient is reviewed. Other examples of tasks might involve fulfillment of orders or responding to patient phone calls.

In order to reduce the risk of errors during the care process due to missed tasks, the provider is able to view and track un-disposed tasks, current work lists, the status of each task, unassigned tasks or other tasks where a risk of omission exists. For example, a provider is able to create a report to show test results that have not been reviewed by the ordering provider based on an interval appropriate to the care setting.

Capability to track and review reports on the timeliness of certain tasks in accordance with relevant law and accreditation standards.

Healthcare requires secure communications among various participants: patients, doctors, nurses, chronic disease care managers, pharmacies, laboratories, payers, consultants, etc. An effective EHRS supports communication across all relevant participants, reduces the overhead and costs of healthcare-related communications, and provides automatic tracking and reporting. The list of communication participants is determined by the care setting and may change over time. Because of concerns about scalability of the specification over time, communication participants for all care settings or across care settings are not enumerated here because it would limit the possibilities available to each care setting and implementation. However, communication between providers and between patients and providers will be supported in all appropriate care settings and across care settings. Implementation of the EHRS enables new and more effective channels of communication, significantly improving efficiency and patient care. The communication functions of the EHRS will eventually change the way participants collaborate and distribute the work of patient care.

For those functions related to data capture, data is captured using standardized code sets or nomenclature, depending on the nature of the data. Data may also be captured from devices.

Key identifying information is stored and linked to the patient record. A lookup function uses this information to uniquely identify the patient.

Contact information including addresses and phone numbers, as well as key demographic information such as date of birth, sex, and other information is stored and maintained for reporting purposes and for the provision of care.

S.1.4.0; S.1.4.1; S.1.4.2; I.1.4.4; I.1.4.5

Patient summary lists can be created and maintained when appropriate for the patient or a particular care setting.

S.1.4.0; S.1.4.1; S.1.4.2; I.1.4.4; I.1.4.5

A problem list may include, but is not limited to: Chronic conditions, diagnoses, or symptoms, Visit- or stay-specific conditions, diagnoses, or symptoms. Problem lists are managed over time, whether over the course of a visit or stay or the life of a patient, allowing documentation of history information and tracking the changing character of the problem and its priority. All pertinent dates, including date noted, dates of any changes in problem specification or prioritization, and date of resolution are stored. The entire problem history for any problem in the list is viewable.

Medication lists are managed over time, whether over the course of a visit or stay, or the lifetime of a patient. All pertinent dates, including medication start, modification, and end dates are stored. The entire medication history for any medication is viewable. Medication lists are not limited to medication orders recorded by providers, but may include patient-reported medications.

Allergens and substances are identified and coded (whenever possible) and the list is managed over time. All pertinent dates, including patient-reported events, are stored and the description of the patient allergy and reaction is modifiable over time. The entire allergy history, including reaction, for any allergen is viewable.

Patient historical data related to previous medical diagnoses, surgeries and other procedures performed on the patient, and relevant health conditions of family members is captured through such methods as patient reporting (for example interview, medical alert band) or electronic or non-electronic historical data. This data may take the form of a positive or a negative such as: "The patient/family member has had..." or "The patient/family member has not had..." When first seen by a health care provider, patients typically bring with them clinical information from past encounters. This and similar information is captured and presented alongside locally captured documentation and notes wherever appropriate.

A key feature of an electronic health record is its ability to present, summarize, filter, and facilitate searching through the large amounts of data collected during the provision of patient care. Much of this data is date or date-range specific and should be presented chronologically. Local confidentiality rules that prohibit certain users from accessing certain patient information must be supported.

Clinical documents and notes may be created in a narrative form, which may be based on a template. The documents may also be structured documents that result in the capture of coded data. Each of these forms of clinical documentation are important and appropriate for different users and situations.

Care-setting dependent data is entered by a variety of caregivers. Details of who entered data and when was captured should be tracked.

DC.3.2.5; S.3.1.4

Mechanisms for incorporating external clinical documentation, such as image documents, and other clinically relevant data are available. Data incorporated through these mechanisms is presented alongside locally captured documentation and notes wherever appropriate.

Patients may provide data for entry into the health record or be given a mechanism for entering this data directly. Patient-entered data intended for use by care providers will be available for their use.

Care plans, guidelines, and protocols may be site specific or industry-wide standards. They may need to be managed across one or more providers. Tracking of implementation or approval dates, modifications and relevancy to specific domains or context is provided.

DC.1.2.1

DC.3.2.3

DC.1.3.1

Guidelines or protocols may contain goals or targets for the patient, specific guidance to the providers, suggested orders, and nursing interventions, among other items.

When a patient is scheduled for a test, procedure, or discharge, specific instructions about diet, clothing, transportation assistance, convalescence, follow-up with physician, etc. may be generated and recorded, including the timing relative to the scheduled event.

Different medication orders require different levels and kinds of detail, as do medication orders placed in different situations. The correct details are recorded for each situation. Administration or patient instructions are available for selection by the ordering clinicians, or the ordering clinician is facilitated in creating such instructions. Appropriate time stamps for all medication related activity is generated.

When a clinician places an order for a medication, that order may or may not comply with a formulary specific to the patient’s location or insurance coverage. Whether the order complies with the formulary should be communicated to the ordering clinician at an appropriate point to allow the ordering clinician to decide whether to continue with the order. Formulary-compliant alternatives to the medication being ordered may also be presented.

In a setting in which medication orders are to be administered by a clinician rather than the patient him or herself, the necessary information is presented including: the list of medication orders that are to be administered; administration instructions, times or other conditions of administration; dose and route, etc. Additionally, the clinician is able to record what actually was or was not administered, whether or not these facts conform to the order. Appropriate time stamps for all medication related activity are generated.

Orders that request actions or items can be captured and tracked. Examples include orders to transfer a patient between units, to ambulate a patient, for medical supplies, durable medical equipment, home IV, and diet or therapy orders. For each orderable item, the appropriate detail, including order identification and instructions, can be captured. Orders should be communicated to the correct recipient for completion if appropriate.

For each orderable item, the appropriate detail and instructions must be available for the ordering care provider to complete. Orders for diagnostic tests should be transmitted to the correct destination for completion or generate appropriate requisitions for communication to the relevant resulting agencies.

Order sets allow a care provider to choose common orders for a particular circumstance or disease state according to best practice or other criteria. Recommend order sets may be presented based on patient data or other contexts.

S.1.1.0

D.C. 1.1

Documentation and tracking of a referral from one care provider to another is supported, whether the referred to or referring providers are internal or external to the healthcare organization. Guidelines for whether a particular referral for a particular patient is appropriate in a clinical context and with regard to administrative factors such as insurance may be provided to the care provider at the time the referral is created.

Results of tests are presented in an easily accessible manner and to the appropriate care providers. Flow sheets, graphs, or other tools allow care providers to view or uncover trends in test data over time. In addition to making results viewable, it is often necessary to send results to appropriate care providers using an electronic messaging systems, pagers, or other mechanism. Results may also be routed to patients electronically or in the form of a letter.

Interact with a blood bank system or other source to manage orders for blood products or other biologics. Use of such products in the provision of care is captured. Blood bank or other functionality that may come under federal or other regulation (such as by the FDA in the United States) is not required; functional communication with such a system is.

Treatment decisions are documented and include the extent of information, verification levels and exposition of treatment options. This documentation helps ensure that decisions made at the discretion of the patient, family, or other responsible party govern the actual care that is delivered or withheld.

Patient advanced directives can be captured as well as the date and circumstances under which the directives were received, and the location of any paper records of advanced directives as appropriate.

When a clinician fills out an assessment, data entered triggers the system to prompt the assessor to consider issues that would help assure a complete/accurate assessment. A simple demographic value or presenting problem (or combination) could provide a template for data gathering that represents best practice in this situation, e.g. Type II diabetic review, fall and 70+, rectal bleeding etc. As another example, to appropriately manage the use of restraints, an online alert is presented defining the requirements for a behavioral health restraint when it is selected.

When a clinician fills out an assessment, data entered is matched against data already in the system to identify potential linkages. For example, the system could scan the medication list and the knowledge base to see if any of the symptoms are side effects of medication already prescribed. Important but rare diagnoses could be brought to the doctor’s attention – for instance ectopic pregnancy in a woman of child bearing age who has abdominal pain.

DC 1.2

When personal health information is collected directly during a patient visit input by the patient, or acquired from an external source (lab results), it is important to be able to identify potential problems and trends that may be patient-specific, given the individual's personal health profile, or changes warranting further assessment. For example: significant trends (lab results, weight); a decrease in creatinine clearance for a patient on metformin, or an abnormal increase in INR for a patient on warfarin.

Decision support functions should permit consideration of patient/family preferences and concerns, such as with language, medication choice, invasive testing, and advanced directives.

At the time of the clinical encounter, standard care protocols are presented. These may include site-specific considerations.

At the time of the clinical encounter, recommendations for tests, treatments, medications, immunizations, referrals and evaluations are presented based on evaluation of patient specific data, their health profile and any site-specific considerations. These may be modified on the basis of new clinical data at subsequent encounters.Variances from care plans, guidelines, or protocols are identified and tracked, with alerts, notifications and reports as clinically appropriate.

Populations or groups of patients that share diagnoses (such as diabetes or hypertension), problems, demographic characteristics, medication orders are identified. The clinician may be notified of eligibility for a particular test, therapy, or follow-up; or results from audits of compliance of these populations with disease management protocols.

Potential candidates for participation in a research study are identified and the clinician notified of patient eligibility. The clinician is presented with protocol-based care to patients enrolled in research studies.

Patients with specific conditions need to follow self-management plans that may include schedules for home monitoring, lab tests, and clinical check ups; recommendations about nutrition, physical activity, tobacco use, etc.; and guidance or reminders about medications.

DC.1.1.7.2; DC.3.2.4

 DC 1.3

The clinician is alerted to drug-drug, drug-allergy, and drug-food interactions at levels appropriate to the health care entity. These alerts may be customized to suit the user or group.

The clinician is alerted to drug-condition interactions and patient specific contraindications and warnings e.g. elite athlete, pregnancy, breast-feeding or occupational risks. The preferences of the patient may also be presented e.g. reluctance to use an antibiotic.

Offer alternative treatments on the basis of best practice (e.g. cost or adherence to guidelines), a generic brand, a different dosage, a different drug, or no drug (“watchful waiting”). Suggest lab order monitoring as appropriate.

To reduce medication errors at the time of administration of a medication, the patient is positively identified; checks on the drug, the dose, the route and the time are facilitated. Documentation is a by-product of this checking; administration details and additional patient information, such as injection site, vital signs, and pain assessments, are captured.  In addition, access to online drug monograph information allows providers to check details about a drug and enhances patient education.

Possible order entry components include, but are not limited to: missing results required for the order, suggested corollary orders, notification of duplicate orders, institution-specific order guidelines, guideline-based orders/order sets, order sets, order reference text, patient diagnosis specific recommendations pertaining to the order. Also, warnings for orders that may be inappropriate or contraindicated for specific patients (e.g. X-rays for pregnant women) are presented.

Possible result interpretations include, but are not limited to: abnormal result evaluation/notification, trending of results (such as discrete lab values), evaluation of pertinent results at the time of provider order entry (such as evaluation of lab results at the time of ordering a radiology exam), evaluation of incoming results against active medication orders.

  DC 1.4

When a healthcare referral is made, pertinent health information, including pertinent results, demographic and insurance data elements (or lack thereof) are presented to the provider. Protocols for appropriate workup prior to referral may be presented.

Entry of specific patient conditions may lead to recommendations for referral e.g. for smoking cessation counseling if the patient is prescribed a medication to support cessation.

To reduce blood administration errors at the time of administration of blood products, the patient is positively identified and checks on the blood product, the amount, the route and the time are facilitated. Documentation is a by-product of this checking.

To ensure the accuracy of specimen collection, when a provider obtains specimens from a patient, the clinician can match each specimen collection identifier and the patient’s ID bracelet. The provider is notified in real-time of potential collection errors such as wrong patient, wrong specimen type, wrong means of collection, wrong site, and wrong date and time. Documentation of the collection is a by-product of this checking.

At the time of an encounter, the provider or patient is presented with due or overdue activities based on protocols for preventive care and wellness. Examples include but are not limited to, routine immunizations (adult and well baby care), age and sex appropriate screening exams (such as PAP smears).

The provider can generate notifications to patients regarding activities that are due or overdue and these communications can be captured. Examples include but are not limited to time sensitive patient and provider notification of: follow-up appointments, laboratory tests, immunizations or examinations. The notifications can be customized in terms of timing, repetitions and administration reports. E.g. a Pap test reminder might be sent to the patient a 2 months prior to the test being due, repeated at 3 month intervals, and then reported to the administrator or clinician when 9 months overdue.

S.3.4.1

Standardized surveillance performance measures that are based on known patterns of disease presentation can be identified by aggregating data from multiple input mechanisms. For example, elements include, but are not limited to patient demographics, resource utilization, presenting symptoms, acute treatment regimens, laboratory and imaging study orders and results and genomic and proteomic data elements. Identification of known patterns of existing diseases involves aggregation and analysis of these data elements by existing relationships. However, the identification of new patterns of disease requires more sophisticated pattern recognition analysis. Early recognition of new patterns requires data points available early in the disease presentation. Demographics, ordering patterns and resource use (e.g., ventilator or intensive care utilization pattern changes) are often available earlier in the presentation of non-predictable diseases. Consumer-generated information is also valuable with respect to surveillance efforts.

Upon receipt of notice of a health risk within a cared-for population from public health authorities or other external authoritative sources, identify and notify individual care providers or care managers that a risk has been identified and requires attention including suggestions on the appropriate course of action. This process gives a care provider the ability to influence how patients are notified, if necessary.

Identifies that expected follow-up for a specific patient event (e.g., follow up to error alerts or absence of an expected lab result) has not occurred and communicate the omission to appropriate care providers in the chain of authority. Of great importance to the notification process is the ability to match a care provider’s clinical privileges with the clinical requirements of the notification.

Examples include but are not limited to: evidence on treatment of conditions and wellness, as well as context-specific links to other knowledge resources. For example, when a condition is diagnosed provider is directed to relevant online evidence for management.

 This function addresses the ability to access and update current information about the relationships between caregivers and the subjects of care. This information should be able to flow seamlessly between the different components of the EHRS, and between the EHRS and other systems. Business rules may be reflected in the presentation of, and the access to this information. The relationship among providers treating a single patient will include any necessary chain of authority/responsibility. > Example: In a care setting with multiple providers, where the patient can only see certain kinds of providers (or an individual provider), allow the selection of only the appropriate providers. > Example: The user is presented with a list of people assigned to a given practitioner and may alter the assignment as required - to a group, to another individual or by sharing the assignment.

 DC.2.6.3; > S.2.2

A user may assign the relationship of parent to a person who is their offspring. This relationship may facilitate access to their health record as parent of a young child.

S.1.4.1; I.1.3; I.1.5; I.2.2

 S.2.1.2

Communication among providers involved in the care process can range from real time communication (for example, fulfillment of an injection while the patient is in the exam room), to asynchronous communication (for example, consult reports between physicians). Some forms of inter-practitioner communication will be paper based and the EHRS must be able to produce appropriate documents.

When a medication is prescribed, the prescription is routed electronically to the pharmacy. This information is used to avoid transcription errors and facilitate detection of potential adverse reactions. Upon filling the prescription, information is sent back to the practitioner to indicate that the patient received the medication. If there is a question from the pharmacy, that communication can be presented to the provider with their other tasks.

The clinician is able to communicate with patients and others, capturing the nature and content of electronic communication, or the time and details of other communication. For example: when test results arrive, the clinician may wish to email the patient that test result was normal (details of this communication are captured); a patient may wish to request a refill of medication by emailing the physician; patients with asthma may wish to communicate their peak flow logs/diaries to their provider; or a hospital may wish to communicate with selected patients about a new smoking cessation program.

The provider or patient is presented with a library of educational materials and where appropriate, given the opportunity to document patient/caregiver comprehension. The materials can be printed or electronically communicated to the patient.

Communication with medical devices is supported as appropriate to the care setting. Examples include: vital signs/pulse-oximeter, anesthesia machines, home diagnostic devices for chronic disease management, laboratory machines, bar coded artifacts (medicine, immunizations, demographics, history, and identification).

I.2.4; I.4.7

I.1.3; I.4

Example: The patient census in a hospital setting

The user can export personal health information to disease specific registries, other notifiable registries, and add new registries through the addition of standard data transfer protocols or messages.

I.2.4 > I.4.7

The user is able to capture or receive information on potential organ and blood donors and recipients. The user can make this information available to internal and external donor matching agencies.

Maintain or access current directory of provider information in accordance with relevant laws, regulations, and conventions, including full name, address or  physical location, and a 24x7 telecommunications address (e.g. phone or pager access number) for the purposes of the following functions

Provide a current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions, including, when available, full name, address or  physical location, alternate contact person, primary phone number, and relevant health status information for the purposes of the following functions.

DC.1.1.1; I.1.4

The minimum demographic data set must include the data required by realm-specific laws governing health care transactions and reporting. This may also include data input of death status information.

S.1.4; I.1.5.1; > S.3.7.3

S.3.6.2

 S.1.7

When an internal or external party requests patient data and that party requests de-identified data (or is not entitled to identify patient information, either by law or custom), the user can export the data in a fashion that meets local requirements for de-identification. An audit trail of these requests and exports is maintained. For internal clinical audit, a re-identification key may be added to the data.

I.1.8; I.3; I.6.1

The system user can schedule events as required. Relevant clinical or demographic information can be linked to the task.

DC.3.1; > DC.3.2.1; I.2.3; I.4.1; > I.7

In times of identified local or national emergencies and upon request from authorized bodies, provide current status of healthcare resources including, but not limited to, available beds, providers, support personal, ancillary care areas and devices, operating theaters, medical supplies, vaccines, and pharmaceuticals. The intent is for the authorized body to distribute either resources or patient load to maximize efficient healthcare delivery.

S.1.4.4; I.1.6; I.5.1

DC.2.6.1; I.2.4

DC.2.6.3; > DC.2.6.2; S.3.6

A user can create standard and ad hoc reports for clinical, administrative, and financial decision-making, and for patient use - including structured data and/or unstructured text from the patient’s health record. Reports may be linked with financial and other external data sources (i.e. data external to the entity).; Such reports may include patient-level reports, provider/facility/delivery system-level reports, population-level reports, and reports to public health agencies. > > Examples of patient-level reports include: administratively required patient assessment forms, admission/transfer/discharge reports, operative and procedure reports, consultation reports, and drug profiles. > > Examples of population-level reports include: reports on the effectiveness of clinical pathways and other evidence-based practices, tracking completeness of clinical documentation, etcetera. > > Examples of reports to public health agencies include: vital statistics, reportable diseases, discharge summaries, immunization data including adverse outcomes, cancer data, and other such data necessary to maintain the publics’ health (including suspicion of newly emerging infectious disease and non-natural events). > >

DC.2.6.3; S.3.6

Provide hardcopy and electronic output that can fully chronicles the healthcare process, supports selection of specific sections of the health record, and allows healthcare organizations to define the report and/or documents that will comprise the formal health record for disclosure purposes.

I.2.4; > DC.1.15

Using data standards and technologies that support interoperability, encounter management promotes patient-centered/oriented care and enables real time, immediate point of service, point of care by facilitating efficient work flow and operations performance to ensure the integrity of > (1) the health record, > (2) public health, financial and administrative reporting, and > (3) the healthcare delivery process.; This support is necessary for direct care functionality that relies on providing user interaction and workflows, which are configured according to clinical protocols and business rules based on encounter specific values such as care setting, encounter type (inpatient, outpatient, home health, etc), provider type, patient's EHR, health status, demographics, and the initial purpose of the encounter.

S.3.2.2

The system user is presented with a presentation view and system interaction appropriate to the context with capture of encounter-specific values, clinical protocols and business rules. This “user view” may be configurable by the user or system technicians. As an example, a mobile home health care worker using wireless laptop at the patient's home would be presented with a home health care specific workflow synchronized to the current patient's care plan and tailored to support the interventions appropriate for this patient, including chronic disease management protocols.

DC.2.2.1.2;

Workflows, based on the encounter management settings, will assist in determining the appropriate data collection, import, export, extraction, linkages and transformation. As an example, a pediatrician is presented with diagnostic and procedure codes specific to pediatrics. Business rules enable automatic collection of necessary data from the patient's health record and patient registry. As the provider enters data, workflow processes are triggered to populate appropriate transactions and documents. For example, data entry might populate an eligibility verification transaction or query the immunization registry.

A user can generate a bill based on health record data. Maximizing the extent to which administrative and financial data can be derived or developed from clinical data will lessen provider reporting burdens and the time it takes to complete administrative and financial processes such as claim reimbursement. This may be implemented by mapping of clinical terminologies in use to administrative and financial terminologies.

Enables remote treatment of patients using monitoring devices, and two way communications between provider and patient or provider and provider. - Promotes patient empowerment, self-determination and ability to maintain health status in the community. Promotes personal health, wellness and preventive care. For example, a diabetic pregnant Mom can self-monitor her condition from her home and use web TV to report to her provider. The same TV-internet connectivity allows her to get dietary and other health promoting information to assist her with managing her high-risk pregnancy.

DC.3.2.1; > DC.3.2.3; DC.3.2.5; DC.1.1.7.2

Using data standards and technologies that support interoperability, information access functionalities serve primary and secondary record use and reporting with continuous record availability and access that ensure the integrity of (1) the health record, (2) public health, financial and administrative reporting, and (3) the healthcare delivery process.

I.7

DC.1.3

The user is assisted in coding information for clinical reporting reasons. For example, a professional coder may have to code the principle diagnosis in the current, applicable ICD as a basis for hospital funding. All diagnoses during the episode may be presented to the coder, as well as the applicable ICD hierarchy containing these codes.

The user is assisted in coding information for billing or administrative reasons. For example, the HIPAA 837 Professional claim requires the date of the last menstrual cycle for claims involving pregnancy. To support the generation of this transaction, the clinician would need to be prompted to enter this date when the patient is first determined to be pregnant, then making this information available for the billing process.

I.7; S.3.1.3

The provider is alerted or presented with the most cost-effective services, referrals, devices etc. to recommend to the patient. This may be tailored to the patient's health insurance/plan coverage rules. Medications may be presented in order of cost, or the cost of specific investigations may be presented at the time of ordering.

Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for encounter management during an episode of care. - - The EHR system shall capture the patient health-related information needed for administrative and financial purposes including reimbursement. - - Captures the episode and encounter information to pass to administrative or financial processes (e.g. triggers transmissions of charge transactions as by-product of on-line interaction including order entry, order statusing, result entry, documentation entry, medication administration charting.) - - Automatically retrieves information needed to verify coverage and medical necessity. - As a byproduct of care delivery and documentation, captures and presents all patient information needed to support coding. Ideally performs coding based on documentation. - - Clinically automated revenue cycle - examples of reduced denials and error rates in claims. - - Clinical information needed for billing is available on the date of service. - - Physician and clinical teams do not perform additional data entry / tasks exclusively to support administrative or financial processes.

Expedites determination of health insurance coverage, thereby increasing patient access to care. The provider may be alerted that uninsured patients may be eligible for subsidized health insurance or other health programs because they meet eligibility criteria based on demographics and/or health status. For example: a provider is notified that the uninsured parents of a child enrolled in S-CHIP may now be eligible for a new subsidized health insurance program; a provider of a pregnant patient who has recently immigrated is presented with information about eligibility for subsidy. Links may be provided to online enrollment forms. When enrollment is determined, the health coverage information needed for processing administrative and financial documentation, reports or transactions is captured.

S.2.2

Automatically retrieves information needed to support verification of coverage at the appropriate juncture in the encounter workflow. Improves patient access to covered care and reduces claim denials. When eligibility is verified, the EHRS would capture eligibility information needed for processing administrative and financial documentation, reports or transactions - updating or flagging any inconsistent data. In addition to health insurance eligibility, this function would support verification of registration in programs and registries, such as chronic care case management and immunization registries. An EHRS would likely verify health insurance eligibility prior to the encounter, but would verify registration in case management or immunization registries during the encounter.

Automatically retrieves information needed to support verification of medical necessity and prior authorization of services at the appropriate juncture in the encounter workflow. Improves timeliness of patient care and reduces claim denials.

Automatically retrieves structured data, including lab, imaging and device monitoring data, and unstructured text based on rules or requests for additional clinical information in support of service requests or claims at the appropriate juncture in the encounter workflow

Automatically retrieves information needed to support claims and encounter reporting at the appropriate juncture in the encounter workflow.

Effective use of this function means that clinicians do not perform additional data entry to support health management programs and reporting.

  >

DC.1.2.1; DC.2.6.3; > DC.2.7.1

DC.3.2.4

I.5.2

I.5.2; > S.1.4.1

To enforce security, all EHR-S applications must adhere to the rules established to control access and protect the privacy of EHR information. Security measures assist in preventing unauthorized use of data and protect against loss, tampering and destruction.

·          Both users and application 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: > Username/ password; > Digital certificate; > Secure token; > Biometrics

·          EHR-S Users are authorized according to identity, role, work-assignment, present condition and/or location. > User based authorization refers to the permissions granted or denied based on the identity of an individual. An example of User based authorization is patient defined denial of access to all or part of a record to a particular party for reasons such as privacy. > Role based authorization refers to the responsibility or function performed in a particular operation or process. Example roles include: nurse, dietician, administrator, legal guardian, and auditor. > Context-based Authorization is defined by ISO as security-relevant properties of the context in which an access request occurs, explicitly time, location, route of access, and quality of authentication. In addition to the standard, context authorization for EHR-S is extended to satisfy special circumstances such as, assignment, consents, or other healthcare-related factors. A context-based example might be a right granted for a limited period to view those—and only those—EHR records connected to a specific topic of investigation.

I.1.1; I.1.2

This is a fundamental function of EHR-S applications. To ensure access is controlled, the EHR-S applications will perform an identity lookup of users or application for any operations that require it (authentication, authorization, secure routing, querying, etc.) and enforce the system and information access rules that have been defined.

A healthcare professional will be able to manage a patient’s ability to view his/her EHR. Typically, a patient has the right to view much of his/her EHR. However, a healthcare provider may sometimes need to prevent a patient (or guardian) from viewing parts of the record. For example, a patient receiving psychiatric care might harm himself (or others) if he reads the doctor's evaluation of his condition. Furthermore, reading the doctor's therapy-plan might actually cause the plan to fail.

·          Non-repudiation ensures that a transferred message has been sent and received by the parties claiming to have sent and received the message. Non-repudiation is a way to guarantee that the sender of a message cannot later deny having sent the message and that the recipient cannot deny having received the message. Non-repudiation can be achieved through the use of a: > Digital signature -- which serves as a unique identifier for an individual (much like a written signature). > Confirmation service -- which utilizes a message transfer agent to create a digital receipt (providing confirmation that a message was sent and/or received). > Timestamp -- which proves that a document existed at a certain date and time.

Exchange of EHR information requires appropriate security and privacy considerations, including data obfuscation and both destination and source authentication when necessary. For example, it might be necessary to encrypt data sent to remote destinations. This function requires that there is an overall coordination regarding what information is exchanged between EHR-S entities and how that exchange is expected to occur. The policies applied at different locations must be consistent or compatible with each other in order to ensure that the information is protected when it crosses entity boundaries within the EHR-S or external to the EHR-S.

EHR-S applications need to ensure that they are exchanging EHR information with the entities (applications, institutions, directories) they expect. This function depends on entity authorization, and authentication to be available in the system. For example, a physician practice management application in the EHR-S, might send claim attachment information to an external entity. For this, the application must use a secure routing method which ensures that both the sender and receiving sides are authorized to engage in the information exchange.

The purpose of attestation is to show authorship and assign responsibility for an act, event, condition, opinion, or diagnosis. 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. (Note: A transcriptionist may transcribe an author's notes and a senior clinician may attest to the accuracy of another's statement of events.) Attestation is required for (paper or electronic) entries such as narrative/progress notes, assessments, flow sheets, and orders. Digital signatures may be used to implement document attestation. For an incoming document, if included, the record of attestation is retained. Attestation functionality must meet applicable legal, regulatory and other applicable standards or requirements.

I.6.1

I.1.7

A patient's privacy may be adversely affected when EHRs are not held in confidence. Privacy rule enforcement decreases unauthorized access and promotes the level of EHR confidentiality.

Since EHR information will typically be available on a variety of EHR-S applications, the EHR-S must provide the ability to access, manage and verify accuracy and completeness of EHR information, and provide the ability to audit the use of (and access to) EHR information.

·          Discrete and structured EHR data, records and reports must be: > Made available to users in a timely fashion; > Stored and retrieved in a semantically intelligent and useful manner (for example, chronologically, retrospectively per a given disease or event, or in accordance with business requirements, local policies, or legal requirements); > Retained for a legally-proscribed period of time; > Destroyed in a systematic manner in relation to the applicable retention period. The system must also allow an organization to identify data/records to be destroyed, and to review and approve destruction before it occurs.Audit functionality extends to security audits, data audits, audits of data exchange, and the ability to generate audit reports. Audit trail settings should be configurable to meet the needs of local policies. Examples of audited areas include: > Security audit - logs access attempts and resource usage including user login, file access, other various activities, and whether any actual or attempted security violations occurred. > Data audit - records who, when, and by which system an EHR record was created, updated, translated , viewed, extracted, or (if local policy permits) deleted. Audit-data may refer to system setup data or to clinical and patient management data. > Information exchange audit – record data exchanged between EHR-S applications (for example, sending application; the nature, history, and content of the information exchanged; and information about data transformations (for example, vocabulary translations), reception event details, etc.). > Audit reports – should be flexible and address various users' needs. For example, a legal authority might want to know how many patients a given healthcare provider treated while the provider's license was suspended. Similarly, in some cases a report detailing all those who modified or

The EHR-S may consist of a set of components or applications; each application manages a subset of the health information. Therefore it is important that, through various interoperability mechanisms, the EHR-S maintains all the relevant information regarding the health record in synchrony. For example, if an MRI is ordered by a physician, a set of diagnostic images and a radiology report will be created. The patient demographics, the order for MRI, the diagnostic images associated with the order, and the report associated with the study must all be in synch in order for the clinicians to view the complete record.

The EHR-S enables an authorized user (such as a clinician) to access and aggregate the distributed information that corresponds to the health record or records which are needed for viewing, reporting, disclosure, etc. The EHR-S must be able to support data extraction operations across the complete data set that constitutes the health record of an individual and provide an output that fully chronicles the healthcare process. Data extractions are used as input to continuity of care records. In addition, data extractions can be used for administrative, financial, research, quality analysis and public health purposes.

Interoperability standards enable an EHR-S to operate as a set of applications.

Unique identity, registry, and directory service functions are critical to successfully managing the security, interoperability, and the consistency of the health record data across the EHR-S.

The EHR-S will rely on a set of infrastructure services, directories, and registries (organized hierarchically) that support communication between EHR-Systems. For example, a patient treated by a primary care physician for a chronic condition may become ill while out of town. The new provider’s EHR-S will interrogate a local, regional, or national registry to find the patient’s previous records. From the primary care record, the remote EHR-S will retrieve relevant information (in conformance with applicable patient privacy and confidentiality rules). An example of local registry usage is an EHR-S application sending a query message to the Hospital Information System to retrieve a patient’s demographic data.

Examples that EHR-S applications need to support are a consistent set of terminologies such as: LOINC, SNOMED, ICD-10 and messaging standards such as HL7. Vocabularies may be provided through a terminology service internal or external to the EHR-S.

Version control allows for multiple sets/versions of the same terminology to exist and be distinctly recognized over time. Terminology versioning supports retrospective analysis and research, as well as interoperability with systems that comply with different releases of the standard. Similar functionality exists for messaging and other informatics based standards. It should be possible to retire deprecated versions when applicable business cycles are completed while maintaining obsolescent code sets for possible claims adjustment throughout the claim's lifecycle.

An EHR-S application which uses local terminology, must be capable of mapping and/or converting the local terminology into a standard terminology. For example, a local term or code for "Ionized Calcium" must be mapped to an equivalent, standardized (LOINC) term or code when archiving or exchanging artifacts.

I.4.2

I.3

·          Interoperable EHR-S applications require infrastructure components that adhere to standards for connectivity, information structures, and semantics ("interoperability standards"). Standard EHR Infrastructure components, which may exist locally or remotely, must support seamless operations between complementary systems. Standard infrastructure components include: > HL7 Messages, Clinical Document Architecture (CDA), X12N healthcare transactions, Digital Imaging and Communication in Medicine (DICOM). > Common semantic representation to support information exchange. EHR-Systems may use different standardized or local vocabularies. In order to reconcile the semantic differences across vocabularies, the EHR-S must be able to adhere to standard vocabulary or leverage vocabulary lookup and mapping capabilities that are included in the Health Informatics and Terminology Standards. > Support of multiple interaction modes to respond to differing levels of immediacy and types of exchange. For example, messaging is effective for many near-real time, asynchronous data exchange scenarios but may not be appropriate if the end-user is requesting an immediate response from a remote application. In addition, even in the case where store-and-forward, message-oriented interoperability is used, the applications may need to support the appropriate

Similar to standard-based messaging, standard-based application integration requires that the EHR-S application use standardized programming interfaces, where applicable. For example, CCOW may be used for visual integration and WfMC for workflow integration.

An EHR-S will use the entity registries to determine the security, addressing, and reliability requirements between partners and use this information to define how data will be exchanged between the sender and the receiver.

·          Business Rule implementation functions include: decision support, diagnostic support, workflow control, access privileges, and system and user defaults and preferences. > > The EHR-S should support the ability for providers and institutions to customize decision support components such as triggers, rules or algorithms, and the wording of alerts and advice, to meet local requirements and preferences. > > Examples of applied business rules include: > Suggesting diagnosis based on the combination of symptoms (flu-like symptoms combined with widened mediastinum suggesting anthrax > Classifying a pregnant patient as high risk due to factors such as age, health status, and prior pregnancy outcomes. > Sending an update to an immunization registry when a vaccination is administered > Limiting access to mental health information to a patient’s psychiatrist/psychologist > Establishing system level defaults such as for vocabulary data sets to be implemented. > Establishing user level preferences such as allowing the use of health information for research purposes.

Workflow management functions include: > Distribution of information to and from internal and external parties; > Support for task-management as well as parallel and serial task distribution; > Support for notification and task routing based on system triggers; and > Support for task assignments, escalations and redirection in accordance with business rules. > > Workflow definitions and management may be implemented by a designated application or distributed across EHR-S applications.

Rationale

Facilitates self-health management and supports the delivery of effective healthcare.

Support delivery of effective healthcare; patient safety; improve efficiency

Support delivery of effective healthcare; improve patient safety; improve efficiency

Support delivery of effective healthcare; patient safety;

Support delivery of effective healthcare; patient safety

Supports delivery of effective healthcare, Improves efficiency, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions

Supports delivery of effective healthcare, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Facilitates self-health management, Improves patient safety

Supports delivery of effective healthcare, Facilitates management of chronic conditions

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety.

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Facilitates self-health management, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Facilitates self-health management

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates self-health management, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency

Supports delivery of effective healthcare, Improves efficiency, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions

Supports delivery of effective healthcare, Improves efficiency, Facilitates management of chronic conditions, Facilitates self-health management, Improves patient safety

Supports delivery of effective healthcare, Improves efficiency, Improves patient safety

Facilitates self-health management, Improves patient safety

Supports delivery of effective healthcare, Facilitates self-health management, Improves patient safety

Supports delivery of effective healthcare, improves patient safety and efficiency, and facilitates management of chronic conditions. 

Supports delivery of effective healthcare, improves patient safety and efficiency, and facilitates management of chronic conditions  

Supports delivery of effective healthcare, improves patient safety and efficiency, and facilitates management of chronic conditions. 

Improves patient safety and facilitates self-health management.

Supports delivery of effective healthcare and improves efficiency; supports the management of chronic conditions.

Supports delivery of effective healthcare and improves efficiency.Supports delivery of effective healthcare and improves efficiency.

Supports delivery of effective healthcare, improves efficiency, supports the management of chronic conditions; and facilitates self-health management.

 

Improves patient safety and efficiency and supports delivery of effective healthcare.

Improves patient safety and efficiency and supports delivery of effective healthcare.

Improves patient safety and efficiency and supports delivery of effective healthcare.

Improves patient safety and efficiency and promotes the delivery of effective healthcare.

Improves patient safety, efficiency, and supports the delivery of effective healthcare.

Supports delivery of effective healthcare, improves efficiency, and facilitates management of chronic conditions.

Supports delivery of effective healthcare, improves efficiency, and facilitates management of chronic conditions.

Supports delivery of effective healthcare and improves patient safety and efficiency  

Supports delivery of effective healthcare and improves patient safety and efficiency  

Supports the delivery of effective healthcare and improves efficiency.

Supports the delivery of effective healthcare, improves efficiency; and facilitates self-health management.

Supports the delivery of effective healthcare and improves efficiency. 

Supports the delivery of effective healthcare and improves efficiency.  

Supports the delivery of effective healthcare and improves patient safety and efficiency.  

Supports the delivery of effective healthcare, improves patient safety and efficiency, and facilitates management of chronic conditions.

1. Support delivery of effective healthcare - 3. Facilitate management of chronic conditions - 4. Improve efficiency

1. Support Delivery of Effective Healthcare - 3 Facilitate management of chronic conditions

1. Support Delivery of Effective Healthcare - 2 Improve Patient Safety - - 4 Improve efficiency

Support delivery of effective healthcare; patient safety; management of chronic conditions; improve efficiency;

Support delivery of effective healthcare; improve efficiency; management of chronic conditions

Support delivery of effective healthcare; management of chronic conditions; improve efficiency; facilitate self health management

Support delivery of effective healthcare; management of chronic conditions; improve efficiency; facilitate self health management

Support delivery of effective healthcare; Management of chronic conditions Improve efficiency

1. Support delivery of effective healthcare - 2. Improve patient safety - 3. Facilitate management of chronic conditions

2. Improve patient safety - 4. Improve efficiency

1. Support delivery of effective healthcare - 4. Improve efficiency

1. Support delivery of effective healthcare - 2. Improve patient safety - 3. Facilitate management of chronic conditions - 4. Improve efficiency - 5. Facilitate self-health management

1. Support delivery of effective healthcare - 2. Improve patient safety - 3. Facilitate management of chronic conditions - 4. Improve efficiency

1. Support delivery of effective healthcare - 2. Improve patient safety - 4. Improve efficiency

1. Support Delivery of Effective Healthcare - 2 Improve Patient Safety - 3 Facilitate management of chronic conditions - 4 Improve efficiency

1. Support Delivery of Effective Healthcare - 2 Improve Patient Safety - 3 Facilitate management of chronic conditions - 4 Improve efficiency - 5 Facilitate self-health management

1. Support Delivery of Effective Healthcare - 3 Facilitate management of chronic conditions - 4 Improve efficiency

1. Support Delivery of Effective Healthcare - 2 Improve Patient Safety - 3 Facilitate management of chronic conditions - 4 Improve efficiency - 5 Facilitate self-health management

1. Support delivery of effective healthcare - 2. Improve patient safety - 3. Facilitate management of chronic conditions - 4. Improve efficiency

1. Support Delivery of Effective Healthcare - - 4. Improve efficiency -

1. Support Delivery of Effective Healthcare - 2. Improve Patient Safety - 3. Facilitate management of chronic conditions - 4. Improve efficiency - 5. Facilitate self-health management

Support reference to standard and local terminologies and their versions in a manner that ensures comparable and consistent use of vocubulary, such as the Common Terminology Services specification.

Citations Chapter

D

D

D

D

D

D

U.S. Department of Health and Human Services, Healthy People 2010, Health Communication Focus Area. (USDHHS 2000) http://www.healthypeople.gov/document/HTML/Volume1/11HealthCom.htm - ; Science Panel on Interactive Communication and Health. Wired for Health and Well-Being: the Emergence of Interactive Health Communication.  Washington, DC: US Department of Health and Human Services, US Government Printing Office, April 1999 . http://www.health.gov/scipich/pubs/finalreport.htm >

D

DD

D

D

D

D

D

D

ISO/TS 18308 - Health Informatics - Requirements for an Electronic Health Record Architecture; ASTM E 1769 Standard Guide for Properties of Electronic Health Records and Record Systems

D

D

D

D

D

D

D

D

D

ISO/TS 18308 Final Draft - Health Informatics - Requirements for an Electronic Health Record Architecture. (care plans); HIMSS Electronic Health Record Definitional Model June 2003 (protocols); ASTM E 1769 Standard Guide for Properties of Electronic Health Records and Record Systems

D

DHIMSS Electronic Health Record Definitional Model June 2003 D

D

D

D

HIMSS Electronic Health Record Definitional Model June 2003 D

D

D

D

D

D

D

D

D

DDD

D

D

American Dental Association Specification No. 1000 for a Standard Clinical Architecture for the Structure and Content of an Electronic Health Record. (consent)

D

DD

D

D

D

D

D

D

D

D

Institute of Medicine (IOM). Committee on Health Care in America. Crossing the quality chasm: A new health system for the 21st century. - National Academy Press: Institute of Medicine. 2001. - Laine C, Davidoff F. Patient-centered medicine. A professional - evolution. JAMA 1996 Jan 10;275(2):152-6.

Payne TH. Computer Decision Support Systems. CHEST 2000; 118:47S-52S. - - Hunt DL, Haynes RB, Hanna SE, Smith K. Effects of computer-based clinical decision support systems on physician performance and patient outcomes: a systematic review. JAMA 1998;280:1339-1346. -

Holman H, Lorig K. Patients as partners in managing chronic disease. - Partnership is a prerequisite for effective and efficient health care. BMJ - 2000 Feb 26;320(7234):526-7 - Lorig KR, Sobel DS, Stewart AL, Brown BW Jr, Bandura A, Ritter P, Gonzalez VM, Laurent DD, Holman HR. Evidence suggesting that a chronic disease self-management program can improve health status while reducing hospitalization: a randomized trial. Med Care 1999 Jan;37(1):5-14

D

D

D

D

D

D

D

Bates DW et al. Effect of computerized physician order entry and a team intervention on prevention of serious medication errors. JAMA 1998;280:1311-1316. - - Bates DW et al. The impact of computerized physician order entry on medication error prevention. JAMIA 1999;6:313-321. - - Raschke RA et al. A computer alert system to prevent injury from adverse drug events. JAMA 1998;280:1317-1320. - - Chertow GM et al. Guided Medication dosing for inpatients with renal insufficiency. JAMA 2001;286:2839-2844. - - Evans RS et al. A computer-assisted management program for antibiotics and other anti-infective agents. NEJM 1998; 338:232-238. - - Hunt DL, Haynes RB, Hanna SE, Smith K. Effects of computer-based clinical decision support systems on physician performance and patient outcomes: a systematic review. JAMA 1998;280:1339-1346. - - Mekhjian HS et al. Immediate benefits realized following implementation of physician order entry at an academic medical institution. JAMIA 2002;9:529-539. -

Payne TH. Computer Decision Support Systems. CHEST 2000; 118:47S-52S. - - - Stair TO. Reduction of Redundant Laboratory Orders by Access to Computerized Patient Records. Computers in Emergency Medicine 1998;16:895-897. - - Sanders DL, Miller RA. The effects on clinician ordering patterns of a computerized decision support system for neuroradiology imaging studies. Proc AMIA Symp 2001;:583-587. - - Hunt DL, Haynes RB, Hanna SE, Smith K. Effects of computer-based clinical decision support systems on physician performance and patient outcomes: a systematic review. JAMA 1998;280:1339-1346. - - Chin HL, Wallace P. Embedding guidelines into direct physician order entry: simple methods, powerful results. Proc AMIA Symp 1999:;221-225.

DD

D

DD

D

D

D

D

DD

Poom EG, Kuperman GJ, Fiskio J, Bates DW. Real-time notification of laboratory data requested by users through alphanumeric pagers. JAMIA 2002;9:217-222. - - Kuperman GL et al. Improving response to critical laboratory results with automation. JAMIA 1999;6:512-522. - - Bates DW et al. Reducing the frequency of errors in medicine using information technology. JAMIA 2001;8(4):299-308. - -

U.S. Preventive Services Task Force. http://www.ahrq.gov/clinic/uspstfix.htm - - Reference: Hunt DL, et. al. Effects of Computer-based Clinical Decision Support on Physician Performance and Patient Outcomes. JAMA.1998:280;1339-1346.

U.S. Preventive Services Task Force. http://www.ahrq.gov/clinic/uspstfix.htm - Reference: Hunt DL, et. al. Effects of Computer-based Clinical Decision Support on Physician Performance and Patient Outcomes. JAMA.1998:280;1339-1346. - -

D

D

DD

D

S

S

S

 See also S.3.7.1, S.3.7.3

IOM Rpt, page 9, "Effective communication - among health care team members and with patients - is critical to the provision of quality health care (Bates and Gawande, 2003; Wanlass et. Al. 1992) - http://www.iom.edu/report.asp?id=14391

An EHR used at a professional site should support personal health information (http://www.connectingforhealth.org/resources/phwg_final_report.pdf). Why Keeping Family Health Records is a Good Idea http://www.health-minder.com/articles/benefits.htm

S

S

S

S

D

D

D

D

DS

Contact tracing is an essential and required feature of public health and has usefulness outside of public health when evaluating non-reportable infectious disease or genetically related conditions. (http://biotech.law.lsu.edu/Books/lbb/x578.htm)

An Integrated Analysis of Staffing and Effects on Patient Outcomes http://www.nursingworld.org/OJIN/KEYNOTES/speech_3.htm

S

S

S

S

S

S

S

S

S

S

Disease specific registries are exemplified by the long-standing cancer registry system that exists in each state and supported by institution-based tumor registries in many health care institutions. See http://www.cdc.gov/cancer/npcr/index.htm for more information.

Organ donor transplant management is a complex interaction of many coordinated bodies that extends beyond the institutions involved in organ harvesting and transplantation. This system is described at http://www.optn.org/about/transplantation/matchingProcess.asp.

Unique identification of providers along with appropriate demographics is already being done in healthcare and will form an essential component of the National Provider Identifier in the US under HIPAA (http://aspe.hhs.gov/admnsimp/nprm/npinprm.pdf). Role based access to systems is an essential component of any security system. An example of role based access as it applies to the EHR by the Open Architecture for Secure Internetworking Services (OASIS) may be found at(http://www.cl.cam.ac.uk/~km/MW2001-talk.pdf). OASIS is a not-for-profit global consortium that drives the development, convergence and adoption of e-business standards (http://www.cl.cam.ac.uk/~km/MW2001-talk.pdf). - While current provider location is a convenience item that relates mostly to customer satisfaction it elevates to a level of vital importance when com-municating critical test results (http://www.macoalition.org/documents/CTRPractices.pdf)

Patient location is an essential part of the patient record, which, by IOM definition in their 1991 report forms the basis of an EHR (http://books.nap.edu/books/0309055326/html/index.html).

Patient demographics is an essential part of the patient record, which, by IOM definition in their 1991 report that forms the basis of an EHR (http://books.nap.edu/books/0309055326/html/index.html).

S

S

S

S

S

S

S

S

Personal health information disclosure is required for pubic health purposes, see http://www.cdc.gov/mmwr/preview/mmwrhtml/su5201a1.htm. -

Information on the recommended isolation of patients with certain infectious diseases may be found at http://www.cdc.gov/ncidod/sars/isolationquarantine.htm with a current list of possible infectious agents at http://www.cdc.gov/ncidod/sars/executiveorder040403.htm. - Information on an instructional role in emergency situations has been developed by JCAHO and maybe found at http://www.jcaho.org/about+us/public+policy+initiatives/emergency+preparedness.pdf.

Deidentification of data requires removing patient demographic information to the point that the individual patient can not be identified. Actual requirements for deidentification will vary based on location and specific need. In the US regulations for that are viewed as acceptable for complete deidentification can be found at http://privacyruleandresearch.nih.gov/pr_08.asp#8a.

IOM Rpt, page 10, "Electronic scheduling systems for admissions, procedures and visits not only increase efficiency, but also provide better service to patients (Everett, 2002; Hancock and Walter, 1986; Woods, 2001) - http://www.iom.edu/report.asp?id=14391

The Public Health response to biological and chemical terrorism: interim planning guidance for state public health officials. http://www.bt.cdc.gov/Documents/Planning/PlanningGuidance.PDF -

AHIMA Practice Brief: Data Quality Management Model: http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_000066.html

S

S

SS

S

“Claims and encounter data are used to monitor and improve outcomes for numerous preventive services, including prenatal care, childhood immunization, and cancer screenings.” p. 8 - Promoting Prevention Through Information Technology: - Assessment of Information Technology in Association of Health Center Affiliated Health Plans http://www.ahcahp.org/publications/Working%20Papers/Final%20Report%20from%202003%20AHCAHP%20IT%20Assessment.pdf -

AHIMA Practice Brief: Definition of the Health Record for Legal Purposes: http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_009223.html

S

S

S

S

S

Remarks by Tommy G. Thompson, Secretary of HHS, NHII Conference 7/1/03: "Why is it that retailers such as L.L. Bean have been able to personalize my shopping experience and yours - automatically providing the correct sizes and suggestions of other items based on what I bought last year - but my doctor and pharmacist cannot quickly refer to a list of my prescriptions or see when I had my last physical?"(http://www.hhs.gov/news/speech/2003/030701.html ) Key Capabilities of an Electronic Health Record System, p. 9 (http://www.iom.edu/report.asp?id=14391) Standards Insight - An Analysis of Health Information - Standards Development Initiatives - July 2003(http://www.himss.org/content/files/StandardsInsight/2003/07-2003.pdf )

The CPR in Eleven Paperless Physicians' Offices; http://www.himss.org/content/files/proceedings/slides/sessions/ses048s.pdf; http://www.himss.org/content/files/proceedings/2000/sessions/ses048.pdf -

Paperless Success: The Value of E-Medical Records - http://www.himss.org/content/files/proceedings/2001/sessions/ses045.pdf - http://www.himss.org/content/files/proceedings/2001/sessions/ses081.pdf - - "Having clinical data represented with a standardized terminology and in a machine-readable format would reduce the significant data collection burden at the provider level, as well as the associated costs, and would likely increase the accuracy of the data reported ." IOM Key Capabilities of an Electronic Health Record System , pg 14 ( http://www.iom.edu/report.asp?id=14391 ) - - “1. Real-time status reports linking performance measures with health outcomes. 2. Rapid adjustments for problem resolution. 3. Community awareness of their local health institutions quality of care.” Reference, Improving Health in the Community. IOM, NAS. -

Recent examples of: device monitoring (http://www.hi-europe.info/files/2003/9974.htm); remote monitoring(http://www.devicelink.com/mddi/archive/03/06/012.html); and telehealth (http://www.mcg.edu/Telemedicine/Index.html) - -

AHIMA Practice Brief: Definition of the Health Record for Legal Purposes: http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_009223.html - - IOM Key Capabilities of an Electronic Health Record System, p.14 - http://www.iom.edu/report.asp?id=14391

S

S

S

S

S

Remarks by Tommy G. Thompson, Secretary of HHS, NHII Conference 7/1/03: We need a health information system that automatically gives health professionals access to the patient-specific medical knowledge required for diagnosis and treatment - the latest research results from medical journals, the most up-to-date guidelines, the appropriate public health notifications. Our doctors then will not have to depend on their great memories any more. - http://www.hhs.gov/news/speech/2003/030701.html -

NHII03 Standards and Vocabulary Groups A&B: http://aspe.hhs.gov/sp/nhii/Conference03/StandardsVocabA.ppt, http://aspe.hhs.gov/sp/nhii/Conference03/StandardsVocabB.PPT

Medical Informatics for Better and Safer Health Care. http://www.ahrq.gov/data/informatics/informatria.pdf

IOM Key Capabilities of an Electronic Health Record System: "Use of communication and content standards is equally important in the billing and claims management area - close coupling of authorization and prior approvals can, in some cases, eliminate delays and confusion. Additionally, immediate validation of insurance eligibility will add value for both providers and patients through improved access to services, more timely payments and less paperwork. "http://www.iom.edu/report.asp?id=14391 - HIMSS Electronic Health Record Definitional Model - Version 1.0 - - AHIMA Practice Brief: Definition of the Health Record for Legal Purposes: http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_009223.html - - AHIMA Practice Brief: Health Informatics Standards and Information Transfer: Exploring the HIM Role: http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_000024.html - - AHIMA Practice Brief: Defining the Designated Record Set: http://library.ahima.org/xpedio/groups/public/documents/ahima/pub_bok1_017122.html -

Enrolling and Retaining Low Income families http://cms.hhs.gov/schip/outreach/progress.pdf - To a Streamlined Approach to - Public Health Insurance Enrollment - http://www.healtheapp.org/ -

S

S

S

S

S

S

S

Immunization registries are having continual success in increasing vaccination rates of children (http://www.cdc.gov/mmwr/preview/mmwrhtml/mm5001a2.htm). - - Electronic determination of insurance coverage is a required HIPAA transaction in the US. See the 270/271 Implementation Guide available at http://www.wpc-edi.com/hipaa/HIPAA_40.asp. - -

Plans reported that their electronic connections to various types of providers enable numerous functions to be completed over the Internet, including claims submission, online eligibility verification, and referral approvals. P.9 - Promoting Prevention Through Information Technology: Assessment of Information Technology in Association of Health Center Affiliated Health Plans http://www.ahcahp.org/publications/Working%20Papers/Final%20Report%20from%202003%20AHCAHP%20IT%20Assessment.pdf

Electronic transmission of clinical data for claims is a required HIPAA transaction in the US that is under development. See http://www.hl7.org/library/committees/ca/hipaa%20and%20claims%20attachments%20white%20paper%2020030920.pdf for details.

Electronic submission of claims data is a required HIPAA transaction in the US. See the 837 Implementation Guide available at http://www.wpc-edi.com/hipaa/HIPAA_40.asp. - - - -

IOM Key Capabilities of an Electronic Health Record System p. 14 http://www.iom.edu/report.asp?id=14391 - HIMSS Electronic Health Record Definitional Model - Version 1.0

Nearly all plans (92 percent) reported having one or more IT databases that reference clinical criteria, guidelines or protocols. While plans reported a variety of methods used to communicate clinical criteria, guidelines and protocols to providers, e-mail and electronic newsletters are seldom used and only one of the most widely used methods is related to IT. p 3 - Promoting Prevention Through Information Technology: Assessment of Information Technology in Association of Health Center Affiliated Health Plans http://www.ahcahp.org/publications/Working%20Papers/Final%20Report%20from%202003%20AHCAHP%20IT%20Assessment.pdf

S

S

S

I

I

I

Patient Provider Communication Tools http://www.chcf.org/documents/ihealth/PatientProviderCommunicationTools.pdf Informing Patients A Guide for Providing Patient Health Information - http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=61336 - - Promoting Prevention Through Information Technology: Assessment of Information Technology in Association of Health Center Affiliated Health Plans - http://www.ahcahp.org/publications/Working%20Papers/Final%20Report%20from%202003%20AHCAHP%20IT%20Assessment.pdf

Plans reported using IT systems to support numerous activities and processes, such as utilization management, disease management and targeted mailings to members. P. 3 Promoting Prevention Through Information Technology: Assessment of Information Technology in Association of Health Center Affiliated Health Plans http://www.ahcahp.org/publications/Working%20Papers/Final%20Report%20from%202003%20AHCAHP%20IT%20Assessment.pdf -

Public health response information changes continually and the ability to access the latest data by EHR users is essential (http://www.cdc.gov/phin/components/PHIN%20Brochure%20HAN%20.ppt). -

ISO 9735-7:2002 - - Electronic data interchange for administration, commerce and transport - (EDIFACT) -- Application level syntax rules (Syntax version number: 4, - Syntax release number: 1) -- Part 7: Security rules for batch EDI - (confidentiality)

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

'Ensure consistent terminologies, data correctness and interoperability in accordance with realm specific requirements, by complying with standards for health care transactions, vocabularies, code sets, and artifacts such as templates, interface, decision support algorithms, and clinical document architecture...etc."

I

I

I

I

I

FullName

DC.2.7.2 Patient knowledge access

DC.3.1 Clinical workflow tasking

DC.3.1.1 Clinical task assignment and routing

DC.3.1.2 Clinical task linking

DC.3.1.3 Clinical task tracking

DC.3 Operations Management and Communication

DC.3.1.3.1 Clinical task timeliness tracking

DC.3.2 Clinical communicationDC.1 Care Management

DC.1.1.1 Identify and locate a patient record

DC.1.1.2 Manage patient demographics

DC.1.1.3 Manage summary lists

DC.1.1.3.1 Manage problem list

DC.1.1.3.2 Manage medication list

DC.1.1 Health information capture, management, and review

DC.1.1.4 Manage Patient History

DC.1.1.5 Summarize health record

DC.1.1.6 Manage clinical documents and notes

DC.1.1.7 Capture key health data

DC.1.1.7.1 Capture external clinical documents

DC.1.1.7.2 Capture patient-originated data

DC.1.2 Care plans, guidelines, and protocols

DC.1.1.3.3 Manage allergy and adverse reaction list

DC.1.2.1 Present care plans, guidelines, and protocols

DC.1.2.3 Manage patient-specific instructionsDC.1.3 Medication ordering and management

DC.1.3.1 Order medication

DC.1.3.2 Manage medication formularies

DC.1.3.3 Manage medication administration

DC.1.4 Orders, referrals, and results management

DC.1.4.1 Place generic orders

DC.1.4.2 Order diagnostic tests

DC.1.4.3 Manage order sets

DC.1.2.2 Manage patient-specific care plans, guidelines, and protocols.

DC.1.4.4 Manage referrals

DC.1.4.5 Manage results

DC.1.4.6 Order blood products and other biologics

DC.1.5 Consents and authorizations

DC.1.5.1 Manage consents and authorizations

DC.1.5.2 Manage patient advanced directivesDC.2 Clinical Decision SupportDC.2.1 Health information capture and review

DC.2.1.1 Support for standard assessments

DC.2.1.2 Support for Patient Context-enabled Assessments

DC.2.1.4 Patient and family preferencesDC.2.2 Care plans, guidelines and protocols

DC.2.2.1.5 Support research protocols

DC.2.2.1.6 Support self-care

DC.2.3 Medications and medication management

DC.2.1.3 Support for identification of potential problems and trends

DC.2.2.1 Support for condition based care plans, guidelines, protocols

DC.2.2.1.1 Present standard care plans, guidelines, protocols

DC.2.2.1.2 Present context sensitive care plans, guidelines, protocolsDC.2.2.1.3 Capture variances from standard care plans, guidelines, protocols

DC.2.2.1.4 Support management of patient groups or populations

DC.2.3.1 Support for medication ordering

DC.2.3.1.1 Drug, food, allergy interaction checking

DC.2.3.1.2 Patient specific dosing and warnings >

DC.2.3.1.3 Medication recommendations

DC.2.3.2 Support for medication administration.DC.2.4 Orders, referrals, results and care management

DC.2.4.1 Support for non-medication ordering   

DC.2.4.3 Support for referrals

DC.2.4.3.2 Support for referral recommendationsDC.2.4.4 Support for Care Delivery

DC.2.4.4.1 Support for safe blood administration

DC.2.6 Support for population health

DC.2.4.2 Support for result interpretation  

DC.2.4.3.1 Support for referrals   

DC.2.4.4.2 Support for accurate specimen collectionDC.2.5 Support for Health Maintenance: Preventive Care and Wellness

DC.2.5.1 Alerts preventive services and wellness 

DC.2.5.2 Notifications for preventive services and wellness

DC.2.6.2 Support for notification and response

DC.2.7 Support for knowledge access

S.3.4 Manage Practitioner/Patient relationships >

S.3.5 Subject to Subject relationship

S.3.5.1 Related by genealogy

DC.2.6.1 Support for clinical health state monitoring within a population.

DC.2.6.3 Support for monitoring and appropriate notifications regarding an individual patient’s health

DC.2.7.1 Access clinical guidance 

S.3.5.2 Related by insurance

S.3.5.3 Related by living situation

S.3.5.4 Related by other means

S.3.6 Acuity and Severity

DC.3.2.1 Inter-provider communication

DC.3.2.2 Pharmacy communication

DC.3.2.4 Patient, family and care giver education

DC.3.2.5 Communication with medical devicesS.1 Clinical Support

DC.3.2.3 Provider and patient or family communication

S.1.1 Notifiable Registries

S.1.2 Donor management support

S.1.3 Provider directory

S.1.3.1 Provider demographics

S.1.3.2 Provider's location within facility

S.1.3.3 Provider's on call location

S.1.3.4 Provider's general location

S.1.4 Patient directory

S.1.4.1 Patient demographics

S.1.4.2 Patient's location within a facility

S.1.4.4 Optimize patient bed assignment

S.1.5 De-identified data request management

S.1.6 Scheduling

S.1.7 Healthcare resource availability

S.2.1 Measurement, monitoring, and analysis

S.2.1.1 Outcome Measures

S.1.4.3 Patient's residence related to the provision and administration of services

S.2 Measurement, Analysis, Research and Reports

S.2.1.2 Performance and accountability measures

S.2.2 Report generation

S.2.2.1 Health record outputS.3 Administrative and Financial

S.3.1 Encounter/Episode of care management

S.3.1.1 Specialized views

S.3.1.2 Encounter specific functionality

S.3.1.4 Support remote healthcare services

S.3.2 Information access for supplemental use

S.3.1.3 Automatic generation of administrative and financial data from clinical record

S.3.2.1 Rules-driven clinical coding assistance

S.3.2.3 Integrate cost/financial information

S.3.3 Administrative transaction processing

S.3.3.1 Enrollment of patients

S.3.2.2 Rules-driven financial and administrative coding assistance

S.3.3.3 Service authorizations

S.3.3.4 Support of service requests and claims

S.3.7 Maintenance of supportive functions

S.3.3.2 Eligibility verification and determination of coverage

S.3.3.5 Claims and encounter reports for reimbursement

S.3.3.6 Health service reports at the conclusion of an episode of care.

S.3.7.1 Clinical decision support system guidelines updates

S.3.7.2 Patient education material updates

S.3.7.3 Patient reminder information updates

S.3.7.4 Public health related updates

I.1 Security

I.1.1 Entity Authentication

I.1.2 Entity Authorization.

I.1.3 Entity Access Control

I.1.3.1 Patient Access Management

I.1.4 Non-repudiation

I.1.5 Secure Data Exchange

I.1.6 Secure Data Routing

I.1.7 Document Attestation

I.1.8 Enforcement of Confidentiality

I.2 Health record information and management

I.2.1 Data Retention and Availability

I.2.2 Audit trail

I.2.3 Synchronization

I.2.4 Extraction of health record information

I.3 Unique identity, registry, and directory services

I.3.1 Distributed registry access

I.4 Health Informatics and Terminology Standards

I.5 Interoperability Standards

I.4.1 Maintenance and versioning of health informatics and terminology standards.

I.4.2 Mapping local terminology, codes, and formats

I.5.1 Interchange Standards >

I.5.2 Application Integration Standards

I.5.3 Interchange Agreements

I.6 Business Rules Management

I.7 WorkflowOverviewDirect CareBlank

Org Phone EmailBaptist Healthcare System, Inc. 502 896 3100Oracle Corporation - Healthcare 650-506-0908Physician Micro Systems, Inc. 206-441-8490

503-531-7141Physician Micro Systems, Inc. 206-441-2246Epic Systems Corporation 608-271-9000KHIMA 785-478-0194Intelligent Medical Systems, Inc. 432-364-2223

703-575-6360Mayo Clinic/Foundation 507-284-9133

301-589-0900Epic Systems Corporation 608-271-9000

610-219-4779

312-422-2185Great Plains Health Alliance, Inc. 785-478-3659OMNI Medical Group (918)748-7890

Kaiser Permanente 404-943-7591Physician Micro Systems 206-441-2405Physician Micro Systems, Inc. 206-441-2400

858-826-7293Mayo Clinic/Foundation 507-284-3827

33-130-70-99-77Mayo Clinic/Foundation 507-284-5506Misys Healthcare Systems 801-588-6020Geisinger Health System 570-271-6982Regenstrief Institute, Inc. 317-630-7070Fraser Health Authority 604-520-4137Northwestern Memorial Hospital 312-926-8007Physician Micro Systems, Inc. 206-441-2400HealthMEDX, Inc. 417-582-1816HL7 Australia Voter #7 61-438-392-779

404-639-2621

404-639-7715Epic Systems Corporation 608-271-90003M Health Information Systems 708-352-3507IBM 561-862-2001

801-584-5660

[email protected]@[email protected]

GE Medical Systems - Information Technologies [email protected]

[email protected]@[email protected]@smartdoctor.com

SAIC - Science Applications International Corp [email protected]

[email protected] Healthcare Information Management [email protected]

[email protected] Medical Solutions Health Services [email protected] Alliance for Health InformationTechnology [email protected]

[email protected]@sjmc.org

GE Medical System Information Technology [email protected]

[email protected]@[email protected]

SAIC - Science Applications International Corp [email protected]

[email protected] Medical Systems - Information Technologies [email protected]

[email protected]@[email protected]@[email protected]@[email protected]@[email protected]

GE Medical Systems - Information Technologies [email protected] for Disease Control and Prevention/CDC [email protected] for Disease Control and Prevention (CDC) [email protected]

[email protected]@[email protected]

U.S. Department of Veterans Affairs-OIFO,Salt Lake [email protected]

Northwestern Memorial Hospital 312-926-9165MedicAlert Foundation 209-669-2490HL7 UK, Clinical Info. Consultancy 44-118-958-4954 [email protected]

703-824-8571 [email protected]

858-793-7932 [email protected]

Misys Healthcare Systems 919-329-1602Centennial HealthCare Corp. 770 730 1148 [email protected]

847 277 5041 [email protected] Micro Systems, Inc. 206-441-2304 [email protected] Health Network 718-334-5790 [email protected] 202-898-2830 [email protected]

312-233-1135 [email protected]

Columbia University 212-305-9801HCR ManorCare 419-252-6417 [email protected]

610-219-3050 [email protected]

734-205-6904 [email protected]. R. Larsen, Inc. 708-579-0610 [email protected], Inc. 615-777-2735 [email protected] Australia Voter #2 51-413-644282 [email protected] and Drug Administration 301-827-5534 [email protected] Health Cooperative 206-448-2675 [email protected]

2065201063 [email protected]

Misys Healthcare Systems 919-847-8102 [email protected]

773-702-9665 [email protected] Australia Voter #4 61-408-309-839 [email protected] Family Practice 540-636-7000 [email protected] Consulting, Inc. 360-592-8001 [email protected]

301-435-3869 [email protected] Health System (570) 271-6222 [email protected] Health Solutions 619-535-7892 [email protected] Health Administration 813-864-7365 [email protected] Corporation - Healthcare 415-491-8117 [email protected] Micro Systems, Inc. 206-441-2400 [email protected]

ISO WG2 Meeting 909-536-7010HL7 Canada Voter #3 416-481-2002 [email protected]

610-219-3938 [email protected] Canada 416-481-2002 [email protected]. Department of Veterans Affairs 703-824-0995 [email protected]

[email protected]@medicalert.org

SAIC - Science Applications International CorpSAIC - Science Applications International Corp

[email protected]

GE Medical Systems Information Technologies

American Health Information Management Association

[email protected]

Siemens Medical Solutions Health ServicesGE Medical Systems - Information Technologies

University of Washington Physicians Network

University of Chicago Hospitals & Health Systems

National Cancer Institute Center for Bioinformatic

[email protected]

Siemens Medical Solutions Health Services Corp.

Kaiser Permanente 626-381-4154 [email protected]

306-655-8515

610-219-2087 [email protected] Clinic/Foundation 507-284-0753 [email protected]

847-277-5096 [email protected] Micro Systems, Inc. 206.441.2243 [email protected] Canada Voter #7 250-888-5824 [email protected]

49-9131-84-3480 [email protected] Group 603-20932800 [email protected], Inc. 312-930-5617 [email protected] Systems Corporation 608-271-9000 [email protected] University 212-305-8127 [email protected] 602-256-6656 [email protected]

Health Information Strategies Inc. 780-459-8560Food and Drug Administration 301-827-0195 [email protected] Medical Association 312-464-4713 [email protected]

610-219-6545 [email protected] Records Institute 505-856-9167 [email protected]

202-690-6443 [email protected], Inc. 856-874-0342 [email protected], Inc. 415-644-3800 [email protected] 520-888-9409 [email protected]

410-732-4352 [email protected]

334-749-3993 [email protected] Permanente 925-926-3011 [email protected] and Drug Administration / CFSAN 212-418-3116 [email protected] Permanente 626-229-6455 [email protected]. Department of Veterans Affairs 518-449-0622 [email protected] Corporation - Healthcare 415-507-4511 [email protected] 925-979-7440 [email protected] Corporation - Healthcare 415-491-8131 [email protected]

Misys Healthcare Systems 919-329-1172Misys Healthcare Systems 520-733-6365 [email protected] Australia Voter #6 61-414-861-822 [email protected] Products, Inc. 412-372-5783 [email protected] Inc. 703-759-6363 [email protected]

314-951-5280 [email protected]

773-834-8200 [email protected]

410-785-9683 [email protected]

510-768-6835 [email protected]

HL7 Canada Voter #4 - Saskatoon District HealthSiemens Medical Solutions Health Services Corp.

GE Medical Systems - Information Technologies

Siemens Medical Solutions Health Services Corp.

[email protected]

Siemens Medical Solutions Health Services Corp.

U.S. Department of Health & Human Services

Health Care Information Consultants, LLCSiemens Medical Solutions Health Services Corp.

[email protected]

University of Chicago Hospitals & Health SystemsU.S. Department of Health and Human Services / CMSU.S. Department of Veterans Affairs - OIFO,Oakland

HC Trends Consulting (978)697-4011 [email protected] Health Services 505-248-4916 [email protected] 312-915-9281 [email protected] of Kansas 913-588-4286 [email protected] Permanente 925-926-5139 [email protected] and Drug Administration 301-827-0935 [email protected] Systems Inc. 480-423-8184 [email protected] Memorial Hospital 312-926-7677 [email protected]. Department of Veterans Affairs 972-605-1924 [email protected]

703-845-3299 [email protected]

College of American Pathologists 503-494-6161 [email protected] Australia 61-412-746-457 [email protected]

61-412-746-457 [email protected] Australia 61-412-746-457 [email protected] Franciscan Services, Inc. 414-465-4501 [email protected]

Misys Healthcare Systems 520-570-2000

208-367-2941 [email protected] Medical Systems 866-644-7458 [email protected] Cross Blue Shield Association 312-297-5962 [email protected]. Department of Veterans Affairs 301-734-0417 [email protected] Corporation - Healthcare 415-491-8103 [email protected] and Drug Administration 301-827-6085 [email protected]

780-421-5620 [email protected]

814-944-1651 [email protected] Micro Systems, Inc. 206-441-2305 [email protected] Medical Center 310-423-5873 [email protected] Academy of Neurology (310) 206-3093 [email protected]

703-681-5611 [email protected]

National Cancer Institute 301-594-9185 [email protected] Corporation 972-604-4066 [email protected]

University of Texas, School of Nursing 512-462-9367 [email protected] Global Healthcare 301-624-1779 [email protected]

847-277-5006 [email protected] Corporation - Healthcare 415-491-8104 [email protected]

800-331-4215 [email protected] International 800-647-9002 [email protected]

312-942-2097 [email protected]

770-209-0284 [email protected]/OPHS/USDHHS 202-260-2652 [email protected] 302-235-6822 [email protected]

U.S. Department of Veterans Affairs / EDS

[email protected]

Saint Alphonsus Regional Medical Center

HL7 Canada Voter #5 - IBM Canada, Alberta WellnetSiemens Medical Solutions Health Services

U.S. Department of Defense, Health Affairs

GE Medical Systems - Information Technologies

GE Medical Systems - Information Technologies

Centers for Disease Control and Prevention / CDC

801-582-1565 [email protected] University School of Nursing 212-305-2139 [email protected]

Misys Healthcare Systems 520-733-6302

610-219-3036 [email protected] Internal Medicine Assoc. 256-351-1990 [email protected] Australia Voter #5 61-411-256-312 [email protected]

UW Medical Foundation 608-829-5358

Gordon Point Informatics Ltd. 250-812-7858Oracle Corporation - Healthcare 415-507-4508 [email protected]

301-458-4618 [email protected]. Department of Veterans Affairs 315-425-4645 [email protected]

703-681-5611 [email protected] Consultancy Services 734-213-7448 [email protected]

American HealthTech, Inc. [email protected] Micro Systems, Inc. 206-441-2400 [email protected] Consulting, LLC 858-538-2220 [email protected] and Drug Administration / CVM 301-827-1821 [email protected]

916-636-1964 [email protected] Corporation - Healthcare 415-491-8137 [email protected] Medical Group (918)748-7567 [email protected] Permanente 626-381-3529 [email protected] Clinic/Foundation 507-284-0051 [email protected]

414-362-3610 [email protected] Corporation 916-636-1168 [email protected] Microsystems, Inc. 510-795-3055 [email protected]

215-542-2318 [email protected] Australia Voter #3 61-2-6289-7494 [email protected] Micro Systems, Inc. 206-441-2400 [email protected]. Department of Veterans Affairs 518-449-0693 [email protected]'s Health Specialists 315-253-6257 [email protected]

858-826-3360 [email protected] and Drug Administration /CDER 301-594-5411 [email protected] Micro Systems, Inc. 206-441-2400 [email protected] Permanente 808-432-5430 [email protected] Memorial Hospital 312-926-7948 [email protected] Manor Care 419-252-5688 [email protected]

Misys Healthcare Systems 520-733-6389Mayo Clinic/Foundation 507-284-2013 [email protected] Medical Group (918)748-7890 [email protected] Permanente 714-562-3456 [email protected]

U.S. Department of Veterans Affairs-OIFO,Salt Lake

[email protected]

Siemens Medical Solutions Health Services Corp.

[email protected]@GPinformatics.com

National Center for Health Statistics/CDC

U.S. Department of Defense, Health Affairs

(601) 978-6800 x3021

California Department of Health Services-Rancho Co

GE Medical Systems - Information Technologies

ACTS Retirement - Life Communities, Inc.

SAIC - Science Applications International Corp

[email protected]

OMNI Medical Group (918)270-8735 [email protected]

703-575-6395 [email protected]

Medical Group Management Association 202-293-3450 [email protected] Healthcare, S.C. 262-532-6770 [email protected] Permanente 626-229-6635 [email protected]

[email protected]

Center for Aging Services Technologies 202-508-9463 [email protected] Auxilio Mutuo 787-306-1149 [email protected]

650-723-6979Kaiser Permanente 510-625-4992

Misys Healthcare Systems 520-570-2286Advanced Healthcare, S.C. 262-532-6770Kaiser Permanente 626-381-6624Food and Drug Administration / OC 301-827-3050Oracle Corporation - Healthcare 310-656-2024HL7 Canada Voter #2 416-481-2002Delta Dental Plans Association 630-574-6991

Misys Healthcare Systems 520-570-2298Food and Drug Administration 301-827-2336Physician Micro Systems, Inc. 206-441-2400

MeritCare Health System 218-333-5282

603-624-4366Epic Systems Corporation 608-271-9000Allscripts HealthCare Solutions 847 680-3515

301-435-1620HCR Manor Care 419-252-5500WVDHHR Bureau for Medical Services 304-558-1752Epic Systems Corporation +1-608-271-9000Family Practice Partners 615-890-9191Food and Drug Administration / CDRH 301-594-3880Northwestern Memorial Hospital 312-926-1790Fox Systems Inc. 480-423-8184Kaiser Permanente 626-381-4187

202-401-8266IntraNexus, Inc. 412-443-7946Advanced Healthcare 262-532-6800American College of Physicians 202-261-4550RxHub, LLC 651-855-3053OMNI Medical Group (918)744-3526Epic Systems Corporation 608-271-9000Oracle Corporation - Healthcare 415-507-4512Oracle Corporation - Healthcare 916-812-6906

SAIC - Science Applications International Corp

SAIC - Science Applications International Corp

Stanford Medical Informatics, Stanford University [email protected]

[email protected]

[email protected]@[email protected]@[email protected]

[email protected]

[email protected]@[email protected]

[email protected]. Department of Veterans Affairs Office of CIO [email protected]

[email protected]@allscripts.com

National Cancer Institute Center for Bioinformatic [email protected]

[email protected]@[email protected]@[email protected]@[email protected]@kp.org

National Information Infrastructure Office, US Department of Health [email protected]

[email protected]@[email protected]@[email protected]@[email protected]@oracle.com

Epic Systems Corporation 608-271-9000

Duke University Health System 919-684-6421Gartner 510-522-8135Food and Drug Administration / CDER 301-827-7752

202-690-7100

847-704-8737

[email protected]

[email protected]@[email protected]

U.S. Department of Health & Human Services [email protected] Medical Systems - Information Technologies [email protected]

BalloterAlfred M BareaAnand InumpudiAndrew Ury

Andrew WoyakAndy BushAndy GieslerAnn Nowlin, ACAnthony Sforza MD

Anthony YaegerB. Patrick Cahill

Barbara BoykinBarry Guinn

Barry Royer

Bob NuberBrenda OlsonBrian Crotty

Brian DeBuskBrian PechBrianna HildrethBruce Kleaveland

Bryan SageCalvin Beebe

Charles ParisotChristopher G. ChuteChristopher MasonCindy WengerClement McDonald MDCorey DalzielCorey GaardeCorey SpearsDan CobbDan Geddes

Daniel Drury

Daniel Jernigan MD

Daniel Pollock MDDann BormannDarice GrzybowskiDave Allard

Dave Tuma

David Channin MDDavid HarringtonDavid Markwell

David Metcalf

David Roberts

David WrightDeborah Green

Denny BrileyDerek BairdDiane CarrDianne Delamare

Don Mon

Dongwen WangDoug Smith

Douglas Pratt

Duane ThorneEdward LarsenEdwin MillerElizabeth MossElizabeth SmithEllen Anderson

Eric Rose, MD

Eric Teller

Eric YablonkaEvelyn HovengaFloyd Bradd, III, MDFrancine Kitchen

Francis HartelFrank RichardsFrank WilcoxFred StarkFreida HallGary Colvin

Gary DickinsonGavin Tong

Glen MarshallGrant GillisGregg Seppala

Gregory Thomas

Guy Paterson

Hans BuitendijkHarold Solbrig

Harry SolomonHedge StahmHelen Stevens

Helmut Koenig, M.D.HM GohHugh LyshkowJake HoidaJames Cimino MDJames Gabler

Jane CurryJay CrowleyJean Narcisi

Jeanne GreetJeffrey Blair

Jennie HarvellJerry OsheroffJessi FormoeJim McCain

Joan Duke

Joan MillerJoann LarsonJoAnn ZiyadJoe EstradaJoe UrbanskiJohn ChurinJohn DenningJohn Hatem

John LeschakJohn MayJohn PayneJohn RitterJohn Taylor MDJon Kimerle

Jonathan Silverstein MD

Jorge Ferrer

Jose Garcia

Joseph BourgeoisJoseph HerreraJoyce SensmeierJudith Warren PhDJune RosplochKatherine HollingerKathleen ConnorKathrynn PearsonKeith Ackley

Ken Rubin

Kent Spackman MD PhDKlaus VeilKlaus VeilKlaus VeilLarry Young

Laurecia Dailey-Evans

Lawney LovellLawrence FolkersLenel JamesLinda Fischetti RN MSLinda WalshLise Stevens

Lloyd McKenzie

Louis GordonLynda Sue WelchM. Michael ShabotMarc Nuwer

Marco Johnson

Margaret Weiker

Mark Diehl

Mark IvieMark Shafarman

Mark WebbMary Ann LavinMary Gerard

Mary HamiltonMary Jo DeeringMary Lou Della Fera

Margaret Haber BSN RN OCN

Marge Benham-Hutchins, RN, MSN

Matthew GreeneMelinda Jenkins

Michael Buchanan

Michael CassidyMichael Hennigan MDMichael Legg

Michael Rosencrance

Michael van CampenMichelle Clements

Michelle WilliamsonNancy LeRoy

Nancy OrvisNed Simpson

Nelwyn MadisonNicholas MasonNoam H. ArztNorman Gregory

Pam CothamPatrick LoydPatti HarrisonPaul BironPaul Carpenter MD

Paul SchluterPenny SanchezPeter Hendler MD

Peter KressPeter MacIsaacPeter MurrayPeter RonteyPhillip Gioia MD

Randy AdeRandy Levin MDRebecca TulsiRhonda SatoRichard DlugoRichard Keller

Richard WilliamsRick HaddorffRobert PaulsenRobert Dolin MD

Robert Gray

Robert Schlesinger

Robert TennantRoberta RischmannRobin Zimmerman

Ronald Kinney

Russell BodoffSally Montes

Samson TuSandra Stuart

Scott MattinglyScott NovogoratzScott RobertsonSema HashemiSergei SemenovShari DworkinSheila Frank

Shirley GarciaSteve GittermanSteve Scheer

Steven Clemenson

Steven WagnerStirling MartinStuart Scholly

Sue DubmanSue MitchellSue ThompsonSumit RanaSusan Andrews, MDSusan BoundsSusan FagenSusan FoxSuzanne Nagami

Ted KellarTerri BelangerThomson KuhnTim McNeilTim YoungTimothy EscherTom JonesTom Oniki

Suzie Burke-Bebee MS BSN RN

Vassil Peytchev

Wesley RishelWilliam Hess

William Yasnoff PhD

Yongjian Bao

W. Edward Hammond PhD

93 "Not Persuasive - The wording and concept in question as detailed by youAndrew Ur I94 Andrew Ur I

105 no proposed wording Calvin Bee I106 Persuasive - Typographical error will be corrected Calvin Bee I107 Persuasive in part: Not Persuasive: Author's suggestion that the functionCalvin Bee I108 “Not Persuasive. Your comment has merit and will require further revi Calvin Bee I109 Not Persuasive. Author’s proposal would adversely affect other functionsCalvin Bee I

111 The language change to indicate that registries supply links for retrieval Calvin Bee I

115 Persuasive. Reflects intention of the authoring group Calvin Bee I

121 Persuasive. Reflects intention of the authoring group to associate func Gavin Ton I122 Persuasive in part. Authoring groups intend to link all dependencies a Gavin Ton I123 Persuasive. Your comment reflects the authoring groups intent. We will SSHA I

129 Agree that clarification to the function description should be considered. SSHA I130 Persuasive. Authors' comment " 'There is no mention here of audits of cSSHA I131 “Not Persuasive. Your comment has merit and will require further revie SSHA-CCAI132 Persuasive. Reflects intention of the authoring group SSHA I

137 Persuasive with modification. Accept proposed wording change for the stRobert GraI138 “Not Persuasive. Your comment has merit and will require further revi Robert GraI139 "Not Persuasive - The wording and concept in question as detailed by yoRobert GraI

143 Need clarification from balloter. This may be duplicative if rationale fo Julie Richa I

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

146 “Not Persuasive. Your comment has merit and will require further revi Julie Richa I147 “Not Persuasive. Proposed function name is not the intent of the functionJulie Richa I148 “Not Persuasive. Your comment has merit and will require further revie Julie Richa I

158 duplicate comment Gavin Ton I

167 “Not Persuasive. Your comment has merit and will require further revi John MoehI168 “Not Persuasive. Your comment has merit and will require further revi Mark Ivie I169 John MoehI170 Yongjian B I

172 John MoehI

175 “Not Persuasive. Your comment has merit and will require further revie Yongjian B I176 "Not Persuasive - The wording and concept in question as detailed by yoYongjian B I177 "Not Persuasive - The wording and concept in question as detailed by y Yongjian B I178 Not-related because the comment pertains to the functional description. John MoehI179 “Not Persuasive. Proposed title or statement is not the intent of the functYongjian B I180 "Not Persuasive - The wording and concept in question as detailed by youJohn MoehI181 “Not Persuasive. Proposed function name is not the intent of the functionYongjian B I182 John MoehI

190 “Not Persuasive. Your comment has merit and will require further revi Corey DalziI

194 Persuasive. Your comment reflects the authoring groups intent. We will Ellen Ande I

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

205 Rate as possibly substative based on balloters assignment of vote (Maj-Neg). Simi I

208 Rate as possibly substative based on balloters assignment of vote (Maj-Neg). This I

212 Not Persuasive. Author’s proposed function name would alter the function. Author I

216 "Not Persuasive - The wording and concept in question as detailed by y Peter DeVaI217 Peter DeVaI

219 "Not Persuasive - The wording and concept in question as detailed by youFloyd BraddI

221 "Not Persuasive - The wording and concept in question as detailed by y Yongjian B I222 Not-related because the comment pertains to the functional description. John MoehI223 “Not Persuasive. Proposed title or statement is not the intent of the functYongjian B I224 "Not Persuasive - The wording and concept in question as detailed by youJohn MoehI225 “Not Persuasive. Proposed function name is not the intent of the functionYongjian B I226 John MoehI

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

Not Persuasive.  This function was carefully considered and approved by the SIG and identified a

273 Persuasive. Your comment reflects the authoring groups intent. We will Harold SolbI

282 need clarification from balloter. Harold SolbI283 Persuasive - Typographical error will be corrected Harold SolbI284 Persuasive in part: Not Persuasive: Author's suggestion that the functionHarold SolbI285 “Not Persuasive. Your comment has merit and will require further revi Harold SolbI286 Not Persuasive. Author’s proposal would adversely affect other functionsHarold SolbI

301 Persuasive - Reflects the intentions of the authoring group. HL7 AustralI302 Persuasive - Typographical error will be corrected HL7 AustralI

303 need clarification from balloter. Ditto for all sections at this level with HL7 AustralI304 Persuasive. Does not change intent of function to remove the parens ar HL7 AustralI

308 “Not Persuasive. Your comment has merit and will require further review.HL7 AustralI

313 “Not Persuasive. Your comment has merit and will require further revi Kathleen CI

315 Not Persuasive. However, the Functional model should have a glossary tLenel Jam I316 “Not Persuasive. Your comment has merit and will require further revie Mark Diehl I317 “Not Persuasive. Your comment has merit and will require further revie Mark Diehl I318 "Not Persuasive - The wording and concept in question as detailed by youMichael H I

322 Persuasive. Your comment reflects the authoring groups intent. We will B. Patrick CI331 Possibly duplicative B. Patrick CI332 Persuasive - Typographical error will be corrected B. Patrick CI333 Persuasive in part: Not Persuasive: Author's suggestion that the functionB. Patrick CI334 “Not Persuasive. Your comment has merit and will require further revi B. Patrick CI335 Not Persuasive. Author’s proposal would adversely affect other functionsB. Patrick CI

341 Persuasive. Reflects intention of the authoring group B. Patrick CI

348 Persuasive. Your comment reflects the authoring groups intent. We will Rick HaddoI

357 Possibly duplicative Rick HaddoI358 Persuasive - Typographical error will be corrected Rick HaddoI359 Persuasive in part: Not Persuasive: Author's suggestion that the functionRick HaddoI360 “Not Persuasive. Your comment has merit and will require further revi Rick HaddoI361 Not Persuasive. Author’s proposal would adversely affect other functionsRick HaddoI

367 Persuasive. Reflects intention of the authoring group Rick HaddoI373 "Not Persuasive - The wording and concept in question as detailed by youSusan And I

377 “Not Persuasive. Your comment has merit and will require further revi Vicki Hohn I

385 Persuasive - Reflects the intentions of the authoring group. Yongjian B I386 “Not Persuasive. Your comment has merit and will require further revi John MoehI387 “Not Persuasive. Your comment has merit and will require further revi Mark Ivie I388 John MoehI

394 “Not Persuasive. Your comment has merit and will require further revie Yongjian B I395 "Not Persuasive - The wording and concept in question as detailed by yoYongjian B I959 Cindy Wen I

1001 “Not Persuasive. Your comment has merit and will require further reviewCharlene I1002 “Not Persuasive. Your comment has merit and will require further revi Charlene I1003 Persuasive. Authoring groups intend to link all dependencies among thCharlene I1023 Persuasive. Your comment reflects the authoring groups intent. We will Paul CarpeI1032 Possibly duplicative Paul CarpeI

1034 Persuasive in part: Not Persuasive: Author's suggestion that the functionPaul CarpeI

1036 “Not Persuasive. Your comment has merit and will require further revi Paul CarpeI1037 Not Persuasive. Author’s proposal would adversely affect other functionsPaul CarpeI

1043 Persuasive. Reflects intention of the authoring group Paul CarpeISort by Chapter

Your Rationale for the Disposition Submitted Field24

The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function.

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

Statement Maj - Neg Delete the wBetter yet, Priorities Not PersuasiveMin - Neg Examples in descriptio Priorities Not Persuasive

I.2 NA Manage EHR information across EHR-PrioritiesI.2.1 Aff-S Retain, ensure availabiEdit & CommSimple: Already done, duplicateI.2.2 Aff-S Comment It PrioritiesI.2.3 Min - Neg Negative Mi Priorities Considered and parked for future DSTU activitiesI.2.4 Maj - Neg Manage data extractionNegative MaPriorities

I.3.1 NA Enable system communication with Priorities

I.5 Aff-C Provide automate healtEdit Repla Priorities

Aff-S There shoulPrioritiesAff-S There shoulPriorities

Statement Maj - Neg AuthenticatAuthenticatAuthenticatComplex: Needs more info, research or review

Statement Maj - Neg Either the PrioritiesStatement Min - Neg Provide audit trail cap There is no PrioritiesName Min - Neg Needs a ve Priorities Considered and parked for future DSTU activitiesStatement Aff-T Provide autProvide autTypo - aut Priorities

Statement Min - Neg Provide autProvide autName Min - Neg Per my remaPriorities Considered and parked for future DSTU activitiesStatement Min - Neg What rules?Priorities Not Persuasive

Statement Min - Neg This functi Priorities

• Tracking amendments to clinical documents.• Tracking amendments to clinical documents.

Suggest explicity drawing out the technical solutions as separate functions and in each case defining them as standards based to support application interoperability e.g Standards-based API, Standards-based EDI, standards-based connectivity and etc.

exchanging information with partners. . .

Tracking amendments to clinical documents

Name Aff-S Support theMessaging This functi Priorities Considered and parked for future DSTU activitiesName Aff-S Entity Dire The name dPriorities Not PersuasiveStatement Aff-S Support interaction wi The word "eSimple: Request is already in another section or functionConsidered and parked for future DSTU activities

Statement Aff-S Dependant uPriorities

Statement Min - Neg Provide audProvide audRecording ePriorities Considered and parked for future DSTU activitiesMin - Neg SynchronizaPriorities Considered and parked for future DSTU activities

Statement Min - Neg Enable secuEnable secu PrioritiesName Min - Neg Distributed Distribute There are t Priorities Resolved in another section or functions

Statement Min - Neg ConceptuallNeed to conPriorities Not Persuasive

Name Min - Neg InteroperabSystem InteThe functio Policy Considered and parked for future DSTU activitiesName Min - Neg Interchang Data Interchange Priorities Not PersuasiveStatement Min - Neg Support theSupport theRemove secoPriorities Not PersuasiveStatement Min - Neg Similar to Similar to Remove workSimple: Not relatedComment made on reference material – not persuasiveName Min - Neg Application Application integration Priorities Not PersuasiveStatement Min - Neg Support int Support int The functio Priorities Not PersuasiveName Min - Neg Interchang Entity interchange prof Priorities Not PersuasiveName Maj - Neg Manage the Remove thiBusiness ru Priorities Not Persuasive

Statement Min - Neg Audit trail Priorities Considered and parked for future DSTU activities

Statement Maj - Neg AuthenicateAuthenicateSimple: Already done, duplicate

Retrieve of patient health record is usually not part of registry and directory services' functions. It needs to be addressed with interchange standards.Location of the resource is overly burdonsome. The location function should not be required in this function.

Seems the 'Manage the sets' sentence would better serve in I.1.3. If it is used here to denote a relationship with the first statement, I would show it directly

Statement Maj - Neg Clinical int Priorities

Name Maj - Neg Clinical in Priorities

Name Maj - Neg SynchronizRecord Syn Priorities Not Persuasive

Statement Aff-C Vague. Unc Priorities Not PersuasiveName Aff-C Remove Vague and oPriorities Not Persuasive

Name Maj - Neg Entire item Automated iPriorities Not Persuasive

Statement Min - Neg Support theSupport theRemove secoSimple: Already done, duplicate Not PersuasiveStatement Min - Neg Similar to Similar to Remove workSimple: Already done, duplicateComment made on reference material – not persuasiveName Min - Neg Application Application integration PrioritiesStatement Min - Neg Support int Support int The functioSimple: Already done, duplicate Not PersuasiveName Min - Neg Interchang Entity interchange profSimple: Already done, duplicate Not PersuasiveName Maj - Neg Manage the Remove thiBusiness ru Priorities Already resolved, duplicate comment, canned text

•Tracking amendments to clinical documents.•Tracking attestation and documentation closure practices to attain record completeness.

Clinical Concept Dictionary

I have included statements about many other required EHR synchronizations in my ballot response and need to avoid confusion.

I.1.1 I.1.1 I.1.1 Maj - Neg Authenticate EHR-S usNegative MaSimple: Already done, duplicate

I.2 I.2 I.2 H NA Manage EHR information across EHR-PrioritiesI.2.1 I.2.1 I.2.1 Aff-S Retain, ensure availabiEdit & CommSimple: Request is already in another section or functionI.2.2 I.2.2 I.2.2 Aff-S Comment It Simple: Already done, duplicateI.2.3 I.2.3 I.2.3 Min - Neg Negative MiSimple: Already done, duplicate Considered and parked for future DSTU activitiesI.2.4 I.2.4 I.2.4 Maj - Neg Manage data extractionNegative MaPriorities

Name Yes Min - Neg Data RetentData Retention Availab PrioritiesStatement Aff-S proscribed Simple: Already done, duplicate

• Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally proscribed retention• Providing the ability to destroy EHR data/records in a systematic way according to policy and after the legally prescribed retention

Statement Maj - Neg Remove statNot approprDitto for al PrioritiesStatement Maj - Neg The parentheses around 'or disable' inappropr

Statement Maj - Neg Remove statement or cDitto for al Policy Considered and parked for future DSTU activities

Aff-S An EHR-S wiAn EHR-S wiLike other Priorities

Statement Aff-S Spell out Policy Not PersuasiveMaj - Neg Throughout Add approprThere is an PrioritiesMaj - Neg Throughout Add approprA rationale Priorities Considered and parked for future DSTU activities

Name Maj - Neg Entire item Automated iSimple: Already done, duplicate Not Persuasive

I.1.1 Maj - Neg Authenticate EHR-S usNegative MaSimple: Already done, duplicateI.2 NA Manage EHR information across EHR-PrioritiesI.2.1 Aff-S Retain, ensure availabiEdit & CommSimple: Already done, duplicateI.2.2 Aff-S Comment It Simple: Already done, duplicateI.2.3 Min - Neg Negative MiSimple: Already done, duplicate Considered and parked for future DSTU activitiesI.2.4 Maj - Neg Manage data extractionNegative MaPriorities

I.5 NA Provide automate healtEdit ReplaSimple: Already done, duplicate

I.1.1 Maj - Neg Authenticate EHR-S usNegative MaSimple: Already done, duplicate

I.2 NA Manage EHR information across EHR-PrioritiesI.2.1 Aff-S Retain, ensure availabiEdit & CommSimple: Already done, duplicateI.2.2 Aff-S Comment It Simple: Already done, duplicateI.2.3 Min - Neg Negative MiSimple: Already done, duplicate Considered and parked for future DSTU activitiesI.2.4 Maj - Neg Manage data extractionNegative MaPriorities

overrides of applied business rules.overrides of applied business rules.

I.5 NA Provide automate healtEdit ReplaSimple: Already done, duplicateName Maj - Neg Entire item Automated iSimple: Already done, duplicate Not Persuasive

Aff-S An EHR-S wiAn EHR-S wiLike other Priorities Considered and parked for future DSTU activities

Statement Min - Neg Change the term "clini PrioritiesStatement Min - Neg Provide audProvide audRecording eSimple: Already done, duplicate

Min - Neg SynchronizaSimple: Already done, duplicateStatement Min - Neg Enable secuEnable secu Priorities

Name Min - Neg InteroperabSystem InteThe functio Priorities Already resolved, duplicate comment, canned textName Min - Neg Interchang Data InterchangeSimple: Already done, duplicate Not PersuasiveName Aff-C Remove Vague and oPriorities Not PersuasiveStatement Maj - Neg Eliminate t Priorities Considered and parked for future DSTU activitiesStatement Min - Neg Split this Priorities Considered and parked for future DSTU activitiesStatement Aff-S These capabPrioritiesI.1.1 Maj - Neg Authenticate EHR-S usNegative MaSimple: Already done, duplicateI.2 NA Manage EHR information across EHR-Priorities

I.2.2 Aff-S Comment It Simple: Already done, duplicate

I.2.3 Min - Neg Negative MiSimple: Already done, duplicate Considered and parked for future DSTU activitiesI.2.4 Maj - Neg Manage data extractionNegative MaPriorities

I.5 NA Provide automate healtEdit ReplaSimple: Already done, duplicateSort by Chapter Your recommended disposition on the Comment.

Section Pubs Vote and TExisting W Proposed Comments Priorities Not_RelateNot_Persua

Location of the resource is overly burdonsome. The location function should not be required in this function.

Not Persuasive Probably "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.Not Persuasive Probably

Not no proposed wordingPersuasive – minor editorial or typos Not Persuasive Action Item

Persuasive (accept part, reject parNot Persuasive Action ItemConsidered and parked for future DSTU activities Not “Not PersuaCandidate Issue

Not Not PersuasCandidate Issue

Substantiv The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function.

Persuasive – minor editorial or typos Not Persuasive. Reflects intention of the authoring group

Persuasive (with modification), mi Not Persuasive.Candidate IssuePersuasive – clarification simple Not Persuasive Action Item Persuasive – clarification simple Not Persuasive.Action Item

Persuasive Not Agree that clarification to the function description should be considered.Persuasive – clarification simple Not Persuasive.Action Item

Considered and parked for future DSTU activities Not “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ CPersuasive – minor editorial or typos Not Persuasive. Reflects intention of the authoring group

Persuasive (accept part, reject parNot Persuasive Note that the "persuavie with Modification" accept part/reject part should also include option to part the rejected partConsidered and parked for future DSTU activities Not “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment periodNot Persuasive Not "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordi

Unclear; needs more inNot Need clarification from balloter. This may be duplicative if rationale for Min-Neg vote is described elsewhere within this section by another balloter

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

Suggest explicity drawing out the technical solutions as separate functions and in each case defining them as standards based to support application interoperability e.g Standards-based API, Standards-based EDI, standards-based connectivity and etc.

Considered and parked for future DSTU activities Not “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment periodNot Persuasive Probably “Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of theConsidered and parked for future DSTU activities Not “Not PersuaAction Item

Persuasive Not duplicate comment

Considered and parked for future DSTU activities Not “Not PersuaCandidate IssueConsidered and parked for future DSTU activities Not “Not PersuaCandidate Issue

Persuasive (accept part, reject parPossibly Sunanda McGarveyResolved in another section or functions Substantiv Sunanda McGarvey

Not Persuasive Substantiv

Considered and parked for future DSTU activities Not “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ Not Persuasive Possibly "Not PersuaPossibly substantive because author is asserting that this function should be limited to data standards, which was not the intent of the authoring groNot Persuasive Possibly "Not PersuaPossibly substantive because author is asking to reduce functionality asserting that it is covered in I 4.

Comment made on reference material – not persuasive Substantiv Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of Not Persuasive Not “Not Persuasive. Proposed title or statement is not the intent of the function.”Not Persuasive Not "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordingNot Persuasive Not “Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of theNot Persuasive Probably

Considered and parked for future DSTU activities Not “Not PersuaCandidate Issue

Persuasive – clarification simple Not Persuasive.Action Item

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

Persuasive_W_Mods Possibly Rate as possibly substative based on balloters assignment of vote (Maj-Neg). Similar wording expressed by others. We agree with the presumed intent of the

Needs more review andPossibly Rate as possibly substative based on balloters assignment of vote (Maj-Neg). This is asking for new subfunction and needs more review/info from balloter. N

Not Persuasive Not Not Persuasive. Author’s proposed function name would alter the function. Authoring group intended synchonization of applications and information artefacts

Not Persuasive Not "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current worNot Persuasive Probably

Not Persuasive Probably "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin

Not Persuasive Possibly "Not PersuaPossibly substantive because author is asking to reduce functionality asserting that it is covered in I 4.Comment made on reference material – not persuasive Not Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of

Not “Not Persuasive. Proposed title or statement is not the intent of the function.”Not Persuasive Not "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordingNot Persuasive Not “Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of theAlready resolved, duplicate comment, canned text Probably

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as

Not Persuasive.  This function was carefully considered and approved by the SIG and identified a

Persuasive – clarification simple Not Persuasive.Action Item

Unclear; needs more inNot need clarification from balloter. Persuasive – minor editorial or typos Not Persuasive Action Item

Persuasive (accept part, reject parNot Persuasive Action ItemConsidered and parked for future DSTU activities Not “Not PersuaCandidate Issue

Not Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Persuasive – minor editorial or typos Not Persuasive Action ItemPersuasive – minor editorial or typos Substantiv Persuasive Action Item

Pending Possibly need clarification from balloter. Ditto for all sections at this level with this comment….Persuasive – minor editorial or typos Not Persuasive.Action Item

Considered and parked for future DSTU activities Not “Not PersuaWe need to make a uniform decision about how to handle this structural comment. There was alot of controversy about this, although it is not a substanti

Possibly “Not PersuaCandidate Issue

Not Persuasive Not Not Persuasive. However, the Functional model should have a glossary that spells out all acronyms , defines the terms and points to resources related to the tNot “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. “

Considered and parked for future DSTU activities Not “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. “Not Persuasive Probably "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin

Persuasive – clarification simple Not Persuasive.Action ItemUnclear; needs more inNot Possibly duplicative

Persuasive – minor editorial or typos Not Persuasive Action ItemPersuasive (accept part, reject parNot Persuasive Action Item

Considered and parked for future DSTU activities Not “Not PersuaCandidate IssueNot Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Not Persuasive. Reflects intention of the authoring group

Persuasive – clarification simple Not Persuasive.Action Item

Unclear; needs more inNot Possibly duplicativePersuasive – minor editorial or typos Not Persuasive Action Item

Persuasive (accept part, reject parNot Persuasive Action ItemConsidered and parked for future DSTU activities Not “Not PersuaCandidate Issue

Not Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Not Persuasive. Reflects intention of the authoring groupNot Persuasive Probably "Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin

Considered and parked for future DSTU activities Probably “Not PersuaCandidate Issue

Persuasive – minor editorial or typos Not Persuasive Action ItemNot “Not PersuaCandidate IssueNot “Not PersuaCandidate Issue

Persuasive (accept part, reject parPossibly

Already resolved, duplicate comment, canned text Not “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “Not Persuasive Possibly "Not PersuaPossibly substantive because author is asserting that this function should be limited to data standards, which was not the intent of the authoring groNot Persuasive ProbablyConsidered and parked for future DSTU activities Possibly “Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ WConsidered and parked for future DSTU activities Probably “Not PersuaCandidate Issue

Persuasive (accept part, reject parNot PersuasivAction Item in partPersuasive – clarification simple Not Persuasive.Action Item

Unclear; needs more inNot Possibly duplicative

Persuasive (accept part, reject parNot Persuasive Action Item

Considered and parked for future DSTU activities Not “Not PersuaCandidate IssueNot Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Not Persuasive. Reflects intention of the authoring groupYour recommended disposition on the Comment.

PersuasivePersuasiv Pending ConsideredSubstantiv Your RationOther Note Reviewer Additional

The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function.

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function.

Persuasive. Reflects intention of the authoring group

Agree that clarification to the function description should be considered.

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ CPersuasive. Reflects intention of the authoring group

Note that the "persuavie with Modification" accept part/reject part should also include option to part the rejected part“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordi

Need clarification from balloter. This may be duplicative if rationale for Min-Neg vote is described elsewhere within this section by another balloter

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ Possibly substantive because author is asserting that this function should be limited to data standards, which was not the intent of the authoring groPossibly substantive because author is asking to reduce functionality asserting that it is covered in I 4.

Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of “Not Persuasive. Proposed title or statement is not the intent of the function.”"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function.

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function

Rate as possibly substative based on balloters assignment of vote (Maj-Neg). Similar wording expressed by others. We agree with the presumed intent of the

Rate as possibly substative based on balloters assignment of vote (Maj-Neg). This is asking for new subfunction and needs more review/info from balloter. N

Not Persuasive. Author’s proposed function name would alter the function. Authoring group intended synchonization of applications and information artefacts

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wor

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin

Possibly substantive because author is asking to reduce functionality asserting that it is covered in I 4.Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of “Not Persuasive. Proposed title or statement is not the intent of the function.”"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function."  

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

need clarification from balloter. Ditto for all sections at this level with this comment….

We need to make a uniform decision about how to handle this structural comment. There was alot of controversy about this, although it is not a substanti

Not Persuasive. However, the Functional model should have a glossary that spells out all acronyms , defines the terms and points to resources related to the t“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. ““Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. “"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Persuasive. Reflects intention of the authoring group

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Persuasive. Reflects intention of the authoring group"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “Possibly substantive because author is asserting that this function should be limited to data standards, which was not the intent of the authoring gro

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ W

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an

Persuasive. Reflects intention of the authoring group

Additional Column 2

The language change to indicate that registries supply links for retrieval is accepted and reflects the original intention of the function.

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

11111

1

1

111

11

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ C 11

1“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period 1"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordi 1

1

for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period 1“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the 1

1

1

1111

1

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ 1Possibly substantive because author is asserting that this function should be limited to data standards, which was not the intent of the authoring gro 1

1Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of 1

1"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording 1“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the 1

1

1

1

for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function.

for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function

Rate as possibly substative based on balloters assignment of vote (Maj-Neg). Similar wording expressed by others. We agree with the presumed intent of the 1

Rate as possibly substative based on balloters assignment of vote (Maj-Neg). This is asking for new subfunction and needs more review/info from balloter. N 1

Not Persuasive. Author’s proposed function name would alter the function. Authoring group intended synchonization of applications and information artefacts 1

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wor 11

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin 1

1Not-related because the comment pertains to the functional description. The authoring group intended the description to capture the complimentary nature of 1

1"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording 1“Not Persuasive. Proposed function name is not the intent of the function. The author's suggested renaming would limit the function name to only a portion of the 1

1

for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function."  

1

1111

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an 1

11

11

We need to make a uniform decision about how to handle this structural comment. There was alot of controversy about this, although it is not a substanti 1

1

Not Persuasive. However, the Functional model should have a glossary that spells out all acronyms , defines the terms and points to resources related to the t 1“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. “ 1“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.. “ 1"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin 1

11111

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an 1

1

1

1111

Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an 1

1"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wordin 1

1

1111

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period. “ 1Possibly substantive because author is asserting that this function should be limited to data standards, which was not the intent of the authoring gro 1

1“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the upcoming DSTU comment period.“ W 1

1111

1

1Not Persuasive. Author’s proposal would adversely affect other functions that depend on this function. Patient specific extracts are described in Direct Care an 1

111

Not Persuasive.  This function was carefully considered and approved by the SIG and identified as Essential now or Future for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the exclusion of this function. Author’s proposal would adversely affect other functions that depend on this function.

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.for one or more care settings/profiles.  Your comment does not provide any new information that would justify re-considering the inclusion of this function

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. The current wording accurately reflects the intent and meaning of the EHR SIG.” The concept of reliability covers issues such as availability, volume, and manner in which EHR interchanges will be handled by trading partners. Author's proposal would adversely affect other functions that depend on this function. We are not proposing an average system or just current systems, we appreciate that this function may only feasible in the near future or for sophisticated systems - but it has been approved as a important functionality.

II ReviewI.1 SecurityI.1.1 Entity AuthenticationI.1.2 Entity Authorization.I.1.3 Entity Access Control

I.1.3.1I.1.4 Non-repudiationI.1.5 Secure Data ExchangeI.1.6 Secure Data RoutingI.1.7 Document Attestation

I.1.8

I.2

I.2.1I.2.2 Audit trailI.2.3 Synchronization

I.2.4

I.3

I.3.1

I.4

I.4.1

I.4.2

I.5

I.5.1 Interchange Standards >

I.5.2I.5.3 Interchange Agreements spreadsheet needs fixed - see kc a

I.6 spreadsheet needs fixed - see kc aI.7 Workflow

PreReview

Patient Access Management

Enforcement of Confidentiality

Health record information and managementData Retention and Availability

Extraction of health record informationUnique identity, registry, and directory servicesDistributed registry accessHealth Informatics and Terminology Standards

Maintenance and versioning of health informatics and terminology standards.

Mapping local terminology, codes, and formatsInteroperability Standards

Application Integration Standards

Business Rules Management

Disposition DispositionDefined Priorities

Refer Resolved

Pending EHR SIG

Persuasive

Inter-team

Pending

Use this to refer the submitted ballot line item comment to another committee.

Use this to refer the submitted ballot line item for guidance or interpretation, for example, to the ARB.

The committee has accepted the ballot comment as submitted and will make the appropriate change.

HL7 Policy Related

Persuasive with Mod

The committee believes the ballot comment has merit, but has changed the proposed solution given by the voter.

Not Persuasive

The committee does not believe the ballot comment has merit or is unclear… requires an affirmative vote of at least two-thirds.

Not Related Discuss

Considered

Withdraw

Withdraw

The TC has determined that the ballot comment is not relevant …requires an affirmative vote of at least two-thirds…

The TC, (editor or task force), has reviewed the item and has determined that no change will be made to the standard at this time… The reviewer should comment (to the voter) on the result

This code is used when the submitter agrees to "Withdraw" the negative line item…. If the negative balloter agrees to "Withdraw" a negative line item it must be recorded in the ballot spreadsheet. NOTE: Withdrawals are counted as affirmative votes.

The balloter has been convinced by the committee to retract their ballot item. This may be due to a …misunderstanding about the content. NOTE: Retractions of the whole vote is as if it never was submitted, so it is not counted in the final tally.

Boiler Plate

Where a balloter’s comment revisits an issue previously addressed by the EHR SIG, or demonstrates an inaccurate understanding of the purpose/basis of the function:

"Not Persuasive - The wording and concept in question as detailed by your suggestion, was previously addressed by the authoring work group. After careful consideration, the SIG decided that the current wording accurately reflects the intended meaning.”

Suggestions to delete function as "overreaching” or not currently feasible/realistic or has complex implementation issues that are not explicit."

"Not Persuasive.  This function may be a stretch-goal, however it is believed that the functions are a superset of all functions that can or should be provided by EHR-S’ (both now and in the future). This function was carefully considered and approved by the SIG and identified as Essential now or Essential Future for one or more care settings/profiles.”

For suggestions to combine (roll up) functions where granularity would be lost. 

"Not Persuasive. The functions in question must remain separate to differentiate the needs of different care settings/profiles." 

For multiple suggestions about a single issue that we agree is a problem, but we accept only the best, or an alternate solution. 

"Persuasive with mods.  We agree with the intent of your comment and offer the alternate wording of "..............." to best capture the revision that you have identified.

For suggestions to change the name or statement text in a way that does not match the goal and intent of the functions as reviewed and approved by the SIG:

“Not Persuasive. Proposed Functional Name change alters the intent of the function.”

For suggestions to change the name or statement text in a way that does not match the goal and intent of the functions as reviewed and approved by the SIG:

“Not Persuasive. Proposed Functional Statement change alters the intent of the function.”

The suggestions, comments or recommendation made reflect a misunderstanding of the intention. Minor or modest changes have been made, taking into account varied voter input, to provide more clarity of the DSTU intent in this area:

“Persuasive, with Mods. The Functional Name or Functional Statement was unclear; corrections have been made to provide greater clarity.”

The voter is concerned that there is not a description for the function, for which the WG/SIG thinks a description is not needed or that one at the parent level is adequate or appropriate.

“Not Persuasive. Descriptions not required for each function, they are optional reference information”

The Voter is concerned that there is not consistency with headers.

“Not Persuasive. The issue of standard formatting for headers will be taken under consideration for future DSTU activities.

The voter thinks the function is outside the scope and wants the function deleted or changed substantially.

“Not Persuasive. Though this function may be a separate function in some systems, it may be integral to others. As such, after careful consideration, the SIG decided that this function was inside the scope of an EHR-S.

The voter has a valid issue and some quality recommendations, but the implications of their proposals are complex, and/or time consuming, and will dictate further study and analysis to determine how to best incorporate and assess their suggestion.

“Not Persuasive. Your comment has merit and will require further review. We will assess your recommendations as part of the future standard development.“

The voter has a recommendation that affects dependencies:

“Not Persuasive. Author's proposal would adversely affect other functions that depend on, or are related to, this function.“