1. FHIR® is the registered trademark of HL7 and is used with the permission of HL7. The Flame Design mark is the registered trademark of HL7 and is used with the permission of HL7.
Amsterdam, 15-17 November | @fhir_furore | #fhirdevdays17 | www.fhirdevdays.com
Continua Implementing FHIR
Melanie Yeung, eHealth Innovation @ University Health Network
2. About Me
• Name: Melanie Yeung @melaniesyeung
• Company: eHealth Innovation,
University Health Network @Official_eHI
• Background:
• Trained as a Clinical (Biomedical) Engineer
• Member of PCHAlliance/Continua Health Alliance
• Member of IEEE Personal Health Devices Working Group
• Member of Bluetooth Medical Expert Working Group
• Co-manager of awesome dev team (@ehealthdevs)
3. My Daytime Job
• Research centre in Toronto, Canada
• Affiliated with the University of Toronto
• Unrivaled access to patients, healthcare professionals and
researchers
• 70+ scientists, engineers, project managers, psychologists,
human factors specialists, developers, designers, and students
4. Tutorial Objectives - What can you expect?
• Intro to PCHAlliance, Device
Standards, and Continua Design
Guidelines
• Device Data Upload using FHIR®
Observations
• Consuming Device Data from
Home to Hospital
• Preeclampsia Use Case
5. Personal Connected Health Alliance
• improve efficiencies and reduce cost
• advance prevention over treatment
• promote individual ownership and
control over personal health data,
including the ability to share it with
one’s healthcare provider, caregivers or
social network
• improve communication and data
exchange between patients and
providers
• create new incentives for a movement
towards personal responsibility and
engagement in one’s own health
6. Published annually, PCHAlliance’s Continua Design Guidelines define a
flexible framework for user friendly end-to-end interoperability of
personal connected health devices and systems. Continua certified
products bear the globally recognized Continua logo, which signals
market-readiness for 21st century health data exchange. The
Guidelines are recognized as an international standard by the United
Nations’ International Telecommunication Union (ITU-T) and available
free in six languages.
PCHAlliance’s flagship event, the Connected Health Conference, is
the premier international conference and expo for the exchange of
research, evidence, ideas, innovations and opportunities in
connected health. Formerly the mHealth Summit, and now in its
ninth year, the event features industry-leading keynote
presentations, dynamic programming, poster presentations, an
interactive exhibit floor, and high-value networking sessions.
www.ConnectedHealthConf.org
10. Truly Open Design Guidelines
• Continua guidelines are endorsed by a neutral leader
• International Telecommunication Union (ITU),
the global standards agency of the United Nations
• Anyone can get the Continua guidelines for FREE
• In six languages
• Download via ITU or: www.pchalliance.org/continua-design-guidelines
• Anyone can submit comments
• Via Continua or ITU
• Any party welcome to join PCHAlliance at the level of choice
• Easy market access for vendors, no vendor lock-in for users
• Contribute to new versions
11. Commercial
Ready Platforms
Continua Enabling Software Libraries (CESL)
Continua Test Tool (CTT)
Speed the
adoption
Reference source
code
Testing
Prototypes
Basis for Continua
Test Tool
Creation of
reference devices
for IOP
Existing New
Continua Code and Testing Today and Tomorrow
13. Towards adoption in Europe: Oct 2017 highlights
Denmark: (2012) National health IT strategy
sets out reliance on (Continua); roll out of
national COPD services in 2018.
Norway: (Dec. 2014) MoH announced Continua
standards as the framework for new national
remote health and social care program
Sweden (April 2016) announced open
architecture based on Continua Guidelines
European Commission: (2013) Continua
referenced alongside IHE in European eHealth
Interoperability Framework
Finland: (Oct 2017) MoH launches personal
health record in Dec 2017, expressed interest
in diabetes pilot with Continua in 2018.
eHealth Network: (May 2017) Invited six
governments to present at Malta meeting;
new MWP being prepared, led by SPMS
Austria: (Oct 2017) MoH published technical
framework directive for telemonitoring with
Continua
Catalonia (July 2017) MoH mandates
Continua compliance for glucose meters
to connect with personal health record
Portugal: (Oct 2017) SPMS will test sleep
apnea products for Continua compliance at
Boston Plugfest
15. Personal Health Devices Interface (PHD-IF)
16
Continua Design Guidelines supports
devices that can use :
• an interface based on ISO/IEEE 11073-
20601 (X73-IF)and a supported
transport technology (ZigBee, NFC,
USB and Bluetooth BR/EDR)
• an interface based on a Bluetooth LE
(BLE-IF) as transport, technology and
one or more (application level)
services and profiles defined by
Bluetooth Special Interest Group (SIG).
16. Institute of Electrical and Electronics Engineering
• IEEE-11073 Personal Health Devices
(PHD) Working Group
• Focus on interoperability of personal
health devices for personal use
• Transport agnostic
• Open group, including both industry and
academic participation
• Easy access and low cost to published
standards
17. IEEE 11073- PHD’S FOCUS
Agent (aka. Sensor)
• Exchange Protocol + Device
Specializations
• Domain Information Model (DIM)
• Service Model
• Communication Model
• Device-specific information
• Supported Domains:
• Disease Management
• Health and Fitness
• Aging Independence
Manager (aka. Client)
18. Domain Information Model (DIM)
• Describes the device and physiological data
• Object oriented model
• No requirement to implement in object oriented language
• Generic set of classes created
• Classes define attributes and methods
• Attribute type defined in ASN.1 (language for abstract modeling of
data and interactions)
• Objects are tailored using the attributes
• Attributes may be:
• Mandatory, optional, or conditional
• Static or dynamically changing
20. IEEE 20601: Objects
Sensor
PM-Store Object ‘n’
Agent’s hard disk
*optional*
MDS Object
Device’s bureaucratic and system
information
*must have*
Metric Object ‘k’
Describes a measurement
(e.g. weight, status, waveform)
*optional*
Scanner Object ‘m’
Formats and groups for data
transmission (eventing)
*optional*
22. -00103 Technical Report - Overview
Device Specializations
-10404
Pulse
Oximeter
-10407
Blood
Pressure
-10408
Thermo-
meter
-10415
Weighing
Scale
-10417
Glucose
Meter
-10441
Cardio
-10419
Insulin
Pump
-10425
CGM
-104xx
…
-20601 Optimized Exchange Protocol
Communication Protocols
NFC Bluetooth BR/EDR USB 2.0 ZigBee
OSILayers4-5OSILayers6-7
IEEE Standards and Specializations
NFC PHD class Bluetooth HD profile USB PHD class ZigBee HC class
23. Completed Standards (20 / 29)
• IEEE Std 11073-10404 Dev specialization – Pulse oximeter
• IEEE Std 11073-10406 Dev specialization – Basic ECG
• IEEE Std 11073-10407 Dev specialization – Blood pressure monitor
• IEEE Std 11073-10408 Dev specialization – Thermometer
• IEEE Std 11073-10415 Dev specialization – Weighing scale
• IEEE Std 11073-10417 Dev specialization – Glucose meter + Revision +
Revision
• IEEE Std 11073-10418 Dev specialization – INR (blood coagulation) +
Corrigendum
• IEEE Std 11073-10419 Dev specialization – Insulin Pump +Revision
• IEEE Std 11073-10420 Dev specialization – Body composition analyzer
• IEEE Std 11073-10421 Dev specialization – Peak flow
• IEEE Std 11073-10422 Dev specialization – Urine analyzer
• IEEE Std 11073-10424 Dev specialization – SABTE +Corrigendum
• IEEE Std 11073-10425 Dev specialization – CGM +Revision
• IEEE Std 11073-10427 Dev specialization – Power Status Monitor(PSM)
• IEEE Std 11073-10441 Dev specialization – Cardiovascular + Revision
• IEEE Std 11073-10442 Dev specialization – Strength fitness equip
• IEEE Std 11073-10471 Dev specialization – Activity hub
• IEEE Std 11073-10472 Dev specialization – Medication monitor
• IEEE Std 11073-20601 Optimized exchange protocol + Amd + Rev+Cor
• IEEE Std 11073-00103 Personal health device communication -
Overview
24. Projects Underway (12)
• IEEE P11073-10426 Dev specialization – Home Healthcare Environment
Ventilator (New)
• IEEE P11073-20601 Optimized exchange protocol (Revision)
• IEEE P11073-10404 Dev specialization – Pulse Oximeter (Revision)
• IEEE P11073-10407 Dev specialization – Blood Pressure Monitor (Revision)
• IEEE P11073-10408 Dev specialization – Thermometer (Revision)
• IEEE P11073-10415 Dev specialization – Weighing Scale (Revision)
• IEEE P11073-10420 Dev specialization – Body composition analyzer (Revision)
• IEEE P11073-10406a Dev specialization – Basic ECG (Revision)
• IEEE P11073-10471a Dev specialization – AI Living Hub (Revision)
• IEEE P11073-10425 Dev specialization – Continuous Glucose Meter (Revision)
• IEEE P11073-10419 Dev specialization – Glucose Meter (Revision)
• IEEE P11073-10428 Dev specialization – Electronic Stethoscope
26. Bluetooth Special Interest Group (SIG)
• Bluetooth SIG Medical Working Group
• Scope: to improve the user experience
for Bluetooth-enabled medical,
healthcare, and fitness devices
• Industry-focused, closed group
(membership required to develop
standards)
28. Bluetooth Generic Attributes (GATT) Specifications
• GATT profile
• describes a use case, roles, and general behaviors based on the GATT
functionality, enabling extensive innovation while maintaining full
interoperability with other Bluetooth® devices.
• GATT services
• collections of characteristics and relationships to other services that
encapsulate the behavior of part of a device.
33. Continua Device Data to FHIR® server Upload Objectives
• Ensure no loss of information
• Equivalent to what is available via IHE PCD-01 upload
• Represent information using HL7 Defined FHIR® resources
• Support secure, interoperable uploads from Personal Health Gateway
to Health & Fitness Service
• https transport
• OAuth-2 based authorization framework
• Allow consumer choice in PHGs
35. Service-IF
37
Continua Design Guidelines specify
three implementations for
uploading HL7 V2.6 Observations
payloads:
• IHE PCD-01 message packaged in
SOAP and authenticated using
SAML,
• HL7 FHIR Resources via REST and
OAuth, and
• IHE PCD-01 message sent over
HL7 hData Framework and hData
REST transport binding.
36. Service-IF
38
Continua Design Guidelines specify
three implementations for
uploading HL7 V2.6 Observations
payloads:
• IHE PCD-01 message packaged in
SOAP and authenticated using
SAML,
• HL7 FHIR Resources via REST and
OAuth, and
• IHE PCD-01 message sent over
HL7 hData Framework and hData
REST transport binding.
HL7 v.2.6
HL7 v.3.0HL7 FHIR STU3
37. 11073 “MDC” Device Info Model (highly simplified!)
Physical Top-Level Device Info (ID, H/W & S/W versions, battery …)
Medical Device
System (MDS)
Virtual Medical
Device (VMS)
Channel
Metric
Device Subsystem Info (BP, ECG, temp …)
Related Parameter Group Info (ECG Channel #1, #2, #3, …)
Parameter Metadata Info (Datatype independent info, e.g. period)
1..*
1..*
1..*
Numerics /
Enumerations /
Waves
1..1
Parameter Info (Value + datatype-specific elements)
Defined in ISO/IEEE 11073-10201 & 11073-20601
39. 11073 “MDC” PHD Model FHIR Mapping (current)
Medical Device
System (MDS)
Metric
(Abstract)
Numerics /
Enumerations /
Waves
1..*
1..1
Patient
Observation
DeviceComponent
(PHD MDS Profile)
40. Continua Personal Health Device Measurement Upload
• Three FHIR defined resources
1. the Patient Resource,
2. the DeviceComponent Resource,
3. the Observation Resource.
42
Observation (Metric OBXes)
Components: (OBX-facets)
DeviceComponent (PHG)
Patient (PID)
Bundle
DeviceComponent (sensor)
HTTP POST header
41. Patient Resource
• Managing Patient Identity
• PHG must properly reference the patient resource in any observation
resource being uploaded
• In the FHIR protocol this is done by having the PHG provide the Logical ID of
the patient resource to the FHIR server.
• Potential challenges in obtaining the Logical ID of the patient resource
for the PHG
• PHG must know the Logical ID of the Patient Resource, or
• must be able to provide a Patient Designator which will allow the Logical ID to
be located
42. Patient Resource
(Scenario – Logical ID is provided)
• Logical ID is
communicated to the
H&FS party responsible
for configuring the PHG
in the home
environment.
• PHG is configured with
the appropriate Logical
Identification of the
Patient Resource
43. Patient Designator
(Scenario – Logical ID is not provided)
Patient Designator is:
• other information, which identifies the patient
• can represent a wide range of different forms of patient identity, appropriate to different
situations
• contains information about who the assigning authority is, and how the patient is identified
by that assigning authority
• is used to establish the identity of the patient in the uploading of a measurement
• Patient Designator is can be used to generate a FHIR Patient Resource
1) PHG takes the responsibility of specifying the Logical ID of this resource, which must be
unique when used in the FHIR server
2) PHG obtains from HF&S the generated Logical ID by identifying the Patient Resource using
the Patient Designator
44. DeviceComponent Resource
• Characteristics, operational status and capabilities for a component of a
healthcare device. Used to describe PHG or sensor attributes such as:
• System ID
• Device Type
• Production specification
• Regulation certification information
• Time synchronization/capabilities
• The Logical ID of the DeviceComponent Resource shall be unique on the H&F and
should be set to IEEE systemId-Transport Address or if not available, then should
be set to UUID
46
45. Observation Resource
• mapping of [ISO/IEEE 11073-20601] to FHIR is primarily through the
IEEE nomenclature codes
• codes describe what the measurement is, the units, and can be the
measurement itself.
• mapped to the appropriate FHIR CodeableConcept elements
48. Use Case Overview
• Annie is a 31 y.o. female, 1st pregnancy
• Asymptomatic hypertension (DBP > 90-99mmHg SBP > 140-
149mmHg) and proteinuria (conc. 30mg/dl >1+ dipstick) > 20wk
gestation
• She delivered a healthy 7lbs 5 oz baby boy 1/29/2017 at 19:50
following induction at 37 + 6 weeks.
• Infant was delivered vaginally without complications, APGARS 8/9.
Infant and mother transitioned normally to the postpartum ward and
were discharged to home on Hospital Day 2.
50
49. Initial diagnosis
• Annie first presented at wk35 prenatal visit with +3
proteinuria dipstick
• Follow-up lab results urinalysis showed Protein:creatinine
863 mg/mmol (norm <30mg/mmol)
• Home blood pressure readings (taken every 6 hours) ranged
from 98-114 / 65-76 mmHg.
• Daily home dipstick shows –ve results
51
50. Home monitoring
• On the fourth day, however, her BP spiked to 142/90.
• This data was analyzed by the CDS system that automatically sent her an SMS
text message reminding her that she was to repeat the measurement every
hour for 3 hours.
• When repeating the measurements, her BPs are still 140-149 / 90-99.
• Following these readings, the CDS concludes that Annie should begin
start taking her blood pressure every 4 hours.
• The system sends an SMS text to Annie and an EMR alert to her provider
notifying them of the recommendation.
• Upon receiving the alert, Annie’s provider logs into the EMR and reviews the
vital signs obtained at home.
52
51. Analysis and Escalation
• Over the next 48 hours, Annie dutifully records her blood pressure.
• Annie’s blood pressures continue to trend up, now ranging between
150-155 / 100-108.
• CDS concludes that Annie needs to be evaluated and stabilized as
an inpatient.
• System sends an SMS text to Annie and a traditional EMR alert to
her provider notifying them of the recommendation.
• Upon receiving the alert, Annie’s provider logs into the EMR,
reviews the home vital signs before arranging for her admission.
53
52. Hospitalization
• Upon admission, Annie is monitored every hour x 2 using a hospital
blood pressure device that also transmits its data to the CDS system.
• The new monitor confirms that Annie’s blood pressure is ranging
between 150-155 / 100-108.
• CDS system alerts her provider, recommending that her therapy be
augmented with oral medication.
• Following this addition to her oral therapy, Annie’s blood pressure
normalizes over the next 48 hours to 100-125 / 65-80 mmHg and she
is subsequently discharged to complete her home remote monitoring.
54
53. Noninvasive Blood Pressure Monitor Device
• Typically two numbers reported
• Systolic pressure: contraction of the
heart
• Diastolic pressure: relaxation of the
heart
• Third number may be available
• Mean arterial pressure
• Units of measurement (mmHg)
• Pulse Rate (/min) *optional
Let’s begin. How many of you have heard of PCHA? Or Continua?
What is this organization?
The Personal Connected Health Alliance (PCHAlliance) aims to make health and wellness an effortless part of daily life. The PCHAlliance, a non-profit organization formed by HIMSS, believes that health is personal and extends beyond healthcare. The PCHAlliance mobilizes a coalition of stakeholders to realize the full potential of personal connected health. PCHAlliance members are a vibrant ecosystem of technology and life sciences industry icons and innovative, early stage companies along with governments, academic institutions, and associations from around the world.
Strives to… improve, advance, promote, create
PCHA does this through two major initiatives: Connected Health Conference and Continua Design guidelines
To support its vision, the PCHAlliance convenes the global personal connected health community at the annual Connected Health Conference, the premier international event for the exchange of research, evidence, ideas, innovations and opportunities in personal connected health.
The PCHAlliance publishes and promotes the global adoption of the Continua Design Guidelines, an open framework for user-friendly, interoperable health data exchange in personal connected health. The Continua Design Guidelines are recognized by the International Telecommunication Union (ITU), an agency of the United Nations, as the international standard for safe, secure, and reliable exchange of data to and from personal health devices
eco-system of open plug-and-play interoperable personal connected health devices and services which are validated in accordance with the Continua certification program.
Personal health devices and gateways in the home connected to services
How do we enable the transfer of data from E2E? Leveraging existing industry standards and providing guidance to secure data through three interfaces. Plug-n-play guaranteed when each of the services are Continua certified
Technical E2E architecture can be described in these 3 interfaces
PHD Interface connecting a Personal Health Device to a PHG capturing sensor data from a patient
Services interface – collecting, aggregating and
Healthcare Information System Interface – combining data with other information
These interfaces and ability to achieve E2E interoperability are described through a series of documents that combined produces the CDG.
not a proprietary platform
Accepted by the International Telecommunication Union, the global standards agency of the United Nations, and can be downloaded for FREE in six languages via ITU or in English via www.continuaalliance.org
and creates new market access
Note on languages is it 6+English? (so 7 total) or 6 including English. Mentioning English seems a bit odd, right?
CESL code base is intended to
Speed the adoption of Continua by assisting members in product development via reference source code
Enable testing of prototypes against CESL reference implementations
Enable the Continua Test Tool by providing a basis on which to build
Enable the creation of reference devices for use in Plugfests and manual test programs
Development, Test & Certification
Continua test tools save time and resources during development
Certified Experts (“CCEs”) available to support development and certification
“Plugfests” allow real world testing in a trusted, constructive environment
Continua CertifiedTM logo
Individual: ensures interoperability
Manufacturers: provides competitive advantage
>100 health devices and services certified
Wins:
Finland (pop 5.5m): MoH interest in diabetes pilot with Continua in 2018
Austria (pop 8.6m): MoH publishes framework directive for telemonitoring
Denmark (pop 5.7m): National COPD rollout expected in early 2018
Catalonia (pop 7.5m): MoH mandated Continua compliance for glucose meters (July 2017)
India (pop 1.3bn): PCHAlliance represented in the standards body BIS - MHD 17.
Opportunities
eHealth Network will roll out new Multiannual Work Plan in 2018
WHO/ITU European mHealth Hub project: PCHAlliance included in several proposals
Digital Health Society process including task force for interoperability
3 interfaces
Devices certified as Continua Compliant can feed data into any other systems that are continua certified
3.2.16 Continua personal health devices interface (PHD-IF): The Continua PHD-IF connects
one or more personal health device (e.g., sensor/actuator) client components to one or more
personal health device (sensor/actuator) service components using transport media such as USB,
BLE, Bluetooth, ZigBee or NFC. Examples of sensor service components include glucose meters,
weighing-scales and heart rate monitors.
3.2.17 Continua services interface: The Continua services interface is an interface between a
personal health gateway (e.g., smart phone, tablet or dedicated hub) and a health and fitness service
(e.g., disease management service, ageing independently service or wellness service). The health
and fitness service could be hosted in the cloud. IP based connectivity is assumed between the
personal health gateway and the health and fitness service and Continua focuses on defining the
behavior of the OSI layers above IP.
3.2.18 Continua healthcare information system interface (HIS-IF): HIS-IF is an interface
between a health and fitness service (e.g., disease management service, ageing independently
service and wellness service) and a healthcare information system (HIS) such as an electronic
medical record (EMR), an electronic health record (EHR) or a pharmacy information system).
For those of you unfamiliar,
IEEE has a number of different working groups devoted to standards, the one we are involved with is specifically for developing standards for Personal Health Device - 11073
Focus on data elements, and stays transport agnostic
Open group/ Open participation
4.2.2 Domain information model
The DIM is a hierarchical model that describes an agent as a set of objects. These objects and their attributes represent the elements that control behavior and report on the status of the agent and data that an agent can communicate to a manager. Communication between the agent and the manager is defined by the application protocol in IEEE Std 11073-20601.
4.2.3 Service model
The service model defines the conceptual mechanisms for the data exchange services. Such services are mapped to messages that are exchanged between the agent and the manager. Protocol messages within the ISO/IEEE 11073 series of standards are defined in ASN.1. The messages defined in IEEE Std 11073-20601 can coexist with messages defined in other standard application profiles defined in the ISO/IEEE 11073 series of standards.
4.2.4 Communication model
In general, the communication model supports the topology of one or more agents communicating over logical point-to-point connections to a single manager. For each logical point-to-point connection, the dynamic system behavior is defined by a connection state machine as specified in IEEE Std 11073-20601.
*Capabilities described are typical of respective devices, however they are not universal rules
Agent has objects to describe its features
Focus on interoperability of personal health devices (PHD) for personal use rather than in-hospital
Transport agnostic
Open group, including both industry and academic participation
Scope: improve the user experience for Bluetooth-enabled medical, healthcare, and fitness devices.
Critical for Bluetooth LE devices (not covered by IEEE-11073 standards)
Industry-focused, closed group (Associate or Promoter membership required)
Pair of specs
profile describes a use case, roles and general behaviors based on the GATT functionality. Services are collections of characteristics and relationships to other services that encapsulate the behavior of part of a device. This also includes hierarchy of services, characteristics and attributes used in the attribute server.
The top level of the hierarchy is a profile. A profile is composed of one or more services necessary to fulfill a use case. A service is composed of characteristics or references to other services. Each characteristic contains a value and may contain optional information about the value. The service and characteristic and the components of the characteristic (i.e., value and descriptors) contain the profile data and are all stored in Attributes on the server.
Descriptors: value
Properties:
Value: opaque structured
IEEE and Bluetooth are two separate standards that target different implementations
IEEE is a application layer protocol
BT are both transport and application layer
Can transcode the BT data into IEEE to make it interoperable before extending it to HL7
3 interfaces
Devices certified as Continua Compliant can feed data into any other systems that are continua certified
3.2.16 Continua personal health devices interface (PHD-IF): The Continua PHD-IF connects
one or more personal health device (e.g., sensor/actuator) client components to one or more
personal health device (sensor/actuator) service components using transport media such as USB,
BLE, Bluetooth, ZigBee or NFC. Examples of sensor service components include glucose meters,
weighing-scales and heart rate monitors.
3.2.17 Continua services interface: The Continua services interface is an interface between a
personal health gateway (e.g., smart phone, tablet or dedicated hub) and a health and fitness service
(e.g., disease management service, ageing independently service or wellness service). The health
and fitness service could be hosted in the cloud. IP based connectivity is assumed between the
personal health gateway and the health and fitness service and Continua focuses on defining the
behavior of the OSI layers above IP.
3.2.18 Continua healthcare information system interface (HIS-IF): HIS-IF is an interface
between a health and fitness service (e.g., disease management service, ageing independently
service and wellness service) and a healthcare information system (HIS) such as an electronic
medical record (EMR), an electronic health record (EHR) or a pharmacy information system).
Continua has developed a mapping for 20601 regardless of specialization. What has been mapped to FHIR resources are the attributes of Metric objects. So it does not make any difference what the object represents (glucose concentration, body mass, steps, blood pressure, etc.
The MDS static attributes describing the device have been mapped to Device and DevcieComponent resources. The Coincident Time stamp Observation handles the 20601 time properties of the sensor. Dynamic/Observational MDS attributes (like the battery level) are mapped to Observations
Demographic and administrative information about the patient.
Links the measurement information to the patient
The Logical ID of the Patient Resource identifies the Patient Resource, and indirectly the patient
PHG must know the Logical ID of the Patient Resource, or must be able to provide a Patient Designator which will allow the Logical ID to be located
Interoperibilty of medical device data from the home to hospital.
Managing chronic conditions > Disease management service
Aging and Wellness
Health and Fitness
These are only a few of the possibilities. Continua data from all types of sensors is possible and the ability to aggregate and secure the data downstream as a conduit into the EHR will fully open up the use-case spectrum, such that any organization with a vision for solving real solutions can realize that vision……………....................
Diabetes:
Glucose meter, Continuous Glucose Monitor, Insulin Pump, Weight Scale, Blood Pressure Monitor, Heart rate monitor (optional)
Hypertension:
Blood Pressure Monitor, Weight Scale, Heart Rate Monitor
Heart Failure:
Weight Scale, Blood Pressure Monitor, ECG (Electrocardiogram), Heart rate monitor
COPD:
Spirometer, Peak Flow, Thermometer, Pulse Oximeter, Heart rate monitor, CO2 monitor (optional)
Health & Fitness and many other use-cases …
