Local health agencies have been reporting to their state counterparts for decades.
Of course state health agencies have an important role to play in the public health system, as they set policy through legislation and regulation, and dispense funds.
The natural consequence of policy and funding is reporting, to ensure services are provided and funds properly spent.
The decades of the 1980s and 1990s saw widespread adoption of automation in local health agencies, as the personal computer revolution spread from the business world to the government sector.
This brought an end to the era of hand-tabulating tallies of services performed, with reports submitted on paper forms.
With the advent of database software, whether dBASE or Access on the personal computer, or more sophisticated software running on mini-computers or mainframes, local health agencies could collect data on a daily basis, and generate reports at will.
In this environment EHR software companies emerged.
In Minnesota, there were in the late 1980s and early 1990s at least five different software companies offering their products to local health agencies.
A similar situation occurred in neighboring Wisconsin, although the differing role of local health agencies in other states may have led to a different software solution.
For example, in some states the state health agency has built software for selected public health services and offered or mandated it for use in local health agencies.
There is clearly a connection between the interests of a state health agency in designing state reporting systems, and that of software vendors who sell to local health agencies the tools needed to collect data for those state reports.
What should the relationship be between these parties?
Here are the actors:
- The state health agency
- One or more software vendors
- A variety of local health agencies, some small, with limited technical resources, and others large, with greater resources and perhaps systems they have built for themselves
Each of these actors brings unique strengths to the conversation.
The state agency understands the needs for consistency and uniformity, in order to be able to report to the legislature or federal government.
The software vendor understands how to design screens to collect data, a database for storing data, and reports to tally data.
But the local agency understands work flow and the service delivery processes which must mesh with the collection and reporting of data.
Certainly, the need to collect and report data is secondary to the priority of delivering quality services to clients.