PCD Detailed Profile Proposal 2009 WCM

From IHE Wiki
Jump to navigation Jump to search

Proposed Workitem: Waveform Communication Management [WCM]

  • Proposal Editor: Ken Fuchs
  • Editor: Ken Fuchs
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Patient Care Device

Summary

The WCM (Waveform Communication Management) Profile provides support for the communication of physiological 2-dimensional waveforms that have been digitized at regular time intervals (e.g. every 2msec for an ECG waveform). This data can then be reported using the IHE PCD WCM Profile as either a time-bounded waveform report or a continuous stream of waveform data.

2. The Problem

Waveform data is an important component of information coming from medical patient care devices. This information can be an important complement to assessing the current status of a patient or the status of a patient during a clinical event. As such waveform information can be provided in a number of forms:

  • waveform snapshots
    • specific forms of snapshots such as 12-lead ECG associated with a diagnostic encounter
    • general snapshots of waveforms captured during a clinical event or due to a request by a clinician
  • continuous waveforms
    • a continuous "real-time" stream of waveform data that would be used for a remote "real-time" waveform display

Independent of the form of waveform, the following information must be accommodated:

  • waveform type (e.g. ECG, Arterial Blood Pressure, CO2, etc.)
  • sampling rate
  • start time
  • event time
  • scaling (e.g. #bits/mmHg in the case of blood pressure)
  • annotations (e.g. pacer, beat-label, QRS, respiration, out-of-range, etc.)
  • status (e.g. lead-off, out-of-range, test mode, etc.)
  • filter status (e.g. low-pass, high-pass, etc.)
  • number of waveform samples
  • suggested waveform display color
  • units of measure
  • patient identification
  • clinician notes

A waveform snapshot may also include encapsulated vitals signs and event related information. The real-time waveform probably has this information as part of DEC or ACM data stream.

3. Key Use Cases

  1. A patient enters the Emergency Room complaining of pressure on the chest wall. A 12-lead ECG is obtained and transmitted via WCM to the Cardiology Management System. The data is reviewed and annotated and sent via WCM to the hospital Clinical Information System as part of the patient's clinical record.
  2. A patient, post Heart Attack, is walking in his room while being monitored using a patient telemetry system. The system detects a run of ventricular beats and generates an alarm at the central nurse station. In parallel the alarm information, including the waveform, parameter data and alarm information is acquired by a separate alarm communication system which then sends the appropriate information snapshot to a caregiver's portable device.
  3. A physician would like to review the current status of a patient including his parameter information, waveforms, device settings, etc. He brings up an application on his PDA or personal computer and can view the current information delayed by a maximum of 10 seconds.
  4. A physician starting his rounds would like to review the waveforms and associated data for a patient under his/her care. He/she accesses an archive which has stored the continuous waveforms and related vital signs and other parameter data over the past 24 (or more) hours.

4. Standards & Systems


5. Technical Approach

<This section can be very short but include as much detail as you like. The Technical Committee will flesh it out when doing the effort estimation.>

<Outline how the standards could be used/refined to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility.>

<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>


Existing actors

<Indicate what existing actors could be used or might be affected by the profile.>

New actors

<List possible new actors>


Existing transactions

<Indicate how existing transactions might be used or might need to be extended.>

New transactions (standards used)

<Describe possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>


Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>


Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>

6. Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

7. Risks

<List technical or political risks that could impede successfully fielding the profile.>

8. Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>

9. Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA



5. Discussion

Use Case 1 - there are already DICOM based IHE profiles to support the transmission of 12 Lead ECG Data. During the Oct. 2008 F2F it was decided that 12 Lead Rest ECG reports would be out of scope for this profile.
Use Case 2 - a basic decision needs to be made whether these types of applications require 'raw data' or images such as jpeg files. This scenario is closely related to work being done on the ACM Profile. During the Oct. 2008 F2F it was decided that 'raw data' would be the best way of transferring this type of data. This is the best way of supporting very widely varying display sizes, form factors, pixel areas, etc.
Use Case 3 - this is a good example of the possible use of the WCM profile.
Use Case 4 - this Use Case is related to the Query for Bulk Data (QBD) Profile and will be handled as such.
Retrieved from "http://wiki.ihe.net/index.php?title=PCD_Detailed_Profile_Proposal_2009_WCM&oldid=29651"