This page documents the change that will be performed in the scope of the Tanzanian project to make openIMIS ready for interfacing with an accounting system. This work will be divided in several steps:

1. Create a database structure to save the account payable

2. Save the different account payable

3. Convert the different account payable following that structure

4. Create a FHIR interface for the accounting systems

Create a database structure to save the account payable

The concept is to use a widely use format as base. inspiration can form FHIR invoice and SAGE API Invoices. openIMIS is not an accounting system therefore generating book and ledger is not in the project scope but invoice are a good representation for the payable mentioned above. To bring flexibility, a JSON fields was added to the invoice line in case a structured details is required.

The link with the Source and actor won’t be in a form a database foreign keys because those could be from different table.

inboundInvoices

referenceActor {
  "label":"",
  "code":"",
  "type": "batchRun/commissionOverview/capitationReport",
  "id":"UUID",
  "address":{"text":"",...}
}

referenceSource {
  "label":"",
  "code":"",
  "type": "HF/Insuree/PH/payer/user",
  "id":"UUID",
  "address":{"text":"",...}
}

tax details {
  "lines": [
    {"label":"", "rate":"", "base":"", "amount":""}]
    …
  ],
  "total":""
}

inboundInvoiceLineItems

to docuement the content fo the inboundInvoice

tax details {
  "lines": [
    {"label":"", "rate":"", "base":"", "amount":""}]
    …
  ],
  "total":""
}

inboundInvoicePayments

To document the payment done on the invoice. out of scope: a payment done for 2 invoice, to support such scenario an “generalPayment“ table need to be created, this table will have sub table with relationships to inboundInvoicePayments, once the reconciliation between the different invoice will be done.

inboundInvoiceEvents

this table will log the event relating to the invoice

Save the different account payable

Ideally the “batchrun“ would be rename “close accounts payable”, closing account will be on a defined scope:

1. area: if not national, will take only the product define on the level selected or below

2. type: the type below could be checked

   1. supplier payment method (notion not yet existing)

      1. Claim valuation (fee for service - batchRun): https://openimis.atlassian.net/browse/OTC-10

      2. Capitation payment: https://openimis.atlassian.net/browse/OTC-10

   2. operation fee payment method (notion not yet existing)

      1. Commission payment:

      2. Payment fees

   3. insuree Cash payment (doesn’t exist yet)

3. an account payable param report will be generated for each of the bellow Item when required by the payment method

   1. Product / payment period for “supplier payment method”

   2. actor / payment period for “operation fee payment method”

   3. insuree for the insuree payment period

Convert the different account payable following the new structure

1. Claim valuation (batchRun):

   1. two way of creating the accountPayable are possible for the valuation, in both case there will be one “accountPayable” per HF

      1. One asset (line) per claim, claim details as asset description: claimed amount as unit price, net amount as net price, discount calculated based on net and unit price

      2. one asset (line) per item or service with claim detail as asset description: item/service claimed unit price as unit price, net as valuated price, quantity as quantity, discount calculated based on net and unit price

2. Capitation payment:

   1. two way of creating the accountPayableare possible for the valuation, in both case there will be one “accountPayable” per HF

      1. one asset (line) per weighted indicator I for product P : Allocated contribution/ Sum(indicator for P) as unit price , indicator I as quantity, (1-weight) as discount;

         1. Population living in catchments area of the health facility

         2. Number of families living in catchments area of the health facility

         3. Insured population living in catchments area of the health facility

         4. Insured number of families living in catchments area of the health facility

         5. Number of claims (contacts) with the health facility by insured in the catchment area

         6. Adjusted amount

      2. asset (line) per product with the detail of the calculation as asset description

3. Commission payment:

   1. one accountPayable per EO,

      1. one asset (line) per product/commission, sum of policy value as quantity, commission as unit price, product account code as ledger account

      2. one asset (line) per policy : policy value as quantity, commission as unit price, product account code as ledger account (dependent detail as asset description)

4. Payment fees

   1. one accountPayable per type of payment (TBC)

      1. one asset (line) per product/commission, sum of policy value as quantity, Payment fees as unit price, product account code as ledger account

      2. one asset (line) per policy : policy value as quantity, Payment fees as unit price, product account code as ledger account (dependent detail as asset description)

5. insuree Cash payment (doesn’t exist yet)

   1. one accountPayable per insuree (for all dependant), one line per cash payment (level of Item and service)

   2. one accountPayable per period, one line per cash payment claim

Create a FHIR interface for the accounting systems

Here the FHIR ressource to be used:

https://www.hl7.org/fhir/invoice.html

Front end

Search page

search criteria

search result

card page

general information

detials

Other FE approach (not prefered)

• Either drop down as current screen

  • General Account Payable section

    • Select “Account payable”

    • Payment plan picker in the future data model

      • can be a static drop down list for the old model: Valuation / Capitation / Commission fees / payment fees + Product picker

      • Or calculation for payment plan using the product configuration could be created, then payment plan could be created for each products

    • two datetime entries: DateFrom/DateTo

    • Location picker

  • Export Account Payable section

    • Payment plan picker in the future data model

      • can be a static drop down list for the old model: Valuation / Capitation / Commission fees / payment fees + Product picker

      • Or calculation for payment plan using the product configuration could be created, then payment plan could be created for each products

    • two datetime entries: DateFrom/DateTo

    • Location picker

    • group by: Product or third party

    • third party: user(EnrolmentOffice)/HF/”insuree”

  • section “payment plan calculated” that will display all “Account Payable generated” with there input detail in 1 column, working var in a second and the result in the third (relative index)