Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

 

Table of Contents
maxLevel4
indent10px

Primary mentor

 

Backup mentor

 

Assigned to

 

...

Excerpt

The service delivery module is designed to collect billing and accounting data associated with patient encounters. This information is used by other systems to prepare patient or insurance invoices and statements, pay-for-performance statements, standard cost data, or monitoring & evaluation statistics. Data is exchanged with these other systems in three different ways: (1) uploading service definitions into OpenMRS; (2) transfers of service data relating to a single patient or provider from OpenMRS to the external system initiated by OpenMRS; (3) transfers of service data relating to one or more patients for a specified time period from OpenMRS to the external system initiated by the external system.

Type (1) transfers can be in multiple different are from including .xls or .csv or similar files ; type or from a connection database in which this data is pulled. In the first version of the this module, the later method will be used where data is entered into a database and then it is assumed that an integration engine like Mirth Connect is used to enter that data into OpenMRS. Type (2) and (3) transfers are by HL7, JSON or XML.

 

The Description below needs to be edited and described further

In addition, the module will raise an event when a new record is written containing the service data plus a configurable set of fields from related tables. Updates and deletions to service data are accomplished by new service data records reversing or adjusting the original transaction. Groups of services can be created for a hierarchical selection of services, and the module can be configured to permit certain service groups to be available only with services rendered at a particular location. Service sets can be created for quick selection of multiple services delivered together. A data entry screen should be available wherever patient encounters are available. The patient information page should allow viewing the patient's history of services received. The provider page should allow viewing the service delivery history of the provider.

Project Champions

Unlicensed user

Unlicensed user

Unlicensed userRoger Friedman

Darius Jazayeri

Joaquin Blaya

Objectives

1. Design a data model for the module
2. Design an administrative GUI for the module, the data entry form and the patient and provider history forms
3. Design message formats for the 3 types of data transfers and the event
4. Design a project plan setting for the sequence in which features will be developed
5. Develop the module
6. Develop taglibs for the creation and display of service delivery records in the design of HTML pages
7. Add HTML Form Entry tags for creating service delivery records.
8. Develop sysadmin and user documentation for the module.

Extra Credit

 

Resources

HISP India Billing Module

Use Case Diagram

Gliffy
nameService Data Model

Data Model

Gliffy
nameService Delivery Data Model