2012-02-27 PCD Pulse Oximetry Project Meeting

From IHE Wiki
Revision as of 14:01, 25 August 2015 by Chrisdcarr (talk | contribs) (→‎Action Items)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Weekly Conference Call

Date: Monday, February 27th, 2012 Meeting will at 1 pm.

Attendees

Agenda

  1. (05 min) Roll call and meeting minutes approval
  2. (25 min) Use case discussion: this will include a discussion of the trigger events that initiate an exchange of pulse oximeter results from a device. We need to reach consensus on the distinction between the probe and the device that intended to exchange information. We will also discuss aspects of the workflow to clarify how and where the device data is validated for each use cases. We need to clarify whether the Anesthesia Record will contain validated results, raw device results, or a combination of the two.
  3. (25 min) Data Requirements Analysis: The information exchanged along with the results for pulse and oxygen saturation. This may include: device allowable ranges, patient-type (e.g. adult, pediatric) reference ranges (from device, from device manager, or added in the receiving system), verification indicator specifying the clinicians validated a result, operator identity - for verified results. We will also discuss alarm conditions intended to be reported to the clinical information system - primarily for those results that were not validated at the point of care.
  4. (5 min) Action item update

Meeting Notes

  • Minutes from 2/13/12 meeting were approved.
  • Use Case Analysis:
    • Ioana presented a high level view of pulse ox activities and who is participating in these activities. The patient is not included because Ioana is focusing on those actively involved in the process. Participants include the clinician, the pulse oximeter, an optional device manager, and the information system. There are two modes for communicating information depicted in the image.
    • The device manager is a middleware component. It is not something that the clinician would interact with but might bridge between the protocols used by devices and the standards information systems might expect. It is an enabling technology that optionally could sit between the device and the information system. Device managers might provide translation/transformation functions. This is an optional item because it would not be needed if the pulse oximeter can communicate with the information system out of the box.
  • Business Process Workflow:
    • Ioana reviewed the workflow. The use case is focused on interoperability, but we are also interested in how clinicians are interacting with the device.
    • Catherine recommended that “mark result as valid” should be in the clinician lane.
    • Sean asked what a clinician would do if he could not obtain a valid result and wanted to delete the entry at the “correct error” step. Ioana will add a step for aborting the reading. Catherine recommended adding “discard invalid results” at this point. Ioana stated that at this point there are no results to be discarded because nothing has been sent. The clinician wants to abort the process of taking a reading. “Discard invalid results” occurs within the information system. Catherine and Ioana agreed to call items not yet validated “entry” rather than “results”.
    • Sean asked if there was a business rule about when validation is required or if there can be flexibility regarding how frequently a facility wants to validate the data. Ioana stated that continuous data would not have the verification step. Business rules are on the information system. Sean stated that everything could come in as verified by the system, and the nurse could provide additional verification and mark as valid. Ioana agreed. Unverified data is data that comes into the system directly from the device and has not been validated by the clinician.
    • Catherine asked if persist results includes displaying and storing results. Ioana confirmed that this is what is meant.
  • Class Data Analysis:
    • The group agreed that it is advantageous to display both the recorded and corrected time.
    • Pulse oximeters do not always provide a time stamp. A device without a time stamp would likely be a consumer focused device such as an exercise device. This is not something that would be capable of sending information and is out of scope. Catherine recommended a statement that pulse oximeters not capable of exchanging information are out of scope.

Links

  • Use case analysis: actors and main business use cases"

PulseOx UseCaseAnalysis,v1.png

PulseOx Workflow,v1.png Workflow description for business use cases for Pulse Oximetry

  • 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..*].

PulseOx DataAnalysis,v1.png

Action Items

  1. Item:
  2. Item:

Back to PCD Pulse Oximetry Integration Project main page