Background
In this paper, I will lay out a view of what an Election Management System (EMS) is, what it does, and some of the key considerations and principles that have led to this view. At the outset, let’s admit that the term “Election Management System” does not have a fully accepted definition. The view put forth in this paper is based on work at the Open Source Digital Voting Foundation, both in scrutinizing various States’ approaches, white papers and RFIs, and in careful technical architecture and prototyping work.
What is an EMS?
An EMS, at its core, is a data management application. The data it manages are the critical facts needed to organize and conduct elections: dates, deadlines, contests, candidates, precincts and so on.
An EMS will be required to exchange information with a variety of other systems, some closely related to elections (e.g. Voter Registration,) some requiring specialized interfaces (e.g. Ballot Design and Production) and perhaps some requiring stand-alone equipment (e.g. Precinct Count Optical Scan Systems.)
Real World Scenarios
... A Jurisdictional election official is beginning to plan for the next election. He or she begins the process by defining the Election in the EMS, naming it and specifying the deadline dates as they are known. Perhaps they use a previous Election as a template to get things going quickly. The Election, in a “planning mode”, does not appear on any other screens yet, as much information is not yet available. The EMS in fact flags this election with a list of “pending actions.”
... Perhaps some of the races are already known, so the official begins defining those races, just by name, and maybe some candidates, relevant districts, and other information, if they are known. Now a local official can go on to define some local races, again supplying what they know so far.
... So this process continues, and at each stage, each EMS user can see how much of the information that they are responsible for has been entered and what is still pending. Precinct level officials might be interested to see how complete the information is that pertains to them and how the ballot definitions are starting to look.
... Deadlines are approaching and changes have to be completed, so that detailed ballot layouts can be generated for printing. Perhaps this is done by a Ballot Design module, or perhaps the choice is made to export the detailed information from an EMS to a separate system responsible for the design and production of the ballots.
Of course there are many other facets to the use and experience of an EMS. The above scenarios are just one slice of the experience.
|
Design Principles
It is useful to think about fundamental design principles to guide the creation of a system such as this. While the detailed requirements are being researched and understood, here are a set of guidelines that might be useful to keep in mind:
- Choice - An EMS should be useful at both the State and Local level. It should not require wholesale adoption by a state., but rather encourage adoption in stages. Initially for example for one Jurisdiction, then for several, then for the State, and so on.
- Core system plus functional modules - A concerted effort should be made to separate the crucial minimal core of the system from capabilities which, while essential to some states, may not be a priority in others. Capabilities such as that should be constructed modularly so that requirements of each entity can be implemented according to their priority.
- Access control - All access to the EMS should be through a log in process, whereby users identify themselves and their role and privileges are ascertained. Users are assigned a log in, password, and membership to one or more groups. All operations, including querying entry and updating, reporting, and administration of the EMS are access controlled.
- Extensibility - The Core system manages the central data elements and relationships. In all cases the data elements include only the most fundamental attributes. Additional information can be appended to all these records by the functional modules that are included.
Additional Links
|
