The SHR community had a good discussion around the workflows of how data could be sent to the HMIS on our call yesterday. We discussed some simple solutions that may be appropriate for the next OpenHIE release. I have captured these on the following 2 workflow pages:
Basically the first one is suggesting a plain pass through of DXF through from the point of care systems to DHIS via the IL. The second, is a little more complex and would require a mediator to be created in the IL that triggers on a certain time period and queries the SHR for information and then processes that information into the DXF format and send that off to DHIS.
In both cases the workflows are very DHIS2 specific. We discussed this and we think this is ok for an initial solution. But, we noted that in the future we may want to address this and find/develop standards to perform these tasks.
Also, previously these workflow have fallen under the responsibility of myself and the IL/SHR communities. But I think now with the inclusion of the HMIS community they may want to take over the stewardship of these workflows? This seems to make sense to me. The SHR and IL community would still want to be highly involved as the workflows have direct relationship to both of those components but perhaps the HMIS community should take the lead?
Please let me and the IL/SHR community know what you think of these workflows.
Cheers,
Ryan
···
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
I am also thinking that the second workflow can also be a simple pass through from the IL perspective which should make it simpler. I am not sure the IL is the component to determine when these messages should originate. Rather they should be triggered from the SHR itself. (to push or to pull) This has pragmatic implications - there is a difference between the reporting period and the reporting time. It might be prudent to report last month’s data on the 1st, 4th or 10th day of the month depending on a variety of real world factors. Also there might be a case to report data for the last 3 months for a facility which has been offline and has backlog to report. Whatever the circumstance, it seems the IL would not necessarily be the best actor to determine when and what to report. It has an important role to play in routing, validation and authorization.
In another modification, I don’t think it is a good idea to be passing sql around between components. Particularly with data as sensitive as the SHR, it probably should not be allowed to execute arbitrary sql it gets from outside, even from a trusted component like the IL.
The fact that the dxf will be generated from an sql resultset is an internal detail of the SHR implementation. It might equally be generated off a cohort query or any other method. For our immediate Rwanda use case it seems that we happen to have sql queries already for calculating the dataelements so we will use that route. But this is a detail which should not be relevant to the workflow.
I don’t see this (so far) as being very particular to dhis2. It is a routine aggregate data hmis workflow. What is dhis2 specific is the format of the xml or json message (the dxf datavalueset). That is a problem we are aware of, but there seems to be broad consensus that this is the most concise and useful way to represent this data at present.
Roger has also pointed out the need for metadata exchange related to the aggregate datasets. Agree this is important but (i) I think this is a separate workflow and (ii) its a large enough challenge that it will have to fall outside the scope of v1.0. It is likely that such a workflow would involve a metadata repository actor which potentially involves terminology service or more domain specific hmis/imr-type repository service. Its not an issue we are going to address in this iteration.
Bob
···
On 10 September 2014 10:28, Ryan Crichton ryan@jembi.org wrote:
Hi all,
The SHR community had a good discussion around the workflows of how data could be sent to the HMIS on our call yesterday. We discussed some simple solutions that may be appropriate for the next OpenHIE release. I have captured these on the following 2 workflow pages:
Basically the first one is suggesting a plain pass through of DXF through from the point of care systems to DHIS via the IL. The second, is a little more complex and would require a mediator to be created in the IL that triggers on a certain time period and queries the SHR for information and then processes that information into the DXF format and send that off to DHIS.
In both cases the workflows are very DHIS2 specific. We discussed this and we think this is ok for an initial solution. But, we noted that in the future we may want to address this and find/develop standards to perform these tasks.
Also, previously these workflow have fallen under the responsibility of myself and the IL/SHR communities. But I think now with the inclusion of the HMIS community they may want to take over the stewardship of these workflows? This seems to make sense to me. The SHR and IL community would still want to be highly involved as the workflows have direct relationship to both of those components but perhaps the HMIS community should take the lead?
Please let me and the IL/SHR community know what you think of these workflows.
Cheers,
Ryan
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
I am also thinking that the second workflow can also be a simple pass through from the IL perspective which should make it simpler. I am not sure the IL is the component to determine when these messages should originate. Rather they should be triggered from the SHR itself. (to push or to pull) This has pragmatic implications - there is a difference between the reporting period and the reporting time. It might be prudent to report last month’s data on the 1st, 4th or 10th day of the month depending on a variety of real world factors. Also there might be a case to report data for the last 3 months for a facility which has been offline and has backlog to report. Whatever the circumstance, it seems the IL would not necessarily be the best actor to determine when and what to report. It has an important role to play in routing, validation and authorization.
In another modification, I don’t think it is a good idea to be passing sql around between components. Particularly with data as sensitive as the SHR, it probably should not be allowed to execute arbitrary sql it gets from outside, even from a trusted component like the IL.
The fact that the dxf will be generated from an sql resultset is an internal detail of the SHR implementation. It might equally be generated off a cohort query or any other method. For our immediate Rwanda use case it seems that we happen to have sql queries already for calculating the dataelements so we will use that route. But this is a detail which should not be relevant to the workflow.
I don’t see this (so far) as being very particular to dhis2. It is a routine aggregate data hmis workflow. What is dhis2 specific is the format of the xml or json message (the dxf datavalueset). That is a problem we are aware of, but there seems to be broad consensus that this is the most concise and useful way to represent this data at present.
Roger has also pointed out the need for metadata exchange related to the aggregate datasets. Agree this is important but (i) I think this is a separate workflow and (ii) its a large enough challenge that it will have to fall outside the scope of v1.0. It is likely that such a workflow would involve a metadata repository actor which potentially involves terminology service or more domain specific hmis/imr-type repository service. Its not an issue we are going to address in this iteration.
Bob
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
On 10 September 2014 10:28, Ryan Crichton ryan@jembi.org wrote:
Hi all,
The SHR community had a good discussion around the workflows of how data could be sent to the HMIS on our call yesterday. We discussed some simple solutions that may be appropriate for the next OpenHIE release. I have captured these on the following 2 workflow pages:
Basically the first one is suggesting a plain pass through of DXF through from the point of care systems to DHIS via the IL. The second, is a little more complex and would require a mediator to be created in the IL that triggers on a certain time period and queries the SHR for information and then processes that information into the DXF format and send that off to DHIS.
In both cases the workflows are very DHIS2 specific. We discussed this and we think this is ok for an initial solution. But, we noted that in the future we may want to address this and find/develop standards to perform these tasks.
Also, previously these workflow have fallen under the responsibility of myself and the IL/SHR communities. But I think now with the inclusion of the HMIS community they may want to take over the stewardship of these workflows? This seems to make sense to me. The SHR and IL community would still want to be highly involved as the workflows have direct relationship to both of those components but perhaps the HMIS community should take the lead?
Please let me and the IL/SHR community know what you think of these workflows.
Cheers,
Ryan
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Where the process is triggered is debatable and I could see this working either way. The reason this was modelled this way was so that the SHR remains a system that just has to respond to queries rather than having to trigger an processing itself. This seemed to be beneficial, but I don’t have very strong feelings about this.
I agree about sending sql. I don’t like this either. It would be something we do to get something in the first version of OpenHIE, it wouldn’t be the way we want it. I agree the SHR could generate the DXF itself.
The workflows are DHIS specific due to the use of DXF, but as you say that is something we know and we don’t know of a standards-based alternative to DXF. I just added those comments in there as one of the principles of OpenHIE is swapability of components however, that would be difficult with a DXF endpoint as only DHIS (AFAIK) supports this and DXF seems to be closely tied to the DHIS data model…
Agree, about the indicator registry.
Please feel free to edit these workflows as you see fit if there are any changes you would like to make.
Cheers,
Ryan
···
On Thu, Sep 11, 2014 at 1:40 PM, Ryan Crichton ryan@jembi.org wrote:
Forwarding Bob’s response on the SHR list. (see below)
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
I am also thinking that the second workflow can also be a simple pass through from the IL perspective which should make it simpler. I am not sure the IL is the component to determine when these messages should originate. Rather they should be triggered from the SHR itself. (to push or to pull) This has pragmatic implications - there is a difference between the reporting period and the reporting time. It might be prudent to report last month’s data on the 1st, 4th or 10th day of the month depending on a variety of real world factors. Also there might be a case to report data for the last 3 months for a facility which has been offline and has backlog to report. Whatever the circumstance, it seems the IL would not necessarily be the best actor to determine when and what to report. It has an important role to play in routing, validation and authorization.
In another modification, I don’t think it is a good idea to be passing sql around between components. Particularly with data as sensitive as the SHR, it probably should not be allowed to execute arbitrary sql it gets from outside, even from a trusted component like the IL.
The fact that the dxf will be generated from an sql resultset is an internal detail of the SHR implementation. It might equally be generated off a cohort query or any other method. For our immediate Rwanda use case it seems that we happen to have sql queries already for calculating the dataelements so we will use that route. But this is a detail which should not be relevant to the workflow.
I don’t see this (so far) as being very particular to dhis2. It is a routine aggregate data hmis workflow. What is dhis2 specific is the format of the xml or json message (the dxf datavalueset). That is a problem we are aware of, but there seems to be broad consensus that this is the most concise and useful way to represent this data at present.
Roger has also pointed out the need for metadata exchange related to the aggregate datasets. Agree this is important but (i) I think this is a separate workflow and (ii) its a large enough challenge that it will have to fall outside the scope of v1.0. It is likely that such a workflow would involve a metadata repository actor which potentially involves terminology service or more domain specific hmis/imr-type repository service. Its not an issue we are going to address in this iteration.
Bob
–
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
On 10 September 2014 10:28, Ryan Crichton ryan@jembi.org wrote:
Hi all,
The SHR community had a good discussion around the workflows of how data could be sent to the HMIS on our call yesterday. We discussed some simple solutions that may be appropriate for the next OpenHIE release. I have captured these on the following 2 workflow pages:
Basically the first one is suggesting a plain pass through of DXF through from the point of care systems to DHIS via the IL. The second, is a little more complex and would require a mediator to be created in the IL that triggers on a certain time period and queries the SHR for information and then processes that information into the DXF format and send that off to DHIS.
In both cases the workflows are very DHIS2 specific. We discussed this and we think this is ok for an initial solution. But, we noted that in the future we may want to address this and find/develop standards to perform these tasks.
Also, previously these workflow have fallen under the responsibility of myself and the IL/SHR communities. But I think now with the inclusion of the HMIS community they may want to take over the stewardship of these workflows? This seems to make sense to me. The SHR and IL community would still want to be highly involved as the workflows have direct relationship to both of those components but perhaps the HMIS community should take the lead?
Please let me and the IL/SHR community know what you think of these workflows.
Cheers,
Ryan
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA