The DIGI team at I‐TECH-University Of Washington has been working on automating the process of translating from L2 HIV DAK artifacts to L3 Content (FHIR IGs) , and this also required working on a Proof of Concept to Implement the SMART Guidelines CDS in OpenMRS.
The work to Implement the SMART Guidelines with in OpenMRS has leaveraged and exetended the previous work for ANC DAK.
Here is a High level overview of how SMART CDS rules are currently being implemented
We use the CQL OpenMRS module that Loads the FHIR Resources from the File System ie under/openmrs/dak and leverages the Clinical Reasoning Module to do the PlanDefiniton Evaluation .
Whenever a Patient Encounter is Created ,the PatientFlags Module then generates and saves the Patient Flags from the CarePlan generated as a result of the PlanDefinition Evaluation by the CQL module .
The saved patient flags are then displayed on the Patient Dashborad by the esm-patient-flags-app.
Here is the OpenMRS distro project that can be run out of the box.
Here is a quick demo .
Great work! Can you clarify which concept dictionary you were using? I notice that the value sets have unique WHO codes. We added these to CIEL for ANC but not for HIV, I believe. If you have mappings that should be added, please let me know.
So far, for the SMART DAKs we’ve been ending up with essentially a concept system-per-DAK. In theory, there are some mappings for many elements in the data dictionary (XLSX) to ICD-11 / ICD-10 /LOINC / ICHI / ICF and SNOMED GPS (really SNOMED CT), but I’m unsure how accurate these mappings are. We definitely haven’t done any analysis of any of this might map to CIEL yet.
But that is not really useful, then. If there is no connection between the dictionary used for capturing the patient information and the CQL running the rules, then you would basically have to create a completely separate system to collect data for rules compared to caring for patients… For ANC, we added the WHO codes to the CIEL concepts so that the CQL would work. The choice is either to use the maps from the SQL to find concepts in the CIEL dictionary with similar maps, or to use the SAME-AS WHO concepts. As you pointed out, the maps provided in the DAK are not often SAME-AS and cause issues when triggering data in the medical record that was not collected specifically for the purpose of the DAK. That is what we need to document and provide feedback for. The best option is for CIEL to have SAME-AS concepts required by the CQL which overlap with existing clinical concepts… I could use some help in doing that for the HIV DAK if someone wants to.
But people do not have those codes in their EHR… so everyone has to manually map their entire dictionaries which is difficult. The idea behind the standard maps provided by WHO is that those can be used instead… but if there is not a SAME-AS map or NARROWER-THAN map to those codes in the dictionary, the rules will not fire properly. I believe that the mappings provided by WHO are insufficient in real world use cases (unless they add CIEL maps), but that has not been tested. You can test against the SNOMED, ICD, LOINC, etc. maps provided by CIEL, but to be 100% sure, we should add those DAK codes to CIEL just like we did for ANC.
Did anyone look at actually cross-walking from the reference maps provided in the DAK data dictionary to the concept code maps in the CIEL or OpenMRS dictionary?
To be clear: this is just a proof of concept, and not something we’re expecting to operationalize immediately. Figuring out how we map from the DAK to actual OpenMRS concepts, etc. is well beyond the scope we’re currently working on.
I agree that the mappings provided in the DAK are not workable in practice; for example, the data elements capturing which ART regimen a client is on—all answers to which are specific combinations of drugs, e.g., ABC + 3TC + EFV—are almost exclusively mapped to both XM3U67 from ICD-11 (“Antivirals for treatment of human immunodeficiency virus infections, combinations”) and 416234007 from SNOMED, so the mappings don’t even make the semantic distinctions the DAK actually needs. These sorts of concerns fit into the feedback we’re giving the WHO.
Maybe this becomes a conversation to have at the Implementer’s meeting? I suspect there is high interest and opinion about SMART Guidelines in OpenMRS, especially with the Kenya teams implementing the indicator aspects of the DAK into their OpenMRS ecosystem. @ibacher can we propose a session on it - would you mind leading it?
That would be awesome! I definitely am interested! For now, it seems like we can’t use their maps to trigger the rules, and we need SAME-AS maps or NARROWER-THAN maps. Could your team at least give me the most important concepts that they use for demos and such and I’ll make sure those are in CIEL. Then we can incrementally add the others…
For the rule demonstrated here, we just use this ValueSet and patient age. (There’s also an element to capture “other” signs, but this isn’t directly used in the decisions support logic). Oh, and we assume that those answers are connected to a concept that is SAME-AS http://smart.who.int/hiv/CodeSystem/HIVConcepts|HIV.D.DE17 (“Signs of Serious Illness”). (We chose this one because the data is quite straight-forward).
Name WHO-HIV-DAK Code Description
Signs of serious illness HIV.D.DE17 Signs that may indicate the client has a serious illness and needs triage or an emergency referral
Tachycardia HIV.D.DE19 Heart rate above a rate per minute based on age
The WHO-HIV-DAK CodeSystem has a url
http://smart.who.int/hiv/CodeSystem/HIVConcepts
OK. It is looking for coded answers to the Signs of Serious Illness question… Technically the answer to that question could be NONE or UNKNOWN, but if we are looking at Tachycardia or one of the others, specifically, as answers than it will work! I will be sure to add these.
For example, even this concept was not present in CIEL beforehand. Technically it would require a phenotype of FEVER + Temp > 39 C or perhaps two measured temperatures > 39 C without the diagnosis. However, the concept is now in CIEL
