A Functional Profile for Emergency Department Information ...



Emergency Department Information Systems

Functional Profile

EDIS Functional Profile Working Group

Emergency Care Special Interest Group

Health Level 7

Co-Chairs

Todd C. Rothenhaus, MD FACEP

Donald Kamens, MD FACEP FAAEM

James McClay, MD, MS

Kevin Coonan, MD

Version 0.6 (8/1/2006)

EDIS Functional Profile Working Group

|EC-SIG Co-chairs | |

|Todd C. Rothenhaus, MD FACEP |Boston University School of Medicine |

|Donald R. Kamens, MD FACEP FAAEM |XPress Technologies |

|James McClay, MD MS |University of Nebraska Medical Center |

|Kevin Coonan, MD |University of Utah School of Medicine |

| | |

|EDIS Functional Profile Working Group | |

|Randy Case |Siemens |

|Dennis G. Cochrane MD FACEP |Morristown Memorial Hospital, Morristown, NJ |

|John Epler |Picis |

|JT Finnel |Regenstrief Institute |

|M. Catherine Glenz RN, BSN |Alert Life Sciences Computing, Inc. |

|John R. Griffith |MEDHOST, Inc. |

|Mark Jaben |Haywood Regional Medical Center |

|Richard Hartl MD |Wellsoft, Inc |

|Laura Heermann Langford, RN, PhD. |Intermountain Healthcare |

|Daniel Myung |Boston University |

|JA Magnusun |Oregon Department of Human Services |

|Dan Pollack |Centers for Disease Control |

|Uhri Randhas |MEDHOST, Inc. |

|Eric Rock |MEDHOST, Inc. |

|John Santmann MD |Wellsoft, Inc. |

|Bharat Sutariya |Cerner, Inc. |

|Chris Thompson, MD, FACEP |Touch Medix, LLC |

Emergency Department Information Systems (EDIS) - Functional Profile

Emergency Care Special Interest Group – HL7 VERSION 0.6 08/1/2006

Welcome to the EDIS Functional Profile (EDIS-FP) project of the HL7 Emergency Care SIG (EC-SIG). The project is aimed at developing an HL7 Informative Functional Profile for emergency department information systems (EDIS), conforming to the HL7 EHR Functional Model, under the auspices and direction of the EHR Technical Committee. By creating a robust and usable functional profile that includes specific and relevant conformance criteria, we hope to develop an open and objective standard for development, refinement, and comparisons between ED information systems.

In 2003, the EHR TC (then a special interest group) began development of a functional model for electronic health record systems (EHR-S). Subsequently, a number of organizations approached HL7 to accelerate development of a consensus standard to define the necessary functions of an EHR. The EHR SIG was promoted to a full technical Committee and in 2004 published the EHR-S Functional model as a Draft Standard for Trail Use (DSTU). The EHR Functional Model remains in development.

The EHR-TC intends that unique functional profiles will be developed by subject matter experts in various care settings or domains (i.e. ambulatory, inpatient, anesthesia, long-term care). These functional profiles will serve to inform developers, purchasers, and other stakeholders of the functional requirements of systems developed for these domains. Recently, the Certification Commission on Health Information Technology (CCHIT) adopted the EHR FM as a tool for evaluation of ambulatory and inpatient EHR systems. The EC-SIG has been in communication with the leadership of CCHIT and intends to advance the EDIS-FP as the standard for evaluation of emergency department information systems.

The EC-SIG was founded last year to inform the HL7 and other standards development organizations (SDOs) of the unique HIT requirements and workflows of emergency care. The EC-SIG co-chairs solicited input and membership from domestic an international specialty societies, including but not limited to, ACEP, SAEM, AAEM, ENA, and the Canadian and Australasian Emergency Medicine Societies. Participation was also thoroughly solicited from the vendor community through invitations and presentations.

In 2005, American College of Emergency Physicians (ACEP) joined HL7 and sponsored membership in the EC-SIG in the form of 4 memberships and 2 funded awards for travel and expenses. Sufficient infrastructure was secured from an unrestricted grant from X-press Technologies to set up an intranet site and weekly teleconferences to supplement thrice yearly face to face meetings at HL7 workgroup meetings. Members of the EDIS-FP include physicians, nurses, medical informatics experts, EDIS developers, engineers, and other representatives from the vendor community.

We began the EDIS-FP project by taking a broad look at the functions required of ED systems and without particular reference to the EHR FM, which faces open ballot in HL7 in 2006. Using this methodology, we have discovered at least a few functions that the EHR-TC may have not yet considered in the FM. It has also permitted us to tackle the project in a manner recognizable to most people working in emergency medicine. Ultimately, harmonization between the workgroup product and the FM will need to occur for the product to become an HL7 Informative Functional Profile. We anticipate publication of the workgroup document in a format suitable for practicing emergency department providers and managers to use as a guide to system evaluation and selection. It is also expected that the EDIS-FP will defines conformance for both EHR systems and for any subsequent profiles subsequently developed from the FP itself.

The project was planned in four phases:

1. Organization – solicitation of participants, determination of scope and care setting of profile, and development of project plan and overview (completed).

2. Formalization – step by step development of EDIS functions and conformance criteria (largely completed).

3. Harmonization –comparison with, incorporation into, and alignment with the EHR FM (in process).

a. Incorporate defined EDIS functions through alignment with EHR-FM.

b. Accept or reject other functions from FM.

c. Solicit input from EHR TC for possible new functions.

d. Define priority timeframes (i.e. essential now, essential future) for functions.

e. Incorporate and modify conformance criteria.

4. Finalization – attention to detail, wording, language, conformance and preparation for final EHR – TC approval and external publication.

The development of the EDIS FP uses the HL7 approach. That is to say that everyone’s contribution or concern needs to be addressed. Your input is welcome.

Reading this Document

The EDIS FP like the EHR FM, is divided into three broad sections: Direct Care, Supportive Functions and Information Infrastructure. Each section defines a broad category of functions applicable to

|Direct Care | |

|Supportive Functions | |

|Information Infrastructure | |

We began with a scope of ED care that begins with a “heads-up” and moves through patient arrival, triage, nursing and physician assessment, orders, results, procedures and ongoing assessments, and finally admit/transfer/discharge planning. However, many of these traditional concepts or tasks are interspersed throughout the document, depending upon whether aspects constitute patient tracking, administrative functions, clinical workflow, tasks/orders, clinical documentation, or clinical decision support, etc. For instance, the triage process can be found in both clinical workflow and clinical documentation. If a particular aspect of the profile do not make sense, look for pointers to other areas included in the document.

Functional Priorities

The EHR TC and EC-SIG recognize that clinical computing is an evolving field, and that many of the desired functions of an EHR-S may not be available at this time. Certain functions, for instance access to regional health information, may not be feasible or essential now because widespread adoption of RHIOs has yet to occur. Nevertheless, it is important for functional profiles to outline major trends and articulate a vision for functionality (especially interoperability) for the future. Furthermore, the delineation of potential functions for future implementation and adoption should guide vendors in development, and help purchasers develop and articulate to vendors a strategic vision for future functional requirements.

Each function in the EDIS FP is assigned a single priority as follows:

|Essential Now |The function is readily available and the users can implement it. In assigning this priority, the committee believes that the |

| |function is critical to helping an EDIS: |

| |• Support Delivery of Effective Healthcare |

| |• Improve Patient Safety |

| |• Facilitate management of chronic conditions |

| |• Improve efficiency |

| |• Facilitate self-health management |

|Essential Future |The function should be feasible to implement and readily available to users within the prescribed period of time. |

|Optional |The function is important or desirable but not a critical component of an EDIS. |

Conformance Criteria

Conformance criteria have been developed in accordance with the standards set forth by the EHR technical committee. In order to ensure consistent, unambiguous understanding and application of the functional profile, the use of a consistent set of keywords (normative verbs) have been employed to describe conformance requirements.

• SHALL – indicates a mandatory, required action. Synonymous with ‘is required’.

• SHOULD – indicates an optional, recommended action that is particularly suitable, without mentioning or excluding other actions. Synonymous with ‘is permitted and recommended’.

• MAY – indicates an optional, permissible action. Synonymous with ‘is permitted’

In addition, clarification is necessary to understand the standardized nomenclature used to describe the functions of a system. The following chart, adapted from the EHR FM, illustrates the hierarchy of nomenclature. For example, “capture” is used to describe a function that includes both direct entry “create” and indirect entry through another device “input”. Similarly, “maintain” is used to describe a function that entails reading, updating, or removal of data.

|MANAGE |

|Capture |Maintain |

|Input Device (Ext.) |Create (Int.) |Read |Update |Remove Access |

| | |(Present) | | |

| |View |Edit |Obsolete |

| |Report |Correct |Inactivate |

| |Display |Amend |Destroy |

| |Access |Augment |Nullify |

| | | |Purge |

| |Type| |

|ID | |Name |

|EDC.1 |H |Care Management |

|EDC.1.1 |H |Patient Location Tracking |Track patient physical location through all phases of visit, from pre-arrival through disposition. |

|(See: DC.3, S.1.4.2) | | |In emergency medicine, the concept of tracking within and EDIS connotes multiple concepts. This section refers to tracking physical location only. |

| | | |Tracking the status of care is covered in Clinical Workflow Tracking and Task Management |

|EDC.1.1.1 |F |Track inbound patients |Track inbound patients |

| | | | |

| | | |Log information about incoming referrals from: physicians offices, clinics, EMS, transfers from other hospitals or EDs, nursing homes, others. |

|EDC.1.2.1.1 |H |Patient Registration |ED patients frequently require evaluation and treatment prior to ADT registration. The ability to provide care before formal registration is |

| | | |essential. In addition, many patients are brought directly to patient care areas. |

|EDC.1.2.1.1.1 |F |Enter patient into EDIS |Enter patient into EDIS |

|EDC.1.2.2.1 |F |Task Management |Manage ED tasks with the EDIS |

| | | | |

| | |See: Clinical workflow tasking | |

| | |(DC 3.1) | |

|EDC1.4.1 |F |Display Diagnostic Results |Provide means to view results of diagnostic studies. |

|EDC.1.5.1 |F |Merge Pre-Arrival Data |Merge inbound (EMS, telephone, transfer) data with record being created for visit. |

|EDC.1.5.8.2.1 |F |Record Completion | |

|EDC.1.6.1 |F |Manage discharged patients |Provide a means to capture and maintain outstanding patient issues after the ED visit is completed. |

|EDC.2.1 |F |Evidence Based Triage |Provide a means for triage staff to assign triage categories. |

| | | | |

| | | | |

ESP.1.1 |H |Department Modeling and Room Management |Describe ED physically and organizationally. |Provide means to describe ED physically and organizationally, including departments, rooms, holding areas. |The system shall allow for Room/Department Management.

The system shall/should allow for the management of holding areas.

The system shall/should provide for the management of rooms containing multiple patients.

The system shall/should provide for the management of room availability

The system shall provide for the management of patient placement.

|This may be a new function. I can’t seem to find a similar function in the EHR-FM.

| |EDC.1.1.1 |F |Manage room availability |Flag room status or availability |Provide means for providers to flag rooms as reserved, clean, dirty, biohazard, etc.

ED Flow is dependent on readying new rooms, changing linen, and making the room availability known. |The system should provide a means to flag room status as reserved, in need of cleaning, or other status. | | |EDC.1.1.2 |F |Manage patient placement |Provide a means for the mechanics of patient placement, including overviews of the department, waiting room, and other areas for which status is of importance. Allow, permit, and facilitate relevant communications, notifications, movement.

|This is the key piece of asynchronous distributed communication that was provided for decades by the grease board. | | | |EDC.1.1.5.3 |F |Manage holding areas |Create holding areas as needed | |The system should provide means to hold patients in EDIS for unique reasons, including out of department, other departments, etc. | | |EDC.1.1.5.4 |F |Manage Multiple patients in a single room |Allow/prohibit multiple patients in single room |Administratively determine a-priori if multiple patients are permitted in a particular room…. This is a room level function. That is, some rooms may and others may not allow multiple patients. |The system shall allow multiple patients to be in a single room. |This may not be too critical. may not rise to the level of a function… | |EDC.1.1.5.5 |F |Manage Hallway Patients |Allow for the management of patients in hallways, as well as the creation, dissolution of bed status in hallways and other “temporary” locations |Necessary, of course. |The system shall allow for the management of hallway patients. | | | | | | | | | | | | |Manage Admissions to Hospital from ED. | |Support for unique needs of bed requests, including service, type of bed, admitting attending, isolation, etc. | | | |ESP 2 | |Measurement, Analysis, Research and Reports | | | | | | | | | | | | | | | | | | | | | |ESP 3 | |Administrative and Financial | | | | | |ESP.3.1.3 |F |Billing | |Provide means to create a bill for patients.

Without extra work by clinician… | |Should we include all relevant billing data into this function. | | | | | | | | | |

| |Information Infrastructure | | | | | |IN.1 |H |Security | | | | | |EII.2 |H |Health record information and management | | | | | |IN.3 |H |Identity, registry, and directory services | | | | | |EDC.1.1.3 |H |Protect Identities | | | | | |EDC.1.1.4.1 |F |Protect all patient identities.

(Has to be a better way to say this.) |Keep patient identities invisible to other providers on public tracking screens. |Create de-identified view for broadcast in common areas. Many EDs design or employ common displays or dashboards.

Frequently called “JCAHCO view”

(Move to II…note that tracking system needs special attention for protection of identity….Information Infrastructure...not only tracking) |The system shall provide a means to protect patient identities from other patients, patient visitors, and non participating healthcare providers. | | |EDC.1.1.4.2 |F |Protect individual patient identity.

|Flag patient identity as confidential to others. |Create a flag to indicate to providers the need to protect the identity of patients at particular risk of harm.

Despite best efforts of confidentiality, display should identify patients at particular risk of harm during stay (e.g. domestic violence)

|The system shall provide a means to flag patients who require protection of their identity from others, including family, visitors, and non participating healthcare providers. | | |IN.5 |H |Standards-based Interoperability | | | | | |IN.5.1 |H |Inbound Interoperations | | | | | |EDC.1.5.5 |H |Cross Reference Documents | | | | | |EDC.1.5.5.1 |F |Use incoming medical summaries | |This will have special bearing on CDR, CCR, (CDA), and other medical summary standards. |

|Moved from DC | |EDC.1.5.5.2 |H |Use Available patient reports/data | | | |Moved from DC | |EDC.1.5.5.2.1 |F |Find and use relevant documents related to patient |Review previous medical records |Reports that are available in the system or an interoperable system (say an HIS – CDR) should be searchable, findable, and usable |The crème-de-la-crème??? |Moved from DC | |IN.5.2 |H |Hospital Level Interoperations | | | | | |IN.5.2.1 |F |ADT Interface |Interface with ADT system |Provide means to interface EDIS with hospital-wide ADT system | | | |IN.5.2.2 |F |Laboratory Interface | | |

| | |IN.5.2.3 |F |Pharmacy Interface | | |

| | |IN.5.2.4 |F |Automated Dispensing Equipment | |Provide means to send message to automated dispensing equipment.

(i.e. Pyxis) | | | |IN.5.2.5 |F |Materials Management | |Provide means to alert materials management system with stock usage. | | | |IN.5.2.6 |F |Radiology Interface | | | | | | | |Bed Request Interface | | | | | | | |Support for bar code registration | | |

Pharmacy system handhelds. | | |IN.5.3 |H |Outbound Interoperations | | | | | | | |Structured Document Support | | |The system shall export the ED record in CDA format. | | | |F |RHIO Outbound Functionality |Export EDIS Encounter to RHIO |Provide means for provider with appropriate credentials to, or automatically export, data to RHIO | | | | |F |Electronic Prescribing |Export prescriptions to eRx system |Provide functionality to transmit prescriptions electronically. | | | | |F |Agency Reporting | |Provide for automated electronic transfer of selected public health and surveillance reports. | | | | |F |Primary Care Physician | |Provide means to electronically transfer ED care record to patient’s primary care physician. | | | | |F |Custom flags | |Provide means to create specifically formatted or customized flags or notes to other clinical systems.

May be useful prior to RHIO development.

Examples: medication changes to CDR, note to enterprise EHR. | | | | | |Billing Interface

Facility

Supplies E/M

and

Physician | | | | | | | | | | | | | |IN.6 |F |Business Rules Management | | | | | |IN.7 |H |Workflow Management | | | | | |IN.7.1 |F |Sub-second Response Time | |Speed of interface is both an implementation element and a necessity for EHR adoption.

|Must:

Not impair workflow

Not impair patient flow

Exhibit Ease

| | |IN.7.2

|F |Asynchronous Distributed Communications

| | |Communicate state of needed attention in the ED (e.g. “to be seen”. Is backed up….or “labs are ready on a bunch of patients)..etc. Don’t see how this has to do with ADS | | | | | | | | | | | | | | | | | | |

Appendix A: Glossary of Terms

EHR-S Electronic health record system

Follow-up The who, when, and where. and what happens if you don’t.

Pre-arrival Data Data obtained on a patient prior to arrival in the ED.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download