Child pages
  • Service Delivery Module
Skip to end of metadata
Go to start of metadata

 

Primary mentor

 

Backup mentor

 

Assigned to

 

Abstract

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

Project Champions

Roger 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

Service Data Model

Data Model

Service Delivery Data Model

 

 

 

  • No labels

1 Comment

  1. Roger mentioned

    This was discussed on a design call and the consensus was for an initial effort we should (1) postpone the location limitation until a later time, and perhaps remove either the highest level or lowest level of the 3 layers of concept selection; and (2) rather than have a separate table, have an obs group sufficient to hold the data fields. 

    Joaquim, when designing this, I particularly focused on identifying chargeable services, plus a communication mechanism to an external program.  Even if you build your tables of charges, bill preparation and payment receipt component on the OpenMRS framework, I would appreciate it if you would keep the partitioning in place. Also I would appreciate it if the communication to the billing side identified a responsible party (perhaps with a relationship) and an insurance plan and patient plan ID (person attributes) and perhaps an external program ID (person attribute). I think implementing this way would make it easier to integrate with OpenERP or an accounting package as the billing component.  Also, please keep the billing system service code IDs as  a concept source plus concept reference terms as shown in the data model so that more than one system can be operative at the same time -- like a fee-for-service or performance incentive system.