[Technical] Designing an Access Control Application for Convention Event Management
In order to implement a crowd management system which is capable of capping the number of attendees in a given area, provides for security in making sure that the system can't be subverted by a bad actor from outside, and which is fast and easy to train new users on, you can use the commonly available cell phone, a custom web app, and cheaply printed custom tear-off tickets with sequential UPC to build a scalable, robust implementation.
Requirements
Controlling entry into a public space, a number of things have to be present in order to be possible. Note that this discussion doesn't discuss controlling or tracking exits from an event space.
- An area with clear bottlenecks, of at most two-person wide entries
- Staff interested in and empowered to control entry at the bottlenecks
- A means of controlling and tracking individual entries to the space
- A cell phone or tablet with camera for each controlling staffer
- Staff within the space interested in , trained, and empowered to control limited seating
- Clear pre-determined numbers of maximum attendees
Core Mechanism
In order to track the presence or absence of any entity, that entity must be uniquely identified in some way. If entities must be treated in different ways within the scope of the area controlled, individual identification is necessary. The only real alternative is to throw additional manpower and higher-speed communication between staff for one at a time allocation which increases costs and slows processes.1
Within the scope of discussion of this article (Dragon Con), there are only two potential tracking identifiers available for crowds.
- The badge ID uniquely tied to each issued badge, readable as a UPC or QR code on the back
- A unique issued token (card or ticket) issued at the queuing area of the event and subsequently returned on entry
The issued badge ID is the ideal piece of tracking information. The convention has a responsibility for each of them to be unique, they are able to be tied to an individual in the case of theft or repeated violation, they are non-fungible, they are permanent and durable, and they are required to be on the person of every attendee at all times when involved in convention activities. The cost for their creation and maintenance is borne by the convention as a whole so there is a vested interest by the organization to make use of that information.
Independent and uniquely issued tokens represent an actual, nonrecoverable cost for every event they are used at, do not provide tracking feedback to the organization about who is interested in what particularly heavily attended event, and are intentionally ephemeral. However, they provide a very clear process-forward system for attendees to see and understand, the idea of receiving a ticket in order to see an event is something already built into social awareness, being marked with both machine-readable and human readable sequential information, they can be used to enforce line order if necessary, and especially when it comes to the questions around Disability Services reasonable accommodation, the lack of tie to any specific individual removes even the temptation or appearance of impropriety when it comes to HIPPA isolation.2
The rest of this article will focus on the more complicated issue of providing reasonable accommodation from a limited pool of seats/access points in the venue, but the overall architecture should be applicable to solving the larger problem of access control of areas for the general population. In thinking about solving the more general problem, looking at solutions which use the more rugged individual identification of the badge is probably the better option, with dealing with DS issues pushed down to simply keeping individually identifiable association between injury and reasonable accommodation isolated in a second database which can be burned at the end of the event.
Application Support
Let's outline the conceptual process and then break that down into what a specific digital application would need to manage in order to make it possible.
What we need to do is issue a token to attendees as they arrive, roughly sequentially, to represent that they have been acknowledged and their particular needs have been at least roughly observed. At the time of seating, individuals need to present their token, it needs to be observed by staff, it needs to be canceled in some way so that it can't be reused, and they need to be routed into the event area to be handed off to the staff responsible for seating. This needs to occur right up to the point when the maximum capacity has been reached, and then the access staff need to be aware that all the seats have been allocated and no more entries are permitted. For DS, this will occur much earlier than for gen pop, because they load earlier. It takes longer for movement-impaired individuals to make their way to their seats and doing so can sometimes be disruptive. There will be much more limited numbers of available seats for DS and their specific locations within the event space will also be limited because of attendee reasonable accommodation requirements.
Why An App?
What are the things computers are objectively better at than humans?
- Memory, for what IDs have been seen already
- Counting, for keeping up with entrance numbers
- Perception, for reading sequential numbers easily in challenging light situations
- Non-Locality, for being able to do this in multiple places at the same time
The digital application needs to bring all of these things to bear.
Configuration
Several pieces of information are necessary to have the system function at all. Functionally, they are generalizable and able to to be used for controlling multiple venue areas simultaneously.
- Name of the venue area
- Name of the Event
- Maximum count of the entries to the venue area
- Optional: Specific counts for types of entries to the venue area3
- Beginning sequential ID for this event (which may be the last sequential ID + 1 for events happening one after another)
- Optional: Name/ID of staffer using application (for assessment and responsibility)
Process
How might this actually look in operation?
We will assume that the application is running as a web app on a single, known URL. This means that any device can access it with that information and we are not limited to a specific set of devices or specific kind of device, providing the best flexibility for delivering the service.4
At the beginning of day, before any events, an organization member responsible for access control will review and update Configuration information for the specific event space. Counts should be reviewed and if necessary adjusted based on new information.
Before the event, staff users should update their individual Configuration information (personal ID, starting sequence ID, and any other optional information in use that day). All users should make sure that Configuration data cross checks between them to avoid not being synchronized.
As the event is queuing, staffers give out tokens to individual attendees who are qualified to receive them. Whenever possible, this should be on a first-come, first-served basis. It is up to the staffer, not to the application, to determine if someone is qualified to receive a token. Because people can come and go during the queuing process, there is no expected cap on the number of tokens to be given out. If process managers do want to limit the number of tokens handed out, Configuration should include maximum tokens (which should be at least the number of spaces available plus a slop factor). With that information available, the application itself can come into use as a counter with the staffer clicking a button for every token given out and receiving feedback when maximum tokens have been distributed.
Once queuing is done and loading began, staffers arrange their queue into a line and begin processing individuals as they move into the event space by using the camera on their device to rapidly scan ID UPC/QR codes and optionally click a button in order to designate the type of seating being granted based on available information.5
Staffers within the event space have no need of the application but they will know if there is a person entering the space, that person has been vetted, counts have not been exceeded, and they should proceed with local assessment and seat assignment with established policy.
Once maximum counts have been reached (potentially in the case of specifically limited spaces long before less limited spaces have been consumed), the staffers at the doors will be alerted by the application and they will know to stop allowing attendees into the event space.
In order to maintain orderly and reasonable assumption of first-come, first-served, the application will monitor the sequential IDs and if the current ID is outside of the expected ID plus or minus a slop factor, the application will alert the staffers controlling entry, allowing them to review the lineup or ignore the alert, resetting the expected sequential ID to move forward with loading.
Likewise, if the application detects a repeated sequential ID being presented, it will alert the staffer and allow them to decide on action in accordance with local policy.
Once loading is completed and the event underway, entry staffers take the time to review the Configuration information for the next event they are responsible for, check counts, make sure that the actual ground truth of seats occupied in the event space makes sense when compared to what the application says it should be, and prepare to begin queuing for the next event.
At end of day, organization oversight members may generate reports based on activity seen during the day in order to make policy decisions for the next event.
Database Concerns
Specifically as pertains to the operation of Disability Services in the context of providing reasonable accommodation in the convention space, HIPPA regulations are meaningful. Access to and accumulation of private medical information, including whether a given individual possesses a specific type of disability, has certain legal obligations.
It is important to note that this information does not have to be perfectly secure but only sufficiently secure. Perfect security is impossible but sufficient security is well within our means.
The ephemerality of the disposable ticket allocated at queuing time provides a great service to us. Because it cannot be independently traced to a given individual, nothing about keeping track of that information needs to be particularly private. All information is inherently anonymized because of the method of token allocation. As such, the backend database with all of its counts can be extremely open with only minimal concern given to whether or not individual staffers can read it.
However, in the case where the individual identification is given by the badge ID, directly traceable to an individual, the system is still usable. It requires two databases; one for universal information about attendees and where they were, specifically their attendance at a given event (which could be extremely useful to convention organizers going forward in terms of gauging interest, etc.), and a second database specifically for accumulating disability counts and the association with an individual who requires accommodation attending an event.
The second database will need to be reviewed for access control and can never be publicly readable – and the associated information which links a given badge ID to specific accommodations will need to be anonymized, aggregated, and exported to another database so that the whole database containing private information can be scrubbed. Processes should be in place to avoid even the appearance of impropriety.
Compliance with HIPAA is not something which is overwhelmingly impossible but it is something which needs to be kept in mind anytime that personally associated information gets accumulated and used for analysis.
Specific processes for anonymizing and aggregating sensitive information are beyond the scope of this article.
Conclusions
Managing access to large, popular event spaces takes a significant effort. Much of it is process and training staffers to understand the protocol. There are tools at our disposal which can seriously improve our ability to provide access and access control to events. Making use of omnipresent wireless networking and computing devices almost every single person carries with them can make it a much less onerous task as long as the requirements for speed, ease-of-use, and simplicity of process are kept in mind.
Specifically in the case of Disability Services, concerns about HIPAA compliance are important and should be dealt with but there's no reason it should stand in the way of reasonable accommodation by the venue and the staffers, with reasonable limitation in place to reflect the needs of event staff and broader spectrum legal compliance with allocated seating.