© 2011 TIBCO Software Inc. All Rights Reserved.

Paul C. Brown, TIBCO SoftwareJohn Kelly, NaviNet

David Querusio, Harvard Pilgrim Health Care

• Need for Action

• Reference Models and Reference Architectures

• Concept: Exploit the Natural Order of the Business Processes

• Example: Claim Processing

• What Needs to be Done?

• Summary

• Industry in flux

• Enterprises experimenting with different business models– Trying various combinations of roles: risk holder, plan manager, plan

administrator, care provider

• Health plans are often aggregates– Different business models, administration approaches, companies

• Monolithic COTS applications span multiple roles– Difficult to use for individual roles

• Business experiments are expensive:– Custom contracts, interface specifications, development work

• Process Model – The Process– The business view

• Architecture Pattern – The Structure– Also called architectural style– The IT view

• Process-Pattern Mapping – How the Solution Works– The business/IT alignment view

1. Bass et. al., Software Architecture in Practice, 2nd Edition, Addison Wesley

: Process-Pattern Mapping

: ArchitecturePattern

: ProcessModel

Architecture

• Activities and data flow• Business information models

– What does Order Status Result include?

Order Status Result

-addressLine1-addressLine2-city-state-country-postalCode

Address

-productID-qty-unitPrice-extendedPrice

Order Line Item

-orderID-orderDate-orderTotal-currentStatus

Order

-customerID-customerName

Customer-orderCustomer

-billTo

-shipTo

-lineItems *

enter order identification information

select "check order status"

submit order status request

display status result

look up order status

Initiate Order Status

Order Identification Information

Order Status Result

Order Status Request

• All major participants– Systems– People

• Communications channels

• Restrictions on componentsand channels

Order Management System

Internet Explorer or Firefox

TIBCO Business Works

Apache Tomcat

Customer

All back-end system access will be mediated via services

All application data persistence will be managed by the back-end system

Application servers will remain stateless

HTTP.WAN

proprietary API

SOAP/HTTP

keyboard/display

• Process model mapped onto architecture pattern– Some activities split across participants

select "check order status"

enter orderID

read result

display options

prompt for order ID

submit query request

display result

call query service

format result for display

"display status results" activities

interrogate back-end system

return query result

"lookup order status" activities

get order status

Customer Internet Exploreror Firefox

TIBCOBusiness

Works

Apache Tomcat Order ManagementSystem

• Standardized structure for solving a class of problems

– Reference Model – The Abstracted Work Process

– Architecture Pattern – The Abstracted Structure

– Process-Pattern Mapping – How the Abstracted Solution Works

: Reference Process-Pattern Mapping [1..*]

: Reference Architecture Pattern : Reference Process Model [1..*]

Reference Architecture

• The overall structure of health care business processes is consistent and stable

– Little variation in activity structure

• Logical roles in the process remain relatively stable– Changes usually sub-divide existing roles

• What varies is who plays which role

• Standardize business process reference models– Focus: Logical roles and their interfaces

• Standardize the process status reporting

• Leave architecture pattern and activity implementation unspecified

• Goal: flexible business models with transaction tracking– Improve response times– Improve quality of care– Reduce cost

Payer

Funds Provider

ClaimAcceptor

ClaimAdjudicator

ClaimRouter

ClaimPayer

Provider

ClaimSubmitter

ServiceProvider

ClaimPreparer

prepareclaim

submitclaim

Claim Submission Interface

acceptclaim

ClaimAcceptance

Interface

adjudicateclaim

ClaimAdjudication

Interface

provideclaim

paymentfunds

Funds Provisioning

Interface

provideservice

routeclaim

HIPAA 837Claim

Interface

payclaim

ClaimPaymentInterface

• HIPAA Provider-Payer Interface

• Incomplete - does not represent business sub-roles

• Custom extensions required for real business use– Typically 100 pages per interface

Traditional Payer ActivitiesTraditional Provider Activities

handle HIPAA 278 authorization

requests

HIPAA 278Authorization

Interface

handle HIPAA 270 Eligibility

requests

HIPAA 270EligibilityInterface

procedurepricingservice

ProcedurePricingServiceInterface

determineeligibilityservice

DetermineEligibilityServiceInterface

adjudicateclaim

ClaimAdjudication

Interface

submitclaim

ClaimSubmissionInterface

payclaim

ClaimPaymentInterace

provideclaim

paymentfunds

FundsProvisioning

Interface

provideservice

acceptclaim

ClaimAcceptance

Interface

prepareclaim route

claim

HIPAA 837Claim

Interface

Benefit Policy Administration

Authorization Limitation

Benefit Administrator

-authorizationPeriodExplicit Authorization

service count limit

serviceDollarLimit

Benefit Category

-startDate-endDate-claimAmount-paidAmount

Service InstanceType of Service

-taxID-NPI-payerSpecifcID-UPIN

Provider

ProviderType

Benefit Plan

Conditional

Limitations

Procedure Diagnosis

Member

Benefit

Policy

Non-processing support - deals with member issues, may redirect benefit administrator

the processor of claims

count limit on service provided

Entirely based on what is on claim

dollar value limit on paid services

-authorizationFor

-typeOfAuthorization

Requred

-requiredProcedures *

-limitations

-requiredProvider

*

-provides

-administeredBy1

-requiredDiagnosis *

-coveredPackage1..*

-requiredProviderType*

-paidServiceHistory *

-startDate-endDate-claimAmount-paidAmount

Service Instance

-taxID-NPI-payerSpecifcID-UPIN

Provider

Subscriber

Submitter

837 Claim

Member

Payer

Claim

Submitter may be a provider or an intermediary

-attendingProvider0..1

-adjustedService

lines

-billingProvider1

-initiallySubmittedServiceLines1..*

-servicingProvider1

Group

-groupedServices*

-serviceGroup

0..1

1..*-coverageThrough

1

*

1

1

servicingProvider

«enumeration»Provider-Service Role Type

atttendingProviderbillingProvider

«enumeration»Provider-Claim Role Type

claim preparersubmitterpayer

«enumeration»Administrative Role Type

-startDate-endDate-claimAmount-paidAmount

Service Instance

-taxID-NPI-payerSpecifcID-UPIN

Provider

Legal EntitySubscriber

837 Claim

MemberClaim

Administrative Role

Administrative Role

Provider-Claim Role

Provider-Claim Role

Provider-Service Role

Provider-Service Role

-adjustedService

lines

-initiallySubmittedServiceLines1..*

1..*

Group

-groupedServices*

-serviceGroup0..1

-coverageThrough

1

*

1

1

Traditional Payer Activities

Traditional Provider Activities

claim settlement process monitoring service

Claim StatusReporting Interface

Claim Status Query

InterfacehandleHIPAA claim

status query

HIPAA 276-277Claim Status

Interface

adjudicateclaim

ClaimAdjudication

Interface

prepareclaim

acceptclaim

ClaimAcceptance

Interface

provideservice submit

claim

ClaimSubmissionInterface

payclaim

ClaimPaymentInterace

provideclaim

paymentfunds

FundsProvisioning

Interface

routeclaim

HIPAA 837Claim

Interface

: Adjudicate Claim

: Provide ClaimPayment Funds

: HIPAA 837 Claim Interface

: Claim StatusReportingInterface

: Accept Claim

: Funds Provisioning

Interface

: Route Claim

: ClaimAdjudication

Interface

: ClaimAcceptance

Interface

: Pay Claim

: ClaimPaymentInterface

Health Care Nameplate Company

: Adjudicate Claim

: Accept Claim

: ClaimAdjudication

Interface

: ClaimAcceptance

Interface : Pay Claim

: ClaimPaymentInterface

Vision Care Company

• Standardize High-level Process Models– Standardize major roles, major activities, interactions – Standardize major interfaces and coordination patterns– Develop milestone-level tracking states– Identify and accommodate:

– Variations in process structure– Variations in individual activities (black box perspective)

• Abstract Shared Functionality as Business Services– e.g. Eligibility, Procedure pricing

• Use models to validate data structures and interfaces– Ability to handle common variations

• Activities, activity relationships, and roles remain relatively constant within a process

– Empirical observation of business process evolution over four decades– What commonly changes:

– Who plays each role– Sequencing of activities without dependencies– Occasional introduction of a new activity– Formatting of information and interfaces

• Process structure provides framework for validating:– Interfaces– Data structure information content

• Track ongoing progress at Harvard Pilgrim Health Care

• Identify appropriate industry working group(s) – HL7– Joint Initiative Council (JIC)– … Open for suggestions!

• Merge work

• Give us your feedback at healthcarereferencearchitecture.com

• Business model evolution can be facilitated by standardizing business processes and role-based interfaces

• The approach is being put into practice at Harvard Pilgrim Health Care

• More process focus is needed in health care– Interfaces are process artifacts, not information artifacts– Information is only valuable when used in a process