SemHealth
Advancing Open mHealth with Semantic Web Technology
This project was originally inspired by the Heritage Open mHealth Challenge”Heritage Provider Network (HPN), in collaboration with the University of California Los Angeles (UCLA) and Open mHealth” to develop and submit a mobile application that utilizes the Open mHealth architecture to facilitate interoperability between increasing number of mobile apps related to health and well being.
Contents
Project Summary
The Open mHealth architecture is meant to help people coherently leverage the data generated by the multitude of mobile healthcare applications currently in the marketplace. Mobile applications have their own APIs to access their data, which makes it difficult for developers to quickly and easily combine data for other applications. The motivation for this project stems from the semantic integration challenges that arise from the increasing mobile health data silos. Thus, Open mHealth provides a standard for APIs to assist in the above by following these goals stated on its main developer page:
- to foster software reusability in order to allow new applications to be built faster and to share innovations (software components, novel approaches) amongst software developers
- to standardize and commoditize back-end data stores so client software may access any Open mHealth-compliant data store in a uniform way (interoperability)
- to produce examples and documentation of these concepts meaningfully and simply
- to be pragmatic, considerate and iterative in our approach
So the idea spawned from this challenge was to convert the existing k-Health application to use the Open mHealth architecture. Further, we propose to extend the Open mHealth architecture with semantic web technologies. As Open mHealth is the first standard in mobile health architecture, now is a perfect time to add semantic web technologies and see how well these technologies work with the current spec. Ideally, completion of this project will both satisfy course requirements and result in a submission to the Heritage Open mHealth challenge From this application, we want to extract the database, reasoner and visualization modules to create a Open mHealth compliant Data Storage Unit (DSU), Data Processing Unit (DPU), and Data Visualization Unit (DVU) respectively. A DSU, DPU, and DVU are defined as follows on the developer page:
- A DSU provides a uniform way to access data through the various calls of API. The API calls that DSUs are required to implement are: (1) Registry Read, which returns a list of Payload IDs supported by a DSU, (2) Authenticate, which allows end-users to authenticate with a DSU, and (3) Read, which allows applications to read data associated with a particular Payload ID and end-user.
- A data processing unit represents a unit of work to be performed on JSON data. DPUs may be composed through multiple API calls. All that is required of a DPU is that it must have a well-documented open API. A DPU may be available as a library to include in an application or as a simple HTTP-based service.
- A data visualization unit represents a visual representation of data for a particular Payload ID that may have been processed by a DPU. A DVU lives in a web browser and should be written using JavaScript and HTML5 techniques. A collection of DVUs can form the backbone of a complete application for clinicians to use to assess patient or participant data. A DVU must publish its API and the Payload ID it supports. A DVU can be thought of as a library that any other Open mHealth developer can pick up and use.
Note that both the reasoners input is not saved in any way and its output is not displayed to the user.
Members
Maryam Panahiazar <mary@knoesis.org> Shiwangee Nandan <shiwangee@gmail.com> James West <west.126@wright.edu> Pramod Anantharam <pramod.atre@gmail.com>
Project Specification
As stated in the introduction, this project has two major goals:
*Compliance of k-Health with Open mHealth architecture *Empower Open mHealth with semantic processing capabilities. There are a web-recognizable collection of knowledge representation standards (RDF , OWL) proposed by Semantic Web, that can serve as metadata protocols among connected devices.
Architecture of the SemHealth
- Sensors
- All are bluetooth sensors already utilized by the current k-Health application to measure weight, heart rate, and blood pressure
- Android application
- Reads sensor observations through bluetooth
- Performs annotation on observations and generates percepts from those observations
- Uploads annotated observations and percepts to the server-side data store
- Retrieves data using DSU API and feeds data to DPU and/or DVU APIs
- Visualizes data through DVU API
- Considered a “nice to have” as existing visualization may be used as-is
- Will utilize existing graphing library for Android with Open mHealth-style API that may be translated to browser at a later time
- Server-side
- Open mHealth compliant DSU and DPU APIs
- Triple data storage replaces existing SQLite database in k-Health application
- Existing k-Health reasoner now the brains behind DPU
More specific goals to accomplish this include:
*Perform further research on the technologies to be utilized by this project *Develop a semantic data model to store data from mobile application *Add annotations to the observations currently collected by k-Health using existing ontology. A large amount of sensors exist, by annotating the sensors with subject, predicate, and object triples (as in RDF, http://purl.org/lsn/#sensor1http://purl.org/lsn/#hasLocation http://example.org/ssn/#spot ), the sensors can construct a linked sensor web. *Embedding the meta knowledge queries. *Develop APIs for DPU and DVU modules *Implement the semantic data model and APIs in an Open mHealth compliant fashion Convert the k-Health application to utilize these APIs for its data storage, processing, and visualization
Use CASE
Contact
Shiwangee Nandan, shiwangee@gmail.com James West, west.126@wright.edu Maryam Panahiazar, mary@knoesis.org
