2012-03-19 PCD Pulse Oximetry Project Meeting

Weekly Conference Call

Date: Monday, March 19th, 2012 Meeting will start at 1 pm.

Attendees

[expected]

• Leah Krynicky
• Ioana Singureanu
• Catherine Hoang
• Toni Philips
• Rob Rawlins
• Sean McFarland
• John Rhoads
• Tocher Kellom
• Ben Loewenbach
• Greg Staudenmaier
• Serafina Versaggi
• Don Morge
• Sara Toscano

Agenda

1. (05 min) Roll call and meeting minutes approval
2. (40 min) Data Requirements Analysis: We will continue last week's discussion of coded information and expand the discussion to alarm conditions and alerts. We also have additional information about reference ranges provided by John Rhoads:
   • Pleth variability index – this may still be a one-vendor proprietary measurement. PVI may be a trademark. This may raise some issues for standardization and for IHE.
   • Some devices report several, for example:
     • the extreme range of technically possible measurement values from the device, regardless of whether they are consistent with being connected to a living patient (as for example, when connected to a test instrument) (rare)
     • the physiological range (extreme range of physiologically possible values)
     • the “normal” range, which may be settable by the user on a unit, patient category (e.g. neonate, pediatric, adult) or individual case basis (used for reference or display, as for example to place reference lines on a graphical display, but not used to generate alarms)
     • the alarm range outside of which the device generates an alarm, usually settable per patient
     • a panic range, a wider range outside of which a higher severity of alarm (e.g., life-threatening vs. non-life-threatening) is initiated

Maybe we only need one or perhaps two, but you need to specify what the meaning of the range is.

1. (10 min) Document Review Process We will discuss the process used to peer-review the analysis model.
2. (5 min) Action item update

Meeting Notes

We received additional thoughts from Dr. Goldman: There should be a "signal strength" or "percent modulation" available (some call it Perfusion Index, some have other names). This is essentially a measure of the AC component of the pleth, assumed to be produced by cyclic blood flow.

Alarms - most instrument shave "high" and "low" for various parameters. Some have two sets so that, for example, a small violation in sat produces a medium priority alarm, and a larger variation a high priority.

Instrument averaging time should be available over the interface. It is an essential part of interpreting transient desat events (for example, counting desat events in neonates, or measuring the lowest sat achieved during apneain a sleep study)

The probe type should be communicated (e.g. Neonatal, adult, ear, etc)

(At some point I'd like to review the list of all the 'goes out of" and "goes in to" signals for the pulse ox. Please let me know when/where to do that.)

• Trademark:

John Rhoads stated that there is a trademark claim that might lead to IP problems. If we use PVI as a code we may be infringing on a trademark. Ioana will investigate to determine if there is a problem in using this.

• Range of Alerts:

John also discussed the range of alerts. The alarm range and extreme alarm range would be of interest to us. Reference ranges are not used for alarms but are used for things like drawing limit lines on a graphical display. Rob Rawlins stated that there are also technical versus physiological alarm. Technical alarms are for things like low batteries and are not related to the patient. Ioana asked which range we would want to send to a nurse and what range would notify a clinician that something is wrong with a patient. We are trying to communicate results for pulse oximetry and to communicate alarms for the physiological status. We will provide a reference range or the receiving system and supplement a range of its own. Will we provide the physiological range, the normal range for a specific type of patient, an alarm range, or a panic range? Rob stated that not all devices will use this terminology. Sean stated that typically you would have the normal range. Anything outside of that would be abnormal. It would be nice to know when an alarm went off and to differentiate if it is a panic alarm. There could be a list of triggers for alarms. Rob stated that it might be good to standardize using the term alarm and to distinguish when there is a physiological alarm. Ioana suggested that some alarms should be focused on point of care and others on the readings. Rob stated that a low battery will not invalidate readings. Ioana stated that alarms about changing batteries probably do not need to enter into the information system. Ioana suggested distinguishing between technical and clinical alarms. Rob agreed that this distinction should be possible. John stated that we should stay aligned with the IEC standard for alarms. Toni Phillips stated that from the point of care perspective you make decisions but from the research perspective you might want to know about other alarms. Ioana stated that the normal range would part of each measurement. We need to figure out what the other alarms tell us about the status of the message. Toni stated that there are times that you might want to know the highs and lows on the alarms. Ioana agreed and stated that we would need to determine configuration ranges for alarms. The technical alarms don't have anything to do with the physiological status of the patient and probably will not be in scope. Sean asked if a probe disconnected would be a technical or clinical alarm. John stated that this would be technical but would be a serious alarm because it is blocking the measurement. Sean stated that it would be clinically relevant how long this was occurring. However, it would not indicate why it was disconnected. Ioana noted that disconnect events might be a normal part of clinical care. A disconnected probe would report 0. Toni stated that in the moment, a zero would be useful and you would probably be doing something about it. In retrospect, there wouldn't be context and it wouldn't mean as much. Rob stated that by having a device report a 0 along with "sensor off" it would prevent other devices from continuing to report the last reading. Ioana stated that ideally a device should report a signal strength 0, result of probe disconnected, and value of 0. Rob stated that device manufacturers report things differently and have done so based on research that they conducted. It might be difficult for them to change the process, for example if it violates some risk mitigation that they put in place. Ioana stated that the device manager might be able to back fill some of these capabilities. Ioana asked if this should be on the flow sheet or the device manager. Rob stated that not every device will implement alarm standards in the same way. Two different devices will have different technical alarms. John agreed that technical alarms are the purview of the vendor, but everyone must comply with the things in the standard. John stated that there are times when the device might doubt the credibility of the data and that this would come with a note that the information is reliable or not. This is a quality measure rather than technical alert. Ioana stated that this uncertainty code can come from many causes.

• Signal strength:

Rob stated that signal strength can be recorded in multiple ways. The group agreed that this should be part of every reading.

Ioana might simplify by adding severity code to alarm and removing event configuration from the diagram.

Rob stated that he investigated when there might be an alert rather than an alarm. He determined that we will typically not deal with alerts. New standards might change this, but current standards that apply deal with alarms, particularly with the distinction between technical and physiological as discussed above. There is an ISO standard for pulse oximeters that there will be an indication of measurement delayed if you cannot get a reading within 30 seconds. Ioana stated that if we see information with a delayed flag we will know it is a previous value. FDA does not have guidance on this. Ioana stated unless there is a reason to suppress technical alarms we will allow them. It would be good to distinguish between technical and clinical alarms.

Ioana will follow up with Toni to provide background info to Dr. Edwards and Dr. Gunnar. Ioana will provide a summary of the workflow and will work with Toni to present the data with enough context.

Links

• Our data analysis identifies the core data elements required to support the use cases. Optional data elements are indicated by the [0..*] cardinality notation and repeating element are specified as [1..*].

Action Items

Refer to last week's action items

Back to PCD Pulse Oximetry Integration Project main page