This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201801 Financial Management"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "[http://wiki.hl7.org/index.php?title=Category:201801_FHIR_Connectathon_Track_Proposals Return to January 2018 Proposals] Category:201801_FHIR_Connectathon_Track_Proposals|Se...")
 
 
(6 intermediate revisions by one other user not shown)
Line 5: Line 5:
 
__NOTOC__
 
__NOTOC__
 
=Financial Management=
 
=Financial Management=
 +
 +
*[https://drive.google.com/open?id=1sXe3sppykd8p2iHtc3GYKy4IH4BRWa5k Financial Management Track Orientation Slides]
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
Line 12: Line 14:
 
==Justification==
 
==Justification==
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
The FM resources for Claims and Reimbursement Resources are of interest internationally for implementing modern claim processing and connectathon exposure allows implementers to test and contribute to the resources as they are being readied to transition from Draft to DSTU.
+
The FM resources for Claims and Reimbursement Resources are of interest internationally for implementing modern claim processing and connectathon exposure allows implementers to test and contribute to the resources as they are currently STU.
 
Since September 2013 FM resources have gained maturity and been tested in many of the connectathons with increased complexity of the test scenarios with each successive connectathon.
 
Since September 2013 FM resources have gained maturity and been tested in many of the connectathons with increased complexity of the test scenarios with each successive connectathon.
 +
 +
==FHIR Version==
 +
For this Connectathon we will be using the FHIR R3 (3.0.2) specification due to bandwidth constraints for several of the constant participants. For May we expect to be using the current draft R4 build which will be frozen in April to support the Connectathon and STU ballot.
  
 
==Proposed Track Lead==
 
==Proposed Track Lead==
Line 26: Line 31:
 
:Almerys supporting most scenarios from the client and server perspectives
 
:Almerys supporting most scenarios from the client and server perspectives
 
:US Payors/Providers/Support (Optum, Blue Cross/Blue Shield, others TBD)
 
:US Payors/Providers/Support (Optum, Blue Cross/Blue Shield, others TBD)
 +
:CMS (BlueButton uses the ExplanationOfBenefit resource)
  
 
==Roles==
 
==Roles==
Line 75: Line 81:
 
==Scenarios==
 
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
Each of the scenarios shown below may be implemented via FHIR REST or simple HTTP Request-Response exchange of Resources. The expected Track testing will be via HTTP POST Request-Response with the resource, or exchangeable content in the body of the HTTP content.
+
Each of the scenarios shown below may be implemented via FHIR REST or simple HTTP (POST) Request-Response exchange of Resources with the target insurer (payor or payer) endpoint. The expected Track testing will be via HTTP POST Request-Response with the resource, or exchangeable content in the body of the HTTP content.
 +
 
 +
A FHIR Operation, $submit, has been defined to replace the simple HTTP (POST) for several of the request-style resources (EligibilityRequest, Claim, ProcessRequest) but it is expected there hasn't been sufficient time for implementers of claints and servers to implement this new exchange pattern for the 2018 January Connectathon. This operation is expected to replace the HTTP POST exchange for the 2018 May Connectathon.
 +
 
 
While XML and JSON are both valid for rendering the FHIR resources, XML is preferred for the official testing to ensure as many participants as possible are able to find one or more Clients or Servers to test against.  
 
While XML and JSON are both valid for rendering the FHIR resources, XML is preferred for the official testing to ensure as many participants as possible are able to find one or more Clients or Servers to test against.  
 
The testing scenarios shown below form the core of the "Financial" test track. There are eight test scenarios:
 
The testing scenarios shown below form the core of the "Financial" test track. There are eight test scenarios:
Line 151: Line 160:
  
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->
 
  
 
==Sample Data==
 
==Sample Data==

Latest revision as of 22:00, 22 January 2018

Return to January 2018 Proposals

Financial Management

Submitting WG/Project/Implementer Group

Financial Management Work Group

Justification

The FM resources for Claims and Reimbursement Resources are of interest internationally for implementing modern claim processing and connectathon exposure allows implementers to test and contribute to the resources as they are currently STU. Since September 2013 FM resources have gained maturity and been tested in many of the connectathons with increased complexity of the test scenarios with each successive connectathon.

FHIR Version

For this Connectathon we will be using the FHIR R3 (3.0.2) specification due to bandwidth constraints for several of the constant participants. For May we expect to be using the current draft R4 build which will be frozen in April to support the Connectathon and STU ballot.

Proposed Track Lead

Coordinator: Paul Knapp {Knapp Consulting Inc.} Skype: paulknapp Benoit Schoeffler {Almerys}

Zulip: Connectathon Mgmt / Connectathon 17 - Financial Track

Expected participants

Knapp Consulting - Client and Server supporting all scenarios including the Veteran Institutional Claim to VA Payor Scenario
Almerys supporting most scenarios from the client and server perspectives
US Payors/Providers/Support (Optum, Blue Cross/Blue Shield, others TBD)
CMS (BlueButton uses the ExplanationOfBenefit resource)

Roles

FHIR Client - Eligibility Submitter

Enable the creation and submission of the Eligibility resource and the receiving or obtaining of an EligibilityResponse.

FHIR Server - Eligibility Processor

Support the receiving and processing of the Eligibility resource and creation of the EligibilityResponse resource.

FHIR Client - Claims Submitter

Enable the creation and submission of the Claim resource and the receiving or obtaining of a ClaimResponse. This may be as a Pre-Authorization, Pre-Determination or a completed Claim for actual adjudication.

FHIR Server - Claims Processor

Support the receiving and processing of the Claim resource as a: Pre-Authorization; Predetermination; or, actual Claim; and creation of the ClaimResponse resource.

FHIR Client - Claims Attachment Submitter

Enable the creation and submission of the Communication resource and the receiving or obtaining of a ProcessResponse. This may be as supporting information for a Pre-Authorization, Pre-Determination or a completed Claim for actual adjudication.

FHIR Server - Claims Attachment Processor

Support the receiving and processing of the Communication resource as supporting information for a Pre-Authorization, Predetermination or actual Claim; and creation of the ProcessResponse resource.

FHIR Server - Claims Attachment Requestor

Support the receiving and processing of the ProcessRequest resource and return a CommunicationRequest resource for a previously received and pended Pre-Authorization, Predetermination or actual Claim.

FHIR Client - ProcessRequest Submitter

Enable the creation and submission of the ProcessRequest resource and the receiving or obtaining of a ProcessResponse. This may be to: request a Claim Reversal, request a deferred response, or a PaymentReconciliation or to obtain the processing status.

FHIR Server - ProcessRequest Processor

Support the receiving and processing of the ProcessRequest resource and creation of the ProcessResponse resource.

FHIR Server - PaymentReconciliation Processor

Support the receiving and processing of the ProcessRequest resource and creation of the PaymentReconciliation resource.

FHIR Server - Explanation of Benefit Processor

Support the receiving and processing of the ProcessRequest resource and creation of the ExplanationOfBenefit resource.

Scenarios

Each of the scenarios shown below may be implemented via FHIR REST or simple HTTP (POST) Request-Response exchange of Resources with the target insurer (payor or payer) endpoint. The expected Track testing will be via HTTP POST Request-Response with the resource, or exchangeable content in the body of the HTTP content.

A FHIR Operation, $submit, has been defined to replace the simple HTTP (POST) for several of the request-style resources (EligibilityRequest, Claim, ProcessRequest) but it is expected there hasn't been sufficient time for implementers of claints and servers to implement this new exchange pattern for the 2018 January Connectathon. This operation is expected to replace the HTTP POST exchange for the 2018 May Connectathon.

While XML and JSON are both valid for rendering the FHIR resources, XML is preferred for the official testing to ensure as many participants as possible are able to find one or more Clients or Servers to test against. The testing scenarios shown below form the core of the "Financial" test track. There are eight test scenarios:

  1. Submit an Eligibility, Retrieve/Receive an EligibilityResponse
  2. Submit a Pre-Authorization (Claim Resource) then an Attachment, Retrieve/Receive a ClaimResponse
  3. Submit a Claim, Retrieve/Receive a ClaimResponse :via REST (Create), Retrieve a ClaimResponse (Get) :via HTTP and Receive a ClaimResponse
  4. Submit Veteran Institutional Claim to VA Payor, Receive/Retrieve ClaimResponse
  5. Retrieve deferred ClaimResponse via ProcessRequest
  6. Retrieve the processing status (ProcessResponse) via ProcessRequest
  7. Retrieve a PaymentReconciliation via ProcessRequest
  8. Retrieve an ExplanationOfBenefit via ProcessRequest

You may select one or more of these testing scenarios - whatever appeals to you most given your particular context. We encourage you to execute these scenarios with varying test data, but the only test executions which can be assured are those using resources based on the data provided here.

Submit an Eligibility, Retrieve/Receive an EligibilityResponse

Action: The FHIR Client will construct a Eligibility resource. To obtain the EligibilityResponse for the submitted resource via FHIR REST the client with perform a GET on EligibilityResponse with search parameters which may be expected to select the intended response.
Precondition: None
Success Criteria: Eligibility processed correctly by the Server (inspect via browser or available UI)
Bonus point: return plan details in addition to the indication of whether the coverage is in force.

Submit a Pre-Authorization (Claim Resource) then an Attachment, Retrieve/Receive a ClaimResponse

Action: The FHIR Client will construct a Claim resource indicating Pre-Authorization. The service will respond with a ClaimResponse indicating only receipt not adjudication of the Claim (Pre-Authorization). To obtain the adjudicated ClaimResponse the client must then submit an Attachment (Communication resource) containing any supporting material to which the Server will respond with a ProcessResponse indicating success or failure with errors. Then the client may obtain the adjudicated ClaimResponse via the appropriate protocol. The ClaimResponse will contain an identifier which may be used during claim submission to indicate that the Pre-Authorization has been performed.
Precondition: None
Success Criteria: Pre-Authorization and Attachment processed correctly by the Server (inspect via browser or available UI)
Bonus point: For sending a business-appropriate form of attachment.

Submit a Claim via REST, Retrieve a ClaimResponse

Action: The FHIR Client will construct a Claim having either already submitted the supporting resources or with the supporting resources provided within the Claim as contained resources. To obtain the ClaimResponse for the submitted Claim the client with perform a GET on ClaimResponse with search parameters which may be expected to select the intended response.
Precondition: None
Success Criteria: Claim processed correctly by the Server (inspect via browser or available UI)
Bonus point: N/A

Submit a Claim via HTTP and Receive a ClaimResponse

Action: The FHIR Client will construct a Claim with the supporting information provided within the Claim as contained resources. The response to the Claim will be an OperationOutcome if the Claim cannot be understood or a ClaimResponse if it can.
If the priority=deferred then a ClaimResponse containing only errors or acknowledgement detail will be returned. The ClaimResponse containing adjudication details can be obtained later as the response to a ProcessRequest (action=poll) resource, for example: [base]/ClaimResponse?request.identifier=http://happyvalley.com/claim%7C1500
Precondition: None
Success Criteria: Claim processed correctly by the Server (inspect via browser or available UI)
Bonus point: N/A

Submit Veteran Institutional Claim to VA Payor, Receive/Retrieve ClaimResponse

Action: The FHIR Client will construct a Claim with the supporting information provided within the Claim as contained resources where the Claim is from an Institutional Provider to a VA Hospital for Emergency Services. The response to the Claim will be an OperationOutcome if the Claim cannot be understood or a ClaimResponse if it can.
Precondition: None
Success Criteria: Claim processed correctly by the Server (inspect via browser or available UI)
Bonus point: for performing a Pre-Authorization prior to the claim

Retrieve deferred ClaimResponse via ProcessRequest

Action: Submission of a ProcessRequest (action=poll) resource which contains a reference to the previously submitted claim will result in the creation, and perhaps return, of the ClaimResponse containing the adjudicated results of the previously submitted Claim.
Precondition: None
Success Criteria: ClaimResponse returned correctly by the Server and parsed and displayed in context by the Client
Bonus point: N/A

Retrieve the processing status (ProcessResponse) via ProcessRequest

Action: Submission of a ProcessRequest (action=status) resource which contains a reference to the previously submitted claim will result in the creation and perhaps return of the ProcessResponse containing the processing status of the previously submitted Claim.
Precondition: None
Success Criteria: ProcessResponse returned correctly by the Server (inspect via browser or available UI)
Bonus point: N/A

Retrieve a PaymentReconciliation via ProcessRequest

Action: Submission of a ProcessRequest (action=poll) resource which contains a reference to the ProcessRequest class of Resources will result in the creation and possible return of the PaymentReconciliation containing the payments for the previously submitted Claims.
Precondition: None
Success Criteria: PaymentReconciliation returned correctly by the Server (inspect via browser or available UI)
Bonus point: N/A

Retrieve an ExplanationOfBenefit via ProcessRequest

Action: Submission of a ProcessRequest (action=poll) resource which contains a reference to the ExplanationOfBenefit class of Resources and a period and Coverage will result in the creation and possible return of the ExplanationOfBenefit.
Precondition: None
Success Criteria: ExplanationOfBenefit returned correctly by the Server (inspect via browser or available UI)
Bonus point: N/A

Retrieve a Coverage resource from another FHIR Server

Action: GET a Coverage resource from another FHIR server for a test Patient.
Precondition: None
Success Criteria: Coverage retrieved correctly from the Server (inspect via browser or available UI)
Bonus point: GET the Coverage then submit a Claim or other eClaim request to the Insurer


Sample Data

Claims

Field Patient #1 Claim Patient #2 Claim
Claim Number 1500 1501
Processing Priority Normal Normal
Claim Type Oral Health Oral Health
Name John M. Smith (Usual) Judy F. Robinson (Usual)
Gender M F
Birthdate 1973-04-14 1993-06-24
Exceptions Full-time student (Code 1) at Rozdale University
Address 1234 Any Street

Menlo Park, California 90123

1 Landingpad Lane

Loma Linda, California 90310

Dentist Dr. Darryl Dentist (# 904563)

Happy Valley Clinic (# 1535)

Dr. Phil Amolar (# 678543)

Happy Valley Clinic (# 1535)

Referral Practitioner (# 720415)

Reason: Rampant decay (Code 7)

Insurance The Benefit Company (BINN# 654123)

Certificate: A7G345, Plan (Policy): 123YHT56 SubPlan: 35 Dependent: 01 Relationship: Self

Policy: Dental annual Individual Maximum of $2500, Basic Services at 80%, Major at 50%, no Orthodontic coverage

Health Management Corp (BINN# 564378)

Certificate: RF98765 Plan (Policy): GALACTIC Dependent: 04 Relationship: Child Frank Robinson born 1953-05-14

Policy: Dental annual Individual Maximum of $2500, Basic Services at 100%, Major at 80%, lifetime individual Orthodontic coverage $6000 Vision: $200 per year, Pharmacy: 20% co-pay, $3500 individual annual maximum.

Service Code, Fee, Tooth Surface, Lab#1 Code, Lab#1 Fee, Lab#2 Code, Lab#2 Fee
Service #1 1102, $65.00 1101, $55.00
Service #2 21211, $105.00, 21, L 2102, $730.00
Service #3 27211, $900.00, 22, , 99111, $250.00 21211, $105, 21, L
Service #4 21212, $200.00, 42, DI
Service #5 11101, $135.00

Services

Code Description Fee
1101 Exam, comp, primary 55.00
1102 Exam, comp, mixed 60.00
1103 Exam, comp, permanent 65.00
1201 Exam, comp, primary 45.00
1205 Exam, emergency 75.00
2101 Radiograph, series (12) 530.00
2102 Radiograph, series (16) 730.00
2141 Radiograph, bytewing 530.00
2601 Radiograph, panoramic 420.00
11101 Polishing, 1 unit 35.00
11102 Polishing, 2 unit 70.00
11103 Polishing, 3 unit 105.00
11104 Polishing, 4 unit 135.00
21211 Amalgam, 1 surface 105.00
21212 Amalgam, 2 surface 200.00
27211 Crown, PFM 900.00
99111 Lab, commercial 250.00
99333 Lab, in office 200.00
99555 Lab, Expense 0.00

TestScript(s)