Support for Health Information Types
Bahmni supports health information exchange compliant to ABDM’s Health Information (HI) types as defined by CDAC NRCeS. You can see the details of the FHIR profiles in the NRCeS published FHIR IG.
Data is sent as structured FHIR data, and is sent with clinical encodings*.
The following HI Types are supported
Prescription
OPConsultation
DiagnosticReport
DischargeSummary
ImmunizationRecord
HealthDocumentRecord
WellnessRecord
Note: Bahmni is used in clinical setups like Hospitals, clinics, care centers in varied different contexts. Depending on your implementation setup you may not generate certain types of HI Type documents at all. And when you do, you may decide to interpret different EMR data elements differently. Bahmni ABDM HIP module allows you to enable such configuration which can help you to interpret EMR data and help in transformation to ABDM HI Type documents.
Such configuration elements are specified through “abdm_config.properties” file under openmrs runtime directory (in docker container, it is /openmrs/data). If the file is not present, then the HIP module tries to set reasonable defaults and also read from OMRS Global properties (using the same configuration element keys mentioned below).
Note, the support for the following is in early stages. Please ping us on slack if you want further information
configuration | description | mandatory |
|---|---|---|
abdm.conceptResolution | Specifes how the conceptMaps are to be resolved. As of this point only “UUID” is supported. In future, we hope to support Coding system as well. Such a UUID based resolution strategy may not be scalable, but is definitive and unambiguous for an implementation. | no (default UUID) |
The following are required in order to include document in the FHIR Bundle | ||
abdm.conceptMap.document.opConsult | List of concept identifiers that must be included in the op-consult Hi Type | No |
abdm.conceptMap.document.dischargeSummary | List of concept identifiers that must be included in the discharge summary Hi Type. | No |
abdm.conceptMap.document.diagnosticReport | List of concept identifiers that must be included in the diagnostic report Hi Type. | No |
abdm.conceptMap.document.wellnessRecord | List of concept identifiers that must be included in the wellness record Hi Type. | No |
abdm.conceptMap.document.prescription | List of concept identifiers that must be included in the prescription Hi Type. | No |
abdm.conceptMap.document.healthDocumentRecord | List of concept identifiers that must be included in the health document record Hi Type. | No |
The following are required for the Immunization Record creation. | ||
abdm.conceptMap.immunization.template | concept identifier for the root template in observation to interpret. If specified then other immunization conceptMaps (abdm.conceptMap.immunization.*) should be provided |
|
abdm.conceptMap.immunization.vaccineCode | concept identifier for vaccine code. Either this property or abdm.conceptMap.immunization.vaccineCode must be defined | yes |
abdm.conceptMap.immunization.occurrenceDateTime | concept identifier for vaccine occurance date and time | yes |
abdm.conceptMap.immunization.manufacturer | concept identifier for vaccine manufacturer | yes |
abdm.conceptMap.immunization.brandName | concept identifier for vaccine brand |
|
abdm.conceptMap.immunization.doseNumber | concept identifier for dose number (1, 2…) | yes |
abdm.conceptMap.immunization.lotNumber | concept identifier for vaccine lot number | yes |
abdm.conceptMap.immunization.expirationDate | concept identifier for vaccine expiry date | yes |
abdm.conceptMap.immunization.status | concept identifier for whether vaccine was given or not. If defined, then further checks are done whether to share immunization history. See Immunization configuration section below for more details | no |
abdm.conceptMap.immunization.vaccineNonCoded | Concept identifier for Non coded free text vaccine name. If no vaccine is registered against “abdm.conceptMap.immunization.vaccineCode” then this is used | no |
|
|
|
The following are required for the document uploaded using an obs template. Note that the following are applicable, only when the “abdm.conceptMap.docType.template” property is set | ||
abdm.conceptMap.docType.template | concept identifier to determine whether the uploaded file as a obs template. Please see section below on suggestions of how such a template can be setup easily. If provided, then other relevant configuration parameters are required for abdm.conceptMap.docTemplate.* | No |
abdm.conceptMap.docTemplate.docType | concept identifier which determines whats the type of document uploaded. This is expected to be a “coded” concept, having answers that map to the above “abdm.conceptMap.docType.*” properties (Mandatory if abdm.conceptMap.docType.template is specified) | yes
|
abdm.conceptMap.docTemplate.attachment | concept identifier (of type:complex) that will store a reference to an uploaded document (Mandatory if abdm.conceptMap.docType.template is specified) | yes |
abdm.conceptMap.docTemplate.externalOrigin | concept identifier that will used for storing documents sourced from external sources (e.g. patient bringing her files before a procedure and such files uploaded for references). If this property is set and a document Template is found to have this info recorded, then such files are not transferred/shared. | No |
abdm.conceptMap.docTemplate.documentDate | concept identifier that will store a document creation or uploaded date | No |
The following are required for the capturing Physical Examinations and Other Observations section under OPConsult Hi-type. | ||
abdm.conceptMap.opConsult.physicalExamination | List of concept identifiers that must be included in the physical examination section of op-consult. | No |
abdm.conceptMap.opConsult.otherObservations | List of concept identifiers that must be included in the other observations section of op-consult. | No |
The following are required for the capturing History and Examinations under OPConsult Hi-type. | ||
abdm.conceptMap.historyExamination.chiefComplaintTemplate | concept identifier for the root template in observation to interpret. The root concept should be of type you can still define other conceptMaps without root concept. It is not mandatory. | No |
abdm.conceptMap.historyExamination.codedChiefComplaint | concept identifier for coded chief complaint | No |
abdm.conceptMap.historyExamination.nonCodedChiefComplaint | concept identifier for non-coded chief complaint if any | No |
abdm.conceptMap.historyExamination.signAndSymptomDuration | concept identifier for symptom duration | No |
abdm.conceptMap.historyExamination.chiefComplainDuration | concept identifier for chief complaint duration units | No |
The following are required for the Wellness Hi-type. | ||
abdm.conceptMap.wellness.vitalSigns | List of concept identifiers that must be included in the vital signs section | No |
abdm.conceptMap.wellness.bodyMeasurement | List of concept identifiers that must be included in the body measurement section | No |
abdm.conceptMap.wellness.physicalActivity | List of concept identifiers that must be included in the physical activity section | No |
abdm.conceptMap.wellness.generalAssessment | List of concept identifiers that must be included in the general assessment section | No |
abdm.conceptMap.wellness.womenHealth | List of concept identifiers that must be included in the women health section | No |
abdm.conceptMap.wellness.lifestyle | List of concept identifiers that must be included in the lifestyle section | No |
abdm.conceptMap.wellness.otherObservations | List of concept identifiers that must be included in the other observations section | No |
abdm.conceptMap.wellness.documentReference | List of concept identifiers that must be included in the document reference section | No |
Configure Authoring Organization for documents
Bahmni HIP plugin module, provides additional configuration details that can further enhance how the documents send information about the organization caring for the patient.
Type | Description |
|---|---|
Location tag: | Since Bahmni provides ability to create multiple locations and in hierarchical manner, this tag helps to identify whether an visit location should be considered as an organization. Alternatively, Bahmni will identify the location that is tagged as “Visit Location” or the root of the location hierarchy is neither “Organization” or “Visit Location” tag is assigned |
Location Attribute: | Health facility registry (HFR) Identifier of the organization in ABDM facility registry. |
Location Attribute: | Indicates the URL for the website. |
Location Attribute: | Communication Email for the facility |
Location Attribute: | Communication phone for the facility |
The Bahmni documentation is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)