Haiti Metadata Module

@craigappl,

Absolutely. I should be able to get to it by today or tomorrow.

@ball was also just talking with me about adding some of the HIV forms to our instance, so I think it’s definitely okay for you to start adding them to the Haiti Core module.

Take care, Mark

@craigappl,

So I went ahead and moved the installation out of the Haiti Core Activator and created a simple component for installing metadata:

However, after doing that, I realized that it wasn’t really necessary and I should be including the bundles from Haiti Core with our main HaitiMetadataBundle, so I modified PIH Core as follows:

So we really don’t need the “HaitiCoreInstaller” component I created, but I left it around in case we want to use it in the future.

I’ve just committed all this code now and it’s running through our pipeline now, will let you know if I run into any errors.

A few related notes:

  1. I forgot to mention (but you may have noticed) it looks like I botched the package names when creating the Haiti Core module, so I went ahead and cleaned this up a few days ago.

  2. One thing I’ve got on my todos–at some point we need to make sure that this all works properly from scratch, on an empty OpenMRS instance.

Take care, Mark

We would love to share the htmlforms (especially the HIV ones). Since we have other Haiti implementations which don’t use the CIEL concept dictionary, we cannot use their dictionary. I am currently adding CIEL mappings to our existing concepts and adding CIEL concepts when those concepts are missing from our current implementation.

It’s great that we have all these implementations, but we are not starting from a blank slate.

Ellen

@craigappl looks like all our tests passed, so I would go ahead and use this new code…

Take care, Mark

Thanks Mark,

I’ll review and modify our build process today or tomorrow. The next step for us is to add the biometric and provider identifiers to haiticore. We’re going to begin working on a fingerprint reader integration and the first step is creating the biometric patient identifier. We also have SolDevelo working on integration with the health worker registry and they need to capture the provider identifier from the HIE.

Sincerely, Craig

Great!

The nice thing about this new approach is that we both can add new metadata to Haiti Core but the other org will have to explicitly pick it up, giving us time to review, etc, first.

Here’s a link to the list of all the patient identifier types we have in Haiti:

https://github.com/PIH/openmrs-module-pihcore/blob/master/api/src/main/java/org/openmrs/module/pihcore/metadata/haiti/HaitiPatientIdentifierTypes.java

Feel free to pull “Biometrics Reference Number” into Haiti Core, or not, depending on if it works for you. We just added it to do some fingerprinting prototyping, we aren’t actively using it, so it would be easy to switch to something you create if need be.

The one other identifier type here that we might want to share is the ZL EMR ID… it’s obviously Zanmi Lasante specific… it’s our primary identifier in our ZL EMR… but if you think you might ever want to collect it in iSante we could move it to Haiti Core.

We should also sync up on fingerprinting as well… as you probably know, our colleagues at Zanmi Lasante have built a fingerprint solution, and it’s on our to do list to integrate that into the PIH EMR.

And finally, @ball was just talking with me about the iSante forms and the various encounter types referenced on them… we should add the key encounter types that go with the forms when we had the forms to the system.

Take care, Mark

Hi @mogoodrich

We didn’t have a metadataBundle class in the isanteplus module so I just finished creating one. I’m having trouble building the Application Context with my iSantePlusServiceTest when I build this module now that I have added these changes.

Error: “No qualifying bean of type [org.openmrs.module.metadatadeploy.api.MetadataDeployService] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}”

Recent Commit link

Here’s the full SureFire Report.

The module runs fine when I skip the tests. Can you help me figure out how to fix?

Has the Metadata Deploy module been added as a dependency in the isanteplus module? Is it listed as a required module in the the config.xml?

Take care, Mark

Thanks Mark!

Metadata Sharing and Metadata Mapping weren’t in the config.xml file. I got the tests to pass :slight_smile:

@ball

The current registration form in iSanté has this version information:

MSPP FICHE D’ENREGISTREMENT ADULTE (VERSION OCTOBRE 2005)

I noticed that your registration form collects religion, which is a core difference from this registration form. Did you start collecting religion due to an updated MSPP form? If so, do you have a copy of that version?

Thanks, Craig

FYI @nathaelf

@craigappl @nathaelf

Collecting religion is an optional field collected at registration. This was a request from our Haiti team - Zanmi Lasante (ZL). I don’t know if the decision came from MSPP or ZL.

As for “updated MSPP forms”, ZL is not using the same forms used by iSante (and iSantePlus) but there are many similarities. (I can share those if you are interested.) I don’t understand all the choices but we have been collecting HIV data for many years (since 1990’s).

We plan to creating form(lets) based on the ZL HIV paper forms with much borrowing from the iSantePlus HIV concepts and htmlforms. Each section of the intake and followup will become a form within a larger template (ie. Symptoms, Plan, WHO stage, etc).

The iSantePlus HIV forms are part of the PIH build for Haiti, so we should be able to switch those on anytime. I have made those minor changes and have a script to update the mappings which I can share.

Sorry that I missed this post from May 1.

Ellen

@craigappl @nathaelf @mogoodrich

For the iSantePlus HIV forms, I have created encounterType code which I’d like to add to the HaitiCore module. To make it clear for me, I have modified the descriptions slightly to include “iSantePlus” in the description to differentiate from non-iSantePlus encounterTypes.

Thanks,

Ellen

These are suggested code additions on the haiticore module:

HaitiEncounterTypes.java

	// iSantePlus / MSPP encounter types
	public static EncounterTypeDescriptor ADULT_HIV_INTAKE  = new EncounterTypeDescriptor() {
		public String uuid() { return "17536ba6-dd7c-4f58-8014-08c7cb798ac7"; }
		public String name() { return "Saisie Première pour le VIH"; }
		public String description() { return "iSantePlus Saisie Première visite Adulte VIH"; }
	};
	
	public static EncounterTypeDescriptor ADULT_HIV_FOLLOWUP  = new EncounterTypeDescriptor() {
		public String uuid() { return "204ad066-c5c2-4229-9a62-644bc5617ca2"; }
		public String name() { return "Suivi Visite pour le VIH"; }
		public String description() { return "iSantePlus Saisie visite suivi Adulte VIH"; }
	};
	
	public static EncounterTypeDescriptor PEDS_HIV_INTAKE  = new EncounterTypeDescriptor() {
		public String uuid() { return "349ae0b4-65c1-4122-aa06-480f186c8350"; }
		public String name() { return "Saisie Première pour le VIH (pédiatrique)"; }
		public String description() { return "iSantePlus Saisie Première visite Pédiatrique VIH"; }
	};
	
	public static EncounterTypeDescriptor PEDS_HIV_FOLLOWUP  = new EncounterTypeDescriptor() {
		public String uuid() { return "33491314-c352-42d0-bd5d-a9d0bffc9bf1"; }
		public String name() { return "Suivi visite pour le VIH (pédiatrique)"; }
		public String description() { return "iSantePlus Saisie visite Suivi pédiatrique VIH"; }
	};
	
	public static EncounterTypeDescriptor ART_ADHERENCE  = new EncounterTypeDescriptor() {
		public String uuid() { return "c45d7299-ad08-4cb5-8e5d-e0ce40532939"; }
		public String name() { return "ART Adhérence"; }
		public String description() { return "iSantePlus Conseils ART d'Adhérence"; }
	};

HaitiEncounterTypeBundle.java

install(EncounterTypes.ADULT_HIV_INTAKE);
install(EncounterTypes.ADULT_HIV_FOLLOWUP);
install(EncounterTypes.PEDS_HIV_INTAKE);
install(EncounterTypes.PEDS_HIV_FOLLOWUP);
install(EncounterTypes.ART_ADHERENCE);

message.properties (English)

ui.i18n.EncounterType.name.17536ba6-dd7c-4f58-8014-08c7cb798ac7=HIV Adult Intake (iSantePlus)
ui.i18n.EncounterType.name.204ad066-c5c2-4229-9a62-644bc5617ca2=HIV Adult Followup (iSantePlus)
ui.i18n.EncounterType.name.349ae0b4-65c1-4122-aa06-480f186c8350=HIV Peds Intake (iSantePlus)
ui.i18n.EncounterType.name.33491314-c352-42d0-bd5d-a9d0bffc9bf1=HIV Peds Followup (iSantePlus)
ui.i18n.EncounterType.name.c45d7299-ad08-4cb5-8e5d-e0ce40532939=ART Adherence (iSantePlus)

constants.js

.value('EncounterTypes', {
artAdherence: {
    uuid: "c45d7299-ad08-4cb5-8e5d-e0ce40532939"
},
hivIntakeAdult: {
    uuid: "17536ba6-dd7c-4f58-8014-08c7cb798ac7"
},
hivIntakePeds: {
    uuid: "349ae0b4-65c1-4122-aa06-480f186c8350"
},
hivFollowupAdult: {
    uuid: "204ad066-c5c2-4229-9a62-644bc5617ca2"
},
hivFollowupPeds: {
    uuid: "33491314-c352-42d0-bd5d-a9d0bffc9bf1"
}
}

Thanks @ball. It makes sense to me that we extract these encounter types into the Haiti Core module, since the notion of an Adult / Pediatric Initial / Followup HIV encounter, or an ART Adherence encounter, should be a shared concept for us all. In that vein, I don’t think we should add “iSantePlus” to the encounter type descriptions or the message properties.

if we need to distinguish between the iSantePlus forms and a different set of forms (with slightly different questions or different layout), we should distinguish this by using the Form (which can include version). This way, we can have encounters with the same encounter types, but which are associated with different forms.

@craigappl / @nathaelf - does this make sense to your team?

Thanks! Mike

Hi @mogoodrich, @mseaton, @ball,

We’re testing the interactions with the Master Person Index and would like to add an “ECID” identifier type to Haiti core. This is the identifier that will store a patient’s ID that’s auto generated by the MPI. Does that sound alright?

Thanks, Craig

Sounds right that the identifier for the MPI would be defined in Haiti Core. What does “EC” stand for? Is this I National Identifier or just an “internal-use” key reference to an entry in the MPI?

Take care, Mark

Hi @mogoodrich,

Enterprise Client ID is the ID that’s used as the core identifier in the MPI. It’s a national UUID for every record in the MPI.

Thanks, Craig

Hi @mogoodrich, @ball, @mseaton

@jamesfeshner and I are about to start working on managing our iSantePlus locationAttributeTypes. To do this, we see the need to have:

  1. Legacy iSante Site Code
  2. MSPP Site Code based on the official list we received from LNSP

I would like to create the metadata package in openmrs-module-isanteplus for #1 and a package in Haiti Core for #2.

Does this sound alright to you?

Thanks, Craig

@craigappl, yes that sounds right to me - thanks!

@craigappl sounds right to me as well