The claim is the resources have to be presented using two different FHIR resources. Claim - contains base information about the claim (request), ClaimResponse - contains information which is the outcome of processing claim (response). In the table below you can find information where fields should be included (note! the response can contain the reference of request).
FHIR resources:
Request | Claim |
Response | ClaimResponse |
Fields mapping:
OpenIMIS field | DB type | Request or response | FHIR field | Description | Note | STPH |
ClaimID | PK | Request | claim.Identifier | this isn't required, most important is the ClaimCode (see below) but FHIR claim can has multi identifiers | ||
InsureeID | FK(tblInsuree) | Request | claim.patient - Reference(Patient) | We can represent the insuree as the FHIR patient resource but the most important is claim.patient.identifier | claim.patient.identifier | |
ClaimCode | nvarchar | Request | claim.Identifier | |||
DateFrom | smalldatetime | Request | claim.billablePeriod | |||
DateTo | smalldatetime | Request | ||||
ICDID | FK(tblICDCodes) | Request | claim.diagnosis | If ICD is some fixed set of coded value then we can use the CodeableCondept to describe this. The sequence field can be used to create an order of diagnosis. | ||
ClaimStatus | tinyint | Response | claimResponse.processNote | Default value: 2; 1 - rejected 2 - entered 4 - checked 8 - processed 16 - valuated | We can try to use the process note or create the FHIR extension (if needed) because the FHIR ClaimResponse STU3 haven't the type field. Alternatively we can use the claimResponse.status but then only 4 of 5 statuses can be mapped. | can be also request claim.status |
Adjuster | FK(tblUsers) | Request | claim.provider - Reference(Practitioner) | I'm not sure if this field is used, all records created by me have null values in that field. | ||
Adjustment | ntext | Response | claimResponse.disposition | |||
Claimed | decimal | Request | claim.total | |||
Approved | decimal | Response | claimResponse.totalBenefit | |||
Reinsured | decimal | Response | If needed we can create the FHIR extension. | |||
Valuated | decimal | Response | If needed we can create the FHIR extension. | |||
DateClaimed | date | Request | claim.created | default: getDate() | ||
DateProcessed | smalldatetime | Response | claimResponse.created | |||
Feedback | bit | default value: 0 | This is probably used only by OpenIMIS and I don't know if this is valuable for external systems. | |||
FeedbackID | FK(tblFeedback) | default value: 0 | ||||
Explanation | ntext | Request | claim.information.valueString | I couldn't find a better place for information about the explanation. The FHIR claim can consider multiple information elements. We can use the information category to distinguish the type of information. | ||
FeedbackStatus | tinyint | - | default value: 1 1 - idle 2 - not selected 4 - selected for feedback 8 - delicered 16 - by passed else select status | This field probably is used only by the OpenIMIS and isn't requirement by external systems. | ||
ReviewStatus | tinyint | - | default value: 1 1 - idle 2 - not selected 4 - selected for review 8 - reviewed 16 - by passed else select status | This field probably is used only by the OpenIMIS and isn't requirement by external systems. | ||
ApprovalStatus | tinyint | - | default value: 1; | Probably not used field | ||
RejectionReason | tinyint | Response | claimResponse.error | default value: 0 | I'm not sure if that field is used. | |
ValidityFrom | datetime | - | Audit information. More information can be found here (on page 113): https://github.com/openimis/openimis_docs/blob/master/specs/Web%20application%20-%20Functional%20Design%20Specification.pdf | This information are valuable for OpenIMIS but I probably not required by external systems. | ||
ValidityTo | datetime | - | ||||
LegacyID | int | - | ||||
AuditUserID | int | - | ||||
ValidityFromReview | datetime | Response | I'm not sure if this information are valuable for external systems. If needed we can try to use the claimResponse.processNote or add the FHIR extensions. | |||
ValidityToReview | datetime | Response | ||||
AuditUserIDReview | int | Response | ||||
RowID | timestamp | - | I'm not sure but this is probably some unique value used to distinguish database rows. Probably not useful for external systems. | |||
HFID | FK(tblHF) | Request | claim.facility - Reference(Location) | |||
RunID | FK(tblBatchRun) | - | This is probably useful only for the internal system not for external systems. If needed add the FHIR extension can be considered. | |||
AuditUserIDSubmit | int | Response | I'm not sure if this information are valuable for external systems. If needed we can try to use the claimResponse.processNote or add the FHIR extensions. | |||
AuditUserIDProcess | int | Response | ||||
SubmitStamp | datetime | Response | ||||
ProcessStamp | datetime | Response | ||||
Remunerated | decimal | Response | If needed we can create the FHIR extension. | |||
GuaranteeId | nvarchar | Request | claim.information.valueString | I couldn't find a better place for information about the guarantee Id. The FHIR claim can consider multiple information elements. We can use the information category to distinguish the type of information. | ||
ClaimAdminId | FK(tblClaimAdmin) | Request | claim.enterer - Reference(PractitionerRole) | |||
ICDID1 | int | Request | claim.diagnosis | If ICD is some fixed set of coded value then we can use the CodeableCondept to describe this. The sequence field can be used to create an order of diagnosis. | ||
ICDID2 | int | Request | claim.diagnosis | If ICD is some fixed set of coded value then we can use the CodeableCondept to describe this. The sequence field can be used to create an order of diagnosis. | ||
ICDID3 | int | Request | claim.diagnosis | If ICD is some fixed set of coded value then we can use the CodeableCondept to describe this. The sequence field can be used to create an order of diagnosis. | ||
ICDID4 | int | Request | claim.diagnosis | If ICD is some fixed set of coded value then we can use the CodeableCondept to describe this. The sequence field can be used to create an order of diagnosis. | ||
VisitType | char | Request | claim.type | E - emergency R - referrals O - other "" - select type | ||
ClaimCategory | char | - | I didn't find the logic related to this field. |
Note:
- The claim items (tblClaimItems) and services (tblClaimServices) can be represented as an FHIR "claim.item".
- Additional in the "insurance" field we can contain information about policies related to insuree (using Reference(Coverage)).