Long-Term Care-Nursing Homes EHR-Systems Functional Profile: Release 1. Supportive Functions

07/01/2008

HL7 LTC-Nursing Home EHR-S Functional Profile (based on the HL7 EHR-S Functional Model, February 2007) -- Supportive Functions

Priority Column: EN = Essential Now; EF = Essential Future; O = Optional

Functional Model (FM) Source Column -- Criteria Status is either: N/C = no change; A=added; M=modified; D = deleted. For new children functions, the FM Source columns is blank.

Blue, Underscored text = addition to text from the HL7 EHR-S Functional Model; Strikethrough text = HL7 EHR-S Functional Model text deleted for the LTC Functional Profile

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1 H EN Clinical Support     1.  The system SHALL conform to function IN.1.1 (Entity Authentication). 1 S.1 1 N/C
2.  The system SHALL conform to function IN.1.2 (Entity Authorization). 2 S.1 2 N/C
3.  The system SHALL conform to function IN.1.3 (Entity Access Control). 3 S.1 3 N/C
4. The system SHALL conform to function IN.1.4 (Patient Access Management) 4     A
5. The system SHALL conform to function IN.1.5 (Non-Repudiation) 5     A
6. The system SHALL conform to function IN.1.6 (Secure Data Exchange) 6     A
7. The system SHALL conform to function IN.1.8 (Information Attestation) 7     A
8. The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality) 8     A
9. The system SHALL conform to function IN.1.10 (Secure Data Routing – LTC) 9     A

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.1 F O Registry Notification Statement: 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.

Description: The user can export personal health information to disease specific registries, other notifiable registries such as immunization registries, through standard data transfer protocols or messages. The user can update and configure communication for new registries.

IN.2.4
IN.4.1
IN.4.2
IN.5.1
IN.5.2
IN.5.4
1.  The system SHOULD automatically SHALL provide the ability to  transfer formatted demographic and clinical information to local disease specific registries (and or other notifiable registries) as directed by scope of practice, organizational policy or jurisdictional law. 10 S.1.1 1 M
2.  The system MAY provide the ability to automate the retrieval of formatted demographic and clinical information from local disease specific registries (and or other notifiable registries). 11 S.1.1 2 M
3.  The system SHOULD SHALL provide the ability to add, change, or remove access to registries. 12 S.1.1 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.2 F O Donor Management Support Statement: Provide capability to capture or receive, and share needed information on potential donors and recipients.

Description: The user is able to capture or receive information on potential donors and recipients (for products such as blood, organs, eggs, sperm, or stem cells eye, cadaver, etc.). The user can make this information available to internal and external donor matching agencies.

IN.1.7
IN.2.4
1.  The system MAY SHALL provide the ability to document capture demographic and clinical information needed for the donation. 13 S.1.2 1 M
2.  The system MAY receive demographic and clinical information about potential donors. 14 S.1.2 2 D
3.  The system MAY receive demographic and clinical information about the donation. 15 S.1.2 3 D
4.  The system MAY share communicate documented demographic and clinical information about potential donors with appropriate outside parties. 16 S.1.2 4 M
5.  The system MAY share communicate documented demographic and clinical information about the donation with appropriate outside parties (e.g. donor management organization, eye bank, surgeon). 17 S.1.2 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3 H EN Provider Information Statement: Maintain, or provide access to, current provider information. IN.1.3
IN.4
  18 S.1.3   N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.1 F EN Provider Access Levels Statement: Provide a current registry or directory of practitioners that contains data needed to determine levels of access required by the system.

Description: Provider information may include any credentials, certifications, or any other information that may be used to verify that a practitioner is permitted to use or access authorized data.

IN.2.3
IN.3
1.  The system SHOULD provide SHALL create and maintain a registry or directory of all personnel who currently use or access the system. 19 S.1.3.1 1 M
2.  The system SHOULD contain, in the directory, the SHALLprovide the ability to capture realm-specific legal identifiers required for care delivery such as the practitioner's license number as discrete data elements, including the NPI, practitioner's license number and other identifiers as required by scope of practice, organizational policy, or jurisdictional law. 20 S.1.3.1 2 M
3.  The system SHOULD SHALL provide the ability to add, update, and inactivate entries in the directory so that it is current. 21 S.1.3.1 3 M
4.  The system SHOULD contain, in the directory, the information necessary to determine levels of access required by the system security functionality. 22 S.1.3.1 4 N/C
5.  The system MAY provide SHOULD create and maintain a directory of clinical personnel external to the organization, that are not users of the system, to facilitate documentation communication and information exchange (i.e., e-mail alert for change in condition, critical lab value to  a dialysis center, etc.). 23 S.1.3.1 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.2 F O Provider's Location Within Facility Statement: Provide provider location or contact information on a facility's premises.

Description: The identification of provider’s location within a facility may facilitate the handling of critical care situations. This may include the location of on site practitioners by name or immediate required specialty. A real-time tracking system may provide automatic update of such information.

  1.  The system SHOULD SHALL provide the ability to input or create information on provider location or contact information on a facility's premises. 24 S.1.3.2 1 M
2.  The system SHOULD SHALL provide the ability to add, update, or inactivate information on provider's location or contact information on a facility's premises, so that it is current. 25 S.1.3.2 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.3 F EN Provider's On Call Location Statement: Provide provider location or contact information when on call.

Description: The provider immediate contact information. This may include on call practitioners on a facility’s premises as well as on call contact information (e.g., phone number, pager, cell phone, etc.) after scheduled working hours.

IN.2.3 1.  The system SHOULD SHALL provide the ability to input or create information on provider on-call location or contact information when on call. 26 S.1.3.3 1 M
2.  The system SHOULD SHALL provide the ability to add, update, or obsolete inactivate information on a provider's on call location or contact information, so that it is current. 27 S.1.3.3 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.4 F EN Provider's Location(s) or Office(s) Statement: Provide locations or contact information for the provider in order to direct patients or queries.

Description: Providers may have multiple locations or offices where they practice. The system should shall capture and maintain information necessary to identify and contact practice locations or offices of providers, and may include information such as on the primary location, any secondary locations, as well as the scheduled hours at each location, Information maintained may include web sites, maps, office locations, etc.

IN.2.3 IN.3 1.  The system SHOULD SHALL contain capture information necessary to identify and contact primary and secondary practice locations or offices of providers to support communication and access. 28 S.1.3.4 1 M
2.  The system SHOULD SHALL provide the ability to add, update and inactivate obsolete information necessary to identify and contact on the provider's primary and secondary practice locations or offices of providers. 29 S.1.3.4 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.5 F O Team/Group of Providers Registry or Directory Statement: Provide access to a current directory, registry or repository of information on Teams or Groups of providers in accordance with relevant laws, regulations, and organization or internal requirements.

Description: An organization may assign caregivers to teams that need to be registered as such. In another scenario, an organization might contract with a group of providers. The group would be listed by the group name or individually or both. A caregiver might be part of more than 1 team or group. All of these factors need to be supported. Information includes, but is not limited to; full name, address or physical location, and a 24x7 telecommunications address (e.g., phone or pager access number).

IN.2.3 1.  The system SHOULD SHALL provide the ability to access a current directory, registry or repository of Teams or Groups of providers in accordance with relevant laws, regulations, and organization or internal requirements. 30 S.1.3.1 1 M
2.  The system SHOULD conform to IN.3 (Registry and Directory Services), Conformance Criteria #13 (The system MAY provide the ability to use registries or directories to identify healthcare resources and devices for resource management purposes). 31 S.1.3.1 2 N/C
3.  The system SHOULD conform to S.3.4 (Manage Practitioner/Patient Relationships), Conformance Criteria #2 (The system SHALL provide the ability to specify the role of each provider associated with a patient such as encounter provider, primary care provider, attending physician, ophthalmologist, psychologist, dentist, podiatrist, geriatric nurse practitioner, physician assistant, resident, or consultant). 32 S.1.3.1 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.6 F EN Provider Caseload/Panel Statement: Provide access to a provider's caseload or panel information.

Description: An organization might employ the concept of A facility may maintain a caseload or panel of patients to facilitate continuity of care and distribution of work.

A caregiver may have, or be accountable for, zero to multiple defined caseloads or panels of members/patient/clients within the organization.

Information about the caseload or panel includes such things as whether or not a new member/patient/client can be added.

A member/patient may be provided access to a listing of caregivers with open caseloads or panels to select a provider.

  • For example, a wound care nurse (or team) may have a list of assigned residents based upon the resident's care needs. A list of these residents would be produced to assist that nurse in delivering care.
  • Another example might be a list of residents receiving hospice care. A list of those residents would be produced that were assigned to hospice care personnel.
  • A somewhat different example of this functionality would be the ability to identify those providers able to accept new patients
DC.1.7.2.4
DC.3.1.1
DC.3.1.3
IN.2.3
IN.2.4
1.  The system SHALL provide the ability to access a provider's resident caseload or panel information. 33 S.1.3.1 1 M
2.  The system SHALL provide the ability to add, update, and remove access to panel information such as status the provider’s resident caseload information. 34 S.1.3.1 2 M
3.  The system SHOULD SHALL conform to function S.3.4 (Manage Practitioner/Patient Relationships). 35 S.1.3.1 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.3.7 F EN Provider Registry or Directory Statement: Provide access to a current directory, registry or repository of provider information in accordance with relevant laws, regulations, and organization or internal requirements.

Description: A system maintains or has access to provider information needed in the provision of care. This is typically a directory, registry or repository. Information includes, but is not limited to; full name, specialty, credentials, address or physical location, and a 24x7 telecommunications address (e.g., phone or pager access number).

Views of the information are tailored to the user's security level and access need. For example, a nursing supervisor may need access to a provider's home phone. A member/patient wishing to select a primary care provider has a narrower view that would not include personal access information.

IN.1.3
IN.2.1
IN.3
1.  The system SHOULD conform to IN.3 (Registry and Directory Services), Conformance Criteria #7 (The system SHOULD provide the ability to use registries or directories to uniquely identify providers for the provision of care). 36 S.1.3.7 1 N/C
2.  The system SHALL contain provider information including (but not limited to) (such as full name, specialty, address and contact information, and NPI and license number (where applicable), in accordance with scope of practice, organizational policy and jurisdictional law. 37 S.1.3.7 2 M
3.  The system SHALL provide the ability to add, update, and remove access to entries in the registry or directory so that it is current. 38 S.1.3.7 3 N/C
4.  The system MAY SHOULD provide a directory of clinical personnel external to the organization that are not users of the system to facilitate documentation. 39 S.1.3.7 4 M
5.  The systems SHOULD SHALL provide the ability to restrict the view of selected elements of the registry or directory information, subject to the user's security level and access needs. 40 S.1.3.7 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.4 H EN Patient Directory Statement: Provide a current directory of patient information in accordance with relevant privacy and other applicable laws, regulations, and conventions.

Description: The patient directory may capture information including but not limited to, full name, address or physical location, alternate contact person, primary phone number, and relevant health status information. The view of this information may vary based on purpose, scope of practice, organizational policy or jurisdictional law. Several specific directory views are described in the following functions.

DC.1.1.1
IN.1.4
   41 S.1.4   M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.4.1 F EN Patient Demographics Statement: Support interactions with other systems, applications, and modules to enable the maintenance of updated demographic information in accordance with realm-specific recordkeeping requirements.

Description: The minimum demographic data set must include the data required by realm-specific laws organizational policy and jurisdictional law governing health care transactions and reporting. For example, this may include data input of death status information, or may include support to identify multiple names, such as updating from Baby Girl John Doe, to neonate's patient’s given name.

This function addresses exchange of demographic information with systems both internal and external to the organization such as between:

  • The facility and the external pharmacy services provider
  • The EHR ADT module and the facility’s Dietary Management system.
DC.1.3.3
S.1.4
S.3.7.3
IN.2.3
1.  The system MAY SHOULD provide the ability to reconcile add and update patient demographic information (subject to authorized user approval) through interaction with other systems, applications and modules. 42 S.1.4.1 1 M
2.  The system MAY SHALL accept and retrieve patient demographic information as required by realm specific laws governing health care transactions and reporting in accordance with IN.5.1 (Interchange Standards). 43 S.1.4.1 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.4.2 F EN Patient's Location Within a Facility Statement: Provide the patient's location information within a facility's premises.

Description: This function is intended to support maintaining and/or providing access to information on the patient's location during an episode of care. This function can be as simple as displaying the assigned bed for a patient (i.e., Adam, W2-Reb 214 West Wing Rm #214). It can also be a function that supports real-time information on the patient location as they receive ancillary services in other parts of a facility (such as physical therapy or diagnostic imaging in the Rehab Department).  

Note: For standard reports like an ER Log or a Census, see the Standard Reports function (S.2.2).  

The system should shall support viewing a patient’s specific location in terms that may include campus, building, wing, unit, room, bed.

The system should support jurisdictional laws related to patient consent on disclosure.

The patient location information should also be available when the provider is not in the patient record. As such, the systems may need to provide a query feature on patient location information.

The system may support the identification of the patient by alternate identifying names.

    1.  IF the patient has an assigned location, THEN the system SHALL provide the ability to identify and display/view the patient’s assigned location. 44 S.1.4.2 1 N/C
2.  The system SHOULD support consents as they apply to the release of patient location information according to scope of practice, organization policy, or jurisdictional laws. 45 S.1.4.2 2 N/C
3.  The system MAY provide the ability to identify the patient’s current, real-time location, unambiguously, within a facility. 46 S.1.4.2 3 N/C
4.  The system MAY SHALL provide the ability to query patient location information. 47 S.1.4.2 4 M
5.  The system MAY SHOULD provide the ability to query patient location by alternate identifying names. 48 S.1.4.2 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.4.3 F EN Patient's Residence for the Provision and Administration of Services Statement: Provide the patient's residence information for the provision and administration of services to the patient, patient transport, and as required for public health reporting.

Description: This function is intended to support the provision of services to patients at their place of residence. Examples include but are not limited to the following:

  • Visiting nurse may be providing care to a new mother and baby at their place of residence. SNF staff providing services to a resident of the organization’s assisted living facility.
  • A patient with a mobility problem may require transport to and from a clinic appointment.
  • Support identification of multiple residences for related to a patient like a child with multiple such as a guardians (divorced parents with joint custody) or adults with Winter/Summer residences.
DC 1.1.2 1.  The system SHOULD SHALL provide the ability to identify the patient’s primary residence. 49 S.1.4.3 1 M
2.  The system MAY SHALL provide the ability to identify the patient’s secondary or alternate residence. 50 S.1.4.3 2 M
3.  The system MAY provide the ability to enter and update patient information related to the provision of service. 51 S.1.4.3 3 N/C
4.  The system SHOULD provide the ability to enter and update patient information related to transport, such as, mobility status, special needs and facility access (stairs, elevator, wheelchair access). 52 S.1.4.3 4 N/C
5.  The system SHOULD SHALL provide the ability to enter and update patient residence information as necessary for public health reporting. 53 S.1.4.3 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.4.4 F EN Patient Bed Assignment Statement: Support interactions with other systems, applications, and modules to ensure that the patient's bed assignments within the facility optimize care and minimize risks (e.g., of exposure to contagious patients).

Description: Access to a list of available beds is important to safely manage the care of patients whose bed requirements may change based on change in condition or risk factors (for example, a patient may by gender, certification level, need for a room with special equipment such as oxygen, or need to be close to the nursing station/cohort by condition or to be in a private room, etc.).

S.1.7 IN.6 1.  The system SHOULD SHALL support interactions as required to support facilitate patient bed assignment internal or external to within the system. 54 S.1.4.4 1 M
1a.  The system SHOULD support interactions as required to facilitate patient bed assignment external to the system. 55     A
2.  The system MAY provide patient information to an external system to facilitate bed assignment that optimizes care and minimizes risk. 56 S.1.4.4 2 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.5 F O De-Identified Data Request Management Statement: Provide patient data in a manner that meets local requirements for de-identification.

Description: When an internal or external party requests patient data and that party requests de-identified data (or is not entitled to identified patient information, either by scope of practice, organizational policy or jurisdictional law or custom), the user can export the data in a fashion that meets requirements for de-identification in that locale or realm as required by scope of practice, organizational policy or jurisdictional law.

An auditable record of these requests and associated exports may shall be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review.

A random re-identification key may be added to the data, to support re-identification for the purpose of alerting providers of potential patient safety issues. For example, if it is discovered that a patient is a risk for a major cardiac event clinical complications (such as hip fracture), the provider could be notified of this risk, allowing the provider to identify the patient from the random key.

IN.1.6
IN.1.7
IN.1.8
IN.2.2
IN.3
IN.4.3
IN.5.1
IN.5.4
IN.6.1
1.  The system SHALL conform to IN.1.9 (Patient Privacy and Confidentiality) and provide de-identified views of data in accordance with scope of practice, organizational policy and jurisdictional law. 57 S.1.5 1 N/C
2.  The system SHOULD conform to IN.2.4 (Extraction of Health Record Information), Conformance Criteria #3 (The system SHOULD provide the ability to de-identify extracted information). The system SHALL provide the ability to de-identify extracted information. 58 S.1.5 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.6 F EF 2013 Scheduling Statement: Support interactions with other systems, applications, and modules to 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.

Description: The system may support user access to scheduling systems as required. Relevant clinical or demographic information required in the scheduling process could be linked to the task.

DC.3.1
DC.3.2.1
IN.2.3
IN.4.1
IN.7
1.  The system MAY SHALL provide the ability to access scheduling data/features, either internal or external to the system, for from other internal systems that are necessary for scheduling patient care or patient resources/devices. 59 S.1.6 1 M
2.  The system MAY provide the ability to access scheduling features, either internal or external to the system, for patient care devices/equipment. 60 S.1.6 2 M
3.  The system MAY SHOULD incorporate relevant clinical or demographic information in the scheduling process. 61 S.1.6 3 M
4.  The system MAY pass relevant clinical or demographic information to support efficient scheduling with other system. 62 S.1.6 4 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.7 F EF 2015 Healthcare Resource Availability Statement: Support the collection and distribution of local health care resource information, through interactions with other systems, applications, and modules, to enable planning and response to extraordinary events such as local or national emergencies.

Description: In times of identified local or national emergencies and upon request from authorized bodies, provide current status of the organization’s physical and human health care resources including, but not limited to, available beds, providers, support personnel, ancillary care areas and devices, operating theaters, medical supplies/equipment, vaccines, and pharmaceuticals. The intent is to enable the authorized body to distribute or re-distribute either resources or patient load to maximize efficient healthcare delivery. In addition, these functions may also be used for internal assessment and planning purposes by facility administrators.

S.1.4.4 IN.1.6 IN.5.1 IN.5.4 1.  The system MAY collect SHALL capture information on health care resource availability through interactions with other systems, applications, and modules. 63 S.1.7 1 M
2.  The system MAY provide the ability to access information on health care resource availability for internal assessment and planning purposes. Health care resources may include, but is not limited to available beds, providers, support personnel, ancillary care areas and devices, operating theaters, medical supplies/equipment, vaccines, and pharmaceuticals. 64 S.1.7 2 M
3.  The system MAY SHALL provide the ability to export information on healthcare resource availability to authorized external parties. 65 S.1.7 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.1.8 F O Information View Statement: Support user-defined information views.

Description: Views of the information can be tailored for or by the user (or department or "job classification”) for their presentation preferences, within local or facility established rules. For example, a nursing supervisor may elect or prefer to see summary data on all patients as the default view.

IN.2.4
IN.2.5.1
IN.2.5.2
1.  The system MAY SHALL provide authorized administrators the ability to tailor the presentation of information for preferences of the user, department/area or user type. 66 S.1.8 1 M
2.  The system MAY provide authorized users the ability to tailor their presentation of information for their preferences. 67 S.1.8 2 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2 H EN Measurement, Analysis, Research and Reports      1.  The system SHALL conform to function IN.1.1 (Entity Authentication). 68 S.2 1 N/C
2.  The system SHALL conform to function IN.1.2 (Entity Authorization). 69 S.2 2 N/C
3.  The system SHALL conform to function IN.1.3 (Entity Access Control). 70 S.2 3 N/C
4.  The system SHALL conform to function IN.1.9 (Patient Privacy and Confidentiality). 71 S.2 4 N/C
5.  The system SHALL conform to function IN.2.4 (Extraction of Health Record Information). 72 S.2 5 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.1 H EN Measurement, Monitoring, and Analysis Statement: Support measurement and monitoring of care for relevant purposes.

Description:

DC.2.6.1   73     N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.1.1 F EN Outcome Measures and Analysis Statement: Support the capture and subsequent export or retrieval of data necessary for the reporting on patient outcome of care by population, facility, provider or community.

Description: Many regions require regular reporting on the health care provided to individuals and populations. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software. The system may also provide the functionality to prompt for the collection of necessary information at the appropriate time in a patient encounter if such collection need can be properly defined in a supportive workflow. e.g., Requesting specific information for reporting of emergency services such as gun shot, suspected abuse, communicable diseases etc, or for the collection of additional research data for specific a specific diagnosis.

S.3.6.2
IN.4.3
IN.6
1.  The system SHOULD SHALL provide the ability to export or retrieve data required to evaluate patient outcomes as required by organizational policy or jurisdictional law. 74 S.2.1.1 1 M
2.  The system MAY SHOULD provide data detailed by physician, facility, facility subsection, community or other selection criteria. 75 S.2.1.1 2 M
3.  The system SHOULD provide the ability to define outcome measures for specific patient diagnosis. 76 S.2.1.1 3 N/C
4.  The system SHOULD provide the ability to define outcome measures to meet various regional requirements. 77 S.2.1.1 4 N/C
5.  The system SHOULD provide for the acceptance and retrieval of unique outcome data defined to meet regional requirements. 78 S.2.1.1 5 N/C
6.  The system MAY SHOULD provide the ability to define report formats for the export of data. This formatted data could be viewed, transmitted electronically or printed. 79 S.2.1.1 6 M
7.  The system MAY SHOULD provide the ability to define prompts in the clinical care setting that would request information needed to comply with regional requirements when specific triggers are met (e.g., have user defined/customizable fields to collect required information). 80 S.2.1.1 7 M
8.  The system MAY export data or provide a limited query access to data through a secure data service. 81 S.2.1.1 8 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.1.2 F EN Performance and Accountability Measures Statement: Support the capture and subsequent export or retrieval of data necessary to provide quality, performance, and accountability measurements which providers, facilities, delivery systems, and communities are held accountable.

Description: Many regions require regular reporting on the health care provided to individuals and populations (quality measures, report cards, dashboards, etc.). These reports may include measures related to process, outcomes, costs of care, may be used in 'pay for performance' monitoring and adherence to best practice guidelines. The system needs to provide the report generating capability to easily create these reports or provide for the export of data to external report generating software.

DC.2.6.3
DC.2.6.2
S.3.6
IN.5.4
1.  The system SHOULD SHALL provide the ability to export or retrieve data required to assess health care quality, performance and accountability. 82 S.2.1.2 1 M
2.  The system SHOULD provide the ability to define multiple data sets required for performance and accountability measures. 83 S.2.1.2 2 N/C
3.  The system MAY SHALL provide the data export in a report format that could be displayed, transmitted electronically or printed. 84 S.2.1.2 3 M
4.  The system MAY export data or provide a limited query access to data through a secure data service. 85 S.2.1.2 4 N/C
5.  The system SHOULD calculate and report quality calculations such as CMS Quality Indicators (QIs) from the MDS, or other required instruments, in accordance with the most recent jurisdictional specifications and export the information to administrative and financial systems. 86     A
6.  The system SHOULD calculate and report quality calculations such as CMS Quality Measures (QMs) from the MDS, or other required instruments, in accordance with the most recent jurisdictional specifications and export the information to administrative and financial systems. 87     A

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.2 H EN Report Generation Statement: Support the export of data or access to data necessary for report generation and ad hoc analysis.

Description: Providers and administrators need access to data in the EHR-S for the generation of both standard and ad hoc reports. These reports may be needed for clinical, administrative, and financial decision-making, as well as for patient use. Reports may be based on structured data and/or unstructured text from the patient's health record.

DC.2.6.3
S.1.5
S.3.6  
1.  The system SHALL conform to function IN.2.2 (Auditable Records) in accordance with scope of practice, organizational policy and jurisdictional law. 88 S.2.2 1 N/C
2.  The system SHALL conform to function IN.2.1 (Data Retention, Availability and Destruction). 89 S.2.2 2 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.2.1 F EN Health Record Output Statement: Support the definition of the formal health record, a partial record for referral purposes, or sets of records for other necessary disclosure purposes.

Description: Provide hardcopy and electronic output that fully chronicles the health care process, supports selection of specific sections of the health record, and allows health care organizations to define the report and/or documents that will comprise the formal health record for disclosure purposes. A mechanism should be provided for both chronological and specified record element output. This may include defined reporting groups (i.e., print sets). For example: Print Set A = Patient Demographics, History & Physical, Consultation Reports, and Discharge Summaries. Print Set B = all information created by one caregiver. Print Set C = all information from a specified encounter. An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review. The system has the capability of providing a report or accounting of disclosures by patient that meets in accordance with scope of practice, organizational policy and jurisdictional law.

DC.1.1.4
DC.1.4
IN.1.2
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.3
IN.5.1
IN.5.4
IN.6
1.  The system SHALL provide the ability to generate reports consisting of all and part of an individual patient’s record. 90 S.2.2.1 1 N/C
2.  The system SHOULD SHALL provide the ability to define the records or reports that are considered the formal health record for disclosure purposes. 91 S.2.2.1 2 M
3.  The system SHOULD provide the ability to generate reports in both chronological and specified record elements order. 92 S.2.2.1 3 N/C
4.  The system SHOULD provide the ability to create hardcopy and electronic report summary information (procedures, medications, labs, immunizations, allergies, vital signs). 93 S.2.2.1 4 N/C
5.  The system MAY provide the ability to specify or define reporting groups (i.e., print sets) for specific types of disclosure or information sharing. 94 S.2.2.1 5 N/C
6.  The system SHOULD SHALL provide the ability to include patient identifying information on each page of reports generated. 95 S.2.2.1 6 M
7.  The system SHOULD SHALL provide the ability to customize reports to match mandated formats as required by jurisdictional law and/or regulations. 96 S.2.2.1 7 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.2.2 F EN Standard Report Generation Statement: Provide report generation features using tools internal or external to the system, for the generation of standard reports.

Description: Providers and administrators need access to data in the EHR-S for clinical, administrative, financial decision-making, audit trail and metadata reporting, as well as to create reports for patients. Many systems may use internal or external reporting tools to accomplish this (such as Crystal Report).

Reports may be based on structured data and/or unstructured text from the patient's health record. Users need to be able to sort and/or filter reports. For example, the user may wish to view only the diabetic patients on a report listing patients and diagnoses.

IN.1.9
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.3
1.  The system SHOULD SHALL provide the ability to generate reports of structured clinical and administrative data using either internal or external reporting tools. 97 S.2.2.2 1 M
2.  The system MAY SHOULD provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools. 98 S.2.2.2 2 M
3.  The system SHOULD provide the ability to export reports generated. 99 S.2.2.2 3 N/C
4.  The system SHOULD SHALL provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data. 100 S.2.2.2 4 M
5.  The system (or an external application, using data from the system) MAY provide the ability to save report parameters for generating subsequent reports. 101 S.2.2.2 5 N/C
6.  The system (or an external application, using data from the system) MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification. 102 S.2.2.2 6 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.2.2.3 F EN Ad Hoc Query and Report Generation Statement: Provide support for ad hoc query and report generation using tools internal or external to the system.

Description : Providers and administrators need to respond quickly to new requirements for data measurement and analysis. This may be as a result of new regulatory requirements or internal requirements. This requires that users be able to define their own query parameters and retain them. The data may be found in both structured and unstructured data.

Providers and administrators also need to query for the absence of specific clinical or administrative data. For example, the Quality Control department a quality assurance study may be reviewing whether or not the protocol for management of Diabetes Mellitus is being followed. If the protocol calls for fasting blood sugars every 3 months at minimum, the investigator might need to run an across-patient query locating patients with diabetes who do not show an FBS result within the last 3 months.

IN.2.5.1
IN.2.5.2
1.  The system SHOULD SHALL provide the ability to generate ad hoc query and reports of structured clinical and administrative data through either internal or external reporting tools. 103 S.2.2.3 1 M
2.  The system MAY SHOULD provide the ability to include information extracted from unstructured clinical and administrative data in the report generation process, using internal or external tools. 104 S.2.2.3 2 M
3.  The system SHOULD provide the ability to export reports generated. 105 S.2.2.3 3 N/C
4.  The system SHOULD provide the ability to specify report parameters, based on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data. 106 S.2.2.3 4 N/C
5.  The system MAY provide the ability to save report parameters for generating subsequent reports. 107 S.2.2.3 5 N/C
6.  The system MAY provide the ability to modify one or more parameters of a saved report specification when generating a report using that specification. 108 S.2.2.3 6 N/C
7.  The system MAY provide the ability to produce reports, using internal or external reporting tools, based on the absence of a clinical data element (e.g., a lab test has not been performed in the last year). 109 S.2.2.3 7 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3 H EN Administrative and Financial   IN.1.9
IN.2.4
1.  The system SHALL conform to function IN.1.1 (Entity Authentication). 110 S.3 1 N/C
2.  The system SHALL conform to function IN.1.2 (Entity Authorization). 111 S.3 2 N/C
3.  The system SHALL conform to function IN.1.3 (Entity Access Control). 112 S.3 3 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.1 H EN Encounter/Episode of Care Management Statement: Support the definition of Manage and document the health care needed and delivered during an encounter/episode of care.

Description: 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 health care 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.

    113 S.3.1   N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.1.1 F EN Specialized Views Statement: Present specialized views based on the encounter-specific values, clinical protocols and business rules.

Description: 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

Examples include:
 

  • An attending physician is presented with a view that provides the primary functions used by the physician (physician order entry, physician progress notes, referrals, care plan, etc.).
  • A speech pathologist performing a bedside treatment session, and using a wireless laptop, would be presented with rehabilitation specific workflow synchronized to the patient's current care plan and tailored to support interventions appropriate to this patient, including age and condition-specific guidelines.
DC.2.2.1.2
S.1.3.7
1.  The system SHOULD provide the ability to define presentation filters that are specific to the types of encounter, clinical protocols and business rules. These specifics may include care provider specialty, location of encounter, date of encounter, associated diagnosis. 114 S.3.1.1 1 M
1a.  The system SHALL conform to function IN.6 (Business Rules Management). 115     A
2.  The system MAY provide the ability to define presentation filters that are specific to the patent demographics. 116 S.3.1.1 2 N/C
3.  The system SHOULD provide the ability to tailor a "user view". 117 S.3.1.1 3 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.1.2 F EN Encounter Specific Functionality Statement: Provide assistance in assembling appropriate data, supporting data collection and processing output from a specific encounter.

Description: Workflows, based on the encounter management settings, will assist (with triggers, alerts and other means) in determining and supporting the appropriate data collection, import, export, extraction, linkages and transformation. As an example, a pediatrician is presented with neonatal diagnostic and procedure codes specific to pediatrics may be filtered out when presenting codes to facility clinicians. 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.

DC.3.1.1
IN.4.2
IN.4.3
IN.7
1.  The system SHALL provide workflow support for data collection appropriate for care setting. 118 S.3.1.2 1 N/C
2.  The system SHOULD provide the ability to create and modify data entry workflows. 119 S.3.1.2 2 N/C
3.  The system SHOULD provide the ability to extract appropriate information from the patient record as necessary to document the patient encounter. 120 S.3.1.2 3 N/C
4.  The system SHOULD provide a reduced set of diagnostic and procedure codes appropriate for the care setting. 121 S.3.1.2 4 N/C
5.  The system MAY initiate secondary reporting workflows as a result of information entered into the encounter. 122 S.3.1.2 5 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.1.3 F EN Automatic Generation of Administrative and Financial Data from Clinical Record Statement: Provide patients clinical data to support administrative and financial reporting.

Description: 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.

S.3.2.2
IN.4.1
IN.4.2
IN.4.3
1.  The system SHOULD provide the ability to define the data required for each external administrative and financial system. 123 S.3.1.3 1 N/C
2.  The system SHOULD SHALL export appropriate data to administrative and financial systems. 124 S.3.1.3 2 M
3.  The system SHOULD calculate and report the appropriate Medicare and/or Medicaid payment calculation score from the MDS in accordance with the most recent jurisdictional specifications and export the calculated scores to administrative and financial systems. 125     A

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.1.4 F O Support Remote Healthcare Services Statement: Support remote health care services such as tele-health and remote device monitoring by integrating records and data collected by these means into the patient's record for care management, billing and public health reporting purposes.

Description: 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 patient can self-monitor her condition from her home and use web TV to report to her provider the facility’s community outreach service. The same TV-internet connectivity allows her to get dietary and other health promoting information to assist her with managing her high-risk pregnancy diabetes and related risk factors.

DC.1.1
DC.1.3.3
DC.1.7.2.1
DC.1.7.2.2
DC.1.7.3
DC.3.2.1
DC.3.2.3
DC.3.2.5
IN.1.4
IN.1.6
IN.1.7
IN.2.2
IN.2.3
IN.2.5.1
IN.2.5.2
1.  The system SHOULD SHALL provide the ability to capture patient data from remote devices and integrate that data into the patient's record. 126 S.3.1.4 1 M
2.  The system SHOULD SHALL provide authorized users two-way communication between local practitioner and remote patient, or local practitioner to remote practitioner. 127 S.3.1.4 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.1.5 F EN Other Encounter and Episode of Care Support Statement: Where not covered above, provide the means to manage and organize the documentation of the health care needed and delivered during an encounter/episode of care.

Description: 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 health care 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 record, health status, demographics, and the initial purpose of the encounter.

DC.3.1
DC.3.2
1.  The system SHALL provide the ability to organize patient data by encounter. 128 S.3.1.5 1 N/C
2.  The system SHOULD accept and append patient encounter data from external systems, such as diagnostic tests and reports. 129 S.3.1.5 2 N/C
3.  The system SHALL provide the ability to create encounter documentation by one or more of the following means: direct keyboard entry of text; structured data entry utilizing templates, forms, pick lists or macro substitution; dictation with subsequent transcription of voice to text, either manually or via voice recognition system. 130 S.3.1.5 3 N/C
4.  The system SHOULD provide the ability to define presentation filters that are specific to the types of encounter. These specifics may include care provider specialty, location of encounter, date of encounter, associated diagnosis. 131 S.3.1.5 4 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.2 H EN Information Access for Supplemental Use Statement: 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.

Description: 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.

    132 S.3.2   N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.2.1 F EN Rules-Driven Clinical Coding Assistance Statement: Make available all pertinent patient information needed to support coding of diagnoses, procedures and outcomes.

Description: The user is assisted in coding information for clinical reporting reasons. For example, a professional coder may have to code the principal diagnosis in the current, applicable ICD as a basis for hospital funding Medicare Part B reimbursement for therapy. All diagnoses and procedures services during the episode may be presented to the coder or clinician, as well as the applicable ICD or CPThierarchy containing these codes.

IN.4.1
IN.4.2
IN.4.3
IN.6
IN.7
1.  The system SHALL provide the ability to access pertinent patient information needed to support coding of diagnoses, procedures services and outcomes. 133 S.3.2.1 1 M
2.  The system MAY SHOULD assist with the coding of diagnoses, procedures and outcomes based on provider specialty, care setting and other information that may be entered into the system during the encounter. 134 S.3.2.1 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.2.2 F EN Rules-Driven Financial and Administrative Coding Assistance Statement: Provide financial and administrative coding assistance based on the structured data and unstructured text available in the encounter documentation.

Description: The user is assisted in coding information for billing or administrative reasons. For example, in the US Domain, 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 provider 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. Medicare Part A claims must include HIPPS codes that reflect the payment calculation category and assessment type for MDSs completed during the billing period. To support this transaction, the payment calculation classification and assessment type information would need to be captured for each MDS completed during a Part A stay and the information made available for the billing process.

S.3.1.3
IN.2.5.1
IN.2.5.2
IN.4.1
IN.4.3
IN.6
IN.7
1.  The system SHALL maintain financial and administrative codes. 135 S.3.2.2 1 N/C
2.  The system SHOULD provide the ability to retrieve data from the electronic health record as required to simplify the coding of financial and administrative documentation. 136 S.3.2.2 2 N/C
3.  The system MAY SHOULD support rules driven prompts to facilitate the collection of data in the clinical workflow that is required for administrative and financial coding. 137 S.3.2.2 3 M
4.  The system MAY SHOULD assist with the coding of required administrative and financial documents based on provider specialty, care setting and other information that may be entered into the system during the encounter. 138 S.3.2.2 4 M
5.  The system MAY SHOULD internally generate administrative and financial coding such as place of service, type of facility, tax rates, etc. 139 S.3.2.2 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.2.3 F O Integrate Cost/Financial Information Statement: Support interactions with other systems, applications, and modules to enable the use of cost management information required to guide users and workflows.
Description: The provider is alerted or presented with the most cost-effective services, referrals, devices and 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 interventions may be presented at the time of ordering.
DC.1.7.1
DC.1.7.2.4
IN.4.3
IN.6
1.  The system MAY provide the ability to retrieve formularies, preferred providers, and other information, from internal or external sources, that are associated with a patient’s health care plan and coverage so that the provider can offer cost effective alternatives to patients. 140 S.3.2.3 1 N/C
2.  The system MAY provide the ability to retrieve or request information about exemptions on coverage limitations and guidelines. 141 S.3.2.3 2 N/C
3.  The system MAY provide the ability to retrieve and provide expected patient out-of- pocket cost information for medications, diagnostic testing, and procedures, from internal or external sources, that are associated with a patients health care plan and coverage. 142 S.3.2.3 3 N/C
4.  The system MAY SHALL alert the provider of care where formularies, preferred provider and other information indicate the health plan requires an alternative. 143 S.3.2.3 4 M
5.  The system SHOULD SHALL conform to S.3.3.3 (Service Authorizations) to integrate support of prior authorization processes. 144 S.3.2.3 5 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3 H EN Administrative Transaction Processing Statement: 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.

Description: 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.
  • Physicians and clinical teams clinicians do not perform additional data entry/tasks exclusively to support administrative or financial processes.
     145     M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3.1 F O Enrollment of Patients Statement: Support interactions with other systems, applications, and modules to facilitate enrollment of uninsured patients into subsidized and unsubsidized health plans, and enrollment of patients who are eligible on the basis of health and/or financial status in social service and other programs, including clinical trials.

Description: 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 a provider is presented with information about eligibility for subsidy for a patient who has recently immigrated. 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.

DC.2.2.3
IN.1.6
IN.1.7
1.  The system SHOULD SHALL provide the ability to retrieve subsidized and unsubsidized health plan options from internal or external sources to allow for presentation of alternatives for health care coverage to patients subject to jurisdictional law. 146 S.3.3.1 1 M
2.  The system MAY provide the ability to retrieve health plan enrollment criteria to match patients health and financial status. 147 S.3.3.1 2 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3.2 F EN Eligibility Verification and Determination of Coverage Statement: Support interactions with other systems, applications, and modules to enable eligibility verification for health insurance and special programs, including verification of benefits and pre-determination of coverage.

Description: 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 system 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. A system would likely verify health insurance eligibility prior to the encounter, but would verify registration in case management or immunization registries during the encounter. When consistency checks are conducted they may check for consistency between internal data entered by a user in multiple places, consistency between internal data and data received externally, or consistency between data elements received externally.

IN.2.3
IN.5.1
IN.5.3
IN.5.4
1.  The system SHOULD SHALL provide the ability to input patient health plan eligibility information for date(s) of service. 148 S.3.3.2 1 M
2.  IF the system is unable to obtain health plan coverage dates through exchange with an external source as per S.3.3.2 (Eligibility Verification and Determination of Coverage), Conformance Criteria #5 (The system SHOULD provide the ability to exchange electronic eligibility information (e.g., health plan coverage dates) with internal and external systems), THEN the system MAY SHALL provide authorized users the ability to input and maintain patient health plan coverage dates. 149 S.3.3.2 2 M
3.  The system MAY SHOULD provide the ability to input general benefit coverage information for patients. 150 S.3.3.2 3 M
4.  The system SHOULD provide for the retention of eligibility date(s) of service, coverage dates, general benefits and other benefit coverage documentation for service rendered. 151 S.3.3.2 4 N/C
5.  The system MAY SHOULD provide the ability to transfer exchange electronic eligibility information from (e.g., health plan coverage dates) with internal and external systems. 152 S.3.3.2 5 M
6.  The system MAY provide the ability to access information received through electronic prescription eligibility checking. 153 S.3.3.2 6 N/C
7.  The system MAY provide authorized users the ability to collect and retain patient registration in special programs such as but not limited to: registries and case management. 154 S.3.3.2 7 N/C
8.  The system MAY provide the ability to check for inconsistencies in the information recorded SHOULD alert the user to inconsistencies present in eligibility and coverage information (e.g., coverage dates, patient identity data, coverage status). 155 S.3.3.2 8 M
9.  IF the system provides the ability to exchange eligibility information with external systems, THEN the system SHALL conduct the information exchange in accordance with ASC X12N 270/271 (Healthcare Eligibility Benefits Inquiry and Response) version 004010X092A1 or higher. 156     A

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3.3 F EN Service Authorizations Statement: Support interactions with other systems, applications, and modules to enable the creation of requests, responses and appeals related to service authorization, including prior authorizations, referrals, and pre-certification.

Description: 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.

DC.1.1.3.1
IN.5.4
1.  IF the system is unable to obtain service authorization data through exchange with an external source per S.3.3.3 (Service Authorizations), Conformance Criteria #3 (The system MAY provide the ability to exchange electronic, computer readable data on service authorization information, including specific data if mandated by local authority), THEN the system SHOULD SHALL provide the ability to input service authorizations relevant to the service provided including the source, dates, and service(s) authorized. 157 S.3.3.3 1 M
2.  IF the system is unable to obtain referral data through exchange with an external source per S.3.3.3 (Service Authorizations), Conformance Criteria #4 (The system MAY provide the ability to exchange electronic, computer readable data on service referral information, including specific data if mandated by local authority), THEN the system SHOULD SHALL provide the ability to input referrals relevant to the service provided including the source, date and service(s) referred. 158 S.3.3.3 2 M
3.  The system MAY provide the ability to transfer and/or collect exchange electronic, computer readable data on service authorization information, including specific data if mandated by local authority. 159 S.3.3.3 3 M
4.  The system MAY provide the ability to transfer and/or collect exchange electronic, computer readable data on service referral information, including specific data if mandated by local authority. 160 S.3.3.3 4 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3.4 F EN Support of Service Requests and Claims Statement: Support interactions with other systems, applications, and modules to support the creation of health care attachments for submitting additional clinical information in support of service requests and claims.

Description: Retrieves structured and unstructured data, including but not limited to lab data, imaging data, device monitoring data, and text based data, based on rules or requests for additional clinical information, in support of service requests or claims, at the appropriate juncture in the encounter workflow.

IN.2.5.1
IN.2.5.2
1.  The system SHALL provide the ability to view available, applicable clinical information to support service requests. 161 S.3.3.4 1 N/C
2.  The system SHALL provide the ability to view available, applicable clinical information to support claims. 162 S.3.3.4 2 N/C
3.  The system MAY SHOULD provide available, applicable clinical information to support service requests in computer readable formats. 163 S.3.3.4 3 M
4.  The system MAY SHOULD provide available, applicable clinical information to support claims in computer readable formats. 164 S.3.3.4 4 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3.5 F EN Claims and Encounter Reports for Reimbursement Statement: Support interactions with other systems, applications, and modules to enable the creation of claims and encounter reports for reimbursement.

Description: Retrieves information needed to support claims and encounter reporting. This reporting occurs at the appropriate juncture in the encounter workflow in a manual or automated fashion. For example this could occur at an initial, interim or final billing. The system may also present the information that is provided for audit and review by local authorities.

IN.2.5.1 IN.2.5.2 1.  The system SHALL provide the ability to view available, applicable information needed to enable the creation of claims and encounter reports for reimbursement. 165 S.3.3.5 1 N/C
2.  The system SHALL provide the ability to capture and present available, applicable data as required by local authority for audit and review. 166 S.3.3.5 2 N/C
3.  The system MAY SHOULD provide available, applicable data in a computer readable form when needed to enable the creation of claims and encounter reports for reimbursement. 167 S.3.3.5 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.3.6 F EN Health Service Reports at the Conclusion of an Episode of Care Statement: 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 registry and discharge data that a provider may be required to generate at the conclusion of an episode of care.

Description: Effective use of this function means that providers do not perform additional data entry to support health management programs and reporting. Nursing Homes are required by federal regulations to complete a discharge summary. The proposed CARE Instrument developed by CMS is an example of an end of episode report.  State regulations may also include discharge summary requirements.

S.2.2
IN.7
1.  The system MAY SHOULD prompt providers for data needed for end of care reporting during the continuum of care to reduce the need for end of care data collection. 168 S.3.3.6 1 M
1a.  The system SHALL conform to function DC.1.1.4 (Produce a Summary Record of Care) 169     A
2.  The system SHOULD create service reports at the completion of an episode of care such as but not limited to; discharge summaries, public health reports, etc. using data collected during the encounter as required by scope of practice, organizational policy, or jurisdictional law. 170 S.3.3.6 2 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.4 F EN Manage Practitioner/Patient Relationships Statement: Identify relationships among providers treating a single patient, and provide the ability to manage patient lists assigned to a particular provider.

Description: This function addresses the ability to access and update current information about the relationships between caregivers and the patients. This information should be able to flow seamlessly between the different components of the system, and between the EHR system 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. Designating relationships such as attending physician, dentist, podiatrist, ophthalmologist, etc.

DC.2.6.3
S.1.3.4
S.2.2
IN.2.4
1.  The system SHALL provide the ability to identify all providers by name associated with a specific patient encounter. 171 S.3.4 1 N/C
2.  The system SHALL provide the ability to specify the role of each provider associated with a patient such as encounter provider, primary care provider, attending physician, ophthalmologist, psychologist, dentist, podiatrist, geriatric nurse practitioner, physician assistant, resident, or consultant. 172 S.3.4 2 M
3.  The system SHALL provide the ability to identify all providers who have been associated with any encounter for a specific patient. 173 S.3.4 3 N/C
4.  The system SHOULD SHALL provide authorized users the ability to add and update information on the relationship of provider to patient. 174 S.3.4 4 M
5.  The system MAY SHOULD provide the ability to view patient lists by provider. 175 S.3.4 5 M
6.  The system SHALL provide the ability to specify primary or principal provider(s) responsible for the care of a patient within a care setting. 176 S.3.4 6 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.5 H EN Subject to Subject Relationship Statement: Document relationships between patients and others to facilitate appropriate access to their health record on this basis if appropriate.

Description: A user may assign the relationships between patients and others to facilitate access to their health record. Some examples may include parent, relatives, a legal guardian, health care surrogate or payer.

S.1.4.1
IN.1.3
IN.1.5
IN.2.2
   177 S.3.5   N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.5.1 F EN Related by Genealogy Statement: Provide information on relationships by genealogy.

Description: Relationships by genealogy may include genetic mother, next of kin, and/or family members. Appropriate consents must be acquired prior to the collection of or use of this information.

DC.1.1.3.1
DC.1.3.3
1.  The system SHALL provide the ability to collect and maintain genealogical relationships. 178 S.3.5.1 1 N/C
2.  The system SHALL provide the ability to identify persons related by genealogy. 179 S.3.5.1 2 N/C
3.  The system SHOULD MAY provide the ability to collect and maintain patient consents required to allow patient records to be viewed for the purposes of a genealogical family member’s family medical history accessed. 180 S.3.5.1 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.5.2 F EN Related by Insurance Statement: Support interactions with other systems, applications, and modules to provide information on relationships by insurance (domestic partner, spouse, and guarantor).

Description:

  1.  The system MAY SHALL provide the ability to identify persons related by insurance plan. 181 S.3.5.2 1 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.5.3 F EN Related by Living Situation Statement: Provide information on relationships by living situation (in same household).

Description:

   1.  The system MAY SHALL provide the ability to identify patients related by living situation. 182 S.3.5.3 1 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.5.4 F EN Related by Other Means Statement: Provide information on relationships by other means.

Description: Other relationships that may need to be recorded would include but not be limited to surrogate mother, power of attorney/conservator/guardian, a person authorized to see health records, health care surrogate, and persons who may be related by epidemiologic exposure, etc.

  1.  The system MAY provide the ability to identify patients related by employer and work location for purposes of epidemiological exposure and public health analysis and reporting. 183 S.3.5.4 1 N/C
2.  The system SHOULD SHALL provide the ability to identify persons with Power of Attorney for Health Care or other persons with the authority to make medical decisions on behalf of the patient. 184 S.3.5.4 2 M
3.  The system MAY provide the ability to identify persons related to the patient by other means. 185     A

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.6 F EN Acuity and Severity Statement: Provide the data necessary to support and manage patient acuity/severity for illness/risk-based adjustment of resource.

Description: Research has been done on nurse staffing and patient outcomes; the impact of organizational characteristics on nurse staffing patterns, patient outcomes, and costs; and the impact of nurses’ experience on patient outcomes. The research indicates that nurse staffing has a definite and measurable impact on patient outcomes, medical errors, length of stay, nurse turnover, and patient mortality. Case mix/acuity data helps determine what is, indeed, appropriate staffing -- as modified by the nurses’ level of experience, the organization’s characteristics, and the quality of clinical interaction between and among physicians, nurses, and administrators. Also, case mix, acuity and severity data is routinely the evidential basis most frequently cited by staff when recommending clinical staffing changes.

S.2.1.2 1.  The system SHOULD SHALL provide the ability to collect appropriate existing data to support the patient case mix/acuity/severity processes for illness/risk-based adjustment of resources. 186 S.3.6 1 M
2.  The system MAY provide the ability to export appropriate data to support the patient acuity/severity processes for illness/risk-based adjustment of resources. 187 S.3.6 2 N/C
3.  The system MAY prompt the user to provide key data needed to support acuity/severity processes. 188 S.3.6 3 N/C
4.  The system MAY provide the ability to calculate patient acuity and/or severity levels. 189     A

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.7 H EN Supportive Function Maintenance Statement: Update EHR supportive content using a manual or automated process.

Description:

      190 S.3.7   N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.7.1 F EN Clinical Decision Support System Guidelines Updates Statement: Facilitate and/or perform updates of clinical decision support system guidelines and associated reference material.

Description: Clinical decision support rules may be applied to the system using a manual process. As standards are developed to represent these rules, an automated update will be recommended. Any process to update decision support rules should include the verification of the appropriateness of the rules to the system. This may include but not be limited to authenticity of the source, the currency of the version, and any necessary approvals before updates can take place.

DC.2.6.3
DC.2.7.1
IN.2.2
IN.4.1
IN.4.3
IN.5.1
IN.5.3
IN.5.4
IN.6
1.  IF providing decision support, THEN the system SHALL provide the ability to update the clinical content or rules utilized to generate clinical decision support reminders and alerts. 191 S.3.7.1 1 M
2.  IF providing decision support, THEN the system SHOULD validate that the most applicable version is utilized for the update, and capture the date of update. 192 S.3.7.1 2 M
3.  IF multiple versions exist, THEN the system MAY SHALL track and retain the version used when guidelines are provided in a patient stay/encounter. 193 S.3.7.1 3 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.7.2 F O Patient Education Material Updates Statement: Receive and validate formatted inbound communications to facilitate and/or perform updating of patient education material.

Description: Materials may include information about a diagnosis, recommended diets, associated patient health organizations, or web links to similar educational information. These materials may be provided electronically and may require validation prior to inclusion in the system. For example, First Databank for drug information.

DC.3.2.4 1.  The system MAY SHALL provide the ability to capture and update patient education material. that may be printed and provided to the patient at the point of care. 194 S.3.7.2 1 M
1a.  The system MAY provide the ability to print the patient education material for provision to the patient at the point of care. 195     A
2.  The system MAY provide the ability to validate the material prior to update. 196 S.3.7.2 2 N/C

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.7.3 F O Patient Reminder Information Updates Statement: Receive and validate formatted inbound communications to facilitate updating of patient reminder information from external sources such as Cancer or Immunization Registries.

Description: Information from outside groups, such as immunization groups, public health organizations, etc. may periodically send updates to patient care providers. The system should be capable of generating patient reminders based on the recommendations of these organizations. Patient reminders could be provided to patients by a number of means including phone calls, or mail. A record of such reminders may become part of a patient’s record. Examples of reminders could include a recommended immunization, prophylactic guidelines for MVP, patient self-testing for disease, etc.

DC.2.2.4 DC.2.3.2 DC.2.5.1 DC.2.5.2 DC.3.2.3 S.1.4.1 IN.2.2 IN.5.2 IN.6 1.  The system MAY provide the ability to add patient reminders for patients based on the recommendations of public health authorities or disease specific associations. 197 S.3.7.3 1 N/C
2.  The system MAY provide the ability to automatically associate patient reminders with patients meeting specific phenotypic criteria such as age, gender, diagnosis, etc. 198 S.3.7.3 2 N/C
3.  The system MAY SHALL provide the ability to display patient reminders, manually process, and record associated telephone contacts. 199 S.3.7.3 3 M
4.  The system MAY provide the ability to automatically generate patient reminders for mailing delivery to patients. 200 S.3.7.3 4 M

 

ID# Type Priority Name Statement/ Description See
Also
Conformance
Criteria
Row
#
FM Source
ID
#
Criteria
#
Criteria
Status
S.3.7.4 F EF 2013 Public Health Related Updates Statement: Receive and validate formatted inbound communications to facilitate updating of public health reporting guidelines.

Description: As standards become available, information and reporting requirements from outside groups, such as public health organizations, may be made available to patient care providers. Examples may include requirements to report on new disease types, or changes to reporting guidelines. The information in these public health updates may be applied to the system so that appropriate data can be collected and reported to comply with requirements.

IN.4.3
IN.5.2
1.  The system MAY SHALL provide the ability to capture and update public health reporting guidelines. 201 S.3.7.4 1 M
2.  The system MAY provide the ability to validate the material prior to update. 202 S.3.7.4 2 N/C

View full report

Preview
Download

"LNEHRSFP1.pdf" (pdf, 1.47Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"LNEHRSFP1-dcf.pdf" (pdf, 839.45Kb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"LNEHRSFP1-sf.pdf" (pdf, 1.72Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"LNEHRSFP1-iif.pdf" (pdf, 1.72Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®

View full report

Preview
Download

"LNEHRSFP1-A.pdf" (pdf, 1.21Mb)

Note: Documents in PDF format require the Adobe Acrobat Reader®. If you experience problems with PDF documents, please download the latest version of the Reader®