Resting ECG Workflow Status

This template is for the one page status overview of an IHE Cardiology Supplement that is currently undergoing development. Delete text in italics and replace it with your material. Don't forget to delete the double quotes too.

Administrative Info

Date: 7-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 should 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 vendor’s 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 will identify the actors involved in this workflow and how they will communicate. It will reuse as many actors and transactions from existing IHE profiles as appropriate. Consideration will be 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 will make 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. Work on this profile started in Spring, 2008 before the domain was archived. The technical contributors represented electrocardiograph, PACS, and EMR vendors. The group was working towards a profile that reused many of the HL7 and DICOM transactions from similar IHE workflow profiles. DICOM was the preferred standard for communicating with the electrocardiographs. However, the group had not gotten into the details to know if there were any shortcomings of the existing HL7 and DICOM standards that would need to be addressed by the SDOs.

Scope

<Objective, key content of the profile supplement. This can likely be taken from the Profile Proposal or the Supplement intro that describes the profile at a high level. This content should not change much after initial creation of the profile-specific status page>

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

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

<List of any risks and concerns associated with completing the profile supplement. This list should include both "technical risks" (e.g., uncertainty about available standards, etc) as well as "project risks" (e.g., issues with availability of key supplement team members, etc). Some of the risks in this section (especially the technical related ones) may be taken from the "Open Issues" section from within the Profile Supplement.>

Next Steps

<List the next steps that need to be taken and/ or action items that need completing in order to progress toward reaching the next milestone(s)>