Oracle® Health Sciences mHealth Connector Cloud Service

Introduction

The Cloud Connector framework allows customers to import data collected and managed by a third-party or device vendor's cloud platform to Oracle mHealth Connector Cloud. This document explains how device cloud vendors and the Oracle services team can use a set of standard connectors, including the standard HTTP connector, which accepts messages in JSON format from an external service.

If you are interested in connecting to mHealth Connector, please contact your Oracle sales representative or email Oracle Health Sciences at: healthsciences_ww_grp@oracle.com.

You can also visit the Oracle Health Sciences website at: https://www.oracle.com/industries/health-sciences/index.html">>https://www.oracle.com/industries/health-sciences/index.html

Connector Framework Components

The four components of the connector framework are the connector, the interpreter, the mapper, and the messenger.

Figure 1 mHealth Connector Cloud-to-Cloud Connector framework components

• Connector—This provider-specific code manages connection and communication with the provider's devices and services. It's responsible for device discovery, connection management, and communication of data from the external devices or cloud services, including the processing of any provider-specific communication metadata, known as the envelope. The three types of connectors are generic, specialized, and custom.

• Interpreter—The interpreter parses device payloads and extracts data and telemetry information. Interpreters can be categorized as JSON or binary. Binary interpreters support additional payload grammars which can be used to parse device-native binary payloads.

• Mapper—The device model mapper takes data extracted from incoming device data and processes it into messages that are compatible with the mHealth Connector cloud message format. You can create a mapping between the fields extracted from the incoming data parsed by the interpreter, to the fields of mHealth Connector device model format. The mapping docCloud-to-Cloud Connector Framework for Data Ingestion from a Third-Party Cloud Serviceument associates a grammar and a device model.

• Messenger—The messenger communicates information about the device registration, device metadata, and device message to the Oracle Internet of Things service instance embedded within the mHealth Connector platform.

Typical Workflow

In a typical workflow, a device cloud vendor calls a REST endpoint published by the mHealth Connector. The mHealth Cloud Service framework invokes a series of mappings and transformation steps, configured for each clinical study, to create a new data message and stores the message in the mHealth Cloud Service.

Create and Configure an HTTP Connector

Connectors manage the connection and communication with devices or with third-party cloud services. They also process the metadata and telemetry data from the devices or the services. HTTP Connector hosts a set of HTTP servers that are front-ended with a load balancer. The HTTP Connector must be configured for basic authentication. For authentication configuration, create a user account with the administrator role in the embedded IoT cloud service console and configure the same in the Connector screen.

1. Open the Internet of Things Cloud Service management console.

2. Click Menu . Click Devices, and then click Connectors.

3. On the Connectors page, click Create New Connector .

4. Enter values in the Name and Description fields.

5. If you need only one instance of the connector, select 1 in the Scale Factor field.

6. In the Type field, select Generic.

7. In the Telemetry section, select the appropriate values.

   • Protocol: Select HTTP Server.

   • Authentication: Select Basic authentication, and then enter your user name and password. You must have administrative access to perform this step.

   • Envelope: Click Add Grammar, and add the details in the Grammar window. Use the Map field to map the required device metadata fields with the values of the interpreted envelope data.

   • Payload encoding: If your payload is in JSON, select asciihex. if your payload is in base64-encoded binary, select base64.

8. Click Save. When you receive the message, Saved successfully, click Back.

   The generic connector is listed on the Connectors page and the State field displays the status of the connector. The five states are STARTING, STARTED, FAILED, STOPPING, and STOPPED. STARTED indicates that the connector is ready to accept device data.

   • To modify your generic connector, click Edit .

   • To remove the generic connector, click Delete .

   • To create an instance of your generic connector, click Start .

     Note:

     The Edit, Delete, and Start buttons are enabled only when the connector is in STOPPED state.

   • To view the device notifications that the connector receives, click connectors_messageALERT .

     Note:

     On the Notifications page, click the data under Content to view the device information. You can also create an interpreter from this page when device data is received for the first time. See Configure an Interpreter.

   • To view the details of your generic connector, click View .

     Figure 2 View the Cloud-to-Cloud Connector framework details

     
     

     Note:

     Depending on the volume, frequency of the data, etc., it is possible for a single connector to serve multiple clinical studies at the sane time. When a connector supports more than one study, make sure that a unique study identifier or a combination of attributes are included in the data payload so the framework can route the message to the correct mHealth study datastore.

On-boarding a Device Cloud

To send data to mHealth Cloud Service, a device cloud needs POST device messages for JSON format to a HTTP connector REST resource created in the mHealth Cloud Service. The entities within a JSON payload must be accessible using JSONPath notation. Although a data message can have an array of entities, it is expected that every POST message includes the same number of entities.

If one HTTP Connector handles data messages across multiple clinical studies, make sure that each message includes a study identifier field. Similarly, it is assumed that a subject identifier (a non-PII value) and a physical or virtual device identifier and /or serial number is included in every message. For example:

{
"deviceId" : "abcs-1234",
"deviceSerialNumber" : "serial#",
"studyname" : "clinical study",
"subjectId" : "patient identifier (non-PII)",
"event_timestamp" : "UTC time in ISO date format yyyy-mm-ddTHH:mi:ssZ",
"attribute_1" : "attribute_1_value",
"attribute_2" : attribute_2_value
}

{
"deviceId" : "abcs-1234",
"deviceSerialNumber" : "serial#",
"studyname" : "clinical study",
"subjectId" : "patient identifier (non-PII)",
"event_timestamp" : "UTC time in ISO date format yyyy-mm-ddTHH:mi:ssZ",
"attribute_1" : ["attribute_1_value_1", "attribute_1_value_2", "attribute_1_value_3" ],
"attriibute_2" : attribute_2_value
}

{
"deviceId" : "abcs-1234",
"deviceSerialNumber" : "serial#",
"studyname" : "clinical study",
"subjectId" : "patient identifier (non-PII)",
"event_timestamp" : "UTC time in ISO date format yyyy-mm-ddTHH:mi:ssZ",
"attribute_1" : {
"attr1": "attribute_1_value",
"attr2": "attribute_2_value"
}
"attribute_2" : attribute_2_value
}

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.