Apr. 14, 2023 Release notes
Focus on regulations in this new coog release!
coog 23.14 is marked by the creation – as part of a major collective project – of the DSN module and its generation of parameter sheets.
The Prest’IJ module, meanwhile, has improved its registration process for companies and their employees.
Business areas such as Health and the NOEMIE module are not left out in this new version, with the management of double attachment and refusal of noemization as soon as a contract is taken out.
coog Back-Office
Regulatory
DSN
Generation of DSN forms
Business need: generate DSN forms for posting on Net-entreprises.
Changes :
- In “Company”, a new configuration has been added to prepare the DSN flow.
- On each product (in the laboratory’s DSN tab), it is possible to set up a DSN configuration using a mapping rule.
DSN transcoding rule (default) delivered as standard
- Generation (automatically following a management action and/or manually) of DSN forms in XML and PDF format from coog.
Generation and consultation of a DSN form from the subscriber of a group contract
Enable Prest’IJ re-registration from a registration form
Context:
Periodic purging of the GESTIP database is carried out on data considered obsolete:
- Coverage with an end date prior to today’s date – 33 months and which has not been modified for 24 months,
- Insureds to whom no cover is attached and who have not been modified in the last 24 months,
- Companies to which no insured is attached and which have not been modified in the last 30 months.
However, for some companies, it is necessary to register employees after the purge performed by the Caisse Nationale d’Assurance Maladie (CNAM).
Business requirement: be able to relaunch the company’s registration after a purge to enable employee enrolment.
Evolution: activate the “Relaunch the enrolment process” button for companies with a Prest’IJ “Déclaration confirmée” status, enabling them to return an enrolment to the CNAM.
Health
NOEMIE
Enable refusal of noémisation when subscribing to a contract
Context: refusal of noemization by the policyholder was only possible by entering an endorsement on an existing contract.
Business need: it should be possible to enter a policyholder’s refusal to demote at the time of underwriting.
Evolution: addition of a checkbox to indicate that the policyholder does not wish to activate noemization as part of the health contract underwriting process.
almerys
Management of third-party double noemization
Scope of application: almerys interface for managing healthcare services.
Context: it is necessary to generate two V3 flows (one on D and one on D+1) to inform almerys and manage the double attachment of a beneficiary (non-emancipated minor) to two beneficiaries (parents) in the sense of the Régime Obligatoire (RO).
Business requirement: activate RO rights on D and inform the Tiers Payant organization of the child’s attachment to both parents when they are covered under the same contract.
Evolution: V3 tags required for double attachment.
Enable modification of third-party communication preferences
Scope of application: almerys interface for managing healthcare benefits.
Context:
Today, it is not possible to indicate the policyholder’s communication preferences (postal or email) in the V3 flow. The V3 flow tags used to indicate this information to almerys were by default populated with the email value.
Business need:
To be able to communicate to almerys the policyholder’s communication preferences for the method of sending benefit statements and management letters.
This information must be sent in a V3 flow if preferences are modified.
Changes :
- Addition of two data items “Mode d’envoi des décomptes almerys” and “Mode d’envoi des courriers de gestion almerys” on the third-party record,
- Feeding of V3 flow tags,
- Implementation of a rider to modify the policyholder’s communication preferences in order to inform almerys of this modification,
- Addition of the two data items to the APIs.
Borrower
Addition of a new “Agency” field if the lender is a bank
Scope: this new field is only available for banks organized into branches (regional, for example) when adding a loan to the underwriting process.
Context:
When a loan is entered, the name of the lending organization and the address must be entered. For bank networks organized into branches, the manager had access to the list of branch addresses, without being able to determine which branch the address corresponded to.
Business need: to have access from the bank to all its existing branches via their names and to be able to filter on the name of the desired branch.
Evolution: addition of a new “Agency” field to access the list of agencies available for the chosen bank, in order to select the desired agency.
Override the overlap check on loan insurance coverages
Evolution: lift the overlapping cover check not applicable to borrower insurance.
Contracts
Management of contributions and benefits contact persons
Business need:
Management of the notion of contribution and benefit contact, which, for one or more legal entities covered by a group contract, includes the notions of third party, contact method and bank details.
For each group contract, the contributions/benefits contact can be :
- Centralized (one and only one legal entity as interlocutor),
- Decentralized (each legal entity is responsible for its own contributions/benefits),
- Mixed (grouping of interlocutors at corporate level),
- Delegated (the interlocutor is not a legal entity covered by the contract, but another third party).
Evolutions :
- A wizard has been added to the subscription process, enabling you to enter the contribution and benefit contact persons and the management mode,
- Addition of a rider enabling the interlocutors to be modified during the life of the contract.
Improved call slip event mechanics
Context: call slip events are generated but can only be consulted from the contract’s “Event Logs” record.
Business need: access to events (generation, validation, issue, payment) directly from call slips.
Evolutions :
- Added event logs from the “Call slips” entry point,
- New events added: “Payment allocation” and “Payment deallocation”.
Endorsements
Addition of contract amendment template elements
Changes :
Add rider templates for :
- Modify additional benefit data,
- Modify additional contract data,
- Cancel a contract.
Adding the notion of application groups to endorsement definitions
Context:
Rider definitions can be linked to user groups to restrict access. However, if a rider definition is linked to a group, all attached users can enter and apply the rider.
Requirement: to avoid the risk of fraud, it must be possible to separate rider entry rights from rider application rights.
Evolution: set up application groups to define which groups can apply the rider.
The rider remains in draft form, and a user with the appropriate rights can take it back and apply it.
Enable termination of additional formulas via the formula modification rider
Context:
The rider allows you to take out a new supplementary plan. However, if you wish to :
- Change a complementary plan, this does not cancel the previous plan’s coverage;
- Cancel a top-up plan, no action is taken.
As a reminder, a complementary plan is a plan that includes non-mandatory benefits. This complementary package is linked to a package subscribed to on the contract.
Business need: to be able to replace or terminate complementary formulas, respectively by changing the complementary formula via an endorsement, or by selecting “Empty” to terminate the formula.
Evolution: redesign of the formula modification rider to enable termination or formula change in a single rider.
Claims
Add identifier and external number to claims
Business need: when delegating benefits management, the delegate can have his own identifier.
Evolution: add “Identifiers” fields on claims to store an external reference.
Addition of a rule on benefits to enable the entry of compensation periods in the future.
Scope: manual creation of benefits – does not apply to periods created by batch (e.g. pension extension).
Context :
Today, the period entry wizard blocks benefit entry in the future. The period end date must be less than or equal to the current date.
Business need: it must be possible to enter services in the future, so as to be able to record services with an end date greater than the current date.
Application examples: receipt of a work stoppage on 06/04/2023 for a period from 01/04/2023 to 25/05/2023.
It is now possible to enter the end date of the work stoppage on 05/25/2023 without having to split the periods.
Evolution: creation of a new rule type and delivery of a default rule for defining the maximum advance period allowed.
You can define the rule to be applied to the service.
Creation of a claims reimbursement generation batch
Context: the future implementation of benefits capture means that the generation of claim reimbursement receipts must be decoupled from the validation of claim periods.
Business requirement:
Benefits must be able to be entered, without receipts being generated automatically for future periods. It is also necessary to be able to consult future receipts for a given third party.
Evolution :
- Addition of a claim reimbursement generation batch “claim.indemnification.invoice”: this batch will process indemnification periods whose status is “Valid” and will select indemnifications whose start date is less than or equal to the date passed as a batch parameter.
Addition of an “Indemnifications” entry point presenting all indemnification periods. It will be possible to filter on “Validated” status.
Addition of the breakdown of compensation periods on the date of loan payment.
Scope: Borrower benefits.
Context: when entering benefit periods, the periods entered do not necessarily correspond to loan payment dates.
Business need: benefits must be automatically split by coog so that the periods correspond to the payment dates of the loan on which the benefits are entered.
Evolution: the benefit period entry wizard automatically trims benefit periods to the same dates as loan payment dates.
Possibility of filtering the rules engine function “date_of_end_of_previous_claim” with a list of claim codes.
Context: the rules engine function only checks for the presence of a claim (any loss).
Evolution: addition of an optional parameter to the rules engine function.
This parameter will enable filtering via a list of loss codes to limit the search if necessary.
Example of application: implementation of a complex eligibility rule that checks the time between two claims.
When an insured person has benefited from a period of compensation for temporary incapacity for work (ITT), a new period of compensation is possible for a new ITT after a return to paid employment of at least X consecutive months. New compensation for loss of employment may be provided following a return to paid employment of at least X consecutive months.
Addition of an entry point for delegation slips.
Scope of application: healthcare services – integration of services paid for by the Tiers-Payant service.
Context: invoices paid by the delegate are accessible in the “Supplier invoices” menu, which groups together all invoices paid by third parties.
Business requirement: when integrating healthcare services paid for by the delegatee, it was necessary to be able to view only those receipts linked to a payment by the delegatee.
Evolution: creation of a new menu for viewing receipts for services paid for by the delegatee.
Make available the date of management takeover in the rules engine
Scope: group benefits.
Context: the management takeover date can be entered on group contracts, but cannot be used for parameterization purposes.
Business need: make the management takeover date available in the rules engine for use in medical selection, deductible calculation, benefit calculation, etc.
Evolution: add the function to the rules engine.
Application example:
Following the subscription of a group contract, the new insurer determines whether it will take over all claims or only revalorizations. The takeover date must be used in the rules to calculate the benefit.
Billing
Contributions
Error message displayed when a transaction created by an invoice is cancelled
Context: cancelling an accounting movement on a receipt in “Issued” status has the effect of changing the receipt to “Paid” status (in accounting terms, the movements are cancelled).
Evolution: introduction of an error message to inform the user that cancellation is not possible.
Event types added for suspension and de-suspension of payments
Context: it is difficult to identify contracts under suspension of payment.
Business need: enhance traceability of contracts suspended and/or de-suspended.
Evolution: add event types for suspension and/or de-suspension of payments.
Application example:
Following the rejection of a payment, direct debits are suspended on the contract. This suspension will be available in the event logs.
Optional taxes added to product guarantees
Context: if the tax applied to a benefit depends on policyholder or contract criteria, it was necessary to set up as many benefits as tax profiles.
Business need: vary the tax rate applied to a given benefit according to criteria such as the plan, additional data, etc.
Example of application: in Health, cover taken out by policyholders under the general scheme is subject to a TSCA of 13.27%, while cover taken out by policyholders under the agricultural scheme (MSA) is subject to a TSCA of 6.27%.
Changes :
- Addition of the notion of optional tax on benefits,
- Use of the rule engine to define tax application conditions.
Rate schedule management
Scope: group contracts with standard pricing.
Context: at present, pricing for standard and customized contracts was entered when the contract was underwritten.
Business need:
- To be able to quickly and easily enter the contribution rates or packages applicable to each benefit/population group – either at contract level (customized pricing), or at product level (offer pricing),
- Generate DSN forms (see Regulations).
Application example:
In group health, for a standard product, it is no longer necessary to enter package rates for each population group on each contract.
Evolutions :
- New usage concept in additional data: “Contribution structure component”. Additional data on benefits is mandatory to generate rate schedules. It is possible to parameterize which elements are to be taken into account in pricing (e.g. “college” additional data on the population group).
- By default, coopengo delivers two additional data items: contribution types and contribution bases.
- Creation of a wizard for exporting rate schedules in csv format, for use outside the tool (export/import functionality).
- Creation of a tool for aggregating contributions by population group (new screens + input of contribution call slips to obtain the overall TA/TB rate rather than the rate per benefit).
Step 1 – Selecting the grid type
- Choice of benefits
- Choice of population groups
- Choice of type and, if relevant, contribution base
Step 2 – Option of entering rates directly in the interface or generating the CSV
Step 3 – CSV recovery
Step 4 – Update CSV in Excel then import
Step 5 – File used and added to product
Accounting
Add a wizard for creating an accounting product
Commissions
Addition of the ‘code_courtier’ function to the rules engine
Business need: to be able to add broker-specific commission calculation conditions to the rules engine, in order to mutualize cross-broker parameterization.
Evolution: added a function to the rules engine to access the broker’s code in a commissioning context.
Enable the rules for calculating the payment date of the withholding tax to work with the booked payment method.
Scope of application: prepaid commission plan.
Context:
When setting up withholding tax on commission plans, it is possible to configure the date on which withholding tax is to be paid in two different ways:
- Use a rule to calculate the payment date for deducted commissions,
- Check box “On first paid receipt”.
These two modes are exclusive.
Business need: to be able to set up a rule for the payment date of the commission on the contract effective date.
However, the withholding tax cannot be paid before the first receipt is paid.
Evolution: remove the exclusivity between the two calculation modes.
Display additional data in commission log record name
Scope: this function only applies to linear commission plans.
Context :
By default, the commission log name is that of the commission plan in coog. If a user wishes to set up three linear commission protocols, he must set up three commission plans (example: linear 5, linear 10, linear 15) and associate three commission protocols with them.
Evolution :
The aim of this evolution is to set up a linear commission plan and associate three commission protocols – each with an additional data item specifying the commission rate.
As a result, the value of the additional data is attached to the name of the commission plan when a contract is subscribed.
Benefit: optimized parameterization of commission plans and protocols.
Documents
Creation of a batch to cancel duplicate document production requests
Context :
In management, triggering events generate a document production request. If several amendments of the same type are made on the same day, it is common for several document production requests to be generated.
Evolution: creation of a “ report_production_request_batch_cancel_duplicates ” batch.
This process will set duplicate document production requests to “Cancelled” status. Duplicate detection conditions :
- Document requests are in “To be processed” status,
- The mail template is identical,
- The context is identical,
- The event generating the document production request is identical,
- The creation date is different from the creation date of the most recent document production request.
Enable printing of covered risks from the print wizard
Context: Mail can be edited from a third party, a claim or a contract, but it is not possible to generate mail for a single or several covered elements of a contract.
Business need: to have the ability to print a mail for a contract or for a single covered element of the contract.
Evolution:
From the mail generation wizard, it is now possible to select a “Contract” or “Covered risk” template. The list of available letters will be filtered by model.
Document category and family added
Context: a document in coog was defined by its variant and not in absolute terms.
Business need: to enable documents such as administrative or medical formalities to be grouped together and searched for more quickly.
Example of application: a medical questionnaire specific to an insurer could belong to the “Health questionnaire” category and the “Medical formalities” family.
Evolution :
- Added new notions of document category and family to group document types,
- Updated simulation API to return required documents grouped by category.
Processes
Task management
Add a completed task modification mechanism
Context: completed tasks in coog were only available in read-only mode.
Business need: modify the information of a completed task when, for example, an error is detected.
Evolution: new button to modify a completed task.
Add summary field to task template
Context: task creation does not allow text to be entered to contextualize the task.
Business need: to enable the manager to enter information and quickly access essential task information.
Evolution: new free-entry description field in text format.
Rules engine
Improved filter rule mechanics
Context:
Filter rules in actions by event type can be used to filter action application conditions by event type. The context of the rule does not return information enabling filtering on business objects.
Business need: to be able to apply filter rules to business objects (contracts, services, etc.).
Evolution: add filter rule contexts to the model object rule with the corresponding object key.
Development of a powerful new rules engine mechanism, searchable by API
Methodological approach to evolution :
Lambda is the term used in coog. We can also speak of a made-to-measure rule.
Evolution:
An API mechanism has been added, enabling rules to be set up in coog that can be queried via API. These rules do not access data stored in coog.
The “LambdaAPI” object will initially be based on a call to rule_engine. In terms of data, the rule algorithm will only have access to the following elements:
- Parameters (
rule_engine.rule_parameter) of the rule in question, - Tools” menu method,
- Tables,
- Other rules that respect the same constraints.
A documentation API will list the rules and describe the expected input parameters.
An API for executing these rules will ask coog to execute N calls to these rules, with the parameters supplied in the API request, and coog will return as many execution results.
Wizard to find out whether a rule is used and in what context
Context:
It is impossible to know from a rule in the rules engine where this rule is used (on which products, warranties or services). It is necessary to go through the various parameterization objects to find this link.
Business need: visualize directly on which parameterization object the rule is used from the rule and no longer from the various parameterization objects.
Evolution: from the rules engine, create one or more links to the benefits, products and services on which they are configured.
A function retrieves the additional data for the benefit offered, if not already present for the benefit subscribed.
Business requirement: in order to implement complex rules based on additional data of the “guarantee” business type, it is necessary to retrieve additional data for all subscribed guarantees from the rules engine.
Evolution: the rules engine function “donnee_complementaire_autre_garantie_contrat” provides access to warranty typing.
Application example: to set up an eligibility rule, it is necessary to retrieve additional data of the “guarantee” business type.
Technical core
Add a wizard to generate the anonymization script
Context: anonymization of a client’s databases is performed via a “hard” script stored on Docker.
This script is not part of the application itself, and has no mechanism for overloading it with specific data.
Business need: enable this script to be generated, adapting it to the environment on which it will be launched (installed modules, customer-specific data, …).
Evolution :
- Identify fields likely to contain data requiring anonymization, using a new “sensitivity” parameter set to “non_sensitive” or “sensitive_party”,
- Create a wizard to download an anonymization script in SQL format.
This script can be run on a copy of the database from which it was generated, in order to anonymize all personal data.
“No”: only data will be anonymized.
“Delete all”: data will be anonymized and revision versions will be deleted.
Basic configuration tools added for OpenTelemetry
Evolution:
Implementation of OpenTelemetry to :
- Have a standard centralized logging mechanism,
- Track calls between coog components,
- exploit usage statistics/patterns.
Renaming entry points
Context: avoid duplication of menu names within the application.
Evolution: addition of parent menus to contextualize results, notably in the quick search bar.
Add a button to cancel the scheduled execution of a batch, a chain or a batch plan.
Context: to stop the execution or scheduling of a batch, you need to delete the job and then the run, even if the run has several jobs.
Evolution: a button has been added to stop the scheduling or execution of a batch, batch chain or batch plan in a single action.
Default activation of technical history on configuration objects
Scope: all configuration objects except distribution networks and commissioning protocols.
Context: to view modifications made to configuration objects.
Evolution: addition of an object for viewing the history of configuration information.
Addition of a text field to display a formatted version of the call trace
Evolution: in the “Errors” entry point, it is now possible to obtain the call trace in text format.
Add a button to export the error report in the Errors menu
Context:
Activating the error handler enables you to store application errors and their details. These errors can be exported via JSON for integration and visualization in any environment.
Business requirement: export generation without having to install the export/import plugin.
Evolution: add a button to export errors in JSON format, without activating an additional plugin.
coog API
External event notification API added
Scope: The API will only be usable on “CUSTOM” events and not with events delivered by coog.
Business need:
An external IS tool wishes to send events to coog. These events can be connected to actions.
Evolution:
Add a method to be overloaded on event types. If you try to notify an event in this list, coog will return an “Event type not found” error.
Added support for MongoDB ReplicaSet
Business need: simplify management and ensure compatibility with the old MongoDB connection method.
Evolution: add an environment variable to manage ReplicaSet connections without modifying the current behavior with the old variables (when this variable is used, the previous variables will be ignored and only the new variable will be used).
Addition of ID and end date fields to the API that lists commercial products
Evolution: added the following fields to the commercial products API RPC (model.api.product.list_commercial_products):
- “commercial product id”,
- “technical product id”,
- “commercial product end date”.
Adding Web resources to the Commercial Products API
Business need: display commercial products grouped by family.
Evolution: return “web.ui.resource” to “list_commercial_products” API.
Add API V2 to close claims
Business need:
Closure of a claims file in an external tool needs to be passed back to coog. The reason for closure/substatus must also be transmitted.
Evolution: Claims closure API added.
Add an API for creating and updating healthcare benefits
Business need: the creation and updating of healthcare benefits from an external tool had to be transferred back to coog.
Evolution: addition of an API for creating and updating healthcare benefits.
GraphQL
Addition of a GraphQL API for searching for third parties by IBAN
Business need: bank account information must be retrieved from external IS or an insured space.
Evolution: addition of a bank account search API via a mandatory IBAN filter.
Adding a quote entry point to B2B GraphQL
Business need: GraphQL queries don’t retrieve quotes.
Evolution: a quotation entry point has been added to the “b2b_dashboard_query” (quotations will be available below the contracts entry point).
Creation of the GraphQL entry point for consulting schemes and affiliation funds
Context: a Front wanted to be able to load from coog information from the mandatory schemes repository and the affiliating organizations.
Evolution: creation of a GraphQL repository API for querying repositories.
coog Front-Office
Insured area (B2C)
Addition of an emailing mechanism for the personal space
Context: addition of a secure, automated policyholder space creation process.
Evolution: new mechanism for creating the policyholder’s personal space by sending an email from the Front-Office.