...
| OpenIMIS field | DB type | Request or response | FHIR field | Description | Note | STPH | Mapping status |
| ClaimID | PK | Request | claim.Identifier | this isn't required, most important is the ClaimCode (see below) but FHIR claim can have multiple identifiers | I would include ClaimUUID into the Claim instead of ClaimID. | mapped | |
| ClaimUUID | UK | Response | claim.Identifier | ||||
| 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 | mapped | |
| ClaimCode | nvarchar | Request | claim.Identifier | OK | mapped | ||
| DateFrom | smalldatetime | Request | claim.billablePeriod | OK | mapped | ||
| DateTo | smalldatetime | Request | mapped | ||||
| 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. | OK | mapped | |
| 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 a combination of claimResponse.status and claimResponse.outcome but limited in values. Extension required? | |
| 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. | Only reference to openIMIS user. | ||
| Adjustment | ntext | Response | claimResponse.disposition | claimResponse.payment.adjustment | |||
| Claimed | decimal | Request | claim.total | OK | mapped | ||
| Approved | decimal | Response | claimResponse.totalBenefit | OK | |||
| 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() | OK | mapped | |
| DateProcessed | smalldatetime | Response | claimResponse.created | If different endpoint to claimResponse, claimResponse.created will be the request date. Maybe claimResponse.payment.date | |||
| Feedback | bit | default value: 0 | This is probably used only by OpenIMIS and I don't know if this is valuable for external systems. External system might want to know if claim is pending for feedback. | No need. To see if replaced by FeedbackID | |||
| FeedbackID | FK(tblFeedback) | default value: 0 | claimResponse.communicationRequest | ||||
| 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. | OK | mapped | |
| 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. | Only used internally | ||
| 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. | Only used internally | ||
| 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. | In Web App we have the rejection reason for each Item and Service in a Claim. We should provide these reasons. | |
| ValidityFrom | datetime | - | Audit information. More information can be found here (on page 113): Web application - Functional Design Specification.pdf | This information are valuable for OpenIMIS but 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. | I don't think this information is valuable for external systems. It's only used internally. | |||
| 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. | Not used by external systems. | |||
| HFID | FK(tblHF) | Request | claim.facility - Reference(Location) | Could also be Claim.organization | |||
| 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. | Not used by external systems. | |||
| 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. | Claim.insurance.preAuthRef | ||
| ClaimAdminId | FK(tblClaimAdmin) | Request | claim.enterer - Reference(PractitionerRole) | This information is present in the API token? | |||
| 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. | OK | ||
| 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. | OK | ||
| 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. | Ok | ||
| 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. | OK | ||
| VisitType | char | Request | claim.type | E - emergency R - referrals O - other "" - select type | OK | ||
| ClaimCategory | char | - | I didn't find the logic related to this field. | I don't think is used externally. |
...