2012-04-16 PCD Pulse Oximetry Project Meeting
Weekly Conference Call
Date: Monday, April 16th, 2012 Meeting will start at 1 pm.
Attendees
- Leah Krynicky
- Ioana Singureanu
- Rob Rawlins
- Tocher Kellom
- Serafina Versaggi
- Ben Loewenbach
- Mike Henderson
- Sara Toscano
- Catherine Hoang
Agenda
- (05 min) Roll call and meeting minutes approval
- (40 min) This call is intended as a walkthrough Pulse Oximetry Requirements Analysis for review. The review comments are due by April 23rd and the comments may be added to the document or submitted using the peer review form.
Meeting Notes
Ioana reviewed the Pulse Oximetry Integration Project Requirements Analysis document and how to read it. She has distributed a peer review form for the document.
The primary focus of the use case is to address the documentation of the results taken at the point of care. The two scenarios are continuous communication and spot check.
The use case diagram includes the patient and probe distinct from the pulse oximeter. The operator and the verifier are two human roles in the process. The device manager communicates with the information system. Ioana altered the workflow to indicate that the verifier is explicitly responsible for the validation of information in the information system. The steps in the workflow are numbered and have descriptions following the diagram. Data objects in the workflow are also defined. Ioana asked that folks review the workflow to ensure it concurs with their understanding. Ioana asked for feedback regarding which attributes may be optional.
When using an identifier, we mean it to be fully qualified. It will not be permissible to just have a number. HL7 has specific formats for person name that we are using. There is not a lot of agreement about which are mandatory. Typically, family name is required at a minimum.
Rob asked how to identify what is a required parameter for the oximeter for the device manager versus something optional for the workflow. Ioana stated that we do not identify what is required by the device. This is the information required by the information system. If your device is communicating directly with the information system then all information is mandatory for the device. Information not supported by the device would have to be added by the device manager. Whether information is coming from the device or the device manager the information will eventually go to the information system. Rob stated that the goal is to eventually not have the device manager. Whoever is writing the device interface needs to understand what is required and what is optional.
Rob asked about the alarms committee. Ioana stated that the purpose is not to identify all possible alarms. We can agree on priorities for alarms. An example list of event codes might be helpful, but we are not in a position to list all possible codes. Rob stated that if there is not some sort of standardization of the text there could be such a wide variety that it would be useless. Ioana stated that the text is meant to be free form. The codes are what should be standardized. Rob agreed that the codes should be standardized. Action: Ioana requested that Rob provide a starter list of event codes as part of his comments.
Rob asked if there is a way to determine if something is required or optional based on the terminology used. Ioana stated that the value sets are meant to give a set of possible values. The devices should use the subset of values that are applicable to how the device is intended to be used. Ioana asked that folks look for values that are missing when they review. Rob asked if there are preferred but optional parameters. Serafina stated that terminology does not give you this information. Ioana stated that the cardinality tells you if something is optional. If there is a “0”, it is optional. Mike recommended including cardinality on all attributes in order to clarify what is optional and what is required. Ioana will replace “0..1” with “OPTIONAL” and “0..*” with “OPTIONAL REPEATED”.