Post on 14-Feb-2017
© 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