(5) Capturing Health-Related Observations

• Information exchange between medical professionals
  • existing standards for information exchange between professionals
  • existing services for storing and managing health records
• How to get health-related information from patients
  • current scenarios look mostly at information sharing between professionals
  • patient data (observations and notes) are not part of the current landscape
• Developing a model and an application for patient-generated data
  • Observations of Daily Living (ODL) can be very useful for doctors
  • the models around creation, sharing, delegation, and exchange have to be flexible

(6) Personal Health Information

(7) Monitoring Body Weight

(9) Scenarios

• Activities where the application is useful
  • elder activities (CMU Project [http://www.projecthealthdesign.org/projects/current_projects/cmu])
  • asthma and depression or anxiety (BreathEasy [http://www.projecthealthdesign.org/projects/current_projects/breatheasy])
  • youth with obesity and depression (iN Touch [http://www.projecthealthdesign.org/projects/current_projects/iN_Touch])
  • tracking chronic disease (Crohnology.MD [http://www.projecthealthdesign.org/projects/current_projects/crohnology])
  • monitoring low birth weight infants (FitBaby [http://www.projecthealthdesign.org/projects/current_projects/fitbaby])
• Requirements derived from those use cases
  • various activities require different data to be captured
  • data should be captured in a structured form for easier use/analysis
  • data input must be simple and easy
  • augmenting observations should be possible (using connected devices)

(10) Acquiring User Input

• Different scenarios need different data input
  • some template mechanism is required for acquiring structured data
  • templates could be used to generate form-based data entry
  • part of the templating mechanism should be external data
• Pulling in external data can be done in various ways
  • custom-built based on individual mechanisms per data provider
  • based on generic Web standards such as feeds (and some extraction mechanism)
  • based on specific standards for sharing health data (e.g., Continua [http://www.continuaalliance.org/])

(11) Delegating User Input

• ODLs may be entered by caretakers or parents
  • identification/authentication must allow delegation
  • ownership and access right model has to be flexible

(12) UI Design Issues

• Structured data entry should be encouraged
  • use interface elements that make structured data entry easy
  • use interfaces that are specific (templates)
  • entry helpers (yesterday's ODL) may make data entry easier
• Immediate feedback for providing incentives
  • show graphs/trends of values after an ODL has been added
  • interface/interaction should be

(14) Open and Extensible Model

• ODL reports should be usable for various scenarios
• Openness means that application can add specific data
  • openness creates the problem of how to understand added data
  • various additions can have overlapping meaning
• Extensibility means that the model might be extended later
  • in the best case, old implementations can deal with new data
  • in the usual case, new implementations can deal with old data

(15) Web-Based for Cross-Platform

• Data entry should be possible across platforms
  • it may be more convenient on a regular computer
  • mobile data entry is necessary to ensure ODL coverage
• Text and simple data entry can be done Web-based
  • some mobile platforms may even support speech-to-text soon
  • with templates/types data entry can be made easier
• More advanced forms of data entry are not yet supported
  • Capture API [http://www.w3.org/TR/capture-api/] just published and not yet implemented
  • no ability to connect to Bluetooth-enabled devices

(16) Resource Types

• Users are needed for identification and authentication
• ODL reports are needed for capturing records
• ODL templates should provide some outline for ODL reports
• Services may be used to represent ODL consumers

(17) Resource Relationships

• Users may have a variety of (possible authorizing) relationships
  • family relationships may allow access to ODL records
  • professional relationships (e.g., caretakers)
  • temporary relationships (delegating data entry for a period of time)
• ODLs are created by a user and for a user
• ODLs are created according to a template
  • templates define/guide what is contained in an ODL
  • templates can also be used for validation of ODLs
  • templates are provided by services and used by users
• ODLs are accessible by a service (which might have modification rights)
  • can services delegate access rights?
  • can access rights be selective (only parts of the ODL)?

(18) Resource Interactions

• Users and user relationships required for user management
  • creating new users is the sign up process
  • modifying relationships permanently (family) or temporarily
• Getting templates as the starting point for creating ODLs
  • find the service providing the template and select it
• Creating ODLs based on a template
  • only accept the ODL if it validates against the template
  • how to deal with existing ODLs when a template changes?
• Access a stream of ODLs as published by users
  • services need a way how to get new ODLs (push or pull)

(20) Weather Application

(21) Weather.gov Web Pages