* Germaine: Met with physicians in Brussels who are BIOCOS participants and talked about the web site.
Table Contents
* Component Model
* Architectural Onion
* Requirements Layer-by-Layer
Component Model
* Monitor measures the Wearer
* Wearer records observations in the Diary
* Administrator & Physiologist use Data Analysis Software
to assess the data collected by the Device
* Diary influences the interpretation of the data
* Clinical settings: data stored in Medical Record Systems
Data Analysis Software Subsystem
* Analysis Workstation
* Reference Data Workstation used by Chronobiology Center
* Analysis Workstation relies on model parameters from Reference
Data Workstation.
Architectural Onion
(from the center to the periphery)
* Body
* Data Acquisition
* Data Transport
* Session
* Analysis
* Tool Integration
* Plotting & Charting
* Reporting
* Desktop Integration
* Identity Management
* Clinical Integration
* Networking - communities, websites.
* Change Management
Body
* DBP/SBP/HR/Blood Flow/Physical Activity
* Low cost
* Nonintrusive
* Performance: beat to beat
User-Noted Events
* Integration with diary
Data Acquisition (DAQ)
* Digital signal processing (DSP)
- Collect signal data from sensors
- Collect user-noted events
- Convert signals/events to measurements
* Flexible framework for sensor configuration that varies by:
- Sensor technology
- Biophysics
- Target measurements
* Stamp each measurement
- Time
- Trustworthiness
* Subject to calibration
- "Good" vs " Bad"
- Extent to which the measurement
reflects reality.
- Same as accuracy.
* Capacity
- 7 days of data
- 30 minutes between measurements.
Germaine: asked why every 30 minutes. ABPMs enable multiple
rates to use all of the storage capacity, i.e. every 7 minutes
for 1 day vs. 30 min for 1 month, or vary them by day and night.
It needs to be configured at point before it is "installed"
on the wearer. Adjust the measurements, or by time ranges. 5 min,
20, 30, 60, 2 hrs is the current default choices. Four time ranges
starting from midnight and ending at the following midnight.
Gerry: There are three events: the time the event occurred, the
time it was recorded, and the time it was added to the patient
record, and the time it was invalidated because it was linked
to the wrong record (i.e. the changes to the record). Also, what
about time zones? Germaine: maintain the time zone at which the
measurement was taken. Also, we have this issue with shift workers,
for example, those who start working at 4pm.
Bob: Also, there is the time we start the measurement and the
time we stop making that measurement. We record the time we start.
Acquired Data Alarms
* Simple analysis of acquired data
- Compare measurement to limit
- Limit may be user-specific
* Respond to limit violation
- Categorize violation
-- Caution
-- Warning
-- Alarm
- Tag measurement
- Alert user or other subsystems
Why alarming? Chris thought it was an implied extensibility requirement. Germaine said the Colin ABPM had an alarming setting.
Data Transport
* Communications
* Framework for multiple transports
- RTF, Bluetooth, serial, USB removable flash memory.
* Open protocol
* Integrity assured. (the data sent was the data received)
* Source authenticated (the data was sent from that device.
Chris: Designed to prevent unintended mistakes, not intended security violations. It is not a requirement to detect fraud
Session Management
* Session":
- a period of time devoted to a specific activity
- a period during which
-- a device is connected to an analysis workstation\
-- data is uploaded to the workstation
-- the data is analyzed.
Chris: I wanted to define the process of uploading the package of measurements and perhaps I need to use a term other than session. El: is this a file transfer. Chris: Yes, if it is a file.
Session Management
* Need
- Handles sequences of data independent capacity of da acquisitin9o
device.
- Requirement for 7 days of data
Longer cycles are in play
Session Management
* Use can change sessions into super-sessions
* User can split sessions into sub-sessions
* System analyzes any data
- Session
-- Super- session
-- sub-sessions
The initial focus was to create a circuit that wasn't single
channel or clipping, a flexible substrate for the circuit. That's
what we accomplished in the May timeframe. We noticed that it
was very difficult to get good measurements. We discussed it and
decided to focus on the sensor portion to improve on what we did
earlier. We obtained some FLDT (with plastic backing) and FDT
(without). They were more sensitive and had as lower capacitance.
We tried them with different configurations, Velcro, inflated,
deflated, with different cuffs, used a charge pump (register and
capacitor with an amplifier to show that the signal corresponds
with what we were getting with other cuffs. We assured that we
were getting good signal. It worked with a backing. At first we
used tapes, but we don't think this is consistent enough for general
use. We need an inflatable cuff; with it we can get a good signals.
Many of these measurements were baseline, about 0.5 volts. Between
adhesive, Velcro and inflatable cuff, inflatable cuff is best.
However, we could get acceptable measurements with a Velcro strap,
like a watchstrap, around the arm, but we did not get acceptable
measurements with adhesive. We investigated the piezo film in
the existing kit, not the new sheets the Phoenix Project recently
ordered. They will require fabrication into sensors, and the person
who follows us, who is a graduate student from Jim Holte's class,
will do this.
Bob: I see that you calibrated to the SBP. Did you calibrate to
the DBP? Inanc: No, we did the SBP. But, we showed we could go
from signal to measurement.
We agreed to have another meeting dedicated to learning about Inanc and Ashok's sensor project, outside of these Coordinating Team meetings on the second and fourth Sundays. We decided to meet on the first Sunday on October 7th, 2:30-4:30 p.m. at at University of Minnesota, Mayo Memorial Bldg., Room 748 (Lazarow Conference Room), same time and location as this meeting today.
El will meet with Inanc and Ashok on Monday, October 1st at
Expresso Expose coffee shop at Harvard and Washington to show
to them how to easily post their interim work on their Phoenix
webpages in a portable manner, using a flash drive on any computer
that is connected to the Internet. Ashok will bring his notebook
computer and Inanc will bring a flash drive. Then, they'll post
their work as they develop it so that others can comment and use
their results. Unlike commercial or academic publication where
one waits until the work is complete to publish, in the open source
community one publishes interim work, as work-in-progress, to
leverage the network effect by encouraging useful comments, questions
and usage as early as possible and without concern that interim
errors or changes would diminish the perceived quality of the
work in the "final" version.
Scut: Important Loose Ends and Open Issues in Clinical Care.
* Did it get done?
* Is it complete and correct.
* Has it been put (coded) into the billing system.
* Has follow-up with the patient been done, are they improving.
* How do I document that I want that done.
Discussion: This sounds like project management. Actually, this sounds like workflow management. A general workflow management tool and a user interface to manage it. Gerry says that for scut you often hire an intern to "clean it up". But how can someone who is an intern and doesn't have the domain knowledge, resolve the scut. We noted that in some industries, scut is assigned to an intern, or new employee, because it is not necessarily of low value, but is of unknown value and crosses over all of the current process boundaries. As a result, it may represent an opportunity for the person for rapid advancement, by redesigning the current system or organization. It depends on the person. Then, we noted that it depends on whether you want a tool to address the scut separately or redesign the system to eliminate this scut by absorbing it into the new system as part of the new standard process, possibly as a new policy for the policy engine.
Chris noted that an example of a tool that might be appropriate for scut as a workflow policy engine is produced by Haley Systems at: http://www.haley.com . Look at their commercial tools to identify the terminology and concepts.
Then, look at the Java Specification Request, JSR, for the implementation of rule engines at http://jcp.org/en/jsr/detail?id=94 .
This page is maintained by Ellis S Nolley. It was last updated on 23 September 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