• Rational
• Boundary conditions
• Upgrade functionality
• Downgrade functionality
• White list

The 1^st 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 1^st of April. Furthermore, it seems that some insurances will not be ready before the 1^st 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