Transactions content modification on uploading

Owned by vickyp
Last updated: Jan 17, 2024 by Roman Konovalov
7 min read

VAT support

In accordance with DoH circular DG/62/17, from 1-Jan-2018 in relation to the implementation of Value Added Tax, several data elements were added to the following transactions schema:

  1. Claim.Submission
    1. Claim.VAT
    2. Activity.VAT
    3. Activity.VATPercent
  2. Person.Register
    1. Contract.CollectedPremium
    2. Contract.VAT
    3. Contract.VATPercent

Practice showed that many users systems were not ready to support these changes. A new feature is designed in Greenrain messenger that consists in updating the file with missed fields on uploading to the Post Office. This logic is applied for Shafafiya severs only and if the corresponding settings are selected in Settings.

Step 1. Click Settings at the top of the app.

Step 2. In the dialog appeared click VAT Support tab and check the necessary VAT settings:

  • None - no update is to be made;
  • 0% VAT - VAT fields with 0% are to be added;
  • 5% VAT - VAT fields with 5% are to be added.

Step 3. Click OK.

Step 4. On Upload tab, click Select Files to Upload and select a transaction file.

Step 5. Click Upload Transactions or Validate Only.
Greenrain Messenger adds absent fields to the file, verifies the numbers, then uploads the file to the Post Office/validates on the Post office without uploading.


Add missing VAT for Claim.Submission

Restrictions

  • VAT value in Settings is not None.
  • The earliest Activity.Start in a claim >= 1-Jan-2018.

Calculation

  1. If Activity.VATPercent has no value, then Activity.VATPercent = VAT % from Settings.
  2. If Activity.VAT has no value or it is calculated incorrectly, then Activity.VAT = Activity.Net * VAT % from Settings.
  3. If Claim.VAT has no value or Claim.VAT is calculated incorrectly, then Claim.VAT = sum of all Activity.VAT.


Add missing VAT for Person.Register

Restrictions

  • VAT value in Settings is not None.
  • Contract.RenewalDate of a contract >= 1-Jan-2018. A person may have several contracts, so this logic is not applied for those contracts that do not satisfy the condition.

Calculation

  1. If Contract.CollectedPremium has no value, then Contract.CollectedPremium = Contract.GrossPremium / Number of days in the current year * Number of days in the Contract where Number of days in the Contract = Contract.ExpiryDate - Contract RenewDate
  2. If Contract.VATPercent has no value, then Contract.VATPercent = VAT % from Settings.
  3. If Contract.VAT has no value or it is calculated incorrectly, then Contract.VAT = Contract.CollectedPremium * VAT % from Settings.

Split into successful and failed batches

Often happens that users validate/upload big batches, and too many errors are returned by the Post Office. It takes time to find those errors and resolve them one by one which leads to exceeding the allowed submission period. The purpose of the feature is to exclude failed records from the original file and let user upload successful records first, then correct failed records in a separate file. This logic is applied only if the corresponding setting is switched on in Settings.

General workflow looks as follows.

Step 1. Click Settings at the top of the app.

Step 2. In the dialog appeared on General tab check the setting Split successful and failed records to separate transactions.

Step 3. Click OK.

Step 4. On Upload tab, click Select Files to Upload and select a transaction file.

Transactions details load to the grid below.

Step 5. Click Upload Transactions or Validate Only.

Each record in the file starts validating against the specific Health Authority rules set. Progress bar at the bottom of the tab shows uploading/validating progress. When the process is finished, a dialog appears saying that the file uploading/validating is finished either successfully or not.

ScenarioUpload TransactionsValidate Only
All records are successful

The file is not updated and uploaded to the Post Office as is, then moved to _Sent folder.

The file is not updated and validated on the Post Office as is, then stayed in the select folder.
All records failedThe file is not updated and not uploaded to the Post Office. Validation errors report is returned.The file is not updated and not uploaded to the Post Office. Validation errors report is returned.
Some records are successful, some failed

The file splits into two batches.

  1. A new transaction file is created in the select folder and all records having validation errors are moved there from the original file. The file name format is <original_name>_Failed.xml (or .zip depending on the original file extension).
  2. Successful records stay in the original file, and the file gets uploaded to the Post Office and moved to _Sent folder.

The file splits into the said two batches, and both they stay in the select folder.


Greenrain Messenger shows both split files. User may open the _Failed file and correct errors, then try uploading/validating again.



Split rules

When the user selects any of the split files after corrections again, Greenrain Messenger loads both of them to the grid (if exist) since they are related, and uploads/validates them together. 

  1. If a record exists in both files, then it is removed from the _Failed file. The original transaction file data has a higher priority. So, eventual changes in the _Failed file will be lost.
  2. If a record in the _Failed file has no validation errors, it is moved back to the original file as successful. In case the _Failed file has no records left, it is deleted from the select folder.
  3. If a record in the original file has validation errors, it is moved to the _Failed file. In case all records are moved to the _Failed file, it is renamed to the original file.

If the original transaction contains duplicated records by Claim.ID / Member.ID, all the copies of the claim / person are placed into _Failed file no matter that each separate data entry doesn't throw errors. It's up to user to decide which of the copies should be deleted from the transaction.

DoH Personal Profile updates for Person.Register

DoH Personal Profile web service provides true details about a particular member so that Person.Register transaction contains correct information. This change was introduced on Shafafiya on March 10, 2018.

When user uploads or validates Person.Register file, Greenrain Messenger calls DoH Personal Profile Service in order to retrieve this information and update the file before uploading. The logic described is applied only if the corresponding setting is switched on in Settings.

Step 1. Click Settings at the top of the app.

Step 2. In the dialog appeared click Person.Register tab and check the setting Automatically update Person.Register transactions.

Step 3. Click OK.

Greerain Messenger calls DoH Personal Profile Service with the following parameters from the transaction for each person:

  • Person.EmiratesIDNumber
  • Person.UnifiedNumber
  • Person.PassportNumber
  • Person.BirthDate

If personal information is available, then the fields below are added to Person.Register transaction with corresponding values returned by the service. 

Field Name
Description
Person.UnifiedNumberUnified Number to uniquely identify a person. This number is issued by the Ministry of Interior (MOI).
Person.FirstNameEn

Person First Name in English. This value equals to the first word in a person's full name. Info

Person.MiddleNameEn

Person Middle Name in English. This value contains everything left between the first and the last words in a person's full name.

Person.LastNameEn

Person Last Name in English. This value equals to the last word in a person's full name.

Person.FirstNameArPerson First Name in Arabic. This value equals to the first word in a person's full name. Make sure that Arabic names are written from right to left.
Person.MiddleNameArPerson Middle Name in Arabic. This value contains everything left between the first and the last words in person's full name.
Person.LastNameArPerson Last Name in Arabic. This value equals to the last word in a person's full name.
Person.NationalityCodePerson Nationality code.
Person.CityCode

Code of residence city for the person. However, DoH service contains the city of birth only.

In case some fields already exist in the transaction but have values that are not matched with those returned by the service, Greenrain Messenger replaces this incorrect information too. 

Greenrain Messenger cannot call the service (and make the necessary updates) in the following cases:

  • Person.EmiratesIDNumber = NULL and Person.UnifiedNumber = NULL;
  • Person.EmiratesIDNumber = NULL and Person.UnifiedNumber <=10;
  • Person.EmiratesIDNumber is one of the default numbers and Person.UnifiedNumber = NULL.

Greenrain Messenger performs the search with Person.EmiratesIDNumber first. In case there are no results or Person.EmiratesIDNumber has one of the default values, the search if performed with Person.UnifiedNumber. If a person still cannot be found for some reason, DoH Personal Profile returns a corresponding error. Examples:

ConditionError Message Example
Passport Number is wrongPassport number 'ABC12345' is incorrect. Original error description: INVALID PASSPORT NUMBER. Original error code: 1. Reference: Person.UnifiedNumber = 12345466 and Person.EmiratesIDNumber = 000-0000-0000000-0. Source: DoH Personal Profile Service.
Birth Date is wrong

Birth Date 10-Jan-2001 is incorrect. Original error description: INVALID BIRTH DATE. Original error code: 1. Reference: Person.UnifiedNumber = 12345466 and Person.EmiratesIDNumber = 784-1983-5146079-9. Source: DoH Personal Profile Service.

Any other unexpected errorDoH Personal Profile Service returned an error. Original error description: CANNOT PROCESS THE REQUEST. Original error code: 1. Reference: Person.UnifiedNumber = 12345466 and Person.EmiratesIDNumber = 000-0000-0000000-0. Source: DoH Personal Profile Service.

DoH sent a notification email on January 9, 2019 requesting that DoH Personal Profile Service must be called with Emirates ID Number of UAE residents and Unified Number for anybody else. 

In order to be compliant with DoH rules to call the service, please make sure that in your transaction:

  1. correct Person.EmiratesIDNumber is set for UAE residents (not a default value);
  2. correct Person.UnifiedNumber and Person.EmiratesIDNumber = <default value> are set for other persons.

Default values for Emirates ID Number:

  • 000-0000-0000000-0 - National without card;
  • 111-1111-1111111-1 - Expatriate resident without a card;
  • 222-2222-2222222-2 - Non-national, non-expat resident without a card;
  • 999-9999-9999999-9 - Unknown status, without a card.

Electronic Medical Invoice

In accordance with DoH circular US/12/19 issued on March 14, 2019, providers must send a copy of e-claims to the patients by email or SMS (so-called Electronic Medical Invoice). The effective date is June 1, 2019. To cover this requirement, Greenrain Messenger uses personal contact data gathered with the means of Greenrain Submission to send a medical invoice to the patient. An email is sent once a Claim.Submission transaction is uploaded to Shafafiya. An email contains the claim details attached as a pdf file. Electronic medical invoice is sent if the following conditions are met:

  • at least Email of the patient is known;
  • a claim is not a resubmission.

The medical invoice looks as follows: