Timeline

Timeline expected:  current progress and processing speeds should double in 18 months to 3 years.  Most systems are already far behind, producing at just 2%-4% their potential productivity rates.  If they do produce a basic GIS method in 18 months, they will still be operating at their 2% to 4% low to poor productivity rates.  Companies that incorporate GIS fully in the next 15 months will at least have the potential to catch up in 1.5 (2015) to 3 years (2016/7).

It is interesting to see the order in which this technique was developed and then put into video format.  The following are different levels of development of the map videos.  You can see how the changes in presentation evolved.

The earliest stages may not be fully included in this review for IP related purposes.

The hardest thing for many to comprehend is the speed at which NPHG produces maps.

Therefore, the goal here is detail the speed at which this method works.  With several years experience using these algorithms, and watching as the system works faster over time with them, I can now come up with an approximation of how long it will take for the technique to be able to produce at it fastest rates per day.  Once the entire series of algorithms are integrated, the numbers of maps that can be produced per day for reporting purposes on a standard teradata system are what is so impressive about NPHG.

The following are my experiences with the rate of productivity of this work, for very slow to very fast days.

The very slow days are those when the system is bogged down by other running their queries, at least I believe that is what is slowing down to output productivity.  I state this because in the evenings, in particular a few minutes after work hours, the same program I just ran takes only have as long.  And by the time a half hour has passed, my productivity is triple to quadruple the speed of a little earlier.  There are also certain times at night when background programming is being run as well, also slowing down productivity.  But in general what I am seeing is that, using a very conservative estimation of productivity, I can produce:

  • 12 series of programming projects per 8 hr day,
  • 3.5 days per week
  • using the remaining 1.5 days to construct a presentation
  • with 375 images per series presented
  • 4 weeks per month about
  • 12 months per year
  • 50-52 weeks per year

The total productivity for the above scenario is

  • 12 x 3.5 = approx. 42 projects/week;
  • 42 x 375 images/project = 15,750 images (maps) per week,
  • 15,750 x 4 weeks, or 63,000 maps per month,
  • and for 10 months 630,000 per year, for a 12 month year, at 756,000 maps per year; this is equal to 3150 maps/business day over a ten month/year period.

Now to be fair about this,due to the nature of the programming I use,  videos are faster to produce than individual maps.  The speed of making 4 maps that are directly correlate takes about 1/4th the time it takes to produce 4 different unrelated maps of four completely different subjects.  However, we are producing 375 nearly identical maps, versus 4 different; this means that about 90 individual maps can be produced instead of 375 video maps.  Reapplying the above equations, with a 90 independent, unrelated maps production rate, we get:

  • 42 x 90 = 3,780 per week
  • 3,780 x 4 weeks per month = 15,120
  • for 10 months, for 12 months = 151,200 for 10 months, 181,440 maps for 12 months or per year; that is equal to 756 maps/business day over a ten month/year period;

Now let’s apply this to sample reports.

An in-migration disease, anti-bioterrorism report I expect to require from 250 to 350 disease reports per day, just one map for each disease/metric.  Divide weekly production rates by 5 to see how many reports could be generated per day . . . .

  • 3,780/5 = 756 single map ICD reports; or two total reports for two agencies, companies, locations, etc.
  • For a cultural medicine program, there are about 250 metrics that measure culturally bound, culturally linked, etc. diseases, meaning about the same length of time is needed.  We don’t normally need to run these types of reports daily; they are expected to be monthly or quarterly.  This enables us to generate individual reports for numerous ethnicity, culturally-defined or socioeconomically-defined groups, such as a series of low income communities, versus regional Hispanic, Asian and African American health care programs.    This means that as many as three reports per day can be generated based upon the 3,780/5 = 756 equation.  If you assign only half a month to generate these report so that detailed reports can be written up manually, we are talking about 6 reports per month for one worker engaged in this process.  But since even monthly is perhaps publishing it in terms of utility, a two month repeat process doubles the output to 12 per period, a three month or quarterly process to 18 per quarter.
  • We can also substitute cultural reports with any other topic, such as anatomic systems, department related ICD groups, surgeries by groups, high cost risks identified for the institution or program.  In general, this means that at this very slow, basic rate of productivity, we can develop detailed reports on about 20 items of special interest per quarter, per person working this kind of population health analysis position.

Now, let’s reduce the barriers that I noted exist for productivity.  We can automate a lot of these processes and eliminate delays.

With this newer process, the following productivity rates can be generated:

  • 20 series of programming projects per 12 hr day (we could say 18 hr or unlimited if it’s automatic),
  • 5 days per week (we’ll skip weekends productivity for now)
  • with 1500 images per series presented (I normally use 750-2000 images to produce an excellent video)
  • 4 weeks per month about
  • 12 months per year
  • 50-52 weeks per year

The total productivity for the above scenario is

  • 20 x 5 = approx. 60 projects/week;
  • 60 x 1500 images/project = 90,000 images (maps) per week,
  • 90,000 x 4 weeks, or 360,000 maps per month,
  • and for 10 months 3,600,000 per year, for a 12 month year, at 4,320,000 maps per year.  For a 10 month year: 18,000 maps/day for a 200 day business year of 10 months, 9863 maps/10 month fullyearday.  For a 12 month year: that is equal to 21,600/business day; 11,836/fullyearday

In essence, I am talking about producing between 7,500 and 20,000 maps per day on an automated system, resulting in a basic 40 to 50 reports per month, perhaps as much as 100 reports per month depending on the topics and frequency of reporting.

  • Ratio of change in rates = 9863/3150 for 10 month fullyear day numbers, or 3.1

Applying this to bioterrorism daily surveying, this method will produce two or three department reports of 350 diseases each per day, if done manually.  10 per day on a long day, minimum.  3500 diseases or metrics reported on per day for surveillance, per system at work.

Within the next few years, the Big Data systems will speed up this process.  Ideally, we should be able to generate more maps and more reports per day, tripling to quadrupling this productive rate in about 3 years.  If we believe in the 15 month doubling rates given for hardware productivity, double that rate even.

For most managed care systems, we can report on 1000 down to 500 metrics per month with little effort using this method, so long as the right hardware-software-system set up is available.  Since the current systems are working on just 5 to 20 maps per year, not really projects, they are at 20/1000 to 20/500 or 2% to at most 4% their potential productivity rates, if they do routinely generate 20 map reports per year.

[Will recheck all of these numbers later.]