Compatibility measures & White list

The 1st of January is the official start date of all V4.3 XML versions. However, neither an intermediate nor insurance is ready to process these XML files before the 1st of April. Furthermore, it seems that some insurances will not be ready before the 1st of January 2012!

As a consequence the generalInvoiceRequest430 module will be enhanced by

  • a transparent upgrade function allowing to read all V4.0 and V4.1 XML files and transform these to V4.3
  • a transparent downgrade function allowing to generate either V4.3 files or downgrade to V4.0, V4.1 files, respectively. The decision process is implicit and based on a white list of insurances ready to process V4.3. If an insurance EAN is not in the list there is an automatic downgrade. The white list itself is maintained by Suva.
By implementing these measures there is an easy and transparent migration path to V4.3.
 

Boundary conditions
  • The upgrade and downgrade functionality is achieved by a delegation technique to the lower version COM modules in question. As a consequence such a COM module must be installed as well but of course only the ones for which invoices/reminders are produced.
     
  • The module undestands
    • generalInvoiceRequest_410.xsd - the generalInvoiceRequest410 COM module must be installed
    • hospitalInvoiceRequest_400.xsd - the hospitalInvoiceRequest400 COM module must be installed
    • mdInvoiceRequest_400.xsd - the mdInvoiceRequest400 COM module must be installed
    • invoiceReminderRequest_400.xsd - the reminderRequest400 COM module must be installed
      This module can be used for a downgrade only!
       
  • The downgrade in the GetXML/Print methods is based on the white list of Suva and the role/place information
    • role/place = enRolePhysician/enPlacePractice downgrades to mdInvoiceRequest400
    • role/place = enRolePhysician/enPlaceHospital downgrades to hospitalInvoiceRequest400
    • role/place = enRoleHospital/enPlaceHospital downgrades to hospitalInvoiceRequest400
    • role = enRolePharmacist is not downgraded as there is no older Sumex1 COM module of that type
    • all other role/place combinations downgrade to generalInvoiceRequest410
    • due to the white list technique an absent insurance EAN always produces a downgrade

Upgrade functionality
The upgrade functionality is achieved by the LoadXML method and the lower version COM module. LoadXML can load
  • generalInvoiceRequest_430.xsd
  • generalInvoiceRequest_410.xsd
  • hospitalInvoiceRequest_400.xsd
  • mdInvoiceRequest_400.xsd
Since the data spaces of V4.3 and the lower versions are not fully compatible the module makes some compatibility decisions:
  generalInvoiceRequest410 to generalInvoiceRequest430  
case_id (main software) is not loaded anymore (cf. downgrade)
patient_id (main software) is loaded if available
role roles without an equivalence in V4.3 are transformed to the best fit
 
hospitalInvoiceRequest400 to generalInvoiceRequest430
case_id (main software) is not loaded anymore (cf. downgrade)
hospitalizationEnd is not loaded anymore (cf. downgrade)
patient_id (main software) is loaded if available
surgery is not loaded anymore (cf. downgrade)
 
mdInvoiceRequest400 to generalInvoiceRequest430
case_id (main software) is not loaded anymore (cf. downgrade)
patient_id (main software) is loaded if available
surgery is not loaded anymore (cf. downgrade)
serviceLocation address is not loaded anymore (cf. downgrade)
case_id (main software) is not loaded anymore (cf. downgrade)
 
invoiceReminderRequest400 to generalInvoiceRequest430
can not be loaded

 
Downgrade functionality
The downgrade functionality is achieved by the GetXML and Print methods and the lower version COM modules. The downgrade decision is primarly based on the white list and the boundary conditions.
Since the data spaces of V4.3 and the lower versions are not fully compatible the module makes some compatibility decisions:
  generalInvoiceRequest430 to generalInvoiceRequest410  
case_id (main software) the patient_id from V4.3 is used as case_id
role roles without an equivalence in V4.1 are transformed to the best fit
validator Since there is no service record validation in the lower version
only a pseudo downgrade validator is included in the XML
 
generalInvoiceRequest430 to hospitalInvoiceRequest400
case_id (main software) the patient_id from V4.3 is used as case_id
ESR=enRedPayinSlip produces an error!
hospitalizationEnd is calculated as
max(treatmentEnd, last service date, hospitalizationBegin + treatmentDays)
law=ORG produces an error!
surgery is not populated
validator Since there is no service record validation in the lower version
only a pseudo downgrade validator is included in the XML
 
generalInvoiceRequest430 to mdInvoiceRequest400
case_id (main software) the patient_id from V4.3 is used as case_id
ESR=enRedPayinSlip produces an error!
serviceLocation is calculated as
   = hospital if enBillingRoleMT is set for a Tarmed record
  = practice otherwise
Note that no address can be set!
law=ORG produces an error!
surgery is not populated
validator Since there is no service record validation in the lower version
only a pseudo downgrade validator is included in the XML
 
generalInvoiceRequest430 to invoiceReminderRequest400
ESR=enRedPayinSlip produces an error!
storno produces an error!

 
White list
The white list maintained by Suva and published on the web site of the Forum Datenaustausch