1. 11 May 2008 1 System Requirements Phoenix Ambulatory Blood Pressure Monitoring System © 2008 Christopher J. Adams Copying and distribution of this document is permitted in any medium, provided this notice is preserved

2. 11 May 20082 Table of Contents I. Mission II. Scope III. Stakeholders IV. Goals & Goal Conflicts V. Dictionary VI. Scenarios, Stories, Use Cases & Exceptions VII. Requirements VIII. Justifications IX. Assumptions X. Agreed Priorities XI. Acceptance Criteria XII. Parking Lot

3. 11 May 20083 Mission l Develop an ambulatory blood pressure monitor –Inexpensive –Unobtrusive –Easy to use –Collects a week of blood pressure measurements l Develop a means for chronobiological analysis of the collected blood pressure measurements I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

4. 11 May 20084 Mission l Be a learning community –IEEE study group –Open source l Deliver the monitor and analytic framework to the Halberg Chronobiology Center –For long term use on massive scale to l Obtain measures of health l Encourage the development of techniques for –Diagnosis –Prevention –Treatment I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

5. 11 May 20085 Scope I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

6. 11 May 20086 Scope l Monitor measures the Wearer l Wearer records observations in the Diary l Administrator & Physiologist use Data Analysis Software to assess the data collected by the Device l Diary influences the interpretation of the data l Wearer optionally tracks results in a Personal Health Record System l Clinical settings  data stored in Medical Record System l Wearer de-identified to assure privacy  Person Identification System

7. 11 May 20087 I. MissionII. Scope III. Stakeholders IV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria Stakeholders http://www.phoenix.tc- ieee.org/014_Systems_Architecture_and_E ngineering/all-in-one.html#requirements

8. 11 May 20088 Goals & Goal Conflicts l Make a monitor that is –Inexpensive –Unobtrusive –Easy to use –Collects a week of blood pressure measurements I. MissionII. ScopeIII. Stakeholders IV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

9. 11 May 20089 Goals & Goal Conflicts l Inexpensive –Price not a barrier to use –Less expensive than blood pressure cuff –Less expensive than wrist watch l < US$50 –Less expensive than “two bushels of yams” l Third-world friendly l < US$10 I. MissionII. ScopeIII. Stakeholders IV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

10. 11 May 200810 Goals & Goal Conflicts l Unobtrusive –When wearing monitor, patient can l Forget about, be unaware of device –No more encumbering than l Wrist watch l Band-aid™ l Piece of jewelry –Usable wherever the patient is l At home l At work when allowed l Not only at hospital, clinic or doctor's office I. MissionII. ScopeIII. Stakeholders IV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

11. 11 May 200811 Goals & Goal Conflicts l Easy to use –Easier to use than current: l Blood pressure cuffs l Home BP monitors –Patient can: l Ignore device l Determine that device is functioning normally l Observe a blood pressure and heart rate measurement –Device l Is automatic –measurements taken regardless of patient behavior l Allows manually initiated measurements I. MissionII. ScopeIII. Stakeholders IV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

12. 11 May 200812 Goals & Goal Conflicts –Must measure l Systolic and diastolic blood pressure l Heart rate –At least as accurate as current: l Blood pressure cuffs l Home blood pressure monitors I. MissionII. ScopeIII. Stakeholders IV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria –Would also like to measure l Physical activity –To determine if vigorous body movement, such as physical exercise, influenced the blood pressure measurement l Blood flow –Records measurements l at least every half hour l for at least 7 days l Collects a week of blood pressure measurements

13. 11 May 200813 Goals & Goal Conflicts l The Halberg Chronobiology Center wants the monitor –For long term use on massive scale –To obtain measures of health –To encourage the development of diagnostic, prevention and treatment techniques I. MissionII. ScopeIII. Stakeholders IV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

14. 11 May 200814 Dictionary l Wearable –Suitable for wear or able to be worn on the body l Activity of daily living (ADL) –the things a person normally does in daily living including any daily activity performed for self-care (such as feeding, bathing, dressing, grooming), work, homemaking, and leisure –health professionals routinely refer to the ability or inability to perform ADLs as a measurement of the functional status of a person –See http://en.wikipedia.org/wiki/Activity_of_daily_living I. MissionII. ScopeIII. StakeholdersIV. Goals / Conflicts V. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

15. 11 May 200815 Scenarios, Stories, Use Cases & Exceptions See Other Deck for Specifics about the Scenarios 1. Home-based self care 2. Internet-based individual health surveillance 3. Clinical care 4. Self-care followed by clinical care 5. Public healthcare 6. Research 7. Education 8. Sports training 9. Emergency medical service 10. Combat lifesaving

16. 11 May 200816 Requirements 1. Value Requirements 2. Functional Requirements 3. Quality Requirements I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

17. 11 May 200817 Value Requirements l Intellectual property essentially free l Device manufacturable for $10 l Computing hardware –Readily available –Essentially free l Free software licensing I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

18. 11 May 200818 Functional Requirements l Information model l Behaviour requirements l Algorithms I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

19. 11 May 200819 Quality Requirements l Biocompatibility l Environment requirements l Human interface look-and-feel l Operational requirements l Performance (efficiency) requirements l Privacy l Security (integrity) l Safety requirements l Required attributes l Training requirements I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

20. 11 May 200820 Quality Attributes l Functionality –Reliability –Survivability –Usability –Interoperability I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria l Change concerns –Maintainability –Expandability l Adaptability l Scalability –Flexibility –Portability –Reusability l Managerial concerns –Designability –Verifiability –Manageability

21. 11 May 200821 Quality Requirements l Expandability –Analysis framework must be adaptable to chronobiology scenarios other than blood pressure l Interoperability –A 3rd party must be able to analyze the data received from the device, say for diagnosis I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

22. 11 May 200822 Quality Requirements l Wearability –Device is wearable during normal activities of daily living for a continuous period of up to 7 days l No rash, no “other” effects l Longer periods eventually foreseen but not required –The record for a cuff-based device is 20 years, though not continuously l Need definitions –Wearable –Activity of daily living I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

23. 11 May 200823 Component Model Data Analysis Software Subsystem l Analysis Workstation –Handles data for a single wearer l Reference Data Workstation used by Chronobiology Center –Handles data for whole populations l Analysis Workstation relies on model parameters from Reference Data Workstation

24. 11 May 200824 Sensors l Phenomenon –Blood pressure –Heart rate –Blood flow –Physical activity l Low cost l Nonintrusive l Performance: beat to beat BodyData AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

25. 11 May 200825 User-Noted Events l Indicates the time at which something interesting happened l Provides integration with diary BodyData AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

26. 11 May 200826 Time l An issue that covers several layers l Precision = +- 5 minutes l Time zones –Problem -- how to know time-zone changed l Measurements of one device must be comparable to measurements of another device –Impacts clock sychronization Body Signal Acquisition MeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

27. 11 May 200827 Signal Acquisition l Digital signal processing (DSP) –Collect signal data from sensors –Collect user-noted events l Flexible framework for sensor configuration that varies by –Sensor technology –Biophysics –Target measurements l Capacity –7 days of data –30 minutes between measurements Body Signal Acquisition MeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management l Support variable sampling –Over 24 hour period –Span always starts at midnight l Support complex signal-to- measurement conversion –One sensor may produce multiple measurements –One measurement may require multiple sensors –One measurement may require multiple sensor readings l e.g., multiple heart beats

28. 11 May 200828 Data Transport l Communications with device l Framework for multiple transports –RTF, Bluetooth, serial, USB l Open protocol l Integrity assured l Source authenticated BodySignal AcquisitionMeasurement Data Transport Time Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

29. 11 May 200829 Measurement More Digital Signal Processing l Flexible framework for sensor configuration that varies by –Sensor technology –Biophysics –Target measurements l Convert signals/events to measurements –One sensor may produce multiple measurements –One measurement may require multiple sensors –One measurement may require multiple sensor readings l e.g., multiple heart beats l Subject to calibration l Measurement “goodness” –Accuracy (calibration) –Noise (dispersion) l “Was threshold of sensor exceeded? l Stamp each measurement with: –Time l Time-zone aware –Trustworthiness or “goodness” l Extent to which the measure reflects reality l Analysis Patterns –Observations and Measurements (Fowler) BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

30. 11 May 200830 Acquired Data Alarms l Framework –Assess measurement against some criteria –Tag measurement – other subsystems –Alert other subsystems l To alert user  User-interaction subsystem –Alarming deactivatable l Example, to avoid audible alarms when collecting data from sleeping wearer –Able to incorporate 3 rd party alarm subsystem BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management l Simple alarm subsystem –Compare measurement to limit l Limit may be user-specific –Respond to limit violation l Categorize violation –Caution –Warning –Alarm l Alert user –Beep or vibration

31. 11 May 200831 Time Series l Time Series –[concept] a sequence of data points l measured typically at successive times l spaced at (often uniform) time intervals l Each series encompasses one type of observation l Acquired Series –[concept] Time Series corresponding to data uploaded l From a device to an analysis workstation l During a single connection session BodySignal AcquisitionMeasurementData Transport Time Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

32. 11 May 200832 Time Series l Need –Handle sequences of data independently of capacity of data acquisition device –Current requirement = 7 days of data –Longer cycles are in play l E.g., circaseptan cycles in tumor cell growth BodySignal AcquisitionMeasurementData Transport Time Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

33. 11 May 200833 Time Series l User can align overlapping series –Duplicate data items, uploaded multiple times l User can link series into super-series l User can split series into sub-series l System analyzes any data sequence –Series –Super-series –Sub-series BodySignal AcquisitionMeasurementData Transport Time Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

34. 11 May 200834 Individual Analysis l SBP | DBP | HR | Blood flow –MESOR –Circadian amplitude –Circadian acrophase –24-hour cosine curve by least squares (cosinor analysis) l Special sampling period requirements –Marking of l Overswing (circadian ampl. > upper limit of 90% of reference set) l Underswing (circadian ampl. < lower limit of 90% of reference set) l Dipping? l SBP | DBP –Hyperbaric index l Arterial compliance (future?) BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

35. 11 May 200835 Population Analysis l Group sessions into reference sets l Categorize sessions –Age & gender –Dynamically determined attributes l Determine statistical limits of set –10% / 90% BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

36. 11 May 200836 Tool l Framework for integration l Between analysis worksites/tools BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

37. 11 May 200837 Plotting / Charting Data Presentation l Types of plots –Scatterplots –Bar charts l Histograms –Line charts –Box plots –Tables l Multilayered –E.g., best-fit line over scatterplot l Varying resolution –Display types l Computer display l Paper –Peaks / valleys never clipped l Not same as clipping when threshold of sensor exceeded l Annotations –Programmatic l From analysis algorithms l From data acquisition –Sensor threshold exceeded –Manual l From user BodySignal AcquisitionMeasurementData TransportTime Series AnalysisTool Plot / Chart ReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

38. 11 May 200838 Reporting l Form-like reports l Flexible l Incorporate –Charts & graphs –Tables –Free-form text l Reports saved and stored Needs elaboration BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

39. 11 May 200839 Session l Encapsulates each user experience Needs elaboration BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

40. 11 May 200840 Desktop Integration l Functions assembled into application l Graphical user interface l Printing BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop Integration Person IdentityHealth RecordNetworkingChange Management

41. 11 May 200841 Person Identity Privacy l Goals –Unburden Phoenix of privacy issues –Relegate the burden of privacy to caregivers –Minimize the constraints posed by Phoenix on a caregiver’s process l Issue –“Who has seen my stuff?” BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop Integration Person Identity Health RecordNetworkingChange Management

42. 11 May 200842 Person Identity Privacy l Group data by session l Identify session by session key l Primarily identify collected data by session key l Make the session key available to external systems l Trace each session to the device employed in the session l Manage person (patient) identity externally l Within the system, keep all data anonymous l Include anonymous fields in reports/displays Anonymous fields are intended for person identity but can be repurposed l Anonymous fields may be ignored l Assign labels and values to anonymous fields from an external source BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop Integration Person Identity Health RecordNetworkingChange Management

43. 11 May 200843 Clinical Health Record l Integration with clinical information systems –Clinical Care Support System (CCSS)  Phoenix –Patient Administration Systems (PAS) –Electronic Practice Management (EPM) systems –Laboratory Information Systems (LIS) –Dietary, Pharmacy and Billing systems –Electronic Medical Record (EMR) systems –Electronic Health Record (EHR) systems l HL7 — electronic health record interchange standards l Laboratory test standards –Assume chronomedical analysis conducted as laboratory procedure BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson Identity Health Record NetworkingChange Management

44. 11 May 200844 Personal Health Record l Integration framework l Future BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson Identity Health Record NetworkingChange Management

45. 11 May 200845 Networking l Web sites l Multisite integration l Community l Issue –Impacts of informed consent l Cf. –Larry Beatty’s work –Physionet BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworkingChange Management

46. 11 May 200846 Change Management l Usage tracking –Who used what? Needs elaboration BodySignal AcquisitionMeasurementData TransportTime Series AnalysisToolPlot / ChartReportingSession Desktop IntegrationPerson IdentityHealth RecordNetworking Change Management

47. 11 May 200847 Justifications l Measuring blood pressure for 7 days –Cornélissen G, Delmore P, Halberg F. Why 7- Day Blood Pressure Monitoring? Healthwatch 3, Halberg Chronobiology Center, 2004. l http://www.phoenix.tc- ieee.org/0001_Bibliography/HWatch3.pdf; 2.2 MB pdf http://www.phoenix.tc- ieee.org/0001_Bibliography/HWatch3.pdf http://www.phoenix.tc- ieee.org/0001_Bibliography/HWatch3.pdf I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

48. 11 May 200848 Assumptions I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

49. 11 May 200849 Priorities I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

50. 11 May 200850 Acceptance Criteria I. MissionII. ScopeIII. StakeholdersIV. Goals / ConflictsV. Dictionary VI. ScenariosVII. RequirementsVIII. JustificationsIX. AssumptionsX. Priorities XI. Acceptance Criteria

51. 11 May 200851 PARKING LOT l Standards concerning interface between body and devices on the body (ref. US Pharmacopeia §9.7)