Page tree
Skip to end of metadata
Go to start of metadata

Testing will occur on Thursday and Friday: in Saudi Arabia from 10am to 4pm Riyadh time (3am to 9am Eastern), then in North America from 9am to 11am Eastern (4pm to 6pm Riyadh).

Track overview

Short Description

This Track is focused on exercising the base FHIR resources to support eClaims (resources supporting: eligibility, prior authorization, claims, payment, cancellation and status check) and on the emerging specification for Saudi Arabia as it uses these resources to create and launch its national eClaims services as the Financial Services portion of the Saudi National Platform for Health Information Exchange Services (NPHIES).

Long Description

The FM resources for Claims and Reimbursement Resources are of interest internationally for implementing modern claim processing and connectathon exposure allows implementers to learn, test and contribute to the resources as they evolve. 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.

At this connectathon participants will also begin testing the Saudi Arabia profiles on these resources and the message exchange approach adopted by Saudi Arabia to support the exchange of eCLaims messages from Healthcare Providers (HCPs) through the NPHIES system to Health Insurance Companies (HICs).

Type

Test the design of a Resource/set of Resources (and begin the testing of Saudi localized profiles and terminology) 

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group

The Financial Management Work Group is responsible for the track and for the KSA Financial Services Implementation Guide which is in development.

Proposed Track Lead

Paul Knapp {Knapp Consulting Inc.} Skype: paulknapp,  

Benoit Schoeffler {Almerys}

Related tracks

None - typically if the Attachments Track is operating then we coordinate test exchanges.

FHIR Version

FHIR R4

Specification(s) this track uses

FHIR R4: http://hl7.org/fhir

Artifacts of focus

The FInancial services section of the track will use the resources as specified in FHIR R4 with the sample terminology and cases detail at the bottom of the page, the KSA trial exchanges will use the profiles and terminology from KSA.
KSA Technical Materials (Messages, Profiles, Terminology): https://www.cchi.gov.sa/en/Uniplat/Pages/default.aspx

Clinical input requested (if any)

For Providers and insurers worldwide input on the alignment of the FHIR Financial resources to the eCLaims requirements for your country is welcome and valued.

For KSA: HCP and HIC input on the input on the alignment of the KSA Technical Materials to their business requirements is always welcome and valued. 

Patient input requested (if any)

None at this time.

Expected participants

Knapp Consulting - Client and Server supporting all general FHIR R4 scenarios. emerging support for the KSA profiles

Almerys supporting all general FHIR R4 scenarios from the client and server perspectives

IQVIA focus on FHIR R4 and emerging support for the KSA profiles

Zulip stream

https://chat.fhir.org/#narrow/stream/179207-connectathon-mgmt/topic/Financial.20Track

Track Orientation

KSA Orientation: Wed Sep 9th 2020 at 10AM Riyadh time (9AM CET, Midnight Pacific, 3AM Eastern)

North America Orientation: Wed Sep 9th 2020 at 3PM Eastern time (9PM CET, Noon Pacific, 10PM Riyadh)

Track details

System Roles

eClaims Client: an application which creates eligibility requests, preauthorizations, claims and related exchanges and receives processed responses to those exchanges.

eClaims Server: an adjudication engine which receives and processes eligibility requests, preauthorizations, claims and related exchanges and returns processed responses to those exchanges.

eClaims Intermediate: a clearinghouse or networking system which interconnects eClaims Clients and Servers. It transports and validates exchanges but does not adjudicate the exchanges.

Typically any of the above applications will require weeks or months to develop or adapt an existing server to use the FHIR eClaims resources. However, a light client may be created by using Postman or a similar http-base submission program to send locally created claims, and other information requests, and receive processed responses. Samples of all of the requests may be provided to facilitate manual editing and exchange.

Role 1: Client - Eligibility Submitter

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

Role 2: Server - Eligibility Processor

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

Role 3: 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 Preauthorization, Predetermination or a completed Claim for actual adjudication.

Role 4: Server - Claims Processor

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

Role 5: Client - Claims Attachment Submitter

Enable the creation and submission of a Task containing a reference to the Communication resource and the receiving of a Task with the response. This may be as supporting information for a Preauthorization, Predetermination or a completed Claim for actual adjudication.

Role 6: Server - Claims Attachment Processor

Support the receiving and processing of a Task referencing a Communication resource as supporting information for a Preauthorization, Predetermination or actual Claim; and creation of the Task resource containing the response.

Role 7: Server - Claims Attachment Requestor

Support the receiving and processing of the Task resource and return a Task referencing a CommunicationRequest resource for a previously received and pended Preauthorization, Predetermination or actual Claim.

Role 8: Client - Task: Polling, Status Check Submitter

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

Role 9: Server - Task: Polling, Status Check Processor

Support the receiving and processing of the Task resource and creation of the Task response resource or provision of the requested resource.

Role 10: Server - PaymentReconciliation Processor

Support the receiving and processing of the Task (Poll) resource and creation of the PaymentReconciliation resource.

Role 11: Server - Explanation of Benefit Processor

Support the receiving and processing of the Task (Poll) resource and creation of the ExplanationOfBenefit resource.

Role 12: Intermediate - an eClaims Clearinghouse or Network

Support the receiving, validation and routine of the eClaims exchanges between Clients, Providers, and Servers, payors or Third Party Administrators.

Scenarios

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 a $submit operation where available, an HTTP POST Request-Response, with the resource, or exchangeable content, in the body of the HTTP content. 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 plus a ninth scenario for an application to act as an eClaims Intermediate for any or all of the eight test scenarios:

  1. Submit an Eligibility, Retrieve/Receive an EligibilityResponse :via $submit operation
  2. Submit a Pre-Authorization (Claim Resource) then an Attachment, Retrieve/Receive a ClaimResponse :via $submit operation
  3. Submit a Claim, Retrieve/Receive a ClaimResponse :via REST (Create), Retrieve a ClaimResponse (Get) :via HTTP and Receive a ClaimResponse
  4. Submit a Claim, Retrieve/Receive a ClaimResponse :via $submit operation
  5. Retrieve deferred ClaimResponse via Task :via $submit operation
  6. Retrieve the processing status via Task :via $submit operation
  7. Retrieve a PaymentReconciliation via Task :via $submit operation
  8. Retrieve an ExplanationOfBenefit via Task :via $submit operation

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.

Scenario 1: Submit an Eligibility, Retrieve/Receive an EligibilityResponse

Action: The FHIR Client will construct a Eligibility resource and use the $submit operation with the resource and receive an EligibilityResponse .

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.

Scenario 2: 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 and priority=deferred and use the $submit operation with the resource. The service will respond with a ClaimResponse indicating only receipt not adjudication of the Claim (Preauthorization). To obtain the adjudicated ClaimResponse the client must then submit an Attachment (Communication resource) containing any supporting material, using a Task and submission to a $submit operation, to which the Server will respond with a Task indicating success or failure with errors. Then the client may obtain the adjudicated ClaimResponse via polling, a Task with code=poll submitted via $submit. The ClaimResponse will contain an identifier which may be used during claim submission to indicate that the Preauthorization has been performed.

Precondition: None

Success Criteria: Preauthorization and Attachment processed correctly by the Server (inspect via browser or available UI)

Bonus point: For sending a business-appropriate form of attachment.

Scenario 3: 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 will 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

Scenario 4: Submit a Claim via $submit and Receive a ClaimResponse

Action: The FHIR Client will construct a Claim with the supporting information provided within the Claim as contained resources and submit the claim via $submit. 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 Task (code=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

Scenario 5: Submit a Claim via $submit and Receive a ClaimResponse

Step 1: Submit Claim and receive acknowledgement 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 Task (code=poll) resource, for example: 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

Step 2: Retrieve deferred ClaimResponse via Task

Action: Submission of a Task (code=poll) resource via a $submit operation 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

Scenario 6: Retrieve the processing status (Task) via Task

Action: Submission of a Task (code=status) resource via a $submit operation which contains a reference to the previously submitted claim will result in the creation and perhaps return of the Task containing the processing status of the previously submitted Claim.

Precondition: None

Success Criteria: Task returned correctly by the Server (inspect via browser or available UI)

Bonus point: N/A

Scenario 7: Retrieve a PaymentReconciliation via Task

Action: Submission of a Task (code=poll) resource via a $submit operationwhich contains a reference to the PaymentReconciliation 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

Scenario 8: Retrieve an ExplanationOfBenefit via Task

Action: Submission of a Task (code=poll) resource via a $submit operationwhich 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

Scenario 9: Operate as a Claims Intermediate

Action: The application shall receive submissions, validate the submission and route to the appropriate Server endpoint then obtain the response and return to the Client or any or all of the above scenarios.

Precondition: None

Success Criteria: See the success criteria for each of the above exchanges as the same would apply when conducted through an Intermediate.

Bonus point: N/A

Sample Data

Claims

FieldPatient #1 ClaimPatient #2 Claim
Claim Number15001501
Processing PriorityNormalNormal
Claim TypeOral HealthOral Health
NameJohn M. Smith (Usual)Judy F. Robinson (Usual)
GenderMF
Birthdate1973-04-141993-06-24
Exceptions
Full-time student (Code 1) at Rozdale University
Address1234 Any Street

Menlo Park, California 90123

1 Landingpad Lane

Loma Linda, California 90310

DentistDr. Darryl Dentist (# 904563)

Happy Valley Clinic (# 1535)

Dr. Phil Amolar (# 678543)

Happy Valley Clinic (# 1535)

ReferralPractitioner (# 720415)

Reason: Rampant decay (Code 7)


InsuranceThe 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 #11102, $65.001101, $55.00
Service #221211, $105.00, 21, L2102, $730.00
Service #327211, $900.00, 22, , 99111, $250.0021211, $105, 21, L
Service #4
21212, $200.00, 42, DI
Service #5
11101, $135.00

Services

CodeDescriptionFee
1101Exam, comp, primary55.00
1102Exam, comp, mixed60.00
1103Exam, comp, permanent65.00
1201Exam, comp, primary45.00
1205Exam, emergency75.00
2101Radiograph, series (12)530.00
2102Radiograph, series (16)730.00
2141Radiograph, bytewing530.00
2601Radiograph, panoramic420.00
11101Polishing, 1 unit35.00
11102Polishing, 2 unit70.00
11103Polishing, 3 unit105.00
11104Polishing, 4 unit135.00
21211Amalgam, 1 surface105.00
21212Amalgam, 2 surface200.00
27211Crown, PFM900.00
99111Lab, commercial250.00
99333Lab, in office200.00
99555Lab, Expense0.00


KSA Scenarios

The scenarios will be based on the readiness of participants.

TestScript(s)

None at this time.

Security and Privacy Considerations

All exchanges will be via HTTP without authentication or encryption to maximize the focus of the exchange of FHIR content to fulfill the eClaims business purposes.

Track Report Out 

*1 paragraph summary: what was the track trying to achieve

*1 list of participants (with logos if you have time and energy)

*systems which have implemented the IG, Profile, or Resource, and approximate percentage covered

*1 paragraph: notable achievements

*1-2 screenshots if relevant and interesting and/or links to further information about implementations/achievements

*1 paragraph: discovered issues / questions (if there are any)

*1 paragraph: now what?

  • No labels