Resting ECG Workflow Status

From IHE Wiki
Revision as of 17:15, 7 December 2009 by Barrybrown (talk | contribs)
Jump to navigation Jump to search

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

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