US20080251579A1 - Secure identification of dependants - Google Patents
Secure identification of dependants Download PDFInfo
- Publication number
- US20080251579A1 US20080251579A1 US11/734,601 US73460107A US2008251579A1 US 20080251579 A1 US20080251579 A1 US 20080251579A1 US 73460107 A US73460107 A US 73460107A US 2008251579 A1 US2008251579 A1 US 2008251579A1
- Authority
- US
- United States
- Prior art keywords
- identifier
- database
- patient
- data
- dependent
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F9/00—Details other than those peculiar to special kinds or types of apparatus
- G07F9/002—Vending machines being part of a centrally controlled network of vending machines
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
- G16H10/65—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records stored on portable record carriers, e.g. on smartcards, RFID tags or CD
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
Definitions
- a credit card or other personal identification card such as a driver's license
- a computer reads the personal data provided on the magnetic strip, and compares the data to data stored in a database of, for example, flights and associated passengers. If the personal data matches the passenger data, the passenger is automatically checked in, thereby limiting the need to stand in long lines to register for flights.
- Similar systems have been developed for hotel check-in, registration at trade shows, accessing tickets for athletic events and theaters, and elsewhere where check-in or registration for a limited number of seats or times is necessary. More recently, this technology has also been expanded to include registration or check-in services in hospitals and health care facilities.
- the present invention provides a secure system and a method for correlating the records of one or more dependents with a personal identifier of a guardian.
- at least one dependent such as a child or another dependent person, is associated with the personal identifier of a guardian, such as a parent or other care-giver, in a database.
- the personal identifier can be a common form of identification such as a credit card, driver's license, insurance card or other form of identification, or a token generated specifically for use in this application.
- the guardian is not required to be otherwise associated with the health care or database system.
- the guardian is granted certain access to the associated dependent's records. Such access may include permitting the guardian to check the dependent in for an appointment, schedule or reschedule an appointment for the dependent, or to view or modify the dependent's personal information.
- a method for correlating dependent patients with a personal identifier of a guardian in a health care system for checking into an appointment or accessing health care records.
- the method comprises the steps of obtaining a readable personal identifier from a guardian of a dependent patient, registering the readable personal identifier with the dependent patient in a healthcare database, and prompting a user to present the readable personal identifier to a reader at a health care facility.
- the guardian is provided access to process health care or related services for the dependent patient.
- the readable personal identifier comprises a credit card, a driver's license, a health insurance card, or a personal identification card.
- a unique identifier can be provided as a combination of information, such as an account number associated with the credit card and a cardholder name, and a first and a second cardholder can be associated with a first and second unique identifier.
- a first dependent moreover, can be associated with the first unique identifier and a second dependent patient with the second unique identifier. Therefore, by way of example, two individuals who share a credit card account can have access rights for different individuals or sets of individuals.
- a kiosk including a reader capable of reading the personal identifier is provided, and is programmed to compare the personal identifier to the data in the healthcare database and to display at least one dependent associated with the personal identifier at check-in.
- the personal identifier comprises at least one of a biometric identifier, an active memory storage device and a passive memory storage device.
- the personal identifier can comprise any of a number of different types of readable tokens.
- a data access system for use in a health care facility.
- the data access system includes a health care computer network, a health care database including a patient database, and a data structure associating a readable personal identifier of a guardian with at least one dependent patient.
- a reader device is connected to the computer network for reading the readable personal identifier when presented.
- the computer network is programmed to correlate the readable personal identifier with the dependent patient in the database and to provide the guardian access to at least a portion of the health care database to process health care services for the patient.
- the data access system provides the guardian access to check the dependent patient in for an appointment or to schedule an appointment for the patient.
- the readable personal identifier comprises at least one of a credit card, a driver's license, a health insurance card, an active memory storage device, a passive memory storage device, and a biometric identifier.
- the reader is provided in a kiosk connected to the computer network and providing a display for interacting with the guardian and the dependent patient.
- a method is providing for associating dependent patients with first and second holders of a single account.
- a first account holder is prompted to register account data in a healthcare database, the account data including at least one of an account number and an identifier of the first account holder.
- a second account holder is also prompted to register account data in the healthcare database, the account data including at least one of the account number and an identifier of the second account holder.
- a dependent of the first accountholder is then associated with the first accountholder in a database; and a dependent of the second accountholder is associated in a database with the second accountholder, wherein when the first accountholder uses the account as identification, the first accountholder is provided access to process health care services for the first dependent and when the second accountholder provides a credit card associated with the account as identification, the second accountholder is provided access to process health care services for the second dependent.
- the system can produce a first unique identifier as a combination of the account number and identification of the first accountholder.
- a second unique identifier can be produced as a combination of the account number and identification of the second accountholder.
- an individual can be associated with both account holders so that either the first or second account holder is provided access to process health care services for the individual.
- FIG. 1 is a schematic illustration of a health care computer system including a plurality of kiosks for patient check-in and other uses;
- FIG. 2 is a simplified flow chart showing the method of the present invention for registering dependents with guardian identification
- FIG. 3 is a screen shot illustrating a welcome screen when entering e health care facility
- FIG. 4 is a screen shot illustrating an “insert card” screen
- FIG. 5 is a graphic illustration of a database providing correlation of patient data to identification data prior to the addition of identifying data
- FIG. 6 is a graphic illustration of the database of FIG. 5 with patient identification data registered to the database;
- FIG. 6A is a simplified block diagram showing a data access system implementing the secure identification method
- FIG. 7 is a screen shot illustrating an instruction to register an identification card with a receptionist
- FIG. 8 is a screen shot of a screen used by a receptionist to enter patient data for lookup
- FIG. 9 is a screen shot illustrating the process of adding an identifier for the patient.
- FIG. 10 is a screen shot illustrating a set-up of card usage
- FIG. 11 is an illustration of a guardian/dependent correlation database
- FIG. 12 is a screen shot of a welcome screen for a patient registering at a kiosk
- FIG. 13 is a screen shot of a selection screen for selecting a kiosk activitiy
- FIG. 14 is a screen shot for entering an identification card
- FIG. 15 is a screen shot for associating a patient with the identification card
- FIG. 16 is a screen shot illustrating identification of card usage through the kiosk
- FIG. 17 is a screen shot illustrating the addition of additional patients to the card
- FIG. 18 is a screen shot illustrating review of the data associated with the card
- FIG. 19 is a screen shot illustrating review of the data associated with the card after an additional patient is added.
- FIG. 20 is a screen shot illustrating the patients associated with a first identifier
- FIG. 21 is a screen shot illustrating the patients associated with a second identifier
- FIG. 22 is a flow chart illustrating a patient look-up process that provides patient check in and access to health records in accordance with an alternate embodiment of the invention
- FIG. 23 is a schematic illustrating a patient database for use with a patient look-up
- FIG. 24 is a screen shot illustrating acquisition of patient identification data for the patient look-up of FIG. 22 ;
- FIG. 25 is another screen shot illustrating acquisition of patient identification data for the patient look-up of FIG. 22 ;
- FIG. 26 is another screen shot illustrating acquisition of patient identification data for the patient look-up of FIG. 22 ;
- FIG. 27 is yet another screen shot illustrating acquisition of patient identification data for the patient look-up of FIG. 22 ;
- FIG. 28 is still screen shot illustrating acquisition of patient identification data for the patient look-up of FIG. 22 .
- an exemplary patient check-in system 10 a including a server 22 a , memory storage 72 a , a network 24 a (e.g., a local area network, a wide area network, the Internet, etc. which may include wireless transceiver or transceivers 745 ), a receptionists station 950 , and a plurality of patient kiosks 26 a , 26 b , 26 c , 26 d , 26 e and 26 f .
- a network 24 a e.g., a local area network, a wide area network, the Internet, etc. which may include wireless transceiver or transceivers 745
- a receptionists station 950 e.g., a receptionists station 950 .
- Server 22 a runs software programs that perform various methods/processes that are contemplated by the present invention and to provide browser type screen shots to the kiosks 26 a , 26 b , etc., and to receive input from the kiosks.
- Each of kiosks 26 a , 26 b , etc. may take any of several different forms including work stations, personal computers, laptops, thin-client type devices, etc. Where the kiosks are more than thin clients, in at least some embodiments each kiosk may perform all or at least a subset of the steps required to perform the inventive processes.
- each kiosk operates primarily as a human-server interface device for input/output between a patient and server 22 a where server 22 a performs most or all of the inventive process steps.
- each kiosk 26 a , 26 b , etc. is a thin client type device.
- Kiosk 26 a includes a flat panel display 21 , an input device 27 , a card reader 19 and a printer 17 .
- Input device 27 is shown as a keyboard but may include other input devices such as a mouse device, a track ball type device, etc., and, is generally provided for, as the label implies, entering information into system 10 a for use by server 22 a .
- the input device(s) 27 includes a keyboard for entering text type information and a mouse type device (not illustrated) for moving a mouse controlled cursor (see 351 in FIG. 13 ) around on the screen of display 21 .
- the display 21 may be a touch screen display. In this application, therefore, the touch screen provides the function of the input device 27 .
- Card reader 19 includes a slot for receiving identification cards from patients for identification purposes.
- the identification card may be a credit card, a driver's license, a dedicated insurance card, a healthcare card, etc., from which information can be read to uniquely identify a cardholder.
- the cardholder can be either a patient, a guardian of a patient, or both, and is not required to have any other relationship with the database system except with regards to the personal identifier.
- the cardholder can access the kiosk system to check in an associated dependent for an appointment, as described below.
- the associated patient identifier the cardholder can access records associated with the dependent.
- patient identities will be associated with patient unique cards in one or more database in memory storage 72 a , as described more thoroughly below.
- Memory storage 72 a is linked to server 22 a and stores programs 13 performed by server 22 a and various data arranged in data structures and databases (also referred to as “databases” hereinafter) that may be used by the server software to perform inventive methods.
- memory 72 a includes an electronic medical records database 15 that, as the label implies, stores electronic medical records (EMRs) for facility patients While EMRs often are extremely detailed, for the purposes of this disclosure portions of the EMR are particularly important.
- EMR database 15 includes a patient identification database 31 , an appointments or scheduling database 69 , and a guardian/dependent database 71 .
- each database 31 , 69 and 71 are referred to as separate databases in the interest of simplifying this explanation, is should be appreciated that, in at least some cases, each database 31 , 69 , and 71 may in fact include data interspersed among separate patient EMRs, and may include data that is stored outside of an EMR database 15 .
- the databases described herein are merely provided as an example, and the data is shown arranged in a manner intended to simplify explanation of the invention. It will be apparent to those of ordinary skill in the art that the data can be arranged in any of a number of different ways, in one or multiple databases, and that the description here is not intended to limit the invention.
- the present invention provides methods for identifying patients using common forms of identification, and, in a specific example, readable personal identifiers such as credit cards, and for identifying dependents through a guardian's personal identification.
- the system will be described with reference to an exemplary family, headed by Bruce Johnson and his wife Helen Smith.
- Bruce and Helen are the parents of Bradley Johnson.
- Bruce has a daughter, Elizabeth Johnson, from a previous marriage, and Helen has a daughter, Sally Smith, from a previous marriage.
- Bruce, Bradley and Elizabeth Johnson are all patients at St. Daniel's clinic, as is Sally Smith.
- Helen Smith is not a patient, and is not identified in the associated databases in memory 72 a .
- Registration of the extended Johnson family using registered personal identifiers and particularly through a patient check-in system 10 a is described below. Registration is shown through a series of exemplary screen shots. It will be apparent, however, that the form of data entry can be varied and that these screen shots are provided by way of illustration only. Moreover, as the present invention is shown for a kiosk system, it will be apparent that the invention can also be used with other systems that use personal identifiers and identification cards to identify users.
- FIG. 2 a flowchart showing a process 100 for correlating one or more patients with a personal identifier is shown.
- the process will initially be described for providing a personal identification card for Sally Smith, the daughter of Helen Smith, who, as noted above, is not a patient at the clinic. Subsequently, a similar process will be shown for Bruce Johnson, who is a patient of the clinic, registering his daughter Elizabeth, from a kiosk 26 a . Both Helen and Bruce will also register their son, Bradley. In this example, it is assumed that Bruce and Helen share a credit card account and use this credit card account MC xxxxxx1880 to register the dependent patients.
- a screenshot 120 welcoming a user to the kiosk 26 a is shown.
- a message 122 is provided asking the user to identify his or her self.
- Selectable icons are also provided for entering a personal identifier, which can be a credit card 124 , personal health card 126 , personal information 128 , or a driver's license 129 , as shown here, or various other forms of identification and other types discussed hereafter.
- An arrow 127 can also be provided to select between the icons.
- screenshot 130 is displayed, including a message 132 instructing the user to insert the card in a card reader 19 , shown schematically as card reader 134 .
- Icons providing options to return to the last screen 136 and to exit the process 138 are also provided.
- FIG. 5 in process block 104 of FIG. 2 , an identity of the cardholder and the card number are retrieved from the magnetic strip on the card, and the card data is evaluated as compared to data in database 31 . Because neither the card nor Helen Smith is found in the database, either as a patient, guardian, or as a cardholder, screen shot 140 is displayed ( FIG. 7 ), instructing Helen Smith to proceed to the registration desk 950 to register the card in accordance with the steps provided below.
- the receptionist or other personnel requests identification data for the patient or dependent that is to be registered with the card, and enters this data into a patient data screen 150 in this screen, the name of the patient, Sally Smith, is entered in block 152 , along with a social security number in block 154 , and a birth date in block 156 .
- the receptionist also requests verification of the relationship between the cardholder Helen Smith, and the patient Sally Smith, and, after verification, enters this relationship into data block 158 .
- the process 100 compares the entered data to data in the EMR database 15 , and verifies the identity of the patient. When an appropriate relationship is established and verified by the receptionist, the process proceeds to process block 108 , and the receptionist acquires credit card data from Helen Smith.
- the relationship data may also optionally be stored in a guardian/dependent database 71 , as described below.
- the receptionist next acquires credit card data including the type of card 162 , brand of card 164 , card number 166 , cardholder name 168 , and expiration date 169 .
- the data is entered by the receptionist into screenshot 160 .
- the identification is a credit card as described here
- the card can be used both for identification and for payment purposes, and the receptionist therefore requests information regarding how the card is to be used, as shown in screen shot 170 of FIG. 10 , which provides the options of identification 172 , payment 174 , and co-payment 176 .
- the data is entered into the screen shot 170 .
- card usage can include additional options, and that these options can be specified by the facility. For example, it is also possible to specify whether the card is to be used solely for check-in, for scheduling of appointments, or for other types of health care access. These options can be individually configures by users or facilities. It will also be apparent that the type of data entered will vary depending on the type of identification card used. Thus, for example, the data entered for a driver's license will be specific to this form of identification.
- a patient information database 51 is shown both prior to registration of identification cards, and after registration of identification cards, respectively.
- no identification data is associated with patient Sally Smith in column 80 .
- the acquired data is stored to the database 31 for later retrieval.
- the stored data can include patient name Sally Smith in column 80 , card identification number MC xxxxxx1880 in column 82 , and the card holder name, Helen Smith, in column 84 .
- a relationship between the cardholder and identified patient is stored in column 86 and card usage data is stored in columns 88 and 90 .
- a patient identifier that can include a combination of card data and other identifying data associated with the card, such as a name of the cardholder, can be calculated or established, as described more fully below.
- This identifier can also be used to allow multiple users of a single credit card account to associate different patients with the account, also as described more fully below.
- the relationship between Helen and Sally Smith can also be stored in the guardian/dependent database 71 , as shown here in FIG. 11 .
- a guardian or caregiver is associated with a patient in the database, moreover, a level of access can also be established. For example, a parent may be allowed access to schedules and personal identification cards, and medical records of the specified dependent, while a caregiver such as a nanny or babysitter may be allowed access only to check in and out of scheduled appointments.
- a parent may be allowed access to schedules and personal identification cards, and medical records of the specified dependent
- a caregiver such as a nanny or babysitter may be allowed access only to check in and out of scheduled appointments.
- Helen Smith also registers her second dependent, Bradley Johnson, using the same credit card, as shown in database 31 of FIG. 6 .
- a cardholder guardian can establish a secure means for identification of a dependent through the kiosk 26 a as well, as will now be described as Bruce Johnson registers his dependents through the kiosk 26 a .
- a screenshot 120 welcoming a user to the kiosk 26 a is shown.
- a message 122 is again provided asking the user to identify his or her self and providing selectable icons for a credit card 124 , personal health card 126 , or personal information 128 , or a driver's license 129 .
- any of these various types of identification can be provided, in the description below, it will again be assumed that the identification provided is a credit card, and that the account number is MC xxxxxx1880.
- screenshot 130 is displayed next, providing a message 132 instructing the user to insert the card in a card reader 19 , shown schematically as card reader 134 .
- the card reader 19 reads the data from the credit card, compares the data to the database 31 of FIG. 5 , and recognizes both the name Bruce Johnson and the card as having been previously registered in database 31 .
- a confirmation screen 180 can be provided asking the user in message 182 to confirm his or her identity by accessing the confirm icon 184 .
- a picture 185 of the user can also be provided.
- the patient look-up process described below with reference to FIGS. 22 - 29 can also be used.
- screenshot 190 of FIG. 13 After the user Bruce Johnson has accessed the system, in screenshot 190 of FIG. 13 , he is asked to select between a number of different possible options from the kiosk 26 a .
- the user can check in for appointments in icon 132 , check in for lab work in icon 134 , update account information in icon 136 , find a facility location in icon 138 , and check out after an appointment icon 140 .
- the user selects an update account information icon 136 and proceeds to screenshot 140 , which asks Mr. Johnson to select between various types of data to edit.
- the data can include personal data 142 , insurance data 144 , and/or an option to setup personal identifiers in icon 146 .
- the user can select to setup accounts for the personal identifier already submitted or provide an additional card or identifier (screen shot not shown). If an additional identifier is provided, in screenshot 130 ( FIG. 4 ), the user is prompted to insert an additional identification card for registration in the card reader 19 .
- server 22 a accesses database 71 ( FIG. 11 ), and retrieves a list of the patients associated with Bruce Johnson.
- the database 71 includes a first column 60 of patient names, addresses and other identifiers; a second column 62 providing a first list of guardians; a third column 64 providing a second list of guardians and identifying data such as a social security number.
- the database 71 identifies Bruce Johnson as a patient, and also identifies Bruce Johnson as the guardian of Elizabeth Johnson and Bradley Johnson. Helen Smith, due to the previous registration described above, can also be listed as a guardian.
- the system can, in order to provide additional security, also query the user to input a social security number, a portion of a social security number, a zip code or other identifying data to add a further level of security.
- a separate guardian/dependent database 71 is shown here, it will be apparent that the dependency data can also be provided in the database 31 , as described above, or in any combination of logical or physical databases.
- the guardian/dependency relationships provided in the database 71 can be established either through entry of the data through a receptionist and receptionist computer 950 , as described above, through pre-existing data in the database, by providing proof of guardianship to the clinic generally, through existing insurance or health care records, or in other ways which will be apparent to those of skill in the art.
- screen shot 210 ( FIG. 15 ) is displayed on the kiosk 26 a , providing the names of the three patients that can be associated by Bruce Johnson—Bruce Johnson, Elizabeth Johnson, and Bradley Johnson—and the user Bruce Johnson is prompted to select a patient to associate with the card. Here it is assumed that Bruce Johnson selects Bradley Johnson.
- screenshot 220 FIG. 16
- the system requests the user to specify the activities that should be associated with the selected patient and card.
- the identification is a credit card, as described here
- the user can specify use for identification (icon 224 ) and for payment purposes, either for a co-pay only (icon 226 ) or payment for all purposes (icon 228 ).
- This data is then stored along with the card data and patient data in database 31 .
- Various other data can also be manipulated and stored in the database 31 , as will be apparent to those of skill in the art.
- FIG. 17 after the identification data is added to the card (screenshot 230 ), the cardholder is asked whether additional patients should be added to the card. Three icons appear. A yes icon 232 , a no icon 234 , and a view card data icon 236 . Selecting the yes icon 232 returns the cardholder to screen 210 of FIG. 15 , where Mr. Johnson can now register Bradley Johnson with his card, using the same steps specified above.
- Selecting the no icon 234 takes the patient to screen 190 of FIG. 13 and selecting the view card data icon 236 takes the patient to screenshot 240 of FIG. 18 , screenshot 240 where data from the database 31 is shown.
- screenshot 240 a list of the patients associated with the registered card is shown. Bruce Johnson is listed as a patient, along with data specifying that the card is to be used both as identification and for payment. Bradley Johnson is also listed, as a dependent of Bruce Johnson. The card is used for identification only for Bradley.
- FIG. 19 after the steps discussed above are also taken to add Elizabeth Johnson to the identification card, all three patients are registered to the card as shown in screenshot 242 of FIG. 19 . Two additional icons, an “edit patients” icon 246 and an exit icon 248 are provided.
- the kiosk screen returns to screenshot 190 of FIG. 13 , which allows the patient to check in for appointments 194 , check in for lab work 190 , update account information 198 , find a facility location 200 , or checkout after an appointment 202 .
- the guardian can also be provided with options to schedule appointments, access medical records, or perform other health care procedures for the dependents.
- an exit icon is shown here, various other screen and data flows are also possible.
- screenshot 270 of FIG. 20 is displayed, illustrating Bruce Johnson, Elizabeth Johnson, and Bradley Johnson, and therefore all of the patients associated with the selected card and patient identification.
- Helen Smith enters the facility and inserts her card with the same account number, her dependents Sally Smith and Bradley Johnson are shown ( FIG. 21 ). Therefore, despite the fact that Bruce Johnson and Helen Smith are using the same credit account, they are provided with access to different sets of patients based on data retrieved from the database 31 .
- the database 31 correlates patients and personal identifiers here shown as identification cards.
- the database 31 includes a patient column 80 , a card identification column 82 , a cardholder column 84 , a relationship column 86 , an identification column 88 , a payment column 90 and an identifier column 92 .
- the patient column 82 includes the names of patients of the clinic, here providing the names of Bruce, Bradley and Elizabeth Johnson, as well as Sally Johnson. Helen Smith, as described above is not a patient. The remaining columns associate identification and payment information with the patients. In FIG. 5 , no identification has been provided for any of the patients but Bruce Johnson, and these columns therefore are blank for the other listed patients.
- FIG. 6 illustrates the database after Bruce Johnson and Helen Smith have registered their dependents in the database as described above, with both guardians using the same credit card account, which is shard by Helen Smith and Bruce Johnson.
- Bruce and Helen share the same credit card account, they do not share the same set of dependents, therefore another identifier is required to provide appropriate access to the parents.
- a unique identifier which can, for example, combine account data from column 82 and cardholder data from column 84 or any other identification data can be calculated and stored for each specific card as shown in column 92 .
- a first identifier is provided for the card when used by Bruce Johnson, and a second identifier for the account when used by Helen Smith.
- the same card can provide access to different sets of patients.
- the patients can be associated with different cards.
- Bruce Johnson uses credit card MCXXXXX1880 to identify himself, and VSXXXXX1996 to identify dependents Bradley and Elizabeth Johnson.
- Helen Smith uses a separate account, MCXXXXX1334 to identify her dependents, Bradley Johnson and Sally Smith. Each parent, therefore, can associate their dependent children with different identification cards.
- a specific identifier is described in column 92 , it will be apparent that the process can also determine the identity of the user by comparing a second form of identification, such as a name on the card, to data in the database, or require the insertion of a second form of identification from the parent, to differentiate between account holders rather than calculating a specific personal identifier shown in column 92 . It will also be apparent that a patient can be associated with a number of different personal identifiers and cards, and that an unlimited number of patient identification associations can be established, stored, and maintained. Furthermore, it is also possible to identify cardholders based on the submitted identification card alone, or on the card in combination with personal data provided by the user.
- the personal information is read from the magnetic strip of a credit card and stored in the database system as a database key.
- the personal information from the magnetic strip can be used to create a unique token, or can be compared to the stored data when entered.
- a credit card account number has been described above for simplicity, the token may also be a hash or other encrypted version of the account number of the credit card.
- the database key requires more than the encrypted or hashed account number and might include any other identifying information available, such as the guardian's personal name, card id, the CV2 data, etc. thereby forming the identifier 92 .
- the personal identifier can be any type of readable personal identifier or token capable of storing unique identifying information and/or of being read by a machine.
- the personal identifier may, therefore, be a driver's license, insurance card, or health care identification card or a combination of such forms of identification, or any other form of identification that includes personal information such as account number, full name, address, date of birth, and telephone number stored in a machine readable format.
- the identifier may include active or passive memory storage, be an RFID tag, a barcode or other type of optical encoding device, or a biometric identifier.
- a dependent is a person that either does not have a useable personal identifier, or is not capable of using the personal identifier, such as a child or a dependent adult.
- the guardian can be any individual with a useable personal identifier, such as a parent or care-giver. The guardian, moreover, is not required to be otherwise associated in anyway with the health care facility or the database system.
- the database record for the guardian's personal identifier can be associated with one or more database records of the dependents, with or without identifying the guardian.
- the dependent's database record in the database system can take many forms, and may contain personal information of the dependent including without limitation name, address, date of birth, social security number, and sex.
- the method further contemplates one or more guardians each with their own personal identifier being associated with one or more identical dependents. In this situation, one or more guardians may responsibility for the dependent, such as the case of parents. Further, the method contemplates a guardian with more than one personal identifier identifying the same or different dependents.
- the kiosk 26 a can be used to find a patient, guardian, or dependent in the database using a patient “look-up” system that identifies a particular patient based on personal identification data input by the kiosk operator.
- a patient “look-up” system that identifies a particular patient based on personal identification data input by the kiosk operator.
- the system will be described below with reference to identifying a patient, it will be apparent the system can also be used to identify a guardian, or an accountholder in the database, and that it is not necessary that the identified individual be a patient. It will also be apparent that the described system can be used in lieu of other forms of identification, or in combination with a patient identifier such as a credit card, driver's license, insurance card, or other token.
- a probability calculation is used to limit the amount of data that must be input by a user. The probability is calculated based on an analysis of the data in the database, and therefore increases both the security and efficiency of an automated patient identification process.
- a target subset of patients or patient data is initially identified.
- the target subset can be determined based on patient identifying data, such as a name or a portion of the name of the patient, or a social security number or a portion of a social security number provided by the patient.
- the subset could be determined based on a known list of patients that have appointments on the specific day that the kiosk is being used.
- the purpose of this step is to narrow the set of patient data that must be evaluated to determine the identity of the patient using the kiosk 26 a .
- FIG. 24 an exemplary screen shot is shown.
- the kiosk 26 a prompts the patient to enter the first three letters of his or her first and last name in data entry blocks 282 and 284 . As shown here by way of example, the patient enters the first three letters “Bru” in data block 282 and the first three letters “Joh” in block 284 .
- a patient look-up data base 290 including patient identifying data, here shown as a patient name 292 , birth date 293 , social security number 294 , phone number 295 , and zip code 296 .
- patient identifying data here shown as a patient name 292 , birth date 293 , social security number 294 , phone number 295 , and zip code 296 .
- patient names are retrieved based on the data entered into the screen shot 280 : Bruce Johnson, who lives at 555 Maple Drive and has a birth date of Jul. 31, 1960; Bruce Johnson who also lives at 555 Maple Drive and has a birth date of May 1, 1937; Bruno Johnsrud, who lives at 1222 North St. and was born on Jun. 3, 1979 and Bruce Johnstone, of 777 Oak Court, born on Jun. 4, 1979.
- process 400 continues to process block 404 to begin the process of determining the best next question to ask.
- the process 400 evaluates the data in the database 290 to identify the number of unique acceptable values or answers for each identification parameter in the database subset identified in process block 402 .
- FIG. 23 here, for example, there are four sets of identification parameters shown: birth date, social security number, phone number, and zip code.
- the birth date moreover, can be parsed into individual comparable segments consisting of a month, a date, and a year. Each of these columns, and each segment of the parsed birth date data, represents a potential question for the user, the answer to which helps to further narrow the potential list of patients, and to eventually identify the patient.
- process block 404 the system evaluates the data in each individual column to determine the number of unique acceptable answers.
- This data is used by the process 400 to determine which data will most quickly narrow the field of patients to a single, unique patient. If the birth date column is further broken down by month, date, and year, the number of possibilities decreases.
- the process 400 calculates the distribution of unique patients associated with each acceptable answer. Using the limited example above of FIG. 23 , there are two patients associated with the zip code 54321 , and one patient each associated with the other two zip codes. In step 408 , the process 400 determines the number of questions having unique acceptable answers above a threshold value, where the threshold can be a fixed number, a percentage, or a ranking relative to other questions.
- the process 400 selects the question with the largest number of “good answers”, where a good answer is an answer that has fewer than a defined threshold number of patients associated with it.
- a question may have ten acceptable answers, as determined in step 404 .
- step 412 the question with the largest number of good answers is selected, and in process block 414 , that question is displayed to the user. Subsequently, the process 400 determines whether a patient is uniquely identified in block 416 . If the patient is not uniquely identified by the response to the question, the process 400 returns to step 404 . The process continues until a specific patient is identified, or until it becomes clear that the patient cannot be identified. At this point, the patient can be directed to a receptionist.
- FIG. 24 a series of example screen shots 280 , 300 , 304 , 308 , and 312 are shown in which the patient at the kiosk is asked to provide personal data to verify identity.
- the questions actually presented to a patient will be filtered as described above.
- a data block 302 is provided for entry of the data, and the patient enters 1979 , which, referring also to FIG. 23 , narrows the identity of the patient to either Bruno Johnsrud or Bruce Johnstone.
- the kiosk 26 a requests day of his or her birth, and the patient here enters the number three into data block 306 . Based on this data, the system can determine that the patient is Bruno Johnsrud. In some applications, therefore, it would be possible to stop acquiring data at this point.
- the kiosk can move on to the screen 308 of FIG. 27 , which prompts the user to identify the last four digits of his or her social security number, and in screen shot 312 of FIG. 28 , the last four digits of his or her telephone number.
- the zip code of column 290 address, or other data could also be acquired to determine the identify of the patient.
- the patient look-up system described above can also be used to identify a guardian, who can then be given access to the associated records of dependents, as shown, for example, in the database of FIG. 11 .
- personal identification of the dependent can also be requested, as described above.
- a touch screen could be used and the data for entry provided on screen.
- an alphabet can be provided on the screen, and the user prompted to select the appropriate letters from the display screen.
- a series of digits between 0 and 9 can be shown.
- a list of, for example, the birth years of column 293 in FIG. 23 could all be displayed, preferably with a series of random years that are not associated with any of the identified patients, again to limit the probability of identity theft or fraud, and to retain compliance with federal regulations.
- communications between a patient and the patient check-in system 10 a can be provided using wireless personal communication devices 743 ( FIG. 1 ).
- a user can, for example, submit credit card identification data wirelessly from the device 743 rather than inserting a card into a card reader as described above. Identifying data for a driver's license, insurance account, or other data could also be transmitted rather than entered through a kiosk.
- screen shots are described above both for a receptionist computer 950 and a kiosk 26 a , it will be apparent that the screen shots are exemplary only, and that the icons, data entry screens, and informational screens shown are not intended to limit the invention.
- the data accessible through these systems is limited only by what is available in the associated databases, and access rights associated with the user accessing the database.
Abstract
The present invention provides a method for identifying patients using common forms of identification, and specifically readable personal identifiers such as credit cards, and for identifying dependents through a guardian's personal identification. The guardian registers the account with a health care database, and associates the dependent patients with the account. Thereafter, the guardian can process healthcare services for the guardian by providing a readable identifier identifying the account. As a result, the guardian can register the dependent patient for an appointment through a kiosk or other publicly accessible terminal, and can also access scheduling or other services.
Description
- In recent years, kiosks and other types of automated registration and check-in devices have become commonplace for registering for flights at airports. In these automated check-in devices, a credit card or other personal identification card, such as a driver's license, is typically inserted into a card reading device. A computer reads the personal data provided on the magnetic strip, and compares the data to data stored in a database of, for example, flights and associated passengers. If the personal data matches the passenger data, the passenger is automatically checked in, thereby limiting the need to stand in long lines to register for flights. Similar systems have been developed for hotel check-in, registration at trade shows, accessing tickets for athletic events and theaters, and elsewhere where check-in or registration for a limited number of seats or times is necessary. More recently, this technology has also been expanded to include registration or check-in services in hospitals and health care facilities.
- While many such systems exist, however, these systems have somewhat limited functionality because registration can be limited to those who have the appropriate form of identification, typically a credit card. Therefore, families with children, for example, typically cannot register using automatic check-in services, because the children do not have credit card forms of identification. Furthermore, these systems typically do not require any verification of the identity of the user. These problems are particularly acute in the health care industry, where it is important to accurately identify the patient, and to quickly and easily process the registration of a sick child. The present invention addresses this problem.
- The present invention provides a secure system and a method for correlating the records of one or more dependents with a personal identifier of a guardian. In this method, at least one dependent, such as a child or another dependent person, is associated with the personal identifier of a guardian, such as a parent or other care-giver, in a database. The personal identifier can be a common form of identification such as a credit card, driver's license, insurance card or other form of identification, or a token generated specifically for use in this application. Except for purposes of supplying the personal identifier, the guardian is not required to be otherwise associated with the health care or database system. Based on the personal identifier, the guardian is granted certain access to the associated dependent's records. Such access may include permitting the guardian to check the dependent in for an appointment, schedule or reschedule an appointment for the dependent, or to view or modify the dependent's personal information.
- In one aspect of the invention, a method is provided for correlating dependent patients with a personal identifier of a guardian in a health care system for checking into an appointment or accessing health care records. The method comprises the steps of obtaining a readable personal identifier from a guardian of a dependent patient, registering the readable personal identifier with the dependent patient in a healthcare database, and prompting a user to present the readable personal identifier to a reader at a health care facility. When the user presents the readable identifier at the healthcare facility, the guardian is provided access to process health care or related services for the dependent patient.
- In another aspect of the invention, the readable personal identifier comprises a credit card, a driver's license, a health insurance card, or a personal identification card. In another aspect of the invention, a unique identifier can be provided as a combination of information, such as an account number associated with the credit card and a cardholder name, and a first and a second cardholder can be associated with a first and second unique identifier. A first dependent, moreover, can be associated with the first unique identifier and a second dependent patient with the second unique identifier. Therefore, by way of example, two individuals who share a credit card account can have access rights for different individuals or sets of individuals.
- In another aspect of the invention, a kiosk including a reader capable of reading the personal identifier is provided, and is programmed to compare the personal identifier to the data in the healthcare database and to display at least one dependent associated with the personal identifier at check-in.
- In another aspect of the invention, the personal identifier comprises at least one of a biometric identifier, an active memory storage device and a passive memory storage device. Alternatively, the personal identifier can comprise any of a number of different types of readable tokens.
- In still another aspect of the invention, a data access system is provided for use in a health care facility. The data access system includes a health care computer network, a health care database including a patient database, and a data structure associating a readable personal identifier of a guardian with at least one dependent patient. A reader device is connected to the computer network for reading the readable personal identifier when presented. When the identifier is read, the computer network is programmed to correlate the readable personal identifier with the dependent patient in the database and to provide the guardian access to at least a portion of the health care database to process health care services for the patient.
- In another aspect of the invention, the data access system provides the guardian access to check the dependent patient in for an appointment or to schedule an appointment for the patient.
- In yet another aspect of the invention, the readable personal identifier comprises at least one of a credit card, a driver's license, a health insurance card, an active memory storage device, a passive memory storage device, and a biometric identifier.
- In still another aspect of the invention, the reader is provided in a kiosk connected to the computer network and providing a display for interacting with the guardian and the dependent patient.
- In a further aspect of the invention, a method is providing for associating dependent patients with first and second holders of a single account. In this method, a first account holder is prompted to register account data in a healthcare database, the account data including at least one of an account number and an identifier of the first account holder. A second account holder is also prompted to register account data in the healthcare database, the account data including at least one of the account number and an identifier of the second account holder. A dependent of the first accountholder is then associated with the first accountholder in a database; and a dependent of the second accountholder is associated in a database with the second accountholder, wherein when the first accountholder uses the account as identification, the first accountholder is provided access to process health care services for the first dependent and when the second accountholder provides a credit card associated with the account as identification, the second accountholder is provided access to process health care services for the second dependent. In another aspect of the invention, the system can produce a first unique identifier as a combination of the account number and identification of the first accountholder. A second unique identifier can be produced as a combination of the account number and identification of the second accountholder. Additionally, an individual can be associated with both account holders so that either the first or second account holder is provided access to process health care services for the individual.
- These and other aspects of the invention will become apparent from the following description. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made therefore, to the claims herein for interpreting the scope of the invention.
-
FIG. 1 is a schematic illustration of a health care computer system including a plurality of kiosks for patient check-in and other uses; -
FIG. 2 is a simplified flow chart showing the method of the present invention for registering dependents with guardian identification; -
FIG. 3 is a screen shot illustrating a welcome screen when entering e health care facility; -
FIG. 4 is a screen shot illustrating an “insert card” screen; -
FIG. 5 is a graphic illustration of a database providing correlation of patient data to identification data prior to the addition of identifying data; -
FIG. 6 is a graphic illustration of the database ofFIG. 5 with patient identification data registered to the database; -
FIG. 6A is a simplified block diagram showing a data access system implementing the secure identification method; -
FIG. 7 is a screen shot illustrating an instruction to register an identification card with a receptionist; -
FIG. 8 is a screen shot of a screen used by a receptionist to enter patient data for lookup; -
FIG. 9 is a screen shot illustrating the process of adding an identifier for the patient; -
FIG. 10 is a screen shot illustrating a set-up of card usage; -
FIG. 11 is an illustration of a guardian/dependent correlation database; -
FIG. 12 is a screen shot of a welcome screen for a patient registering at a kiosk; -
FIG. 13 is a screen shot of a selection screen for selecting a kiosk activitiy; -
FIG. 14 is a screen shot for entering an identification card; -
FIG. 15 is a screen shot for associating a patient with the identification card; -
FIG. 16 is a screen shot illustrating identification of card usage through the kiosk; -
FIG. 17 is a screen shot illustrating the addition of additional patients to the card; -
FIG. 18 is a screen shot illustrating review of the data associated with the card; -
FIG. 19 is a screen shot illustrating review of the data associated with the card after an additional patient is added; -
FIG. 20 is a screen shot illustrating the patients associated with a first identifier; -
FIG. 21 is a screen shot illustrating the patients associated with a second identifier; -
FIG. 22 is a flow chart illustrating a patient look-up process that provides patient check in and access to health records in accordance with an alternate embodiment of the invention; -
FIG. 23 is a schematic illustrating a patient database for use with a patient look-up; -
FIG. 24 is a screen shot illustrating acquisition of patient identification data for the patient look-up ofFIG. 22 ; -
FIG. 25 is another screen shot illustrating acquisition of patient identification data for the patient look-up ofFIG. 22 ; -
FIG. 26 is another screen shot illustrating acquisition of patient identification data for the patient look-up ofFIG. 22 ; -
FIG. 27 is yet another screen shot illustrating acquisition of patient identification data for the patient look-up ofFIG. 22 ; and -
FIG. 28 is still screen shot illustrating acquisition of patient identification data for the patient look-up ofFIG. 22 . - Referring now to the figures, and more particularly to
FIG. 1 , an exemplary patient check-insystem 10 a is shown including aserver 22 a,memory storage 72 a, anetwork 24 a (e.g., a local area network, a wide area network, the Internet, etc. which may include wireless transceiver or transceivers 745), areceptionists station 950, and a plurality ofpatient kiosks Server 22 a runs software programs that perform various methods/processes that are contemplated by the present invention and to provide browser type screen shots to thekiosks kiosks server 22 a whereserver 22 a performs most or all of the inventive process steps. Hereinafter, unless indicated otherwise and in the interest of simplifying this explanation, it will be assumed that eachkiosk - Each of the
kiosks 26, 26 b, etc., is similarly constructed and operates in a similar fashion and therefore, in the interest of simplifying this explanation, onlykiosk 26 a will be described here in any detail.Kiosk 26 a includes aflat panel display 21, aninput device 27, acard reader 19 and a printer 17.Input device 27 is shown as a keyboard but may include other input devices such as a mouse device, a track ball type device, etc., and, is generally provided for, as the label implies, entering information intosystem 10 a for use byserver 22 a. In the present case it will be assumed that the input device(s) 27 includes a keyboard for entering text type information and a mouse type device (not illustrated) for moving a mouse controlled cursor (see 351 inFIG. 13 ) around on the screen ofdisplay 21. Furthermore, thedisplay 21 may be a touch screen display. In this application, therefore, the touch screen provides the function of theinput device 27. -
Card reader 19 includes a slot for receiving identification cards from patients for identification purposes. In this regard, the identification card may be a credit card, a driver's license, a dedicated insurance card, a healthcare card, etc., from which information can be read to uniquely identify a cardholder. The cardholder can be either a patient, a guardian of a patient, or both, and is not required to have any other relationship with the database system except with regards to the personal identifier. When the cardholder is a guardian, the cardholder can access the kiosk system to check in an associated dependent for an appointment, as described below. In addition, through use of the associated patient identifier, the cardholder can access records associated with the dependent. To this end, prior to using one of the kiosks to check-in for an appointment it is contemplated that patient identities will be associated with patient unique cards in one or more database inmemory storage 72 a, as described more thoroughly below. -
Memory storage 72 a is linked toserver 22 a and storesprograms 13 performed byserver 22 a and various data arranged in data structures and databases (also referred to as “databases” hereinafter) that may be used by the server software to perform inventive methods. To this end,memory 72 a includes an electronicmedical records database 15 that, as the label implies, stores electronic medical records (EMRs) for facility patients While EMRs often are extremely detailed, for the purposes of this disclosure portions of the EMR are particularly important. To this end, as shown inFIG. 1 ,EMR database 15 includes apatient identification database 31, an appointments orscheduling database 69, and a guardian/dependent database 71. Here, while each ofdatabases database EMR database 15. The databases described herein are merely provided as an example, and the data is shown arranged in a manner intended to simplify explanation of the invention. It will be apparent to those of ordinary skill in the art that the data can be arranged in any of a number of different ways, in one or multiple databases, and that the description here is not intended to limit the invention. - The present invention provides methods for identifying patients using common forms of identification, and, in a specific example, readable personal identifiers such as credit cards, and for identifying dependents through a guardian's personal identification. By way of example, the system will be described with reference to an exemplary family, headed by Bruce Johnson and his wife Helen Smith. Bruce and Helen are the parents of Bradley Johnson. Bruce has a daughter, Elizabeth Johnson, from a previous marriage, and Helen has a daughter, Sally Smith, from a previous marriage. Bruce, Bradley and Elizabeth Johnson are all patients at St. Daniel's clinic, as is Sally Smith. Helen Smith is not a patient, and is not identified in the associated databases in
memory 72 a. Registration of the extended Johnson family using registered personal identifiers and particularly through a patient check-insystem 10 a is described below. Registration is shown through a series of exemplary screen shots. It will be apparent, however, that the form of data entry can be varied and that these screen shots are provided by way of illustration only. Moreover, as the present invention is shown for a kiosk system, it will be apparent that the invention can also be used with other systems that use personal identifiers and identification cards to identify users. - Referring now to
FIG. 2 , a flowchart showing aprocess 100 for correlating one or more patients with a personal identifier is shown. As described here, the process will initially be described for providing a personal identification card for Sally Smith, the daughter of Helen Smith, who, as noted above, is not a patient at the clinic. Subsequently, a similar process will be shown for Bruce Johnson, who is a patient of the clinic, registering his daughter Elizabeth, from akiosk 26 a. Both Helen and Bruce will also register their son, Bradley. In this example, it is assumed that Bruce and Helen share a credit card account and use this credit card account MC xxxxxx1880 to register the dependent patients. - Referring still to
FIG. 2 and also toFIGS. 3 and 4 , when Helen Smith approaches thekiosk 26 a upon entry to the clinic, ascreenshot 120, welcoming a user to thekiosk 26 a is shown. Atscreenshot 120, amessage 122 is provided asking the user to identify his or her self. Selectable icons are also provided for entering a personal identifier, which can be acredit card 124,personal health card 126,personal information 128, or a driver'slicense 129, as shown here, or various other forms of identification and other types discussed hereafter. Anarrow 127 can also be provided to select between the icons. Although any of these various types of identification can be used in the present invention, in the description below, it will be assumed that the identification provided is a credit card having account number MC xxxxxx1880. - Referring now to
FIG. 4 , after Helen Smith chooses to insert a creditcard using icon 124,screenshot 130 is displayed, including amessage 132 instructing the user to insert the card in acard reader 19, shown schematically ascard reader 134. Icons providing options to return to thelast screen 136 and to exit theprocess 138 are also provided. Referring now also toFIG. 5 , in process block 104 ofFIG. 2 , an identity of the cardholder and the card number are retrieved from the magnetic strip on the card, and the card data is evaluated as compared to data indatabase 31. Because neither the card nor Helen Smith is found in the database, either as a patient, guardian, or as a cardholder, screen shot 140 is displayed (FIG. 7 ), instructing Helen Smith to proceed to theregistration desk 950 to register the card in accordance with the steps provided below. - Referring still to
FIGS. 1 , 2, 5, and now toFIGS. 8-10 , to associate a patient with the card, inprocess block 106, the receptionist or other personnel requests identification data for the patient or dependent that is to be registered with the card, and enters this data into apatient data screen 150 in this screen, the name of the patient, Sally Smith, is entered inblock 152, along with a social security number inblock 154, and a birth date inblock 156. The receptionist also requests verification of the relationship between the cardholder Helen Smith, and the patient Sally Smith, and, after verification, enters this relationship intodata block 158. Theprocess 100 then compares the entered data to data in theEMR database 15, and verifies the identity of the patient. When an appropriate relationship is established and verified by the receptionist, the process proceeds to process block 108, and the receptionist acquires credit card data from Helen Smith. The relationship data may also optionally be stored in a guardian/dependent database 71, as described below. - Referring now also
FIG. 9 , the receptionist next acquires credit card data including the type ofcard 162, brand ofcard 164,card number 166,cardholder name 168, andexpiration date 169. The data is entered by the receptionist intoscreenshot 160. When the identification is a credit card as described here, the card can be used both for identification and for payment purposes, and the receptionist therefore requests information regarding how the card is to be used, as shown in screen shot 170 ofFIG. 10 , which provides the options ofidentification 172,payment 174, and co-payment 176. After the appropriate data is acquired, the data is entered into the screen shot 170. Although a limited number of options are shown here by way of example, it will be apparent that card usage can include additional options, and that these options can be specified by the facility. For example, it is also possible to specify whether the card is to be used solely for check-in, for scheduling of appointments, or for other types of health care access. These options can be individually configures by users or facilities. It will also be apparent that the type of data entered will vary depending on the type of identification card used. Thus, for example, the data entered for a driver's license will be specific to this form of identification. - Referring now also to
FIGS. 5 and 6 , a patient information database 51 is shown both prior to registration of identification cards, and after registration of identification cards, respectively. As shown inFIG. 5 , therefore, initially, no identification data is associated with patient Sally Smith incolumn 80. After data is acquired in process block 112 (FIG. 2 ), the acquired data is stored to thedatabase 31 for later retrieval. As shown inFIG. 6 , the stored data can include patient name Sally Smith incolumn 80, card identification number MC xxxxxx1880 incolumn 82, and the card holder name, Helen Smith, incolumn 84. A relationship between the cardholder and identified patient is stored incolumn 86 and card usage data is stored incolumns database 31, a patient identifier that can include a combination of card data and other identifying data associated with the card, such as a name of the cardholder, can be calculated or established, as described more fully below. This identifier can also be used to allow multiple users of a single credit card account to associate different patients with the account, also as described more fully below. - The relationship between Helen and Sally Smith can also be stored in the guardian/
dependent database 71, as shown here inFIG. 11 . When a guardian or caregiver is associated with a patient in the database, moreover, a level of access can also be established. For example, a parent may be allowed access to schedules and personal identification cards, and medical records of the specified dependent, while a caregiver such as a nanny or babysitter may be allowed access only to check in and out of scheduled appointments. For purposes of this example, it is assumed that, with the registration of Sally Smith, Helen Smith also registers her second dependent, Bradley Johnson, using the same credit card, as shown indatabase 31 ofFIG. 6 . - Although the correlation of identification cards to patients can be performed by a receptionist at
reception desk 950, in alternate embodiments of the invention, a cardholder guardian can establish a secure means for identification of a dependent through thekiosk 26 a as well, as will now be described as Bruce Johnson registers his dependents through thekiosk 26 a. Referring again toFIG. 3 , upon entry to the clinic, ascreenshot 120, welcoming a user to thekiosk 26 a is shown. Atscreenshot 120, amessage 122 is again provided asking the user to identify his or her self and providing selectable icons for acredit card 124,personal health card 126, orpersonal information 128, or a driver'slicense 129. Although any of these various types of identification can be provided, in the description below, it will again be assumed that the identification provided is a credit card, and that the account number is MC xxxxxx1880. - Referring now to
FIG. 4 ,screenshot 130 is displayed next, providing amessage 132 instructing the user to insert the card in acard reader 19, shown schematically ascard reader 134. Referring now also toFIG. 12 , thecard reader 19 reads the data from the credit card, compares the data to thedatabase 31 ofFIG. 5 , and recognizes both the name Bruce Johnson and the card as having been previously registered indatabase 31. Thereafter, aconfirmation screen 180 can be provided asking the user inmessage 182 to confirm his or her identity by accessing theconfirm icon 184. Apicture 185 of the user can also be provided. To affirm identity, or as an alternative to the card insertion, the patient look-up process described below with reference toFIGS. 22 - 29 can also be used. - After the user Bruce Johnson has accessed the system, in
screenshot 190 ofFIG. 13 , he is asked to select between a number of different possible options from thekiosk 26 a. As shown here, the user can check in for appointments inicon 132, check in for lab work inicon 134, update account information inicon 136, find a facility location inicon 138, and check out after anappointment icon 140. In order to add personal identifiers to the database for himself and his dependents, the user selects an updateaccount information icon 136 and proceeds toscreenshot 140, which asks Mr. Johnson to select between various types of data to edit. As shown here, the data can include personal data 142, insurance data 144, and/or an option to setup personal identifiers in icon 146. When the personal identifier setup icon 146 is selected, the user can select to setup accounts for the personal identifier already submitted or provide an additional card or identifier (screen shot not shown). If an additional identifier is provided, in screenshot 130 (FIG. 4 ), the user is prompted to insert an additional identification card for registration in thecard reader 19. - Referring now to
FIG. 14 , in addition to, or in lieu of entry of the card, the user can be prompted inscreenshot 200 to enter thecredit card brand 204, acard number 206, and the associatedexpiration date 208. After the card is identified and the acquired data is stored,server 22 a accesses database 71 (FIG. 11 ), and retrieves a list of the patients associated with Bruce Johnson. As shown here, thedatabase 71 includes afirst column 60 of patient names, addresses and other identifiers; asecond column 62 providing a first list of guardians; athird column 64 providing a second list of guardians and identifying data such as a social security number. Here, thedatabase 71 identifies Bruce Johnson as a patient, and also identifies Bruce Johnson as the guardian of Elizabeth Johnson and Bradley Johnson. Helen Smith, due to the previous registration described above, can also be listed as a guardian. The system can, in order to provide additional security, also query the user to input a social security number, a portion of a social security number, a zip code or other identifying data to add a further level of security. Although a separate guardian/dependent database 71 is shown here, it will be apparent that the dependency data can also be provided in thedatabase 31, as described above, or in any combination of logical or physical databases. The guardian/dependency relationships provided in thedatabase 71 can be established either through entry of the data through a receptionist andreceptionist computer 950, as described above, through pre-existing data in the database, by providing proof of guardianship to the clinic generally, through existing insurance or health care records, or in other ways which will be apparent to those of skill in the art. - Based on data retrieved from the
database 71, screen shot 210 (FIG. 15 ) is displayed on thekiosk 26 a, providing the names of the three patients that can be associated by Bruce Johnson—Bruce Johnson, Elizabeth Johnson, and Bradley Johnson—and the user Bruce Johnson is prompted to select a patient to associate with the card. Here it is assumed that Bruce Johnson selects Bradley Johnson. In screenshot 220 (FIG. 16 ), the system then requests the user to specify the activities that should be associated with the selected patient and card. When the identification is a credit card, as described here, the user can specify use for identification (icon 224) and for payment purposes, either for a co-pay only (icon 226) or payment for all purposes (icon 228). This data is then stored along with the card data and patient data indatabase 31. Various other data can also be manipulated and stored in thedatabase 31, as will be apparent to those of skill in the art. - Referring now to
FIG. 17 , after the identification data is added to the card (screenshot 230), the cardholder is asked whether additional patients should be added to the card. Three icons appear. Ayes icon 232, a noicon 234, and a viewcard data icon 236. Selecting theyes icon 232 returns the cardholder to screen 210 ofFIG. 15 , where Mr. Johnson can now register Bradley Johnson with his card, using the same steps specified above. - Selecting the no
icon 234 takes the patient to screen 190 ofFIG. 13 and selecting the viewcard data icon 236 takes the patient toscreenshot 240 ofFIG. 18 ,screenshot 240 where data from thedatabase 31 is shown. Atscreenshot 240, a list of the patients associated with the registered card is shown. Bruce Johnson is listed as a patient, along with data specifying that the card is to be used both as identification and for payment. Bradley Johnson is also listed, as a dependent of Bruce Johnson. The card is used for identification only for Bradley. Referring now toFIG. 19 , after the steps discussed above are also taken to add Elizabeth Johnson to the identification card, all three patients are registered to the card as shown inscreenshot 242 ofFIG. 19 . Two additional icons, an “edit patients” icon 246 and an exit icon 248 are provided. When the patient chooses to exit by selecting icon 248, the kiosk screen returns toscreenshot 190 ofFIG. 13 , which allows the patient to check in forappointments 194, check in forlab work 190, updateaccount information 198, find afacility location 200, or checkout after anappointment 202. It will be apparent that the guardian can also be provided with options to schedule appointments, access medical records, or perform other health care procedures for the dependents. Furthermore, it will be apparent that, although an exit icon is shown here, various other screen and data flows are also possible. - When the check in for
appointments icon 194 icon is selected,screenshot 270 ofFIG. 20 is displayed, illustrating Bruce Johnson, Elizabeth Johnson, and Bradley Johnson, and therefore all of the patients associated with the selected card and patient identification. When Helen Smith enters the facility and inserts her card with the same account number, her dependents Sally Smith and Bradley Johnson are shown (FIG. 21 ). Therefore, despite the fact that Bruce Johnson and Helen Smith are using the same credit account, they are provided with access to different sets of patients based on data retrieved from thedatabase 31. - Referring again to
FIGS. 5 and 6 and also toFIG. 6A , comparative exemplary databases are shown illustrating one implementation of the present invention. Thedatabase 31, as discussed above, correlates patients and personal identifiers here shown as identification cards. Referring first toFIG. 5 , thedatabase 31 includes apatient column 80, acard identification column 82, acardholder column 84, arelationship column 86, anidentification column 88, apayment column 90 and anidentifier column 92. Thepatient column 82 includes the names of patients of the clinic, here providing the names of Bruce, Bradley and Elizabeth Johnson, as well as Sally Johnson. Helen Smith, as described above is not a patient. The remaining columns associate identification and payment information with the patients. InFIG. 5 , no identification has been provided for any of the patients but Bruce Johnson, and these columns therefore are blank for the other listed patients. -
FIG. 6 illustrates the database after Bruce Johnson and Helen Smith have registered their dependents in the database as described above, with both guardians using the same credit card account, which is shard by Helen Smith and Bruce Johnson. Here, although Bruce and Helen share the same credit card account, they do not share the same set of dependents, therefore another identifier is required to provide appropriate access to the parents. To account for this situation, a unique identifier, which can, for example, combine account data fromcolumn 82 and cardholder data fromcolumn 84 or any other identification data can be calculated and stored for each specific card as shown incolumn 92. As shown here, despite the fact that the same account is used, a first identifier is provided for the card when used by Bruce Johnson, and a second identifier for the account when used by Helen Smith. Thus, as shown inFIGS. 20 and 21 , the same card can provide access to different sets of patients. Referring now toFIG. 6A , rather than using the same credit card as described above, the patients can be associated with different cards. Here, for example, Bruce Johnson uses credit card MCXXXXXX1880 to identify himself, and VSXXXXXX1996 to identify dependents Bradley and Elizabeth Johnson. Helen Smith uses a separate account, MCXXXXXX1334 to identify her dependents, Bradley Johnson and Sally Smith. Each parent, therefore, can associate their dependent children with different identification cards. Although a specific identifier is described incolumn 92, it will be apparent that the process can also determine the identity of the user by comparing a second form of identification, such as a name on the card, to data in the database, or require the insertion of a second form of identification from the parent, to differentiate between account holders rather than calculating a specific personal identifier shown incolumn 92. It will also be apparent that a patient can be associated with a number of different personal identifiers and cards, and that an unlimited number of patient identification associations can be established, stored, and maintained. Furthermore, it is also possible to identify cardholders based on the submitted identification card alone, or on the card in combination with personal data provided by the user. - As described above, in the preferred embodiment, the personal information is read from the magnetic strip of a credit card and stored in the database system as a database key. The personal information from the magnetic strip can be used to create a unique token, or can be compared to the stored data when entered. Although a credit card account number has been described above for simplicity, the token may also be a hash or other encrypted version of the account number of the credit card. In some applications, as in the situation described above where multiple users use the same credit card to identify different sets of patients, the database key requires more than the encrypted or hashed account number and might include any other identifying information available, such as the guardian's personal name, card id, the CV2 data, etc. thereby forming the
identifier 92. - Although the system has been described above for simplicity as using a credit card for accessing data in the system, the personal identifier can be any type of readable personal identifier or token capable of storing unique identifying information and/or of being read by a machine. The personal identifier may, therefore, be a driver's license, insurance card, or health care identification card or a combination of such forms of identification, or any other form of identification that includes personal information such as account number, full name, address, date of birth, and telephone number stored in a machine readable format. The identifier may include active or passive memory storage, be an RFID tag, a barcode or other type of optical encoding device, or a biometric identifier.
- As used herein, a dependent is a person that either does not have a useable personal identifier, or is not capable of using the personal identifier, such as a child or a dependent adult. The guardian can be any individual with a useable personal identifier, such as a parent or care-giver. The guardian, moreover, is not required to be otherwise associated in anyway with the health care facility or the database system. In the database system, the database record for the guardian's personal identifier can be associated with one or more database records of the dependents, with or without identifying the guardian.
- Although specific database records are used by way of example above, it would be understood to one skilled in the art that the dependent's database record in the database system can take many forms, and may contain personal information of the dependent including without limitation name, address, date of birth, social security number, and sex. In addition, the method further contemplates one or more guardians each with their own personal identifier being associated with one or more identical dependents. In this situation, one or more guardians may responsibility for the dependent, such as the case of parents. Further, the method contemplates a guardian with more than one personal identifier identifying the same or different dependents.
- Referring now to
FIG. 22 , in an alternate embodiment of the invention, thekiosk 26 a can be used to find a patient, guardian, or dependent in the database using a patient “look-up” system that identifies a particular patient based on personal identification data input by the kiosk operator. Although, for simplicity, the system will be described below with reference to identifying a patient, it will be apparent the system can also be used to identify a guardian, or an accountholder in the database, and that it is not necessary that the identified individual be a patient. It will also be apparent that the described system can be used in lieu of other forms of identification, or in combination with a patient identifier such as a credit card, driver's license, insurance card, or other token. In the process described below, a probability calculation is used to limit the amount of data that must be input by a user. The probability is calculated based on an analysis of the data in the database, and therefore increases both the security and efficiency of an automated patient identification process. - Referring still to
FIG. 22 , ininitial step 402 of patient look-upprocess 400, a target subset of patients or patient data is initially identified. The target subset can be determined based on patient identifying data, such as a name or a portion of the name of the patient, or a social security number or a portion of a social security number provided by the patient. Alternatively, the subset could be determined based on a known list of patients that have appointments on the specific day that the kiosk is being used. In any case, the purpose of this step is to narrow the set of patient data that must be evaluated to determine the identity of the patient using thekiosk 26 a. Referring now also toFIG. 24 , an exemplary screen shot is shown. Here, in screen shot 280, thekiosk 26 a prompts the patient to enter the first three letters of his or her first and last name in data entry blocks 282 and 284. As shown here by way of example, the patient enters the first three letters “Bru” indata block 282 and the first three letters “Joh” inblock 284. - Referring now also to
FIG. 23 a patient look-updata base 290 is shown including patient identifying data, here shown as apatient name 292,birth date 293,social security number 294,phone number 295, andzip code 296. As shown here by way of example, there are four patients whose names are retrieved based on the data entered into the screen shot 280: Bruce Johnson, who lives at 555 Maple Drive and has a birth date of Jul. 31, 1960; Bruce Johnson who also lives at 555 Maple Drive and has a birth date of May 1, 1937; Bruno Johnsrud, who lives at 1222 North St. and was born on Jun. 3, 1979 and Bruce Johnstone, of 777 Oak Court, born on Jun. 4, 1979. To narrow the identity of the patient, theprocess 400 continues to process block 404 to begin the process of determining the best next question to ask. - Referring again to
FIG. 22 , inprocess block 404, theprocess 400 evaluates the data in thedatabase 290 to identify the number of unique acceptable values or answers for each identification parameter in the database subset identified inprocess block 402. Referring again toFIG. 23 , here, for example, there are four sets of identification parameters shown: birth date, social security number, phone number, and zip code. The birth date, moreover, can be parsed into individual comparable segments consisting of a month, a date, and a year. Each of these columns, and each segment of the parsed birth date data, represents a potential question for the user, the answer to which helps to further narrow the potential list of patients, and to eventually identify the patient. Inprocess block 404, the system evaluates the data in each individual column to determine the number of unique acceptable answers. In the limited example shown here, for example, there are three unique acceptable answers to a question requiring a patient to identify a zip code or telephone number, two answers in the social security number column, and four unique answers or values in the date of birth column. This data is used by theprocess 400 to determine which data will most quickly narrow the field of patients to a single, unique patient. If the birth date column is further broken down by month, date, and year, the number of possibilities decreases. - In
process block 406, theprocess 400 calculates the distribution of unique patients associated with each acceptable answer. Using the limited example above ofFIG. 23 , there are two patients associated with thezip code 54321, and one patient each associated with the other two zip codes. Instep 408, theprocess 400 determines the number of questions having unique acceptable answers above a threshold value, where the threshold can be a fixed number, a percentage, or a ranking relative to other questions. - Subsequently, in
step 410, theprocess 400 selects the question with the largest number of “good answers”, where a good answer is an answer that has fewer than a defined threshold number of patients associated with it. By way of example, a question may have ten acceptable answers, as determined instep 404. Instep 406, it is determined that three of the ten acceptable answers have ten or more patients associated with the answer. Five have six or more patients, and two have three or fewer patients associated with each answer. In this example, there are two good answers, because these answers filter the field to three or fewer patients, thereby limiting the number of additional questions that would be required to identify the patient. Instep 412, the question with the largest number of good answers is selected, and inprocess block 414, that question is displayed to the user. Subsequently, theprocess 400 determines whether a patient is uniquely identified inblock 416. If the patient is not uniquely identified by the response to the question, theprocess 400 returns to step 404. The process continues until a specific patient is identified, or until it becomes clear that the patient cannot be identified. At this point, the patient can be directed to a receptionist. - Referring again to
FIG. 24 and now alsoFIGS. 25 throughFIG. 28 , a series ofexample screen shots - Referring first to
FIG. 25 , in screen shot 300, the patient is prompted to enter the year of his or her birth. As shown here, adata block 302 is provided for entry of the data, and the patient enters 1979, which, referring also toFIG. 23 , narrows the identity of the patient to either Bruno Johnsrud or Bruce Johnstone. InFIG. 26 , in screen shot 304, thekiosk 26 a requests day of his or her birth, and the patient here enters the number three into data block 306. Based on this data, the system can determine that the patient is Bruno Johnsrud. In some applications, therefore, it would be possible to stop acquiring data at this point. However, if the patient is not uniquely identified, or if it is desirable to verify the identity of the patient, the kiosk can move on to thescreen 308 ofFIG. 27 , which prompts the user to identify the last four digits of his or her social security number, and in screen shot 312 ofFIG. 28 , the last four digits of his or her telephone number. Although not shown here, it will be apparent that the zip code ofcolumn 290, address, or other data could also be acquired to determine the identify of the patient. - Although described above for purposes of identifying a patient, as noted above, it will be apparent that the patient look-up system described above can also be used to identify a guardian, who can then be given access to the associated records of dependents, as shown, for example, in the database of
FIG. 11 . In this application, personal identification of the dependent can also be requested, as described above. - Although the system has been described above as including data entry blocks, in alternative embodiments of the invention, a touch screen could be used and the data for entry provided on screen. Thus, for example, in the screen shot 280 of
FIG. 22 , an alphabet can be provided on the screen, and the user prompted to select the appropriate letters from the display screen. In the remaining screens, a series of digits between 0 and 9 can be shown. Alternatively, a list of, for example, the birth years ofcolumn 293 inFIG. 23 could all be displayed, preferably with a series of random years that are not associated with any of the identified patients, again to limit the probability of identity theft or fraud, and to retain compliance with federal regulations. - Furthermore, although the system has been described above with reference to an automated patient check-in system, and specifically a kiosk system, it will be apparent that the identification methods described above can also be applied in other applications, and that the inventive concepts of the present invention are not limited to use in kiosks. Additionally, communications between a patient and the patient check-in
system 10 a can be provided using wireless personal communication devices 743 (FIG. 1 ). A user can, for example, submit credit card identification data wirelessly from thedevice 743 rather than inserting a card into a card reader as described above. Identifying data for a driver's license, insurance account, or other data could also be transmitted rather than entered through a kiosk. - Additionally, although specific screen shots are described above both for a
receptionist computer 950 and akiosk 26 a, it will be apparent that the screen shots are exemplary only, and that the icons, data entry screens, and informational screens shown are not intended to limit the invention. The data accessible through these systems is limited only by what is available in the associated databases, and access rights associated with the user accessing the database. - One or more specific embodiments of the present invention have been described above. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.
- Thus, the invention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the following appended claims. To apprise the public of the scope of this invention, the following claims are made:
Claims (28)
1. A method for correlating dependent patients with a personal identifier of a guardian in a health care system for checking into an appointment or accessing health care records, the method comprising the following steps:
obtaining a readable personal identifier from a guardian of a dependent patient;
registering the readable personal identifier with the dependent patient in a healthcare database;
prompting a user to present the readable personal identifier to a reader at a health care facility; and
wherein the readable personal identifier identifies the dependent patient and provides access for the guardian to process health care services for the dependent patient.
2. The method as recited in claim 1 , wherein the readable personal identifier comprises a credit card.
3. The method as recited in claim 1 , wherein the readable personal identifier comprises at least one of a driver's license, a health insurance card, or a personal identification card.
4. The method as recited in claim 2 , further comprising the step of producing a unique identifier as a combination of an account number associated with the credit card and another cardholder identifier, wherein a first and a second cardholder are associated with a first and second unique identifier.
5. The method as recited in claim 4 , further comprising the step of associating a first dependent with the first unique identifier and a second dependent patient with the second unique identifier.
6. The method as recited in claim 2 , further comprising the step of associating an indicator of whether the credit card is to be used as a form of payment with the dependent patient in the healthcare database.
7. The method as recited in claim 1 , further comprising the step of providing a kiosk including a reader capable of reading the personal identifier, and wherein the kiosk is programmed to compare the personal identifier to the data in the healthcare database and to display at least one dependent associated with the personal identifier at check-in.
8. The method as recited in claim 1 , wherein the personal identifier comprises at least one of a biometric identifier, an active memory storage device and a passive memory storage device.
9. The method as recited in claim 1 , wherein the personal identifier comprises a readable token.
10. The method as recited in claim 1 , The method as recited in claim 1 , further comprising the step of providing a kiosk including a reader capable of reading the personal identifier wherein the step of registering the readable personal identifier with the dependent patient in the healthcare database comprises prompting the guardian to select a dependent patient to associate with the personal identifier in the database at the kiosk.
11. A data access system for use in a health care facility, the data access system comprising:
a health care computer network;
a health care database including a patient database, and a data structure associating a readable personal identifier of a guardian with at least one dependent patient; and
a reader device connected to the computer network for reading the readable personal identifier when presented, wherein the computer network is programmed to correlate the readable personal identifier with the dependent patient in the database and to provide the guardian access to at least a portion of the health care database to process health care services for the patient.
12. The data access system as recited in claim 11 , wherein the step of providing access to at least a portion of the healthcare database comprises providing the guardian access to check the dependent patient in for an appointment.
13. The data access system as recited in claim 12 , wherein the step of providing access to at least a portion of the healthcare database comprises providing the guardian access to schedule an appointment for the patient.
14. The data access system as recited in claim 11 , wherein the readable personal identifier comprises at least one of a credit card, a driver's license, a health insurance card, an active memory storage device, a passive memory storage device, and a biometric identifier.
15. The data access system as recited in claim 11 , wherein the database correlates a plurality of dependents with a personal identifier.
16. The data access system as recited in claim 11 , wherein the reader is provided in a kiosk connected to the computer network and providing a display for interacting with at least one of the guardian and the dependent patient.
17. A method for associating dependent patients with a first and a second accountholder of a single account, the method comprising the following steps:
prompting the first accountholder to register account data in a healthcare database, the account data including at least one of an account number and an identifier of the first accountholder;
prompting the second accountholder to register account data in the healthcare database, the account data including at least one of the account number and an identifier of the second accountholder; and
associating a dependent of the first accountholder in a database with the account number and the identifier of the first accountholder; and
associating a dependent of the second accountholder in a database with the with the account number and the identifier of the second accountholder, wherein when the first accountholder uses the account as identification, the first accountholder is provided access to process health care services for the dependent of the first accountholder and when the second accountholder uses the account as identification, the second accountholder is provided access to process health care services for the dependent of the second accountholder.
18. The method as recited in claim 17 , wherein the account is a credit account.
19. The method as recited in claim 17 , wherein the account is a health insurance account.
20. The method as recited in claim 17 , wherein the account is identified by a readable identifier including at least one of an active memory storage, a passive memory storage device, or an optical encoding device.
21. The method as recited in claim 20 , further comprising the step of providing the readable identifier to a reader to allow access to process health care services.
22. The method as recited in claim 17 , further comprising the step of associating at least one of the dependent of the first accountholder with the second unique identifier and the dependent of the second accountholder with the first unique identifier when the corresponding one of the dependents is also a dependent of the other of the first and second accountholders.
23. The method as recited in claim 17 , wherein at least one of the first and second accountholders is a patient registered in the healthcare database.
24. The method as recited in claim 17 , further comprising the steps of producing a first unique identifier as a combination of the account number and the identifier of the first accountholder and second unique identifier as a combination of the account number and the identifier of the second accountholder.
25. A method of identifying a user associated with a health care database at a computerized entry point, the method comprising the following steps:
(a) prompting the user to input at least one of the following types of identification data at the computerized entry point:
(i) at least a portion of the user's first name,
(ii) at least a portion of the user's last name,
(iii) at least a portion of the series of digits in an identification number,
(iv) at least a portion of a birth date;
(b) accessing the health care database to identify a target subset of users including, the target subset including at least one user that correlates to the input data;
(c) evaluating data correlating to the types of identification data associated with the target subset of users in the healthcare database to determine at least one of the types of identification data that is most likely to reduce the target subset to a single user and prompting the user to input the determined type of identification;
(d) repeating step (a) to acquire another of the types of identification data, step (b) accessing the database, and step (c) until a single user is identified in the database; and
(d) allowing the single user to process health care services when the single user is identified.
26. The method as recited in claim 25 , wherein step (a)(iii) comprises the step of prompting the user to input at least a portion of a series of digits in at least one of a social security number, a telephone number, a personal identification number, a health insurance account number, a zip code, and a personal identification number associated with the account of the user.
27. The method as recited in claim 25 , wherein the user is a guardian of at least one dependent in the health care database and step (d) comprises allowing the single user to process health care services for the dependent.
28. The method as recited in claim 25 , wherein step (c) further comprises the step of notifying the user when the user cannot be identified by the input data and prompting the user to talk to a receptionist.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/734,601 US20080251579A1 (en) | 2007-04-12 | 2007-04-12 | Secure identification of dependants |
US12/833,359 US7992780B2 (en) | 2007-04-12 | 2010-07-09 | Secure identification of dependants |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/734,601 US20080251579A1 (en) | 2007-04-12 | 2007-04-12 | Secure identification of dependants |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/833,359 Continuation US7992780B2 (en) | 2007-04-12 | 2010-07-09 | Secure identification of dependants |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080251579A1 true US20080251579A1 (en) | 2008-10-16 |
Family
ID=39852812
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/734,601 Abandoned US20080251579A1 (en) | 2007-04-12 | 2007-04-12 | Secure identification of dependants |
US12/833,359 Active US7992780B2 (en) | 2007-04-12 | 2010-07-09 | Secure identification of dependants |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/833,359 Active US7992780B2 (en) | 2007-04-12 | 2010-07-09 | Secure identification of dependants |
Country Status (1)
Country | Link |
---|---|
US (2) | US20080251579A1 (en) |
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080314969A1 (en) * | 2007-06-20 | 2008-12-25 | Hussey Robert M | Patient care indicia reader system |
US20090165123A1 (en) * | 2007-12-19 | 2009-06-25 | Giobbi John J | Security system and method for controlling access to computing resources |
US20090206992A1 (en) * | 2008-02-14 | 2009-08-20 | Proxense, Llc | Proximity-Based Healthcare Management System With Automatic Access To Private Information |
US20090299770A1 (en) * | 2008-05-29 | 2009-12-03 | The Quantum Group, Inc. | System and method for making patient records follow a physician |
US20110241823A1 (en) * | 2010-04-02 | 2011-10-06 | Anders Paul B | Tag-based personalization |
US20130080234A1 (en) * | 2011-09-26 | 2013-03-28 | National Bankcard Services, Inc. | Method of targeting consumers for up-selling based on purchasing history |
US20140129702A1 (en) * | 2012-11-05 | 2014-05-08 | Cercacor Laboratories, Inc. | Physiological test credit method |
US20180367670A1 (en) * | 2017-06-20 | 2018-12-20 | OpenPath Security Inc. | Virtual Office Receptionist |
US20200058032A1 (en) * | 2018-08-20 | 2020-02-20 | Denikumar Dalpatbhai Lad | Biometric Payment Transaction Without Mobile or Card |
US10698989B2 (en) | 2004-12-20 | 2020-06-30 | Proxense, Llc | Biometric personal data key (PDK) authentication |
US10764044B1 (en) | 2006-05-05 | 2020-09-01 | Proxense, Llc | Personal digital key initialization and registration for secure transactions |
US10769939B2 (en) | 2007-11-09 | 2020-09-08 | Proxense, Llc | Proximity-sensor supporting multiple application services |
US10856750B2 (en) | 2017-04-28 | 2020-12-08 | Masimo Corporation | Spot check measurement system |
US10909229B2 (en) | 2013-05-10 | 2021-02-02 | Proxense, Llc | Secure element as a digital pocket |
US10943471B1 (en) | 2006-11-13 | 2021-03-09 | Proxense, Llc | Biometric authentication using proximity and secure information on a user device |
US10964413B2 (en) | 2008-05-29 | 2021-03-30 | The Quantum Group, Inc. | System and method for making patient records follow a physician |
US11080378B1 (en) | 2007-12-06 | 2021-08-03 | Proxense, Llc | Hybrid device having a personal digital key and receiver-decoder circuit and methods of use |
US11095640B1 (en) | 2010-03-15 | 2021-08-17 | Proxense, Llc | Proximity-based system for automatic application or data access and item tracking |
US11113482B1 (en) | 2011-02-21 | 2021-09-07 | Proxense, Llc | Implementation of a proximity-based system for object tracking and automatic application initialization |
US11120449B2 (en) | 2008-04-08 | 2021-09-14 | Proxense, Llc | Automated service-based order processing |
US11206664B2 (en) | 2006-01-06 | 2021-12-21 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
US11258791B2 (en) | 2004-03-08 | 2022-02-22 | Proxense, Llc | Linked account system using personal digital key (PDK-LAS) |
US11546325B2 (en) | 2010-07-15 | 2023-01-03 | Proxense, Llc | Proximity-based system for object tracking |
US11553481B2 (en) | 2006-01-06 | 2023-01-10 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
US11837341B1 (en) * | 2017-07-17 | 2023-12-05 | Cerner Innovation, Inc. | Secured messaging service with customized near real-time data integration |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8332322B2 (en) * | 2010-05-07 | 2012-12-11 | Miicard Limited | Method of establishing identity validation based on an individual's ability to access multiple secure accounts |
US11670405B2 (en) | 2018-07-12 | 2023-06-06 | Direct Supply, Inc. | Apparatus for clinical data capture |
US11238416B1 (en) | 2020-09-25 | 2022-02-01 | SkedgeAlert, Inc. | Availability based resource scheduling |
WO2022248715A1 (en) * | 2021-05-28 | 2022-12-01 | Huma Therapeutics Limited | Methods and systems for facilitating digitally distributed clinical trials |
Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5726688A (en) * | 1995-09-29 | 1998-03-10 | Ncr Corporation | Predictive, adaptive computer interface |
US6094640A (en) * | 1993-06-08 | 2000-07-25 | The Pugliese Company | Electronic ticketing and reservation system and method |
US6121968A (en) * | 1998-06-17 | 2000-09-19 | Microsoft Corporation | Adaptive menus |
US6232972B1 (en) * | 1998-06-17 | 2001-05-15 | Microsoft Corporation | Method for dynamically displaying controls in a toolbar display based on control usage |
US20020166235A1 (en) * | 1999-12-21 | 2002-11-14 | Larry Winget | Composite removable hard top |
US20030033079A1 (en) * | 2001-08-11 | 2003-02-13 | Endicott William L. | Computer-implemented system and method for wayfinding |
US6640212B1 (en) * | 1999-09-30 | 2003-10-28 | Rodney L. Rosse | Standardized information management system for long-term residence facilities |
US20040138924A1 (en) * | 2002-12-12 | 2004-07-15 | Gorsev Pristine | System and method for intake of a patient in a hospital emergency room |
US20040186744A1 (en) * | 2003-03-17 | 2004-09-23 | Lux Cindy M. | Patient registration kiosk |
US20050010485A1 (en) * | 2003-07-11 | 2005-01-13 | Quadratic Systems Corporation | Integrated system and method for selectively populating and managing multiple, site-specific, interactive, user stations |
US6847387B2 (en) * | 1997-01-21 | 2005-01-25 | International Business Machines Corporation | Menu management mechanism that displays menu items based on multiple heuristic factors |
US20050039041A1 (en) * | 2001-11-14 | 2005-02-17 | Shaw Mari Myra | Access, identity, and ticketing system for providing multiple access methods for smart devices |
US20050044508A1 (en) * | 2003-08-21 | 2005-02-24 | International Business Machines Corporation | Method, system and program product for customizing a user interface |
US20050125265A1 (en) * | 2003-12-09 | 2005-06-09 | International Business Machines Corporation | System and method to re-accommodate airline passengers on an individualized basis via a self-service device |
US20050131856A1 (en) * | 2003-12-15 | 2005-06-16 | O'dea Paul J. | Method and system for adaptive user interfacing with an imaging system |
US20050144642A1 (en) * | 2003-12-24 | 2005-06-30 | Craig Ratterman | Systems and methods for communicating with customers in the hospitality industry |
US20050234741A1 (en) * | 2004-04-16 | 2005-10-20 | Sumit Rana | Electronic appointment scheduling for medical resources |
US20050240958A1 (en) * | 2004-04-21 | 2005-10-27 | Moviecrazy, Inc. | Method and apparatus for on-demand multimedia rental and sales services |
US20050261942A1 (en) * | 2004-05-20 | 2005-11-24 | Wheeler Gary A | Self-serve patient check-in and preventive services kiosk |
US6981242B2 (en) * | 2002-01-11 | 2005-12-27 | Hewlett-Packard Development Company, L.P. | System and method for developing custom operator-specific software-applications |
US20060000903A1 (en) * | 2004-03-11 | 2006-01-05 | James Barry | System and method for a smart passenger travel kiosk |
US20060111941A1 (en) * | 2004-11-24 | 2006-05-25 | Blom Michael G | Automated patient management system |
US20060149603A1 (en) * | 2005-01-04 | 2006-07-06 | Barbara Patterson | Method and system for determining healthcare eligibility |
US20060206818A1 (en) * | 2005-03-10 | 2006-09-14 | Epson America Inc. | Dynamic frequently asked question system |
US20060277071A1 (en) * | 2005-06-03 | 2006-12-07 | Shufeldt John J | Patient receiving method |
US20070050197A1 (en) * | 2005-06-17 | 2007-03-01 | Edward Efron | System and method of interacting with hotel information and services |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8788293B2 (en) * | 2005-07-01 | 2014-07-22 | First Data Corporation | Healthcare system and method for right-time claims adjudication and payment |
-
2007
- 2007-04-12 US US11/734,601 patent/US20080251579A1/en not_active Abandoned
-
2010
- 2010-07-09 US US12/833,359 patent/US7992780B2/en active Active
Patent Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6094640A (en) * | 1993-06-08 | 2000-07-25 | The Pugliese Company | Electronic ticketing and reservation system and method |
US5726688A (en) * | 1995-09-29 | 1998-03-10 | Ncr Corporation | Predictive, adaptive computer interface |
US6847387B2 (en) * | 1997-01-21 | 2005-01-25 | International Business Machines Corporation | Menu management mechanism that displays menu items based on multiple heuristic factors |
US6121968A (en) * | 1998-06-17 | 2000-09-19 | Microsoft Corporation | Adaptive menus |
US6232972B1 (en) * | 1998-06-17 | 2001-05-15 | Microsoft Corporation | Method for dynamically displaying controls in a toolbar display based on control usage |
US6640212B1 (en) * | 1999-09-30 | 2003-10-28 | Rodney L. Rosse | Standardized information management system for long-term residence facilities |
US20020166235A1 (en) * | 1999-12-21 | 2002-11-14 | Larry Winget | Composite removable hard top |
US20030033079A1 (en) * | 2001-08-11 | 2003-02-13 | Endicott William L. | Computer-implemented system and method for wayfinding |
US20050039041A1 (en) * | 2001-11-14 | 2005-02-17 | Shaw Mari Myra | Access, identity, and ticketing system for providing multiple access methods for smart devices |
US6981242B2 (en) * | 2002-01-11 | 2005-12-27 | Hewlett-Packard Development Company, L.P. | System and method for developing custom operator-specific software-applications |
US20040138924A1 (en) * | 2002-12-12 | 2004-07-15 | Gorsev Pristine | System and method for intake of a patient in a hospital emergency room |
US20040186744A1 (en) * | 2003-03-17 | 2004-09-23 | Lux Cindy M. | Patient registration kiosk |
US20050010485A1 (en) * | 2003-07-11 | 2005-01-13 | Quadratic Systems Corporation | Integrated system and method for selectively populating and managing multiple, site-specific, interactive, user stations |
US20050044508A1 (en) * | 2003-08-21 | 2005-02-24 | International Business Machines Corporation | Method, system and program product for customizing a user interface |
US20050125265A1 (en) * | 2003-12-09 | 2005-06-09 | International Business Machines Corporation | System and method to re-accommodate airline passengers on an individualized basis via a self-service device |
US20050131856A1 (en) * | 2003-12-15 | 2005-06-16 | O'dea Paul J. | Method and system for adaptive user interfacing with an imaging system |
US20050144642A1 (en) * | 2003-12-24 | 2005-06-30 | Craig Ratterman | Systems and methods for communicating with customers in the hospitality industry |
US20060000903A1 (en) * | 2004-03-11 | 2006-01-05 | James Barry | System and method for a smart passenger travel kiosk |
US20050234741A1 (en) * | 2004-04-16 | 2005-10-20 | Sumit Rana | Electronic appointment scheduling for medical resources |
US20050240958A1 (en) * | 2004-04-21 | 2005-10-27 | Moviecrazy, Inc. | Method and apparatus for on-demand multimedia rental and sales services |
US20050261942A1 (en) * | 2004-05-20 | 2005-11-24 | Wheeler Gary A | Self-serve patient check-in and preventive services kiosk |
US20060111941A1 (en) * | 2004-11-24 | 2006-05-25 | Blom Michael G | Automated patient management system |
US20060149603A1 (en) * | 2005-01-04 | 2006-07-06 | Barbara Patterson | Method and system for determining healthcare eligibility |
US20060206818A1 (en) * | 2005-03-10 | 2006-09-14 | Epson America Inc. | Dynamic frequently asked question system |
US20060277071A1 (en) * | 2005-06-03 | 2006-12-07 | Shufeldt John J | Patient receiving method |
US20070050197A1 (en) * | 2005-06-17 | 2007-03-01 | Edward Efron | System and method of interacting with hotel information and services |
Cited By (52)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11258791B2 (en) | 2004-03-08 | 2022-02-22 | Proxense, Llc | Linked account system using personal digital key (PDK-LAS) |
US11922395B2 (en) | 2004-03-08 | 2024-03-05 | Proxense, Llc | Linked account system using personal digital key (PDK-LAS) |
US10698989B2 (en) | 2004-12-20 | 2020-06-30 | Proxense, Llc | Biometric personal data key (PDK) authentication |
US11206664B2 (en) | 2006-01-06 | 2021-12-21 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
US11800502B2 (en) | 2006-01-06 | 2023-10-24 | Proxense, LL | Wireless network synchronization of cells and client devices on a network |
US11212797B2 (en) | 2006-01-06 | 2021-12-28 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network with masking |
US11553481B2 (en) | 2006-01-06 | 2023-01-10 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
US11219022B2 (en) | 2006-01-06 | 2022-01-04 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network with dynamic adjustment |
US11182792B2 (en) | 2006-05-05 | 2021-11-23 | Proxense, Llc | Personal digital key initialization and registration for secure transactions |
US11551222B2 (en) | 2006-05-05 | 2023-01-10 | Proxense, Llc | Single step transaction authentication using proximity and biometric input |
US11157909B2 (en) | 2006-05-05 | 2021-10-26 | Proxense, Llc | Two-level authentication for secure transactions |
US10764044B1 (en) | 2006-05-05 | 2020-09-01 | Proxense, Llc | Personal digital key initialization and registration for secure transactions |
US10943471B1 (en) | 2006-11-13 | 2021-03-09 | Proxense, Llc | Biometric authentication using proximity and secure information on a user device |
US20080314969A1 (en) * | 2007-06-20 | 2008-12-25 | Hussey Robert M | Patient care indicia reader system |
US7967190B2 (en) * | 2007-06-20 | 2011-06-28 | Hand Held Products, Inc. | Patient care indicia reader system |
US11562644B2 (en) | 2007-11-09 | 2023-01-24 | Proxense, Llc | Proximity-sensor supporting multiple application services |
US10769939B2 (en) | 2007-11-09 | 2020-09-08 | Proxense, Llc | Proximity-sensor supporting multiple application services |
US11080378B1 (en) | 2007-12-06 | 2021-08-03 | Proxense, Llc | Hybrid device having a personal digital key and receiver-decoder circuit and methods of use |
US9251332B2 (en) | 2007-12-19 | 2016-02-02 | Proxense, Llc | Security system and method for controlling access to computing resources |
US11086979B1 (en) | 2007-12-19 | 2021-08-10 | Proxense, Llc | Security system and method for controlling access to computing resources |
US10469456B1 (en) | 2007-12-19 | 2019-11-05 | Proxense, Llc | Security system and method for controlling access to computing resources |
US20090165123A1 (en) * | 2007-12-19 | 2009-06-25 | Giobbi John J | Security system and method for controlling access to computing resources |
US10971251B1 (en) | 2008-02-14 | 2021-04-06 | Proxense, Llc | Proximity-based healthcare management system with automatic access to private information |
US11727355B2 (en) | 2008-02-14 | 2023-08-15 | Proxense, Llc | Proximity-based healthcare management system with automatic access to private information |
US20090206992A1 (en) * | 2008-02-14 | 2009-08-20 | Proxense, Llc | Proximity-Based Healthcare Management System With Automatic Access To Private Information |
US8508336B2 (en) * | 2008-02-14 | 2013-08-13 | Proxense, Llc | Proximity-based healthcare management system with automatic access to private information |
US11120449B2 (en) | 2008-04-08 | 2021-09-14 | Proxense, Llc | Automated service-based order processing |
US10964413B2 (en) | 2008-05-29 | 2021-03-30 | The Quantum Group, Inc. | System and method for making patient records follow a physician |
US20090299770A1 (en) * | 2008-05-29 | 2009-12-03 | The Quantum Group, Inc. | System and method for making patient records follow a physician |
US10817964B2 (en) | 2008-05-29 | 2020-10-27 | The Quantum Group, Inc. | System and method for making patient records follow a physician |
US11501393B2 (en) | 2008-05-29 | 2022-11-15 | The Quantum Group, Inc. | System and method for making patient records follow a physician |
US11095640B1 (en) | 2010-03-15 | 2021-08-17 | Proxense, Llc | Proximity-based system for automatic application or data access and item tracking |
US20110241823A1 (en) * | 2010-04-02 | 2011-10-06 | Anders Paul B | Tag-based personalization |
US8421594B2 (en) * | 2010-04-02 | 2013-04-16 | Intel Corporation | Tag-based personalization |
US11546325B2 (en) | 2010-07-15 | 2023-01-03 | Proxense, Llc | Proximity-based system for object tracking |
US11669701B2 (en) | 2011-02-21 | 2023-06-06 | Proxense, Llc | Implementation of a proximity-based system for object tracking and automatic application initialization |
US11113482B1 (en) | 2011-02-21 | 2021-09-07 | Proxense, Llc | Implementation of a proximity-based system for object tracking and automatic application initialization |
US11132882B1 (en) | 2011-02-21 | 2021-09-28 | Proxense, Llc | Proximity-based system for object tracking and automatic application initialization |
US20130080234A1 (en) * | 2011-09-26 | 2013-03-28 | National Bankcard Services, Inc. | Method of targeting consumers for up-selling based on purchasing history |
US10305775B2 (en) * | 2012-11-05 | 2019-05-28 | Cercacor Laboratories, Inc. | Physiological test credit method |
US11367529B2 (en) * | 2012-11-05 | 2022-06-21 | Cercacor Laboratories, Inc. | Physiological test credit method |
US9787568B2 (en) * | 2012-11-05 | 2017-10-10 | Cercacor Laboratories, Inc. | Physiological test credit method |
US20180069776A1 (en) * | 2012-11-05 | 2018-03-08 | Cercacor Laboratories, Inc. | Physiological test credit method |
US20140129702A1 (en) * | 2012-11-05 | 2014-05-08 | Cercacor Laboratories, Inc. | Physiological test credit method |
US20190386908A1 (en) * | 2012-11-05 | 2019-12-19 | Cercacor Laboratories, Inc. | Physiological test credit method |
US11914695B2 (en) | 2013-05-10 | 2024-02-27 | Proxense, Llc | Secure element as a digital pocket |
US10909229B2 (en) | 2013-05-10 | 2021-02-02 | Proxense, Llc | Secure element as a digital pocket |
US10856750B2 (en) | 2017-04-28 | 2020-12-08 | Masimo Corporation | Spot check measurement system |
US20180367670A1 (en) * | 2017-06-20 | 2018-12-20 | OpenPath Security Inc. | Virtual Office Receptionist |
US10666799B2 (en) * | 2017-06-20 | 2020-05-26 | OpenPath Security Inc. | Virtual office receptionist |
US11837341B1 (en) * | 2017-07-17 | 2023-12-05 | Cerner Innovation, Inc. | Secured messaging service with customized near real-time data integration |
US20200058032A1 (en) * | 2018-08-20 | 2020-02-20 | Denikumar Dalpatbhai Lad | Biometric Payment Transaction Without Mobile or Card |
Also Published As
Publication number | Publication date |
---|---|
US20100280844A1 (en) | 2010-11-04 |
US7992780B2 (en) | 2011-08-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7992780B2 (en) | Secure identification of dependants | |
US11101026B2 (en) | Schedule-based electronic medical record modules, applications, and uses thereof | |
US20170300643A1 (en) | Systems for facilitating user engagement and behavior to improve health outcomes | |
US20190237203A1 (en) | Facilitating self-scheduling of medical appointments | |
US20090281825A1 (en) | Automated patient flow management system | |
CN101528117A (en) | Patient information management method | |
US20110073644A1 (en) | Network for blood pressure data management and rechargeable smart card | |
US7979294B2 (en) | System and method for providing decision support to appointment schedulers in a healthcare setting | |
US20190362828A1 (en) | Systems and methods for electronic prescriptions | |
Mehl et al. | Harnessing mHealth in low-resource settings to overcome health system constraints and achieve universal access to healthcare | |
JP2016048553A (en) | Medical/health information unitary management system using common patient id number | |
Abo Hamad et al. | Towards leaner healthcare facility: application of simulation modelling and value stream mapping | |
US20160027138A1 (en) | Automated Patient Flow Management Systems | |
CN109565503A (en) | Optimize the system and method that user participates in person for being based on patient context, user role, work at present process and the display degree of approach | |
US20120253849A1 (en) | System and method for standardizing electronic registration | |
Bullard et al. | Evaluating mental health court by impact on jurisdictional crime rates | |
US20050086073A1 (en) | System and method for storing and retrieving medical directives | |
KR20130089993A (en) | Reservation method and system for inspection | |
WO2002052483A2 (en) | System and method for integration of health care records, and for a seamless user interface, for an integrated electronic health care information system | |
US20210097473A1 (en) | Mobile scheduling system | |
JP4489728B2 (en) | Method and program for providing medical / pharmaceutical related information | |
US20240046220A1 (en) | Customer Experience Interface for Integrated Practice Management Solutions | |
US20240047023A1 (en) | System and method for facilitating management of medical and immunization history of users | |
Tufail | Online polyclinic and database management system | |
WO2023192294A1 (en) | Guest-facing game information management systems and methods |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EPIC SYSTEMS CORPORATION, WISCONSIN Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:LARSEN, STEVEN J.;REEL/FRAME:019406/0330 Effective date: 20070606 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |