Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Design Spec

 

UI Designs (Dropbox Link

 

Functional Spec

Introduction

The billing module is designed to be replacement and improvement for the existing billing module in use at JSS.

 

Goals

  1. Track payments for 
    1. Doctor's consultation
    2. Prescription drugs
  2. Allow flexible costs
    1. Doctors should be able to discount any drug price based on patient's individual needs and situation
  3. Support partial payments
    1. Patients must be able to pay only part of a bill during a given visit
    2. Patients are expected to pay remainder during one or more follow-up visit(s)
    3. Payments should be clearly separated and relate to specific items
  4. Resolve the pain points of the current billing system at JSS
    1. Difficult to track discounts, partial payments, insurance payments
    2. sometimes finances are associated with the wrong if paid later (insurance, partial payments)
    3. Problem with calculator for discounted payments – math is incorrect

Out of Scope

  1. Integration with other modules (May come into scope, later)
    1. Integrate with pharmacy
    2. Integrate with all other modules, as appropriate
  2. Support payment of insurance via RSBY

 

Functionality

 

Developer Spec

 

Database Design

Per an initial discussion, the database model may include the following tables. This needs more investigation before being confirmed.

Billing
status - pending, paid, partially paid, approved
patient
provider - whoever does the billing, e.g. clerk
has many: items

BillingItem
concept (concept - drug, labTest, etc)
quantity
how much it costs (value)
link to what made it - link to order ID or Encounter
provider
has many: item adjustments

BillingItemAdjustment
BillingItem
Reason
Value

Price
-concept
-quantity
-value

 

(Might need more columns for any item)

Please research existing billing tools and how they model:

(front-load is better..

research)

throughout:
commit write tests

*blog your experiences?
*


Need to be aware of when bills were issued and when bills were paid
-Insurance RSBY
-partial payments in visit 1, follow up payment in visit 2

1 or more default prices for each item

some things covered by RSBY, some not
-medication not covered by RSBY
-"toe cut off" is covered

Can we integrate into RSBY or other payment systems (NFC)?

Approval (before bill can be issued to the patient)
-> might have "auto approve default prices"
-> might have "auto approve discounted prices"
-> might "only allow prices to be "
vs 
Auditing (after the payment and everything has occured)
->
->

logging for later auditing
history of all price changes with name / date associated?

Open Issues:
(questions we don't know answers too... need input from JSS, others to answer them)

Repositories:
Backend Resources go into "RaxaCore"
Front-end Resources go into "Raxa-JSS"

TIMELINE:
Fri Aug 24: [Nathan] Complete short spec/designs on billing -- add to Wiki
Sat Aug 25 - Sun 26: Review existing billing modules in OpenMRS and lots of other billing systems... consider lots of possible alternatives
Mon Aug 27 - Tues 28: improve architecture plans (database tables needed), review UI to see if we have screens yet to meet JSS's needs 
Wed Aug 29: Call with JSS - review our designs

  • No labels