Introduction

1. Introduction • Sumex I+ • Quality assurance and electronic transfer of physician’s invoice

2. Boundary conditions for Sumex I+ • Boundary conditions relevant for physicians • No increased costs • No increased time requirement • Free choice of the clearing center • Boundary conditions relevant for software houses • Publication and standardization of all interfaces • Hiding of XML standard and OCR-Print layout behind functional interfaces • Automatic update of data and software • Quality and continuity guaranty of project by the healthcare insurance companies

3. Sumex I+ implementation • Validator modules: • Search & browsing of tariff database • Validation of services against the tariff rules (tarmedValidator, labValidator, etc.) • Invoice module: • Generation and printing of standardized OCR invoice • Generation and transfer of XML invoice to insurance • Automatic usage of validator modules internally • netUpdate package: • Keeping software modules and databases up-to-date

4. Sumex I+ modules • Validators • tarmedValidator • labValidator • migelValidator • drugValidator • physioValidator • Managers • MDInvoiceManager • netUpdate Package

5. Technical implementation • MDInvoiceManager and validation modules • ATL-DLL modules written in C++ • netUpdate package • MFC-EXE modules written in C++ • Database access • OleDB access on local ready-only mdb-File • All databases are password protected

6. MDInvoiceManager overview COM Physician software Invoice Manager tarmed Validator COM Data Validation XML Data Modeler COM / XML OCR print Secure Communication (MediPort) Printer Server

7. netUpdate package

8. Hardware & Software requirements • Software • Windows 98 or higher • Windows 2000 or higher recommended • Note: Windows 95 is not supported by MSXML4 • Hardware • Pentium III 500 MHz • 100 MB free disk space • 128 MB RAM

9. Requested interface changes for final release • tarmedValidator • TP of assistant (ISearch) • Limitation information as in html-browser (ISearch) • All validators • RoleType enumeration values as in migelValidator

10. Versioning scheme • 1.00.001 Version number for example tarmedValidator100 001 build number (bugfixes, no interface change) 00 minor version (added features, interface change) 1 major version (heavy interface change) • Implications on physician software • Build number change: no impact on software (netupdate) • Minor change: software may adapt new interface • Major change: software must eventually adapt new interface

11. Schedule & information • Beta-Release • Available since 2.5.2002 • Final-Release for all modules and languages • 1.7.2002 • Download & documentation area • www.tarmed.net • www.xmldata.ch (schema files) • Mailing list, Support & FAQ • www.tarmed.net

12. Summary: win-win situation for all • physician • can produce a correct invoice according to the rules • has a free choice of the intermediate or print locally • software house • have to implement only one interface • Hiding of standards behind functional interfaces • insurance • receive high quality invoices • automated data processing is possible (XML or OCR invoices)

13. Excursion: XML & schema file validation • XSD schema files help to improve the quality of the invoice • mandatory elements and attributes can be requested • patterns can be set to allow only specific values <simpleType name="eanPartyType"> <restriction base="string"> <pattern value="(20[0-9]{11}|76[0-9]{11})"/> </restriction> </simpleType> • the MDInvoiceManager handles the XML generation and schema validation, however you should get familiar with the mandatory fields (www.xmldata.ch) pdf-File or xsd-File