hRHR cases in Palestine
5.2.5 From indicator rules to program rules
To facilitate decision support for care providers in the hRHR implementations, the indicator rules were considered to be the most important feature. To accommodate implementations in multiple countries, the indicator rules needed to be configurable through the user interface. In addition to comply to eRegistries for maternal and child health, configurable rules was seen as a feature that could benefit use cases outside the hRHR scope as well. To better convey a broader scope for the rules feature, the name was changed from indicator rules to program rules.
Over the coming months, this new development endeavour was led by the HISP consultant, and the source code was maintained in a separate code branch. The hRHR Initiative and the Palestinian implementation were the driving forces for the program rules. The consultant
Implementing DHIS 2 for the PPS and hRHR cases in Palestine
51
however, explained his more generic view during the development process, when discussing the relationship between the implementation and the generic DHIS 2 Tracker:
“All my energy is focused on trying to create things to be generic and be fed back [to the generic core].”
He had several discussions with two of the core DHIS 2 developers about how a data model for the rules could be developed to fit with the existing DHIS 2 data model.
Figure 11 - Data model for program rules (source: Frost and Bekken, 2015)
The data model (Figure 11) and execution environment were developed first, followed by functionality for persisting the rules in the database. When the program rules feature was finally in a quite stable state, it was merged into the trunk (the core DHIS 2 source code repository).
Offline usage
One feature that saw some discussion in the course of the development was if the DHIS 2 Tracker could support offline usage. A concern brought up by NIPH in Norway and also by some WHO representatives in Palestine, was what implications it would have if the system ‘went offline’, as it was to be used as a clinical support tool during consultations. If and how this could be supported by DHIS 2 was discussed in several email and face-to-face
discussions, to the point that several quite specific technical solutions were discussed. In the end however, it was found that this sort of feature would be difficult to implement, and didn't fit well with the fact that DHIS 2 is in fact a web application. It was also argued by the core
Program
ProgramRuleVariable ProgramRules
developers that even if such a feature was developed, computers could still crash, something that would require a paper based backup system anyway.
Flow charts as a ubiquitous language
In the beginning of the new development process, the HISP consultant and the NIPH implementer created several flow charts outlining some of the broader use cases that the hRHR Tracker should accommodate. When the rules feature was developed, and each treatment algorithm was to be implemented as particular program rules into the system, the HISP consultant needed to translate each of the elaborate algorithms from the Excel files into the format defined in the rules feature.
“In the first round of the [hRHR] Tracker, [the NIPH coordinator] used a lot of time on very detailed rules. She kind of invented her own "programming language" to display algorithms, which we had to decipher to put into our language. But that really played out only just mediocre. So I managed to convince her to simply create [flow charts] the next time.” – HISP consultant “The next time” was when NIPH had a meeting in Palestine to adapt the globally defined treatment guidelines to the Palestinian context. NIPH made a first draft of the treatment guidelines represented as flow charts, which they brought with them to Palestine, and there fleshed them out with an expert committee to match the guidelines and workflows of the Palestinian health system. These flow charts were less pervasive, and didn’t cover as many details as the more elaborate algorithms from the Excel files.
“Then there is a process after we have received the flow chart to define the details. What happened previously was that the [NIPH coordinator] tried to think of every detail and "programming" them, and then there was an amount of work going though the details to understand what was meant in the "programming language" she had invented. I'm really impressed with [her work], and she really got most of it very correct, but those details still had to be revised. Now we go through the details once, instead of the [NIPH coordinator] doing it first and me doing a revision of [her] details […], and that goes directly into the program rules as part of the work to get all those trinkets right.” – HISP consultant
Implementing DHIS 2 for the PPS and hRHR cases in Palestine
53
When asked if this process was about finding a common language amongst the actors, the HISP consultant stated:
“[The flow charts] were maybe the most common, because then both technical and medical people can look at the presentation and understand if the intervention is correct. And then it takes a more technical mind to actually make the rules that are needed.”
– HISP consultant The following two figures shows one flow chart based on the global treatment guidelines and one flow chart adapted to Palestine.
Figure 12 - Globally defined treatment flow chart (source: Frost and Bekken, 2015)