![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](https://image.slidesharecdn.com/furore-devdays2017-continuaimplementingfhir-171117081401/85/Furore-devdays-2017-continua-implementing-fhir-45-320.jpg)
Furore devdays 2017- continua implementing fhir
- 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
- 8. Capture & Collect Display & Consume 1 3Aggregate, Normalize, Store & Forward 2
- 9. Continua Design Guidelines (CDG) 10 https://www.itu.int/rec/T-REC-H/en
- 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
- 12. Key Alliances
- 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
- 19. Services Actions Services Actions Services Actions Services Actions Eventing Eventing Eventing Object 1 • attribute 1 • attribute 2 • attribute 3 • attribute 1 • attribute 2 • attribute 3 • attribute 4 Object 2 Object 3 • attribute 1 • attribute 2 • attribute 3 • attribute 1 • attribute 2 • attribute 3 • attribute 4 Object 4 Agent DIM
- 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*
- 21. IEEE 11073-10407 Blood Pressure Monitor
- 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.
- 29. GATT Specifications (Medical Device) • BLP/BLS Blood Pressure Profile/Service • CGMP/CGMS Continuous Glucose Monitoring Profile/Service • GLP/GLS Glucose Profile/Service • HRP/HRS Heart Rate Profile/Service https://www.bluetooth.com/specifications/gatt • HTP/HTS Health Thermometer Profile/Service • PLXP/PLXS Pulse Oximeter Profile/Service • WSP/WSS Weight Scale Profile/Service • IDP/IDS Insulin Delivery Profile/Service (in development)
- 30. Hierarchy SERVICE A PROFILE SERVICE B SERVICE C Characteristic B_2 DescriptorsValueProperties Characteristic B_3Characteristic B_1
- 31. IEEE and Bluetooth Personal Health Devices Interface Services Interface
- 32. CDG Technical
- 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
- 38. 11073 “MDC” PoCD Model FHIR Mapping (current) Medical Device System (MDS) Virtual Medical Device (VMS) Channel Metric (Abstract) Numerics / Enumerations / Waves 1..* 1..* 1..* 1..1 Device Patient Observation DeviceComponent (MDS Profile) DeviceComponent (VMD Profile) DeviceComponent (Channel Profile) DeviceMetric
- 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
- 46. Measurement representation (Metric Object)
- 47. Continua Data Use Cases (just a few examples)
- 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
- 54. Observation (BP) Component: (systolic) Component: (diastolic) Component: (MAP) Device (PHG) Patient (PID) Bundle Device (sensor) Observation (Pulse Rate) Blood Pressure:
- 55. Patient Resource • Annie Pchaid https://fhirtest.uhn.ca/baseDstu3 /Patient/PatientId- anniepchaId/_history/1
- 58. Observation Resource cont’d • “category”
- 59. Observation Resource cont’d • “code” • “subject”
- 60. IEEE 11073-10101 Nomenclature 62 Encoded value for the code element = (partition)*2^16 + (IEEE reference ID) MDC_PRESS_BLD_NONINV_DIA = 2*2^16+18950 = 150022 https://rtmms.nist.gov/rtmms/index.htm#!rosetta
- 61. Observation Resource cont’d (Compound Numeric) • “component”
Editor's Notes
- #6: 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
- #7: 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
- #8: 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
- #10: 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
- #11: These interfaces and ability to achieve E2E interoperability are described through a series of documents that combined produces the CDG.
- #12: 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?
- #13: 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
- #15: 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
- #16: 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).
- #18: 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
- #19: 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.
- #20: *Capabilities described are typical of respective devices, however they are not universal rules
- #22: Agent has objects to describe its features
- #25: 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
- #29: 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)
- #31: Pair of specs
- #32: 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.
- #33: 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
- #34: 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
- #37: 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).
- #43: 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
- #44: 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
- #50: 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 …