Status
* Larry Beaty. We need to start our embedded project. Franz Zheng
is interested in the sensor group, not the software. We have a
science writer in Minnesota Monthly interested in writing about
the Sphygmochron website or Phoenix Project, tasked to write about
circadian rhythms, facilitated by Franz. Larry asked about confidence
in ABPM measurements.
* Bob: Noted in his initial notes that we would have our first
sensor in 90 days and that didn't happen. He feels that he isn't
making any progress on his projects and he would like to be relieved
of his current projects of Cuff Calibration and Physiology listed
on the Projects page. The Innovation Study Group, run by Curt
McNamara, is meeting next Thursday to work on blood pressure.
* Mike: Talked about the Innovation Group's work on blood pressure,
not necessarily Phoenix related. They are thinking about using
the body's baroreceptors that regulate blood pressure to measure
blood pressure.
* Chris: Working on architecture specification and systems specification.
Architecture specification will decompose the system into small
pieces, and identify where the subprojects should be and adhere
to patterns, and identify pertinent subsystems that we'll need
to model. "The systems requirements document will allocate
the requirements to a specific piece. For example, we'll need
to monitor the blood pressure, need three pulses, collect seven
days of data, stored here, etc. You don't specify them, but rather
guide them. The more refined the requirements are, the better
you can define small projects.
Bob recommended that the specifications be presented as text in
the form of a pdf, and that authority to change it is restricted,
and later put the requirements into Access or Excel, with the
requirements identified by a number or letter designation. Chris
says requirements are important for traceability and accountability.
Bob says words are important because they can be read and understood.
We had questions about at requirements analysis tools, modeling,
traceability, and coverage. Chris commented that typically, stakeholders
don't perform modeling, thus aren't interested in that function.
In requirements analysis products, the modeling function produces
diagrams and flow charts. We looked at www.sourceforge.net,
searching on "requirements analysis" and found several
products.
* Mary Jo: Wanted to know how to purchase components and obtain
reimbursement from Phoenix. We described our process as: 1) that
buyer should determine "ballpark" costs, 2) buyer sends
an email request to El, 3) El will send an approval to the buyer,
4) buyer should purchase the items and send receipts to El in
digital form, 5) El will create pdf's of them, 6) send a reimbursement
request to IEEE specifying that the check be mailed to the address
the buyer designates, 7) the check will be sent to the buyer within
2 weeks and El will be notified, 8) buyer will notify El when
they receive the check, and 9) The buyer and El will create a
document with three signatures (buyer, two other members of Phoenix)
that claim that the Phoenix Project owns the items. Also, Mary
Jo will send a project plan webpage or Word document, and El will
post it, linked from the Projects page, and send her logon and
instructions for how to maintain a webpage so she can post her
project results and establish a framework for future projects.
* Jim: Talked about the project by Ashok and Inanc to analyze
how to convert a signal to blood pressure.
* Ashok and Inanc: introduced themselves and said they would send
a project plan webpage for El post and link from the main project's
page.
* Germaine: presented on confidence of ABPMs and their history.
She discussed the work they had with CMI, a manufacturer of ABPMs
that no longer exists. She will post her presentation on her Data
Analysis page.
Sociotechnological Issues of Clinical Computing: Common Examples of Healthcare IT Failure.
Sue Prince MSN RN, 8 June 20007, AMAIA [cis-pwg]: (email)
* The "rape and pillage" of healthcare
by corporate greed.
* It is incredible, software should be a subscription model so
it is operational and the cost should be negligible. Need to find
a way to fight against the self-interest of one organization and
focus on the interest off the patient, the community, the nation
and the world.
Scot Silverstein, MD, Drexel University
Common Examples of Healthcare IT Failure
www.ischool.drexel.edu/faculty/ssilverstein/failurecases/
He paraphrased Bill Hersh at OHSU, "if you are spending millions on your electronic health record (EHR), perhaps you should invest thousands in information education."
We want to look at other such activities and learn what went wrong so that we can benefit in our project.
His case examples include 32 items:
* Cites an article in Baseline Magazine, May 14, 2007 by Deborah
Gage and Kim S. Nash.
www.baselinemag.com/article2/0,1397,2131032,00.asp
He described George Halvorson, former chair
of Health Partners and current chair of Kaiser Permanente, "We
really did screw up on the administrative side of those transfers."
Chris concluded the key learning is that you need to focus on
the work. For anyone who interacts with the health system, they
need to model the work.
Gerry's Conclusions:
* It is more complicated than people think it is.
* It is screwing up peoples' lives.
* It is a disaster for the people involved.
Actions:
* Systems need to be designed so that they are open-ended and
we know that we don't know all of the answers.
* Evolutionary adaptation is the only way that works, and this
isn't done in commercial development.
This page is maintained by Ellis S Nolley. It was last updated on 10 June 2007.
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) 2007 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