Introduction

This section of the implementation guide is meant to supplement the more formal parts of the documentation. The per-resource (or per-profile) descriptions work well as a reference, but it is hard to consume and to put them into practice when just making the first steps. For this reason, these pages provide a more example- and best-practice-driven guidance that is building up knowledge gradually and explains the different workflows in a logical order.

The pages of this section build upon each other and are meant to be read in order. Examples of using the API are provided with curl commands (while in practice the same API-s should be called directly by the client code base). These examples assume that the following shell variables are already set:

• server: the host name of the server providing the R5 interoperability endpoints.
• client_id, client_secret, org_id and certificate: credentials for accessing the server.

Obtaining these values is outside of the scope of this documentation.

A note on terminology

Generally, the terms client and server will be used to refer to the consumer and the provider of the Roche interoperability service, respectively. However, this terminology can become confusing when the server sends a notification to the client, because during a notification the traditional client and server roles are effectively swapped. To avoid this confusion, in the context of notifications, the term subscriber will be used to refer to recipient of the notification, who is the same entity as the client of the Roche interoperability service.

The terms client and subscriber are therefore used interchangably to refer to the consumer of the Roche interoperability service, with the aim of using the term that causes the least confusion in a given context.