Page tree
Skip to end of metadata
Go to start of metadata

Track description:
Track Zoom: 339 768 9120
Connectathon Webinar (general room):

Track Zulip:

Submitting WG:  Orders and Observations/CIMI/Patient Care

Project:  Vital Signs FHIR IG Testing

Implementer Group: Logica, Intermountain, AMA, Penrad, Mitre

Justification and Objectives

What’s the purpose of hosting this connectathon track? What do you hope to achieve?  We are hosting this track to test the items in the Vital Signs FHIR IG prior to ballot

This track will use what version of FHIR.  FHIR R4

Clinical input requested (if any)

Does your track have a need for input from the clinical community? If so, what are the needs? No, we have lots of clinical input from AMA, and Intermountain Healthcare

Related tracks

(used to help guide seating arrangements and possibly drive track consolidation)

Proposed Track Lead

Name: Corey Smith, email: Track leads must be registered users on

Expected participants

Who do you expect to be present? Corey Smith, Matt Menning, Nathan Clairmont, Nathan Davis, Susan Matney, Laura Heermann, Monique van Berkum....  How many do you expect to attend? 10

Track Orientation

A webinar will be hosted on April 17, 2020 1300 CT to share further participation information about this track.

System Roles

Describe each type of system that could participate in the track - EHR, Automated blood pressure device, Cloud based data aggregator, Mobile app associated with automated blood pressure device.

Please include information here regarding how much advance preparation will be required if creating a client and/or server.:  Build of the IG for use in development will be done by April 24th.  Less then or equal to three weeks for development.

Role 1 Name


Describe the different scenarios participating systems can engage in during the conenctathon. Each scenario should provide sufficient description that participants can appropriately construct their software in advance to prepare to interoperate during the connectathon.

Use case: SMBP monitoring and transferring results across systems

The patient performs twice-weekly SMBP measurements, and repeats a one-week SMBP monitoring protocol (as described in the AMA IHMI Use Case 1: SMBP document) at the end of the 6-month period to determine a one-week blood pressure average. The patient measures blood pressure and heart rate according to the device and/or mobile application instructions. Results are transferred to a cloud-based application upon successful completion of each measurement. Measurement results are then processed (e.g., confirmation of appropriate wait times before and between measurements, calculation of average systolic and diastolic blood pressure, etc.), after which measurements are transferred to an EHR for storage and retrieval.


3.2.1. Actors Actor



A patient measuring his/her own blood pressure via an automatic blood pressure monitor and mobile application.

Automatic blood pressure monitor

A device that measures the blood pressure and heart rate after being initiated by a user action (e.g., pressing a button on the device or on the corresponding mobile application). The automatic blood pressure monitor is connected to the mobile application via a Bluetooth connection.

Mobile blood pressure application

Software application that interacts with the automatic blood pressure monitor via Bluetooth connection. A patient interacts with the mobile application during initial setup. Automatic blood pressure measurements are transferred via the mobile application to the cloud-based application for processing before being transferred to the patient's EHR.

Cloud-based application

A cloud-based software application that receives and processes SMBP measurements from the mobile application and transmits the results to the patient's EHR.


Electronic health record.

Scenario Step 1 Name



Success Criteria:

Bonus point:


Indicate any test scripts that will be used to help verify system behavior

Security and Privacy Considerations

Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate

  • No labels