8 march 2009 1 data acquisition prototype: project & system requirements phoenix ambulatory...

30
8 March 2009 8 March 2009 1 Data Acquisition Data Acquisition Prototype: Prototype: Project & System Project & System Requirements Requirements Phoenix Phoenix Ambulatory Blood Pressure Ambulatory Blood Pressure Monitoring System Monitoring System © 2009 Christopher J. Adams Copying and distribution of this document is permitted in any medium, provided this notice is preserved Version 1.0 Version 1.0

Upload: walter-greene

Post on 18-Jan-2018

217 views

Category:

Documents


0 download

DESCRIPTION

8 March Purpose and Scope of this Document l Specify system requirements for a prototype of a data acquisition device –Incorporate system requirements of eventual Phoenix ABPM, but… –Do not specify the Phoenix ABPM –Supplement Phoenix requirements with prototype- specific requirements l Incorporate results of sensor prototypes to-date

TRANSCRIPT

Page 1: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 11

Data Acquisition Prototype:Data Acquisition Prototype: Project & System RequirementsProject & System Requirements

PhoenixPhoenixAmbulatory Blood Pressure Monitoring SystemAmbulatory Blood Pressure Monitoring System

© 2009 Christopher J. AdamsCopying and distribution of this document is permitted in any medium, provided this notice is preserved

Version 1.0Version 1.0

Page 2: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 22

OutlineOutline Purpose and Scope of this DocumentPurpose and Scope of this Document Project VisionProject Vision System Vision & Scope System Vision & Scope (Business Requirements)(Business Requirements)

User RequirementsUser Requirements– Use CasesUse Cases– Algorithms Algorithms (Business Rules)(Business Rules)

System RequirementsSystem Requirements– Functional RequirementsFunctional Requirements– Major Nonfunctional RequirementsMajor Nonfunctional Requirements

AppendicesAppendices– Unresolved IssuesUnresolved Issues– Design Direction DetailsDesign Direction Details

Page 3: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 33

Purpose and ScopePurpose and Scopeof this Documentof this Document

Specify system requirements for a prototype of a Specify system requirements for a prototype of a data acquisition devicedata acquisition device– Incorporate system requirements of eventual Phoenix Incorporate system requirements of eventual Phoenix

ABPM, but…ABPM, but…– Do not specify the Phoenix ABPMDo not specify the Phoenix ABPM– Supplement Phoenix requirements with prototype-Supplement Phoenix requirements with prototype-

specific requirementsspecific requirements Incorporate results of sensor prototypes to-dateIncorporate results of sensor prototypes to-date

Page 4: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 44

Project VisionProject Vision Acquire community knowledge aboutAcquire community knowledge about

– Data acquisition devicesData acquisition devices– Hardware and software co-designHardware and software co-design– Partitioning systems into subsystemsPartitioning systems into subsystems– Allocating system requirements to subsystemsAllocating system requirements to subsystems– Embedded software Embedded software architecturearchitecture options options

(round robin, round robin w/ interrupts, …, RTOS)(round robin, round robin w/ interrupts, …, RTOS)– Hardware optionsHardware options

(gates, clocks, memory, MP, buses, DMA, interrupts, ports, …)(gates, clocks, memory, MP, buses, DMA, interrupts, ports, …)– Designing low-power devicesDesigning low-power devices– Acquiring hardware componentsAcquiring hardware components– Testing embedded softwareTesting embedded software

Document results so they can be reproducedDocument results so they can be reproduced

Page 5: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 55

Project VisionProject Vision Architecture — basic technologyArchitecture — basic technology

– Hardware architectureHardware architecture– Hardware component selectionHardware component selection– Embedded software architectureEmbedded software architecture– Software language selectionSoftware language selection– Cross-platform development toolsCross-platform development tools

PrototypePrototype– Must build a device to evaluate interdependent design optionsMust build a device to evaluate interdependent design options– Learning is primaryLearning is primary– Expect subsequent evolutionExpect subsequent evolution– Willing to abandon device based on lessons learnedWilling to abandon device based on lessons learned

Computing device is primaryComputing device is primary– Sensing is secondarySensing is secondary– Acquired data may be simulatedAcquired data may be simulated

Page 6: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 66

System VisionSystem Vision Data acquisition device Data acquisition device (next slides)(next slides) Embedded analytics Embedded analytics (next slides)(next slides) Embedded data storage Embedded data storage (next slides)(next slides) Device allows ambulation during useDevice allows ambulation during use

– At least carriableAt least carriable Electrically self-containedElectrically self-contained

– Does not rely on external power sourceDoes not rely on external power source Power-sensitive designPower-sensitive design

– Design for either:Design for either: Low power, orLow power, or Power measurementPower measurement

Page 7: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 77

System VisionSystem Vision Data acquisition deviceData acquisition device

– Collects continuous analog signals from two sensorsCollects continuous analog signals from two sensors At least one is piezoelectric film sensorAt least one is piezoelectric film sensor

– Measurement Specialties SDT1-028KMeasurement Specialties SDT1-028K

– Collects from piezoelectric film sensorCollects from piezoelectric film sensor Up to Up to 4040 samples per cardiac cycle samples per cardiac cycle @ 200 beats per minute (maximum)@ 200 beats per minute (maximum)

– Converts analog signals to digital signalsConverts analog signals to digital signals– Collects discrete signals from wearer-pressable push-buttonCollects discrete signals from wearer-pressable push-button

Button downButton down Button upButton up

– Turns on and off a human-perceivable device-mounted lightTurns on and off a human-perceivable device-mounted light

133 samples per second

Page 8: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 88

System VisionSystem Vision Embedded analyticsEmbedded analytics

– Identifies / marks peak of each continuous waveformIdentifies / marks peak of each continuous waveform VoltageVoltage

– Identifies / marks trough of each continuous waveformIdentifies / marks trough of each continuous waveform VoltageVoltage

– Calculates biometricsCalculates biometrics Heart rateHeart rate

– Beats per minuteBeats per minute Systolic blood pressureSystolic blood pressure

– mmHgmmHg Diastolic blood pressureDiastolic blood pressure

– mmHgmmHg– Performs calculations over 5 cardiac cycles every 30 minutesPerforms calculations over 5 cardiac cycles every 30 minutes– Translates different combinations of button-down and button-up Translates different combinations of button-down and button-up

signals into eventssignals into events

Page 9: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 99

System VisionSystem Vision Embedded data storageEmbedded data storage

– Timestamps each acquired & calculated valueTimestamps each acquired & calculated value– Preserves three days of acquired & calculated dataPreserves three days of acquired & calculated data– Preserves all acquired valuesPreserves all acquired values

See “Data acquisition device”See “Data acquisition device”– Preserves all calculated valuesPreserves all calculated values

See “Embedded analytics”See “Embedded analytics”

Page 10: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1010

System VisionSystem VisionMajor Out-of-Scope CapabilitiesMajor Out-of-Scope Capabilities

Capacity for full 7 days of dataCapacity for full 7 days of data Patient alertsPatient alerts Localization outside of U.S.Localization outside of U.S.

– ProductionProduction– UseUse

Analog signal processingAnalog signal processing– As alternative to digital signal processingAs alternative to digital signal processing– Separate research topicSeparate research topic

HMI beyond simple light bulbHMI beyond simple light bulb– Will not display calculated valuesWill not display calculated values– Continued exclusion depends on analysis of power managementContinued exclusion depends on analysis of power management

Page 11: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1111

System ContextSystem Context

Page 12: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1212

Use CasesUse Cases Wearer signals the device to log an eventWearer signals the device to log an event

– Assures data-acquisition logic despite sensor failure Assures data-acquisition logic despite sensor failure Technician or wearer confirms device functionsTechnician or wearer confirms device functions Technician connects device to wearerTechnician connects device to wearer System collects dataSystem collects data Wearer restarts data collectionWearer restarts data collection Technician off-loads data from deviceTechnician off-loads data from device

Page 13: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1313

Use CasesUse CasesWearer Signals Device to Log EventWearer Signals Device to Log Event

1.1. Wearer pushes button (and holds until step 6)Wearer pushes button (and holds until step 6)2.2. System activates status lightSystem activates status light3.3. System logs button-downSystem logs button-down4.4. Wearer observes status lightWearer observes status light5.5. Wearer may pauseWearer may pause6.6. Wearer releases buttonWearer releases button7.7. System logs button-upSystem logs button-up8.8. System de-activates status lightSystem de-activates status light9.9. Wearer observes status lightWearer observes status light10.10. Wearer may pauseWearer may pause11.11. Wearer repeats sequence according to predefined codeWearer repeats sequence according to predefined code

Page 14: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1414

Use CasesUse CasesTechnician or Wearer Confirms Device FunctionsTechnician or Wearer Confirms Device Functions

1.1. User signals device-start eventUser signals device-start event2.2. System runs System runs diagnosticsdiagnostics3.3. System toggles the status light in a pattern System toggles the status light in a pattern

indicating successful start-upindicating successful start-up4.4. Technician observes status lightTechnician observes status light

Page 15: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1515

Use CasesUse CasesTechnician Connects Device to WearerTechnician Connects Device to Wearer

1.1. Technician starts deviceTechnician starts device– Signals device-start eventSignals device-start event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”

2.2. Technician confirms device functionsTechnician confirms device functions– Signals run-diagnostics eventSignals run-diagnostics event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”

3.3. Technician places and fastens device on wearerTechnician places and fastens device on wearer4.4. Wearer confirms device is comfortableWearer confirms device is comfortable5.5. Technician starts data acquisitionTechnician starts data acquisition

– Signals acquisition-start eventSignals acquisition-start event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”

Page 16: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1616

Use CasesUse CasesSystem Collects DataSystem Collects Data

1.1. System waits for configured durationSystem waits for configured duration2.2. System activates status lightSystem activates status light3.3. Systems periodically reads data from each sensorSystems periodically reads data from each sensor

– Periodicity configured sensor-by-sensorPeriodicity configured sensor-by-sensor4.4. System timestamps and stores each readingSystem timestamps and stores each reading5.5. System continues reading data for configured durationSystem continues reading data for configured duration6.6. System calculates embedded analyticsSystem calculates embedded analytics7.7. System timestamps and stores each calculated valueSystem timestamps and stores each calculated value8.8. System deactivates status lightSystem deactivates status light9.9. Above sequence repeatsAbove sequence repeats

Page 17: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1717

Use CasesUse CasesWearer Confirms Device is WorkingWearer Confirms Device is Working

1.1. Wearer signals device-check eventWearer signals device-check event– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”

2.2. Wearer observes status light to confirm Wearer observes status light to confirm device functiondevice function

Page 18: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1818

Use CasesUse CasesWearer Restarts Data CollectionWearer Restarts Data Collection

1.1. Wearer places and fastens device on selfWearer places and fastens device on self2.2. Wearer signals acquisition-start eventWearer signals acquisition-start event

– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”

Page 19: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 1919

Use CasesUse CasesTechnician Off-Loads Data from DeviceTechnician Off-Loads Data from Device

1.1. Technician connects device to Technician connects device to storage systemstorage system2.2. Technician signals download-initiation eventTechnician signals download-initiation event

– Use case “Wearer Signals Device to Log Event”Use case “Wearer Signals Device to Log Event”

3.3. System transforms data into transmission format and System transforms data into transmission format and transfers transformed data to file, while manipulating transfers transformed data to file, while manipulating status light to signal transfer progressingstatus light to signal transfer progressing

4.4. System signals completion of transfer with status lightSystem signals completion of transfer with status lightPost-condition:Post-condition:

• Off-loaded data is in a state in which it can be used by external Off-loaded data is in a state in which it can be used by external systemssystems

Page 20: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2020

AlgorithmsAlgorithms

Calculation of pressure waveCalculation of pressure wave Waveform peakWaveform peak Waveform troughWaveform trough Heart rateHeart rate Systolic blood pressureSystolic blood pressure Diastolic blood pressureDiastolic blood pressure

Page 21: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2121

Functional RequirementsFunctional Requirements Downloaded DataDownloaded Data

– ::=::= HeadHead

– Device IDDevice ID– ( Absolute base time )( Absolute base time )– Timestamp of download initiationTimestamp of download initiation

BodyBody– { Acquired/calculated Item }*{ Acquired/calculated Item }*

• Sensor ID/Data Source IDSensor ID/Data Source ID• Timestamp of acquisition/calculationTimestamp of acquisition/calculation• Information typeInformation type• ValueValue

TailTail– Timestamp of download completionTimestamp of download completion– End of data markerEnd of data marker

– If timestamps are relativeIf timestamps are relative then download must include absolute base timethen download must include absolute base time

Page 22: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2222

Functional RequirementsFunctional Requirements Acquired/calculated Acquired/calculated

information typeinformation type– Acquisition control eventAcquisition control event

Start deviceStart device Stop deviceStop device Start acquisitionStart acquisition Stop acquisitionStop acquisition Run diagnosticsRun diagnostics Test acquisitionTest acquisition

– Wearer eventWearer event– Acquired continuous valueAcquired continuous value

mVmV– Acquired discrete valueAcquired discrete value

On/off, down/up, yes/noOn/off, down/up, yes/no

Acquired/calculated Acquired/calculated information typeinformation type– Calculated valuesCalculated values

Pulse (heart rate)Pulse (heart rate)– Units: beats per minuteUnits: beats per minute– Range: 30–200 bpmRange: 30–200 bpm– Accuracy: Accuracy: 5%5%

Systolic blood pressureSystolic blood pressure– Units: mmHgUnits: mmHg– Range: 60–280 mmHgRange: 60–280 mmHg– Accuracy: Accuracy: 3 mmHg3 mmHg

Diastolic blood pressureDiastolic blood pressure– Units: mmHgUnits: mmHg– Range: 40–160 mmHgRange: 40–160 mmHg– Accuracy: Accuracy: 3 mmHg3 mmHg

Page 23: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2323

Major Nonfunctional RequirementsMajor Nonfunctional Requirements InterfacesInterfaces

– OutgoingOutgoing Downloaded dataDownloaded data

– Free and open formatFree and open format– Formal and concise formatFormal and concise format– Human legibleHuman legible– Presentable & workable as plain text file (e.g., editable with text editor)Presentable & workable as plain text file (e.g., editable with text editor)– Widely used format (e.g., industry standard)Widely used format (e.g., industry standard)– Primary options: XML, HL7Primary options: XML, HL7

• However, must understand impact of tagging the dataHowever, must understand impact of tagging the data– Physical ConnectorsPhysical Connectors

Device downloads data via a standard connectorDevice downloads data via a standard connector– Primary options: Secure Digital, USBPrimary options: Secure Digital, USB– Excluded option: RS232Excluded option: RS232

Physical ConstraintsPhysical Constraints– Wearer wears or carries device during operationWearer wears or carries device during operation

Page 24: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2424

Major Nonfunctional RequirementsMajor Nonfunctional Requirements Legal RequirementsLegal Requirements

– Licenses of created works are attributable to the authorsLicenses of created works are attributable to the authors– Free and open sourceFree and open source

Rationale — seeRationale — seehttp://www.phoenix.http://www.phoenix.tctc--ieeeieee.org/000_Background/Phoenix_.org/000_Background/Phoenix_OpenSourceOpenSource..htmhtm

– SoftwareSoftware All software created by the project is free and openAll software created by the project is free and open

– As defined by the Open Source InitiativeAs defined by the Open Source Initiative– http://www.http://www.opensourceopensource.org/docs/definition..org/docs/definition.phpphp

(version 1.9, 2006-07-24)(version 1.9, 2006-07-24) All software incorporated from third parties into the productAll software incorporated from third parties into the product

– Is freeIs free– May be freely redistributedMay be freely redistributed– May be bundled with free and open source software without impinging May be bundled with free and open source software without impinging

on rights of distribution under the open source definitionon rights of distribution under the open source definition

Page 25: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2525

Major Nonfunctional RequirementsMajor Nonfunctional Requirements Legal RequirementsLegal Requirements

– HardwareHardware All hardware designs shall be free — Free Hardware DesignAll hardware designs shall be free — Free Hardware Design

– Design can be freely copied, distributed, modified, and manufacturedDesign can be freely copied, distributed, modified, and manufactured– Does not imply:Does not imply:

• that the design cannot also be sold, orthat the design cannot also be sold, or• that any hardware implementation of the design will be free of costthat any hardware implementation of the design will be free of cost

– Ref: Open CollectorRef: Open Collector• http://www.http://www.opencollectoropencollector.org/.org/WhyfreeWhyfree/definitions.html/definitions.html

All hardware designs shall be open — Open Source HardwareAll hardware designs shall be open — Open Source Hardware– The interface to the hardware must be explicitly made publicThe interface to the hardware must be explicitly made public

• so the hardware can be used freelyso the hardware can be used freely– The design of the hardware must be made publicThe design of the hardware must be made public

• so that others can implement it and learn from itso that others can implement it and learn from it– The tools used to create the design should be freeThe tools used to create the design should be free

• so that others can develop and improve the designso that others can develop and improve the design– Ref: Open CollectorRef: Open Collector

• http://www.http://www.opencollectoropencollector.org/.org/WhyfreeWhyfree/open_hardware.html/open_hardware.html

Page 26: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2626

Major Nonfunctional RequirementsMajor Nonfunctional Requirements

Safety RequirementsSafety Requirements– Electro-Magnetic InterferenceElectro-Magnetic Interference

Device cannot electrically interfere with other electronic devicesDevice cannot electrically interfere with other electronic devices Ref: Ref: FCC Part 68FCC Part 68 For prototype, EMI resistance need be sufficient only to assure For prototype, EMI resistance need be sufficient only to assure

accurate readingsaccurate readings

Page 27: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2727

AppendixAppendixUnresolved IssuesUnresolved Issues

[Bob S] What are the frequency and [Bob S] What are the frequency and resolution requirements for:resolution requirements for:– HR?HR?– DBP?DBP?– SBP?SBP?

[Dick S] Background about power [Dick S] Background about power management circuitsmanagement circuits

[?] Interpretation of FCC Part 68 (EMI)[?] Interpretation of FCC Part 68 (EMI)

Page 28: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2828

AppendixAppendixDesign Direction DetailsDesign Direction Details

Analyze software architecture optionsAnalyze software architecture options– Round-robinRound-robin– Round-robin with interruptsRound-robin with interrupts– Function queue schedulingFunction queue scheduling– Real-time operating systemReal-time operating system

Analyze algorithmsAnalyze algorithms– Calculation of pressure wave (e.g., Chen method)Calculation of pressure wave (e.g., Chen method)– Waveform peakWaveform peak– Waveform troughWaveform trough– Heart rateHeart rate– Systolic blood pressureSystolic blood pressure– Diastolic blood pressureDiastolic blood pressure

Page 29: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 2929

AppendixAppendixDesign Direction DetailsDesign Direction Details

Analyze software interface standardsAnalyze software interface standards– XML vs HL7 vs otherXML vs HL7 vs other

Analyze hardware connector standardsAnalyze hardware connector standards– USB vs Secure DigitalUSB vs Secure Digital

Define diagnosticsDefine diagnostics– Based on designBased on design

Select licenses (may affirm current direction)Select licenses (may affirm current direction)

Page 30: 8 March 2009 1 Data Acquisition Prototype: Project & System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2009 Christopher J. Adams

8 March 20098 March 2009 3030

Design Direction DetailsDesign Direction DetailsCalculation of Pressure WaveCalculation of Pressure Wave

Chen et. al, US Patent No. 6,599,251Chen et. al, US Patent No. 6,599,251– Arterial pulse delay proportional to blood pressureArterial pulse delay proportional to blood pressure

P = a + b ln(T)P = a + b ln(T)– T = Time delay(milliseconds)T = Time delay(milliseconds)– a,b = constants depending ona,b = constants depending on

• nature of the subjectnature of the subject• signal detecting devicesignal detecting device

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

(Richard E. Klabunde, Ph.D, “Cardiovascular Physiology Concepts”, http://www.cvphysiology.com)