Solution Architecture Example

8/12/2019 Solution Architecture Example

1/35

http://www.tibco.com

Global Headquarters3303 Hillview AvenuePalo Alto, CA 94304Tel: +1 650-846-1000Toll Free: 1 800-420-8450Fax: +1 650-846-1005

2008, TIBCO Software Inc. All ri ghts 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.

Solution Architecture Example:Nouveau Health CareClaim Payment SolutionArchitecture

This document presents an example Solution Architecture document. For brevity,

some sections are intentionally left incomplete


2/35

Document

Document Title Here 2

Table of Contents

1 Business Objectives and Constraints ......................................................... 51.1 Quantified Business Expectations ....................................................................... 51.2 Business Constraints ........................................................................................... 51.3 Business Risks ..................................................................................................... 5

2 Solution Context ........................................................................................... 53 Business Process Inventory ........................................................................ 64 Domain Model ................................................................................................ 7

4.1 Accounts and Funds Transfers ............................................................................ 74.2 Settlement Accounts ............................................................................................ 84.3 Settlement Concepts ............................................................................................ 84.4 Payment Domain Concepts ................................................................................. 9

5 Solution Architecture Pattern .................................................................... 106 Processing Claims from Providers ............................................................ 11

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

7 Business Process 2 .................................................................................... 138 Business Process n .................................................................................... 139 Addressing Non-Functional Solution Requirements ............................... 13

9.1 Performance ....................................................................................................... 139.2 Availability within a Data Center ........................................................................ 139.3 Site Disaster Recovery....................................................................................... 159.4 Security .............................................................................................................. 16

10 Payment Manager Service .......................................................................... 1610.1 Business Process Involvement .......................................................................... 1610.2 Interfaces ........................................................................................................... 1910.3 Observable Architecture..................................................................................... 2010.4 Observable State ............................................................................................... 2010.5 Coordination ....................................................................................................... 2110.6 Constraints ......................................................................................................... 2210.7 Non-Functional Behavior.................................................................................... 2310.7.1

Performance ....................................................................................................... 23

10.7.2Availability within a Data Center ........................................................................ 2310.7.3Site Disaster Recovery....................................................................................... 2310.7.4Security .............................................................................................................. 23

11 Claim Router ................................................................................................ 2311.1 Business Process Involvement .......................................................................... 2311.2 Interfaces ........................................................................................................... 2411.3 Observable Architecture..................................................................................... 2411.4 Observable State ............................................................................................... 2511.5 Coordination ....................................................................................................... 25


3/35

Document


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

12 Claim Processor .......................................................................................... 2612.1 Business Process Involvement .......................................................................... 2612.2 Interfaces ........................................................................................................... 2712.3 Observable Architecture..................................................................................... 2712.4 Observable State ............................................................................................... 2712.5 Coordination ....................................................................................................... 2712.6 Constraints ......................................................................................................... 2712.7 Non-Functional Behavior.................................................................................... 27

13 Membership Service ................................................................................... 2713.1 Business Process Involvement .......................................................................... 2713.2 Interfaces ........................................................................................................... 2813.3 Observable Architecture..................................................................................... 2813.4 Observable State ............................................................................................... 2813.5 Coordination ....................................................................................................... 2813.6 Constraints ......................................................................................................... 2913.7 Non-Functional Behavior.................................................................................... 29

14 Provider Service .......................................................................................... 2914.1 Business Process Involvement .......................................................................... 2914.2 Interfaces ........................................................................................................... 2914.3 Observable Architecture..................................................................................... 2914.4 Observable State ............................................................................................... 2914.5 Coordination ....................................................................................................... 2914.6 Constraints ......................................................................................................... 2914.7 Non-Functional Behavior.................................................................................... 30

15 Benefits Service .......................................................................................... 3015.1 Business Process Involvement .......................................................................... 3015.2 Interfaces ........................................................................................................... 3015.3 Observable Architecture..................................................................................... 3015.4 Observable State ............................................................................................... 3015.5 Coordination ....................................................................................................... 3015.6 Constraints ......................................................................................................... 3015.7 Non-Functional Behavior.................................................................................... 30

16 Banking Service .......................................................................................... 3116.1 Business Process Involvement .......................................................................... 3116.2

Interfaces ........................................................................................................... 31

16.3 Observable Architecture..................................................................................... 3116.4 Observable State ............................................................................................... 3216.5 Coordination ....................................................................................................... 3216.6 Constraints ......................................................................................................... 3216.7 Non-Functional Behavior.................................................................................... 32

17 Claim Tracker .............................................................................................. 3217.1 Business Process Involvement .......................................................................... 3217.2 Interfaces ........................................................................................................... 3217.3 Observable Architecture..................................................................................... 32


4/35

Document


17.4 Observable State ............................................................................................... 3317.5 Coordination ....................................................................................................... 3317.6 Constraints ......................................................................................................... 3417.7 Non-Functional Behavior.................................................................................... 34

18 HTTP-JMS Mediation .................................................................................. 3418.1 Business Process Involvement .......................................................................... 3418.2 Interfaces ........................................................................................................... 3418.3 Observable Architecture..................................................................................... 3418.4 Observable State ............................................................................................... 3418.5 Coordination ....................................................................................................... 3418.6 Constraints ......................................................................................................... 3418.7 Non-Functional Behavior.................................................................................... 34

19 Deployment ................................................................................................. 3419.1 Deployment Environment Migration ................................................................... 3419.2 Development Configuration ............................................................................... 3419.3 Test Configuration .............................................................................................. 3519.4 Production Configuration.................................................................................... 35

20 Integration and Testing Requirements ...................................................... 3520.1 Integration Strategy ............................................................................................ 3520.2 Behavioral Testing ............................................................................................. 3520.3 Performance Testing .......................................................................................... 3520.4 Performance Testing .......................................................................................... 35

Appendix A: Common Data Format Specificat ions ....................................... 35Appendix B: Message Format Specif ications ................................................ 35Appendix C: Service Interface Specif ications ............................................... 35Appendix D: Data Storage Specif ications ...................................................... 35


5/35

Document


1 Business Objectives and ConstraintsNouveau Health Care is a traditional health care insurance company. It sells health care insurance policiesand covers claim payments with the revenue it collects from its premiums. It also administers theprocessing of claims.

There are some additional factors that add to the complexity of Nouveaus business. In some cases, theemployers who provide the health care benefits for their employees also provide the funds for paying theclaims: Nouveau administers the policies. In other cases the administration of specialized services (visionand dental care) is farmed out to other companies.

1.1 Quantified Business ExpectationsFor 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 Nouveaupersonnel over that time period, with a budget of $6million. VisionCare resources are not included in thisbudget, 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 ofthe claim. This results in a 100x increase in the cost of processing a claim. Since there is only a 5% profit inthe automated processing of a claim, a single manual process eliminates the profit from 2,000 automatedprocesses. As a result, the overall failure rate of the automated process should be maintained at less thanone in 100,000 claims.

Nouveau Health Care processes 4.4 million claims a day. The cost of processing an electronic claimsubmission is $.85, while the cost of processing a paper claim is $1.85. The impact of the electronic processbeing unavailable is that the claim is likely to be submitted as a paper claim, with a resulting cost increaseof $1.00 per claim. Since claims arrive during peak periods at a rate of 550,000 per hour, the cost of asystem outage is $550,000 per hour. Consequently, the availability of the automated business processshould be maintained at 99.995% with a maximum outage time of 5 minutes per incident. This allows amaximum of 5 outages/year, with anticipated annual outage costs totaling $230,000 per year. Reasonableinvestments that can further reduce this anticipated annual outage cost, and have a reasonable payback

period, are desirable.

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


6/35

Document


Figure 2-1

Nouveau Health Care in Context

3 Business Process InventoryThis solution focuses on four business processes (Figure 3-1):

[lb] Validate Membership and its underlying Validate Membership Service

[lb] Manage Payments, which manages claim payments to health care service providers.

[lb] Process Claim, and its initiator, Route Claim, which together handle the processing ofinsurance claims.

[lb] Monitor Claim Processing, a process that monitors the execution of claim processing.

Figure 3-1

Nouveau Health Care Business Processes

: Nouveau Claim Processor

: Claim Process Monitor

: Payment Manager

: Member Service

: Provider Service

: Benefits Service

: Banking Service

: Claim Router

: Nouveau Health Care

: Partner Claim Processor

: Billing Provider

Architecting BPM Solutions with TIBCO

Architecting Complex Event Processing Solutions with TIBCO

TIBCO Architecture Fundamentals Architecting Composite Applications and Services with TIBCO

: Monitor Claim Processing

: Claim Payment Response: Validate Membership

: Validate

Membership Service

: Manage Payments

: Process Claim: Claim Submission

: Claim PaymentRequest

: Route Claim

: Event claim processing event

request

processing events

reply


7/35

Document


The Validate Membership process is used by authorized parties (health care providers, employers, andmembers) to validate whether or not an individual was covered by the policy on a given date. This businessprocess utilizes an underlying Validate Membership Service, which is also used by the Process Claimbusiness process.

The Manage Payments process manages the payments to health care service providers resulting fromhealth care claims.1What makes this process interesting is that, under normal circumstances, payments aremade on a periodic basis (e.g. monthly) to health care service providers. This means that the paymentmanager must keep track of pending payments. By exception, payments to health care service providers forspecific 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 bypartner companies. Process Claim is a consumer of both the Validate Membership Service and the servicesof the Payment Manager.

Monitor Claim Processing keeps track of the progress of claim processing. The reason that this isnecessary is that some claim processing is done by partner companies. Monitoring provides uniformtracking 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, ProviderAccounts, and Settlement Accounts. Each insurance policy has an associated Payer Account from whichclaims against the policy are paid. Each health care service provider being paid through funds transfers hasa Provider Account. The Settlement Account is used as an intermediary account. When the PaymentManager is told to pay a claim, funds are moved immediately into the settlement account, regardless ofwhen 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 FundsTransfer 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.

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


8/35

Document


Figure 4-1

Funds Transfer Record

Each Funds Transfer Record makes a copy of the account reference information at the time the fundstransfer 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 thepayer account associated with the health care plan to a settlement account; the second captures themovement 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 immediatelymoved from the payer account to the settlement account. The funds remain in the settlement account untilthe provider is actually paid.

4.3 Settlement ConceptsThe concepts associated with settling a health care claim are shown in Figure 4-2. Each health care claimhas a set of health care service instances, each one of which (if accepted) will eventually be associated witha provider settlement. When the Payment Manager is told to pay a claim, it associates the service instancewith a Provider Settlement Record, transfers the associated funds to the settlement account, and records theservice instance payment in the form of a funds transfer. This records the movement of funds from theindividual 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 adirect funds transfer or it may occur via check and be recorded by a Check Record.

-amount-dateTimeInitiateddateTimeConfirmed-transferSuccessful : Boolean

Funds Tansfer Record

-routingNumber-accountNumber

Bank Account Reference

-sourceAccount-targetAccount


9/35

Document


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. Thismodel indicates which services serve as systems of record for the various concepts. The issuer is the entitythat sells the health care plan. The Benefits Service manages the benefits plan and keeps track of who ispaying for services under the plan and what account these payments are taken from. The Provider servicekeeps track of health care service providers and the means by which they are to be paid. The Claim Servicemanages information about the health care claims, and the Payment Manager is responsible for managingthe payments to service providers.2

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

own pocket.

-paymentID-paymentAmount-paymentStartDate-paymentCompletionDate

Provider Settlement Record

...

Health Care Service Instance

-transactionID...


-transactionID...


Settlement Payment

-paymentRequestorID

Payment Requestor

-checkNumber-checkAmount-dateIssued-payee

CheckRecord

-claimID

Claim

Service Instance Payment


-paidService

Instances

1..* 0..1

-planTransfers 1..*

-claimedServices 1..*

*

1

-providerTransfer 0..1 0..1

-payment 0..1


10/35

Document


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 usinga 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 theoriginal information is updated. For example, consider what happens if the Payment Manager records theprovider account at the time it is told to pay the claim. If the payment is deferred, it would be possible forthe provider to change the account between this time and the time that the account is settled. How would thePayment Manager know about the account change?

5 Solution Architecture PatternThe 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 membershipwith 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 viathe Membership Service, requesting claim payment via the Payment Manager, and reporting status to theClaim Tracker. The Payment Manager pays the service providers, getting the account associated with theplan from the Benefits Service, the account associated with the health care service provider from theProvider Service, and using the Banking Service to make the payments. It also reports status to the ClaimTracker.

Payment Manager

Benefits Service

Provider Service

Claim Service



Agent Service

-serviceInstanceID

-billedAmount-adjudicatedAmount-paymentAuthorized : Boolean-amountToBePaid-settled : Boolean-pendingPaymentAmount


...


...


...


-transactionID...


-transactionID...


Issuer Service

Settlement Payment


CheckRecord

-providerID-settlementDay-providerName

Provider

-planID

BenefitPlan-issuerID

-IIN

Issuer

-payerID

Payer

-claimID

Claim

SettlementAccount

Addr ess

-agentID

Agen t

0..*

-billingProvider

1-paidProvider

1



-paidService

Instances

1..* 0..1

-paymentAccount

-claimedServices

1..*

-paymentMailing

Address

-payerAccount

*

-paymentRequestor1

-issuer

0..1

-payer

-targetAccount

-sourceAccount

-payment 0..1

-planTransfers

1..* -providerTransfer 0..1


11/35

Document


Figure 5-1

Nouveau Health Care Architecture Pattern

6 Processing Claims from ProvidersHealth 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 byproviders and on the payments to those providers.

6.1 Business Process DesignIn 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 MappingFigure 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 transactions3andshows 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 obtainthem. Similarly, it shows where membership is validated, but not the interactions with the Member Servicethat actually does the validation. Finally, for simplicity, all interactions with the Claim Tracker have beenomitted.

3In practice, each HIPAA transaction interface that is implemented by an enterprise is extended to accommodate the specific

requirements of that enterprise.

Membership Service

: MembershipValidationServiceInterface

-pendingSettlements...

Payment Manager

: ClaimPaymentInterface

: Claim PaymentNotificationInterface

Claim Processor

: ClaimProcessingInterface

Provider Service

: ProviderQuery

Interface

Benefits Service

: BenefitsQuery

Interface

Banking Service

: BankServiceInterface

Billing Provider

Claim Tracker

: ClaimTrack

Interface

...

Claim Router

: ClaimSubmissionInterface


12/35

Document


Figure 6-1

Processing Claims from Providers

wait for ack and updateclaim status

update deductable anddetermine amount tobe reimbursed and

party to bereimbursed

display for user,obtain manual edits

and approval

determine whetherservice is covered

perform claimvalidation

price service

submit forpayment

update statusand forward

manualreview

required?

approved

?

Deligation withconfirmation

structured

for each service

move funds tosettlement account

pay provider

update claimstatus

Alternatively, could be a

funds transfer

May result in beingbilled as anotherservice

transfer funds

send check

submit claims

receivepayment

receive claimstatus update

receive 997 ACK

May indicate eitheracceptance orrejection

structured

for each claim

validatemembership

determineclaim

processor

submit to claimprocessor

wait forresponse

validate syntax

validate billingprovider

return ACK

send HIPAA 277

close claim

Delegation withmultipleConfirmations

Payment Manager Bank ServiceClaim RouterBilling Provider Claim Processor

payer account reference

claim in standard format

funds tr ansfer request

claim status update1

funds transfer reply

send check r equest

pending settlement

accept/reject notic e

claim status update

HIPAA 837 claim set

provider accountreference

payment request

send check reply

HIPAA 997 ACK

request ACK

claim status

payment

HIPAA 277

Coordination Legend

synchronousinteraction

delegationinteraction

asynchronousinteraction

N

Y1

Y


13/35

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 besubmitted at a rate of 620 claims/second.

The average claim payment request has three service instances, but requests associated with hospitalstays (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. Eachexecution 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 willprovide a four second response time.

Scenario Overall

Scenario Time

Budget

Claim Router

Time Budget

Claim

Processor

Time Budget

Payment

Manager

Time Budget

Bank Service

Time Budget

Immediatepayment, smallclaim

8 seconds 0.1 seconds 3 seconds 4 seconds .9 seconds

Immediatepayment, largeclaim

120 seconds 0.2 seconds 60 seconds 60 seconds .9 seconds

Deferredpayment, smallclaim

2 seconds toHIPAA 997Ack

0.1 seconds 1.9 seconds foraccept/reject

N/A

Deferredpayment, large

claim

10 seconds toHIPAA 997

Ack

0.2 seconds 9.8 seconds foraccept/reject

Settle deferredpayments

8 seconds perprovider

7 seconds perprovider

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:


14/35

Document


Table 1: Availability Budgets

Scenario Availability Claim Router

Availability

Claim

Processor

Availability

Payment

Manager

Availability

Bank Service

Availability

Claimprocessingsubmission andimmediatepayment

99.995%, 24x7,

5 minutes maxoutage perincident

99.999%, 24x7,1 minute maxoutage perincident




Other processes 99.995%, 6AM 12AM,

5 minutes maxoutage perincident

99.999%, 6AM 12AM, 1minute maxoutage perincident





15/35

Document


To avoid placing undue availability constraints on individual components, at least two of each componenttype will be deployed in a high-availability configuration (Figure 9-1). External interactions will occurusing 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.

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. Allother interfaces will be SOAP/JMS except for the Claim Payment Notification Interface which will useXML/JMS. Partner requests for Claim Tracker and Payment Manager interfaces will use HTTP as atransport, and ActiveMatrix Mediation components will be used to move these requests to and from theJMS transport.

9.3 Site Disaster Recovery

In the event of a site disaster recovery, the recovery time objective for the claim processing businessprocess is two hours, and the recovery point objective is 120 seconds. The budget for each component is

Partner systems

Billing Provider Systems

: Membership Service [2..n]

: Membership ValidationService Interface

: HTTP-JMS Mediation [2..n]

: Payment Manager [2..n]

: ClaimPaymentInterface

: Claim PaymentNotificationInterface

: Claim Processor [2..n]

: Claim ProcessingInterface

: Claim Router [2..n]

: ClaimSubmissionInterface

partner reference :Claim Processing

Interface

: Provider Service [2..n]

: Provider Query Interface

: Benefits Service [2..n]

: Benefits Query Interface

: Banking Service [2..n]

: Bank Service Interface

: Claim Tracker

: Claim Track Interface

: Billing Provider

: IP Redirector

: IP Redirector

partner

JMS

JMS

HTTP

JMS

JMS

JMS

JMS

JMS

JMS

JMS

HTTP

HTTP

HTTP

HTTP


16/35

Document


one hour recovery time objective and 60 seconds recovery point objective. Asynchronous replication ofdisks 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 SecurityAll service invocations require certificate-based authentication and authorization using web servicestandards. 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 deferredpayments. 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.

Figure 10-1

Manage Payments Processes

Settle Deferred PaymentsImmediate Payment

Manage Payments

Deferred Payment


17/35

Document


Figure 10-2

Payment Manager Immediate Payment Process

structured

for each provider settlementrecord

Compute total ofsuccessful accounting

transfers for this provider

attempt to transfer sumfrom settlement account to

provider account

reportClaimStatus

(Claim Track Interface::)

getProviderAccount

(Provider Query Interface::)

provider accountingtransfer

retrievedProviderAccount

structured

For each service instance

Attemp t to tr ansfer r equisi tefunds from plan account to

settlement account

get or create a providersettlement record

newAccountingTransfer

getPayerAccount

(Benefits Query Interface::)

retrievedPlanAccount

get settlementaccount

returnsettlement

report

return payeraccount

return provideraccount

transfer planfunds

transferprovider funds

update claimprocess status

payClaim

(Claim Payment Interface::)

wait forresponse

Payment ManagerClaim Processor

: Pay Claim Response

: Pay Claim Request

Claim Tracker

defaultSettlementAccount

Banking ServiceB en ef it s Ser vi ce Pr ov id er Ser vi ce

completedProviderSettlement :

ProviderSettlement Record

Coordination Legend





18/35

Document


Figure 10-3

Payment Manager Deferred Payment Process

payClaim


transfer payerfunds


structured

For each service instance

obtain existing pending s ettlementor create one if one does not exist

: Funds Tansfer Record

getPayerAccount

(Benefits Query Interface::)

transferFunds

(Bank Service Interface::)

pendingSettlement :Provider

Settlement Record

: Bank AccountReference

reportClaimStatus


get settlement account

return pendingpayments

return payeraccount

Payment Manager

deferred request : Pay Claim Request

Claim Processor

defaultSettlementAccount

Banking Service Claim Tracker Benefits Service

pendingSettlement: Provider

Settlement Record

Coordination Legend

pending payments :Pay ClaimResponse


wait forpromise




19/35

Document


Figure 10-4

Payment Manager Settle Deferred Payments Process

10.2 InterfacesThe interfaces presented by the payment manager are shown in Figure 10-5 and detailed in the Payment Manager

Specification document.

return provideraccount


structured

for each pending settlement

Compute total of successfulaccounting transfers for this provider

structured

for each claim

reportClaimStatus


newTransfer

getProviderAccount

(Provider Query Interface::)

transferFunds

(Bank Service Interface::)

identify settlements to be compl eted

at (settlement time)

sendsettlement

report

processdeferredresponse

This is an Out-Only

interaction - requires aJMS queue

transfer fundsto provider

account

Payment ManagerClaim Processor

completedSettlement :Provider Settlement Record

pendingSettlements :


Provider Service Banking Service Claim Tracker

deferred response: Pay ClaimResponse

Coordination Legend





20/35

Document


Figure 10-5

Payment Manager Service Interfaces for Claim Payment

10.3 Observable ArchitectureThe observable architecture of the payment manage is shown in Figure 5-1.

10.4 Observable StateThe observable state of the payment manager is shown in Figure 10-6 and detailed in the Payment Manager

Specification document.

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

Claim Payment Interface

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

-claimID-serviceInstanceID-paidAmount-pendingAmount

Service Instance Payment Result

-claimID-serviceInstanceID-amountToBePaid-providerID-planID

Service Instance Payment Input

-dateTime-success : Boolean-paymentRequestorID

Claim Payment Response

-dateTime-immediatePayment : Boolean-paymentRequestorID

Claim Payment Request

...

Payment Manager

-errorCode-errorDescription

Error Result

0..1

-serviceInstances

ToBeSettled1..*

-serviceInstance

SettlementResults *


21/35

Document


Figure 10-6

Payment Manager Observable State

10.5 Coordination

When immediate payment is requested, the service consumer (e.g. Process Claim) requests the paymentusing the synchronous request-reply coordination pattern (Figure 10-7). The response indicates whether ornot the payments were successfully made.

Figure 10-7

Immediate Payment Coordination

Payment Manager Observable State

Benefits Service

Provider Service

Claim Service



-serviceInstanceID-billedAmount-adjudicatedAmount-paymentAuthorized : Boolean-amountToBePaid-settled : Boolean-pendingPaymentAmount


...


...


...


...


...


-transactionID...


-transactionID...


-serviceInstanceID

Service Instance Ref

Issuer Service

Settlement Payment


CheckRecord

-providerID-settlementDay

Provider Ref

-providerID-settlementDay-providerName

Provider

-planID

BenefitPlan

-claimID

Claim

-payerID

Payer

-claimID

Claim Ref

-issuerID

-IIN

Issuer

-agentID

Agent Ref

ProviderAccountPayer

Account

SettlementAccount

Add ress

-agentID

Agent

0..*

-billingProvider

1

-planTransfers : Funds Tansfer Record [1..*]Service Instance Payment


-paidService

Instances

1..* 0..1

-paymentAccount

-paymentMailing

Address

-payerAccount-issuer

*

-paymentRequestor1

0..1

-payer

-claimedServices11..*

-paidProvider

1

*

1

-targetAccount

-planTransfers

1..*

-targetAccount

-sourceAccount -source

Account

-payment 0..1

-providerTransfer 0..1

Payment Manager

pay allproviders

payClaim


activity prior toclaim payment

activity afterclaim payment

Claim Processor

immediate request : ClaimPayment Request

completed payment report :Claim Payment Response

Coordination Legend





22/35

Document


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

Figure 10-8Deferred Payment and Settlement Coordination

10.6 Constraints

There are some restrictions on the interactions that can occur:

[lb] It is invalid to call the Claim Payment Notification Interface claimPaid() operation for aclaim for which the Claim Payment Interfaces payClaim() operation has not been invoked.

[lb] It is invalid to call the Claim Payment Interface cancelPendingPayments for a claim forwhich:

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

claimPaid

(Claim Payment Notification Interface::)

providersettlement

time

recordpayments to be

made

pay pending

payments

payClaim


activity after

promise returned

process

settlement

report

activity prior to

claim payment

Payment Managerservice consumer

pending payment report :

Claim Payment Response

completed payments : Claim

Payment Response

deferred request : Claim

Payment Request

Deferred Payment

Settle Deferred Payment

Coordination Legend


synchronous

interaction

delegation

interaction


23/35

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 twosecond response time during these peak periods for average requests.

The average claim payment request has three service instances, but requests associated with hospitalstays (about 1% of the total) may contain several hundred service instances. Response time for theserequests will be 10 seconds.

Immediate payment requests account for about 1% of the total volume. Response time for an averagerequest 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 monthon a working day. Thus the Settle Deferred Payments process runs about 67,000 times a day. Eachexecution 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 willprovide a four second response time.

10.7.2 Availabil ity within a Data Center

The payClaim() and claimPaid() operations will be available 99.999% of the time on a 24x7 basis. Therewill 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 AMthrough 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 andauthorization using web service standards. In all cases, WS-Security will be used to encrypt the messagebody.

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

11.1 Business Process InvolvementFigure 11-1 shows the involvement of the Claim Router in claim processing.


24/35

Document


Figure 11-1

Claim Processor Involvement in Claim Processing

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

11.3 Observable Architecture

Figure 11-2

Claim Router Architecture

validate syntax

return ACK

send HIPAA 277

Delegation withmultipleConfirmations

return providerstatus

submit claims

receive claimstatus update

May indicate eitheracceptance orrejection

validatemembership


adjudicate claim

pay claim

structured

for each claim

validatemembership

determineclaim

processor


wait forresponse

update paymentstatus and close

claim

validate billingprovider

updateadjudicationstatus and

forward

Claim Router

Business WorksBusinessConnect

Claim Processor Membership ValidationService

Provider ServiceBilling Provider

claim status update

HIPAA 837 claim set

claim in standardformat

accept/rejectnotice

HIPAA 997 ACK

claim status

HIPAA 277

private claim routingprocess :

BusinessWorks

HIPAA EDI Manager :BusinessConnect

: Claim Router

: Claim Submission InterfaceNouveau reference : Claim Processing Interface

partner reference : Claim Processing Interface


25/35

Document


11.4 Observable StateThere is no observable state maintained by the router. Overall process state information is being maintained by the

Claim Tracker.

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

11.6 ConstraintsThere are no constraints on the use of the interface.

11.7 Non-Functional BehaviorThe non-functional requirements for this component are covered in Chapter 9.


26/35

Document


12 Claim Processor


close claim


wait forresponse

return HIPAA277

Delegation withtwo Confirmations

wait for ack and updateclaim status

update deductable anddetermine amount tobe reimbursed and

party to bereimbursed

display for user,obtain manual edits

and approval

determine whetherservice is covered


price service

submit forpayment

update statusand forward

manualreview

required?

approved?

structuredfor each service

move funds tosettlement account

providersettlement date

pay provider

update claimstatus

May result in beingbilled as anotherservice

validateprovider

queryplan

price

service

review, edit,and approve

validatemembership

get deductablestatus

updatedeductable

Payment ManagerClaim ProcessorClaim Router

claim in standard format

claim status update1

accept/reject notice

claim status update

MemberService

Adj udi cato rBenefitsService

ProviderService

request ACKclaim status

Coordination Legend




N

Y1

Y


27/35

Document


Figure 12-1

Claim Processor Participation in Claim Processing

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

12.3 Observable ArchitectureThe observable architecture for this component is depicted in Figure 5-1 and Figure 9-1.

12.4 Observable StateThe observable state for this component has yet to be defined.

12.5 CoordinationCoordination is Delegation with Confirmation.

12.6 ConstraintsThe constraints on this component have yet to be defined.


13 Membership Service

13.1 Business Process InvolvementSee Figure 11-1 and Figure 12-1.


28/35

Document


13.2 Interfaces

Figure 13-1

Membership Validation Service Interface

13.3 Observable Architecture

Figure 13-2

Membership Service Observable Architecture

13.4 Observable StateThe service is stateless. All relevant state is contained in the back-end systems.

13.5 CoordinationCoordination is synchronous request-reply.

+validateMembership( ValidateMembershipRequest ) : ValidateMembershipReply

Membership Validation Service Interface

-healthPlanIssuerName : string-healtPlanIssueIdentifier : IIN-healthPlanIdentifier-memberName : string-memberIdentifier : MemberID-dateOfService : Date-memberIdentifierFound : boolean-membershipValidOnDate : boolean

Membership Validation Result

ValidateMembershipRequest

-healthPlanIssuerName : string-healtPlanIssueIdentifier : IIN-healthPlanIdentifier-memberName : string-memberIdentifier : MemberID-dateOfService : Date

Membership Data

ValidateMembershipReply

-requests *-results *

external service users :SOAP/HTTP Service

Consumer [*]

HIPAA EDI interface :SOAP/JMS Service

Consumer

HIPAA EDI

other internal users :SOAP/JMS Service

Consumer

web interface :SOAP/JMS Service

Consumer

HTTP

: MembershipService



: Member Database

: Partner System

other partners -systems TBD [*]

SOAP/JMS

SOAP/HTTP1

TBD

SOAP/HTTP

JDBC


29/35

Document


13.6 ConstraintsThere are no constraints on the use of this service.


14 Provider Service


14.2 Interfaces

Figure 14-1

Provider Query Interface

14.3 Observable ArchitectureThe observable architecture of this component has yet to be defined.

14.4 Observable StateThis component is stateless. Relevant state lies in the underlying back-end systems.



+getProviderAccount( request : Get Provider Account Request ) : Get Provider Account Reply

Provider Query Interface

-providerID

Get Provider Account Request Get Provider Account Reply



Provider Service


Error Result

-prov iderAccunt 0 ..1 -er ro r 0 ..1


30/35

Document



15 Benefits Service


15.2 Interfaces

Figure 15-1

Benefits Query Interface

15.3 Observable ArchitectureThe observable architecture of this component has yet to be defined.

15.4 Observable StateThis service is stateless. Relevant state information lies in the underlying back-end systems.




+getPayerAccount( request : Get Payer Account Request ) : Get Payer Account Reply

Benefits Query Interface

planID

Get Payer Account Request



Get Payer Account Reply

Benefits Service


Error Result

-payerAccount 0..1 -error 0..1


31/35

Document


16 Banking Service


See Figure 10-2 and Figure 10-4.

16.2 Interfaces

Figure 16-1

Bank Service Interface

16.3 Observable ArchitectureThe observable architecture for this component has yet to be defined.

+transferFunds( request : Transfer Funds Request ) : Transfer Funds Response+sendCheck( request : Send Check Request ) : Send Check Response

Bank Service Interface

-amount-dateTimeInitiated dateTimeConfirmed-transferSuccessful : Boolean-transactionID


Transfer Funds Response













-transferAmount

-requestID-requestDate

Transfer Funds Request

Send Check Response

-checkAmount-requestID-requestDate

Send Check Request

Banking Service


Error Result


Error Result


CheckRecord

-sourceAccount 1

-sourceAccount

0..1 0..1

-sourceAccount 1

-sourceAccount 1 -targetAccount1

0..1 0..1


32/35

Document


16.4 Observable StateThe observable state for this component has yet to be defined.

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



17 Claim Tracker17.1 Business Process InvolvementSee 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

Figure 17-1

Claim Tracker Interface

17.3 Observable ArchitectureThe claim tracker is a self-contained service.

+reportClaimStatus ( status : Claim Status Notification )+trackClaim()

Claim Track Interface

-claimID-status : ClaimStatus

Claim Status Notification

Claim Tracker


33/35

Document


17.4 Observable State

Figure 17-2

Claim Tracker Observable State: Overall Claim Processing

Figure 17-3

Claim Tracker Observable State: Individual Services on a Claim

17.5 CoordinationInteraction with the reportClaimStatus() operation is one-way (fire-and-forget). Interaction with the trackClaim()

operation is synchronous request-reply.

Claim Process State Model Claim Process State Modelstate machine [ ]

Member Issue

Provider Issue

Service Issue

Claim Rejected

Claim Closed

Claim Accepted

ServiceAdjud ication

Begun

ClaimSubmitted

Claim Payment

Complete

Claim Validated

ServiceAdjud ication

Complete

Claimed Service State Model Claimed Service State Modelstate machine [ ]

Service

Covered

Service

Presented

Alternate Service

Service Priced

Service Paid

Service Not

Covered


34/35

Document




18 HTTP-JMS Mediation

18.1 Business Process InvolvementThis component is involved as a supporting component for all interactions between the partners claim processor and

Nouveaus Claim Tracker and Payment Manager.

18.2 InterfacesSee the Claim Tracker and Payment Manager interfaces.

18.3 Observable ArchitectureThis component will be an ActiveMatrix Service Bus node with Mediation components.

18.4 Observable StateThe component is stateless.

18.5 Coordination

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

18.6 ConstraintsThere are no constraints on the use of this component.


19 Deployment

19.1 Deployment Environment MigrationThe migration details are yet to be defined.

19.2 Development ConfigurationThis configuration is yet to be defined.


35/35

Document

19.3 Test ConfigurationThis environment is yet to be defines.

19.4 Production ConfigurationSee Figure 9-1.

20 Integration and Testing Requirements

20.1 Integration StrategyTBD

20.2 Behavioral TestingTBD

20.3 Performance TestingTBD

20.4 Performance TestingTBD

Appendix A: Common Data Format Specifications

Appendix B: Message Format Specifications

Appendix C: Service Interface Specifications

Appendix D: Data Storage Specifications

Date post:	03-Jun-2018
Category:	Documents
Upload:	foxman2k
View:	241 times
Download:	4 times

Solution Architecture Example

Documents