...
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 |
| Will be added when will be available in the python claim module | ||||
InsureeID | FK(tblInsuree) | Request | claim.patient - Reference(Patient) | The subject of the Products and Services | 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 | Claim number | OK | mapped | |||
DateFrom | smalldatetime | Request | claim.billablePeriod |
| OK | mapped | |||
DateTo | smalldatetime | Request |
| mapped | |||||
ICDID | FK(tblICDCodes) | Request | claim.diagnosis | List of 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.outcome | Default value: 2; 1 - rejected 2 - entered 4 - checked 8 - processed 16 - valuated | Used the FHIR codeable concept (code = imis_status, text = displayed status) | Can be also a combination of claimResponse.status and claimResponse.outcome but limited in values. Extension required? | mapped | ||
Adjuster | FK(tblUsers) | Request | claim.provider - Reference(Practitioner) | Responsible provider | 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.payment.adjustmentReason | Used FHIR adjustmentReason because of the IMIS Adjustment is text. | claimResponse.payment.adjustment | mapped | |||
Claimed | decimal | Request | claim.total |
| OK | mapped | |||
Approved | decimal | Response | claimResponse.totalBenefit | OK | mapped | ||||
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.payment.date | claimResponse.created is used is the request date | If different endpoint to claimResponse, claimResponse.created will be the request date. Maybe claimResponse.payment.date | mapped | |||
Feedback | bit | default value: 0 | No need. To see if replaced by FeedbackID | ||||||
FeedbackID | FK(tblFeedback) | Response | claimResponse.communicationRequest | default value: 0 | claimResponse.communicationRequest | mapped | |||
Explanation | ntext | Request | claim.information.valueString | Additional Data or supporting 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 | In Web App we have the rejection reason for each Item and Service in a Claim. We should provide these reasons. | mapped | |||
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) | Servicing Facility | 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 | Additional Data or supporting information | 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) | Author | This information is present in the API token? | ||||
ICDID1 | int | Request | claim.diagnosis | diagnosis 1 from List of 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 | diagnosis 2 from List of 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 | diagnosis 3 from List of 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 | diagnosis 4 from List of 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. |
...