General notes:
Except when explicitly indicated, FHIR entities' attributes use to be optional... and since they benefit of the expansion mechanism, there is no real limitation when it comes to map openIMIS entities (tables) to the FHIR corresponding one.
At the end the real questions are:
- what are the corresponding entities
- what are their "granularity"... and, most notably, are there "first citizen" entity in openIMIS that would 'just' be attributes of a FHIR entity (because the other way round is less problematic)?
| openIMIS table | FHIR corresponding/related resources |
|---|
tblInsuree & tblFamilies |
Image Removed... but  Image Added
| Person"Demographics and administrative information about a person independent of a specific health-related context." Highlights: - "The Person resource serves as a linkage resource that may provide a reference set of common demographics for an individual (human or animal) across multiple roles (Patient, Practitioner,...)."
- Patient may have several identifiers
|
Person structure is compatible with tblInsuree content: none of the Patient attribute is mandatory and Patient is "expandable" (with whatever we may want)- Warning "RelatedPerson" (here under) doesn't point (directly) to Person!
Group"Represents a defined collection of entities that may be discussed or acted upon collectively but which are not expected to act collectively, and are not formally or legally recognized; i.e. a collection of entities that isn't an Organization." Highlights: Grouping persons, but not with the 'families' semantic: it has its meaning in the health service scope (patients for a group therapy,...) Patient"Demographics and other administrative information about an individual or animal receiving care or other health-related services." Highlights: - "A Patient record is generally created and maintained by each organization providing care for a patient. A patient or animal receiving care at multiple organizations may therefore have its information present in multiple Patient Resources."
- Patient may have several identifiers
- Patients are "Linked" to each other, according a LinkType... but this is NOT the equivalent of tblFamilies: it is used to depict patient entity merge (replaced-by, replaces,...), that master entity for information is another one (refer),...
- One can link Patients (in the tblFamilies meaning) via contact.relationship (supposed to be "partner", "friend",...) but contact detail is a very "weak" reference (keep a name, telecom,... but it is not a formal other Patient entity
|
)Patient structure is compatible with tblInsuree content: none of the Patient attribute is mandatory and Patient is "expandable" (with whatever we may want"Information about a person that is involved in the care for a patient, but who is not the target of healthcare, nor has a formal responsibility in the care process." Highlights: - RelatedPerson refer to ONE "Patient" (and not Person as its name seem to indicated it)
- RelatedPerson does hold the name, telecom(,...) of the actual "person" it represent (it is NOT the equivalent of the 'tblFamilies' concept in openIMIS
FamilyMemberHistory"Significant health conditions for a person related to the patient relevant in the context of care for the patient." Highlights: - Refers to ONE "Patient"
- Used for contextual (can be vague) information (like 'had some sort of cancer')
|
tblPolicy Image Added
| Contract"Legally enforceable, formally recorded unilateral or bilateral directive i.e., a policy or agreement." Highlights:
|
tblClaim Image Added
| Claim"A provider issued list of professional services and products which have been provided, or are to be provided, to a patient which is sent to an insurer for reimbursement." Highlights: - Mandatory attributes:
- Patient (↔ tblInsuree)
- Provider {Practitioner | PractitionerRole | Organization} (↔ tblClaim.HFID)
- Insurance(s) ... no direct relation between tblClaim and tblInsureePolicy... or "PolicyID"... but this is not a FK !?!
- Item(s) (↔ tblClaimItems)... note: tblClaimItems are "first citizen entities" in openIMIS... and (complex) nested structure in FHIR
|