Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

[ADD CONTENT FROM XLS / WORK PROPOSALS FOR YHCR]

Problem statement

It is currently difficult for general practitioners [AND OTHER CLINICIANS?] clinicians to access up-to-date, accurate and regularly recorded observations. This is because if it can be difficult (and not desirable) to make these observations within primary care settings (either due to patient reluctance/availability, pandemic limitations or other factors). This means that:

  • Clinical decision making is hampered by not being able to see trend data for a given observation metric (i.e. there are not enough data points across a period of time to make an informed decision);

  • Observations captured within a clinical setting may not be as representative as those that are captured in a home setting (due to patient nervousness/anxiety, other situational factors - e.g. patient may have had to exert themselves prior to observation).

  • Regular measurements throughout the day - trend data

  • Home observations more representative compared to those taken in a clinical setting

Proposed Solution

Provide a user interface in the Helm Person Held Record that allows patient/citizen users to record information relating to observation measurements they have captured in a home setting.

Observed measurements to include:

  • Blood pressure

  • Peak flow meter measurements

...

Weight

Context of use

Settings and roles

...

  • Weight

  • Pulse

  • Peripheral Oxygen Saturation

It should be possible to record the following for each observation:

  • Unit

  • Value of measurement

  • Date and time (of observation measurement)

  • Notes

In addition, the system should automatically record the date recorded and patient (as subject and performer)

Summary Flow

To do - Visualisation of data from capture to presentation.  [image links inline] 

  1. Patient capture of an observation using tools in the home.

  2. Patient entry of observation data into Helm.

  3. FHIR mapping in SoS

  4. UI presentation in Helm with historical data.

  5. UI presentation in YHCR Care Portal (based on Helm panel above) - with additional functionality for clinician views

  6. [CONFIRM] Clinician roles and workflows

...

Systems Development

...

 Develop interface (based on both technical and functional requirements) to display the answers to WMTM questions in Helm (Person Held Record) that have been authored by professionals in other settings and subsequently shared via YHCR / SoS.

...

Helm

  • User interface to allow patient capture of observation measurements (measure, unit, value, date, subject, notes).

  • User interface to display historical measurements (including metadata).

YHCR Care Portal

  • Develop interface to display patient-recorded observations shared via YHCR / SoS.  This will be based on work completed in Helm as it shares the same architecture.

  • Support the development of the user interface within the Leeds Care Record (LCR) in order to present WMTM answers observations derived from Helm via YHCR / SoS.

User journeys

[CONSENT POLICY DEFINITIONS]- LCC AS DATA CONTROLLER FOR HELM

Diagram

Theme

Questionnaire SharingObservations

Initiative

HOB001 - Patient recorded observations from Helm to System of Systems

User Journey Summary

Patient captures and records personal observations in Helm.

Information provider roles

Patient, citizen

Information consumer roles

GP, practice nurse, care coordinator, secondary care clinician

Supporting Work

Alignments / Support

FHIR profiles and resource mapping

Observation data will conform to the following FHIR profile:

https://www.hl7.org/fhir/STU3/observation.html

Observations are a central element in healthcare, used to support diagnosis, monitor progress, determine baselines and patterns and even capture demographic characteristics. Most observations are simple name/value pair assertions with some metadata, but some observations group other observations together logically, or even are multi-component observations. Note that the DiagnosticReport resource provides a clinical or workflow context for a set of observations and the Observation resource is referenced by DiagnosticReport to represent lab, imaging, and other clinical and diagnostic data to form a complete report.

Uses for the Observation resource include:

Mandatory and Must Support Data Elements

The following data-elements are mandatory (i.e data MUST be present) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements.

Each Questionnaire Observation must have:

  • a

...

a status

...

an intent

...

a category code of “”

...

a patient

Examples

  • Example 1

  • Example 2

  • Example 3

[FHIR DIAGRAM] 

  • patient (as subject)

  • a date and time

  • a unit

  • a value

Each Observation may have:

  • a note

UI design guidance 

To do:

...

Wireframes of web and mobile views

...

To be elaborated during construction sprints:

  • UI control elements - Getting input, navigation, data display / content structuring

  • Advanced UI elements - History, provenance (multi-data point rendering), summary/detail, graphing UI

Clinical terminology and coding

...

Supporting info

...