Phoenix Ambulatory Blood Pressure Monitor Project
1/23/2005 Meeting Notes


Attendees


Discussion

Our next meeting will occur on February 13th.

Status Review:

Wade: Impediance Plethymograph sensor, patent registration and placement in public domain reports.

Dennis: Use Cases and investigating the of use of Wiki.

Germaine: working with Yoshihiko on longitudinal cases and intermittent monitoring, 2) Richie & Ryan's project of 5 weeks of ABPM use on 14 students and interest in schools and a french software developer graduate of the university, and 3) report on analysis methods to post on Phoenix website.

El: Phoenix coordination and medical regulatory compliance.

Bob: Blood pressure compliance to cuff standard and space questions.

Larry: reading about regulatory issues.

Gerry: Thinking about a clinical information system, reference model, what is available, Vista has pieces, 1-10 physician practice. For Phoenix this could lead to: 1) enlarging the scope of Phoenix to include the clinical information system, 2) spinning off a separate study group that develops a clinical informaiton system and working closely with them, 3) looking for opportunities to help Jerry in his quest to develop a clinical medical information system. To Phoenix, Jerry brings the insight that we need to interface a clinical informaotn system and we can consider accomplishing it as: 1) selecting a reference interface and model, 2) selecting a specific clinical information system or 3) helping Jerry develop one.

Chris: We need to develop hardware, software and interfaces, and we need it to be done at the same time.

Bob: We will not be able to put it on a person until it is equal or better than the existing cuff standard.

Regulatory Requirements:

Chris: In the open source world, most testing is informal, you don't have requirements specification in one document, they are spread over the community. Alpha testing is ad hoc, beta testing is throwing the product out and gathering reactions and responding to them. Because most developers are also users and they are not safety critical, this works. Do we have to have acceptance tests for all aspects, do they have to be auditable.

Bob: 1) it must show that it produces data comparable to the blood pressure cuff, 2) must show no adverse effects, 3) show the information can be used without error (can achieve desired outcome) - we can justify our clinical claims, (Jerry calls the Receiver Operator Classification ROC), Preinvestigation. We need a name for this activity - the PID (preinvestigational activity. What do we test?

Bob: We need a test for #1 - comparable with BP cuff, we need a test protocol for #2- how no adverse effects. And we expect more than just blood pressure.

Jerry: Is there a method like OOD that can take the design and implentation and produce the documentation that FDA requires?

Bob: 510K has a way to claim that it is like everyone else, and claim it is like another approved device.

Infrastructure:

Chris: presented the Phoenix Process Framework, page 4, the Framework Matrix. Issues include: Marketing, Human Resources, Systems Management, Software Engineering, Project Management. Each of these is done differently in open source projects. For asynchronous communication we need: Email (we have at tc-ieee-phoenix@majordomo.tc-ieee.org), mailing lists with archives (discussion threads), Project web site (we have at www.phoenix.tc-ieee.org), discussion forums (news servers, web forums - perhaps Yahoo groups), How-to-guides, FAQs, Web content management system (collaborative webpage editing), and perhaps Wiki or Jot.

Dennis: distributed a summary of Wiki, Wikis at Work, at: www.pcmag.com/article2/0,1759,1743602,00.asp .
Software Engineering leads to revision control systems, eg. CVS or Subversion, we need checkin and checkout for collaborative software development and bug/issue tracking to attach a schedule and issue tracking, Build Systems to identify the build and how it is working, Quality assurance, Unit testing frameworks like Junit, code checkers like codestyle, and REmote Code review tools that enable online code reviews to conduct the review, collect comments, enable coder to see them and issue as report. Collaborative Development environments like SourceForge.net which provides a home page, revision control software, discussion forums. Tigris.org is building software development tools including templates for a project engineering site.

We need better asynchronous communications including discussion forums, a wiki so that we can start as teams working on requirements, content management, eventually revision control, bug management, begin thinking about a collaborative development environment. Start doing prototyping with revision control so that prototypes can be saved somewhere, release manasgement (release early, release often - small increments) that provides a sense of progress and a sense of system.

Wade: what we need on hardware side is a sensor that works.

Chris: Now we need action items. Does our websitre support: Servelets (Tomcat), CGI? Next issue is what will we write our product in - e.g. Java, ...

Germaine: Macanova is an open source alternative to Matlab.

Wayne: Project Management Institute (PMI) has local chapters, is software intensive, and would be interested in learning about open source, and may be interested in supporting marketing activities. Mets the 3rd Thurs of each month at the Double Park Place in Minneapolis. They are focused on developing the professionalism of project management.

 

About This Page

This page is maintained by Ellis S Nolley. It was last updated on 13 February 2005.

The author(s) provide this information as a public service, and agree to place any novel and useful inventions disclosed herein into the public domain. They are not aware that this material infringes on the patent, copyright, trademark or trade secret rights of others. However, there is a possibility that such infringement may exist without their knowledge. The user assumes all responsibility for determining if this information infringes on the intellectual property rights of others before applying it to products or services.

Copyright (C) 2004 Ellis S. Nolley. Copying and distribution of this page is permitted in any medium, provided this notice is preserved.

Back to the Meeting Archive Page

Back to the Phoenix Home Page