AbstractThe 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 including .xls or .csv or similar files 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.
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.
Use Case Diagram