Adding software to MIDATA

Types of Software

The following types of software may be connected with the MIDATA platform.

Application Types

Software type Runs where Authentication Access scope
User Application User’s PC or phone OAuth2 login Account holder
Plugin User’s browser Portal session Account holder
Import Service User’s browser and MIDATA server Portal session Account holder
Backend Service MIDATA server Passed as parameter Account holder
External Service External Generated API key All subscribers
Data Broker External Generated API key Organization(s)
Project Analyzer External Generated API key Project

User Applications / Mobile Apps

A user application is software that runs outside of the MIDATA platform. Typically it is a mobile application but a desktop application is also doable.

Features:

  • The software runs outside of MIDATA on a phone or PC
  • It may be written using any language or technology
  • A user application uses OAUTH2 to authenticate to the MIDATA server
  • The use of the application may be linked to research projects on the platform
  • The use of the application may be linked to the use of an external service (see below)
  • The application can read, write to or do query with the server according to the rights it has.
  • The application can send emails or sms to account holders
  • There may be scripts stored on the MIDATA server which are triggered by the external application using FHIR messages

Plugins

A plugin is a combination of HTML and Javascript that runs as part of the MIDATA portal.

Features:

  • The software runs in the browser of the client as part of the MIDATA portal
  • It must be HTML/CSS/Javascript.
  • It is recommended to use angularjs as there is a library for communicating with the MIDATA portal.
  • The plugin receives its authentication token from the portal.
  • The plugin can read, write to or do queries with the server according to the rights it has.
  • The plugin can navigate to other plugins of the MIDATA portal
  • The plugin can send emails or sms to account holders.
  • There may be scripts stored on the MIDATA server which are triggered using FHIR messages
  • Plugins may not do requests to another domain than the MIDATA server.

Import Services

An import service is a Javascript programm that connects to another API that uses OAuth1 or OAuth2 authentification and imports data from another system.

Features:

  • An import service has the same features as a plugin.
  • Additionally there a functions for establishing an OAuth1 or OAuth2 communication to an external server.
  • A backend script may be called daily for doing background import. This backend script may use the previously established OAuth1 / OAuth2 connection.

Backend Services

A backend service is a script that resides on the MIDATA server. The execution is triggered by a condition like a resource or consent change.

Features:

  • A backend service runs on the MIDATA application server.
  • It is typically a nodejs script.
  • The executing is triggered by conditions defined using the developer portal
  • The script receives the session token and context from the server when it is started
  • The backend service may read, write to and do queries with the server according to the rights it has.
  • A backend service does not have any frontend.
  • All the other types of MIDATA software may have backend scripts in addition.

External Service

An external service is software running outside of the MIDATA platform. In contrast to the user application the service has access to all users that are using the service in one session. There is a special variant of external service called “Data Broker” that enforces access restrictions for multi Organization use. This is described later.

Features:

  • The software runs outside of MIDATA and is typically a server.
  • There is only one session between the service and MIDATA.
  • This session has access to all data available to the service.
  • The service receives its authentication token by manually generating an API key for use with the service
  • The service can read, write to or do query with the server according to the rights it has using the FHIR api.
  • A healthcare provider, a team or a developer may be defined as access key manager for the service.
  • Account holders may subscribe to using the service through the portal or user applications.

Data Broker (External Service)

A data broker is software running outside of the MIDATA platform. This type of software acts as middleware between Midata and multiple organizations using the middleware. In contrast to the external service the data broker has no direct access to all users that are using the service. Instead need to be consents between the account holders and the organizations using the service and between the organization and the data broker. With each request the data broker needs to provide the id of the organization on whose behalf the request is made.

Features:

  • The software runs outside of MIDATA and is typically a server.
  • There is only one session between the service and MIDATA.
  • An additional organization id must be provided with each request.
  • A request with session plus organization id has access to all data of the organization that is shared to the service.
  • The service receives its authentication token by manually generating an API key for use with the service
  • The service can read, write to or do query with the server according to the rights it has using the FHIR api.
  • A healthcare provider, a team or a developer may be defined as access key manager for the service.
  • Account holders may not directly subscribe to using the service. Instead consents with the corresponding organization must be created through the portal or API.

Project Analyzer

A project analyzer is a script that is run by a researcher to work with data of a project running on MIDATA.

Features:

  • The software runs outside of MIDATA and is typically a script.
  • The project analyzer may read and update data shared through a project.
  • The project analyzer may share back (aggregated) data to the participants of the project.
  • The authentication token may be generated by the researchers that are part of the project team.

Software Lifecycle

These steps are necessary to create a productive application with MIDATA

  • Create a developer account on the test platform. (test.midata.coop)
  • Register your application on the test platform.
  • Please contact MIDATA if you need datatypes not yet registered on the platform.
  • Develop your application on your local computer.
  • Test your application with the test platform. All types of applications may be tested without having any code deployed to the test platform itself.
  • Server-side code may also be uploaded to the test platform using the developer portal.
  • When you are satisfied with your application please contact MIDATA. A contract for operating the software on the productive instance will need to be made. Send in any server-side code for code review.
  • As last step your application definition and application code (if necessary) will be transfered to the productive instance by an MIDATA administrator.