2012-03-19 PCD Pulse Oximetry Project Meeting: Difference between revisions
Jump to navigation
Jump to search
Created page with "=Weekly Conference Call= Date: Monday, March 19th, 2012 Meeting will start at 1 pm. ==Attendees== [expected] * [mailto:lkrynicky@theambitgroup.com Leah Krynicky] * [mailto:ioana..." |
|||
| Line 25: | Line 25: | ||
#''(05 min)'' Roll call and [[2012-03-12 PCD Pulse Oximetry Project Meeting | meeting minutes]] approval | #''(05 min)'' Roll call and [[2012-03-12 PCD Pulse Oximetry Project Meeting | meeting minutes]] approval | ||
#''(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: | #''(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: | #* 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 '''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) | ||
| Line 34: | Line 35: | ||
#''(10 min)'' '''Document Review Process''' We will discuss the process used to peer-review the analysis model. | #''(10 min)'' '''Document Review Process''' We will discuss the process used to peer-review the analysis model. | ||
#''(5 min)'' '''Action item update''' | #''(5 min)'' '''Action item update''' | ||
==Links== | ==Links== | ||
Revision as of 02:00, 19 March 2012
Weekly Conference Call
Date: Monday, March 19th, 2012 Meeting will start at 1 pm.
Attendees
[expected]
- Leah Krynicky
- Ioana Singureanu
- Catherine Hoang
- Tom Bauld
- Toni Philips
- Rob Rawlins
- Sean McFarland
- Mike Henderson
- John Rhoads
- Rob Rawlins
- Lee Winslow
- Tocher Kellom
- Ben Loewenbach
Agenda
- (05 min) Roll call and meeting minutes approval
- (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.
- (10 min) Document Review Process We will discuss the process used to peer-review the analysis model.
- (5 min) Action item update
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..*].