GF # 14963 - Summary: Create a "lifecycle" status for Account
We currently have a "record status" (Account.status) on Account, however we do not have a "lifecycle status". During PA WGM Jan 30, while discussing tracker 14811, we wanted to create a separate tracker to add that, thus this tracker.
A proposed valueset for the new lifecycle status is below. This would likely be an Extensible binding.
Add a new property billingStatus 0..1 CodableConcept with the following extensible binding:
Open - The account is open for charging transactions (account.status is active)
CareComplete/Not Billed - The account.status is still active and may have charges recorded against it (only for events in the servicePeriod), however the encounters associated are completed. (Also known as Discharged not billed) This BillingStatus is often not used in ongoing accounts. (account.status is active)
Billing - Indicates that all transactions are recorded and the finance system can perform the billing process, including preparing insurance claims, scrubbing charges, invoicing etc. During this time any new charges will not be included in the current billing run/cycle. (account.status is active)
Closed-Bad Debt - The balance of this debt has not been able to be recovered, and the organization has decided not to persue debt recovery. (account.status is in-active)
Closed-Voided - The account was not created in error, however the organization has decided that it will not be charging any transactions associated. (account.status is in-active)
Closed-Completed - The account is closed and all charges are processed and accounted for. (account.status is in-active)
Closed-Combined - This account has been merged into another account, all charged have been migrated. This account should no longer be used, and will not be billed. (account.status is in-active)
The description of the property would be:
"The BillingStatus tracks the lifecycle of the account through the billing process. It indicates how transactions are treated when they are allocated to the account. (need to explain how it relates to account status)"
Should we add invariants to ensure that billingstatus is not used when account status is entered in error?
Should the Account.status also include a completed value?
Should we collapse both statuses into the 1 property.
Cooper moves to disposition this as persuasive, Drew seconds.
The chair asked if we should keep this joint quarter in the next WGM. Both agreed we should keep it