Print Friendly

Overview

tuOtempO has a wide range of possibilities available based on the use of Webservices, Database Synchronization or the exchange of files. This article explains the different options.

Glossary of Frequently Used Terms

TERM CORRESPONDS TO
FUT Frequently Used Terms
tuOtempO Everything related to tuOtempO web application (database, servers, services, …)
Your Software Everything related to your corporate management application (ERP, HIS, CRM. …)

Table of Contents

A. Automatic communications with patients - [tuOtempO memo]

This section regards automatic communication based on events (for example, reservations, confirmations, cancellations, modifications, etc) or mass communication campaigns. Choose the solution which is most adapted to your way of working.

A.1 I’m able to set up a scheduled export of My Software‘s data - [Data Export]

A.1.1 Exporting Your Software‘s data

The batch export of the database should be set up periodically, taking into account the following criteria :

  • The anonymity of the patient data – ensure we only receive a telephone number or an email address
  • The frequency with which the data is updated – we recommend an export every 4 hours, to ensure information concerning appointments that have been changed or canceled via telephone is up to date
  • The time filter on the appointments, relative to the time of export – selecting for example only appointments between 72 hours ahead and 24 hours past. Past appointments will be used for feedback checks, future appointments will be used for reminders or cancellation notices.

The format recommended for the export is the following :

FIELD CORRESPONDS TO
[APP_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Appointment in Your Software (concatenation of all the fields that make up the primary key PK)
[APP_DATE] [nchar](10) NOT NULL Date of the Appointment (preferable format: dd/mm/yyyy)
[APP_START_TIME] [nchar](5) NULL Starting time (preferable format: hh:mm)
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline number
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number”[USER_EMAIL] [nvarchar](50) NULL Email
[RESOURCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Resource (for example, Doctor) in Your Software
[RESOURCE_NAME] [nvarchar](50) NOT NULL Name of the Resource
[RESOURCE_MOBILE_PHONE] [nvarchar](50) NULL Mobile of the Resource
[RESOURCE_EMAIL] [nvarchar](50) NULL Email of the Resource
[LOCATION_LID] [nvarchar](50) NULL ID of the location in Your Software
[LOCATION_NAME] [nvarchar](50) NULL Name of of the location in Your Software

The export should be made into any folder which tuOtempO can access via FTP. If you wish, you can ask for a free FTP folder from tuOtempO for the use of data exchanges.

A.1.2 Appointment Confirmation/Cancellation Option

When you send a communication, you may want to provide the patient with the opportunity to cancel or confirm the appointment and to send their reply via SMS, email or voice message. If you use this functionality it is necessary to manage the return of this information towards you or Your Software.

A.1.2.1 Providing cancellations file

tuOtempO will create an FTP folder with an archive containing the following characteristics :

FIELD CORRESPONDS TO
[APP_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Appointment in Your Software
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline number
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_EMAIL] [nvarchar](50) NULL Email
[RESOURCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Resource (for example, Doctor) in Your Software
[STATUS] [nvarchar](50) NOT NULL Status of the Appointment (PENDING, APPROVED, CANCELLED by USER, CANCELLED by ADMIN)

A.1.2.2 Providing mail notification

In this case you have simply to configure the communications in tuOtempO so as to activate email notification to the center on cancellations

A.2 I am able to create views in My Software‘s database - [tuOtempO Sincro]

Views provide the information needed for the communication services provided by tuOtempO.

A.2.1 The Views

Here are the views with which SINCRO, the component installed on your environment, links

  • The Doctors view (TT_RESOURCES)
  • The Appointments view (TT_RESERVATIONS)

This view enables enables the filtering of resources according to what needs to be transmitted.

FIELD CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Resource (for example, Doctor) in Your Software
[RESOURCE_FIRST_NAME] [nvarchar](50) NOT NULL First name of the Resource
[RESOURCE_SECOND_NAME] [nvarchar](50) NULL Family name of the Resource
[RESOURCE_MOBILE_PHONE] [nvarchar](50) NULL Mobile of the Resource
[RESOURCE_EMAIL] [nvarchar](50) NULL Email of the Resource
[LOCATION_LID] [nvarchar](50) NULL ID of the location in Your Software
[LOCATION_NAME] [nvarchar](50) NULL Name of of the location in Your Software
[WEB_ENABLED] [int](1) NULL Web enabled online (=1)
AVAILABILITIES_STEP [int](3) NULL Recommended interval between two availabilities
The Reservations View should be limited to reservations within a defined range, generally not older than a week (Date >= CURRENT_DATE() – 7)

FIELD CORRESPONDS TO
[APP_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Appointment in Your Software (concatenation of all the fields that make up the primary key PK)
[APP_DATE] [nchar](10) NOT NULL Date of the Appointment (preferable format: dd/mm/yyyy)
[APP_START_TIME] [nchar](5) NULL Starting time (preferable format: hh:mm)
[APP_END_TIME] [nchar](5) NULL End time (preferable format: hh:mm)
[USER_LID] [nvarchar](50) NULL ID of the Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO (only if possible saving this id in some field by the trigger of the temporary reservation table) – Only if using tuOtempO WEB
[USER_FIRST_NAME] [nvarchar](50) NULL First Name – For privacy, it is best left empty
[USER_SECOND_NAME] [nvarchar](50) NULL Second Name – for privacy, it is best left empty
[USER_THIRD_NAME] [nvarchar](50) NULL Third Name – for privacy, it is best left empty
[USER_ID_NUMBER] [nvarchar](50) NULL USER ID Number – for privacy, it is best left empty
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline – Only if using tuOtempO MEMO or SURVEY
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number – Only if using both tuOtempO MEMO and SURVEY
[USER_WORK_PHONE] [nvarchar](50) NULL Work phone – Only if using tuOtempO MEMO or SURVEY
[USER_EMAIL] [nvarchar](50) NULL Email – Only if using tuOtempO MEMO or SURVEY
[USER_PRIVACY][nchar](1) NULL Acceptation of privacy regulations – Only if using tuOtempO MEMO or SURVEY
[COMMUNICATION_PREFERENCES][nchar](3) NULL Communication preferences, BYTEWISE string corresponding to three options: SMS, EMAIL, TEL. FIX (example: 101 => SMS Yes, Email No, Tel Fix Yes)
[USER_DATE_OF_BIRTH] [nchar](10) NULL Date of Birth (preferable format: dd/mm/yyyy) – Only if using tuOtempO SURVEY
[USER_GENDER] [nchar](10) NULL Gender (M, F) – Only if using tuOtempO SURVEY
[USER_ZIP_CODE] [nchar](10) NULL Zip Code – Only if using tuOtempO SURVEY
[USER_LANGUAGE] [nchar](10) NULL Language for sending communications
[NOTES] [nvarchar](500) NULL Notes
[RESOURCE_LID] [nvarchar](50) NOT NULL ID of the Resource (ex. Doctor) in Your Software
[ACTIVITY_LID] [nvarchar](50) NULL ID Activity in Your Software – Only if using tuOtempO WEB
[INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software – if using tuOtempO WEB
[LOCATION_LID] [nvarchar](50) NULL ID Location in Your Software – Only if using tuOtempO WEB
[STATUS] [nvarchar](50) NULL Status of the Appointment (PENDING, APPROVED, CANCELLED by USER, CANCELLED by ADMIN) – Only if using tuOtempO WEB
[APP_OWNER_LID] [nvarchar](50) NULL ID in Your Software of the user who created the appointment – Only if using tuOtempO WEB
[APP_OWNER_TID] [nvarchar](50) NULL ID of the tuOtempO user who created the appointment – Only if using tuOtempO WEB
[APP_OWNER_NAME] [nvarchar](50) NULL Name of of the tuOtempO user who created the appointment – Only if using tuOtempO WEB

In the circumstances in which the dates are in a proprietary format (for example, the date can sometimes be a decimal number) it is necessary that the date view be transformed into a standard format. In case of doubt, it is recommended to use the type STRING.

A.2.2 Privacy Policy

To conform with international privacy policy tuOtempO:

  • will only read, using the SINCRO Component, data presented via the views (a user with restricted privileges should be created in Your Software‘ database)
  • will send the data in anonymous format ( the name of the patient should not be transmitted)
  • won’t treat sensitive information (in the views, the activity should not be present)

A.2.3 Appointment Confirmation/Cancellation Option

tuOtempO MEMO. When you send a communication, you can give the patient the opportunity to cancel or confirm the appointment and send their reply via SMS, email or voice message. If you use this service it is necessary to manage the return of the information.

Table for cancellations TT_DELETE_RESERVATION

tuOtempO writes into the data table the data of the appointments which patients have canceled via SMS, EMAIL or telephone. The writing to this table should launch a trigger (see example) which will delete (or change the status) of the appointment in your table. This table will only be used if you use tuOtempO MEMO communications. If you also use online booking, all the cancellations will be carried over to the exchange tableTT_RESERVATIONS_TMP (see Section B of the document).

FIELD CORRESPONDS TO
[APP_TMP_ID] [nvarchar](10) NOT NULL ID System (do not use)
[APP_LID] [nvarchar](50) NULL ID Appointment in Your Software
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_EMAIL] [nvarchar](50) NULL Email
[APP_STATUS] [nvarchar](4000) NULL Output of the trigger
[STATUS_TRIGGER] [nvarchar](4000) NULL Output of the trigger
[INSERT_TIME] [datetime] NOT NULL Time at which the cancellation was registered in the table

A.3 I prefer to exchange informations calling some Webservices - [tuOtempO SOAP]

A.3.1 Sending appointments

You can call tuOtempO Webservices to provide the data relative to patients and appointments, then tuOtempO will manage the communications.
You will use: updateReservations() to provide user’s and appointment’s data.
See details in tuOtempO Webservices – Soap Edition

A.3.2 Appointment Confirmation/Cancellation Option

When you send a communication, you can give the patient the opportunity to cancel or confirm the appointment and to send the reply via SMS, email or voice message. If you want to use this feature it is necessary to manage the return of the information.

You will use: getReservations() to grab information about the current appointments’ status.

See details in tuOtempO Webservices – Soap Edition

A.4 I can let my own Webservices be called by tuOtempO [tuOtempO WSClient]

A.4.1 Retrieving appointments

You will have to build up or publish a Webservice which will be consumed by tuOtempO. This Webservice should expose the following methods:

SearchAppointments()
The Webservice should be called by tuOtempO with these parameters

VALUE (NULL = optional) CORRESPONDS TO
[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software.
[START_DATE] [nchar](10) NULL Start date of the search interval
[END_DATE] [nchar](10) NULL End date of the search interval
[RESOURCE_LID] [nvarchar](50) NULL ID Resource (ex. Doctor) in Your Software
[LAST_REQUEST_TIMESTAMP] [datetime] NULL Date and time of the last call of SearchAppointments (permits to get only the appointments that have been added or modified after the last call)

The Webservice should return to tuOtempO the following information:

VALUE (NULL = optional) CORRESPONDS TO
[APP_LID] [nchar](10) NOT NULL ID Appointment in Your Software
[STATUS] [nchar](10) NOT NULL Status of the appointment (Confirmed, Cancelled)
[APP_DATE] [nchar](10) NOT NULL Date of the appointment
[APP_START_TIME] [nchar](5) NOT NULL Start time
[APP_END_TIME] [nchar](5) NULL End time
[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software.
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_EMAIL] [nvarchar](50) NULL Email
[USER_INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software
[USER_PRIVACY] [nvarchar](1) NULL Acceptation of privacy regulations (1=OK/0=NOT ACCEPTED)
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
“*[ACTIVITY_NAME] [nvarchar](50) NULL” Name of the activity in Your Software
“*[ACTIVITY_GROUP_LID] [nvarchar](50) NULL” ID Group of services in Your Software
*[ACTIVITY_GROUP_NAME] [nvarchar](50) NULL Name of group of services
[RESOURCE_LID] [nvarchar](50) NOT NULL ID Resource (ex. Doctor) in Your Software
*[RESOURCE_FIRST_NAME] [nvarchar](50) NULL First name of the resource
*[RESOURCE_SECOND_NAME] [nvarchar](50) NULL Second name of the resource
Note: KeyEntities dependence(*) These field should be NOT NULL if you want notifications to patients to contain this information.

A.4.2 Appointment Confirmation/Cancellation Option

When you send a communication, you can give the patient the opportunity to cancel or confirm the appointment and to send the reply via SMS, email or voice message. If you want to use this feature it is necessary to manage the return of the information. In this case your webservice needs to expose the following webservice:

CancelAppointment()
The Webservice should be called by tuOtempO with these parameters

VALUE (NULL = optional) CORRESPONDS TO
[APP_LID] [nchar](10) NOT NULL ID Appointment in Your Software
[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software.
The Webservice, should return to tuOtempO the following data

FIELD CORRESPONDS TO
[DELETE_RESULT] [nvarchar](50) NULL OK / ERROR
[RESULT] [nchar](10) NOT NULL OK/ERROR
[APP_LID] [nvarchar](50) NULL ID Appointment in Your Software (concatenation of all the fields that compose the primary key PK) OR Error Message

A.5 Using tuOtempO as pure gateway for messages - [tuOtempO Gateway]

A.5.1 Sending Messages via tuOtempO

tuOtempO can be used as a gateway SMS, e-mail, voice or fax. The method most to be used is the Webservice updateMessages(). It is also possible to establish an HTTPS protocol.

See details in tuOtempO Webservices – Soap Edition

A.5.2 Retrieving message’s informations

When using tuOtempO as communication gateway you could need to know some more informations about your message, for example sending date and time and if the message has been successfully sent. The method in this case is the Webservice searchMessages(). Note that searching by the “legacyid” filter allow you easily to get exactly the message you are looking for, searching by “to”, for example, will return all the messages sent to that address.

See details in tuOtempO Webservices – Soap Edition

A.6 I’m only interested in communication campaigns - [Bulk Messages]

In this case you can directly paste the addresses of the recipients in tuOtempO multiple messages management interface or import in tuOtempO the patients from a file (ex. excel) and select the addressees of your campaign using tuOtempO filtering functions.

B. Management of Online Appointments - [tuOtempO Web]

To enable reservation online it is necessary to activate a synchronized communication between Your Software and tuOtempO by choosing one of the available procedures.

B.1 I can create views and temporary tables in My Software‘s database - [tuOtempO Sincro]

The views allows tuOtempO to receive the information needed to provide the user with real time information.

  • The Doctors View (TT_RESOURCES).

    This View permits the filtering of resources (Doctors) and the display of real-time information.

  • The Activities View (TT_ACTIVITIES)

    The View permits the filtering of activities (Reservable treatments).

  • The Insurance View ( TT_INSURANCES optional)

    The View permits the display and filtering of the available Insurance plans.

  • The Doctor-Activity Relationship View (TT_RESOURCES_ACTIVITIES)

    This View permits the correct association between Doctors and Treatments.

  • The Insurance-Activity Relationship View (TT_INSURANCES_ACTIVITIES optional)

    This View permits the correct association between Available Insurances and reservable Treatments.

  • The Doctor-Insurance Relationship View (TT_INSURANCES_RESOURCES optional)

    This View permits the correct association between Doctors and available Insurances.

  • The Availability View (TT_AVAILABILITIES)

    This View permits the display and filtering of the Doctor’s reservable time slots

  • The Services-Availabilities Relationship View (TT_ACTIVITIES_AVAILABILITIES optional)

    This view permits to associate doctor’s availability Time slots to certain treatments

  • The Appointments View (TT_RESERVATIONS)

    This view permits to display, filter and  update informations about reserved appointments

The presence of the default NOT NULL indicates that the FIELD is obligatory.

The presence of the word UNIQUE indicates that the FIELD does not allow duplicate values.

FIELD CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID Resource (ex. Doctor) in Your Software
[RESOURCE_FIRST_NAME] [nvarchar](50) NOT NULL First Name of the resource
[RESOURCE_SECOND_NAME] [nvarchar](50) NULL Second Name of the resource
[RESOURCE_MOBILE_PHONE] [nvarchar](50) NULL Mobile of the resource
[RESOURCE_EMAIL] [nvarchar](50) NULL Email of the resource
[LOCATION_LID] [nvarchar](50) NULL ID Location in Your Software
[LOCATION_NAME] [nvarchar](50) NULL Name of of the location in Your Software
[WEB_ENABLED] [int](1) NULL Web enabled online(=1)
AVAILABILITIES_STEP [int](3) NULL Recommended interval between two availabilities
Warning Your doctors could have different properties in his associations with other entities depending on the location. For example, referring to the specific doctor D1, in location L1 his Working time is different from his working time in location L2. In this case it’s recommended to create two different resources with resource_lid D1_L1 and D1_L2 so as to correctly define different working times  in TT_AVAILABILITIES view.
FIELD CORRESPONDS TO
[ACTIVITY_LID] [nvarchar](50) NOT NULL, UNIQUE ID Activity in Your Software
[ACTIVITY_NAME] [nvarchar](50) NOT NULL Name of Activity in Your Software
[ACTIVITY_GROUP_NAME] [nvarchar](50) NULL Name of of the Group of Activities
[ACTIVITY_GROUP_LID] [nvarchar](50) NULL ID of the Group of Activities in Your Software
[ACTIVITY_DURATION] [int] NULL Duration of the activity in minutes
[ACTIVITY_PRICE] [float] NULL Price of the activity
[WEB_ENABLED] [int](1) NULL Web enabled (=1)
FIELD CORRESPONDS TO
[INSURANCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID Insurance in Your Software
[INSURANCE_NAME] [nvarchar](50) NOT NULL Insurance Name in Your Software
[WEB_ENABLED] [int](1) NULL Web enabled online(=1)

FIELD CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NOT NULL ID Resource (ex. Doctor) in Your Software
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
[ACTIVITY_DURATION] [int] NULL Duration of the activity in minutes related to the doctor
[ACTIVITY_PRICE] [float] NULL Price of the activity related to the doctor
FIELD CORRESPONDS TO
[INSURANCE_LID] [nvarchar](50) NOT NULL ID Insurance in Your Software
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
[ACTIVITY_PRICE] [float] NULL Price of the activity related to the insurance
FIELD CORRESPONDS TO
[INSURANCE_LID] [nvarchar](50) NOT NULL ID Insurance in Your Software
[RESOURCE_LID] [nvarchar](50) NOT NULL ID Resource (ex. Doctor) in Your Software
FIELD CORRESPONDS TO
[AVAILABILITY_LID] [nvarchar](50) NOT NULL, UNIQUE ID Availability (interval you can reserve). If the availability does not provide an ID you can use a unique combination of its attributes (ie.: resource_lid+start_date+start_time)
[R_WORKING_DAY] [nvarchar](1) NULL Day of the week.A number between 0 = Sunday and 6 = Saturday
[R_START_TIME] [nvarchar](5) NOT NULL Starting time of the availability on the day (preferable format: hh:mm)
[R_END_TIME] [nvarchar](5) NOT NULL End time of the availability on the day (preferable format: hh:mm)
[R_START_DAY] [nvarchar](10) NULL Date of the start of the availability (preferable format: dd/mm/yyyy)
[R_END_DAY] [nvarchar](10) NULL Date of the end of the availability (preferable format: dd/mm/yyyy)
[RESOURCE_LID] [nvarchar](50) NOT NULL, ID Resource (ex. Doctor) in Your Software
[LOCATION_LID] [nvarchar](50) NULL ID Location in Your Software

The Availability View should be limited to availabilities in the future (R_END_DAY >= CURRENT_DATE())

FIELD CORRESPONDS TO
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
[AVAILABILITY_LID] [nvarchar](50) NOT NULL ID Availability (interval between reservations)
FIELD CORRESPONDS TO
[APP_LID] [nvarchar](50) NOT NULL, UNIQUE ID of the Appointment in Your Software (concatenation of all the fields that make up the primary key PK)
[APP_DATE] [nvarchar](10) NOT NULL Date of the Appointment (preferable format: dd/mm/yyyy)
[APP_TID][nvarchar](50) NULL ID Appointment in tuOtempO (only if possible saving this id in some field by the trigger of the temporary reservation table) – Only if using tuOtempO WEB
[APP_START_TIME] [nvarchar](5) NULL Starting time (preferable format: hh:mm)
[APP_END_TIME] [nvarchar](5) NULL End time (preferable format: hh:mm)
[USER_LID] [nvarchar](50) NULL ID of the Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO (only if possible saving this id in some field by the trigger of the temporary reservation table) – Only if using tuOtempO WEB
[USER_FIRST_NAME] [nvarchar](50) NULL First Name – For privacy, it is best left empty
[USER_SECOND_NAME] [nvarchar](50) NULL Second Name – for privacy, it is best left empty
[USER_THIRD_NAME] [nvarchar](50) NULL Third Name – for privacy, it is best left empty
[USER_ID_NUMBER] [nvarchar](50) NULL USER ID Number – for privacy, it is best left empty
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline – Only if using tuOtempO MEMO or SURVEY
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number – Only if using both tuOtempO MEMO and SURVEY
[USER_WORK_PHONE] [nvarchar](50) NULL Work phone – Only if using tuOtempO MEMO or SURVEY
[USER_EMAIL] [nvarchar](50) NULL Email – Only if using tuOtempO MEMO or SURVEY
[USER_PRIVACY][nvarchar](1) NULL Acceptation of privacy regulations – Only if using tuOtempO MEMO or SURVEY
[COMMUNICATION_PREFERENCES][nvarchar](3) NULL Communication preferences, BYTEWISE string corresponding to three options: SMS, EMAIL, TEL. FIX (example: 101 => SMS Yes, Email No, Tel Fix Yes)
[USER_DATE_OF_BIRTH] [nvarchar](10) NULL Date of Birth (preferable format: dd/mm/yyyy) – Only if using tuOtempO SURVEY
[USER_GENDER] [nvarchar](10) NULL Gender (M, F) – Only if using tuOtempO SURVEY
[USER_ZIP_CODE] [nvarchar](10) NULL Zip Code – Only if using tuOtempO SURVEY
[USER_LANGUAGE] [nvarchar](10) NULL Language for sending communications
[NOTES] [nvarchar](500) NULL Notes
[RESOURCE_LID] [nvarchar](50) NOT NULL ID of the Resource (ex. Doctor) in Your Software
[ACTIVITY_LID] [nvarchar](50) NULL ID Activity in Your Software – Only if using tuOtempO WEB
[INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software – if using tuOtempO WEB
[LOCATION_LID] [nvarchar](50) NULL ID Location in Your Software – Only if using tuOtempO WEB
[STATUS] [nvarchar](50) NULL Status of the Appointment (PENDING, APPROVED, CANCELLED by USER, CANCELLED by ADMIN) – Only if using tuOtempO WEB
[APP_OWNER_LID] [nvarchar](50) NULL ID in Your Software of the user who created the appointment – Only if using tuOtempO WEB
[APP_OWNER_TID] [nvarchar](50) NULL ID of the tuOtempO user who created the appointment – Only if using tuOtempO WEB
[APP_OWNER_NAME] [nvarchar](50) NULL Name of of the tuOtempO user who created the appointment – Only if using tuOtempO WEB

Notes.

1. Date Range. The Reservations view should be limited to appointments within a defined range, generally not older than a week (Date >= CURRENT_DATE() – 7)

2. Date Format. In the circumstances in which the dates are in a proprietary format (for example, the date can sometimes be a decimal number) it is necessary that in the view the date are transformed into a standard format. In case of doubt, it is recommended to use the type STRING.

The use of Views enables the filtering of entities which tuOtempO needs to use in function of the criteria decided in the analysis phase (for example, not to share data concerning a specific medical speciality). This action is not absolutely necessary for tuOtempO to be able at any moment to determine what is and what is not reservable.

Respect of Privacy

You can create a user who only has permissions to read the views and write to the supplementary tables. tuOtempO SINCRO will use exclusively this user and in this way will not be able to read private sensitive data. All the information in the views are anonymous, there are no associations with data identifying the patient.

Temporary Tables give tuOtempO the possibility to write information gathered online :

  • The data of the patient
  • An appointment which needs to be created or canceled
Temporary Reservation Table (TT_RESERVATIONS_TMP)

This table writes into Your Software‘s database the data collected online by tuOtempO. Writing to the table should activate a Trigger responsible for updating or adding information in the appointments table (see example). In the case of a new appointment, the field [APP_LID] will be empty and the value APP_ACTION will be ADD. If the Appointment has been modified or canceled, the field [APP_LID] will contain the id of the appointment and APP_ACTION will be UPDATE or DELETE

When tuOtempO writes data of a patient who has just signed up online, it triggers a check as well to see if the patient is present in Your Software‘s database. If so it will write your patient identifier [USER_LID]. If not present, the trigger will insert a new patient and write your identification number [USER_LID] once it has been generated. Then, as the patient has been identified or created, the trigger will perform all the actions needed to create (or update or delete) his reservation on Your Software‘s database. This will must cause a new reservation appearing (or changing or desappearing) in TT_RESERVATIONS view and permitting user confirmation on tuOtempO.

Note : Duplicate ManagementThe trigger will execute a query permitting the identification of a duplicate patient on the basis of the data present in the support table. If an Operator manually merges two duplicate patients in Your Software it is important that the data relative to the online registration (usually phone number or email) is conserved, otherwise tuOtempO is not capable of identifying with whom the fusion has been made and the associations with their reservations will be lost.
Note : Strong MatchingIf Your Software’s tables allow to save tuOtempO’s id (APP_TID for reservations and USER_TID for patients) it will be possible to have stronger matching criterions when the reservation gets back by the view TT_RESERVATIONS simply putting these ids as APP_TID and USER_TID in the view. In this case it will not be necessary to preserve the data relative to the online registration when merging patients but simply preserve tuOtempO’s id.
FIELD CORRESPONDS TO
[APP_TMP_ID] [nvarchar](10) NOT NULL, ID System (do not use)
[APP_LID] [nvarchar](50) NULL, ID Appointment in Your Software
[APP_TID] [nvarchar](50) NOT NULL ID Appointment in tuOtempO
[APP_ACTION] [nchar](10) NOT NULL Action (add, update, delete)
[APP_DATE] [nchar](10) NOT NULL Date of the appointment
[APP_START_TIME] [nchar](5) NOT NULL Starting time
[APP_END_TIME] [nchar](5) NULL End time
[USER_LID] [nvarchar](50) NULL ID Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO
[USER_FIRST_NAME] [nvarchar](50) NULL First Name
[USER_SECOND_NAME] [nvarchar](50) NULL Second Name
[USER_THIRD_NAME] [nvarchar](50) NULL Third Name
[USER_ID_NUMBER] [nvarchar](50) NULL ID Number
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_EMAIL] [nvarchar](50) NULL Email
[USER_DATE_OF_BIRTH] [nchar](10) NULL Date of Birth
[USER_GENDER] [nchar](10) NULL Gender (M, F)
[USER_ZIP_CODE] [nchar](10) NULL Zip Code
[USER_WORK_PHONE [nvarchar](50) NULL] Work Number
[USER_NOTES] [nvarchar](500) NULL Notes
[USER_LANGUAGE] [nvarchar](10) NULL Language of the patient
[RESOURCE_LID] [nvarchar](50) NOT NULL ID Resource (ex. Doctor) in Your Software
[ACTIVITY_LID] [nvarchar](50) NULL ID Activity in Your Software
[INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software
[LOCATION_LID] [nvarchar](50) NULL ID Location in Your Software
[STATUS] [nvarchar](50) NULL Status of the appointment
[NOTES] [nvarchar] (500) NULL Notes concerning the appointment
[APP_OWNER_LID] [nvarchar](50) NULL ID in Your Software of the user who created the appointment
[APP_OWNER_TID] [nvarchar](50) NULL ID of the tuOtempO user who created the appointment
[APP_OWNER_NAME] [nvarchar](50) NULL Name of the tuOtempO user who created the patient
[STATUS_TRIGGER] [nvarchar](4000) NULL Output of the trigger
[INSERT_TIME] [datetime] NOT NULL Time at which the appointment was registered in the table
[APP_CUSTOM_0] [nvarchar](500) NULL Available for use with the Trigger
[APP_CUSTOM_1] [nvarchar](500) NULL Available for use with the Trigger
[APP_CUSTOM_2] [nvarchar](500) NULL Available for use with the Trigger
[APP_CUSTOM_3] [nvarchar](500) NULL Available for use with the Trigger
[APP_CUSTOM_4] [nvarchar](500) NULL Available for use with the Trigger
tuOtempO SINCRO and the security of Your Software‘s data

The reading of the Views and the writing to the support tables will be carried out by tuOtempO SINCRO, software built around .NET which will be installed on your Windows operating system and which have access via ODBC to Your Software‘s database. tuOtempO SINCRO has only two authorized external connections : one periodic connection with a fixed IP which replies to the Webservices of tuOtempO and the other a socket. The connection with the Socket server permits tuOtempO to notify the sincro when there is any new event (for example an Appointment). The Synchroniser establishes a rapid connection with tuOtempO and writes the novelty in the support tableTT_RESERVATIONS_TMP which launches the triggers. In this way tuOtempO synchronizes the online base with the local base without the local base ever being accessed from the exterior.

Resume of the requirements for integration
  1. Preparation of the views and the support tables
  2. Creation of a user with permissions and access restricted to the views
  3. Access via Logmein or Teamviewer to a server in order to permit the installation and configuration of the SINCRO
  4. Configuration of the Firewall to permit the connection with the SocketServer (socket.tuotempo.com:9000) and to call the Webservices (app.tuotempo.com:80) of tuOtempO
Warning. MS Access database

If the database is Microsoft Access, it is not possible to use Triggers to write to temporary database tables. In this case there are two alternatives.

MS Access : The patients and the appointments are contained in a single table.

If the tables corresponding to the entity PATIENT and APPOINTMENTS are located in the same access database and each entity don’t require more than one table, the SINCRO will be able to write directly to these tables. In this case, each change in these tables should be notified to tuOtempO.

MS Access : The patients and the appointments are in several tables

In this case it is necessary to connect the Access DB with an SQLSERVER to write to the temporary tables and enabling the activation of the TRIGGER.

B.2 I’m able to publish my own Webservice and let tuOtempO call it - [tuOtempO WSClient]

The synchronization with Webservices is achieved in two phases:

B.2.1 Exchange of information which doesn’t change frequently (for instance: a maximum of once a day).

In the category are included for example:

  • Prices or special tariffs
  • Service catalogs
  • Locations
  • Resources (Doctors, etc.)

and all the relationships between these entities (for example, “which services and prices does a Doctor offer for a particular insurance”).

B.2.1.1. Via views of Your Software‘s database, with the work of tuOtempO SINCRO

See B1 above, generally consider only these views:

TT_RESOURCES

TT_ACTIVITIES

TT_INSURANCES

TT_RESOURCES_ACTIVITIES

TT_INSURANCES_ACTIVITIES

TT_INSURANCES_RESOURCES.

B.2.1.2 with 3 Webservice which tuOtempO calls periodically to update its databse upon any changes in Your Software

To let tuOtempO retrieve the entities which should be offered for the online booking you should publish the following  webservices: 

getResources()

This Webservice allows the retrieval of the Doctors which an appointment can be reserved with.

The Webservice should be called by tuOtempO with these parameters

PARAMETER (Bold = must be implemented) CORRESPONDS TO
[CENTER_LID] [nvarchar](50) NULL ID of the Center in Your Software. 
The Webservice should return to tuOtempO the following information:

VALUE (NULL = optional) CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID Resource (ex. Doctor) in Your Software
[RESOURCE_FIRST_NAME] [nvarchar](50) NOT NULL First Name of the resource
[RESOURCE_SECOND_NAME] [nvarchar](50) NULL Second Name of the resource
[RESOURCE_MOBILE_PHONE] [nvarchar](50) NULL Mobile of the resource
[RESOURCE_EMAIL] [nvarchar](50) NULL Email of the resource
[LOCATION_LID] [nvarchar](50) NULL ID Location in Your Software
[LOCATION_NAME] [nvarchar](50) NULL Name of of the location in Your Software
[WEB_ENABLED] [int](1) NULL Web enabled online(=1)
AVAILABILITIES_STEP [int](3) NULL Recommended interval between two availabilities


getActivities()

This Webservice allows the retrieval of the Treatments offered by the Center and can be filtered on the Doctor.

The Webservice should be called by tuOtempO with these parameters

PARAMETER (Bold = must be implemented) CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NULL ID of the Doctor in Your Software. Can be left empty if all activities are to be retrieved.
The Webservice should return to tuOtempO the following information:

VALUE (NULL = optional) CORRESPONDS TO
[ACTIVITY_LID] [nvarchar](50) NOT NULL, UNIQUE ID Activity in Your Software
[ACTIVITY_NAME] [nvarchar](50) NOT NULL Name of Activity in Your Software
[ACTIVITY_GROUP_NAME] [nvarchar](50) NULL Name of of the Group of Activities
[ACTIVITY_GROUP_LID] [nvarchar](50) NULL ID of the Group of Activities in Your Software
[ACTIVITY_DURATION] [int] NULL Duration of the activity in minutes
[ACTIVITY_PRICE] [float] NULL Price of the activity
[WEB_ENABLED] [int](1) NULL Web enabled (=1)


getInsurances()

This Webservice allows the retrieval of the Insurances/pricelists to which Doctors or Treatments can be associated.

The Webservice should be called by tuOtempO with these parameters

PARAMETER (Bold = must be implemented) CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NULL ID of the Doctor in Your Software. Should be left empty if no relation  between insurances and Doctors exists in Your Software.
[ACTIVITY_LID] [nvarchar](50) NULL ID of the Treatment in Your Software. Should be left empty if no relation  between insurances and treatments exists in Your Software.
Insurances’ relationsInsurances use to be associated with either Doctors or treatments but usually not with both, so you should implement the input parameter which represents the correct architecture in Your Software’s database
The Webservice should return to tuOtempO the following information:

VALUE (NULL = optional) CORRESPONDS TO
[INSURANCE_LID] [nvarchar](50) NOT NULL, UNIQUE ID Insurance in Your Software
[INSURANCE_NAME] [nvarchar](50) NOT NULL Insurance Name in Your Software
[ACTIVITY_PRICE] [float] NULL Price of the treatment related to this insurance (not empty if ACTIVITY_LID has been specified as an argument)
[WEB_ENABLED] [int](1) NULL Web enabled online(=1)

B.2.1.3 With an exported archive sent to an FTP folder

A simple way of exchanging information is to extract it from the database and write it once or twice a day to an FTP folder accessible from tuOtempO. If you wish, you can ask for a free FTP folder from tuOtempO for the use of data exchanges.

The file should contain the following data in the order given.

ID Insurance | Insurance Name | ID Group | Name of Group | ID Activity | Name of Activity | Price | Duration | ID Location | Name of Location | ID Resource | Name of Resource |

The price of the activity is relative to the resource and if it is present, to the insurance. The format which is recommended is TXT.

This file contains all the information necessary for the application administrators to configure the activity (for example the list of services to show online) without needing to develop Webservices in the short term. It is for this reason that it is recommended to prepare this data file as a first priority before preparing Webservices.

B.2.2 Exchange of information which changes frequently

In this case, you will have to make the Webservices (either SOAP or Rest) capable being ccalled by tuOtempO. Below we present the essential set of methods which this webservice should implement:

searchAvailabilities()

This Webservice allows the retrieval of the Doctor’s (or the Treatment’s) reservable time slots.

The Webservice should be called by tuOtempO with these parameters

PARAMETER (Bold = must be implemented) CORRESPONDS TO
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software. Can be empty if activities have all the same durations.
[AVA_START_DAY] [nvarchar](10)  NULL Availability search starting day. Defaults to TODAY
[AVA_END_DAY] [nvarchar](10) NULL Availability search ending day. Defaults to AVA_START_DAY + 1 week
[AVA_START_TIME] [nvarchar](5) NULL Starting time of the availability search on AVA_START_DAY. Defaults to 00:00
[AVA_END_TIME] [nvarchar](5) NULL End time of the availability search on AVA_END_DAY
[AVA_MIN_TIME] [nvarchar](5) NULL time slot beginning
[AVA_MAX_TIME] [nvarchar](5) NULL time slot ending
[AVA_RESULTS_NUMBER] [nvarchar](5) NOT NULL Quantity of availabilities to return
[RESOURCE_LID] [nvarchar](50) NULL ID Resource (ex. Doctor) in Your Software. If NULL then returns availabilities for all doctors
[LOCATION_LID] [nvarchar](50) NULL ID Location (ex. establishment) in Your Software. If NULL then returns availabilities for all locations
[INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software
The Webservice should return to tuOtempO the following information:

VALUE (NULL = optional) CORRESPONDS TO
[RESOURCE_LID] [nvarchar](50) NOT NULL ID Resource (ex. Doctor) in Your Software
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
[LOCATION_LID] [nvarchar](50) NULL ID Location (ex. establishment) in Your Software
[INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software
[AVA_DATE] [nvarchar](10) NOT NULL Availability date (preferred format dd/mm/yyyy)
[AVA_START_TIME] [nvarchar](5) NOT NULL Starting time of the availability on the day
[AVAILABILITY_LID] [nvarchar](50) NULL ID Availability (intervals between reservable slots)
[AVA_END_TIME] [nvarchar](5) NULL En time of the availability on the day
[ACTIVITY_PRICE] [nvarchar](50) NULL Price of the activity


addAppointment()

This webservice allow the reservation of a new appointment.

Patients Synchronization Pattern

It’s important to point out that this Webservice should follow one of two possible patterns for dealing with the Patients synchronization between tuOtempO and Your Software. The choice consist in using:

  • the patientID in tuOtempO (USER_TID), or
  • the patientID in Your Software (USER_LID) 

as the patient’s mapping key between the two environments.

The use of the USER_TID implies that you are able to store and link this data to your patients in your database but as a major beefit it allows a better control over the matching between the patient in tuOtempO and the patient in Your Software, especially in case of manual merging of patients in Your Software.

The use of the USER_LID on the other hand makes tuOtempO responsible of dealing with patients’ duplications and merging allowing a lower level of precision.

VALUE (NULL = optional) CORRESPONDS TO
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
[RESOURCE_LID] [nvarchar](50) NULL ID Resource (ex. Doctor) in Your Software
**[USER_TID] [nvarchar](50) NOT NULL ID Patient in tuOtempO. Should be used if you can store this information in Your Software‘ database
**[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software. Not available for new patients. Should be used when it’s not possible to store USER_TID in Your Software‘ database
[USER_FIRST_NAME] [nvarchar](50) NULL First Name
[USER_SECOND_NAME] [nvarchar](50) NULL Second Name
[USER_THIRD_NAME] [nvarchar](50) NULL Third Name
[USER_GENDER] [nchar](10) NULL Gender (M, F)
[USER_DATE_OF_BIRTH] [nchar](10) NULL Date of birth
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline
[USER_EMAIL] [nvarchar](50) NULL Email
[USER_ID_NUMBER] [nvarchar](50) NULL User ID Number
***[APP_DATE] [nchar](10) NOT NULL Date of the appointment
***[APP_START_TIME] [nchar](5) NOT NULL Starting time
***[AVAILABILITY_LID] [nvarchar](50) NOT NULL ID Availability in Your Software, previously returned by the SearchAvailability
[INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software
Note: Patient ID Management** USER_TID and USER_LID are alternative to each other. You should use only one of them.
Note: Availability ID*** AVAILABILITY_LID is alternative to APP_DATE + APP_START_TIME.
VALUE (NULL = optional) CORRESPONDS TO
[ADD_RESULT] [nvarchar](50) NOT NULL OK / ERROR
[ERROR_MESSAGE] [nvarchar](500) NULL Error Message
[APP_LID] [nvarchar](50) NULL ID Appointment in Your Software (concatenation of all the fields that make up the primary key PK) OR NULL in case of error
**[USER_LID] [nvarchar](50) NULL ID Patient in Your Software
Note: Patient ID Management (**) this field should be present only in case of USER_LID pattern. In this case:

  • New Patient. In the case in which a reservation comes from a new patient who registers for the first time online, your Webservice should manage the insertion of the patient in Your Software’s database using the data which tuOtempO has sent. If the patient isn’t present in Your Software’s database, your Webservice should insert them and return the new ID (USER_LID) assigned following the insertion of the appointment.
  • Old Patient. If the patient is already present, the Webservice will return an ID that already exists. The next time that the patient reserves online Online, tuOtempO will send to the Webservice the Patient ID in Your Software. If this patient ID is no longer present (for example because they have been deleted manually) your Software’s Webservice should carry out a search as if it were a new patient

Note: Temporary IDSome applications assign a temporary ID when registering a new patient. tuOtempO will retrieve the definitive ID of the patient via the CheckAppointments() Webservice
Warning: Manual mergeIf an Operator manually merges two duplicate patients in Your Software it is important that the data relative to the online registration is conserved, otherwise tuOtempO is not capable of identifying with whom the fusion has been made and the associations with their reservations will be lost.

deleteAppointment()

This Webservice allows the removal of a reserved Appointment.

The Webservice should be called by tuOtempO with these parameters

VALUE (NULL = optional) CORRESPONDS TO
[APP_LID] [nchar](10) NOT NULL ID Appointment in Your Software
The Webservice should return to tuOtempO the following data

VALUE (NULL = optional) CORRESPONDS TO
[DELETE_RESULT] [nvarchar](50) NOT NULL OK / ERROR
[ERROR_MESSAGE] [nvarchar](500) NULL Error Message
[APP_LID] [nvarchar](50) NULL ID Appointment in Your Software (concatenation of all the fields that make up the primary key PK) OR Error Message

Note: Cancellations by mailtuOtempO can also send cancellations by mail : some centres opt to receive cancellations through an email account that is frequently checked manually by an administrator (often so they can call and fix a new appointment). In this case the Webservice DeleteAppointment is not needed.

getAppointments()

This Webservice is needed when you want the patient to be able to online view or cancel all his existing appointments regardless of their origin (online/offline).

The Webservice should be called by tuOtempO with these parameters

VALUE (NULL = optional) CORRESPONDS TO
[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software.
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO
[START_DATE] [nchar](10) NULL Start date of the search interval
[END_DATE] [nchar](10) NULL End date of the search interval
[RESOURCE_LID] [nvarchar](50) NULL ID Resource (ex. Doctor) in Your Software
[LAST_REQUEST_TIMESTAMP] [datetime] NULL Date and time of the last call of GetAppointments (permits to get only the appointments that have been added or modified after the last call)
[APP_LID] [nchar](10) NULL ID Appointment in Your Software

USER_TID and USER_LID are exclusive to eachother. You should use only one of them according to the Users synchronization pattern chosen.

Merged Patients ManagementIf the USER_LID pattern has been chosen the APP_LID argument must be implemented because it represents  the only way of notifying tuotempo that an appointment’s holder has been merged with another user in Your Software (getAppointments(APP_LID)=MERGED_USER_LID).

The Webservice should return to tuOtempO the following information:

VALUE (NULL = optional) CORRESPONDS TO
[APP_LID] [nchar](10) NOT NULL ID Appointment in Your Software
[STATUS] [nchar](10) NOT NULL Status of the appointment (Confirmed, Cancelled)
[APP_DATE] [nchar](10) NOT NULL Date of the appointment
[APP_START_TIME] [nchar](5) NOT NULL Start time
[APP_END_TIME] [nchar](5) NULL End time
[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software.
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline number
[USER_WORK_PHONE] [nvarchar](50) NULL Work number
[USER_EMAIL] [nvarchar](50) NULL Email
[USER_INSURANCE_LID] [nvarchar](50) NULL ID Insurance in Your Software
[USER_PRIVACY] [nvarchar](1) NULL Acceptation of privacy regulations (1=OK/0=NOT ACCEPTED)
[ACTIVITY_LID] [nvarchar](50) NOT NULL ID Activity in Your Software
*[ACTIVITY_NAME] [nvarchar](50) NULL Name of the activity in Your Software
*[ACTIVITY_GROUP_LID] [nvarchar](50) NULL ID Group of services in Your Software
*[ACTIVITY_GROUP_NAME] [nvarchar](50) NULL Name of group of services
[RESOURCE_LID] [nvarchar](50) NOT NULL ID Resource (ex. Doctor) in Your Software
*[RESOURCE_FIRST_NAME] [nvarchar](50) NULL First name of the resource
*[RESOURCE_SECOND_NAME] [nvarchar](50) NULL Second name of the resource
Note: KeyEntities dependence* These fields should be NOT NULL when the KeyEntities Webservice does just return a partial (filtered) set of key-entities instead of the whole set of key-entities contained in Your Software’s database.

Note: Strong MatchingIf Your Software allow to save tuOtempO patient’s id (USER_TID pattern) it could be possible to invoke the Webservice GetAppointments() passing USER_TID instead of USER_LID.
Warning: Status Cancelled => LAST_REQUEST_TIMESTAMPThe input parameter LAST_REQUEST_TIMESTAMP can only be used if the STATUS = ‘cancelled’ is implemented by the GetAppointments() webservice.

 

B.3 Multi center environment

This webservice is important only in case of high number of centers, it allows to automate the creation of new tuOtempO accounts whenever a new center is added to the pool of centers managed by Your Software.

On tuOtempO side there will be an instance for each center and, if needed, an additional “portal instance” that will permit to have a single point of access on the web which will take care of making parallel searches on the centers, return availabilities and forward to the centers new reservations or cancellations requests. The portal instance could also host, without loss of functionality, centers that have been integrated by views and temporary tables using tuOtempO Sincro.

getCenters()

The Webservice should return to tuOtempO the following information:

Response(Array (CENTER_LID , CENTER_NAME, [DESCRIPTION], [ADDRESS], [PHONE],[WEBSITE_URL])

C. [tuOtempO VIEW] – Access to Medical Results

To enable web access to medical results it is necessary to activate a synchronized communication between Your Software and tuOtempO by choosing one of the available procedures :

C.1 I can create views and temporary tables on My Software‘s database

The views provide to tuOtempO medical result’s data, the tables allow the control of informations flow.

The presence of the default NOT NULL indicates that the FIELD is obligatory.

The presence of the word UNIQUE indicates that the FIELD does not allow duplicate values.

Results View (TT_DOWNLOADS)

When on Your Software a new result is available for the web then a new record will appear in this view (initially with empty content in DOWNLOAD_CONTENT field)

FIELD CORRESPONDS TO
[DOWNLOAD_LID] [nvarchar](50) NOT NULL, UNIQUE ID Result in Your Software
[DOWNLOAD_CODE] [nvarchar](50) NOT NULL The code the user owns and use to request result’s delivery
[DOWNLOAD_FILENAME] [nvarchar](255) NULL Name of the result’s file
[USER_LID] [nvarchar](50) NULL ID of the Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO
[USER_FIRST_NAME] [nvarchar](50) NULL First Name – For privacy, it is best left empty
[USER_SECOND_NAME] [nvarchar](50) NULL Second Name – for privacy, it is best left empty
[USER_THIRD_NAME] [nvarchar](50) NULL Third Name – for privacy, it is best left empty
[USER_ID_NUMBER] [nvarchar](50) NOT NULL USER ID Number – it will be used together with DOWNLOAD_CODE to request result’s delivery
[USER_LANDLINE_PHONE] [nvarchar](50) NULL Landline
[USER_MOBILE_PHONE] [nvarchar](50) NULL Mobile number
[USER_WORK_PHONE] [nvarchar](50) NULL Work phone
[USER_EMAIL] [nvarchar](50) NULL Email
[USER_PRIVACY][nvarchar](1) NULL Acceptation of privacy regulations – Only if using tuOtempO MEMO or SURVEY
[COMMUNICATION_PREFERENCES][nvarchar](3) NULL Communication preferences, BYTEWISE string corresponding to three options: SMS, EMAIL, TEL. FIX (example: 101 => SMS Yes, Email No, Tel Fix Yes)
[USER_DATE_OF_BIRTH] [nvarchar](10) NULL Date of Birth (preferable format: dd/mm/yyyy)
[USER_GENDER] [nvarchar](10) NULL Gender (M, F)
[USER_ZIP_CODE] [nvarchar](10) NULL Zip Code
[USER_LANGUAGE] [nvarchar](10) NULL Language for sending communications
[REQUESTED] [nvarchar](10) NULL Date of the last request made from the web by the user (preferable format: dd/mm/yyyy)
DOWNLOAD_TYPE [nvarchar](10)NOT NULL Result’s file extension (ex.: pdf)
DOWNLOAD_CONTENT [varbinary](max) NULL Result’s file binary content

Temporary Tables give tuOtempO the possibility to write information necessary to control the flow of result delivery (adding user’s data if needed)

Temporary Results Table (TT_DOWNLOADS_TMP)

This table writes into Your Software‘s database the requests collected online by tuOtempO and status changes coming from delivering process. Writing to the table should activate a Trigger responsible for updating or adding information in the TT_DOWNLOADS_FILES table as to permit the transmission of the content. In the case of a new result’s request the value DOWNLOAD_ACTION will be UPDATE. When the content will have been transmitted to tuOtempO then an “empty content” request will arrive with DOWNLOAD_ACTION equal to EMPTY. The trigger will perform all the actions necessary to remove from TT_DOWNLOADS view the binary content of that particular result.

Note: Results in Filesystem onlyIf result’s files are not present in the database but only on the filesystem the trigger will temporary transfer the binary content on the table TT_DOWNLOADS_FILES by executing a stored procedure and remove the content once it has been transmetted to tuOtempO.

To make temporary transfer possible you will have to provide, for each medical result, the informations for retrieving them in the filesystem.

FIELD CORRESPONDS TO
[DOWNLOAD_TMP_ID] [nvarchar](10) NOT NULL, ID System (do not use)
[DOWNLOAD_LID] [nvarchar](50) NOT NULL, ID Result in Your Software
[DOWNLOAD_TID] [nvarchar](50) NOT NULL ID Result in tuOtempO
[DOWNLOAD_ACTION] [nchar](10) NOT NULL Action ( update, empty)
[REQ_DATE] [nchar](10) NOT NULL Date of the request
[REQ_TIME] [nchar](5) NOT NULL Time of the request
[USER_LID] [nvarchar](50) NOT NULL ID Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO
[STATUS] [nvarchar](50) NULL Status of delivering process
[STATUS_TRIGGER] [nvarchar](4000) NULL Output of the trigger
[INSERT_TIME] [datetime] NOT NULL Time at which the record was registered in the table
[DOWNLOAD_CUSTOM_0] [nvarchar](500) NULL Available for use with the Trigger
[DOWNLOAD_CUSTOM_1] [nvarchar](500) NULL Available for use with the Trigger
[DOWNLOAD_CUSTOM_2] [nvarchar](500) NULL Available for use with the Trigger
[DOWNLOAD_CUSTOM_3] [nvarchar](500) NULL Available for use with the Trigger
[DOWNLOAD_CUSTOM_4] [nvarchar](500) NULL Available for use with the Trigger
This table will act as support to TT_DOWNLOADS view to manage the transmission of file’s binary content to tuOtempO.
FIELD CORRESPONDS TO
[DOWNLOAD_LID] [nvarchar](50) NOT NULL, ID Result in Your Software
[FILE_NAME] [nvarchar](200) NOT NULL Name of the result’s file
[FILE_PATH] [nvarchar](200) NULL Path of result’s file on th filesystem
[FILE_CONTENT] [varbinary](max) NULL Result’s file binary content
[FILE_TYPE] [nvarchar](10) NULL Result’s file extension (ex.: pdf)
[STATUS] [nvarchar](50) NULL Status of delivering process
[STATUS_TRIGGER] [nvarchar](4000) NULL Output of the trigger
[REQUESTED] [datetime] NOT NULL Web request’s datetime
[CREATED] [datetime] NOT NULL Creation datetime
[MODIFIED] [datetime] NOT NULL Last modify datetime

C.2 I prefer to use Webservices which communicate with the API of tuOtempO

The synchronization with Webservices is achieved in two phases:

C.2.1. Transmitting web available results

Your Webservices (SOAP possibly) will be capable of replying to this call from tuOtempO:

getTestResultsList([USER_LID|USER_TID], RESULT_START_DATE)
VALUE (NULL = optional) CORRESPONDS TO
[USER_LID] [nvarchar](50) NULL ID Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO
RESULT_START_DATE [nvarchar](10) NULL Test result starting day

The Webservice should return the following information to tuOtempO:

Response(Array (DOWNLOAD_LID, [STATUS (Valid, Cancelled)], DOWNLOAD_CODE, DOWNLOAD_FILENAME, DOWNLOAD_TYPE, USER_LID, [USER_TID], USER_MOBILE_PHONE, [USER_EMAIL], USER_ID_NUMBER ))

FIELD CORRESPONDS TO
[DOWNLOAD_LID] [nvarchar](50) NOT NULL, UNIQUE ID Result in Your Software
[STATUS] [nchar](10) NOT NULL Status of the result (Valid, Cancelled)
[DOWNLOAD_CODE] [nvarchar](50) NOT NULL The code the user owns and use to request result’s delivery
[DOWNLOAD_FILENAME] [nvarchar](255) NULL Name of the result’s file
DOWNLOAD_TYPE [nvarchar](10) NOT NULL Result’s file extension (ex.: pdf)
[USER_LID] [nvarchar](50) NOT NULL ID of the Patient in Your Software
[USER_TID] [nvarchar](50) NULL ID Patient in tuOtempO
[USER_MOBILE_PHONE] [nvarchar](50) NOT NULL Mobile number
[USER_EMAIL] [nvarchar](50) NULL Email
[USER_ID_NUMBER] [nvarchar](50) NOT NULL USER ID Number – it will be used together with DOWNLOAD_CODE to request result’s delivery
Note: Frequency and DurationtuOtempO will call this Webservice with a certain periodicity depending on the configuration setting, typically twice a day. The call will ask for all the results for which the date is equal or after the date specified in RESULT_START_DATE parameter.
Assume, as an example, this date is one week before the current date.
Note: Removing a Test ResultIf for some reason you need to remove a Test Result (e.g. removing Test Result ID=012324) you can choose between
a) just reply to the call omitting the Test Result ID=012324
b) change status to Test Result ID =012324 setting status=cancelled
If a test result is out of the time-slot specified by RESULT_START_DATE the system will notice its cancellation when calling the Webservice getTestResultContent.

C.2.2. Transmitting test result content

Your Webservices (SOAP possibly) will be capable of replying to this call from tuOtempO:

getTestResultContent(DOWNLOAD_LID)

The Webservice should return the following information to tuOtempO:

Response(DOWNLOAD_LID, [DOWNLOAD_CONTENT],STATUS(Valid,Cancelled),[ERROR_MESSAGE])

FIELD CORRESPONDS TO
[DOWNLOAD_LID] [nvarchar](50) NOT NULL, UNIQUE ID Result in Your Software
[STATUS] [nchar](10) NOT NULL Status of the result (Valid, Cancelled)
[DOWNLOAD_CONTENT] [varbinary](max) NOT NULL Result’s file binary content
[ERROR_MESSAGE] [nvarchar](500) NULL Error Message
Note: Content not availableThe field ERROR_MESSAGE should give an explanation of the result’s unavailability.

D. [tuOtempO AGENDA/WEB] – Providing User and Authentication information

In some circumstances a patient or operator can access tuOtempO using registration and authentication data from another application or portal. In this case it is possible to send to tuOtempO the data of the patient or the operator in the URL or by keeping the user data synchronized.

D.1 My users are in the database of My Software

In this case it is simplest not to require synchronization.

Access for a patient coming from your application or portal.

The user logs in to your site in one click via a link to the online appointment module. Your server will call the tuOtempO server using the following URL:

http://app.tuotempo.com/mop_login.php?dbName=tt_acme&username=admin@portal.com
&password=portalpassword&fname=Valentino&lname=Rossi
&phone=3333333333&hometel=05110101010&email=rossi@acme.com&idnumber=BNCDTL72A10G482S
&birthday=10/01/1972¬e=343545&user_lid=134354466

Note: UsernamesIn the FIELD username and password will be the data of an administrative user of tuOtempO who has received the activation link, while in the FIELD user_lid will be placed the ID of a patient in Your Software‘s database.

tuOtempO will reply with a session id (ex:sessionId=2t3t43u43t54u5t4u54t346vbjhj) which your server will use for subsequent calls:

http://app.tuotempo.com/mop_customer.php?dbName=tt_acme&sessionid=2t3t43u43t54u5t4u54t346vbjhj

at this point the user is logged into tuOtempO and can proceed to make a booking.

Privacy and security

The data of the user passes from your server to the server of tuOtempO. It will not be visible or modifiable in the patient’s navigator. The patient’s navigator will only see the session data. If this is changed the session will be disconnected automatically.

Access for an operator coming from your application or portal.

http://app.tuotempo.com/mop_customer.php?dbName=tt_acme&username=operator@acme.com

&password=acmepassword&fname=Valentino&lname=Rossi&phone=3333333333
&hometel=05110101010&email=rossi@acme.com&idnumber=BNCDTL72A10G482S
&birthday=10/01/1972¬e=343545

tuOtempO will conserve the patient information and insert it automatically when required. The insertion will check if the data is present in tuOtempO and when possible will associate it automatically to the user to avoid duplicates.

D.2 I would like to synchronize with my users

D.2.1 My users are in the database of My Software

The LOGIN API should be consulted. Please contact support@tuotempo.com if you need information.

D.2.2 My users are in a CMS (Joomla, Drupal, WordPress)

The USER API should be consulted. Please contact support@tuotempo.com if you need information.

D.2.3 I use JanRain

The USER API should be consulted. Please contact support@tuotempo.com if you need information.

Tagged: