We do not have a concrete requirement yet but we are implementing support for programs in Bahmni. We were wondering how does one link encounters to programs, as it may be required for reporting purposes or providing a program specific of the patient to the user.
We are thinking of doing this via encounter types, i.e. each program would have certain ETs configured for it used only in those programs. Any suggestions on this.
This link could be to a visit too but at the time of opening a visit one may not know the reason for visit.
At PIH we use programs pretty extensively, though not always consistently. We have yet to start supporting them in our Mirebalais-based system, but that is on our near-term roadmap. Iād love to find a consistent approach.
As you suggest, typically for us we would see certain encounter types linked to certain programs. We often see certain identifier types linked to certain programs as well (eg. an ART Number). Sometimes we have also found that the association is best modeled at a lower level - with certain workflows / states within a program. For example, in Malawi we have an overall HIV Program, and within this patients can transition between Pre-ART, EID, and ART, and each of these has itās own intake and follow-up encounter types and patient identifier type. This reflects the way the actual paper mastercards are implemented.
In addition, there is often significant value in using these associations to implement validation logic to improve data quality. For example, certain encounter types (eg. intake) can only occur once per program enrollment per location, and cannot be entered until the program enrollment is entered (or which might automatically enroll the patient in the program).
Recently I threw together a construct for our Malawi system that ties some of these things together, in order to be able to build some generic APIs. You can see this here:
As you can probably tell from all of the reporting-related methods, this mainly gave me a way to write some standard reports (eg. generic row-per-patient reports, generic row-per-encounter reports, generic indicator reports) which take in a āTreatmentGroupā and are able to produce the right reports with the right calculations and columns. But there were all sorts of other uses for this that emerged once I had this at the API level. This may or may not be useful to you (and could certainly be improved), but should give you some sense of our approach.