Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

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 abdm.conceptMap.docType.* concepts define what documentTypes are supported and how

abdm.conceptMap.docType.prescription

concept identifier to determine whether the uploaded file is marked as prescription

No

abdm.conceptMap.docType.dischargeSummary

concept identifier to determine whether the uploaded file is marked as discharge Summary

No

abdm.conceptMap.docType.referral

(Not yet supported)

concept identifier to determine whether the uploaded file is marked as discharge Summary

No

abdm.conceptMap.docType.patientFile

concept identifier to determine whether the uploaded file is marked as patient file.

No

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

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.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.

The following are required for the capturing Physical Examinations under OPConsult and Discharge Summary section.

abdm.conceptMap.physicalExamination.height

concept identifier for height

abdm.conceptMap.physicalExamination.weight

concept identifier for weight

abdm.conceptMap.physicalExamination.temperature

concept identifier for temperature

abdm.conceptMap.physicalExamination.systolicBP

concept identifier for systolic bloop pressure

abdm.conceptMap.physicalExamination.diastolicBP

concept identifier for diastolic bloop pressure

abdm.conceptMap.physicalExamination.pulse

concept identifier for pulse

The following are required for the capturing History and Examinations under OPConsult and Discharge Summary section.

abdm.conceptMap.historyExamination.chiefComplaintTemplate

concept identifier for the root template in observation to interpret.

The root concept should be of type Concept Details and Bahmni form field.

other conceptMaps (abdm.conceptMap.historyExamination.*) which are all have to be captured should be provided as well.

abdm.conceptMap.historyExamination.codedChiefComplaint

concept identifier for coded chief complaint

abdm.conceptMap.historyExamination.nonCodedChiefComplaint

concept identifier for non-coded chief complaint if any

abdm.conceptMap.historyExamination.signAndSymptomDuration

concept identifier for symptom duration

abdm.conceptMap.physicalExamination.chiefComplainDuration

concept identifier for chief complaint duration units

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: Organization

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: ABDM HFR ID

Health facility registry (HFR) Identifier of the organization in ABDM facility registry.

Location Attribute: Website

Indicates the URL for the website.

Location Attribute: Email

Communication Email for the facility

Location Attribute: Phone Number

Communication phone for the facility

  • No labels