Added billing SRS and additional use cases to patient charting module

billing/Readme.md

@@ -0,0 +1,54 @@
+1. Module Scope
+---------------
+
+ABS covers the creation and management of patient billing accounts, primarily for the purpose of collecting charges and credits (financial transactions) to support the submission of a claim or invoice for reimbursement. A billing account will be associated with patient but it will be used for administrative purposes by the healthcare provider. ABS provides a consistent specification for accessing and managing billing repository, independent of the underlying technology stack. The following thematic areas are considered in scope for.
+
+* **Patient Billing Account:** 
+This is a set of functionality that provides the ability to manage patient billing accounts. Its functions include create a new billing account, updating and deleting an existing billing account, merging and unmerging accounts, closing inactive accounts and posting transaction into the selected account. These functions are generally protected and accessible by admitting clerk and patient with appropriate authorization.
+
+
+2. Module Perspective
+---------------------
+ABS is a subsystem of the SEMR which provides functionality of creation and management of patient billing accounts.  In addition, the ABS has interfaces to the external systems such PAS (Patient Administration Service), Insurance Agency and ABS enabled applications. Any details of an external system are out of scope of this document. The figure below shows decomposition of ABS (Accounts and billing service) on the functionality areas and the supported external systems.
+
+![proposed-architecture-for ABS](https://f.cloud.github.com/assets/5391320/1781332/ec2c8622-6891-11e3-90e5-b358d84cbc9d.png)
+
+3. Module Functions 
+-------------------
+The ABS is intended to allow the creation and management of a wide variety of functions related patient’s billing accounts, including, but not limited to, creation, deletion, updating and closing a billing account. This includes merging two related accounts and unmerging an account if merged accounts found unrelated as well as posting of financial transactions against a billing account for	 all the billable charges. At the functional level, the service interface will explicitly allow the query, creation and modification of the different accounts.
+
+4. User Classes and Characteristics 
+-----------------------------------
+Actors will use the billing service for different purposes. These different actors can be generalized into a basic ABS User an Actor that is simply an individual, organization, or application that requires access to content for some purpose. Specializations of the ABS User actor participate in additional operational specific scenarios. Actors described in this section are not necessarily human actors, but also include organizations and systems. Figure #3 outlines the specializations and composition of the different actors used in this specification. These actors are described below.
+
+![abs-user-classes](https://f.cloud.github.com/assets/5391320/1781339/3b1d4d8e-6892-11e3-826a-c095b1cd9d0a.png)
+
+The following actors take a role in the ABS actors:
+
+| **Name**        | **Description**               | **Responsibilities**                                         |      
+|-----------------|-------------------------------|--------------------------------------------------------------|
+|**ABS Service**  |ABS Server Instance            |The ABS Service is a specific implementation of the ABS Server.
+|**Admitting Clerk**|Primary Actor                |Admitting Clerk is an actor who is responsible for managing and accessing billing accounts as well as posting transitions to accounts.
+|**Patient**      |Secondary Actor                |Users belonging to this category are responsible for accessing his/her billing account’s full details.  
+|**Insurance  Agency**|Offstage Actor             |Insurance agency is an offstage actor who is interested in appropriate recording of billing information of relevant patients.
+
+5. System Features
+------------------
+Following are the system features of the ABS:
+
+![abs-use-case-diagram](https://f.cloud.github.com/assets/5391320/1781382/f467e79a-6892-11e3-9812-9afde3d69f59.png)
+
+###Appendix A: Analysis Models                                                                                      
+-----------------------
+Following is the Accounting and Billing DMIM from Hl-7:
+
+![abs-DMIM](https://f.cloud.github.com/assets/5391320/1781396/7aea1bf8-6893-11e3-9f01-0a349828c2e9.png)
+
+**Description:** The Patient Billing Account domain model encompasses all messages in the FIAB domain. This includes the setup and management of accounts (e.g. patient billing accounts) and the posting of financial transactions against those accounts (e.g. lab charge).
+
+Central to the domain model is the concept of an account, with attributes such as identifier, type (code), balance and the currency (e.g. US $) of the account. Associations to the account include patient identification (if the account is a patient billing account), insurance policy, encounter, and the optional specification of a guarantor for any outstanding balance in the account. 
+
+A Billing Account is an accumulator of financial and administrative information for the main purpose of supporting claims and reimbursement. Secondarily, the billing account may contribute significant information to cost accounting and financial decision support systems. A billing account is simply that entity that captures the elements reflecting the cost and price of services provided and supplies consumed for a healthcare activity. The focus for which an account accumulates information will vary. (For example: In a realm where billing is based on periodically collecting financial transactions for a patient, the accumulator might be the patient.) A billing account might also include links to insurance and benefit information, and relevant responsible parties. 
+
+Posting of charges is supplied through a financial transaction. In strictest accounting terms, the financial transaction would have a debit and credit association to 2 accounts (the debit account and the credit account). In this model, only 1 is specified, with a positive financial transaction amount used to add a charge, and a negative financial transaction amount used to negate (remove) a charge. The financial transaction is supported by a costing component (invoice element), which is further supported by the actual service that was performed or the product that was supplied (billable). To add to the balance of a patient billing account, the ActFinancialTransactionCode should be "CHRG" with a positive amount. To reduce this balance, the code would be "REV", again with a positive amount. 
+

billing/patient-billing-account/Readme.md

@@ -0,0 +1,35 @@
+####Description
+--------------
+A Billing Account is an accumulator of financial and administrative information for the main purpose of supporting claims and reimbursement. Secondarily, the billing account may contribute significant information to cost accounting and financial decision support systems. A billing account is simply that entity that captures the elements reflecting the cost and price of services provided and supplies consumed for a healthcare activity. The focus for which an account accumulates information will vary. (For example: In a realm where billing is based on periodically collecting financial transactions for a patient, the accumulator might be the patient.) A billing account might also include links to insurance and benefit information, and relevant responsible parties. 
+The system will provide user with the functionality to create and manage patient’s billing accounts. It will allow user to create a new billing account and update, delete and close an existing billing account. It will also provide user with merging and unmerging of billing accounts. 
+
+
+####Functional Requirements
+* REQ-1:	Create Billing Account
+* REQ-2:	Update Billing Account
+* REQ-3:  Nullify Billing Account
+* REQ-4:  Close Billing Account
+* REQ-5:  Merge Billing Accounts   
+* REQ-6:  Unmerge Billing Accounts
+
+_______________________________________________________________
+**Reference Hl7 RMIM (Domain: Accounts and Billing):**
+[More Details](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=306) 
+
+![fiab_rm010000uv](https://f.cloud.github.com/assets/5391320/1798109/c14f46d2-6b2b-11e3-883e-fb07792e242d.png)
+
+_______________________________________________________________
+**Reference FHIR Resource:**
+[More Details](http://www.hl7.org/implement/standards/fhir/resourcelist.html)
+
+N/A
+_______________________________________________________________
+**Reference CDA Template:**
+[More Details](http://www.hl7.org/Special/committees/structure/index.cfm)
+
+N/A
+_______________________________________________________________
+**Reference OpenEHR Archetypes (Version 1.4):**
+[More Details](http://www.openehr.org/ckm/)
+
+N/A

billing/patient-billing-account/create/AB01-create-billing-account.md

@@ -0,0 +1,32 @@
+#####Use Case ID: UC-AB01
+#####Use Case Name: Create Billing Account
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to create patient’s billing account primarily for the purpose of collection charges and credits (financial transactions).
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Billing account will be created successfully.
+
+**Frequency of Occurrence:**   High
+__________________________________________________________
+**Main Success Scenario: (Create Billing Account)**
+
+1.	AC requests for creating a patient billing account as result of patient admission.
+2.	System asks user to specify billing details such as coverage details, guarantor details, balance amount and status.
+3.	AC enters required information into the system.
+4.	System creates a patient account that may be used subsequently to collect charges and credits to support financial transactions, including billing specific to this hospital stay.
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000100UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A

billing/patient-billing-account/delete/AB03-nullify-billing-account.md

@@ -0,0 +1,32 @@
+#####Use Case ID: UC-AB03
+#####Use Case Name: Nullify Billing Account
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to nullify patient’s billing account.
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Billing account will be nullified successfully.
+
+**Frequency of Occurrence:**   High
+__________________________________________________________
+**Main Success Scenario: (Nullify Billing Account)**
+
+1.	AC requests system to nullify a billing account. 
+2.	System displays a list of accounts available.
+3.	AC specifies an appropriate account and updates account status to “obselete”.
+4.	System nullifies the specified account.  
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000100UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A

billing/patient-billing-account/update/AB02-update-billing-account.md

@@ -0,0 +1,41 @@
+#####Use Case ID: UC-AB02
+#####Use Case Name: Update Billing Account
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to update patient’s billing account.
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Billing account will be updated successfully.
+
+**Frequency of Occurrence:**   High
+__________________________________________________________
+**Main Success Scenario: (Update Billing Account)**
+
+1.	AC requests to update patient’s billing account information.
+2.	System displays the list the accounts available.
+3.	AC selects an appropriate account for update.
+4.	System asks user to modify the specified account’s information such as credit information, updated balance, guarantor role or updated account status.
+5.	AC modifies the fields of account and submits it.
+6.	System validates the fields and updates the patient’s billing account.
+
+______________________________________________________________________________
+**Alternate Flows**
+
+**Alt-1:** 
+
+1.	Invalid information cannot be entered.
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000100UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A

billing/patient-billing-account/update/AB04-close-billing-account.md

@@ -0,0 +1,34 @@
+#####Use Case ID: UC-AB04
+#####Use Case Name: Close Billing Account
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to close patient’s billing account on the basis of inactivity for a specified amount of time.
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Billing account will be closed successfully.
+
+**Frequency of Occurrence:**   High
+__________________________________________________________
+**Main Success Scenario: (Close Billing Account)**
+
+1.	AC selects an option of closing billing account.
+2.	System lists the available billing account and ask user to select a required one.
+3.	AC selects an appropriate account.
+4.	System displays account details as well as inactivity time span.
+5.	AC changes the status of an account to “Closed”.
+6.	System updates the billing account with updated status.
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000100UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A

billing/patient-billing-account/update/AB05-merge-billing-accounts.md

@@ -0,0 +1,33 @@
+#####Use Case ID: UC-AB05
+#####Use Case Name: Merge Billing Accounts
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to merge two related billing accounts. Note that once charges for an encounter have been posted to an account, that account can no longer be merged to an account created for a continuation of that encounter.
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Billing accounts will be merged successfully.
+
+**Frequency of Occurrence:**   Medium
+__________________________________________________________
+**Main Success Scenario: (Merge Billing Account)**
+
+1.	AC selects merge billing accounts option.
+2.	System displays the list of available patient’s billing account. 
+3.	AC selects two appropriate billing accounts for merging.
+4.	System merges the two accounts.
+
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000100UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A

billing/patient-billing-account/update/AB06-unmerge-billing-accounts.md

@@ -0,0 +1,33 @@
+#####Use Case ID: UC-AB06
+#####Use Case Name: Unmerge Billing Accounts
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to unmerge two unrelated billing accounts based on clerk finds out that the current diagnosis reveals a condition unrelated to the previous stay.
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Billing accounts will be unmerged successfully.
+
+**Frequency of Occurrence:**   Medium
+__________________________________________________________
+**Main Success Scenario: (Unmerge Billing Accounts)**
+
+1.	AC selects unmerge billing account option.
+2.	System displays the list of available patient’s billing account both merged and unmerged accounts. 
+3.	AC selects an appropriate merged account and asks system to unmerge it.
+4.	System successfully unmerges the billing accounts
+
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000100UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A

billing/post-patient-billing/Readme.md

@@ -0,0 +1,28 @@
+####Description
+--------------
+The developed application will provide user with the facility to post financial transaction against patient billing account. It includes accumulating stay charges, adjustments, and credits related to the services provided and items consumed.
+
+####Functional Requirements
+* REQ-1:	 Post Patient Billing
+
+_______________________________________________________________
+**Reference Hl7 RMIM (Domain: Accounts and Billing):**
+[More Details](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=306) 
+
+![fiab_rm020000uv](https://f.cloud.github.com/assets/5391320/1798260/281480f8-6b3b-11e3-8c17-5ab445ae8c4b.png)
+
+_______________________________________________________________
+**Reference FHIR Resource:**
+[More Details](http://www.hl7.org/implement/standards/fhir/resourcelist.html)
+
+N/A
+_______________________________________________________________
+**Reference CDA Template:**
+[More Details](http://www.hl7.org/Special/committees/structure/index.cfm)
+
+N/A
+_______________________________________________________________
+**Reference OpenEHR Archetypes (Version 1.4):**
+[More Details](http://www.openehr.org/ckm/)
+
+N/A

billing/post-patient-billing/create/AB07-post-patient-billing.md

@@ -0,0 +1,34 @@
+#####Use Case ID: UC-AB07
+#####Use Case Name: Post Patient Billing
+
+**Level:**                     User Level Goal
+
+**Primary Actors:**            Admitting Clerk (AC)
+
+**Stakeholders:**              Admitting Clerk, Patient, Healthcare Provider, Insurance Agency
+
+**Purpose:**                   The main intent of this use case is to post financial transactions against the billing accounts.
+
+**Pre Condition:**             AC must be identified and authenticated.
+
+**Post Condition:**            Financial transactions will be posted to patient’s billing account successfully.
+
+**Frequency of Occurrence:**   High
+__________________________________________________________
+**Main Success Scenario: (Post Patient Billing)**
+
+1.	AC selects an option to post financial transaction to patient’s account.
+2.	System displays list of available patient billing accounts.
+3.	AC selects an appropriate billing account.
+4.	System asks user to specify transaction details such as amount, account payer, reason, unit quantity, unit price etc  
+5.	AC specifies the required details and submits it.
+6.	System validates the information entered and posts financial transaction to the account. 
+
+________________________________________________________________________
+**Reference Hl7 V3 Interaction Identifiers (Domain: Accounting & Billing):**
+
+FIAB_ST000200UV02
+_______________________________________________________________
+**Reference CCHIT Criteria:**
+
+N/A