CabMD API

Developer Documentation

• Latest Update: 5/7/2025 (1.0.9258.22694)
• Swagger
• by: Kori Francis
• email: support@cab.md

If you have any issues, please don't hesitate to send an email.

Securely Connecting to CabMD

The API Authentication is implemented as HTTP Basic Authentication over SSL (HTTPS). Your API lgin credentials are not the same as the credentials you use to log in to the web interface. You must obtain your API credentials separately after creating an account in CabMD (live accounts at cab.md, demo accounts at demo.cab.md).

Obtaining Your API Credentials

Your API key (should be in the format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, where X is an alpha-numeric character) can be generated from your account settings page, the "My Account" menu item located under "Account". Details on how to generate/refresh your API key, or enable/disable API/third-party access are located here. An example of an API key would look like a02b0f5b-712b-4a68-b495-173f32bcde42.

Authenticating With Your API Credentials

You should use HTTP Basic Authentication to verify your identity via the API. We will also accept using the API key in the query string of the request, but we do highly recommend that you switch to using the Authorization header to pass that information. We will be making changes in the future, and the method of passing via the query string will eventually be refused.

All requests must cover over SSL/HTTPS, to https://api.cab.md. An example using authentication via curl would look like this:

curl -u XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX:x -H Accept:application/xml https://api.cab.md/claims

An example, which is currently allowed, is to also pass the api key along in the query string of the request, like so:

curl -H Accept:application/xml https://api.cab.md/claims?apiKey=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

API Testing

As a third-party integrating with CabMD, how can you test your integration?

To facilitate the ability to run test data through the CabMD API - all you need to do is add use the test keyword in the route of the method you're attempting to use, like so:

Claims:

LIVE EXAMPLE - https://api.cab.md/claims

TEST EXAMPLE - https://api.cab.md/test/claims

The API key for testing comes from any account located in the demo system (available at http://demo.cab.md). Instructions on how to find your API key can be found here: http://support.clinicalsupportsystems.com/customer/portal/articles/827075-how-do-i-access-my-api-key-for-third-party-integrations-, for either the live or the demo systems.

Claims

Claim Input Attributes

The following are all the accepted fields:

• admissionDate - (optional) The date of admission
• careProvider - (required) The care provider is the physician who is performing the service
  • groupNumber* - The group number should either be '0000' (for solo service billing) or ANNN (one letter followed by three numbers, which represents the group as registered with the Ontario Ministry of Health)
  • providerNumber - The physicians OHIP billing number, which is a six-digit number.
  • department* - (sometimes optional) - The department name where these claims should be entered under. This string value should match (case-insensitive) the department name within CabMD. If no match is found, then an error will be returned.
• referringPhysician - (optional) The physician who referred the patient to the careProvider
  • providerNumber - The referring physician's OHIP billing number, six digits.
  • collegeNumber - The five digit number corresponding to the physicians college registration number.
  • firstName - The first name of the referring physician.
  • lastName - The last name of the referring physician.
• patient - The patient to which the defined services were performed and the care provider is claiming.
  • firstName - The first name of the patient.
  • lastName - The last name of the patient.
  • gender - The gender of the patient (either 'male' or 'female')
  • dateOfBirth - The date of birth of the patient.
  • healthCard - The health card number of the patient, usually the 10 digit OHIP number.
  • versionCode - (optional) The patient's health card version code, if applicable.
  • provinceCode - The two letter province code corresponding to the provincial health card being submitted.
  • contact - (optional) Patient contact information which will be seen on the remittance report after the claim is paid.
    • name 
    • number
• admissionDate - (optional) The admission date for the services being claimed.
• diagnosticCode - (optional) The three digit diagnostic code (ie. The decision made by the care provider regarding the patients condition).
• masterNumber - (optional) The four digit master number (ie. The code that describes to OHIP where the service was performed).
• serviceLocationType - (optional) The three letter identifer that descibes what type of service is being performed. Must be either 'HIP' (Hospital In-Patient), 'HOP' (Hospital Out-Patient), 'HED' (Hospital Emergency Department, 'HRP' (Hospital Referred Patient) or 'HDS' (Hospital Day Surgery).
• serviceDate - The date the services are being rendered by the care provider for the patient.
• services (list of item 'service') - The services being rendered by the care provider.
  • serviceCode - The OHIP code that describes the service being rendered. Should be in the format ANNNA, a letter followed by three numbers and then followed by the letter A, B or C (usually A).
  • quantity - The number of serviceCode services rendered.
• reference_id - (optonal) A string value, usually ID/GUID/UUID, that will be passed back to you in the response.

The careProvider's department and groupNumber value is somewhat optional, but the following logic will apply:

Departments

• If the careProvider has no department and the claim was submitted with a department value - it will still be added but a message will be returned explaining that we ignored the department value submitted.
• If the careProvider has only one department in CabMD then the claim should be added to that department.
• If the careProvider has more than one department and the claim has no department defined - then we first look for a preferred department in CabMD. If there's a preferred department, then we use that - otherwise we will throw an error as we can't assume which department it should be in.

Groups

• If the careProvider has no group and the claim includes a group that is not solo (ie. "0000"), then we will not add the claim and there will be an error.
• If the careProvider has a group and the claim doesn't include a group then we will add the claim but have to assume it's the solo number (unless there's a preferred group setup in CabMD).
• If the careProvider has one or more groups and the claim includes a group that exists (solo or one of the defined groups), then the claim will be added as expected.

If you need more information about this, please don't hesitate to contact support.

Creating a Claim via the API

To create a claim, simply POST the claim information to the correct URL endpoint.

Create

LIVE URL: https://api.cab.md/claims
TEST URL: https://api.cab.md/test/claims
Method: POST
Content-Type: application/xml, text/xml or application/json
Accept: application/xml, text/xml or application/json
Required Data: Claim
Required Headers: Authorization (using Basic HTTP Authentication), or apiKey in query string (ie. https://api.cab.md/claims/echo?apiKey=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
Response: The API response object

Usage Examples:

If you POST the following to https://api.cab.md/claims?apiKey=<your api key>

<?xml version="1.0" encoding="UTF-8"?>
<Claim>
  <admissionDate>2011-09-30T15:03:33.2266062-04:00</admissionDate>
  <careProvider>
    <groupNumber>H855</groupNumber>
    <providerNumber>012630</providerNumber>
    <department>Office A</department>
  </careProvider>
  <dianosticCode>413</dianosticCode>
  <masterNumber>4105</masterNumber>
  <patient>
    <dateOfBirth>1983-05-25T15:05:06.1201812-04:00</dateOfBirth>
    <firstName>Kori</firstName>
    <lastName>Francis</lastName>
    <gender>male</gender>
    <healthCard>1234567890</healthCard>
    <versionCode>AB</versionCode>
    <provinceCode>ON</provinceCode>
  </patient>
  <serviceDate>2011-09-30T15:06:19.6853913-04:00</serviceDate>
  <serviceLocationType>HIP</serviceLocationType>
  <services>
    <service>
      <serviceCode>A605A</serviceCode>
      <quantity>1</quantity>
    </service>
  </services>
</Claim>

Then the response status should be "201 Created" and you should receive the following in the response:

<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <success>true</success>
</response>

If the save was not successful, you could receive 400, 401, 404 errors. If the save was unsuccessful with other issues (data was correct, but save couldn't proceeed regardless), you should receive the following:

<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <success>false</success>
  <errors>
    <string>An error might be listed here.</string>
  </errors>
</response>

Submissions

Submission Input Attributes

The following are all the accepted fields:

• careProvider - (required) The care provider is the physician who is performing the service
  • groupNumber - (optional) The group number should either be '0000' (for solo service billing) or ANNN (one letter followed by three numbers, which represents the group as registered with the Ontario Ministry of Health). If no groupNumber is specified (ie. don't add this to your input) then all claims will be submitted.
  • providerNumber - (required) The physicians OHIP billing number, which is a six-digit number.
  • department* - (sometimes optional) - The department name where these claims should be entered under. This string value should match (case-insensitive) the department name within CabMD. If no match is found, then an error will be returned.
• comment - (optional) A comment that will be added to the EDT file when creating the new submission.

The careProvider's department  value is somewhat optional, but the following logic will apply:

• If the careProvider has no department and the submit data was submitted with a department value - it will still be added but a message will be returned explaining that we ignored the department value submitted.
• If the careProvider has only one department in CabMD then the submission will occur that department.
• If the careProvider has more than one department and the submit data has no department defined - then we first look for a preferred department in CabMD. If there's a preferred department, then we use that - otherwise we will throw an error as we can't assume which department we should be submitting.

Submitting Claims via the API

To create a new submission, simply POST the submit information to the correct URL endpoint.

Create

LIVE URL: https://api.cab.md/submissions
TEST URL: https://api.cab.md/test/submissions
Method: POST
Content-Type: application/xml, text/xml or application/json
Accept: application/xml, text/xml or application/json
Required Data: Claim
Required Headers: Authorization (using Basic HTTP Authentication), or apiKey in query string (ie. https://api.cab.md/claims/echo?apiKey=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
Response: The API response object

Usage Examples:

If you POST the following to https://api.cab.md/claims?apiKey=<your api key>

<?xml version="1.0" encoding="UTF-8"?>
<submit>
  <careProvider>
    <groupNumber>H855</groupNumber>
    <providerNumber>012630</providerNumber>
  </careProvider>
  <comment>This is a new submission</comment>
</submit>

Then the response status should be "201 Created" and you should receive the following in the response. In the response will be a message relaying some information about the submission (the filename, number of claims submitted and it's status):

<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <success>true</success>
  <messages>
    <string>The file 'H012630.001' has been creating, containing 1 claim, and are waiting to be submitted to the Minstry of Health.</string>
  </messages>
</response>

If the save was not successful, you could receive 400, 401, 404 errors. If the save was unsuccessful with other issues (data was correct, but save couldn't proceeed regardless), you should receive the following:

<response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <success>false</success>
  <errors>
    <string>An error might be listed here.</string>
  </errors>
</response>