Resting ECG Workflow Status

Administrative Info

Date: 10-Dec-2009

Supplement Editors: Barry Brown (Mortara), Mary Schneider (GE)

Background

IHE promotes the use of healthcare communications standards so products from multiple vendors interoperate in specific clinical scenarios. A resting 12-lead ECG is the most widely prescribed diagnostic cardiac test. Electrocardiographs, unlike other cardiology modality devices, typically use proprietary communication protocols making device interoperability and clinical workflow very difficult. Therefore, IHE will profile “Resting ECG Workflow” and specify the healthcare communications standards to use between systems and devices involved in this clinical scenario. Resting ECG Workflow involves registering the patient, ordering the test, performing the test (acquiring the waveforms), and interpreting the test results (reporting). Many existing multi-vendor installations are unable to support this complete ECG workflow because of the proprietary device protocols. For example, most electrocardiographs are unable to accept ECG orders from other vendors' ECG management systems. Also, any ECG management vendor claiming multi-vendor electrocardiograph support has had to invest in multiple engineering efforts to create vendor-specific device interfaces.

This profile identifies the actors involved in this workflow and how they communicate. It reuses as many actors and transactions from existing IHE profiles as appropriate. Consideration has been given to the types of products already on the market so manufacturers can conform to this profile without major architecture and product scope changes. IHE realizes that manufacturers are more likely to conform to IHE profiles if the engineering effort is minimized.

This profile makes it easier for vendors with related modality storage and reporting products to add support for ECG workflow. For example, classic PACS systems already have image storage and reporting solutions. Adding another modality may not take much effort and will give their customers the benefit of having all their cardiology modalities together.

Scope

This profile covers the complete workflow for diagnostic resting ECG testing, including ordering, acquisition, storage, and reporting. As much as possible, it will follow the template of existing IHE workflow profiles such as CATH, ECHO, SWF, RWF, etc. The profile will specify vendor-neutral interoperability between hospital information systems, electrocardiographs, ECG management systems, and ECG review/analysis workstations.

Target Milestones

<Include a list of the major and intermediate milestones being tracked to ensure completion of the supplement. This includes the major milestones like the public comment preparation face-to-face meeting, publication for public comment, public comment resolution meeting and publication of the Trial Implementation Supplement. It can also include any minor milestones like "draft version available for individual review by Technical Committee members", "Open Issues 1 - 4 resolved", etc. >

• 7 January - Review open issues and "plan of attack" with Technical Cmte (tcon)
• 18 February - Review initial profile draft and open issues with Technical Cmte (tcon)

Highlights/ Accomplishments

<List of highlights and accomplishments. This list can either be limited to those accomplishments since the last update, OR it can be a cumulative list in reverse chronological order (i.e., most recent at the top of the list).>

Risks/ Concerns

1. Reporting (creating the signed ECGs) is part of this profile. However, should the profile also cover report distribution? Or will other IHE profiles cover it, and we should just make sure ECG requirements are covered? Some of the report distribution items to consider include dropping PDF and Annotated ECG XML files into folders, sending PDFs in HL7 messages, DRPT, XDS publish of PDF/CDA/DICOM, queries via DICOM/XDS/IHE ECG.
2. There are many different reporting workflows in use for resting ECG. These include automatic reporting (no cardiologist review), single-step review and sign, multi-step edit, review, and sign. And so on. Can this profile handle all the scenarios? Are these just configuration details for the Report Manager actor that have little affect on the actors and transactions to be specified?
3. Should we handle ECGs with no patient identification? ECGs may be somewhat unique because patients presenting with certain symtoms in the Emergency Department need an ECG immediately to catch urgent conditions, including ST Elevation Myocardial Infarction (STEMI). Even if ECGs are initially acquired without patient identification, must ECG management systems be able to receive and handle these unidentified patients, or can they reject them until patient identifiers are added to the ECGs? Some current information systems will not accept records without at least an MRN, and some devices compensate by generating false MRNs so the records are accepted.

Next Steps

Create complete set of use cases.