Solution Architecture Example: Nouveau Health Care Claim Payment Solution Architecture

This document presents an example Solution Architecture document. For brevity, some sections are intentionally left incomplete

http://www.tibco.com Global Headquarters 3303 Hillview Avenue Palo Alto, CA 94304 Tel: +1 650-846-1000 Toll Free: 1 800-420-8450 Fax: +1 650-846-1005
2008, TIBCO Software Inc. All rights reserved. TIBCO, the TIBCO logo, The Power of Now, and TIBCO Software are trademarks or registered trademarks of TIBCO Software Inc. in the United States and/or other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.

Document

Table of Contents
1 Business Objectives and Constraints ......................................................... 5
1.1 1.2 1.3 Quantified Business Expectations ....................................................................... 5 Business Constraints ........................................................................................... 5 Business Risks ..................................................................................................... 5

2 Solution Context ........................................................................................... 5 3 Business Process Inventory ........................................................................ 6 4 Domain Model................................................................................................ 7

4.1 4.2 4.3 4.4 Accounts and Funds Transfers ............................................................................ 7 Settlement Accounts ............................................................................................ 8 Settlement Concepts ............................................................................................ 8 Payment Domain Concepts ................................................................................. 9

5 Solution Architecture Pattern .................................................................... 10 6 Processing Claims from Providers............................................................ 11

6.1 6.2 Business Process Design .................................................................................. 11 Process-Pattern Mapping................................................................................... 11

7 Business Process 2 .................................................................................... 13 8 Business Process n .................................................................................... 13 9 Addressing Non-Functional Solution Requirements ............................... 13
9.1 9.2 9.3 9.4 Performance ....................................................................................................... 13 Availability within a Data Center ........................................................................ 13 Site Disaster Recovery....................................................................................... 15 Security .............................................................................................................. 16

10 Payment Manager Service .......................................................................... 16

10.1 Business Process Involvement .......................................................................... 16 10.2 Interfaces ........................................................................................................... 19 10.3 Observable Architecture..................................................................................... 20 10.4 Observable State ............................................................................................... 20 10.5 Coordination ....................................................................................................... 21 10.6 Constraints ......................................................................................................... 22 10.7 Non-Functional Behavior.................................................................................... 23 10.7.1 Performance ....................................................................................................... 23 10.7.2 Availability within a Data Center ........................................................................ 23 10.7.3 Site Disaster Recovery....................................................................................... 23 10.7.4 Security .............................................................................................................. 23

11 Claim Router ................................................................................................ 23

11.1 11.2 11.3 11.4 11.5 Business Process Involvement .......................................................................... 23 Interfaces ........................................................................................................... 24 Observable Architecture..................................................................................... 24 Observable State ............................................................................................... 25 Coordination ....................................................................................................... 25
2

Document Title Here

Document

11.6 Constraints ......................................................................................................... 25 11.7 Non-Functional Behavior.................................................................................... 25

12 Claim Processor .......................................................................................... 26

12.1 12.2 12.3 12.4 12.5 12.6 12.7 Business Process Involvement .......................................................................... 26 Interfaces ........................................................................................................... 27 Observable Architecture..................................................................................... 27 Observable State ............................................................................................... 27 Coordination ....................................................................................................... 27 Constraints ......................................................................................................... 27 Non-Functional Behavior.................................................................................... 27

13 Membership Service ................................................................................... 27

13.1 13.2 13.3 13.4 13.5 13.6 13.7 Business Process Involvement .......................................................................... 27 Interfaces ........................................................................................................... 28 Observable Architecture..................................................................................... 28 Observable State ............................................................................................... 28 Coordination ....................................................................................................... 28 Constraints ......................................................................................................... 29 Non-Functional Behavior.................................................................................... 29

14 Provider Service .......................................................................................... 29

14.1 14.2 14.3 14.4 14.5 14.6 14.7 Business Process Involvement .......................................................................... 29 Interfaces ........................................................................................................... 29 Observable Architecture..................................................................................... 29 Observable State ............................................................................................... 29 Coordination ....................................................................................................... 29 Constraints ......................................................................................................... 29 Non-Functional Behavior.................................................................................... 30

15 Benefits Service .......................................................................................... 30

15.1 15.2 15.3 15.4 15.5 15.6 15.7 Business Process Involvement .......................................................................... 30 Interfaces ........................................................................................................... 30 Observable Architecture..................................................................................... 30 Observable State ............................................................................................... 30 Coordination ....................................................................................................... 30 Constraints ......................................................................................................... 30 Non-Functional Behavior.................................................................................... 30

16 Banking Service .......................................................................................... 31

16.1 16.2 16.3 16.4 16.5 16.6 16.7 Business Process Involvement .......................................................................... 31 Interfaces ........................................................................................................... 31 Observable Architecture..................................................................................... 31 Observable State ............................................................................................... 32 Coordination ....................................................................................................... 32 Constraints ......................................................................................................... 32 Non-Functional Behavior.................................................................................... 32

17 Claim Tracker .............................................................................................. 32

17.1 Business Process Involvement .......................................................................... 32 17.2 Interfaces ........................................................................................................... 32 17.3 Observable Architecture..................................................................................... 32
Document Title Here 3

Document

17.4 17.5 17.6 17.7

Observable State ............................................................................................... 33 Coordination ....................................................................................................... 33 Constraints ......................................................................................................... 34 Non-Functional Behavior.................................................................................... 34

18 HTTP-JMS Mediation .................................................................................. 34

18.1 18.2 18.3 18.4 18.5 18.6 18.7 Business Process Involvement .......................................................................... 34 Interfaces ........................................................................................................... 34 Observable Architecture..................................................................................... 34 Observable State ............................................................................................... 34 Coordination ....................................................................................................... 34 Constraints ......................................................................................................... 34 Non-Functional Behavior.................................................................................... 34

19 Deployment ................................................................................................. 34
19.1 19.2 19.3 19.4 Deployment Environment Migration ................................................................... 34 Development Configuration ............................................................................... 34 Test Configuration .............................................................................................. 35 Production Configuration.................................................................................... 35

20 Integration and Testing Requirements ...................................................... 35

20.1 20.2 20.3 20.4 Integration Strategy ............................................................................................ 35 Behavioral Testing ............................................................................................. 35 Performance Testing .......................................................................................... 35 Performance Testing .......................................................................................... 35

Appendix A: Common Data Format Specifications ....................................... 35 Appendix B: Message Format Specifications ................................................ 35 Appendix C: Service Interface Specifications ............................................... 35 Appendix D: Data Storage Specifications ...................................................... 35

Document Title Here

Document

1 Business Objectives and Constraints

Nouveau Health Care is a traditional health care insurance company. It sells health care insurance policies and covers claim payments with the revenue it collects from its premiums. It also administers the processing of claims. There are some additional factors that add to the complexity of Nouveaus business. In some cases, the employers who provide the health care benefits for their employees also provide the funds for paying the claims: Nouveau administers the policies. In other cases the administration of specialized services (vision and dental care) is farmed out to other companies.

1.1 Quantified Business Expectations

For business reasons, Nouveau Health Care needs to be able to engage business partners specializing in claim payment processing for particular kinds of health care (e.g. vision, pharmaceuticals). The objective is to standardize the means by which Nouveau interacts with these business partners and implement a claim payment architecture based on that standard. In the first release, interactions with VisionCare (a business partner) will be implemented to allow them to process Nouveaus vision claims.

1.2 Business Constraints

It is expected that this project will take 18 months and involve a team of 25 full-time-equivalent Nouveau personnel over that time period, with a budget of $6million. VisionCare resources are not included in this budget, although they are committed to completing their side of the project in this time frame.

1.3 Business Risks

A failure in the processing of a single claim results in the need for manual intervention in the processing of the claim. This results in a 100x increase in the cost of processing a claim. Since there is only a 5% profit in the automated processing of a claim, a single manual process eliminates the profit from 2,000 automated processes. As a result, the overall failure rate of the automated process should be maintained at less than one in 100,000 claims. Nouveau Health Care processes 4.4 million claims a day. The cost of processing an electronic claim submission is $.85, while the cost of processing a paper claim is $1.85. The impact of the electronic process being unavailable is that the claim is likely to be submitted as a paper claim, with a resulting cost increase of $1.00 per claim. Since claims arrive during peak periods at a rate of 550,000 per hour, the cost of a system outage is $550,000 per hour. Consequently, the availability of the automated business process should be maintained at 99.995% with a maximum outage time of 5 minutes per incident. This allows a maximum of 5 outages/year, with anticipated annual outage costs totaling $230,000 per year. Reasonable investments that can further reduce this anticipated annual outage cost, and have a reasonable payback period, are desirable.

2 Solution Context
Nouveau Health Care is part of a larger environment that includes the health care service providers that submit claims and the partner companies that process some of the claims (Figure 2-1). Here we see that there can be more than one claim processor, which explains the need for the Claim Router.

Document Title Here

Document

: Billing Provider

: Nouveau Health Care : Claim Process Monitor : Banking Service

: Claim Router

: Nouveau Claim Processor

: Payment Manager

: Provider Service : Member Service : Benefits Service

: Partner Claim Processor

Figure 2-1 Nouveau Health Care in Context

3 Business Process Inventory

This solution focuses on four business processes (Figure 3-1): [lb] [lb] [lb] [lb] Validate Membership and its underlying Validate Membership Service Manage Payments, which manages claim payments to health care service providers. Process Claim, and its initiator, Route Claim, which together handle the processing of insurance claims. Monitor Claim Processing, a process that monitors the execution of claim processing.

TIBCO Architecture Fundamentals

: Validate Membership Service

Architecting Composite Applications and Services with TIBCO

: Claim Payment Request request : Manage Payments reply : Claim Payment Response

: Validate Membership

Architecting BPM Solutions with TIBCO

: Route Claim : Claim Submission : Process Claim

Architecting Complex Event Processing Solutions with TIBCO

: Event

processing events claim processing event : Monitor Claim Processing

Figure 3-1 Nouveau Health Care Business Processes

Document Title Here 6

Document

The Validate Membership process is used by authorized parties (health care providers, employers, and members) to validate whether or not an individual was covered by the policy on a given date. This business process utilizes an underlying Validate Membership Service, which is also used by the Process Claim business process. The Manage Payments process manages the payments to health care service providers resulting from health care claims.1 What makes this process interesting is that, under normal circumstances, payments are made on a periodic basis (e.g. monthly) to health care service providers. This means that the payment manager must keep track of pending payments. By exception, payments to health care service providers for specific claims may be made immediately. Process Claim and its related Route Claim process actually handle the processing of health care claims. Routing is required because some claims are processed by Nouveau itself while others are processed by partner companies. Process Claim is a consumer of both the Validate Membership Service and the services of the Payment Manager. Monitor Claim Processing keeps track of the progress of claim processing. The reason that this is necessary is that some claim processing is done by partner companies. Monitoring provides uniform tracking of all health care claims regardless of whether Nouveau or one of its partners is handling the claim.

4 Domain Model
4.1 Accounts and Funds Transfers
There are three types of bank accounts involved in the claims payment process: Payer Accounts, Provider Accounts, and Settlement Accounts. Each insurance policy has an associated Payer Account from which claims against the policy are paid. Each health care service provider being paid through funds transfers has a Provider Account. The Settlement Account is used as an intermediary account. When the Payment Manager is told to pay a claim, funds are moved immediately into the settlement account, regardless of when the provider is paid. Funds for providers are taken from this account. In the event that the provider is paid by check, the check is drawn on the Settlement Account. For audit reasons, it is necessary to keep track of the movement of funds between accounts. A Funds Transfer Record (Figure 4-1) is created for each transfer. Each record keeps track of the amount transferred, the source and destination accounts, the status of the transfer, and the timing of the transfer.

In the real world, the Manage Payments process would also manage payments to members, reimbursing them for claim-related expenses that they have already paid themselves. 7

Document Title Here

Document

Funds Tansfer Record -amount -dateTimeInitiated dateTimeConfirmed -transferSuccessful : Boolean

-sourceAccount -routingNumber -accountNumber

-targetAccount

Bank Account Reference

Figure 4-1 Funds Transfer Record Each Funds Transfer Record makes a copy of the account reference information at the time the funds transfer is initiated so that subsequent changes to the account information do not affect the record of past transfers.

4.2 Settlement Accounts

Each payment involves two Funds Transfer Records: the first captures the movement of funds from the payer account associated with the health care plan to a settlement account; the second captures the movement of funds from the settlement account to the provider account. By business rule, when the payment manager is told to pay a claim, the related funds are immediately moved from the payer account to the settlement account. The funds remain in the settlement account until the provider is actually paid.

4.3 Settlement Concepts

The concepts associated with settling a health care claim are shown in Figure 4-2. Each health care claim has a set of health care service instances, each one of which (if accepted) will eventually be associated with a provider settlement. When the Payment Manager is told to pay a claim, it associates the service instance with a Provider Settlement Record, transfers the associated funds to the settlement account, and records the service instance payment in the form of a funds transfer. This records the movement of funds from the individual health care plan to the settlement account. When the health care service provider is actually paid (which may be either immediate or deferred), a Settlement Payment is made. The payment may occur via a direct funds transfer or it may occur via check and be recorded by a Check Record.

Document Title Here

Document

Payment Requestor -paymentRequestorID 1 * Claim -claimID

-claimed Services 1..* Health Care Service Instance

...

-paid Service Instances Service Instance Payment 1..* 0..1

Provider Settlement Record -paymentID -paymentAmount -paymentStartDate -paymentCompletionDate

Service Instance Payment

-payment 0..1 Settlement Payment

-plan Transfers 1..* Funds Tansfer Record -transactionID

...

-providerTransfer 0..1 Funds Tansfer Record -transactionID

...

0..1 CheckRecord -checkNumber -checkAmount -dateIssued -payee

Figure 4-2 Settlement Concepts

4.4 Payment Domain Concepts

Putting it all together, we have a partial model of the payment domain concepts shown in Figure 4-3. This model indicates which services serve as systems of record for the various concepts. The issuer is the entity that sells the health care plan. The Benefits Service manages the benefits plan and keeps track of who is paying for services under the plan and what account these payments are taken from. The Provider service keeps track of health care service providers and the means by which they are to be paid. The Claim Service manages information about the health care claims, and the Payment Manager is responsible for managing the payments to service providers.2

In the real world, the payment manager would also manage reimbursements to plan members who paid for services out of their own pocket. 9

Document Title Here

Document

Provider Service Issuer Service Issuer -issuerID -IIN -issuer BenefitPlan -planID -payer Benefits Service -payer Bank Account Reference Account
...

Bank Account Reference -payment Account ... Payer -payerID

Provider -providerID -settlementDay -providerName

Address -payment -paid 1 Mailing Provider Address Payment Manager 1 -billing Provider

Agent Service Agent -agentID 1 -paymentRequestor -transactionID

...

Bank Account Reference Settlement ... Account -target Account -source Account Funds Tansfer Record -transactionID
...

Funds Tansfer Record

CheckRecord -checkNumber -checkAmount -dateIssued -payee

Claim Service * Claim -claimID

-plan 1..* Transfers -claimed Health Care Service Instance Service Instance Payment Services -serviceInstanceID 1..* -billedAmount -adjudicatedAmount -paid -paymentAuthorized : Boolean Service -amountToBePaid -settled : Boolean Instances Service Instance Payment -pendingPaymentAmount 1..* 0..*

-providerTransfer 0..1 Settlement Payment -payment 0..1

0..1

Provider Settlement Record -paymentID 0..1 -paymentAmount -paymentStartDate -paymentCompletionDate

Figure 4-3 Payment Domain Model (Partial) Note that from the Payment Manager perspective, the account reference information for both the plan and provider accounts comes from other services. When the Payment Manager uses this information, it is using a copy. If the copy is made immediately before the information is used, this is generally not a problem. However, if the copy is taken well in advance, consideration must be given to what should occur if the original information is updated. For example, consider what happens if the Payment Manager records the provider account at the time it is told to pay the claim. If the payment is deferred, it would be possible for the provider to change the account between this time and the time that the account is settled. How would the Payment Manager know about the account change?

5 Solution Architecture Pattern

The business processes of Nouveau Health Care are executed by a collection of components (Figure 5-1). The Claim Router provides an interface for the Billing Provider to submit claims. It validates membership with the Membership Service, routes claims to the Claim Processor, and reports status to the Claim Tracker. The Claim Processor (and there may be more than one) adjudicates the claim, validating membership via the Membership Service, requesting claim payment via the Payment Manager, and reporting status to the Claim Tracker. The Payment Manager pays the service providers, getting the account associated with the plan from the Benefits Service, the account associated with the health care service provider from the Provider Service, and using the Banking Service to make the payments. It also reports status to the Claim Tracker.

Document Title Here

10

Document

Billing Provider

: Claim Submission Interface Claim Router

...

: Claim Track Interface Claim Tracker

: Claim Processing Interface Claim Processor

: Membership Validation Service Interface Membership Service

: Claim Payment Interface

: Claim Payment Notification Interface

Payment Manager -pendingSettlements

...

: Provider Query Interface Provider Service

: Bank Service Interface Banking Service

: Benefits Query Interface Benefits Service

Figure 5-1 Nouveau Health Care Architecture Pattern

6 Processing Claims from Providers

Health care claims can be submitted by either the health care service provider or by the member to whom the service was provided. In the Nouveau Health Care example we focus on the claims submitted by providers and on the payments to those providers.

6.1 Business Process Design

In this example the business process design is not documented separately, but is represented in the process-pattern mapping of the next section.

6.2 Process-Pattern Mapping

Figure 6-1 presents an overview of the processing of claims submitted by health care service providers. This sunny-day scenario shows provider interactions via the US quasi-standard HIPAA transactions3 and shows deferred payments to the provider. The process model shows payer and provider account references, but not the details of the interactions with the Benefits Service and Provider Service required to obtain them. Similarly, it shows where membership is validated, but not the interactions with the Member Service that actually does the validation. Finally, for simplicity, all interactions with the Claim Tracker have been omitted.

In practice, each HIPAA transaction interface that is implemented by an enterprise is extended to accommodate the specific requirements of that enterprise. 11

Document Title Here

Document

Billing Provider submit claims

Claim Router HIPAA 837 claim set validate syntax validate billing provider structured for each claim validate membership determine claim processor

Claim Processor

Payment Manager

Bank Service

claim in standard format May indicate either acceptance or rejection submit to claim processor wait for response perform claim validation accept/reject notice

HIPAA 997 ACK

return ACK

determine whether service is covered price service update deductable and determine amount to be reimbursed and party to be reimbursed N manual review Y required? payer account reference May result in being billed as another service

receive 997 ACK

Delegation with multiple Confirmations

display for user, obtain manual edits and approval approved ? Y1 submit for payment request ACK

payment request structured for each service move funds to settlement account

funds transfer request

transfer funds

claim status HIPAA 277 send HIPAA 277 receive claim status update payment

wait for ack and update claim status

pending settlement provider account reference pay provider update claim status

funds transfer reply

send check request send check

Deligation with confirmation

claim status update receive payment update status and forward

send check reply

claim status update1

Alternatively, could be a funds transfer

close claim

Coordination Legend
synchronous interaction asynchronous interaction delegation interaction

Figure 6-1 Processing Claims from Providers

Document Title Here 12

Document

7 Business Process 2 8 Business Process n 9 Addressing Non-Functional Solution Requirements

9.1 Performance
Nouveau Health Care expects to handle up to 4.4 million claims per day. At peak times, claims will be submitted at a rate of 620 claims/second. The average claim payment request has three service instances, but requests associated with hospital stays (about 1% of the total) may contain several hundred service instances. Immediate payment requests account for about 1% of the total volume. The overall business process response time for an average request will be 8 seconds, and for a large request will be 120 seconds. There are 1.4 million providers associated with Nouveau. Each provider is typically paid once a month on a working day. Thus the Settle Deferred Payments process runs about 67,000 times a day. Each execution will complete in 8 seconds, and the full batch will be completed in four hours. At peak, the remaining Claim Payment Interface operations are each invoked 10 times/second and will provide a four second response time. Scenario Overall Scenario Time Budget 8 seconds Claim Router Time Budget 0.1 seconds Claim Processor Time Budget 3 seconds Payment Manager Time Budget 4 seconds Bank Service Time Budget .9 seconds

Immediate payment, small claim Immediate payment, large claim Deferred payment, small claim Deferred payment, large claim Settle deferred payments

120 seconds

0.2 seconds

60 seconds

60 seconds

.9 seconds

2 seconds to HIPAA 997 Ack 10 seconds to HIPAA 997 Ack 8 seconds per provider

0.1 seconds

1.9 seconds for accept/reject 9.8 seconds for accept/reject

N/A

0.2 seconds

7 seconds per provider

1 second

9.2 Availability within a Data Center

The claim processing business process must be available 99.995% of the time. This budgets to:
Document Title Here 13

Document

Table 1: Availability Budgets

Scenario

Availability

Claim Router Availability 99.999%, 24x7, 1 minute max outage per incident 99.999%, 6AM 12AM, 1 minute max outage per incident

Claim Processor Availability 99.999%, 24x7, 1 minute max outage per incident 99.999%, 6AM 12AM, 1 minute max outage per incident

Payment Manager Availability 99.999%, 24x7, 1 minute max outage per incident 99.999%, 6AM 12AM, 1 minute max outage per incident

Bank Service Availability 99.999%, 24x7, 1 minute max outage per incident 99.999%, 6AM 12AM, 1 minute max outage per incident

Claim processing submission and immediate payment Other processes

99.995%, 24x7, 5 minutes max outage per incident 99.995%, 6AM 12AM, 5 minutes max outage per incident

Document Title Here

14

Document

To avoid placing undue availability constraints on individual components, at least two of each component type will be deployed in a high-availability configuration (Figure 9-1). External interactions will occur using an HTTP transport with an IP redirector being used to route requests to the appropriate components. Internal communications within Nouveau Health Care will utilize JMS queues for communications.
Billing Provider Systems : Billing Provider HTTP

: IP Redirector

HTTP

: Claim Submission Interface JMS

: Claim Router [2..n]

Partner systems partner HTTP HTTP

partner reference : Claim Processing Interface

JMS

: Claim Processing Interface

: Claim Processor [2..n] JMS : Membership Validation Service Interface

: IP Redirector : Membership Service [2..n] HTTP JMS : HTTP-JMS Mediation [2..n] JMS : Claim Payment Interface : Claim Payment Notification Interface

JMS

: Payment Manager [2..n] JMS JMS JMS

: Claim Track Interface : Claim Tracker

: Provider Query Interface : Provider Service [2..n]

: Bank Service Interface : Banking Service [2..n]

: Benefits Query Interface : Benefits Service [2..n]

Figure 9-1 Deployment Pattern for High Availability The Claim Router presents an HTTP service interface, since it is intended to be used by external parties. All other interfaces will be SOAP/JMS except for the Claim Payment Notification Interface which will use XML/JMS. Partner requests for Claim Tracker and Payment Manager interfaces will use HTTP as a transport, and ActiveMatrix Mediation components will be used to move these requests to and from the JMS transport.

9.3 Site Disaster Recovery

In the event of a site disaster recovery, the recovery time objective for the claim processing business process is two hours, and the recovery point objective is 120 seconds. The budget for each component is
Document Title Here 15

Document

one hour recovery time objective and 60 seconds recovery point objective. Asynchronous replication of disks between the data centers will be used to keep the disaster recovery site up to date in near real time. Upon failover, all components at the disaster recovery site will be cold-started.

9.4 Security
All service invocations require certificate-based authentication and authorization using web service standards. In all cases, WS-Security will be used to encrypt the message body.

10 Payment Manager Service

10.1 Business Process Involvement
Under normal circumstances, payments are made to health care providers on a periodic (typically monthly) basis. These are referred to as deferred payments. Periodically a process runs to settle (pay) these deferred payments. By exception, claims can be paid immediately. This is generally done as a remedial action for claims that have been excessively delayed in processing for one reason or another. From this, we see that the Manage Payments process actually consists of three processes (Figure 10-1): Immediate Payment, Deferred Payment, and Settle Deferred Payments.
Manage Payments

Immediate Payment

Deferred Payment

Settle Deferred Payments

Figure 10-1 Manage Payments Processes

Document Title Here

16

Document

Claim Processor payClaim (Claim Payment Interface::)

Payment Manager : Pay Claim Request defaultSettlementAcc ount

Benefits Service

Provider Service

Banking Service

Claim Tracker

get settlement account structured For each service instance getPayerAccount (Benefits Query Interface::) return payer account

retrievedPlanAccount

get or create a provider settlement record Attempt to transfer requisite funds from plan account to settlement account newAccountingTransfer transfer plan funds

structured for each provider settlement record getProviderAccount (Provider Query Interface::) retrievedProviderAc count return provider account

Compute total of successful accounting transfers for this provider attempt to transfer sum from settlement account to provider account provider accounting transfer reportClaimStatus (Claim Track Interface::) update claim process status

transfer provider funds

: Pay Claim Response wait for response

return settlement report

completedProvider Settlement : Provider Settlement Record

Coordination Legend
synchronous interaction asynchronous interaction delegation interaction

Figure 10-2 Payment Manager Immediate Payment Process

Document Title Here 17

Document

Claim Processor payClaim (Claim Payment Interface::)

Payment Manager deferred request : Pay Claim Request

Benefits Service

Banking Service

Claim Tracker

defaultSettlementAccount

get settlement account structured For each service instance getPayerAccount (Benefits Query Interface::) : Bank Account Reference pendingSettlement : Provider Settlement Record obtain existing pending settlement or create one if one does not exist

return payer account

transferFunds (Bank Service Interface::) : Funds Tansfer Record

transfer payer funds

reportClaimStatus (Claim Track Interface::) pending payments : Pay Claim Response return pending payments

update claim process status

pendingSettlement : Provider Settlement Record

wait for promise

Coordination Legend
synchronous interaction asynchronous interaction delegation interaction

Figure 10-3 Payment Manager Deferred Payment Process

Document Title Here

18

Document

Claim Processor

Payment Manager at (settlement time) pendingSettlements : Provider Settlement Record

Provider Service

Banking Service

Claim Tracker

identify settlements to be completed

structured for each pending settlement Compute total of successful accounting transfers for this provider getProviderAccount (Provider Query Interface::) transferFunds (Bank Service Interface::) newTransfer return provider account transfer funds to provider account

This is an Out-Only interaction - requires a JMS queue

structured for each claim reportClaimStatus (Claim Track Interface::) update claim process status

deferred response : Pay Claim Response

send settlement report

process deferred response

completedSettlement : Provider Settlement Record

Coordination Legend
synchronous interaction asynchronous interaction delegation interaction

Figure 10-4 Payment Manager Settle Deferred Payments Process

10.2 Interfaces
The interfaces presented by the payment manager are shown in Figure 10-5 and detailed in the Payment Manager Specification document.

Document Title Here

19

Document

Claim Payment Interface +payClaim( request : Claim Payment Request ) : Claim Payment Response
...

Claim Payment Notification Interface +claimPaid( input : Claim Payment Response )

Payment Manager
...

Claim Payment Request -dateTime -immediatePayment : Boolean -paymentRequestorID

Claim Payment Response -dateTime -success : Boolean -paymentRequestorID

-service Instances ToBeSettled 1..* Service Instance Payment Input -claimID -serviceInstanceID -amountToBePaid -providerID -planID

-service Instance Settlement Results * Service Instance Payment Result -claimID -serviceInstanceID -paidAmount -pendingAmount

0..1 Error Result -errorCode -errorDescription

Figure 10-5 Payment Manager Service Interfaces for Claim Payment

10.3 Observable Architecture

The observable architecture of the payment manage is shown in Figure 5-1.

10.4 Observable State

The observable state of the payment manager is shown in Figure 10-6 and detailed in the Payment Manager Specification document.

Document Title Here

20

Document

Provider Service Issuer Service Issuer -issuerID -IIN -issuer BenefitPlan -planID -payer Benefits Service -payer Bank Account Reference Account
...

Bank Account Reference -payment Account ... Payer -payerID

Provider -providerID -settlementDay -providerName

Address -payment Mailing Address 1 -billing Provider

Agent -agentID 1 -paymentRequestor Claim Service * Claim -claimID

Payment Manager Observable State Bank Account Reference Payer Account

...

Bank Account Reference Settlement Bank Account Reference Provider ... ... Account Account -target Account -source Account -transactionID
...

-sourceAccount AgentRef -agentID 1

-target Account CheckRecord -checkNumber -checkAmount -dateIssued -payee

Funds Tansfer Record -transactionID

...

Funds Tansfer Record

1..*

-claimed Services1

* Claim Ref -claimID

-plan 1..* Transfers Service Instance Payment

-providerTransfer 0..1 Settlement Payment -payment 0..1

0..1

Health Care Service Instance -serviceInstanceID -billedAmount -adjudicatedAmount -paymentAuthorized : Boolean -amountToBePaid -settled : Boolean -pendingPaymentAmount 0..*

-planTransfers : Funds Tansfer Record [1..*]

Provider Settlement Record Service Instance Ref -serviceInstanceID -paid Service Instances Service Instance Payment 1..* 0..1 -paymentID -paymentAmount -paymentStartDate -paymentCompletionDate

-paid Provider Ref Provider -providerID -settlementDay 1

Figure 10-6 Payment Manager Observable State

10.5 Coordination
When immediate payment is requested, the service consumer (e.g. Process Claim) requests the payment using the synchronous request-reply coordination pattern (Figure 10-7). The response indicates whether or not the payments were successfully made.
Claim Processor activity prior to claim payment Payment Manager

Coordination Legend
immediate request : Claim Payment Request synchronous interaction asynchronous interaction delegation interaction

payClaim (Claim Payment Interface::)

pay all providers

activity after claim payment

completed payment report : Claim Payment Response

Figure 10-7 Immediate Payment Coordination

Document Title Here 21

Document

For Deferred Payment (Figure 10-8), the exchange between the service consumer and Payment Manager is the front end of a delegation with confirmation interaction. This portion of the interaction simply returns a promise to make the payments at some point in the future. The back end of the delegation with confirmation interaction is the Settle Deferred Payment process, which is triggered by a timer.
service consumer Payment Manager

Deferred Payment
activity prior to claim payment deferred request : Claim Payment Request record payments to be made

payClaim (Claim Payment Interface::)

activity after promise returned

pending payment report : Claim Payment Response

Coordination Legend Settle Deferred Payment

provider settlement time pay pending payments synchronous interaction asynchronous interaction delegation interaction

claimPaid (Claim Payment Notification Interface::) process settlement report completed payments : Claim Payment Response

Figure 10-8 Deferred Payment and Settlement Coordination

10.6 Constraints
There are some restrictions on the interactions that can occur: [lb] [lb] It is invalid to call the Claim Payment Notification Interface claimPaid() operation for a claim for which the Claim Payment Interfaces payClaim() operation has not been invoked. It is invalid to call the Claim Payment Interface cancelPendingPayments for a claim for which: [lb] payClaim() has not been called [lb] The payment has already been made

In a full specification, the triggered behavior mappings would include scenarios to indicate what would happen in each of these circumstances.

Document Title Here

22

Document

10.7 Non-Functional Behavior

10.7.1 Performance
Nouveau Health Care expects to handle up to 4.4 million claims per day. At peak times, payClaim() deferred payment requests may arrive at a rate of 620 requests/second. The service will provide a two second response time during these peak periods for average requests. The average claim payment request has three service instances, but requests associated with hospital stays (about 1% of the total) may contain several hundred service instances. Response time for these requests will be 10 seconds. Immediate payment requests account for about 1% of the total volume. Response time for an average request will be four seconds, and for a large request will be 60 seconds. There are 1.4 million providers associated with Nouveau. Each provider is typically paid once a month on a working day. Thus the Settle Deferred Payments process runs about 67,000 times a day. Each execution will complete in 4 seconds, and the full batch will be completed in four hours. At peak, the remaining Claim Payment Interface operations are each invoked 10 times/second and will provide a four second response time.

10.7.2

Availability within a Data Center

The payClaim() and claimPaid() operations will be available 99.999% of the time on a 24x7 basis. There will be no scheduled outage times for this operation. Maximum outage time per incident is 60 seconds. The remaining Claim Payment Interface operations will be available 99.999% of the time from 6 AM through 12 AM Eastern time. Maximum outage time per incident is 60 seconds.

10.7.3

Site Disaster Recovery

In the event of a site disaster recovery, the recovery time objective for the Payment Manager is one hour, and the recovery point objective is 60 seconds.

10.7.4

Security

All invocations of the Claim Payment Interface operations require certificate-based authentication and authorization using web service standards. In all cases, WS-Security will be used to encrypt the message body.

11 Claim Router
This chapter will serve as both the specification and implementation architecture document for the Claim Router.

11.1 Business Process Involvement

Figure 11-1 shows the involvement of the Claim Router in claim processing.

Document Title Here

23

Document

Billing Provider BusinessConnect submit claims

Claim Router Business Works

Claim Processor

Provider Service

Membership Validation Service

HIPAA 837 claim set validate syntax validate billing provider structured for each claim validate membership determine claim processor validate membership return provider status

May indicate either acceptance or rejection HIPAA 997 ACK return ACK

submit to claim processor wait for response

claim in standard format

perform claim validation accept/reject notice

Delegation with multiple Confirmations

claim status

adjudicate claim

HIPAA 277

send HIPAA 277

update adjudication status and forward update payment status and close claim

pay claim

receive claim status update

claim status update

Figure 11-1 Claim Processor Involvement in Claim Processing

11.2 Interfaces
The details of the Claim Submission Interface have yet to be defined.

11.3 Observable Architecture

: Claim Router : Claim Submission Interface HIPAA EDI Manager : BusinessConnect private claim routing process : BusinessWorks Nouveau reference : Claim Processing Interface partner reference : Claim Processing Interface

Figure 11-2 Claim Router Architecture

Document Title Here 24

Document

11.4 Observable State

There is no observable state maintained by the router. Overall process state information is being maintained by the Claim Tracker.

11.5 Coordination
Coordination between the Claim Submitter and the Claim Router is Delegation with Confirmation.

11.6 Constraints
There are no constraints on the use of the interface.

11.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

Document Title Here

25

Document

12 Claim Processor
12.1 Business Process Involvement
Claim Router Claim Processor Payment Manager Member Service Provider Service Benefits Service Adjudicator

submit to claim processor

claim in standard format

validate membership validate provider May result in being billed as another service query plan price service

perform claim validation wait for response accept/reject notice

determine whether service is covered

price service

update deductable and determine amount to be reimbursed and party to be reimbursed N manual review Y required?

get deductable status update deductable

display for user, obtain manual edits and approval approved ? Y1 Delegation with two Confirmations submit for payment

review, edit, and approve

structured for each service move funds to settlement account

claim status

wait for ack and update claim status

request ACK

return HIPAA 277

provider settlement date

pay provider claim status update claim status update1 update status and forward update claim status

close claim

Coordination Legend
synchronous interaction asynchronous interaction delegation interaction

Document Title Here

26

Document

Figure 12-1 Claim Processor Participation in Claim Processing

12.2 Interfaces
The details of the Claim Processing Interface have yet to be defined.

12.3 Observable Architecture

The observable architecture for this component is depicted in Figure 5-1 and Figure 9-1.

12.4 Observable State

The observable state for this component has yet to be defined.

12.5 Coordination
Coordination is Delegation with Confirmation.

12.6 Constraints
The constraints on this component have yet to be defined.

12.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

13 Membership Service
13.1 Business Process Involvement
See Figure 11-1 and Figure 12-1.

Document Title Here

27

Document

13.2 Interfaces
Membership Validation Service Interface +validateMembership( ValidateMembershipRequest ) : ValidateMembershipReply

ValidateMembershipRequest

ValidateMembershipReply

-requests * Membership Data -healthPlanIssuerName : string -healtPlanIssueIdentifier : IIN -healthPlanIdentifier -memberName : string -memberIdentifier : MemberID -dateOfService : Date

-results * Membership Validation Result -healthPlanIssuerName : string -healtPlanIssueIdentifier : IIN -healthPlanIdentifier -memberName : string -memberIdentifier : MemberID -dateOfService : Date -memberIdentifierFound : boolean -membershipValidOnDate : boolean

Figure 13-1 Membership Validation Service Interface

13.3 Observable Architecture

HTTP web interface : SOAP/JMS Service Consumer HIPAA EDI HIPAA EDI interface : SOAP/JMS Service Consumer SOAP/JMS : Membership Validation Service Interface

: Membership Service

JDBC

: Member Database

other internal users : SOAP/JMS Service Consumer : Membership Validation Service Interface SOAP/HTTP1

SOAP/HTTP : Partner System

TBD

external service users : SOAP/HTTP Service Consumer [*]

other partners systems TBD [*]

Figure 13-2 Membership Service Observable Architecture

13.4 Observable State

The service is stateless. All relevant state is contained in the back-end systems.

13.5 Coordination
Coordination is synchronous request-reply.

Document Title Here

28

Document

13.6 Constraints
There are no constraints on the use of this service.

13.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

14 Provider Service
14.1 Business Process Involvement
See Figure 10-2 and Figure 10-4.

14.2 Interfaces
Provider Query Interface +getProviderAccount( request : Get Provider Account Request ) : Get Provider Account Reply

Provider Service

Get Provider Account Request -providerID

Get Provider Account Reply

-providerAccunt 0..1 Bank Account Reference -routingNumber -accountNumber

-error 0..1 Error Result -errorCode -errorDescription

Figure 14-1 Provider Query Interface

14.3 Observable Architecture

The observable architecture of this component has yet to be defined.

14.4 Observable State

This component is stateless. Relevant state lies in the underlying back-end systems.

14.5 Coordination
Coordination is synchronous request-reply.

14.6 Constraints
There are no constraints on the use of this service.
Document Title Here 29

Document

14.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

15 Benefits Service
15.1 Business Process Involvement
See Figure 10-2 and Figure 10-3.

15.2 Interfaces
Benefits Query Interface +getPayerAccount( request : Get Payer Account Request ) : Get Payer Account Reply

Benefits Service

Get Payer Account Request planID

Get Payer Account Reply

-payerAccount 0..1 Bank Account Reference -routingNumber -accountNumber

-error 0..1 Error Result -errorCode -errorDescription

Figure 15-1 Benefits Query Interface

15.3 Observable Architecture

The observable architecture of this component has yet to be defined.

15.4 Observable State

This service is stateless. Relevant state information lies in the underlying back-end systems.

15.5 Coordination
Coordination is synchronous request-reply.

15.6 Constraints
There are no constraints on the use of this service.

15.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

Document Title Here

30

Document

16 Banking Service
16.1 Business Process Involvement
See Figure 10-2 and Figure 10-4.

16.2 Interfaces
Bank Service Interface +transferFunds( request : Transfer Funds Request ) : Transfer Funds Response +sendCheck( request : Send Check Request ) : Send Check Response

Banking Service

Transfer Funds Request -transferAmount -requestID -requestDate

Transfer Funds Response

0..1 Funds Tansfer Record -amount -dateTimeInitiated dateTimeConfirmed -transferSuccessful : Boolean -transactionID -source Account Bank Account Reference -routingNumber -accountNumber

0..1 Error Result -errorCode -errorDescription

-sourceAccount 1 Bank Account Reference -routingNumber -accountNumber

1 -targetAccount Bank Account Reference -routingNumber -accountNumber

Bank Account Reference -routingNumber -accountNumber

Send Check Request -checkAmount -requestID -requestDate

Send Check Response

0..1 CheckRecord -checkNumber -checkAmount -dateIssued -payee

0..1 Error Result -errorCode -errorDescription

-sourceAccount 1 Bank Account Reference -routingNumber -accountNumber

-sourceAccount 1 Bank Account Reference -routingNumber -accountNumber

Figure 16-1 Bank Service Interface

16.3 Observable Architecture

The observable architecture for this component has yet to be defined.

Document Title Here

31

Document

16.4 Observable State

The observable state for this component has yet to be defined.

16.5 Coordination
Interaction with this component will use synchronous request-reply coordination.

16.6 Constraints
There are no constraints on the use of this service.

16.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

17 Claim Tracker
17.1 Business Process Involvement
See Figure 10-2, Figure 10-3, Figure 10-4, and Figure 11-1. The details of interacting with the Claim Processor have yet to be defined.

17.2 Interfaces
Claim Track Interface +reportClaimStatus( status : Claim Status Notification ) +trackClaim()

Claim Tracker

Claim Status Notification -claimID -status : ClaimStatus

Figure 17-1 Claim Tracker Interface

17.3 Observable Architecture

The claim tracker is a self-contained service.

Document Title Here

32

Document

17.4 Observable State

state machine Claim Process State Model [ Claim Process State Model]

Claim Submitted Claim Validated

Claim Rejected Member Issue

Provider Issue

Claim Accepted

Service Issue

Service Adjudication Begun Service Adjudication Complete Claim Payment Complete

Claim Closed

Figure 17-2 Claim Tracker Observable State: Overall Claim Processing

state machine Claimed Service State Model [ Alternate Service Claimed Service State Model]

Service Presented

Service Covered

Service Not Covered

Service Priced

Service Paid

Figure 17-3 Claim Tracker Observable State: Individual Services on a Claim

17.5 Coordination
Interaction with the reportClaimStatus() operation is one-way (fire-and-forget). Interaction with the trackClaim() operation is synchronous request-reply.
Document Title Here 33

Document

17.6 Constraints
There are no constraints on the use of this service.

17.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

18 HTTP-JMS Mediation
18.1 Business Process Involvement
This component is involved as a supporting component for all interactions between the partners claim processor and Nouveaus Claim Tracker and Payment Manager.

18.2 Interfaces
See the Claim Tracker and Payment Manager interfaces.

18.3 Observable Architecture

This component will be an ActiveMatrix Service Bus node with Mediation components.

18.4 Observable State

The component is stateless.

18.5 Coordination
Coordination will be that specified for each of the referenced interfaces.

18.6 Constraints
There are no constraints on the use of this component.

18.7 Non-Functional Behavior

The non-functional requirements for this component are covered in Chapter 9.

19 Deployment
19.1 Deployment Environment Migration
The migration details are yet to be defined.

19.2 Development Configuration

This configuration is yet to be defined.

Document Title Here

34

Document

19.3 Test Configuration

This environment is yet to be defines.

19.4 Production Configuration

See Figure 9-1.

20 Integration and Testing Requirements

20.1 Integration Strategy
TBD

20.2 Behavioral Testing

TBD

20.3 Performance Testing

TBD

20.4 Performance Testing

TBD

Appendix A: Common Data Format Specifications Appendix B: Message Format Specifications Appendix C: Service Interface Specifications Appendix D: Data Storage Specifications

Document Title Here

35