SHR Transaction Volume Estimates

[Hannes_Venter]

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

···

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

[Lemmon_Larry]

Another useful transaction metric for the HIM and SHR could be derived from estimated visits (encounters) per day nationwide. Each visit would generate
requests to the Client Registry, Facility Registry, Provider Registry, Terminology Service, and to SHR to persist/retrieve data. Additional transactions for ad hoc queries not related to a visit, and for post-visit follow up could contribute something like
10-20% of the daily transaction volume for visits. Adding these together would give a rough estimate of total daily transactions.

This daily transaction volume based on visits and ad hoc queries should be considered to happen during a specific time span, say during daylight hours
(12 hours). And then peak transaction volumes could be estimated by multiplying the average volume by a factor, say 2 times the average volume. Or alternatively, peak times could be considered as say 3 hours in the morning, and account for say 60 percent
of daily volume. This peak transaction volume would be what the HIM and SHR should be tested against.

The numbers used above are not meant to be exact, only to indicate the methodology

that could be used to determine the transaction volumes. Using this, the peak transactions per second would be determined. The HIM and SHR would need
to handle this volume. It would seem that using Kenya as an example (instead of Rwanda) would give a better estimate of the transaction volume that OpenHIE would ultimately need to handle. However, Rwanda could be used as a basis for determining when the
peak hours are, and percentage above the average that peak transactions represent.

Larry Lemmon

Regenstrief Institute for Health Care

Indianapolis, IN 46202

llemmon@regenstrief.org

On Behalf Of Hannes Venter

···

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Ryan1]

Thanks Larry, this is useful. At the moment we are busy expanding our estimates to be more accurate. One thing that we haven’t considered is peak volume at the busiest hours. I will add this factor into our spreadsheet.

Hannes, I’m thinking that we should perhaps look at the average population of countries that have shown interest in the OpenHIE work (Kenya, Tanzinia, Zimbabwe and Rwanda) as a start point for the estimates of national scale. Perhaps this will give us a good value to start with. What do others think of this?

Cheers,

Ryan

···

On Tue, Mar 12, 2013 at 2:57 PM, Lemmon, Larry llemmon@regenstrief.org wrote:

Another useful transaction metric for the HIM and SHR could be derived from estimated visits (encounters) per day nationwide. Each visit would generate
requests to the Client Registry, Facility Registry, Provider Registry, Terminology Service, and to SHR to persist/retrieve data. Additional transactions for ad hoc queries not related to a visit, and for post-visit follow up could contribute something like
10-20% of the daily transaction volume for visits. Adding these together would give a rough estimate of total daily transactions.

This daily transaction volume based on visits and ad hoc queries should be considered to happen during a specific time span, say during daylight hours
(12 hours). And then peak transaction volumes could be estimated by multiplying the average volume by a factor, say 2 times the average volume. Or alternatively, peak times could be considered as say 3 hours in the morning, and account for say 60 percent
of daily volume. This peak transaction volume would be what the HIM and SHR should be tested against.

The numbers used above are not meant to be exact, only to indicate the methodology

that could be used to determine the transaction volumes. Using this, the peak transactions per second would be determined. The HIM and SHR would need
to handle this volume. It would seem that using Kenya as an example (instead of Rwanda) would give a better estimate of the transaction volume that OpenHIE would ultimately need to handle. However, Rwanda could be used as a basis for determining when the
peak hours are, and percentage above the average that peak transactions represent.

Larry Lemmon

Regenstrief Institute for Health Care

Indianapolis, IN 46202

llemmon@regenstrief.org

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Hannes Venter
Sent: Tuesday, March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

[ryan]

(apologies if you are getting this twice, I replied with the incorrect mail account)

Thanks Larry, this is useful. At the moment we are busy expanding our estimates to be more accurate. One thing that we haven’t considered is peak volume at the busiest hours. I will add this factor into our spreadsheet.

Hannes, I’m thinking that we should perhaps look at the average population of countries that have shown interest in the OpenHIE work (Kenya, Tanzinia, Zimbabwe and Rwanda) as a start point for the estimates of national scale. Perhaps this will give us a good value to start with. What do others think of this?

Cheers,

Ryan

···

On Tue, Mar 12, 2013 at 2:57 PM, Lemmon, Larry llemmon@regenstrief.org wrote:

Another useful transaction metric for the HIM and SHR could be derived from estimated visits (encounters) per day nationwide. Each visit would generate
requests to the Client Registry, Facility Registry, Provider Registry, Terminology Service, and to SHR to persist/retrieve data. Additional transactions for ad hoc queries not related to a visit, and for post-visit follow up could contribute something like
10-20% of the daily transaction volume for visits. Adding these together would give a rough estimate of total daily transactions.

This daily transaction volume based on visits and ad hoc queries should be considered to happen during a specific time span, say during daylight hours
(12 hours). And then peak transaction volumes could be estimated by multiplying the average volume by a factor, say 2 times the average volume. Or alternatively, peak times could be considered as say 3 hours in the morning, and account for say 60 percent
of daily volume. This peak transaction volume would be what the HIM and SHR should be tested against.

The numbers used above are not meant to be exact, only to indicate the methodology

that could be used to determine the transaction volumes. Using this, the peak transactions per second would be determined. The HIM and SHR would need
to handle this volume. It would seem that using Kenya as an example (instead of Rwanda) would give a better estimate of the transaction volume that OpenHIE would ultimately need to handle. However, Rwanda could be used as a basis for determining when the
peak hours are, and percentage above the average that peak transactions represent.

Larry Lemmon

Regenstrief Institute for Health Care

Indianapolis, IN 46202

llemmon@regenstrief.org

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Hannes Venter
Sent: Tuesday, March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

[sgrannis]

Good conversation!

I like Larry’s notion of thinking about an encounter-based approach.

One data point – our experience in the U.S. (Indiana) is that we receive about 5 ADT (registration) messages per ED visit (initial registration, then multiple updates)

···

On Tue, Mar 12, 2013 at 9:06 AM, Ryan ryan@jembi.org wrote:

(apologies if you are getting this twice, I replied with the incorrect mail account)

Thanks Larry, this is useful. At the moment we are busy expanding our estimates to be more accurate. One thing that we haven’t considered is peak volume at the busiest hours. I will add this factor into our spreadsheet.

Hannes, I’m thinking that we should perhaps look at the average population of countries that have shown interest in the OpenHIE work (Kenya, Tanzinia, Zimbabwe and Rwanda) as a start point for the estimates of national scale. Perhaps this will give us a good value to start with. What do others think of this?

Cheers,

Ryan

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine

Director, Indiana Center of Excellence in Public Health Informatics
410 West 10th Street, Suite 2000

Indianapolis, IN 46202
(317) 423-5523 (O)
(317) 423-5695 (F)

On Tue, Mar 12, 2013 at 2:57 PM, Lemmon, Larry llemmon@regenstrief.org wrote:

Another useful transaction metric for the HIM and SHR could be derived from estimated visits (encounters) per day nationwide. Each visit would generate
requests to the Client Registry, Facility Registry, Provider Registry, Terminology Service, and to SHR to persist/retrieve data. Additional transactions for ad hoc queries not related to a visit, and for post-visit follow up could contribute something like
10-20% of the daily transaction volume for visits. Adding these together would give a rough estimate of total daily transactions.

This daily transaction volume based on visits and ad hoc queries should be considered to happen during a specific time span, say during daylight hours
(12 hours). And then peak transaction volumes could be estimated by multiplying the average volume by a factor, say 2 times the average volume. Or alternatively, peak times could be considered as say 3 hours in the morning, and account for say 60 percent
of daily volume. This peak transaction volume would be what the HIM and SHR should be tested against.

The numbers used above are not meant to be exact, only to indicate the methodology

that could be used to determine the transaction volumes. Using this, the peak transactions per second would be determined. The HIM and SHR would need
to handle this volume. It would seem that using Kenya as an example (instead of Rwanda) would give a better estimate of the transaction volume that OpenHIE would ultimately need to handle. However, Rwanda could be used as a basis for determining when the
peak hours are, and percentage above the average that peak transactions represent.

Larry Lemmon

Regenstrief Institute for Health Care

Indianapolis, IN 46202

llemmon@regenstrief.org

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Hannes Venter
Sent: Tuesday, March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

–
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

[dritz]

Hi all.

My sense is that extrapolation could be based on:

1. the care guidelines we are operationalizing

2. the size of population that is enrolled in the care plans

In this way, we would be able to estimate transaction volume profiles based on, for example:

· X pregnant women, each of whom will attend 4 ANC visits plus a delivery visit

· Each ANC visit will include an ID resolution (PIX) transaction plus Y clinical readings (weight, BP, temperature, etc.); the first visit will also include a history and a lab result transaction

· Proportion P of these women will have complications requiring R acute care referrals & visits

· Proportion H of these women will be HIV+ and will require A ARV prescription orders & fills

· Proportion T of these women will suffer from TB and will require D drug orders & fills

· Etc.

Developing a profile based on recent USAID survey figures regarding burden of disease will enable not only transaction volumes but transaction types/characteristics. Since these survey figures are typically broken out by province, it could even indicate our load profile by province (if we felt like being tricky about our estimates).

My point is that a set of algorithms which estimate transaction volumes by care guideline (maternal, HIV, TB, Malaria, IMCI, etc.) and by population and proportion could be readily scaled for any region/population for which we have survey data (www.statcompiler.com).

Just a thought…

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

···

---

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Hannes_Venter]

Thanks Derek, a really good thought I really like the idea of basing this on care guidelines.
And then like Ryan said; we can then perhaps focus on the stat data for some select countries such as Kenya, Tanzania, Zimbabwe and Rwanda.

Cheers

Hannes

···

On Tue, Mar 12, 2013 at 3:28 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

My sense is that extrapolation could be based on:

1. the care guidelines we are operationalizing

2. the size of population that is enrolled in the care plans

In this way, we would be able to estimate transaction volume profiles based on, for example:

· X pregnant women, each of whom will attend 4 ANC visits plus a delivery visit

· Each ANC visit will include an ID resolution (PIX) transaction plus Y clinical readings (weight, BP, temperature, etc.); the first visit will also include a history and a lab result transaction

· Proportion P of these women will have complications requiring R acute care referrals & visits

· Proportion H of these women will be HIV+ and will require A ARV prescription orders & fills

· Proportion T of these women will suffer from TB and will require D drug orders & fills

· Etc.

Developing a profile based on recent USAID survey figures regarding burden of disease will enable not only transaction volumes but transaction types/characteristics. Since these survey figures are typically broken out by province, it could even indicate our load profile by province (if we felt like being tricky about our estimates).

My point is that a set of algorithms which estimate transaction volumes by care guideline (maternal, HIV, TB, Malaria, IMCI, etc.) and by population and proportion could be readily scaled for any region/population for which we have survey data (www.statcompiler.com).

Just a thought…

Derek.

---

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

---

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

[Ryan1]

Derek, that sounds like a good way to go. We have already started to break these out by the types of transactions that we currently have in Rwanda. I’m going to try get in touch with Randy (from Liz’s suggestion) as he can provide us with more detailed data for Rwanda.

Here is what we have so far, working from what Shaun put together previously for RHEA: https://docs.google.com/spreadsheet/ccc?key=0Ah8KVMJr8h4pdHhXaGptblVlc1NLSVYwN2lXa2RJZUE#gid=0

I’ve included Larry’s suggestion that load won’t be evenly spread out but we will likely encounter ‘peak time load’. I’ve estimated this as a factor of 3 but does anyone have a better understanding of how much load will increase from the average during peak time in a clinical setting.

Cheers,

Ryan

···

On Tue, Mar 12, 2013 at 3:48 PM, Hannes Venter hannes@jembi.org wrote:

Thanks Derek, a really good thought I really like the idea of basing this on care guidelines.
And then like Ryan said; we can then perhaps focus on the stat data for some select countries such as Kenya, Tanzania, Zimbabwe and Rwanda.

Cheers

Hannes

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

On Tue, Mar 12, 2013 at 3:28 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

My sense is that extrapolation could be based on:

1. the care guidelines we are operationalizing

2. the size of population that is enrolled in the care plans

In this way, we would be able to estimate transaction volume profiles based on, for example:

· X pregnant women, each of whom will attend 4 ANC visits plus a delivery visit

· Each ANC visit will include an ID resolution (PIX) transaction plus Y clinical readings (weight, BP, temperature, etc.); the first visit will also include a history and a lab result transaction

· Proportion P of these women will have complications requiring R acute care referrals & visits

· Proportion H of these women will be HIV+ and will require A ARV prescription orders & fills

· Proportion T of these women will suffer from TB and will require D drug orders & fills

· Etc.

Developing a profile based on recent USAID survey figures regarding burden of disease will enable not only transaction volumes but transaction types/characteristics. Since these survey figures are typically broken out by province, it could even indicate our load profile by province (if we felt like being tricky about our estimates).

My point is that a set of algorithms which estimate transaction volumes by care guideline (maternal, HIV, TB, Malaria, IMCI, etc.) and by population and proportion could be readily scaled for any region/population for which we have survey data (www.statcompiler.com).

Just a thought…

Derek.

---

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

---

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

[ryan]

Derek, that sounds like a good way to go. We have already started to break these out by the types of transactions that we currently have in Rwanda. I’m going to try get in touch with Randy (from Liz’s suggestion) as he can provide us with more detailed data for Rwanda.

Here is what we have so far, working from what Shaun put together previously for RHEA: https://docs.google.com/spreadsheet/ccc?key=0Ah8KVMJr8h4pdHhXaGptblVlc1NLSVYwN2lXa2RJZUE#gid=0

I’ve included Larry’s suggestion that load won’t be evenly spread out but we will likely encounter ‘peak time load’. I’ve estimated this as a factor of 3 but does anyone have a better understanding of how much load will increase from the average during peak time in a clinical setting.

Cheers,

Ryan

···

On Tue, Mar 12, 2013 at 3:48 PM, Hannes Venter hannes@jembi.org wrote:

Thanks Derek, a really good thought I really like the idea of basing this on care guidelines.
And then like Ryan said; we can then perhaps focus on the stat data for some select countries such as Kenya, Tanzania, Zimbabwe and Rwanda.

Cheers

Hannes

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

On Tue, Mar 12, 2013 at 3:28 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

My sense is that extrapolation could be based on:

1. the care guidelines we are operationalizing

2. the size of population that is enrolled in the care plans

In this way, we would be able to estimate transaction volume profiles based on, for example:

· X pregnant women, each of whom will attend 4 ANC visits plus a delivery visit

· Each ANC visit will include an ID resolution (PIX) transaction plus Y clinical readings (weight, BP, temperature, etc.); the first visit will also include a history and a lab result transaction

· Proportion P of these women will have complications requiring R acute care referrals & visits

· Proportion H of these women will be HIV+ and will require A ARV prescription orders & fills

· Proportion T of these women will suffer from TB and will require D drug orders & fills

· Etc.

Developing a profile based on recent USAID survey figures regarding burden of disease will enable not only transaction volumes but transaction types/characteristics. Since these survey figures are typically broken out by province, it could even indicate our load profile by province (if we felt like being tricky about our estimates).

My point is that a set of algorithms which estimate transaction volumes by care guideline (maternal, HIV, TB, Malaria, IMCI, etc.) and by population and proportion could be readily scaled for any region/population for which we have survey data (www.statcompiler.com).

Just a thought…

Derek.

---

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

---

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

[Kari_Schoonbee]

Hi Ryan

I think it depends how the system is used. If save encounters are done by data clerks all over the country at the end of each clinic day I think the peak factor will probably be much higher. If it's done in real time on a per-patient basis I don't think it will be that high. We also need to think how these transactions are handled. In the case of the data entry clerk, if the HIE just acknowledges the requests and puts the transactions in a queue then it's not too much of an issue if they aren't saved immediately.

Another factor that will have an influence on the responsiveness of the system is the size of the messages, especially as far as bandwidth is concerned in low-resource settings. It sounds like internet connectivity is quite bad at Musha and Ruhondo. Is a verbose format like XML optimal or should we look at other options?

Kari Schoonbee
Software Engineer - Jembi Health Systems | SOUTH AFRICA
Mobile: +27 83 488 3025 | Office: +27 21 701 0939
E-mail: kari@jembi.org

···

On 14 Mar 2013, at 10:39 AM, Ryan <ryan@jembi.org> wrote:

Derek, that sounds like a good way to go. We have already started to break these out by the types of transactions that we currently have in Rwanda. I'm going to try get in touch with Randy (from Liz's suggestion) as he can provide us with more detailed data for Rwanda.

Here is what we have so far, working from what Shaun put together previously for RHEA: Transaction volume estimates (from Shaun) - Google Sheets

I've included Larry's suggestion that load won't be evenly spread out but we will likely encounter 'peak time load'. I've estimated this as a factor of 3 but does anyone have a better understanding of how much load will increase from the average during peak time in a clinical setting.

Cheers,
Ryan

On Tue, Mar 12, 2013 at 3:48 PM, Hannes Venter <hannes@jembi.org> wrote:
Thanks Derek, a really good thought I really like the idea of basing this on care guidelines.
And then like Ryan said; we can then perhaps focus on the stat data for some select countries such as Kenya, Tanzania, Zimbabwe and Rwanda.

Cheers
Hannes

On Tue, Mar 12, 2013 at 3:28 PM, Derek Ritz (ecGroup) <derek.ritz@ecgroupinc.com> wrote:
Hi all.

My sense is that extrapolation could be based on:

1. the care guidelines we are operationalizing

2. the size of population that is enrolled in the care plans

In this way, we would be able to estimate transaction volume profiles based on, for example:

· X pregnant women, each of whom will attend 4 ANC visits plus a delivery visit

· Each ANC visit will include an ID resolution (PIX) transaction plus Y clinical readings (weight, BP, temperature, etc.); the first visit will also include a history and a lab result transaction

· Proportion P of these women will have complications requiring R acute care referrals & visits

· Proportion H of these women will be HIV+ and will require A ARV prescription orders & fills

· Proportion T of these women will suffer from TB and will require D drug orders & fills

· Etc.

Developing a profile based on recent USAID survey figures regarding burden of disease will enable not only transaction volumes but transaction types/characteristics. Since these survey figures are typically broken out by province, it could even indicate our load profile by province (if we felt like being tricky about our estimates).

My point is that a set of algorithms which estimate transaction volumes by care guideline (maternal, HIV, TB, Malaria, IMCI, etc.) and by population and proportion could be readily scaled for any region/population for which we have survey data (www.statcompiler.com).

Just a thought…

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
--------------------------------------------------------------------------------
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s'adressent exclusivement au destinataire mentionné ci-dessus. L'expéditeur ne renonce pas aux droits et privilèges qui s'y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m'en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter
Sent: March 12, 2013 6:50 AM
To: openhie-shr; openhim-dev@googlegroups.com
Subject: SHR Transaction Volume Estimates

Hi Everyone,

We've been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we've been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some "generic use case"?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda's 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya's national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don't know what a Kenya shr would look like...).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond "rwandan"-workloads, you need to think about the architecture differently?

And if this is valid: what should the "target population size" be? Is the target Kenya, Tanzania? ... USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn't mean that scalability is never taken into account,

on the contrary, it's a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes
--
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

--

You received this message because you are subscribed to the Google Groups "Shared Health Record (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "OpenHIM-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Hannes Venter
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org

--
You received this message because you are subscribed to the Google Groups "OpenHIM-Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

--
You received this message because you are subscribed to the Google Groups "Shared Health Record (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[ryan]

Hi Kari,

You are definitely correct, it will depend on how the systems is used. So, the question becomes how do we anticipate how the system will be used? Data entry seems like it will be the most crippling aspects for the SHR as data is getting entered quick over a specific period of time. How do we estimate the increase of load is the question. Does anyone have any good idea around this?

If we queue transactions in the SHR we run into a consistency problem. We can never know when the changes that we have sent to the SHR have been saved. So when you query the SHR for data the response that you get back may be inconsistent with what has been sent to the SHR. Consistency isn’t essential in some use cases but with regard to health information I think consistency is important. I believe Derek and Justin were raising a similar concern on a previous call.

Message size is important it can be solved in other ways that just a change of message format however. We could look into compression of our HTTP traffic. We will have to find a balance of an appropriate, standards based message format and realistic message size.

Cheers,

Ryan

···

On Thu, Mar 14, 2013 at 10:57 AM, Kari Schoonbee kari@jembi.org wrote:

Hi Ryan

I think it depends how the system is used. If save encounters are done by data clerks all over the country at the end of each clinic day I think the peak factor will probably be much higher. If it’s done in real time on a per-patient basis I don’t think it will be that high. We also need to think how these transactions are handled. In the case of the data entry clerk, if the HIE just acknowledges the requests and puts the transactions in a queue then it’s not too much of an issue if they aren’t saved immediately.

Another factor that will have an influence on the responsiveness of the system is the size of the messages, especially as far as bandwidth is concerned in low-resource settings. It sounds like internet connectivity is quite bad at Musha and Ruhondo. Is a verbose format like XML optimal or should we look at other options?

Kari Schoonbee

Software Engineer - Jembi Health Systems | SOUTH AFRICA

Mobile: +27 83 488 3025 | Office: +27 21 701 0939

E-mail: kari@jembi.org

On 14 Mar 2013, at 10:39 AM, Ryan ryan@jembi.org wrote:

Derek, that sounds like a good way to go. We have already started to break these out by the types of transactions that we currently have in Rwanda. I’m going to try get in touch with Randy (from Liz’s suggestion) as he can provide us with more detailed data for Rwanda.

Here is what we have so far, working from what Shaun put together previously for RHEA: https://docs.google.com/spreadsheet/ccc?key=0Ah8KVMJr8h4pdHhXaGptblVlc1NLSVYwN2lXa2RJZUE#gid=0

I’ve included Larry’s suggestion that load won’t be evenly spread out but we will likely encounter ‘peak time load’. I’ve estimated this as a factor of 3 but does anyone have a better understanding of how much load will increase from the average during peak time in a clinical setting.

Cheers,

Ryan

On Tue, Mar 12, 2013 at 3:48 PM, Hannes Venter hannes@jembi.org wrote:

Thanks Derek, a really good thought I really like the idea of basing this on care guidelines.

And then like Ryan said; we can then perhaps focus on the stat data for some select countries such as Kenya, Tanzania, Zimbabwe and Rwanda.

Cheers

Hannes

On Tue, Mar 12, 2013 at 3:28 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

My sense is that extrapolation could be based on:

1. the care guidelines we are operationalizing

2. the size of population that is enrolled in the care plans

In this way, we would be able to estimate transaction volume profiles based on, for example:

· X pregnant women, each of whom will attend 4 ANC visits plus a delivery visit

· Each ANC visit will include an ID resolution (PIX) transaction plus Y clinical readings (weight, BP, temperature, etc.); the first visit will also include a history and a lab result transaction

· Proportion P of these women will have complications requiring R acute care referrals & visits

· Proportion H of these women will be HIV+ and will require A ARV prescription orders & fills

· Proportion T of these women will suffer from TB and will require D drug orders & fills

· Etc.

Developing a profile based on recent USAID survey figures regarding burden of disease will enable not only transaction volumes but transaction types/characteristics. Since these survey figures are typically broken out by province, it could even indicate our load profile by province (if we felt like being tricky about our estimates).

My point is that a set of algorithms which estimate transaction volumes by care guideline (maternal, HIV, TB, Malaria, IMCI, etc.) and by population and proportion could be readily scaled for any region/population for which we have survey data (www.statcompiler.com).

Just a thought…

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.

---

Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From: openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com] On Behalf Of Hannes Venter

Sent: March 12, 2013 6:50 AM

To: openhie-shr; openhim-dev@googlegroups.com

Subject: SHR Transaction Volume Estimates

Hi Everyone,

We’ve been looking at creating some performance indicators for the OpenSHR and the OpenHIM.

One such indicator would be the estimated work load for a national SHR,

and we’ve been using the Rwandan transaction estimates that Shaun created

(the figure of which is around 8 transactions per second for national rollout).

One question though is should this figure be extrapolated for some “generic use case”?

In other words: would it be valid to say, we can handle 8 transactions per second for

Rwanda’s 11 000 000 people, so we should test against X transactions per second

for a population of 44 000 000 (Kenya’s national population for example)?

One problem we see with extrapolation though is that a national shr in Kenya (once again e.g.)

might not look like a national shr in Rwanda, they might want to partition the system by province, or something like that

(the point being we don’t know what a Kenya shr would look like…).

I.e. the question is whether we can assume such an extrapolation is valid?

Or would it be the case that the minute you start scaling beyond “rwandan”-workloads, you need to think about the architecture differently?

And if this is valid: what should the “target population size” be? Is the target Kenya, Tanzania? … USA?

Our current feeling is that we should just focus on the stats we have,

and basically focus on Rwanda as a performance test case for any SHR/HIM systems we evaluate.

(Of course this certainly wouldn’t mean that scalability is never taken into account,

on the contrary, it’s a very important aspect to look at)

All thoughts and opinions on this topic are highly welcome

Kind Regards

Hannes

–

Hannes Venter

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes

E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–

Hannes Venter

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes

E-mail: hannes@jembi.org

–

You received this message because you are subscribed to the Google Groups “OpenHIM-Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhim-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–

Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

–

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

–
Ryan Crichton

Senior Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org