Extending healthcare claims API
Extending healthcare claims API
Concept
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
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
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:
- Data class: PegaHC-Data-Claimsupplement
- 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 :
- Claim resolution
- Claims adjudication
- Claim routing
- Information pass through to other systems
Sample scenario 1
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
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
- Create the needed properties (for external data) for the data layer in PegaHC-Data-ClaimSupplement class.
- Create the same properties (for external data) for the API layer in PegaHC-Int-ClaimSupplement class.
- 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
- 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 updatable.