1 / 20

Introduction

Introduction. Sumex I+ Quality assurance and electronic transfer of physician’s invoice. Schedule. Beta-Release as soon as possible Final-Release for all modules 1.5.2000 Download & documentation area www.tarmed.net www.xmldata.ch (schema files) Mailing list, Support & FAQ

Download Presentation

Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Schedule • Beta-Release • as soon as possible • Final-Release for all modules • 1.5.2000 • Download & documentation area • www.tarmed.net • www.xmldata.ch (schema files) • Mailing list, Support & FAQ • www.tarmed.net

  3. Goals of Sumex I+ • Reduction of costs by • improvement of quality • automated data acquisition and control • no media breaks • Realization by • tariff and drug validation • generation of standardized XML invoice • integration of electronic invoice transfer • integration of printing of standardized invoice form

  4. 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

  5. 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

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

  7. 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

  8. Interface definition - tarmedValidator • TarmedValidatorhandles connections to the Tarmed database • Catalogretrieval of catalog information from the Tarmed database for populating lists or combo boxes • Searchbrowsing of and retrieval of detailed information from the Tarmed database • Utilityautomatically generates service records for a given code • Validatechecks whether supplied service data conform to the Tarmed rules

  9. tarmedValidator browser & validate functionality Initialize module ITarmedValidator SetLanguage Initialize GUI ICatalog GetFirstUnit Quit? Set input data ITarmedInput PutPatSex Search data ISearch & IUtility SearchCode Validate data IValidate AddService

  10. recordTarmedType: fields to store in physician software • code • ref_code • quantity • date • number (session number) • ean_provider • ean_responsible • billing_role (both | mt | tt | none) • medical_role (self_employed | employee) • body_location (none | left | right) • external_factor.mt (default=1.0) • external_factor.tt (default=1.0) • validate • remark

  11. recordTarmedType: fields set by tarmedValidator • record_id • unit.mt • unit_factor.mt • scale_factor.mt • amount.mt • unit.tt • unit_factor.tt • scale_factor.tt • amount.tt • amount • vat_rate • anaesthesia (obsolete) • medical_indicated (obsolete) • ean_section (obsolete)

  12. Architectural blue print Invoice Manager Physician software Validator Factory Manager Factory Communication Factory Validators Communication Communication Insurance software

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

  14. Interface definition - MDInvoiceManager • IMDInvoiceRequestManagermanagement of the InvoiceRequests (creation and further processing) • IMDInvoiceRequestsetting the XMLContents (invoice standard) • IMDInvoiceResultproviding the invoice results • ITarmedInputsetting tarmed specific input data • IAddresssetting address data

  15. MDInvoiceRequestManager Physician software MDInvoiceRequestManager MDInvoiceRequestManager CreateStore Address Special Data MDInvoiceRequest PutValues MDInvoiceResult GetValues TarMedInput Special Data

  16. MDInvoiceRequestManager methods • CreateMDInvoiceRequest • Print • Store • Send • PrintAndStore

  17. MDInvoiceRequest methods • Initialize • CreateTarmedInput • CreateAddress • SetHeader, SetInvoice, SetESR, SetBiller, SetProvider, SetInsurance, SetPatient, SetGuarantor, SetReferrer, SetEmployer, SetTreatment, SetKVG, SetVVG, SetUVG, SetICG, SetMVG • AddDiagnosis, AddSurgery, AddTarmedService, AddTarmedServiceEx, AddCantonalService, AddLagService, AddDrugService, AddMigelService, AddPhysioService, AddUnclassifiedService

  18. netUpdate package

  19. 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 • 250 MB free disk space • 128 MB RAM

  20. 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)

More Related