We need to discuss how we ensure India distro receives the commits from global (when do we rebase from upstream?) and also, what do we do to ensure only INDIA SPECIFIC commits go into India Distro.
We would like to demonstrate the following features in the upcoming PAT call 1) Line Reports along with SNOMED and ICD-10 codes 2)Export Patient data using FHIR standard
@akanter
We would like to demonstrate event-router-service in bahmni Along with changes in openmrs-module-bahmnievents.
Quick intro about event-router-service:
Event router service routes the events from Bhamni to external system and vice versa.
As of now it supports routing the message from Bahmni to GCP Pub sub.
To make this run, configuration has to be provided both as an environment variable and through configuration files.
Features it supports:
Routing of message to GCP Topic.
Processing of failed message at scheduled time.
Filtering of message based on payload.
Adding additional data in payload at root element
Routing the message to different topic based on event type in header.
Use case of creating event-router-service:
We have a use case wherein Bahmni is currently deployed on on-prem machine.
There are certain service which are running in GCP Cloud.
Those GCP Cloud service right now requires some data for further processing. For example: Creating google folder for each patient, Send patient data to salesforce, Send patient data to odoo running in cloud.
Right now the sync between Bhamni and GCP is manual.
With the help of this service, we will push the events as and when it gets generated in Bahmni.
Sorry, this notification process does not seem to work for me. I don’t get them early enough to plan to attend the PAT call. I’ll review the recording when it is available and I read the notes. I still would like to have a separate call to discuss the project. Thanks.
@akanter In the last PAT call, we’d demonstrated ICD10 reporting and we will share the recording with you shortly. Also we will be demonstrating Bulk FHIR export of patient data in the PAT call for tomorrow. Please review and we look forward to your inputs. Thanks!
Wow! This is really impressive! I think this can be really useful when he concept selected is SAME-AS to a SNOMED code. The challenge will be for the concepts which are NOT same-as a single SNOMED code. Has anyone looked into those circumstances? I like that you can pass gender/age to the API as this is a large proportion of context, but there are other attributes such as severity or acuity which change the icd coding…
@akanter - Agree. The current implementation is being implemented as a report extension in Bahmni, so that any implementation can modify the logic used by the report to map a (SNOMED code + Patient) to an ICD-10 code. The current extension calls the SNOMED team provided opensource ICD-microservice, which depends on Patient Gender & Age to determine the mapping. But if there is a “richer” microservice which takes more parameters for an accurate decision, the extension can be modified to support it.
Right now, the expectation is that one can export the data as CSV from Bahmni reports, and then re-validate and set the appropriate ICD-10 codes, before sharing with ministries, for cases where the automatic determination leads to multiple ICD-10 codes or cannot be determined conclusively.
Reviewing the SNOMED micro service for ICD coding, I do find problems. This is the reason we use interface terminology which ensures that the actual concept (not just the mapped SNOMED codes) to both ICD-10 WHO and ICD-11 are correct. Perhaps a rules engine can be built to do these mappings, but it would need to be able to handle a SNOMED expressions (multiple codes) for it to be truly useful in all circumstances. My fundamental concern is that patients frequently do not have concepts = single SNOMED and forcing them to use an API which forces them to document this way will degrade the information at point of documentation and then later when you try to cross map.