Difference between revisions of "Ball Park Ticket Taker"

From MgmtWiki
Jump to: navigation, search
(Actors)
(Issues)
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
==Full Title==
 
==Full Title==
This use case considers a user trying to attend a ball game at a park that requires full COVID immuniations as defined by the local health agency.
+
This use case considers a user trying to attend a ball game at a park that requires full COVID immunizations as defined by the local health agency.
  
 
==Context==
 
==Context==
Line 7: Line 7:
  
 
===Goal===
 
===Goal===
To enable the creation of a single aggregated claim set for authorizing access to a ballpark's main entrance asl well as to areas within the park like the level with private boxes.
+
To enable the creation of a single aggregated claim set for authorizing access to a ballpark's main entrance asl well as to areas within the park like the level with private boxes. It has been determined by management that only as access portal with an aggregated, single token check, will be able to handle the volume of people arriving at the access point before the game.
's
 
  
 
===Actors===
 
===Actors===
#Actor: Person seeking access to one game
+
#Actor: Patron seeking access to one (or more) game.
#Actor: Proxy is used here to mean any person that can hold an access token for another.
+
#Actor: Proxy is used here to mean any person that can hold an access token for another, typically a child.
#Actor: Validation web site that can analyze a person's access token remotely to le them know what access would be granted if used at the ballpark.
+
#Actor: Validation web site that can analyze a person's access token remotely to let them know what access would be granted if used at the ballpark.
 
#Actor: Ballpark intake personnel both at the main entrance and at the access point to the private boxes.
 
#Actor: Ballpark intake personnel both at the main entrance and at the access point to the private boxes.
  
Line 21: Line 20:
 
# vaccination status for access to a ballpark.
 
# vaccination status for access to a ballpark.
 
* Person with a cell phone that is loaded with a wallet app that can hold a credential which will allow access to the venue.
 
* Person with a cell phone that is loaded with a wallet app that can hold a credential which will allow access to the venue.
* Note that the exact method used for access can be radios or visual displays. This use case will describe the use of visual display of a QR code for convenience only. Any presentation media that meets the same ease of access would be acceptable.
+
* Note that the exact method used for access can be radios or visual displays. This use case will describe the use of visual display of a QR code for convenience only. Any presentation media that meets the same ease of access would be acceptable. The QR code has the advantage that it can be presented on a smartphone or printed on a sheet of paper for those without smartphones.
* The person, at home, that has acquired a ticket that will grant access to a ball park and to the private boxes.
+
* The person, at home, has acquired a ticket that will grant access to a ball park and to the private boxes.
 +
* While access to alcoholic beverages could talk place at several access points, for the purposes of this use case, it is assumed that every person with access to the private boxes is verified to be 21 so that a single access point get access to both the physical location, as well as the alcoholic beverages, in a manner similar to the "No person under 21 permitted beyond this point" rule.
 +
* A patron at a ballpark can wander around during the game with access points with many criteria so it will not be possible to determine in advance which access points a user might visit during the game. The approach taken here is to list all of the user claims that MIGHT BE required on the access token.
 
===Trigger===
 
===Trigger===
The person arriving at the access point with a cell phone containing the access token.
+
The person arriving at the access point with a cell phone containing the access token to be validated.
  
 
==Scenarios==
 
==Scenarios==
Primary Scenario:
+
===Primary Scenario===
# Person desires to attend a ball game in one of the private boxes. The process to acquire \
+
# A patron desires to attend a ball game in one of the private boxes and acquires a ticket that is combined with all related attributes to successfully attend the ball game. The process of [[Ball Park Ticket Acquisition]] is describes that use case.
 +
# The patron presents themselves to the ticket taker with a QR access token (or other media). The preferred mode is for the QR code to be displayed on a smart phone that has some lock screen capability that assures the holder of the access token is presenting the token.
 +
# If the user is unable to present on their smartphone the back-up case is to print a QR token on paper and present that. Depending the the security requirements of the venue some biometric factor may be required as well, such as a display of the user's face, or a finger print scanner.
 +
# After the presentation the user may need to put the smartphone in a bin prior to passing through a metal detector.
 +
# One cleared for entry the patron may need to present the token again to access the private box floor. If alcoholic beverages are served in the box, some addition scans may be required to acquire them.
 +
# During the game or at half time, the patron may walk to other areas that have age or other restrictions.
 +
# To return to the box level a scan or visual viewing may be required again.
 +
 
 +
===Alternate Scenario===
 +
# Radio media can be enabled from the smartphone. This is typically by use of [[BLE]] or [[NFC]] radios.
 +
# This process can be automated if the gate to the box level is automated. That gate may also have facial recognition.
  
 
==Successful Outcome==
 
==Successful Outcome==
# The patient is correctly matched to their electronic health record.
+
# The patron is able to present a access token at the main entrance and get through the metal detector with low hassle.
# The patient has a successful telemedicine experience, receives a set of reports, is schedules for a lab test and immunization at the local pharmacy.
+
# Access checks at internal points can all be enabled with the same access token used at the main entrance.
# Follow up procedures are created and sent to her smartphone and give her notices when she must take medicine or other procedures.
+
# Where access is denied the patron can be informed of the required attribute that was not available in the token.
  
 
==Unsuccessful Outcome==
 
==Unsuccessful Outcome==
# Not all of the patient's records are available on-line and some action in the real-world is required to get them altogether.
+
# Validity of the access token is tested by the patron before travel to the park. This is a better outcome that getting to the park and then being denied access, so it should be considered a partial success. This also covers the case where the local health agency has changed the rules for access to the ball park after the patron acquired the access token. While the preferred path is for the ticker seller to notify the user, the ability of the user to validate access allows them time to adapt to any post-sale changes.
# The Telemedical connection fails or is not of sufficient quality for the physician to complete the examination.
+
#Failure to access at main gate. The reason should be clear as a ticket counter available to get adjustments as required.
# The patient feels that the quality of care was not sufficient to meet their needs.
 
  
 
==Privacy Concerns==
 
==Privacy Concerns==
* The EHR may release more information that is required for the current visit.
+
* The access token may contain more information that is required for the current visit.
* The patient may be in close quarters with others that should not hear the results of the session.
+
* Presence or lack of specific attributes in the token can be determine at any access point in the park.
 +
* The user attribute data is maintained at the park or at ticket-master for future use and is not well protected.
 +
* User has no simple means to tell the park or ticket-master to delete stored data.
  
 
==Issues==
 
==Issues==
# The patient is one of the 19% of the population w/o a smart phone. Perhaps her grandchild can help with that.
+
# If the patron is one of the 19% of the population w/o a smart phone, perhaps her grandchild can help with that.
# Getting the wallet into the patient's smart phone or lap top may prove to be challenging.
+
# Getting the wallet into the patron's smart phone or laptop may prove to be challenging.
# The patient is not comfortable with technology.
+
# The patron is not comfortable with technology.
# Who determines what data from the MDL is sent to the EHR?  (e.g., the healthcare community specs or explicit user consent)?
+
# Who determines what data from the MDL is sent to ticket-master, or the ball part?  (e.g., the public health details or explicit user consent)?
# Is the driver's license ID number included in any way?
+
# Is the driver's license ID number may be used for long term tracking of the user.?
# Is a picture required for patient record matching to the person on the telemedicine call.
+
# Is a picture required for patron matching to the person at the access points.
 
# Is fraud one of the threats to be addressed within the scope of the recommendation?
 
# Is fraud one of the threats to be addressed within the scope of the recommendation?
  
 
==References==
 
==References==
This use case was updated on 2021-11-11.
+
This use case was updated on 2021-11-22.
  
* [[Mobile Driver's License]] on IDESG wiki.
+
* See [[Mobile Driver's License]] in this wiki.
  
  
[[Category:Profile]]
+
[[Category: Profile]]
[[Category:Use Cases]]
+
[[Category: Use Case]]

Latest revision as of 23:10, 7 December 2021

Full Title

This use case considers a user trying to attend a ball game at a park that requires full COVID immunizations as defined by the local health agency.

Context

  • This use case considers the primary user to be the Ticket Taker. A companion use case will consider the attendee in Ball Park Ticket Acquisition.
  • While it would be interesting to just consider the purchaser going to general admission, this use case will include access to one of the boxes that serves alcoholic beverages and requires proof of age as well. While not all of the conditions are required, the complex case is helpful to determine the widest range of in order to anticipate some of the complexity that may be needed in the future.

Goal

To enable the creation of a single aggregated claim set for authorizing access to a ballpark's main entrance asl well as to areas within the park like the level with private boxes. It has been determined by management that only as access portal with an aggregated, single token check, will be able to handle the volume of people arriving at the access point before the game.

Actors

  1. Actor: Patron seeking access to one (or more) game.
  2. Actor: Proxy is used here to mean any person that can hold an access token for another, typically a child.
  3. Actor: Validation web site that can analyze a person's access token remotely to let them know what access would be granted if used at the ballpark.
  4. Actor: Ballpark intake personnel both at the main entrance and at the access point to the private boxes.

Preconditions

  • A state with strict rules about:
  1. minors access to alcoholic beverages. The only officially recognized digital proof of age is the state-issued driver's license or eID.
  2. vaccination status for access to a ballpark.
  • Person with a cell phone that is loaded with a wallet app that can hold a credential which will allow access to the venue.
  • Note that the exact method used for access can be radios or visual displays. This use case will describe the use of visual display of a QR code for convenience only. Any presentation media that meets the same ease of access would be acceptable. The QR code has the advantage that it can be presented on a smartphone or printed on a sheet of paper for those without smartphones.
  • The person, at home, has acquired a ticket that will grant access to a ball park and to the private boxes.
  • While access to alcoholic beverages could talk place at several access points, for the purposes of this use case, it is assumed that every person with access to the private boxes is verified to be 21 so that a single access point get access to both the physical location, as well as the alcoholic beverages, in a manner similar to the "No person under 21 permitted beyond this point" rule.
  • A patron at a ballpark can wander around during the game with access points with many criteria so it will not be possible to determine in advance which access points a user might visit during the game. The approach taken here is to list all of the user claims that MIGHT BE required on the access token.

Trigger

The person arriving at the access point with a cell phone containing the access token to be validated.

Scenarios

Primary Scenario

  1. A patron desires to attend a ball game in one of the private boxes and acquires a ticket that is combined with all related attributes to successfully attend the ball game. The process of Ball Park Ticket Acquisition is describes that use case.
  2. The patron presents themselves to the ticket taker with a QR access token (or other media). The preferred mode is for the QR code to be displayed on a smart phone that has some lock screen capability that assures the holder of the access token is presenting the token.
  3. If the user is unable to present on their smartphone the back-up case is to print a QR token on paper and present that. Depending the the security requirements of the venue some biometric factor may be required as well, such as a display of the user's face, or a finger print scanner.
  4. After the presentation the user may need to put the smartphone in a bin prior to passing through a metal detector.
  5. One cleared for entry the patron may need to present the token again to access the private box floor. If alcoholic beverages are served in the box, some addition scans may be required to acquire them.
  6. During the game or at half time, the patron may walk to other areas that have age or other restrictions.
  7. To return to the box level a scan or visual viewing may be required again.

Alternate Scenario

  1. Radio media can be enabled from the smartphone. This is typically by use of BLE or NFC radios.
  2. This process can be automated if the gate to the box level is automated. That gate may also have facial recognition.

Successful Outcome

  1. The patron is able to present a access token at the main entrance and get through the metal detector with low hassle.
  2. Access checks at internal points can all be enabled with the same access token used at the main entrance.
  3. Where access is denied the patron can be informed of the required attribute that was not available in the token.

Unsuccessful Outcome

  1. Validity of the access token is tested by the patron before travel to the park. This is a better outcome that getting to the park and then being denied access, so it should be considered a partial success. This also covers the case where the local health agency has changed the rules for access to the ball park after the patron acquired the access token. While the preferred path is for the ticker seller to notify the user, the ability of the user to validate access allows them time to adapt to any post-sale changes.
  2. Failure to access at main gate. The reason should be clear as a ticket counter available to get adjustments as required.

Privacy Concerns

  • The access token may contain more information that is required for the current visit.
  • Presence or lack of specific attributes in the token can be determine at any access point in the park.
  • The user attribute data is maintained at the park or at ticket-master for future use and is not well protected.
  • User has no simple means to tell the park or ticket-master to delete stored data.

Issues

  1. If the patron is one of the 19% of the population w/o a smart phone, perhaps her grandchild can help with that.
  2. Getting the wallet into the patron's smart phone or laptop may prove to be challenging.
  3. The patron is not comfortable with technology.
  4. Who determines what data from the MDL is sent to ticket-master, or the ball part? (e.g., the public health details or explicit user consent)?
  5. Is the driver's license ID number may be used for long term tracking of the user.?
  6. Is a picture required for patron matching to the person at the access points.
  7. Is fraud one of the threats to be addressed within the scope of the recommendation?

References

This use case was updated on 2021-11-22.