Curative POS SDK

This SDK provides complete details about the APIs supported by Curative POS. When you register for integration with your system to utilize our APIs, you will be provided a unique client name, client id and secret key for a sandbox POS account that you can use for integration and testing.

POS APIs

  1. Login
  2. Register User
  3. InActivate User
  4. Register Customer
  5. Sales Data Feed
  6. OpenPOSCart
  7. GetOpenCartProducts

Some generic points:

  • Client id and secret key are ‘tokens’ to uniquely identify the registered client system (refer to sample request for the API). Client id and secret key provided by the POS team at the time of registration of your EMR system, should be passed as header parameter for every API call mentioned in this document.
  • ‘Content Type’ of every API call should be “application/json”.

Basic Integration

At the very simplest level, a basic integration is adding two buttons in three places in your software platform.

  1. RX Button – to allow a clinician to quickly open the POS to recommend products to a patient.
  2. RX Button – to allow front office personnel to open the POS to see what products were recommended by the clinician.
  3. POS Button – allows anyone to open the POS to transact a generic sale. (anyone who walks in and wants to buy something)

Here’s Another View With Icon Placement Examples

Tokenizing the POS During Onboarding

The POS system uses oAuth to allow system-to-system authentication. OAuth is a protocol is used by applications to perform API requests to a system (such as Curative POS) on behalf of another system (such as EMR/EHR software) – this is also known as “system-to-system requests.”

Each time the application makes a request to the POS APIs, it uses the required campus keys and details of the request to generate a unique signature. It then includes the system credentials and the signature in the request header before submitting the request. This process must be repeated for every request because the generated signature will differ each time. The POS then verifies that the system credentials and signature are valid before processing the request.

  1. Sales Agent Triggers Onboarding – Sales agent logs into the Active Care POS Onboarding Portal and enters new organization’s information to begin onboarding process.
  2. oAuth Auto-generated – Onboarding Portal sends oAuth key to new organization contact.
  3. EMR Vendor is Sent oAuth Key – Onboarding Portal sends EMR vendor the organization’s oAuth tokens

Full Integration

To complete a full integration utilize our Sales Data Feed API. This data feed allows you to integrate the POS sales data into the organization’s reporting and/or analytics (daily/weekly/monthly performance reports, etc). This allows organizations to see what affect the retail program is having on various aspects of their business, and provides a competitive advantage for your EMR software over others who may only do the basic integration of the POS.

Introduction

This document provides complete details about integrating the APIs offered by Curative POS system. The Curative POS System APIs are an Application Programming Interface that allows you to integrate your EMR/EHR system with the Curative POS system. By integrating with Curative POS System using these APIs, your users will have access to a POS system that allows therapists to recommend products (Therapist-RX™) to patients, and any user can transact a retail sale directly from inside your EMR/EHR. Once integrated, Curative POS System remembers the recommendation made for patient’s appointments and enables front desk staff to transact and fulfill those product recommendations.

The Curative POS System APIs expects to communicate in form of JSON data. This document will assist you in integrating your application with the Curative POS System APIs and provide brief summary about the POS features offered by the APIs.

What is Therapist-RX™? (RX Button): This is a brand name that describes our unique feature that allows a therapist to recommend a product for a patient in the EMR/EHR and/or the POS and allows other users such as a front desk clerk (patient care coordinator, client care specialist, etc) to access the recommendation (cart) and complete the sale and payment transaction with the patient. The use of an RX button or icon denotes the Therapist-RX™ feature. This functionality is specific to a patient, and a patient’s appointment. Therapists can make multiple product recommendations across the patient’s entire series of appointments on the present day or for future appointments.

Generic Sale (POS Button): This is any anonymous, generic retail sale. This would be any walk-in customers who do not have an appointment or case who just want to purchase some retail products in a typical fashion.

1.1. Prerequisite

This section describes the steps you need to perform and data required to integrate the Curative POS System APIs with your application.
Your EMR/EHR system must be registered with Curative POS System before you start calling the APIs. Please contact our team at integration@curativepos.com prior to beginning integration.

Once you are registered, you will receive a welcome email from ‘donotreply@curativepos.com’. This email contains the following information required to use Curative POS System:

Client Name: A unique client name assigned by Curative POS System while registering your EMR/EHR system. Users are expected to use this client name to login standalone POS System. In general, client name would be a string short form / abbreviated form of your organization.
Client ID: Your client id, assigned by Curative POS System. Client id will be a GUID.
Client Secret Key: Private key provided by Curative POS System to authenticate your EMR/EHR system. Client secret key would be a 44 character long alpha-numeric string.

Client id and client secret key are ‘tokens’ used by the POS system to uniquely identify the registered EMR/EHR system. Please store the client id and client secret key securely as the POS system expects to receive them as header parameter for every API call mentioned in this document.

Note: Even after registering your system with the Curative POS System, you can control the usage of integrated POS. The integrated POS system works only for the users that exist in your EMR/EHR. It is important for your system to register all users in your EMR/EHR with the POS in case those users will need to use the integrated POS.

1.2. Overview

This section will give you an overview on how the Curative POS system APIs works and various business scenarios when your EMR/EHR system should call the Curative POS APIs.

In a normal scenario, a therapist – while treating a patient will want to recommend one or more products to their patient. The therapist can click an RX button to open the integrated POS and add product to a cart that is specific to the patient and the patient’s appointment. Products added to the patient’s appointment can be accessed by front desk clerk (or any other user) to complete the checkout process at any POS “cash register”, or any computer, or device logged into the POS account. The Clerk can add or remove products from the cart and transact the sale with the patient.

The clerk can also open the integrated POS to handle walk-in patients and/or customers for their specific product requirements using a generic “POS” icon that opens a non-patient, non-appointment POS window.

1.3 Business scenarios and related APIs

Registering EMR/EHR users for POS use:

API:
– RegisterUser

The POS has role-based permissions, with four distinct roles:

  • Admin
  • Manager
  • Therapist
  • Clerk

It is necessary to register the EMR/EHR user accounts with the POS, and to associate the roles appropriately. It is important to map the roles of your EMR/EHR software to the four roles in the POS so that users of your system are assigned the proper permissions and features in the POS respective of their job position. On user registration, the POS system returns a user authentication token. This token is required to call all the other APIs offered by the POS system.

Therapist-RX™ (Therapist recommends products to a patient):

APIs:
– RegisterPatient
(onetime activity – once the patient is registered with the POS, you can call the ‘OpenPOSCart’ API directly for all subsequent use)
– OpenPOSCart

A therapist can recommend the product to a patient for specific current or future appointments. The POS system will manage the recommended products separately for each appointment of the patient. This operation can be provided normally from any therapist-centric screen, like documentation and flowsheet of a patient’s appointment. Therapists can recommend products to a patient in the calendar/scheduler, in the patient’s documentation screens, or anywhere else you think a therapist would benefit from having access to the Therapist-RX functionality.

Clerk opens a Therapist-RX™ from a patient’s appointment:

APIs:
– OpenPOSCart

This feature can be offered in the calendar/scheduler, where all the appointments are listed. In this scenario, the cart opened from the POS system would be linked to specific appointment of a specific patient. A clerk can open the POS cart for a patient’s appointment to complete the sale of the therapist recommended products. Clerk can add or remove items from the cart as per patient’s choice and sale the products. Depending on your system context, this operation can be performed by any of the registered user (i.e. therapist, clerk, manager or admin). As the cart would associated with patient’s appointment, this operation can be provided from any and all the places where product recommendation operation is offered.

Generic POS (Retail sale for walk-in patient and/or customer):

APIs:
– OpenPOSCart

Users can transact retail sale for walk-in patient or any anonymous customer. In this scenario, a cart opened from the POS system would not be linked with any patient or appointment. This operation can be provided from any place in your application like, menu, sub-menu, right-click menu or action toolbar. As this is a generic retail sale, the operation should not be offered from patient or appointment specific space.

Open product recommendation for appointments:

APIs:
– GetOpenCartProducts

Clerk or any other registered user can check whether any products have been recommended by a therapist for appointment(s).

Reset password for registered user:

APIs:
– ResetPassword

In the common event where a registered user forgot their password, users can reset the POS password using this operation. NOTE: In the event where a password needs to be changed manually by an administrative person for another user, any POS users that were created and registered form the EMR/EHR should be updated or edited in the EMR/EHR user maintenance screen — not the standalone POS maintenance screen.

Unregister therapist/clerk/admin:

APIs:
– UnregisterUser

To restrict access to the integrated POS, you can unregister a registered user. Unregistered user will not be allowed to perform any operations in the POS.

  1. Integration APIs

This section describes purpose, URL, parameter definition, request-response structure with sample request-response and troubleshooting guide for each Curative POS System API.

Note:

  1. Client id and client secret key provided by the POS team at the time of registration of your EMR/EHR system, should be passed as header parameters for every API call with ‘POST’ request method.
  2. ‘Content Type’ of every API call should be “application/json”.
  3. User credentials should always be passed in encrypted form. Curative POS system supports AES encryption methodology for data encryption/decryption.

2.1 Register User

PurposeThis API will allow clients to register an employee through their EMR/EHR. Upon receiving the API calls of the registered employee, the Curative POS system will create an employee account under their Curative POS account. Once the account has been created, they will receive the employee’s credentials to store.

When receiving the registered employee’s credentials, they can be used to login to their standalone Curative POS account. The following items are needed to login to the Curative POS account:

  1.                 Client Name (Section 1.1)
  2.                 Email
  3.                 Password

Only registered users should be allowed to perform any operation using the Curative POS API calls.

URL/api/apiUser/RegisterUser

Request Type: POST

Request ParametersUserName: [string : 50-character max]

  • Name of the user to be registered with the POS system. User name passed in this parameter will be displayed when user access POS system (integrated or standalone).

UserEmail: [string : 100-character max : valid email address]

  • A valid email address of the user to be registered. This email needs to be unique for every registering user as this will be used as login user id while accessing standalone POS.

UserId: [string : 50-character max]

  • A unique id of the user to be registered. This can be a primary key of the EMR system for specific user.

RoleName: [string : 50-character max] [Valid values: ADMIN / MANAGER / THERAPIST / CLERK]

  • Registered user will be assigned role on the POS side depending on the string passed as RoleName. POS system features will be available based on the roles assigned to registered user.

All the parameters are required.

ResponseStructure:

{“message”:[result message],”success”:[flag],”value”:[object]}

message: Null for successful user registration. In case of failure, error message to indicate reason of the failure. Refer troubleshooting section for possible error messages.

success: true or false to indicates success or failure

value: JSON object of the registered POS user on successful registration. Null in case the API call resulted into failure.

Object structure –

{

“userId”:[User Id of the registered user],

“userEmail”:[Email of the registered user in encrypted form],

“password”:[Password in encrypted form]

}

  • On successful user registration, userId returned in the response will be same as passed in request parameter.
  • userEmail and password should be used to log in the POS system (standalone or integrated) after decryption. [Refer initial content of Section 2 for decryption logic]
SampleRequest –

POST /api/apiUser/RegisterUser HTTP/1.1

Host: https://ipos.com

clientid: c352167b-2154-92cf-de08-08dd59868e1a

clientsecret: nhjd6kC67/w7ToOpSDDFrZe7sKsTcHMa04xWgbeC2Cs=

Content-Type: application/json

Cache-Control: no-cache

Postman-Token: ccbc6fbf-dc8e-217c-633c-83c0ef057577

{UserName:”mike”,UserEmail:”dyane.c@gmail.com”,UserId:”2585″,RoleName:”THERAPIST”}

Response –

{“message”:null,”success”:true,”value”:{“userId”:”2585″,”userEmail”:”evy0wdY6WetbMWi9KAZJMIbO1wFbmkbu0YQy97I8NoL3cx5USYEglgJB59Yl1dfU”,”password”:”SCykEzN7DwxJkL9+Q59W+lLDS399xOefr9YN7RjfR4E=”}}

 

2.2 Reset Password

PurposeShould an employee need to login to their standalone account and forget their password they need to go into their EMR/EHR and click on the “reset password” button.

This API is designed to reset the password for employees that were registered through the integration.

Upon receiving the reset password API call with valid input data, the POS system will re-generate an automated password and return it with the EMR user id.

For any POS Employees that were generated on the standalone site, they can go to the Curative POS site and click on the “I forgot my password” link on the login page.

URL/api/apiUser/ResetPassword

Request Type: POST

Request ParametersUserId: [string : 50-character max]

  • A unique id of the user for whom the password needs to be reset. This should be EMR system’s internal unique ID used at the time of user registration.

All the parameters are required.

ResponseStructure:

{“message”:[result message],”success”:[flag],”value”:[object]}

message: Null for successful user password reset. In case of failure, error message to indicate reason of the failure. Refer troubleshooting section for possible error messages.

flag: true or false to indicate success or failure of the operation.

value: JSON object on successful password reset. Null in case the API call resulted into failure.

Object structure –

{

“userId”:[User Id of the registered user],

“password”:[Password in encrypted form]

}

  • On successful user password reset, userId returned in the response will be same as passed in request parameter.
  • password field will return an auto-generated password, in encrypted form, that should be used to logging in the POS system (standalone or integrated). [Refer initial content of Section 2 for decryption logic]
SampleRequest –

POST /api/apiUser/ResetPassword HTTP/1.1

Host: https://ipos.com

clientid: c352167b-2154-92cf-de08-08dd59868e1a

clientsecret: nhjd6kC67/w7ToOpSDDFrZe7sKsTcHMa04xWgbeC2Cs=

Content-Type: application/json

Cache-Control: no-cache

Postman-Token: 7ca65b65-db92-88ab-05b5-04d931dd6d8d

{UserId:”258″}

Response –

{“message”:null,”success”:true,”value”:{“userId”:”258″,”password”:”SCykEzN7DwxJkL9+Q59W+lLDS399xOefr9YN7RjfR4E=”}}

 

2.3. Unregister User

PurposeThis API is designed to deactivate an EMR/EHR employee from the Curative POS system. This can be used to simply remove access of the Curative POS system for an EMR/EHR employee. Unregistered users should not be allowed to perform any operations on the Curative POS system.

Upon receiving the unregister user API call with valid input data, the Curative POS system will mark the employee account as inactive. The response of the Curative POS system will be a success/failure flag when receiving the API call.

Once a user is successfully unregistered from the POS, EMR system should not allow the user to call any API or access any POS specific feature.

URL/api/apiUser/UnregisterUser

Request Type: POST

Request ParametersUserId: [string : 50-character max]

  • A unique id of the user to be unregistered. This should be EMR system’s internal unique ID used at the time of user registration.

All the parameters are required.

ResponseStructure:

{“message”:[result message],”success”:[flag],”value”:null}

message: Message to confirm success of the operation. In case of failure, error message to indicate reason of the failure.

flag: true or false to indicate success or failure of the operation.

value: Value will always be returned as null for the unregister API call.

SampleRequest –

POST /api/apiUser/UnregisterUser HTTP/1.1

Host: https://ipos.com

clientid: c352167b-2154-92cf-de08-08dd59868e1a

clientsecret: nhjd6kC67/w7ToOpSDDFrZe7sKsTcHMa04xWgbeC2Cs=

Content-Type: application/json

Cache-Control: no-cache

Postman-Token: 7ca65b65-db92-88ab-05b5-04d931dd6d8d

{UserId:”2585″}

Response –

{“message”:”User unregistered successfully.”,”success”:true,”value”:null}

2.4. Register Patient

PurposeThe register patient API is designed to register a patient in the EMR on the Curative POS system. If an employee is not registered through the integration, they will not be allowed to register a patient. It is required to register a patient prior to any product recommendations by a therapist.

Once the system receives the register patient API call, the Curative system will create a customer account based on the information populated on the EMR/EHR.  Whenever an employee completes a sale through the EMR/EHR, it will be linked to a customer account on the Curative POS system. This will allow you to still tag the patient to their transaction on the standalone site.

URL/api/apiPatient/RegisterPatient

Request Type: POST

Request ParametersFirstName: [string : 50-character max]

  • First name of the patient

LastName: [string : 50-character max]

  • Last name of the patient

Birthdate: [valid date string in ‘mm/dd/yyyy’ format]

  • Birth date of the patient

Email: [string : 100-character max : valid email address] – Optional parameter

  • Email address of the patient

PatientId: [string : 50-character max]

  • A unique id of the patient to be registered. This can be primary key of the EMR system for the patient.

UserEmail: [string : 100-character max : valid email address]

  • A valid email address of the registered user.

All the parameters are required except ‘Email’.

ResponseStructure:

{“message”:[result message],”success”:[flag],”value”:null}

message: Message to confirm success of the operation. In case of failure, error message to indicate reason of the failure.

flag: true or false to indicate success or failure of the operation.

value: Value will always be returned as null for the register patient API call.

SampleRequest –

POST /api/apiPatient/RegisterPatient HTTP/1.1

Host: https://ipos.com

clientid: c352167b-2154-92cf-de08-08dd59868e1a

clientsecret: nhjd6kC67/w7ToOpSDDFrZe7sKsTcHMa04xWgbeC2Cs=

Content-Type: application/json

Cache-Control: no-cache

Postman-Token: 4e8e270f-ad83-acd4-798e-6d504c8acdbf

{FirstName:”Micheal”,LastName:”Golub”,BirthDate:”01/01/1956″,Email:”micheal@golubworld.com”,PatientId:”2539″,UserEmail:”dyane.c@gmail.com”}

Response –

{“message”:”Patient registered successfully.”,”success”:true,”value”:null}

2.5 Open POS Cart

PurposeThe Open Cart API is designed to allow employees to open a cart through their EMR/EHR without navigating away from their site. This API will be available to all registered users to complete a sale or make product recommendations.

Upon receiving the API call with valid input data, the POS system will return an open cart linked with the patient’s appointment information. In case a walk-in customer wants to make a purchase, a cart will be available to be opened without patient linking a patient account.

URL/Account/OpenPOSCart

Request Type: GET

Request ParametersUserEmail: [string : 100-character max : valid email address]

  • A valid email address of the registered user for login purpose. This email should be same as the email used to register the user and should be passed in encrypted form. [Refer initial content of Section 2 for encryption logic]

Password: [string : 50-character max]

  • Password in encrypted form as provided when user is registered with the POS system. [Refer initial content of Section 2 for encryption logic]

ClientName: [string : 50-character max]

  • Client name as provided at the time of registering your system with Intelligent POS system. [Refer Section 1.1]

PatientId: [string : 50-character max] – Optional parameter

  • A unique id of the registered patient. This id should be same as the id supplied at the time of the patient’s registration.

ReferenceId: [string : 50-character max] – Optional parameter

  • A unique id to identify patient’s appointments. This can be a primary key of the EMR system for specific patient appointment. This should be the EMR system’s internal unique ID to identify current EMR object for which POS session is to be created.

In case only PatientId or ReferenceId is passed while calling the API, it will be ignored and the cart will be opened for retail sale, i.e. not linked with patient and/or appointment.

ResponseHTML view of the POS system will be returned as response for this API call.
SampleRequest –

POST /api/apiCart/OpenPOSCart HTTP/1.1

Host: https://ipos.com

clientid: c352167b-2154-92cf-de08-08dd59868e1a

clientsecret: nhjd6kC67/w7ToOpSDDFrZe7sKsTcHMa04xWgbeC2Cs=

Content-Type: application/json

Cache-Control: no-cache

Postman-Token: ccbc6fbf-dc8e-217c-633c-83c0ef057577

Parameter to open cart for patient’s appointment –

{UserEmail:” evy0wdY6WetbMWi9KAZJMIbO1wFbmkbu0YQy97I8NoL3cx5USYEglgJB59Yl1dfU”,Password:”zP2TzmWGstsTLEnfr3xRyif3dBrxQNptAr4zZgFTGCo=”,PatientId:”2576″,ReferenceId:”254786″}

Parameter for retail sale –

{UserEmail:” evy0wdY6WetbMWi9KAZJMIbO1wFbmkbu0YQy97I8NoL3cx5USYEglgJB59Yl1dfU”,Password:”zP2TzmWGstsTLEnfr3xRyif3dBrxQNptAr4zZgFTGCo=”}

2.6 Get Open Cart Products

PurposeThe get open cart products API is to inquire whether therapist has recommended products for any appointments listed on the EMR. If the inquiry finds recommended products on an appointment, the EMR/EHR system can provide the employee with an indication on the system.

The Curative POS system will search for a non-empty cart for specific appointment(s); if the API call encounters a cart with products, it will list the count of the products that were recommended.

URL/api/apiCart/GetOpenCartProducts

Request Type: POST

Request ParametersReferenceIds: [string]

  • An array of unique id to identify appointments. An id can be a primary key of the EMR system for specific patient appointment. These ids need to be unique among every appointment of the EMR system.

All the parameters are required.

ResponseStructure:

{“message”:[result message],”success”:[flag],”value”:[object]}

message: Null for successful user registration. In case of failure, error message to indicate reason of the failure. Refer troubleshooting section for possible error messages.

success: true or false to indicates success or failure

value: JSON object on successful operation. Null in case the API call resulted into failure.

Object array structure –

[

{

“referenceId”:[EMR system Appointment Id],

“productCount”:[Count of products recommended by therapist for specific appointment of the patient]

}

]

  • On successful result, productCont value greater than 0 indicates there is open cart for the specific appointment and products are recommended.
SampleRequest –

POST /api/apiCart/GetOpenCartProducts HTTP/1.1

Host: https://ipos.com

clientid: c352167b-2154-92cf-de08-08dd59868e1a

clientsecret: nhjd6kC67/w7ToOpSDDFrZe7sKsTcHMa04xWgbeC2Cs=

Content-Type: application/json

Cache-Control: no-cache

Postman-Token: ccbc6fbf-dc8e-217c-633c-83c0ef057577

{ReferenceIds:[‘12’,’45’,’234’]}

Response –

{“message”:null,”success”:”true”,”value”:[{“referenceId”:”12″,”productCount”:”4″},{“referenceId”:”45″,”productCount”:”2″},{“referenceId”:”234″,”productCount”:”0″}]}

 

3 Integration Test Environment

The Integration Test Environment (ITE) allows your Development team to test applications and process transactions using the Curative POS System APIs in a secure, no-cost environment. The ITE mimics the production environment. There are no license or setup fees, nor processing transaction fees accrued when using the ITE. Contact Curative POS System admin staff to apply for a test account. integration@curativepos.com

To test your integration to the Curative POS System API, use these URLs listed below:
https://demo.curativepos.com/api/apiUser/RegisterUser
https://demo.curativepos.com/api/apiUser/ResetPassword
https://demo.curativepos.com/api/apiUser/UnregisterUser
https://demo.curativepos.com/api/apiPatient/RegisterPatient
https://demo.curativepos.com/Account/OpenPOSCart
https://demo.curativepos.com/api/apiCart/GetOpenCartProducts
To transition your test account to a production account, replace the ITE URLs with these listed below:
https://login.curativepos.com/api/apiUser/RegisterUser
https://login.curativepos.com/api/apiUser/ResetPassword
https://login.curativepos.com/api/apiUser/UnregisterUser
https://login.curativepos.com/api/apiPatient/RegisterPatient
https:/login.curativepos.com/Account/OpenPOSCart
thttps://login.curativepos.com/api/apiCart/GetOpenCartProducts

4 Troubleshooting

This section list possible error messages you may receive in case the Intelligent POS System API call is not returned success, i.e. ‘success’ parameter value in the response structure is ‘false’.

4.1 Common Error Messages

Message: “1000:Client id and client secret parameters are missing in request parameter.”
Reason: You have not sent client id and/or client secret in your request header.
Message: “1001:Invalid client id and/or client secret in request header.”
Reason: You have sent incorrect client id and/or client secret in request header.
Message: “1002:Required parameter missing – <Parameter Name>.”
Reason: You have missed to pass one or more required parameter in request. Message will provide you name of the first required parameter where data is missing in request.
Message: “1003:Request parameter – <Parameter Name> – exceeds the allowed limit.”
Reason: Length of the data you have passed in request parameter exceed the allowed limit. You can refer the API documentation in section 2 to check the allowed maximum limit for each request parameter.
Message: “1004:Invalid email address.”
Reason: You have passed an invalid email address in the email specific requested parameter.

4.2 Register User

Message: “1011:Requested user is already registered.”
Reason: You have passed an email address and/or a user id that is already registered with the POS system. In such case, an active employee with the requested email address and/or linked with supplied user id already exists in the POS system.
Message: “1012:Invalid role name.”
Reason: You have passed a role name that is not one of the valid values the POS system expects to receive. You can refer the ‘Register User’ API documentation in section 2.1 to check the valid options for ‘RoleName’ request parameter.

4.3 Reset Password

Message: “1021:There is no registered user for the requested user id.”
Reason: You have passed a user id that is not registered in POS for your client.

4.4 Unregister User

Message: “1022:There is no registered user for the requested user id.”
Reason: You have passed a user id that is not registered in POS for your client.

4.5 Register Patient

Message: “1031:Invalid date parameter.”
Reason: You have passed an invalid date in the “Birthdate” request parameter.
Message: “1032:Requested patient is already registered.”
Reason: You have passed a patient id that is already registered with the POS system. In such case, an active customer linked with supplied patient id already exists in the POS system.

4.6 Open POS Cart

Message: “1041:You are not authorized to use integrated POS.”
Reason: Credentials you have passed to open POS cart are invalid.
Message: “1042:Patient is not registered with POS.”
Reason: You have passed a patient Id that is not registered with the POS system.

Integration Certification

Once you have completed your integration of Curative POS, the next step is to schedule a call with our IT Director for a quick Zoom call to walk through your integration with a screen share.

Assuming everything is integrated properly we’ll:

  • Certify the integration
  • Add your brand to our Integrated Partners web page.
  • We’ll then work with your team to create a video training course in the Curative POS Jumpstart Academy.

CONTACT US