Introduction¶

Patient account¶

To give patient access to a website / applications that connects to Bricks Huisarts using Bricks Switchboard the practice can create an account in Bricks Huisarts for the patient.

Patients need to have the following information to login to the API:

• Email address

• Password

• Mobile number

More information about creating accounts in Bricks Huisarts can be found in the Bricks Huisarts documentation.

Identification / access¶

All requests contain an identification (Name and Key) and Target part.

The identification part tells the Switchboard which application is accessing the API, the target gives information which practice will receive the data and need execute the request.

The key/values that needs to be added to each request are the following:

{
    "Name": "received-application-name",
    "Key": "received-access-key",
    "Target": "practice-or-agb-code"
}

• Name: Application name

• Key: Access token

• Target: Switchboard practice name or AGB-code

Logged in user¶

For requests that are behind a login you need to follow the login steps. Those requests need to have a session value in the JSON object above. The session value isn’t created by the Bricks Switchboard, this is something you need to create yourself.

A logged in request needs to have the following values:

{
   "Name": "received-application-name",
   "Key": "received-access-key",
   "Target": "practice-or-agb-code",
   "Session": "self-created-user-session-id"
}

• Name: Application name

• Key: Access token

• Target: Switchboard practice name or AGB-code

• Session: A self created session, unique for each user

Requests¶

All requests are a HTTP POST of JSON data to the endpoint. You can set the HTTP Content-Type to application/json, but this isn’t needed to submit a request.

Based on the response headers it is possible to “see” when a request was successful delivered to the practice.

When you get HTTP response code with 500 as a value it means that Bricks Switchboard itself has encountered some sort of issue. This should be solved within a couple of minutes. In case you keep getting the “code 500” please contact Tetra Support to address the issue.

Not getting a 500 as a response code? This means you’ve received a “code 200” and with it a reaction from the practice. In a normal situation the response contains a JSON-string with a ReturnValue.

Within the ReturnValue you will have a ResponseCode. Based on the ResponseCode you can detect a successful request (200), that something is not found (404) or that something went wrong (500).

Example of a “something went wrong” message:

{
   "ReturnValue": {
      "ResponseCode": 500,
      "ResponseText": "Server error",
      "Melding": "Niet ingelogd of al verstuurd",
      "Gelukt": false
   }
}

You can use Gelukt (boolean) to see if you have received a successful response to your request. Gelukt will be true when you have a successful response, false in case when there is an issue. Gelukt in combination with the ResponseCode will “guide” you to find out what is going wrong in case something happens that you do not expect.

When there is an issue you can find the reason in Melding.

In case you get a HTTP 200 code with a text string like Service unavailable or Server error it means that something went wrong at the practice.

General error¶

You’re not doing something wrong when you and send a request to Bricks Switchboard and the response is a HTTP-code 500 in combination with:

{
   "Foutmelding": "Fout opgetreden bij verwerking.",
   "ReturnValue": false
}

This error means that something unexpected happend at API-side.

In a perfect world your should not get this response 😉 possible reasons what is going wrong:

• a session key has been used that never been used before

• AGB-code is incorrect

• something else is little “weird” in your request.

The big picture¶

The position of Bricks Switchboard in the infrastructure: