Extending healthcare claims API

From PegaWiki
Extending healthcare API for integrations and interfaces / This is the approved revision of this page, as well as being the most recent.
Jump to navigation Jump to search

Extending healthcare claims API

Description Guidelines for extending Healthcare Claims API to accommodate external information
Version as of 8.7
Application Pega Smart Claims Engine for Healthcare
Capability/Industry Area Healthcare and Life Sciences



Concept[edit]

The REST integration interface in Smart Claims Engine (build on Pega platform) supports interactions with external systems through Web services. Service REST rules expose the REST APIs (GET, PUT and POST) that other applications can call to invoke action (send claim data, update claim data) or to retrieve claim data from the Smart Claims Engine (SCE).

The Claim API can also be used to send external claim-related data to Smart Claims Engine (SCE) using the repeating element supplementData. This element contains 6 tags out of the box which are mapped to the 6 properties in the chart below.

Before you begin[edit]

Refer to the Pega Healcare API section of the SCE Implementation guide to get stared. The service package ships with basic authentication but it is recommended to at least use Oauth 2.0 for a production environment.

Existing external information intake capability[edit]

SCE provides a design pattern which can be used and extended as needed to store and parse external claim-related information. Out of the box, there are six properties and two classes created to send and store external information. Clients can extend thee classes and add more properties as needed.

The two classes are:

  1. Data class: PegaHC-Data-Claimsupplement
  2. Integration class: PegaHC-Int-Claimsupplement

The six properties are:

Fields Example Type Limit
System External claim system Free form Text 12 characters
Record type Override external edit, error, or warning Free form Text 12 characters
External code AA for allowable amount Free form Text 12 characters
Value $100 Free form Text 12 characters
Field type Currency Free form Text 12 characters
Reason code MAN01 Free form Text 12 characters

Use case examples

External information such as specific claim pend codes representing error, warning situations as well as external system overrides codes can be referenced in the supplementData pagelist. Clients can also choose to extend to send external / custom information to SCE to support :

  1. Claim resolution
  2. Claims adjudication
  3. Claim routing
  4. Information pass through to other systems

Sample scenario 1[edit]

Consider a scenario in which a healthcare application needs to send SCE a claim with a error code (51303) set due to matching member issues in the third party system. The following information would be included on the inbound transaction.

  • External System: S1
  • Record Type: Error
  • Code: 51303

The expected SCE action would be to capture the additional information submitted on the claim. This would help the claims examiners to take the needed action(s) to resolve the claim.

Sample scenario 2[edit]

Consider another scenario in which a third party healthcare application sends claim information to SCE requesting the allowed amount to be overridden by $100 because of reason code MAN01 . The following information would be included on the inbound transaction.

  • External System: S1
  • Record Type: Override
  • Code: AA
  • Value: 100
  • Field type : Currency
  • Reason code: MAN01

The expected SCE action would be to capture the additional information submitted on the claim. This would help the claims examiners to take the needed action(s) to resolve the claim.

Note: If there are any properties whose value is more than 12 characters in length, then a work object in SCE will not be created, and an error response "Record type length should not exceed 12 characters" would be send back.

Process/steps to extend the capability to intake external information[edit]

  1. Create the needed properties (for external data) for the data layer in PegaHC-Data-ClaimSupplement class.
  2. Create the same properties (for external data) for the API layer in PegaHC-Int-ClaimSupplement class.
  3. Create PostMapToEntity_EXT rule in PegaHC-Data-ClaimSupplement and add required mappings by referring to mappings in MapToEntity of the PegaHC-Data-ClaimSupplement class

General guidelines[edit]

  • External information submitted for a claim may be viewed in the claims user interface by:
    • Clicking on Claim Header>Info from external system section.
    • Clicking on Claim Line>Info from external system section.
  • Familiarize yourself with the Pega Platform data model so that you can correctly format requests and understand responses from the Pega API.
  • Ensure that you have a robust API exception handling in place.
  • Evaluate the API design for performance.
  • You can unit test the Service REST rules from the service rule, service package rule, Swagger UI, and external clients.
  • Specific, defined extension points are provided for the Service REST rules to extend services for additional mapping from Pega Platform applications to maximize reuse. These specific extension points should be only the available rules; other implementation rules (and the Service REST rule itself) are marked as Final to ensure that they are easily upgradeable.

Reference materials on Community[edit]

  1. Pega Smart Claims Engine User Guide - Claim API integration
  2. Pega Foundation for Healthcare Implementation Guide - Extending mapping using the MapToEntity
  3. Pega Smart Claims Engine Implementation Guide - Pega Healthcare API