Abstract:
The embodiments of the present invention relate to an electronic transfer and storage system implemented in a medical records environment or application using a card with memory capabilities and biometric (includes finger, palm, iris, facial photo, scent, voice recognition and other biometric attributes) data to authenticate the account holder (patient, nurse, Doctor, Pharmacist, EMS or EMT). With such a card, reader and system, a patient is able to be enrolled with a physician using biometric input for authentication.

Description:
RELATED APPLICATIONS 
       [0001]    The present application claims priority to U.S. Provisional Patent Application Ser. No. 61/361,813, filed Jul. 6, 2010, which is hereby incorporated by reference in its entirety. 
     
    
     FIELD OF INVENTION 
       [0002]    The present invention relates generally to providing secured access to private information, and more particularly, to a system and method for storing private information on a portable storage device controllably providing access thereto by authorized users. 
       BACKGROUND OF INVENTION 
       [0003]    In today&#39;s world, providing secure access to only authorized users, while restricting access from unauthorized users is increasingly important. 
         [0004]    For example, in today&#39;s medical industry or profession a patient&#39;s care is limited to a Doctor&#39;s and or other medical professional&#39;s ability to access the patient&#39;s medical records. The most popular means of accessing a patient&#39;s medical records isn&#39;t so popular or convenient. In many cases accessing a patient&#39;s medical records may involve engaging legal services. 
         [0005]    The Department of Health and Human Services (HHS) enacted the Health Insurance Portability and Accountability ACT of 1996 (HIPAA) to insure that personal information stored, accessed, or posses adheres to a set of guidelines or “security rules”. These rules outline security measures that should be implemented to secure all electronic protected health information (EPHI). The Secretary of Health and Human Services enforces this law. Non-compliance can lead to civil monetary penalties and public distrust. The collection, management, and analysis of log data is integral to meeting HIPAA requirements. 
         [0006]    There is also a set of international standards. Health Level Seven (HL7), the most commonly used health care standard in the world, is an international health care standard for the exchange, integration, sharing, and retrieval of electronic health information, which support clinical practice and the management, delivery, and evaluation of health services. 
         [0007]    Presently, medical records are not portable. It is impossible to directly share information about a patient&#39;s history. If a patient is seeing more than one physician, one physician may not be aware of the existence of the other physician, and what is being treated. This can cause tests to be duplicated. Treatments can run counter to each other. Drugs can be prescribed that have dangerous interactions. Doctors can be shopped for prescriptions. Pharmacies may not be able to clearly read prescriptions, leading to incorrectly filled prescriptions. Prescription forms can be forged or stolen. Payments to doctors can be delayed or not made at all. Unscrupulous providers can bill for non-existent patients or double bill for patients. 
         [0008]    There are electronic medical record systems available right now, but they are not portable and do nothing to solve security problems. They exist primarily to make the Doctor&#39;s office operate more efficiently. Emergency responders, whether they are Doctor&#39;s or EMS or EMT personal, have no information regarding the patient. 
         [0009]    Thus, there is a need for a portable medical card, reader and system that is compliant with the Health Insurance Portability and Accountability ACT of 1996 (HIPAA) to secure all electronic protected health information (EPHI) and that complies with Health Level Seven (HL7). 
       SUMMARY OF THE INVENTION 
       [0010]    In a first aspect of the present invention, biometric data (finger, palm, iris, facial photo, scent, voice recognition and other biometric attributes) may be used to authenticate a patient to allow access to his or her medical records. 
         [0011]    In a second aspect of the present invention, biometric data may be used to authenticate a Doctor to allow access to a patient&#39;s medical records. 
         [0012]    In a third aspect of the present invention, biometric data may be used to authenticate a Pharmacist to allow access to a patient&#39;s medical records. 
         [0013]    In a fourth aspect of the present invention, biometric data may be used to authenticate a Registered Nurse, or other qualified medical professional, to allow access to a patient&#39;s medical records. 
         [0014]    In a fifth aspect of the present invention, biometric data may be used to authenticate any of the above mentioned professionals or any combination of the above mentioned professionals to allow access to a patient&#39;s medical records. 
         [0015]    In a sixth aspect of the present invention, biometric data may be used to authenticate a patient to allow access to his or her medical records by any of the above mentioned professionals or any combination of the above mentioned professionals. 
         [0016]    In a seventh aspect of the present invention, biometric data may be used to authenticate a patient to allow access to his or her medical records by any of the above mentioned professionals or any combination of the above mentioned professionals and using biometric data to authenticate any of the above mentioned professionals or any combination of the above mentioned professionals to allow access to a patient&#39;s medical records. 
         [0017]    In a seventh aspect of the present invention, biometric data may be used to authenticate a patient to allow access to his or her medical records by any of the above mentioned professionals or any combination of the above mentioned professionals and using biometric data to authenticate any of the above mentioned professionals or any combination of the above mentioned professionals to allow access to a patient&#39;s medical records, that comply with the Health Insurance Portability and Accountability ACT of 1996 (HIPAA) to insure that personal information stored, accessed, or posses that adheres to the set of guidelines or “security rules” that outline security measures that should be implemented to secure all electronic protected health information (EPHI). 
         [0018]    In an eighth aspect of the present invention, biometric data may be used to authenticate a patient to allow access to his or her medical records by any of the above mentioned professionals or any combination of the above mentioned professionals and using biometric data to authenticate any of the above mentioned professionals or any combination of the above mentioned professionals to allow access to a patient&#39;s medical records, that comply with Health Level Seven&#39;s (HL7) international standards. 
         [0019]    In a ninth aspect of the present invention, biometric data may be from an individual and or patient that is transferred from the individual and or patient to and through a biometric sensor or scanner, processor, biometric reader, card reader interface and card interface to a net-book or slate to a smart card and then also to a central office computer to a central database to the initial smart card. If the biometric data is required it will be requested by the card. 
         [0020]    In a tenth aspect of the present invention, data that is not web based may be used for authentication. 
         [0021]    In an eleventh aspect of the present invention, a method where the reader identifies itself to the card may be used. 
         [0022]    In a twelfth aspect of the present invention, a method where the card identifies itself to the reader may be used. 
         [0023]    In a thirteenth aspect of the present invention, a method where the type of reader used determines the level of memory access allowed may be used. 
         [0024]    In a fourteenth aspect of the present invention, a method where the code identifying a reader changes on each use may be used. 
         [0025]    In a fifteenth aspect of the present invention, a method where patient verification is done on the card, so that no verification information is exposed may be used. 
         [0026]    In a sixteenth aspect of the present invention, a method for the mutual authentication of a plurality of cards may be used. 
         [0027]    In a seventeenth aspect of the present invention, a method where the verification processor controls the biometric reader may be used. 
         [0028]    In an eighteenth aspect of the present invention, a method where the verification processor can request different types of biometric authentication may be used. 
         [0029]    In a nineteenth aspect of the present invention, a method where the verification processor controls the memory management processor may be used. 
         [0030]    In a twentieth aspect of the present invention, a method where multiple cards will authenticate themselves to each other before any display of information begins may be used. 
         [0031]    In a twenty-first aspect of the present invention, a method where the patient controls access to their personal records may be used. 
         [0032]    In a twenty-second aspect of the present invention, a method where different biometric authentications control the release of records may be used. 
         [0033]    In a twenty-third aspect of the present invention, a “Dog Tag” or basic identification memory may be used. 
         [0034]    In a twenty-fourth aspect of the present invention, the inclusion of a code for the last procedure performed in the enhanced Dog Tag information may be used. 
         [0035]    In a twenty-fifth aspect of the present invention, an enhanced “Dog Tag” memory for EMT/EMR technicians, which shows a synopsis of the patient&#39;s records without exposing the complete underlying records, may be used. 
         [0036]    In a twenty-sixth aspect of the present invention, a prescription record that shows the patient&#39;s prescription history can be viewed by a pharmacist, may be used. 
         [0037]    In a twenty-seventh aspect of the present invention, a method of electronically authenticating a prescription to a pharmacist may be used. 
         [0038]    In a twenty-eighth aspect of the present invention, the storage of a patient&#39;s complete medical history where access is controlled by the patient may be used. 
         [0039]    In a twenty-ninth aspect of the present invention, a secured mag-stripe that duplicates the “Dog Tag” function may be used. 
         [0040]    In a thirtieth aspect of the present invention, a 2D or 3D barcode which contains the basic “DOG Tag” information that can be read by a smart phone or barcode reader may be used. 
         [0041]    In a thirty-first aspect of the present invention, a method where the device, card or reader verifies its physical integrity may be used. 
         [0042]    In a thirty-second aspect of the present invention, a method where the device, card or reader verifies its software integrity may be used. 
         [0043]    In a thirty-third aspect of the present invention, a method where the device, card or reader authenticates itself to a base station may be used. 
         [0044]    In a thirty-fourth aspect of the present invention, a method where the device, card or reader authenticates to other base stations, may be used. 
         [0045]    In a thirty-fifth aspect of the present invention, a method where a doctor can access a patients records remotely may be used. 
         [0046]    In a thirty-sixth aspect of the present invention, a method where a reader identifies itself to a card may be used. 
         [0047]    In a thirty-seventh aspect of the present invention, a method where a reader identifies itself to a base station may be used. 
         [0048]    In a thirty-eighth aspect of the present invention, a method where a reader authenticates itself to a patient&#39;s card may be used. 
         [0049]    In a thirty-ninth aspect of the present invention, a method where a reader authenticates itself to a doctor&#39;s card may be used. 
         [0050]    In a fortieth aspect of the present invention, a method where a reader authenticates itself to a hospital card may be used. 
         [0051]    In a forty-first aspect of the present invention, a method where a readers identity sets its functionality may be used. 
         [0052]    In a forty-second aspect of the present invention, a method for providing access to information stored on a portable storage device via a reader device is provided. The portable storage device stores information including user data associated with a user. The user data has a first portion and a second portion. The first portion is of a basic type and the second portion being of a second type. A storage device controller is located within the housing and is coupled to the memory storage. The method includes the following steps:
       allowing the portable storage device to be inserted into a reader device;   sending a reader identification code from the reader device to the portable storage device in response to the portable storage device being inserted into the reader device;   receiving the reader identification code at the storage device controller, authenticating the reader device if the reader identification code is valid, and responsively ejecting the portable storage device if the reader identification code is not valid;   sending a portable storage device identification code from the portable storage device to the reader device;   receiving the portable storage device identification code at the reader device, authenticating the portable storage device if the portable storage device identification code is valid, and responsively ejecting the portable storage device if the portable storage identification code is not valid; and,   if the reader identification code and the portable storage device identification code are valid:
           providing access to the first portion of the user data stored on the portable storage device; and,   receiving a request for the second portion of the information stored on the reader device by a requesting user, responsively requiring biometric authentication of the requesting user, and responsively providing access to the second portion of the user data stored on the portable storage device if the requesting user is authenticated.   
               
 
         [0061]    In a forty-third aspect of the present invention, a method for providing access to medical records associated with a patient stored on a portable storage device via a card reader is provided. The card includes a memory storage for storing information. The medical records are associated with a user. The medical records has a first portion and a second portion. The first portion is of a basic type and the second portion is of a second type. A storage device controller is located within the housing and is coupled to the memory storage. The method includes the steps of:
       allowing the card to be inserted into the card reader;   sending a reader identification code from the card reader to the card in response to the card being inserted into the card reader;   receiving the reader identification code at the storage device controller, authenticating the card reader if the reader identification code is valid, and responsively ejecting the card if the reader identification code is not valid;   sending a card identification code from the card to the card reader;   receiving the card identification code at the card reader, authenticating the card if the card identification code is valid, and responsively ejecting the card if the portable storage identification code is not valid; and,   if the reader identification code and the card identification code are valid:
           providing access to the first portion of the medical records stored on the portable storage device; and,   receiving a request for the second portion of the information stored on the card reader by a requesting user, responsively requiring biometric authentication of the requesting user, and responsively providing access to the second portion of the medical records stored on the card if the requesting user is authenticated.   
               
 
         [0070]    The embodiments of the present invention relate to an electronic transfer and storage system implemented in a medical records environment or application using a card with memory capabilities and biometric (includes finger, palm, iris, facial photo, scent, voice recognition and other biometric attributes) data to authenticate the account holder (patient, nurse, Doctor, Pharmacist, EMS or EMT). With such a card, reader and system, a patient is able to be enrolled with a physician using biometric input for authentication. The current art uses separate devices for biometric data entry, data display handwriting capture, secured bi-directional wireless communication and user authentication with limited or no device security. 
         [0071]    Accordingly, a first embodiment of the present invention is a secure biometric system including a medical card with memory capabilities and reader with authentication and transfer capabilities, that makes medical records portable. 
         [0072]    This invention combines the biometric data entry, data display and handwriting capture functions, with functions for device security, data encryption and decryption, mutual authentication of the doctor, patient, local wireless network and the wired network for communication with a remote base station within a single hand-held device. Other versions of this device may omit the handwriting capture, biometric data entry, user authentication and secure network communication functions. 
         [0073]    The patient&#39;s complete history would be available to any physician. This would eliminate duplicated test. Treatments can run parallel with each other and work together. Since the patient&#39;s prescription history would be available the dangerous drug interactions can be reduced. The shopping of doctors can be reduced. Since prescription forms would not be used fraudulent prescriptions can be eliminated. The problem of pharmacies not being able to read prescriptions would be eliminated. Billing would be done at the time of the visit. This allows the doctor to be paid faster, and it also eliminates multiple billing and billing for non-existent patients. Since the records portable emergency responders would have information regarding the patient&#39;s blood type, allergies, and special conditions. 
         [0074]    The SASI Med Card is unique in that it is not a web based solution, but a secured smart card solution. This card would hold all of a person&#39;s medical records in a bio-metrically secured fashion. The patient would maintain complete control over who has access to their detailed personal data. Since is all the information is contained in a card that the person has control of, which is bio-metrically linked to the person, identity theft and unwanted probing are virtually impossible. With a web based solution, theft and unwanted probing would be relativity easy. There is still a central data repository, but it is not on the web and would only be used as a backup if a card is damaged, lost or stolen. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0075]    Other advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings wherein: 
           [0076]      FIG. 1A  is a graphical representation of a first side of a portable storage device in the form of a card, according to an embodiment of the present invention; 
           [0077]      FIG. 2A  is a graphical representation of a second side of the portable storage device of  FIG. 1A ; 
           [0078]      FIG. 2  is a block diagram of a system for providing access to information stored on a portable storage device, according to an embodiment of the present invention; 
           [0079]      FIG. 3A  is a block diagram of a portable storage device, according to an embodiment of the present invention; 
           [0080]      FIG. 3B  is a block diagram of a reader device, according to an embodiment of the present invention; 
           [0081]      FIG. 4  is a diagrammatic illustration of a system for storing private information on a portable storage device and a reader of a first type for controllably providing access thereto, according to an embodiment of the present invention; 
           [0082]      FIG. 5  is a diagrammatic illustration of a system for storing private information on a portable storage device and a reader of a second type for controllably providing access thereto, according to an embodiment of the present invention; 
           [0083]      FIG. 6  is a diagrammatic illustration of a system for storing private information on a portable storage device and a reader of a third type for controllably providing access thereto, according to an embodiment of the present invention; 
           [0084]      FIG. 7  is a diagrammatic illustration of a system for storing private information on a portable storage device and a reader of a fourth type for controllably providing access thereto, according to an embodiment of the present invention; 
           [0085]      FIG. 8  is a flow diagram of a method for providing access to private information storage on a portable storage device, according to an embodiment of the present invention; 
           [0086]      FIG. 9  is a first flow diagram of a method for providing access to private information storage on a portable storage device, according to an other embodiment of the present invention; 
           [0087]      FIG. 10  is a second flow diagram of the method of  FIG. 9 ; 
           [0088]      FIG. 11A  is a first portion of a third flow diagram of the method of  FIG. 9 ; 
           [0089]      FIG. 11B  is a second portion of the third flow diagram of the method of  FIG. 9 ; 
           [0090]      FIG. 12A  is a first portion of a flow diagram of a method for initializing a reader device, according to an embodiment of the present invention; and, 
           [0091]      FIG. 12B  is a second portion of the flow diagram of  FIG. 12A . 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0092]    With reference to the drawings, and in operation, the present invention provides a system  10  and method  80 ,  90 ,  100 ,  110 ,  120  for securely storing and providing access to information. 
         [0093]    In one aspect of the present invention, the information is stored on a portable storage device  12 . In one embodiment the portable storage device  12  is in the form of a card  12 . The card  12  generally, may be similar in size to a credit card or smart card. 
         [0094]    The information stored in the system  10  may, in general, be any type of data which the user may want to be secured or kept private, and to which limited persons have access thereto. For example, the information secured by the present invention may include medical information or records. Specifically, in the disclosed embodiment, the portable storage device  12 , which is in the form of a card, is associated with a patient (not shown). The patient&#39;s card  12  is generally kept and maintained by the patient, and carries that patient&#39;s medical records. 
         [0095]    With particular reference to  FIGS. 1A ,  1 B, and  3 A, the portable storage device  12  has a housing  14 . The housing  14  has a first side  14 A shown in  FIG. 1A  and a second side  14 B shown in  FIG. 1B . The first side  14 A includes a portable storage device interface  20 , which in the illustrated embodiment, is in the form of a plurality of electrical contacts  20  (see below). The second side  14 B includes a machine readable code  22 , such as a barcode or a QR code, which can be read by standard (barcode or QR) readers to obtain limited medical record data. This limited medical record may be referred to as “dog tag data or dog tag level data”. 
         [0096]    It should be noted that the portable storage device or card  12  may be used as a secured ID card and may be used to replace existing paper or plastic ID cards. 
         [0097]    As discussed more fully below, the portable storage device  12  may be read by a specialized reader device  30 . With particular reference to  FIGS. 2 and 3B , the reader device  30  generally includes a reader  42  for reading the data or information from the portable storage device  12 . Authentication for access to secured information is provided through a biometric reader  44 . 
         [0098]    The biometric reader  44  may include one or more biometric sensors  46  for sensing a biometric parameter of a user, such as a fingerprint  46 A, voice  46 B, or iris of the eyeball  46 C of the user. A display interface  38  couples the reader  42  to a display  40 . Data related to the sensed biometric parameter of the user is transferred from the sensor  46  to a reader controller  36 , then transferred to the portable data storage device  12  through the card reader interface  34 . The reader controller  36  may include a processor  36 A. 
         [0099]    In general, once a user is authenticated by a comparison of the sensed biometric parameter with access template data  16 E, some of the information stored on portable storage device  12  is transferred to the reader device  30  and displayed on the display  40 . 
         [0100]    With particular reference to  FIG. 3A , the portable storage device  12  includes a controller  18  which communicates to the reader  30  via the card interface  20 . The portable storage device  12  includes memory  16 ,  16 A,  16 B,  16 C,  16 D for storing the information and one or more access templates  16 E. The access templates  16  are biometric templates which are compared with the data from the biometric sensor  46  to confirm or authorize the user (see below). 
         [0101]    The memory  16  may be dedicated or shared memory. In the graphical illustration of  FIG. 3A , the memory  16  is represented by memory 1  16 A, memory 2  16 B, memory 3  16 C, and memory 4  16 D. Each representation  16 A,  16 B,  16 C,  16 D may be associated with a specific data type, but may or may not represent an actual, physical predetermined memory locations. The memory  16  may be embodied in a single memory device or several devices. In one embodiment different portions of the data may be stored in dynamically allocated portions of the memory  16 . 
         [0102]    The controller  18  and memory  16  are generally contained within the portable storage device housing  14 . The controller  18  controls access to the memory  16 , i.e., reads the information from the memory  16  and provides to the reader device  30 , and compares the biometric data from the reader device  30  with the template data  16 E. In the illustrated embodiment, the controller  18  includes a first processor  18 A and a second processor  18 B. The first processor  18 A reads and writes to memory  16 A,  16 B,  16 C,  16 D, while the second processor  18 B accesses memory  16 E and authenticates the user by comparing the biometric data with the template data  16 E. It should be noted, however, that the controller  18  may include a single processor. 
         [0103]    With reference to  FIG. 4 , a graphical illustration of the system  10  includes a card  12  and the reader  30 , according to a first embodiment of the present invention. 
         [0104]    In general, the card  12  may include multiple types of data, each of which may require a different type or level of authentication. In other words, each level or type of data may be accessed by authorized levels of an associated levels. Higher levels of users may, however, access lower levels of types of data. 
         [0105]    In one embodiment, when the card  12  is inserted into the reader device  30 , contact is made through the card interface  34 , which provides electrical power to the storage device  12 . The reader controller  36  then provides its identification (ID code) to the storage device controller  18 , which then sets the access level on the storage device controller  18  or memory processor  18 A based on information stored on access template  16 E. The memory processor  18 A accesses the identified memory  16 A,  16 B,  16 C,  16 D and transfers the associated information over the card interface  20  to the reader device  30 , which then transfers the encrypted data to the display device  40  via the connection  34 . 
         [0106]    If a higher level of access is required, the portable storage device controller  18  sends a request for biometric information over the card interface  20  via the card reader interface  34  to the reader controller  36  which enables the biometric reader  44 . The biometric information entered through the biometric sensor(s)  46  is streamed through the controller  36  via the card interface  34  to the storage device controller  18  where it is verified against the access template  16 E, which then sets the access level on storage device controller  18  for memory 1, memory 2, memory 3, an memory 4  16 A,  16 B,  16 C,  16 D. 
         [0107]    In one embodiment, information transferred and communication between the storage device  12  and the reader device  30  is encrypted. 
         [0108]    The reader device  30  shown in  FIG. 4 , may be setup or configured to be used by any type or level of user. Every authorized user would have template data stored in memory  16 E. Unauthorized users may be able to access the basic data, i.e., the dog tag data. Authorized users may be added to the access templates  16 E, generally with the authorization of the patient. For example, if the patient goes to new doctor&#39;s office, the templates for the authorized users at the new doctor&#39;s office may be downloaded and stored in the access templates portion of memory  16 . It should be noted that each of the new authorized users would have a specified or associated level or type which provides an appropriate level of access to the information. For example, an accounting or administrative user may have access to insurance information stored on the device  12 , while an admitting nurse may have access to the insurance information and a first level of secured medical information. The doctors in the new office may have access to the first level of secured medical information and a second level of secured medical information. All users may have access to the basic or dog tag level of information. 
         [0109]    With specific reference to  FIG. 8 , in one embodiment of the present invention a method  80  provides access to the information stored on a portable storage device  12 . For purposes of discussion, the information stored on the portable storage device  12  is divided into two portions. The first portion is of a defined first type or level and includes the basic information or the dog tag information. The first portion may include additional information, as well. The second portion is of a defined second type or level and includes secured information which may only be accessed by an authorized user. 
         [0110]    Returning to  FIG. 8 , in a first step  80 A, the portable storage device  12  is inserted into the reader device  30 . The reader device  30  sends a reader identification code to the portable storage device  12  in response to the portable storage device  12  being inserted into slot  13  of the reader device  30  in step  80 B. 
         [0111]    The reader identification code is received at the storage device controller  18  where the reader device  30  is authenticated if the reader identification code is valid in step  80 C. If the ID Code is not authentic (step  80 D) then the portable storage device  12  is ejected (step  80 E). 
         [0112]    If the ID Code is authentic, then in step  80 F, the portable storage device  12  sends a storage device identification code to the reader device  30 . In decision block  80 H, if the storage device ID code is not valid, then the storage device is ejects (step  80 E). If the storage device ID card is valid, then the method  80  proceeds to step  80 I. 
         [0113]    In step  80 I, a request for access is received by the storage device  12 . The request may be generated automatically by the reader device  30  in response to authentication of both ID Codes, an may be generated based on some input from the user on the reader device  30 . 
         [0114]    In a decision block  80 J, if the request is for the first portion of the data (only), then access to the first portion if provided in step  80 K. In one embodiment once access is provided it is viewable on the display  40 . The display  40  may include a touchscreen device for providing a user interface for navigating through the information or data. Alternatively, or in addition, the reader device  30  may include one or more buttons (not shown) for implementing a user interface which may be used to send data requests, as well as to navigate through the data displayed on the display  40 . 
         [0115]    In the illustrated embodiment, access to the first portion of the stored information is provided as long as the reader device  30  is valid. 
         [0116]    If the request for data is for the second portion of the data, then a request for biometric authentication is sent from the portable storage device  12  to the reader device  30 . The reader device  30  then instructs the user to provide the biometric data via the biometric reader  44 . If the user is a valid user, i.e., is of the correct type or level to access the second portion of the data, then access to the second portion is provided in step  80 O. 
         [0117]    While the above method  80  only discusses first and second data portions (having different types), it should be noted that additional data portions may be provided. Each additional data portion may have an associated level or type required to access. Also, a particular level or type of user may be able to access not only the associated data portion, but may also be able to access one or more of the other data portions. 
         [0118]    In one aspect of the present invention, the portable storage device  12  may be adapted to receive or accept additional information from the user which may then be sent to, and stored on the portable storage device  12 . The portable storage device  12  may include a user interface  13 , which, for example, may be implemented by the touchscreen device. The user interface  13  may include a virtual keyboard (not shown), or may accept handwritten notes (input using a stylus  41 ), or even audio notes. The additional information may be stored in one of the portions of the data based on the type of information and/or the type or level of user. 
         [0119]    As discussed above, the reader device  30  shown in  FIG. 4  is a general device which may be used by any type of user. It requires only a single portable storage device  12 , generally, the patient&#39;s device  12  to operate. In general, all of the access templates for all authorized users are stored in memory  16  on the device  12 . However, it should be noted that the access templates may be stored off the device  12 , for example, on a server which the device  12  may access. 
         [0120]    Additionally, it should be noted that the reader  30  may have different forms. Several alternative forms  30 ′,  30 ″ are shown in  FIGS. 5 ,  6 , and  7 . 
         [0121]    Additionally, the reader  30 ,  30 ′,  30 ″ may require a second storage device  12 B′,  12 B″ for user authentication. 
         [0122]    Lastly, it should be noted that the various forms of the reader  30 ′,  30 ′,  30 ″ may be adapted to require only the first or patient&#39;s card or to require both cards. 
         [0123]    With particular reference to  FIG. 5 , an enhanced reader device  30 ′ (Reader Type 2), according to an embodiment of the present invention. The enhanced reader device  30 ′ could be, for example, be issued to, and used by, EMT personnel. To use the enhanced device  30 ′, a technician portable storage device or card  12 B′ is inserted into slot  13 B′ and after power on authentication is complete see below), the technician is authenticated and the device  30 ′ is unlocked and ready for a patient&#39;s card  12 A′. 
         [0124]    When a patient&#39;s card  12 A′ is inserted into the remaining slot  13 A′ the card  12 A′ is authenticated (see below) and a session begins. During the session, enhanced patient data is displayed on the display screen  40 . When one of a plurality of keys  15  is pressed the session is ended (and the respective device  12 A′,  12 B′ ejected). When a session ends the display  40  information is cleared and the respective device  12 A′,  12 B′ ejected. It should be noted that in one embodiment, either device  12 A′,  12 B′ may be inserted into either slot  13 A′,  13 B′. 
         [0125]    With particular reference to  FIG. 6 , a “Reader Type 3” or slate reader  30 ″ is shown. To use the slate reader  30 ″, a doctor or pharmacist card  12 B″ is inserted into either slot  13 A′,  13 B′ and after power on authentication (see below), the doctor or pharmacist is authenticated using the biometric data from reader  30 ″ and the device  30 ″ is unlocked and is ready for a patient card  12 A′. 
         [0126]    When a patient card  12 A′ is inserted into the remaining slot  13 A′,  13 B′, the card  12 A′ is authenticated and a session. During the session, data is displayed on the display  40  and new data is entered using the user interface, for example, by writing on the display screen  40  using stylus  41 . Functions for entering prescriptions or communication with associated devices can be selected using one of a plurality of soft keys  43 . When a session ends the screen information is captured along with any other information and is saved to the device  12 A″ and transmitted to a base station  45  over a wireless connection. Then the patient&#39;s card  12 A″ is ejected from the “Slate” reader  30 ″ and returned to the patient. 
         [0127]    With respect to  FIG. 6 , in another aspect of the present invention, a Reader Type 4 or remote reader device  30 ′″ may be used along with another reader, such as a slate reader  30 ″ to allow a doctor to access and review a patient&#39;s records at hospital or other remote location. 
         [0128]    To allow remote access a patient would insert their card  12 A′″ into slot  13 C of reader  30 ′″ after power on authentication is complete. The doctor would insert their card  12 B′″ into a slate reader  30 ″ and then press a dedicated function button after power on authentication is complete. This would begin a wireless reader  30 ″ to its base station  45 B authentication process. Once the reader  30 ″ is authenticated to its base  45 B it would send the location of the remote base  45 A to its base  45 B. Base  45 B would then begin the authentication process with the remote base  45 A via either a secure wireless or wired connection. 
         [0129]    During the connection process the status of the connection would be shown on the indicators  47  on remote device  30 ′″. Once the connection is complete authentication of the doctor and patient proceeds and a session begins. During this remote session the slate reader  30 ″ displays the patient&#39;s records for the doctor to review and annotate. All transmission between the “devices  30 ′,  30 ′″ are encrypted and conform to HIPPA regulations. 
         [0130]    With reference to  FIG. 9 , a method  90  of operating the system  10 , according to another embodiment of the present invention will now be discussed. In a first step  90 A, a portable storage device  12 ,  12 ′,  12 ″ in the form of a smart card is inserted into the reader  30 ,  30 ′,  30 ″,  30 ′″. In the discussion below, unless stated otherwise, reference numbers  12  and  30  will refer to any one of the cards  12 ,  12 ′,  12 ″ or devices  30 ,  30 ′,  30 ″,  30 ′″. 
         [0131]    Once inserted into the reader  30 , the card  12  is powered up, and after completing its power on sequence, sends its ID information to the reader  30 . 
         [0132]    In one embodiment, the ID would be a string with a sequence number or access count with an embedded hash over the string and sequence or count and encrypted with the reader public key. All readers  30  would use a common public/private key pair, and the same would also apply to all cards. 
         [0133]    In step  90 C, the reader  30  decrypts the received string with its private key, and compares the string value to a list of known responses. A hash of the string over the string and sequence or count would also be done and compared with hash received in the message. 
         [0134]    In decision block  90 D, if the response and hash are both correct, the card  12  is authentic and execution proceeds to step  90 F. Otherwise the card  12  is ejected from the device at step  90 E. 
         [0135]    In step  90 F, the process now repeats, but with the reader  30  sending an ID string with a sequence number or access count with the hash done over the string and sequence or count. The string, sequence or count and hash are encrypted with the cards public key and sent to the to the card. 
         [0136]    In step  90 G, the card  12  decrypts the received string with its private key, and confirms that the string received is valid, and that the hash over the string and sequence or count is valid. 
         [0137]    In decision block  90 H, if the string and hash values are valid, execution proceeds to  90 J otherwise, the card  12  would shut down and be ejected from the reader device  30 . 
         [0138]    In step  90 J, the card  12  then requests the readers type, basic, enhanced, etc. The reader types are separate from the authentication strings, and may either be strings or numeric values. This information is used by the card to determine the data the card will allow access too. All requests and responses between the card and reader are encrypted. The same key pairs that were used in the authentication could be used, but the preferred method would use a different key, or method than that used in the authentication process. 
         [0139]    This method would be used in all subsequent transactions. 
         [0140]    In step  90 K, if the reader is a type 1 (basic), the card will send basic patient information to the reader (step  90 L). This response would be encrypted as mentioned above. 
         [0141]    In one embodiment, the ‘dog tag’ information would consist of the name, blood type, and any known conditions the patient may have; Diabetes, epilepsy, drug allergies etc. Note: This information may also be encoded in the form of a QR code that would be printed on the back of the card, for reading by smart phone devices with the proper software installed, if a reader is not available. 
         [0142]    The reader  30  would then decrypt this information and display it on the readers screen  40  in step  90 M. 
         [0143]    In decision block  90 N if the device  12  is a reader type 2 device, the method decrypt this information and display it on the readers screen  40  in step  90 O. This type 2 or enhanced reader would display all of the type 1 or basic information, but would also expand on that to show active prescriptions doctor information or conditions not allowed in the type 1 display. 
         [0144]    In decision block  90 P if the device  12  is a reader type 3 device, the method proceeds to step  90 Q. The type 3 or doctor device, would be capable of accessing the entire patient treatment history. This history would include medications prescribed, x rays, treatments by other doctors etc. While the other readers are read only devices, this device has the capability to write updated records to the card. 
         [0145]    In step  90 R, the session ends when the card is ejected. 
         [0146]    With respect to  FIG. 10 , operation of the Type 2 or enhanced reader  30 ′ will now be discussed. Card 1 and first card refer to the patient card  12 A′. Card 2 and second card refer to the technicians or nurses card  12 B′. 
         [0147]    Once the hardware authentication is complete (see below), the cards  12 A′,  12 B′ will authenticate themselves to each other. This starts with the first card  12 A′ sending an encrypted ID string with a sequence number or access count with an embedded hash over the string and sequence or count (step  100 A). The common card key pair will be used for all transactions. The reader in these transactions only serves as a communication bridge for the authentication. 
         [0148]    In decision block  100 B, if the second card  12 B′ successfully decrypts and decodes the ID sent by the first card  12 A′, it begins the authentication process with the first card  12 A′ being the authenticator. 
         [0149]    If authentications fails though, the second card  12 B′ instructs the device to shutdown and eject the first card  12 A′ (steps  100 C,  100 D). 
         [0150]    In step  100 E, the second card  12 B′ authenticates to the first card  12 A′. This process is the same as the process used with the first card  12 A′. The second card  12 B′ sends an encrypted ID containing a string, a sequence number or count and a hash over the string and numeric value. 
         [0151]    In decision block  100 F, if the first card  12 A′ successfully decrypts and decodes the ID sent by the second card  12 B′ execution proceeds to  100 I otherwise execution proceeds to  100 G. 
         [0152]    In step  100 G, the first card  12 A′ instructs the device  30  to shutdown and eject the second card  12 B′ (steps  100 G,  100 H). 
         [0153]    Now, since hardware and card authentication is complete, the first card can begin uploading the enhanced patient data to the reader (step  100 I). 
         [0154]    In step  100 J, the reader  30 ′ decrypts the data stream from the first card  12 A′ and the data is displayed on the display  40  (step  100 K). 
         [0155]    After decrypting the data stream and displaying, it the device waits for an eject pressed (decision block  100 L). 
         [0156]    Once an eject button has been depressed, in decision block  100 M, if the source of the eject event, was the first card  12 A′, then the display  40  (and its buffer) is cleared and the first card  12 A′ is ejected (step  100 N). 
         [0157]    If the source was from the second card  12 B′, then the display  40  (and its buffer) is cleared and both cards  12 A′,  12 B′ are ejected (step  100 O) and the device  30 ′ is shutdown (step  100 P). 
         [0158]    With reference to  FIGS. 11A and 11B , operation of a type 3 or slate reader  30 ″ will now be discussed (method  110 ). Card 1 and first card refer to the patient card  12 A″. Card 2 and second card refer to the doctors or nurses card  12 B″. 
         [0159]    In step  110 A, once the hardware authentication is complete, the cards  12 A″,  12 A″ will authenticate themselves to each other. This starts with the first card sending an encrypted ID string with a sequence number or access count with an embedded hash over the string and sequence or count. The common card key pair will be used for all transactions. The reader in these transactions only serves as a communication bridge for the authentication. 
         [0160]    In decision block  110 B, if the second card  12 B″ successfully decrypts and decodes the ID sent by the first card  12 A″, it begins the authentication process with the first card  12 A″ being the authenticator. 
         [0161]    In step  110 C, if authentications fails though, the second card  12 B″ instructs the device  30 ″ to shutdown and eject the first card  12 A″ (step  110 D). 
         [0162]    In step  110 E, the process is the same as the process used with the first card  12 A″. The second card  12 B″ sends an encrypted ID containing a string, a sequence number or count and a hash over the string and numeric value. 
         [0163]    In decision block  110 F, if the first card  12 A″ successfully decrypts and decodes the ID sent by the second card  12 B″ execution proceeds to  110 I otherwise execution proceeds to  110 G. 
         [0164]    In step  110 G, the first card  12 A″ instructs the device  30 ″ to shutdown and eject card 2  12 B″ (step  110 H). 
         [0165]    Once all authentications (step  110 I) are complete, the first card  12 A″ instructs the device  30 ″ to enable the biometric reader on the device  30 ″ and to begin sending biometric information to the card  12 A″. 
         [0166]    In step  110 J, the first card  12 A″ then compares the received data to the templates it has stored. In step  110 K, if the received biometric data matches one of the stored templates, execution moves to step  110 M. If there is no match execution proceeds to step  110 L. 
         [0167]    In step  110 L, biometric authentication has failed, the card  12 A″ sends an eject signal to the device  30 ″, which shuts it down and ejects the card  12 A″. 
         [0168]    If biometric authentication was successful, the card  12 A″ now begins uploading the encrypted patient data (step  110 M). 
         [0169]    In step  110 N, the reader  30 ″ decrypts and displays the patient data (step  100 O). 
         [0170]    Once the initial patient data is uploaded and displayed, the doctor sessions begins. Here the doctor can move through the history of the patient. In addition to moving through the patients history the doctor can also include their own notes in the record, using voice, keyboard or stylus. These notes will be written to the card prior to the ending of the session (steps  110 P,  110 Q). The doctor enters any notes on the screen of the reader, using a keyboard, voice or pen. If a prescription is to be issued, the doctors goes to a prescription page, where the prescription information is entered. This page will also show the patients prescription history and indicate if any similar prescriptions were entered by other doctors. 
         [0171]    Once the prescriptions details are entered, the doctor electronically signs the prescription using authentication information from the second card  12 B″ (step  110 R). 
         [0172]    The prescription is then countersigned using authentication from the first card  12 A″ (step  110 S). 
         [0173]    In step  110 T, the doctor ends the session. The notes and any data entered during the session are captured and save in isolated storage on the card  12 A″ (step  110 U). 
         [0174]    The data captured in step  110 U is encrypted and sent to a base station for off site backup and is saved to the cards permanent record (step  110 V). 
         [0175]    With the session ended and all storage functions complete, the card sends an eject signal to the device ( 110 W). On receipt of the eject signal the device&#39;s display and its buffer and any temporary storage are cleared and the card is ejected. 
         [0176]    With reference to  FIGS. 12A and 12B , operation of a Type 3 reader/remote operation will now be discussed (method  120 ). The control card or card  2  refers to the doctors card  12 B′″. 
         [0177]    In step  120 A, the reader device  30 ″ is powered on, through a soft key or by plugging in a power connection. In step  120 B, the device  30 ″ powers the case tampering loops. These are conductive loops in the device case to detect physical tampering with the device. 
         [0178]    In step  120 C, if breaks are detected in the loops execution proceeds to  120 D, otherwise execution continues to  120 E. 
         [0179]    In step  120 D, the device  30 ″ turns its self off. 
         [0180]    In step  120 E, the loops were intact, power is switched to the rest of the device  30 ″. 
         [0181]    In step  120 F, the processor performs validation testing of the device&#39;s software. This validation would include all control code, and verification of temporary storage. 
         [0182]    In decision block  120 G, if the software successfully completed the validation procedure then proceed to  120 I otherwise proceed to  120 H. 
         [0183]    In step  120 H, the software or memory failed validation, the device turns its self off. 
         [0184]    In decision block  120 I, the presence of a control card  12 B′″ is checked for. If none is found, then the method  120  waits for a patient card (step  120 J). The patient card  12 A′″ would already be authenticated on its device  30 ′″. 
         [0185]    In step  120 K, once the control card  12 B′″ is inserted, the card  12 B′″ authenticates to its reader  30 ″ using a string and sequence number or access count hashed together and then the string sequence number or counter and the hash are encrypted using the reader common public key. 
         [0186]    In decision block  120 L, if the reader  30 ″ is successful in validating the card execution proceeds to  120 O, otherwise execution proceeds to  120 M. 
         [0187]    In step  120 M, If validation failed the reader  30 ″ shuts the card down and ejects it. 
         [0188]    In step  120 N, after ejecting the card  12 B′″, the device  30 ″ powers itself down. 
         [0189]    In step  120 O, after successfully validating the card  12 B″ the device  30 ″ then validates itself to the card  12 B″ using the same method as the card validation shown in step  120 K. 
         [0190]    In decision block  120 P, if the card  12 B″ is successful in validating the reader execution proceeds to  120 S, otherwise execution continues with  120 Q. 
         [0191]    In step  120 Q, validation was unsuccessful, thus, the card  12 B″ signals the device  30 ″ to shutdown and eject the card  12 B″. 
         [0192]    In step  120 R, after ejecting the card  12 B″, the device  30 ″ powers itself down. 
         [0193]    In decision block  120 S, the card queries the reader for its type. If it is a type 3 reader execution proceeds with  120 U. Otherwise execution proceeds to  120 T. 
         [0194]    In step  120 T, since the reader type is incorrect, the card  12 B″ sends an eject signal to the device  30 ″. The device  30 ″ then shuts the card down and ejects it. 
         [0195]    In step  120 U, since the device type is correct, the card instructs the device to enable the biometric reader on the device  30 ″ and to start sending sensed biometric data to the card  12 B″. 
         [0196]    In step  120 V, when the reader  30 ″ is finished sending data to the card  12 B″, it compares the received data to the templates stored on the card. 
         [0197]    In decision block  120 W, if the received biometric data matches a template stored on the card, execution proceeds to  120 Y. 
         [0198]    If the biometric data received does not match any of the stored templates, the card sends an eject signal to the device, shutting the card down and ejecting it (step  120 X). 
         [0199]    In step  120 Y, the biometric authentication was successful, so the card  12 B″ will instruct the device  30 ″ to unlock its display  40 . 
         [0200]    In step  120 Z, all of the local authentications and validations are complete. If patient data is available it is decrypted and displayed on the local device, otherwise wait for the stream from device  30 ′″. 
         [0201]    Any modifications and variations of the present invention are possible in light of the above teachings. The invention may be practiced otherwise than as specifically described within the scope of the appended claims.