U.S. Department of Health and Human Services
Taxonomy of Health Information Technology in Nursing Homes and Home Health Agencies -- Report A: Review by Representatives from Standards Development Organizations
University of Colorado, DenverHealth Sciences Center
August 3, 2007
PDF Version (40 PDF pages)
This report was prepared under contract #HHS-100-03-0028 between U.S. Department of Health and Human Services (HHS), Office of Disability, Aging and Long-Term Care Policy (DALTCP) and the University of Colorado. For additional information about this subject, you can visit the DALTCP home page at http://aspe.hhs.gov/_/office_specific/daltcp.cfm or contact the ASPE Project Officer, Jennie Harvell, at HHS/ASPE/DALTCP, Room 424E, H.H. Humphrey Building, 200 Independence Avenue, S.W., Washington, D.C. 20201. Her e-mail address is: Jennie.Harvell@hhs.gov.
The opinions and views expressed in this report are those of the authors. They do not necessarily reflect the views of the Department of Health and Human Services, the contractor or any other funding organization.
TABLE OF CONTENTS
- III. METHODS
- ATTACHMENT A: DRAFT TAXONOMY OF HIT APPLICATION FEATURES FOR NURSING HOMES AND HOME HEALTH AGENCIES
- LIST OF TABLES
- TABLE 1: Software Vendors with Website or Marketing Materials Reviewed
- TABLE 2: HIT Applications from Booz Allen Hamilton 2006 Report
- TABLE 3: Institute of Medicine Committee on Data Standards for Patient Safety Core EHR
The purpose of this paper is to report on findings from a circumscribed literature review and multiple stakeholder discussions pertaining to the use of and need for health information technology (HIT) applications in nursing homes (NHs) and home health agencies (HHAs). Through these two data collection methods, the authors have attempted to identify and organize the types of electronic point-of-care (POC) and information exchange applications and functions currently used in NHs and/or HHAs (beyond federally-mandated OASIS and minimum data set (MDS) reporting and claims submission).
A related goal of the literature review and stakeholder discussions is the identification of NHs and HHAs believed to be implementing POC documentation and/or electronic information exchange tools. The next phase of the project will consist of site visits to a combination of eight NHs and/or HHAs to conduct in-depth observations of the types of HIT tools in use, the extent to which they are used in the facility or agency, and how the costs and benefits for these applications are measured.
For the stakeholder discussions, five groups of stakeholders were targeted, and to comply with Office of Management and Budget requirements, no more than nine representatives from each group were interviewed. Interviews were conducted using either Web-Ex or telephone conference calls. The five stakeholder groups were representatives from the following:
- Standard Development Organizations that have focused on the use of HIT in NH/HHA,
- HIT vendors providing products specifically for NHs,
- HIT vendors providing products specifically for HHAs,
- NH providers, and
- home health providers.
In an attempt to gather as much information from stakeholders as possible, University of Colorado at Denver and Health Sciences Center (UCDHSC) staff developed five electronic discussion guides and a draft taxonomy of HIT applications (one for each respondent type). Given that each respondent group has a different orientation regarding HIT applications, questions specific to each group were outlined and then distributed via e-mail to each stakeholder group. A summary of the development of the draft taxonomy can be found in Section III, Methods, below.
This report is the first of three reports and briefly summarizes: (1) development of the first taxonomy for review by representatives of standards development organizations (SDOs); (2) how concurrent activities by the Health Level 7 (HL7) Long-Term Care (i.e., NH) EHR-S Functional Profile group influenced the direction of the taxonomy development; and (3) the comments/refinements provided by the stakeholders.
The SDO stakeholder representatives were identified by the Office of the Assistant Secretary for Planning and Evaluation (ASPE) Project Officer and the UCDHSC Project Director. Each stakeholder is involved in one or more standards groups that focus on the needs of post-acute and/or long-term care. The SDO stakeholders were:
- Peter Kress, ACTS Retirement Communities and Center for Aging Services and Technologies, Chair of EHR/PHR Task Force.
- Michelle Dougherty, American Health Information Management Association.
- Don Mon, American Health Information Management Association and chair of the HL7 Electronic Health Record workgroup.
- Shelly Spiro, Long-Term Care & Information Systems Consultant.
- Nathan Lake, National Council for Prescription Drug Programs (NCPDP) and co-chair of the HL7 LTC Profile workgroup.
- Zoe Bolton, formerly of American HealthTech, and co-chair of the National Association for the Support of Long-Term Care HIT workgroup.
- Sue Mitchell, Omnicare, and co-chair of the LTC Profile workgroup.
A. Development of the Ttaxonomy. As noted above, a draft taxonomy of HIT application features available NHs and HHAs was developed following a review of available literature. (A copy of the draft taxonomy can be found in Attachment A.) Peer-reviewed literature was identified using the Ovid database, Google Scholar search engine, web searches for nonpublished literature (e.g., white papers, etc.), and materials provided by the ASPE Project Officer. Because literature is sparse in this area, findings were augmented through review of websites and marketing materials of vendors with products designed specifically for use in NHs and HHAs. A list of vendors for which websites and/or marketing materials were reviewed is provided in Table 1. This list is not intended to be a comprehensive list of all vendors with these products, but does include a representative sample of the largest providers of such products for NHs and HHAs.
A recent report prepared for the Office of Disability, Aging and Long-Term Care Policy in ASPE by Booz Allen Hamilton (2006), entitled "Evaluation Design of the Business Case of Health Technology in Long-Term Care: Final Report," identified eight types of HIT applications and functionalities used by PAC providers, including NHs and HHAs, as shown in Table 2 (Booz Allen Hamilton, 2006). Information from the Booz Allen Hamilton report provided background and was used as a starting point for the draft taxonomy developed for this study.
|TABLE 2: HIT Applications from Booz Allen Hamilton 2006 Report|
|SOURCE: Booz Allen Hamilton, 2006.|
After review, we determined that there is substantial overlap among several of the application domains. For example, two domains listed separately point-of-care, and Assessment and Care Planning -- could be considered subcategories of the Electronic Health Record (EHR) functionality. The domains include a mixture of hardware devices (e.g., supportive documentation was defined as "touch screen kiosk or portable device allowing staff to enter all supportive documentation at the POC" and POC is defined as "hand-held or portable tool for staff to enter all documentation and clinical notes at the POC") and software functions, such as computerized provider order entry (CPOE) and the EHR. This presents difficulties when attempting to classify many applications marketed to NH and HH providers into a single category. For example, an HHA may be using software installed on laptops to collect assessment data and develop care plans. The agency would likely consider this a basic EHR. However, this application also could fit into four other categories delineated by Booz Allen Hamilton: Supportive Documentation, POC, Assessment and Care Planning, EHR.
An Institute of Medicine (IOM) Letter Report, Key Capabilities of an Electronic Health Record System, identified eight core functionalities for an EHR (IOM Committee on Data Standards for Patient Safety, 2003). These functionalities are shown in Table 3.
|TABLE 3: IOM Committee on Data Standards for Patient Safety Care EHR Functionalities|
|SOURCE: IOM, 2003.|
While these categories comprise more distinct functionalities with little overlap as compared to the Booz Allen Hamilton domains, literature and vendor materials also describe additional and/or subsidiary types of functionalities, and may differentiate features of these functionalities within separate products or applications. For example, vendors frequently list several types of decision-support features, from prompts for preventive care activities to disease management modules.
To address specific project goals -- the identification of HIT applications currently in use in NHs and HHAs along with the costs and benefits associated with the applications -- a significantly expanded taxonomy was needed.
Many, if not most, PAC providers initially invest in software to achieve the administrative goals and requirements of the agency (e.g., billing, financial management, reporting of MDS and OASIS data, etc.) before purchasing other health-related functionalities. Often, administrative applications interface with other information gathered electronically at the patient-level (e.g., applications to record the date and times of HHA patient visits may interface with applications for payroll and scheduling). Thus, it was determined that those administrative applications should be included in the draft taxonomy. In recognition of the nearly ubiquitous use of information technology applications to support various administrative activities, providers to be included in this study will be implementing information technology for certain administrative activities and implementing the HIT applications selected, in part, based on information contained in the final taxonomy.
Generally, the reviewed literature classifies HIT applications under four general domains: administrative functions, operations management functions, EHRs, and telehealth/telemedicine functions. All the identified HIT applications were easily grouped under those four domains. However, due to the large number of applications related to medication prescriptions and management, and the high level of interest in these applications as a method for reducing medical errors and enhancing patient safety (National Committee for Quality Health Care, 2006; Booz Allen Hamilton, 2006; Rochon et al., 2006), we elected to list medication-related functions under a separate domain. There is some overlap with medication-related functions and functions described under the EHR category, particularly those related to CPOE and medication lists. Where this overlap occurs, it is noted in the description of the application.
B. Mapping the Taxonomy to Other Standards Work. Once developed, the draft taxonomy was reviewed by the UCDHSC project team prior to submission to the ASPE Project Officer for feedback. Because of the ongoing national work to develop standards for EHRs, particularly the HL7 Long-Term Care Profile group, the Project Officer requested that the team frame the taxonomy in the larger context of standards development.
The function names and descriptions from the HL7 EHR System Functional Model (EHR-S FM) Standard (HL7, 2007) were mapped against the applications described in the draft taxonomy. Further, criteria from the Certification Commission for Healthcare Information Technology (CCHIT) Final Criteria for Certification of Ambulatory EHRs (CCHIT, 2006) were included (along with CCHIT's timeline for implementation of these criteria) were included because of the belief that there will be at least some overlap in the CCHIT criteria for ambulatory care EHR products and those criteria that will be specified for NHs, and, possibly at a future date, for home health.
Many of the applications included in the taxonomy were not specifically addressed in the HL7 EHR-S FM, as the taxonomy included many applications under the domains of administration, operations management, and telemedicine/telehealth. The HL7 EHR-S FM has little focus on these domains. In addition, applications listed in vendor marketing materials and websites often combine several elements of functions listed separately within the HL7 EHR-S FM. For example, the ability to create and maintain a patient record (health information capture, management, and review), including demographic information, documentation of patient consent, patient assessments, visit notes, and other functions are listed as unique functions in the HL7 EHR-S FM. However, vendor marketing materials may not list these features separately, but simply refer to them as "clinical data collection needs" or "EHR clinical content."
Because the taxonomy initially was developed through literature review and review of vendor materials, the orientation is toward the end user, rather than toward a standards development or certification organization. In some areas, the draft taxonomy was expanded to align more closely with the HL7 EHR- FM. However, because the taxonomy was used as a discussion guide and a data collection tool for stakeholder calls and, in the future, site visits, we felt it important to preserve the language of the application descriptions as found in the literature.
C. Summary of Feedback Provided by SDO Representatives. The stakeholders largely agreed with the description of functions and organization of the taxonomy. When suggested, changes were made; they often were to clarify to a greater extent the definition proposed for specific functions (i.e., having it align more closely with the HL7 EHR-S FM definition), and combining functions that were artificially separated but that usually were bundled together in one software application (e.g., accounts payable and accounts receivable). Sue Mitchell (co-chair of the long-term care/NH EHR-S Functional Profile workgroup) was particularly helpful in the mapping of the taxonomy to the EHR-S FM and clarifying when the taxonomy developers' assumptions were off the mark. The final SDO taxonomy was then submitted to the ASPE Project Officer, and is one of the source documents being used in the public/private collaborative effort to develop the long-term care/NH EHR-S Functional (See Attachment A).
The development and refinement of the taxonomy has continued. The project team modified the taxonomy to take into account feedback from the SDO stakeholders, then shared the modified taxonomy with NH and home health HIT vendors. Their feedback and additions were included in a later version of the taxonomy that then was shared with the HH and NH providers. In the next two reports, the authors will provide the final taxonomies that incorporate the vendors' and the providers' comments. Within Report B and Report C, the authors will describe the functions purported to being used (or not used) within NHs and HHAs. Based on the findings provided in these two final deliverables, the authors will make recommendations as to the HIT functions that could be used for the planned on-site case studies.
Booz Allen Hamilton (2006). Evaluation Design of the Business Case of Health Technology in Long-Term Care: Final Report. Washington, DC: Office of Disability, Aging and Long-Term Care Policy, ASPE, HHS. http://aspe.hhs.gov/daltcp/reports/2006/BCfinal.htm.
Certification Commission for Healthcare Information Technology (2006). Final Criteria: Functionality for 2006 Certification of Ambulatory EHRs-Effective May 1, 2006. http://www.cchit.org/files/Ambulatory%20Domain/Final%20Criteria%20-%20FU... [Online].
Health Level 7 (2007). HL7 2007 EHR-S Functional Model. http://www.hl7.org/ehr/downloads/index_2007.asp [Online].
Institute of Medicine, Committee on Data Standards for Patient Safety (2003). Key Capabilities of an Electronic Health Record System, Letter Report. Washington, DC: The National Academies Press.
National Committee for Quality Health Care (2006). CEO Survival Guide: Electronic Health Record Systems. Washington, DC: National Committee for Quality Health Care.
Rochon, P.A., Field, T.S., Bates, D.W., Lee, M., Gavendo, L., Erramuspe-Mainard, J. et al. (2006). Clinical application of a computerized system for physician order entry with clinical decision support to prevent adverse drug events in long-term care. Canadian Medical Association Journal, 174, 52-54.
|A: ADMINISTRATION DOMAIN|
|Application Features||Definition||HL7 EHR-S FM February 2007||CCHIT Ambulatory Care Time Frame||Typically Packaged With||Provider Type|
|A.1||Census Management||Admissions, discharges, transfers, bed holds, current list of patients, available beds, ability to generate lists of unduplicated admissions (HHA). Also
See Also HL7 Functions: S.2.2.2 (Standard Report Generation) S.2.2.3 (Adhoc Query & Report Generation)
|S.1.4.2 (Patient's location w/in a facility) S.1.4.3 (Patient's residence for the provision & administration of services) S.1.4.4 (Patient Bed Assignment)||X||X|
|A.2||General Ledger/Accounts Payable||A/P, cash flow, financial statements, bank reconciliation, budgeting.||Census management, Cash Receipts, Credit/collections tracking, Insurance Verification, Billing, Budgeting||X||X|
|A.3||Verification of Insurance & Eligibility for Services||Allows online verification of insurance information and coverage for services. This can be facilitated electronically by the use of HIPAA x12 transaction code sets.||S.3.3.2 (Eligibility Verification & Determination of Coverage) S.3.3.3 (Service Authorizations)||Eligibility verification & determination of coverage, roadmap May 2007||Census management, General Ledger, Credit/collections tracking, Insurance Verification, Coding Support, Billing||X||X|
|A.4||Accounts Receivable/Billing (may include things such as coding assistance, cash receipts, & credit and collections tracking)||Calculates resource utilization category (RUG)/HHRG, electronic generation & submission of UB-92 and Centers for Medicare and Medicaid Services (CMS) 1500 forms or other billing forms. Software also supports the capture of RUG/HHRG codes submitted and validated on MDS/OASIS. Electronic billing is facilitated with the use of HIPAA x12 transaction code sets. Reference file of codes to support financial/administrative coding to maximize reimbursement (including any facility or agency-specific exceptions or alerts). Cash receipts, may include electronic transfer of funds, Credit/collections including account aging, delinquent account worksheet.||S.3.2.1 (Rules-Driven Clinical Coding Assistance) S.3.2.2 (Rules-Driven Financial and Administrative Coding Assistance) S.3.1.3 (Automatic Generation of Administrative & Financial Data from Clinical Record) S.3.3.4 (Support of Service Requests & Claims) S.3.3.5 (Claims & Encounter Reports for Reimbursement)||General ledger, Cash receipts, Credit/collections tracking, Insurance verification, Coding support||X||X|
|A.5||Tracking Medicare/NonMedicare Claims Denials||Tracks denials through to the resubmission and payment of claim. See also S.3.3.4 (Support of Service Requests & Claims)||S.3.3.5 (Claims & Encounter Reports for Reimbursement)||General ledger, Cash receipts, Insurance, Credit/collections tracking, verification, Coding support, Billing||X||X|
|A.6||Resident Trust Fund Management||Tracks trust funds, automatic reminder when a resident's balance approaches the maximum allowed by Medicaid.||General ledger||X|
|A.7||Contracts Management||Tracks payer contact info, contractual agreements, negotiated payer rates, allows the evaluation of proposed contracts based on historical data, ability to bill according to contract terms and monitor for appropriate reimbursement.||General ledger, Cash receipts, Billing, Credit/collections tracking, Insurance verification, Coding support||X||X|
|A.8||Payroll||Automated payroll, calculates deductions, manages accrued leave balances, check writing capabilities.||General ledger, Staffing/scheduling, Staff time/attendance tracking, telephony||X||X|
|B: OPERATIONS MANAGEMENT DOMAIN|
|Application Features||Definition||HL7 EHR-S FM February 2007||CCHIT Ambulatory Care Time Frame||Typically Packaged With||Provider Type|
|B.1||Registration/Admission||Patient Intake, includes data on demographics, caregiver and emergency contact, next of kin, physicians, diagnoses, payers, generation of face sheet (including key demographics), advanced directives. May also include capability to "pre-admit" patients. See Also HL7 Functions: DC.1.1.1 (Identify & Maintain a Patient Record) DC.1.3.1 (Manage Patient & Family Preferences) DC.1.3.2 (Manage Patient Advance Directives) DC.1.3.3 (Manage Consents & Authorizations)||DC.1.1.2 (Manage Patient Demographics) S.1.4.1 (Patient Demographics)||Manage patient demographics, certify May 2006||Census management, electronic medical record (EMR)||X||X|
|B.2||Online Access for Transfers||Interfaces for hospitals or physician offices to refer patients, may include interfaces for receipt of electronic discharge information (e.g., ECIN or E-Discharge). See Also HL7 Functions: DC.1.1.1 (Identify & Maintain a Patient Record)DC.126.96.36.199 (Manage Patient & Family Preferences)||DC.188.8.131.52 (Support for Referral Process)||Support for nonmedication ordering, roadmap May 2007||Registration, EMR||X||X|
|B.3||Acuity Assignment||Automatic assignment of a resident into an acuity class based on a user-defined total attribute point value, for aid in appropriate staffing (e.g., patients may be identified as acuity levels 1-4, with 4 requiring the highest staffing ratio and 1 requiring the lowest staffing ratio).||S.3.6 (Acuity & Severity)||Staffing/scheduling||X|
|B.4||Staffing/Scheduling||Allows coordination of staff shift assignments (NH) and home visits (HH), tracks employee availability.||S.1.6 (Scheduling)||Scheduling, certify May 2006||Payroll, Staff time/attendance tracking||X||X|
|B.5||Staff Time/Attendance Tracking||Capability to capture time clock data, record detailed hours worked, links with staffing/scheduling and payroll.||Payroll, Staffing/scheduling||X||X|
|B.6||Telephony||Allows care providers to use the phone to record visit information (time in/time out).||Billing, Payroll, Staff time/attendance tracking||X|
|B.7||Personnel Management||Tracks eligibility, licenses, captures performance review dates and evaluation results, captures disciplinary actions, staff development activities and clinical in-services, OSHA reports for employee injuries/illnesses.||Payroll||X||X|
|B.8||Workflow Management||Assigns and prioritizes tasks for care providers, allows timelines and due dates to be set, issues reminders for due dates, may also include reporting capabilities for staff productivity and resource utilization. See Also HL7 Functions: DC.3.2.1 (Support for Inter-Provider Communication)IN.7 (Workflow Management)||DC.3.1.1 (Clinical Task Assignment & Routing) DC.3.1.2 (Clinical Task Linking) DC.3.1.3 (Clinical Task Tracking)||Clinical task assignment & routing (create and assign tasks by user or user role), certify May 2006||Staffing/scheduling||X||X|
|B.9||User-Defined Financial Management Reports||Generates reports to monitor financial factors such as costs, pro forma profits, staffing ratios vs. costs, RUG days/month, etc.||X||X|
|B.10||Tracking of Medical Doctor (MD) Signature, including Option of Electronic Signature||Tracks if primary care provider has signed the HH plan of care or updated orders. See Also HL7 Function: IN.1.8 (Information Attestation)||Need new child function in Supportive||X|
|B.11||Facilities/Materials Management||Purchasing and inventory management, may allow for capture of charges at point of service. May allow for service contracts. Management of housekeeping and laundry/linen services. Track service date renewals for plant and equipment.||General ledger||X|
|B.12||Patient Supply Ordering||Allows supplies to be ordered by patient or family member (for home health) or facility (SNF/NH) electronically.||Facilities/materials management, Billing, Clinical notes||X||X|
|B.13||Dietary Management||Menu planning & production system, using resident profile information (diet, consistency, likes, dislikes, special requests, etc.) and compares it to cycle menu to make selections for the residents which are printed on individualized tray tickets. These tray tickets show what every resident is to be served including food items, specific portions, sizes, consistency modifications and special notes. May also include exact tally production sheets, scaled recipes, and nourishment and snack labels. May also include weight tracking and therapeutic note capabilities. See Also HL7 Functions: DC.1.8.4 (Manage Patient Clinical Measurements) DC.1.8.5 (Manage Clinical Documents and Notes) DC.3.2.1 (Support for Inter-Provider Communications)||Facilities management, EMR||X|
|B.14||Pharmacy Management||Pharmacy online adjudication to third-party payers, pharmacy universal claim form, pharmacy cycle fill period, fill list, integrated with formularies and provides list of alternate drugs, accommodates ordering of floor stock pharmacy items, inventory control for narcotics, return medication credits/adjustments.||DC.184.108.40.206 (Support for Medication Recommendations)||Census management, Billing, MAR, e-prescribing, Automated medication dispensing systems, Barcode administration management||X (if own pharmacy)||X (if own pharmacy)|
|B.15||Medications Tracking/Billing||Allows for tracking of costs and coverage of patient medications, interfaces with billing system.||S.3.1.3 (Automatic Generation of Administrative & Financial Data from Clinical Record)||Billing, MAR||X||X|
|B.16||MDS/OASIS Data Collection to Meet Regulatory Requirements Only (i.e., entry, editing, transmission)||The MDS/OASIS can be completed in the following ways: 1. on paper 2. scan sheets 3. electronically (e.g., PDA, laptop, etc.). Here we are concerned with information technology applications1 (not HIT or EHR systems) that use MDS/OASIS assessment data for payment calculations, QA/QM reporting to meet regulatory requirements, or care planning to meet regulatory requirements. Allows MDS/OASIS data collected via paper, scan sheets, or other devices at the POC (e.g. PDA) to be data entered (or scanned), edit checks run, allows for data correction, and export of data to the state repository. Includes HAVEN, RAVEN, and other commercial products. This is the manual collection of data that are then entered into some other software. Devices that interface directly with the EHR/EMR are noted in 3.a. See Also HL7 Function S.2.1.2 (Performance & Accountability Measures)||S.3.1.3 (Automatic Generation of Administrative & Financial Data from Clinical Record) S.3.3.6 (Health Service Reports at the Conclusion of an Episode of Care)||X||X|
|B.17||Quality Management Activities & Reporting||Allows the aggregation of data and reporting for program quality assessment and management purposes. The next few indented rows describe various quality management reports and activities available for NH/HHA.||S.2.1.1 (Outcome Measures & Analysis) S.2.1.2 (Performance & Accountability Measures)||EMR MDS/OASIS, Clinical Notes, Results management, Care planning/goal setting, Decision-support, Trending||X||X|
|B.17.a||Incident Reporting||S.2.2 (S.2.2.2 - S.2.2.3)||X||X|
|B.17.b||Tracking of adverse occurrences (e.g., falls, med errors)||S.2.1 (S.2.1.1, S.2.1.2), S.2.2 (S.2.2.2, S.2.2.3)||X||X|
|B.17.c||Tracking of Infections||S.2.1 (S.2.1.1, S.2.1.2), S.2.2 (S.2.2.3)||X||X|
|B.17.d||Summary Reports of Clinical Pathways Variances Reporting (e.g., if the HHA staff is unable the accomplish the "assigned" activities for a patient by a certain visit, then there is a variance from the clinical pathway)||S.2.1 (S.2.1.1, S.2.1.2), S.2.2 (S.2.2, S.2.2.3)||X|
|B.17.e||Calculation of Outcomes from MDS/OASIS Data (e.g., hospitalization)||Note: See Section B.16. MDS/OASIS IT applications may also enable the SNF/HHA to monitor QA/QI activities at either the facility or patient-level.||S.2.1 (S.2.1.1, S.2.1.2), S.2.2 (S.2.2.2, S.2.2.3)||X||X|
|B.17.f||Risk Audits for Quality Areas of Concern for Surveyors (e.g., wounds)||S.2.1 (S.2.1.1, S.2.1.2), S.2.2 (S.2.2.2, S.2.2.3)||X||X|
|B.17.g||"Dashboard Reports" of Key Quality Indicators (e.g., hospitalizations, infections & falls)||S.2.1 (S.2.1.1, S.2.1.2), S.2.2 (S.2.2.2, S.2.2.3)||X||X|
|B.17.h||Occupancy Rates & Trends||X|
|B.18||Reporting & Population Health Management||Allows secure electronic reporting for federal, state, local (and accrediting agency) required information on patient safety and quality for tracking population health status including prevalence, incidence and aggregate health status measure. Includes the ability to notify appropriate public health agencies for certain reportable conditions (e.g., tuberculosis, etc.) or transmit specific required information to registries (e.g., immunizations). Allows for the report generation of any survey reporting requirements (e.g. CMS 672 and 802).||DC.2.6.1 (Support for Epidemiological Investigations of Clinical Health Within a Population) DC.2.6.2 (Support for Notification & Response) DC.2.6.3 (Support for Monitoring Response Notifications Regarding a Specific Patient's Health) S.2.1.1 (Outcome Measures & Analysis) S.2.1.2 (Performance & Accountability Measures) S.3.7.4 (Public Health-Related Updates)||Quality management||X||X|
|B.19||Electronic Access to Clinical Guidance||Allows care provider online access to information for use in clinical decisions or care planning (e.g., online access to health libraries offering clinical journals).||DC.2.7.1 (Access Healthcare Guidance)||X||X|
|B.20||De-identified Data Request Management||Provide data in a manner that meets federal, state and local requirements for de-identification.||S.1.5||Extraction of health record information, certify May 2006||Physician access to EMR, Security/Privacy||X||X|
|B.21||Policy/Procedure Database||Allows care provider to access policies procedures online.||DC.220.127.116.11 (Support for Standard Care Plans, Guidelines, and Protocols)||Quality management||X||X|
|B.22||Secure Data Transfer to Payors & Regulatory Bodies||Allows secure inter-agency communications to meet regulatory requirements and/or to be reimbursed for services provided. Note: Also see Section C. 12.|
|C: ELECTRONIC HEALTH RECORD (EHR/)/ELECTRONIC MEDICAL RECORD (EMR)2 DOMAIN|
|Application Features||Definition||HL7 EHR-S FM February 2007||CCHIT Ambulatory Care Time Frame||Typically Packaged With||Provider Type|
|C.1||Maintain Patient Record/Health Information Capture, Management, & Review||Identify and maintain a single patient record for each patient. This includes capturing data using standardized code sets or nomenclature, or unstructured data. Details of who entered the data & when they were captured are tracked. See Also HL7 Functions: DC.1.1.2 (Manage Patient Demographics) DC.18.104.22.168 (Capture Data & Documentation from External Clinical Sources) DC.22.214.171.124 (Capture Patient-Originated Data) DC.126.96.36.199 (Capture Patient Health Data Derived from Administrative & Financial Data & Documentation)||DC.1.1.1 (Identify & Maintain a Patient Record)||Identify & maintain a patient record, certify May 2006||X||X|
|C.2||Patient Consent, Authorizations & Directives||Allow for the capture and maintenance of information regarding patient consent, specific authorizations, and advance directives. See Also HL7 Function DC.188.8.131.52 (Manage Referrals)||DC.1.3.2 (Manage Patient Advance Directives) DC.1.3.3 (Manage Consents & Authorizations)||Manage consents & authorizations & manage patient advance directives, capture of presence of consents/advance directives certify May 2006; additional functionality (e.g. specifying types of advance directives) roadmap May 2007||X||X|
|C.3||Comprehensive Initial & Follow-up Assessments||The MDS/OASIS can be completed in the following ways:
This function/feature is focusing on EHR systems that have the capacity to electronically create and use the MDS or OASIS data and that are electronically part of a larger, more complete health record. Manage, create, and maintain required assessment data via POC software (e.g., laptops, PDAs, etc.) upon admission to NH/HHA and at prescribed time points. Note: In HH, this means the completion of OASIS at start of care, 60 day FU, transfers, and discharge. In NHs, this includes the production of MDS, which is a summary report of assessment data collected over a period of time by a variety of disciplines. The MDS/OASIS and other assessment data are integrated with the EHR. Assessment information includes data on patient history, allergies/sensitivities, patient preferences, and other relevant patient information (e.g., skin risk assessment, fall risks, dietary, etc.). See also B.16. See Also HL7 Functions: DC.184.108.40.206 (Capture Patient - Originated Data) DC.1.2 (Manage Patient History) DC.1.3.1 (Manage Patient & Family Preferences) DC.1.4.1 (Manage Allergy, Intolerance and Adverse Reaction List) DC.1.8.4 (Manage Patient Clinical Measurements) DC.1.8.5 (Manage Clinical Documents & Notes) S.3.1.2 (Encounter Specific Functionality)
|DC.1.5 (Manage Assessments) DC.2.1.1 (Support for Standard Assessments) DC.2.1.2 (Support for Patient Context-Driven Assessments)||In the review of the March 16 2007 Ambulatory Care functionality criteria, there was no mention of criteria setting for health-related patient assessments. Note: However, CCHIT does have the following criteria: Manage allergy and adverse reaction list, certify May 2006; manage patient history, certify May 2006||Census management, Clinical notes, Care planning/goal setting, MDS/OASIS data management||X||X|
|C.3.1||Patient-Originated Data||In home health care, patients and family members often provide information relevant to care planning and overall patient assessment.|
|C.4||Summary Reports||Allows aggregation of EMR data to generate brief, clinically relevant assessment summaries, discharge summaries, transfer summaries, and other summary reports (e.g., 60-day summaries in home health care). Functionality for electronic transmission of reports is listed under Secure Electronic Messaging. See Also HL7 Function DC.1.1.5 (Present Adhoc Views of the Health Record)||DC.1.1.4 (Produce a Summary Record of Care)||Report generation, certify May 2006; report generation, certify May 2006||EMR MDS/OASIS, Care Planning/Goal Setting, Clinical notes||X||X|
|C.5||Documentation of Care||Create, addend, correct, authenticate, and close clinical visit data (including assessments/clinical measurements, interventions, communications, etc.) in structured or nonstructured (i.e., text) format. Data may be captured via direct data entry at POC, at the nurses station, through laptops, hand-held devices such as PDAs, kiosks located outside patient rooms, computers located at bedside, or voice-activated dictaphones for later transcription.||DC.1.8.4 (Manage Patient Clinical Measurements) DC.1.8.5 (Manage Clinical Documents & Notes) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) S.3.1.5 (Other Encounter & Episode of Care Support)||Manage clinical documents & notes, certify May 2006; Encounter management; certify May 2006||Census management, Billing, EMR MDS/OASIS, Care planning/goal setting, Decision-support, Trending, Patient supply inventory/ordering, CPOE, MAR, Medication list||X||X|
|C.5.c||Registered Nurse/Licensed Practical Nurse (LPN)|
|C.5.d||Physical Therapist (PT)|
|C.5.e||Occupational Therapist (OT)|
|C.5.g||Social Worker (SW)|
|C.6||Receive External Clinical Documents & Data||Electronic receipt of external facilities/agencies, documents and data such as laboratory data, radiology data, medical devices, patient history, patient consults, etc. See Also HL7 Functions: DC.3.2.1 (Support for Inter-Provider Communication) DC.3.2.2 (Support for Provider-Pharmacy Communication) DC.3.2.3 (Support for Communications Between Provider & Patient and/or the Patient Representative) DC.3.2.5 (Communication with Medical Devices)||DC.220.127.116.11 (Capture Data & Documentation from External Clinical Sources DC.18.104.22.168 (Capture Patient --Originated Data) DC.22.214.171.124 (Capture Patient Health Data Derived from Administrative & Financial Data & Documentation)||Capture external clinical documents, certify May 2006||Clinical notes, Care planning/goal setting, Decision-support||X||X|
|C.6.d||Patient History/EMR from Other Settings|
|C.7||Problem List||Creation of a list of all active patient problems; may be included in functionality supporting the plan of care. Management of problem list so that old and current problems are accessible.||DC.1.4.3 (Manage Problem List)||Manage problem list, certify May 2006||X||X|
|C.8||Care Planning/Goal Setting||Electronic plan of care (POC) data collection and availability of data for generation of the POC (e.g., former CMS 485 form) and goal setting. May allow for POCs required by CMS or others. May be limited to an overall POC, or may allow for discipline-specific POCs (e.g., therapy, nursing, nutritionist). See Also HL7 Functions: DC.126.96.36.199 (Support for Standard Care Plans, Guidelines, Protocols) DC.188.8.131.52 (Support for Context-Sensitive Care Plans, Guidelines, Protocols)||DC.1.6.1 (Present Guidelines & Protocols for Planning Care) DC.1.6.2 (Manage Patient-Specific Care & Treatment Plans)||Support for standard care plans, guidelines, protocols, certify May 2006||EMR MDS/OASIS, Clinical notes, Decision-support, Trending||X||X|
|C.8.a||Interdisciplinary Plan of Care||X||X|
|C.8.b||Acute Problem Plan of Care/Single Plan of Care||X||X|
|C.8.c||Discipline-Specific (e.g., therapy) Plan of Care||X||X|
|C.9||Decision-Support||Clinical support tools providing best practice suggestions for care plans and interventions, based on clinical problems/diagnoses, may include alerts or reminders for specific interventions, tools for assessing risk of various conditions frequently seen in elderly patients using PAC. Indented examples below are applications found in the review of long-term care software available today.||S.3.7.1||X||X|
|C.9.a||Electronic Clinical Pathways/Standardized Care Plans||Includes both automated pathways and documentation/alerts for patient-level variances (i.e., instances when a patient's care deviates from the prescribed pathway) See Also HL7 Functions: DC.1.6.1 (Present Guidelines & Protocols for Planning Care) DC.1.6.2 (Manage Patient -- Specific Care & Treatment Plans) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) DC.2.1.1 (Support for Standard Assessments) DC.2.2.2 (Support Consistent Healthcare Management of Patient Groups or Populations)) S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC.184.108.40.206||Support for standard care plans, guidelines, protocols, certify May 2006; capture variances from standard care plans, guidelines, & protocols roadmap for May 2008 & beyond||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.b||Disease Management Programs||See Also HL7 Functions: DC.1.7.3 (Manage Order Sets) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) DC.220.127.116.11 (Support for Standard Care Plans, Guidelines, Protocols) S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC.2.2.2||Support for standard care plans, guidelines, protocols, certify May 2006, present alerts for disease management, preventive services & wellness, certify May 2006; notification & reminders for disease management, preventive services & wellness, certify May 2006||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.c||Automated Alerts for Routine Lab Tests Based on Clinical Condition (e.g., diabetic patient requires HbA1c test every three months)||See Also HL7 Functions: DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC.2.5.1||Notification & reminders for disease management, preventive services & wellness, certify May 2006||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.d||Automated Prompts for Unusual Events (e.g., medication errors, etc.)||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.e||Automated Prompts for Preventive Practices (e.g., immunizations)||See Also HL7 Functions: DC.1.8.2 (Manage Immunization Administration) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) S.3.7.1 (Clinical Decision-Support System Guidelines Updates) S.3.7.3 (Patient Reminder Information Updates)||DC.2.5.1 DC.2.5.2||Present alerts for disease management, preventive services & wellness, certify May 2006; notification & reminders for disease management, preventive services & wellness, certify May 2006||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.f||Decision-Support for e-prescribing. May Include Dosing; Drug Selection; Drug-to-drug Interactions; Drug-to-food Interactions; etc.; payor formulary||See Also HL7 Functions: DC.1.7.1 (Manage Medication Orders) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC 18.104.22.168 DC.22.214.171.124 DC.126.96.36.199||Manage order sets, roadmap May 2007||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.g||Triggers for Needed Risk Assessments Based in Clinical Factors||System's ability to trigger the completion of needed risk assessments (e.g., skin, dietery, falls dehydration, etc.). See Also HL7 Functions: DC.1.5 (Management Assessments) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC.2.1.1 DC.2.1.3||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.h||Results Interpretation||Manage current and historical test results with the ability to filter and compare results. See Also HL7 Functions: DC.1.8.3 (Manage Results) DC.1.8.6 (Manage Documentation of Clinician Response to Decision-Support Prompts) S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC.2.4.3||Manage results, certify May 2006||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X||X|
|C.9.i||Alerts for SOM/F-tag Compliance||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Trending||X|
|C.10||Care Plan Monitoring||Allows monitoring of the effectiveness of care plans or clinical interventions and needed modifications based on results or measurements (e.g., care plan goals are included as templates with progress notes). See Also HL7 Functions: DC.1.6.2 (Manage Patient -- Specific Care and Treatment Plans)||DC.1.8.3 (Manage Results) DC.1.8.4 (Manage Patient Clinical Measurements) DC.1.8.6 (Management Documentation of Clinician Response to Decision-Support Prompts) DC.2.4.3 (Support for Result Interpretation) DC.2.6.3 (Support for Monitoring Response Notifications Regarding a Specific Patient's Health)||X||X|
|C.11||Trending||Provides graphical and/or tabular displays for trending and analysis of information such as vital signs, weight, lab results including blood sugar levels, intake and output, etc. May include queries to analyze for unusual findings. See Also HL7 Functions: DC.2.1.3 (Support for Identification of Potential Problems & Trends) S.2.2.2 (Standard Report Generation) S.2.2.3 (Adhoc Query & Report Generation)||DC.1.8.3 DC.1.8.4||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Decision-support||X||X|
|C.12||Electronic Communication with Providers, Patients, & Other Family Members||Allows secure intra-agency or intra-facility communications to facilitate health information exchange and coordination among care providers. Extra-agency or extra-facility communications provide methods for communicating with external clinicians or other health settings.||Inter-provider communication, certify May 2006||X||X|
|C.12.b||Extra-agency (with MD, pharmacy, pharmacy consultant, laboratory, etc.)||DC.3.2.1 DC.3.2.2||X||X|
|C.12.c||Health Information Exchange with Patients & Their Caregivers||Allows for the two-way exchange of information between a patient health record and the EHR/EMR. Also allows for clinical information to be shared with home health patients and their caregivers assisting in their care. This includes electronic communication with the next of kin should they need to know if/when there is an incident with the patient. Closely related to telehealth correspondences between physicians/nurses and patients (Communication with patient/family for access to relevant patient information (e.g., labs, visit schedules, patient updates). See Also HL7 Functions: DC.188.8.131.52 (Capture Patient-Originated Data) S.3.4 (Manage Practitioner/Patient Relationships) IN.1.4 (Patient Access Management)||DC.3.2.3||X||X|
|C.13||Patient Education||Generation of patient education materials or electronic access to standardized patient education materials which can be printed out for patient teaching activities. (Systems which provide automated patient teaching programs are listed under the telehealth/telemedicine domain). See Also HL7 Functions: DC.2.2.4 (Support Self-Care) S.3.7.2 (Patient Education Material Updates)||DC.2.7.2 DC.3.2.4||Generate & record patient specific instructions & patient education, roadmap May 2007||Policy/procedure database, Decision-support||X||X|
|C.14||Security/Privacy||Permissions setting, user authentication, reports on access of EMR, disaster recovery plans. Includes patient access to record. Also includes archiving data and auditing of data.||IN.1 (IN.1.1 - IN.1.5), IN.2 (IN.2.1, IN.2.2, IN.2.5)||Security: access control, certify May 2006; security authentication, certify May 2006; reliability backup/recovery, certify May 2006; reliability documentation, certify May 2006; entity authorization, roadmap May 2008 & beyond; enforcement of confidentiality, roadmap May 2007; audit trail, roadmap May 2008 & beyond||X||X|
|C.15||Physician and/or Pharmacist Access to EMR||Provides mechanism (e.g., portal) for remote access to the EMR by attending, admitting, consulting and covering physicians. See Also HL7 Functions: DC.3.2.1 (Support for Inter-Provider Communication).||IN.1.1 IN 1.2 IN.1.3||Secure electronic messaging, CPOE, Record access||X||X|
|C.16||Computerized Provider Order Entry (CPOE) -- Nonmedication Orders||Allows provider orders for diagnostic and treatment services to be entered electronically by a prescriber or nurse, with or without computerized medication ordering. CPOE can be implemented with or without an e-MAR. See Also HL7 Functions: DC.1.7.3 (Manage Order Sets) DC.2.4.2 (Support for Nonmedication Ordering) DC.184.108.40.206 (Support for Referral Process) DC.220.127.116.11 (Support for Referral Recommendations)||DC.18.104.22.168 DC.22.214.171.124 DC.126.96.36.199 DC.188.8.131.52||Order medication, certify May 2006; order diagnostic tests, certify May 2006; support for nonmedication orders, roadmap May 2007||EMR MDS/OASIS, Clinical notes, Results management, Care planning/goal setting, Decision-support, MAR, Medication list, e-prescribe, Pharmacy management||X||X|
|D: MEDICATIONS DOMAIN [While many of the applications within this domain fall under the EHR/EMR domain, but with the emphasis of the potential cost savings and increase in quality of care of electronic applications related to medications.]|
|Application Features||Definition||HL7 EHR-S FM February 2007||CCHIT Ambulatory Care Time Frame||Typically Packaged With||Provider Type|
|D.1||Medication Administration Record (MAR)||All medications administered to patients are recorded into the MAR (which can be mediated by a kiosk, PDA, or bar code reader). Generated from the medication list. Interfaces with pharmacy system, computerized order entry system, and patient tracking (admission-discharge-transfer) system. Medication inventory tracking including receipt and disposition of medications. Specifics: Present a list of all medications to be administered Display the timing, route of administration, and dose of all meds to be administered Provide the ability to capture the details of the administration of the medication. See Also HL7 Function: DC.2.3.2 (Support for Medication & Immunization Administration)||DC.1.8.1||Results management, CPOE, Pharmacy management, Barcode medication administration, Census management||X||X|
|D.1.1||Barcode Medication Administration||A hand-held barcode scanning device is used to scan barcode information (e.g., on the patient's wristband ID), the packaging of the medication to be dispensed, and the administering nurse's ID. After all required barcodes are scanned, the system confirms the patient's identity, matches the patient with the medication order, and confirms that the administering nurse has the authority to dispense the medications. If any problems are identified, the administering nurse will be notified via a combination of warning tones and text messages. The system then records the transaction information and stores it on an electronic MAR.||DC.3.2.5||MAR, Pharmacy management, Billing||X|
|D.2||Medication List||Allows creation of a list of all medications at admission and amendments as medications are changed or updated. In HHAs, this list is typically used for medication tracking and reconciliation, as opposed to a MAR used to document medication administration (i.e., HHA providers frequently do not administer medications, but simply check to ensure the patient understands which medications are needed, when, and is able to administer them independently). In NHs may serve as a reconciliation or continuity of care tool. May contain orders from multiple health care providers.||DC.1.4.2||Manage medication list, certify May 2006||Clinical notes, Care planning/goal setting, Decision-support, CPOE, MAR||X||X|
|D.3||Medication Checking||Allows medications to be checked by appropriate clinical staff for side effects, potential adverse events, duplicate drug therapy, medication precautions, storage, missed dose, and overdose (e.g., medication regimen review). May include decision-support and printable patient education forms. An EHR could have this application without having CPOE. See Also HL7 Function: S.3.7.1 (Clinical Decision-Support System Guidelines Updates)||DC.184.108.40.206 DC.220.127.116.11 DC.18.104.22.168||Support for drug interaction, certify May 2006||X||X|
|D.4||Computerized Provider Order Entry (CPOE) -- Medication||See Also HL7 Functions: DC.22.214.171.124 (Support for Drug Interaction Checking)DC.126.96.36.199 (Support for Patient Specific Dosing & Warnings)DC.188.8.131.52 (Support for Medication Recommendations||DC.1.7.1|
|D.4.1||Communicate Electronic Medication Order Between Practitioner & Pharmacies (two-way functionality) (home health)||Electronic transmission of prescription information between health care providers and pharmacies. Transmission of prescriptions using standards developed by the NCPDP may or may not be in use. Typically involves ordering of medications using a PDA or computer, may also include decision-support. Two-way functionality may be more common in HHAs, where the patient gets prescriptions from the pharmacy. See Also HL7 Functions: DC.1.7.1 (Manage Medication Orders) DC.184.108.40.206 (Support for Drug Interaction Checking) DC.220.127.116.11 (Support for Patient Specific Dosing & Warnings) DC.18.104.22.168 (Support for Medication Recommendations).||DC.3.2.2||Medication orders, certify May 2006; pharmacy communication, certify May 2006||CPOE, Pharmacy management||X (if own pharmacy)||X (if own pharmacy)|
|D.4.2||Communicate Electronic Medication Order Among Practitioner, Pharmacy & Nursing Home (three-way functionality)||Same as above. Transmission of prescriptions using standard developed by the NCPDP may or may not be in use. Three-way functionality may be present in NHs or home care agencies with specialty pharmacies (e.g., for IV therapy), although currently NH use of e-prescribe is prescriber to facility and facility to pharmacy (e.g., little direct communication between prescriber and pharmacy).||DC.3.2.2||Medication orders, certify May 2006; pharmacy communication, certify May 2006||X|
|D.5||Automated Medication Dispensing Systems||Automated Medication Dispensing Cabinets provide computer controlled storage, dispensation, tracking, and documentation of medication distribution at the POC on the resident care unit. Tracking of the stocking and distribution process can occur by interfacing the unit with a central pharmacy computer. These cabinets can also be interfaced with other provider databases such as resident profiles, the facility's admission/discharge/transfer system, and billing systems.||DC.3.2.5||Census management, Billing, MAR, e-prescribing, Pharmacy management||X|
|D.6||Medication Reminder Systems||Provide reminders to take or administer medication at predetermined times. May take the form of software installed on PDAs, PCs, or mobile phones to. Other devices used are specialized watches, pagers, pocket devices, and medication bottle caps programmed to remind the user to take medications at predetermined times. Alerts come in the form of audible alerts, vibration, and some will provide text messages. These systems are for patients capable of self-administering medications. See Also HL7 Functions: DC.2.2.4 (Support Self-Care)||DC.2.2.4 DC.3.2.5||X|
|D.7||Personal Automatic Medicine Dispensers||Programmable, locked devices that will automatically dispense a dose of dry medications at predetermined times. May alert patient/resident when it is time to take medication with audible alarms, lights, text and voice messages. May also include online monitoring capabilities to track dispensing activity and can contact caregivers or a monitoring service when medications are not dispensed per the prescribed regimen. See Also HL7 Functions: DC.22.214.171.124 (Capture Data & Documentation from External Clinical Sources) DC.2.2.4 (Support Self-Care)||DC.3.2.5||X||X|
|E: TELEMEDICINE/TELEHEALTH DOMAIN [Telehealth uses a wide range of information and communications technologies to provide specialist referral services, patient consultations, remote patient monitoring, medical education, and consumer medical and health information through networked programs, private connections, primary and specialty care to the home, and a growing range of Web-based e-patient services (American Telemedicine Association, http://www.atmeda.org/).]|
|Application Features||Definition||HL7 EHR-S FM February 2007||CCHIT Ambulatory Care Time Frame||Typically Packaged With||Provider Type|
|E.1||Telemonitoring of Vital Signs, Weights, EKG Findings||Electronic devices to measure and transmit information to a home health or other provider. Data can include blood pressure, pulse, weight, blood glucose, EKGs, pulse oximetry, Peak Expiratory Flow and Forced Expiratory Volume, etc. Examples are "smart toilets," Internet-enabled weight scales, electrocardiograms, or devices that can be placed on a television cable box, telephonic stethoscopes for ausculating heart, lung and bowel sounds. See Also HL7 Functions: DC.126.96.36.199 (Capture Data & Documentation from External Clinical Sources) DC.2.2.4 (Support Self-Care) S.3.1.4 (Support Remote Healthcare Services)||DC.3.2.5||Decision-support, Virtual visits||X||X|
|E.2||Telemonitoring for Incontinence (Enuresis alarms)||Provide an alert (to caregivers or residents themselves) when a resident is incontinent. These devices typically consist of a moisture-detecting sensor, which is connected to an alerting device. Sensors can take several forms including probes that are placed in undergarments, undergarment pads, and moisture absorbing bed pads or larger sensor pads that are placed under the sheets of the resident's bed. Alerts may be audible, flashing lights, and vibrating alerts. May have the capability of alerting the caregiver via a paging device or through the facility's assistance call system.||X|
|E.3||Telemonitoring for Falls||Devices that signal a caregiver when a resident who is at risk for falling attempts to leave a bed, chair, wheelchair, or toilet unattended. Most consist of a pressure sensor connected to a control unit with an alarm. The size and shape of the sensor depends on the application (chair, bed, or toilet). A single control unit is often compatible with several sensor types, enabling one control unit to be used in several applications. When the resident rises and removes pressure from the sensor, the control unit provides an alert to the caregiver.||X|
|E.4||Telemonitoring for Room Departure, Prolonged Time in Bathroom, & Restlessness Within Own Room||Sensors that notify caregivers of room departure or bed departure.||Telemonitoring for falls||X|
|E.5||Tracking Systems||Tracking systems are used to locate a resident who has left the facility or home, using radio frequency (RF) signals or Global Positioning System (GPS) technology. Tracking systems that use RF technology usually consist of a transmitter worn by the resident and a hand-held tracking device used by the caregiver to locate the resident. Tracking systems using GPS technology combine the use of GPS satellites, digital wireless networks, and the Internet to locate a wandering resident anywhere that digital wireless network service is available. The resident must wear a signaling device (i.e., watch, a pager sized clip-on device, or a box-like device that can be placed in a fanny pack or rucksack). The care provider can use the Internet to locate a resident via a computer, mobile phone, or PDA or by calling a central monitoring station via telephone. In addition to locating a lost resident, many of these systems have the ability to alert a caregiver when the resident has left a predetermined area and when the resident has fallen. Systems may track residents with the facility/home, and may include a wander guard system to prevent wandering (e.g., sprinkler system).||Telemonitoring for room departure, prolonged time in bathroom, & restlessness within own room||X||X|
|E.6||Wireless personal emergency response systems||Automated dialing system that can transmit coded messages to a remote monitoring station when activated by user or sensor.||X|
|E.7||Medication Reminders (see Medication domain)||X||X|
|E.8||In-home Messaging Device||Video screen connected to a patient's home telephone line (POTS) allowing patients to view questions and reminders from the provider. Provide two-way dialog by allowing patients to respond to questions by pressing buttons on the device.||DC.2.2.4 DC.3.2.3 DC.3.2.5||Virtual visits||X|
|E.9||Virtual Visits||Video monitors with audio capability, can be POTS or IP systems. Allow the care provider and patient (or other care provider) to view one another and have a two-way audio dialogue for the virtual visit.||DC.2.2.4 DC.3.2.3 DC.3.2.5||Decision-support systems||X||X|
|E.10||Patient Education Materials||Custom designed software for patient education, typically installed on PCs or PDAs in the home for telemonitoring, virtual visits, or messaging. May be stand-alone or web-based. See Also HL7 Functions: DC.2.2.4 (Support Self-Care) DC.2.6.3 (Support for Monitoring Response Notifications Regarding a Specific Patient's Health) S.3.7.2 (Patient Education Material Updates)||DC.2.7.2 DC.3.2.4||Telemonitoring of vital signs, etc, In-home messaging devices, Virtual visits||X|
|E.11||Health Chat Lines||Patient may log into a private Internet site from their home computer for private synchronous communication with provider. May have the capability to log time spent by provider for billing.||X|
|E.12||Communication with Patient/Family for Access to Relevant Patient Information (e.g., labs, visit schedules, patient updates).||Typically via secure web connections. Closely related to EHR/EMR C.12 Health Information Exchange with patients and caregivers See Also HL7 Function: DC.188.8.131.52 (Capture Patient-Originated Data) S.3.4 (Manage Practitioner/Patient Relationships)||DC.3.2.3||X||X|
|E.13||Teleimage Transmission||Transmission of X-ray and other still images (store and forward) to consulting specialists or primary care providers. See Also HL7 Function: DC.1.8.3 (Manage Results)||DC.3.2.1||Secure electronic messaging||X||X|
|E.14||Cellular Phones with Photo Capabilities||Used to take photographs to supplement clinical documentation or to forward to physician. Especially used to photograph wounds.||Clinical notes, Secure electronic messaging, Physician access to EMR||X|
Information technology applications here are differentiated from HIT or EHR systems. Information technology applications in this context refer to those applications used by HHAs or NHs to meet regulatory requirements for quality assurance reporting and care planning, as well as assisting them in calculating payment rates and submitting claims. HIT, on the other hand, is loosely defined as a more complex, robust set of health data that may include the functionality of these more basic information technology applications, but also have additional functionality and information such as can be found in an EHR.
EHR Systems are defined in the HL7 EHR FM DSTU as: (1) a longitudinal collection of electronic health information for and about persons, where health information is defined as information pertaining to the health of the individual or health care provided to an individual; (2) immediate electronic access to person and population-level information by authorized, and only authorized, users; (3) provision of knowledge and decision-support that enhance the quality, safety, and efficiency of patient care; and (4) support of efficient processes for health care delivery. HIMMS defines an EHR as a "computer-based longitudinal records of patient health information generated by one or more encounters in any care delivery setting." The EHR is intended primarily for use by health care providers. For the purposes of this taxonomy, we consider that an EHR is an integrated record containing information crossing provider settings and is compliant with (or is becoming compliant with) existing interoperability standards. We consider EMRs to be a subset of EHRs and are used and maintained by a single provider setting.