Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
  • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
• • 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/22—Payment schemes or models
  • G06Q20/229—Hierarchy of users of accounts
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/357—Cards having a plurality of specified features
  • G06Q20/3576—Multiple memory zones on card
• • 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
  • G16H80/00—ICT specially adapted for facilitating communication between medical practitioners or patients, e.g. for collaborative diagnosis, therapy or health monitoring
• • B—PERFORMING OPERATIONS; TRANSPORTING
  • B42—BOOKBINDING; ALBUMS; FILES; SPECIAL PRINTED MATTER
  • B42D—BOOKS; BOOK COVERS; LOOSE LEAVES; PRINTED MATTER CHARACTERISED BY IDENTIFICATION OR SECURITY FEATURES; PRINTED MATTER OF SPECIAL FORMAT OR STYLE NOT OTHERWISE PROVIDED FOR; DEVICES FOR USE THEREWITH AND NOT OTHERWISE PROVIDED FOR; MOVABLE-STRIP WRITING OR READING APPARATUS
  • B42D25/00—Information-bearing cards or sheet-like structures characterised by identification or security features; Manufacture thereof
  • B42D25/20—Information-bearing cards or sheet-like structures characterised by identification or security features; Manufacture thereof characterised by a particular use or purpose
  • B42D25/28—Information-bearing cards or sheet-like structures characterised by identification or security features; Manufacture thereof characterised by a particular use or purpose for use in medical treatment or therapy

Definitions

• the present invention relates to a system and method for storing, managing, and retrieving healthcare information, more particularly, to a system and method for storing, managing, and retrieving healthcare information on a smart card.
• Some existing healthcare record systems use a patient ID card to locate patient's medical or health information stored in a care provider's own database.
• This type of ID card contains patient's general information, such as a patient's name, address, ID number, birthday, etc.
• the ID card does not contain any medical or health information.
• ID card is often proprietary, which is issued and used by the patient's primary care provider. Another care provider or paramedic/emergency team is not able to use the card to efficiently obtain the medical or health history of a patient.
• this type of ID card may not be able to promptly record a current medical or health treatment provided by a healthcare provider other than a patient's primary care provider. Further, patients have to repeatedly register their general information every time they go to a different care provider. Furthermore, patients have to bring a different card every time when they go to see a different care provider.
• an ID card in a patient's healthcare record system.
• One main concern is patient's privacy if an ID card contains healthcare information. It is important to make sure that only certain authorized persons, such as a patient, a primary doctor, a pharmacist, a paramedic, etc., can access, update, or delete information in a patient's database. Also, it is important that the scope of authorization is defined such that only certain portions of a patient's database can be accessed, updated, or deleted by authorized persons. For example, a patient may only be authorized to read certain test data file or lab result file, or update certain patient's general information, such as a current address, etc. A pharmacist may only be authorized to access a prescription file of the patient's database.
• Another concern related to a patient's healthcare record system is how to efficiently manage and maintain patient's healthcare information.
• healthcare providers have created their own databases to store patient healthcare information. These databases are generally designed for a particular care provider. As a result, these databases are often different and do not interface with each other. Thus, it is difficult to store, manage, or maintain a patient's specific healthcare record system in a ubiquitous manner. Care providers often do not have prompt access to a patient's vital medical or health information. Also, care providers are not able to promptly update a current healthcare treatment on a patient into the system. As a result, another care provider may not be able to access the most current healthcare information about this patient.
• a further concern related to a patient's healthcare record system is the easy access issue.
• a patient often wants to access certain information, for example, the recent test report, etc.
• the existing systems do not provide such easy access.
• it is difficult for a patient or an authorized party to monitor a patient's health condition.
• the present invention discloses a patient healthcare record system and method for storing, managing, and retrieving healthcare information on a smart card.
• the present invention provides a method of storing, managing, and retrieving information in a record system via a smart card.
• the method includes entering information at a first location, entering a smart card PIN at the first location, and issuing the smart card which stores at least a portion of the information and the smart card PIN.
• the information and the smart card PIN are stored on a server of the record system.
• the smart card stores a flat file which is accessed via a database interface.
• the database interface converts the flat file stored on the smart card into a database file. Still in one embodiment, the method further includes accessing the information at the first location by reading the smart card via a smart card reader at the first location. After an update at the first location, the method further includes storing a record of the update on the server, and storing at least a portion of the record of the update on the smart card. Further in one embodiment, the method further includes accessing the information at a second location by reading the smart card via a smart card reader at the second location. After an update at the second location, the method further includes storing a record of the update on the server, and storing at least a portion of the record of the update on the smart card.
• the present invention also provides a patient specific healthcare record system in an accessible, portable, and secure manner.
• the system includes: a smart card having a processor, an operating system, and at least one file; a smart card reader operable to read/write the smart card; a computer coupled to the smart card reader, the computer having a processor, an operating system, a smart card application operable to convert the at least one file on the smart card to a smart card database file, and a system database file.
• the smart card database file is a subset of the system database file.
• the smart card database file may contain a security code to access the system database file.
• the computer includes a lost card database file that is a subset of the system database file and is a copy of the smart card database file.
• a patient specific healthcare record system includes: a smart card having a processor, an operating system, and at least one file; a smart card reader operable to read/write the smart card; a client computer coupled to the smart card reader, the client computer having a processor, an operating system; a server computer coupled to the client computer, the server computer having a processor, an operating system, a smart card application operable to convert the at least one file on the smart card to a smart card database file, and a system database file.
• the smart card database file is a subset of the system database file and accessible via the client computer.
• the smart card database file may contain a security code to access the system database file.
• the server computer includes a lost card database file that is a subset of the system database file and is a copy of the smart card database file.
• the client computer and the server computer are coupled in a network, such as a Local Area Network (LAN) or a Wide Area Network (WAN), etc.
• LAN Local Area Network
• WAN Wide Area Network
• a patient specific healthcare record system includes: a smart card having a processor, an operating system, and at least one file; a smart card reader operable to read/write the smart card; a web browser device coupled to the smart card reader, the web browser device having a processor and an operating system and being operable to browse the Internet; an Internet web portal/server coupled to the web browser device, the Internet web portal/server having a processor, an operating system, a system database file, and a smart card application operable to convert the at least one file on the smart card to a smart card database file.
• the smart card database file is a subset of the system database file and accessible via the web browser device.
• the smart card database file may contain a security code to access the system database file.
• the Internet web portal/server includes a lost card database file that is a subset of the system database file and is a copy of the subset of the system database file.
• system further includes a second smart card having a processor, an operating system, and a key data file, the smart card application being operable to access a second subset of the system database file based on the key data file of the second smart card, the web browser device browsing the second subset of the system database file.
• the system further includes an Internet ancillary service web portal/server having a processor, an operating system, and a data file, the Internet ancillary service web portal/server being communicable with the Internet web portal/server, and the web browser device browsing the data file of the Internet ancillary service web portal/server.
• the data file stored on the smart card is a key data file.
• the patient's actual medical records are not stored on the smart card, but are stored in a database on a server.
• the key data file provides a key or security code to access the database on the server.
• an authorized user having a smart card can access, update, and/or delete patient's healthcare records stored on the smart card.
• the authorized users can be the patient's primary care provider, paramedic, pharmacist, the patient's care provider other than the primary care provider, patient, smart card issuer, system administrator, etc.
• Such authorization can be implemented in one embodiment by granting access to such a user using another smart card and verifying a security code entered by the user. Once the system verifies the entered security code by reading the user's smart card, the user can access an authorized portion of the smart card database file. If the authorized users are patients themselves, the authorization can be implemented in one embodiment by entering the patients' PINs, etc.
• the present invention provides ubiquitous access, at the point of care, to the patient's healthcare records stored on a smart card and/or the patient's healthcare records, if authorized, via a computer, a server computer in a network, or the Internet web portal/server on the Internet.
• the care provider can promptly access and update the patient's healthcare records stored on his/her smart card and/or the patient's healthcare record, if authorized, stored on a computer, a LAN server, or the Internet web portal/server.
• the record of such treatment is appended to the previously recorded medical records such that another care provider or institution can later review the updated records in a subsequent treatment.
• the patient's healthcare records are generated and maintained from a patient's perspective rather than from a care provider or institution's perspective.
• a smart card may be used as a security key, or an electronic purse to allow quick and efficient medical payments (e.g. co-pay).
• the present invention may provide a method of tracking specific population segments that are high risk, high usage, and high cost of a certain medical or health treatment.
• the population segments may be defined according to patient demographics and/or clinical histories. Examples of high-risk patients may include oncology, diabetes, asthma, or cardiology patients. Examples of high usage patients may include maternity patients during a pregnancy period. Examples of high cost patients may include a well child group, or children within the ages of 0-13 years.
• the present invention may provide a care provider a user- friendly interface on a patient's vital medical or health information, as opposed to a longitudinal list of medical records. Using this information, the care provider is capable of making an adequate assessment of the patient's medical condition.
• the database fields displayed at the user interface would not include the patient's complete healthcare records, but rather the vital medical information would be included therein. Most data entries in the database fields may be pre-defined and limited to specific categories.
• FIG. 1 is a block diagram showing one embodiment of a patient healthcare record system in accordance with the principles of the present invention.
• FIG. 2 is a block diagram showing a second embodiment of a patient healthcare record system in accordance with the principles of the present invention.
• FIG. 3 is a block diagram showing a third embodiment of a patient healthcare record system in accordance with the principles of the present invention.
• FIG. 4 is a block diagram showing a fourth embodiment of a patient healthcare record system in accordance with the principles of the present invention.
• FIG. 5 is a flow chart diagram showing a method of storing patient's information and issuing a new patient's smart card in accordance with the principles of the present invention.
• FIG. 6 is a flow chart diagram showing a method of accessing and updating a return patient's smart card by a care provider in accordance with the principles of the present invention.
• FIG. 7 is a flow chart diagram showing a method of accessing and updating a referral patient's smart card by a care provider in accordance with the principles of the present invention.
• FIG. 8 is a flow chart diagram showing a method of accessing and updating a patient's smart card by an authorized paramedic/emergency team in accordance with the principles of the present invention.
• FIG. 9 is a flow chart diagram showing a method of accessing and updating a patient's smart card by the patient in accordance with the principles of the present invention.
• FIG. 10 is a flow chart diagram showing a method of accessing a lost card database and issuing a new smart card in accordance with the principles of the present invention.
• the present invention relates to a patient specific healthcare system and method for storing, managing, and retrieving healthcare information on a smart card.
• the present invention discloses a patient healthcare record system and method of storing, managing, and retrieving healthcare information on a smart card.
• the system allows healthcare providers to electronically capture, store and subsequently recall sufficient details concerning a patient's medical and health history to formulate a treatment plan.
• the system in accordance with the principles of the present invention provides the tools for storing and maintaining the information on a smart card.
• the smart card is generally controlled and carried by a patient. Given the disparate nature of healthcare delivery systems, the portability of information stored on the smart card can be used to improve the quality of care by making the healthcare information available at the point of care.
• smart cards In addition to storing, managing, and retrieving patient's healthcare information, smart cards also represent a suitable technology for storing digital certificates which, when used with biometrics identification, can be used to authenticate a cardholder's identity. Once identified, the cardholder can then be granted access to extended privileges, such as access to areas on the Internet web portal server not accessible to the general public information.
• the system in accordance with the present invention may provide at least the following applications:
• Smart card technology in addition to storing, managing, and retrieving patients' healthcare information, for securing and limiting access by user classification to the patients' healthcare information.
• An enterprise-ready smart card issuance and tracking system including a lost card database or smart card life-cycle management.
• An institutional smart card/patient tracking system e.g. a local institutional database for tracking a patient healthcare record.
• An Internet web portal server that extends the value of a smart card to a patient and a care provider by providing content that is tailored to the patient's specific healthcare background and interests.
• Interfaces facilitating the exchange of patient information including lab and radiology reports.
• FIG 1 there is generally illustrated by reference numeral 20, one embodiment of a patient healthcare system in accordance with the principles of the present invention.
• the patient healthcare system 20 includes a smart card 22 having a CPU 24, an operating system (O/S) 26, and a plurality of flat files 28.
• the flat files 28 are one patient's healthcare records.
• the term, "flat files”, is used to refer to files that are not associated with each other in a database structure.
• a smart card application for example a smart card application using a database interface, such as an Object Linking and Embedding Database (OLE DB) 30 which is described later in detail, is used to link the flat files 28 such that a user is able to view the records in a database format.
• the smart card application 30 is stored and operated at a PC 32 shown in Figure 1, a server PC 34 shown in Figure 2, or an Internet web portal/server 36 shown in Figures 3 and 4.
• the system 20 also includes a smart card reader 38 operable to read/write the smart card 22.
• the smart card reader 38 provides smart card read/write capabilities and is known in the art to read and/or write the smart card 22.
• the PC 32 operates the smart card reader 38 so that the files 28 on the smart card 22 are loaded into the PC or vice versa. It is appreciated that the smart card reader 38 can be assembled as a part of the PC 32.
• the smart card reader 38 can be implemented as an I/O device of the PC 32, such as a keyboard, PCMIC port, etc.
• the smart card reader 38 may also be implemented in a handheld CE type device.
• the PC 32 includes a processor (not shown) which operates the smart card application 30.
• a patient healthcare database 40 and a lost card database 42 are stored in the PC 32.
• the patient healthcare database 40 is a patient healthcare database including all the patients registered in the system 20.
• a specific patient's healthcare records are stored and updated in the patient healthcare database 40.
• the database generated from the flat files 28 on a specific patient's smart card 22 is a subset of the patient's healthcare records stored in the patient healthcare database 40.
• the records on the smart card 22 are stored and updated by an authorized class of users, such as a patient, a care provider, or a smart card database administrator. For example, a patient may be authorized to update a certain fields of the database, such as the patient's current address, insurance information, emergency contact person, etc.
• a care provider may be authorized to update patient's healthcare records in a certain fields of the database once a new diagnosis or treatment is performed.
• a smart card database administrator may be authorized to validate a user's access to the files 28 on the smart card 22 and/or the database 40,42 on the PC 32, PC server 34, or web portal/server 36.
• the records in the lost card database 42 are a copy of the records in the flat files 28 stored on the smart card 22.
• the lost card database 42 is also a subset of the patient's healthcare records stored in the patient healthcare database 40.
• the lost card database 42 is used in issuing a new smart card if the smart card 22 is lost.
• the most recent updated records in the lost card database 42 are stored on the new smart card.
• only the smart card database administrator has the access to the lost card database.
• the smart card database administrator may update the system to validate the new smart card.
• the lost card database 42 is a separate database from the patient healthcare database 40. It is appreciated that the lost card database 42 can be implemented as a part of the patient healthcare database 40 within the scope of the present invention.
• FIG 2 there is generally illustrated by reference numeral 44, a second embodiment of a patient healthcare system in accordance with the principles of the present invention. In Figure 2, same reference numerals are used for the corresponding parts of the system 20 in Figure 1 for the purpose of illustration.
• the patient healthcare system 44 includes a client PC 46 coupled to the smart card reader 38 and the server PC 34.
• the client PC 46 has a processor and an operating system (not shown).
• the server PC 34 has a processor and an operating system and is in a network communication with a plurality of client PCs 46. Each of the client PCs 46 has the capability of coupling to a smart card reader.
• the smart card application 30, the patient healthcare database 40, and the lost card database 42 are stored and operated on the server PC 34.
• Each of the client PCs 46 is capable of operating the smart card application 30, accessing the patient healthcare database 40, and the lost card database 42 on the server PC 34 so that the system 44 is ubiquous to each of the client PCs 46 in the network.
• the network can be a Local Area Network (LAN) or a Wide Area Network (WAN), etc., or a World Wide Web (WWW), etc.
• LAN Local Area Network
• WAN Wide Area Network
• WWW World Wide Web
• FIG 3 there is generally illustrated by reference numeral 48, a third embodiment of a patient healthcare system in accordance with the principles of the present invention.
• the patient healthcare system 48 includes a smart card 50 having the CPU 24, the operating system (O/S) 26, and a key data file 52.
• the key data file 52 may include an access code to allow a user to access a certain authorized portion of the patient healthcare database 40 or the lost card database 42.
• the key data file 52 is read by the smart card application 30 and is operable to retrieve the authorized portion of the patient healthcare database 40.
• the lost card database 42 includes a copy of the key data file 52 so that when a new smart card is issued to replace the lost smart card 50, the lost card database 42 is copied onto the new smart card.
• the key data file 52 may be maintained by a separate key management system. In this case, when a new smart card is issued, a copy of the key data file which is maintained by a separate key management system is stored on the new smart card.
• the system 48 also includes a web browser device 54, such as a PC or a handheld device, etc., having a processor and an operating system (not shown). The web browser device 54 is operable to browse the Internet and communicable with the Internet web portal/server 36.
• the web browser device 54 is coupled to the smart card reader 38 to read/write the smart card 50.
• the Internet web portal/server 36 can be implemented as a PC at an Internet service provider or a workstation, etc.
• the Internet web portal/server 36 has a processor and an operating system (not shown) and is in communication with a plurality of web browser devices 54 coupled to the Internet.
• the smart card application 30, the patient healthcare database 40, and the lost card database 42 are stored and operated on the Internet web portal/server 36.
• Each of the web browser devices 54 is capable of accessing the smart card application 30, accessing the patient healthcare database 40, and the lost card database 42 on the Internet web portal/server 36 so that the system 48 is ubiquous to each of the web browser devices 54.
• the Internet web portal/server 36 may be coupled to a plurality of Internet ancillary services 56 (only one is shown for illustration purposes). Each of the Internet ancillary services 56 is provided on an Internet web portal/server 58.
• the Internet ancillary services 56 may include a web site or chat room for advising treatments to a specific disease, diet programs, or exercise programs.
• a user of the smart card 50 may access the contents of the Internet ancillary services 56 via the web browser device 54.
• an exemplary user profile of the system 48 is shown.
• One group of the users of the system 48 is patients 60 who hold the smart cards 50.
• Another group is patients' primary care providers 62 who provide primary medical/health care for the patients 60.
• An additional group can be clinic/general physicians 64 who are care providers other than the patients' primary care providers.
• Still another group can be pharmacists or other similar outpatient service providers 66 who supply patients' medications or other similar functions.
• Yet another group can be emergency teams/paramedics 68 who provide emergent, first response medical care for the patients.
• Further another group may be lost card administrators 70 who issue new smart cards to the patients who lost the smart cards.
• Still another group may be smart card issuers 72 who initially issue smart cards to the patients.
• the patient/smart cardholder 60 enters a security code, for example, a Personal Identification Number (PIN), a biometric identification, and/or a password, etc.
• a security code for example, a Personal Identification Number (PIN), a biometric identification, and/or a password, etc.
• the patient/smart cardholder 60 is able to access an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that a patient is authorized to access may be defined in a database which stores the access rules of various users.
• Database field definition technique is well known in the database art. Accordingly, a patient may be able to view certain information such as the lab test results, recent medical treatment, and ancillary services, etc. The patient may also be able to update the patient's general information as mentioned above. If the user of the system is the primary care provider 62, the primary care provider 62 inserts the patient's smart card 50 and a primary care provider's own smart card 72 in the smart card reader 38.
• the primary care provider 62 Upon verification of the entered security code using a key data file 74 of the primary care provider's smart card 72 and the key data file 52 of the patient's smart card 50, the primary care provider 62 is able to access an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that a primary care provider is authorized to access may be defined in a database which stores the access rules of various users.
• the primary care provider 62 may be able to view patient's healthcare records and update current treatments, conditions, and/or prescriptions, etc. Since the system 48 is ubiquous, the primary care provider is also able to view the past treatments, conditions, and/or prescriptions made by the clinic/general physicians 64 in a prompt manner.
• the clinic/general physician 64 may insert the patient's smart card 50 and the clinic/general physician's own smart card 76 in the smart card reader 38.
• the clinic/general physician's 64 Upon verification of the entered security code using a key data file 78 of the clinic/general physician's smart card 76 and the key data file 52 of the patient's smart card 50, the clinic/general physician's 64 is able to access an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that the clinic/general physician is authorized to access may be defined in a database which stores the access rules of various users.
• the clinic/general physician 64 may be able to view patient's healthcare records and update current treatments, conditions, and/or prescriptions, etc. Since the system 48 is ubiquous, the clinic/general physician 64 is also able to view the past treatments, conditions, and/or prescriptions made by the primary care provider or the other clinic/general physicians 64 in a prompt manner.
• the pharmacist/outpatient service 66 inserts the patient's smart card 50 and the pharmacist/outpatient service's own smart card 80 in the smart card reader 38.
• the pharmacist/outpatient service 66 Upon verification of the entered security code using a key data file 82 of the pharmacist/outpatient service's own smart card 80 and the key data file 52 of the patient's smart card 50, the pharmacist/outpatient service 66 is able to access an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that the pharmacist/outpatient service 66 is authorized to access may be defined in a database which stores the access rules of various users.
• the pharmacist/outpatient service 66 may be able to view patient's prescription, insurance company, etc., and update the information of the prescribed medication. Since the system is ubiquous, the pharmacist/outpatient service 66 is able to view and update the above information in a prompt manner.
• the paramedics/emergency team 68 inserts the patient's smart card 50 and the paramedics/emergency team own smart card 84 in the smart card reader 38.
• the paramedics/emergency team 68 is able to access an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that the paramedics/emergency team 68 is authorized to access may be defined in a database which stores the access rules of various users.
• the paramedics/emergency team 68 may be able to view patient's prescription and recent medical treatment and condition records, etc., and update their treatments, observed conditions, etc. Since the system 48 is ubiquous, the paramedics/emergency team 68 is able to view and update the above information in a prompt manner.
• the lost card administrator 70 inserts the lost card administrator own smart card 88 in the smart card reader 38.
• the lost card administrator 70 Upon verification of the entered security code using a key data file 90 of the lost card administrator own smart card 88, the lost card administrator 70 is able to access the lost card database 42 and an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36, for example, the portion or field that validates the new smart card.
• the portion or field that the lost card administrator 70 is authorized to access may be defined in a database which stores the access rules of various users.
• the smart card initial issuer 72 inserts the smart card initial issuer's own smart card 92 in the smart card reader 38.
• the smart card initial issuer 72 Upon verification of the entered security code using a key data file 94 of the smart card initial issuer's own smart card 92, the smart card initial issuer 72 is able to enter patient's registration information into the patient's healthcare database 40, define which user is authorized to access/read/write which portions or fields of the patient's healthcare database 40, the key data file 52, and the lost card database 42, define which portions or fields of the key data file 52 should be stored on the smart card 50, the patient healthcare database 40, and the lost card database 42, store the information on the smart card 50, and validate the smart card 50, etc.
• FIG 4 there is generally illustrated by reference numeral 96, a fourth embodiment of a patient healthcare system in accordance with the principles of the present invention.
• the patient healthcare system 96 in Figure 4 is an alternative embodiment of the patient healthcare system 48 in Figure 3 where the patient's smart card 50 has the flat files 28 instead of the key data file 52 as shown in Figure 3.
• same reference numerals are used for the corresponding parts of the systems 20, 44, and 48 in Figures 1-3 for the purpose of illustration.
• the patient healthcare system 96 includes a smart card 50 having the CPU 24, the operating system (O/S) 26, and flat files 28.
• the flat files 28 are operable with the smart card application 30 using a database interface, such as an Object Linking and Embedding Database (OLE DB).
• OEL DB Object Linking and Embedding Database
• the flat files 28 are presented in a database format (referred to as a flat file database 28).
• the web browser device 54 browses the flat file database 28.
• the flat file database 28 may also include a field that authorizes the retrieval of a portion of the patient healthcare database 40.
• the lost card database 42 stored on the Internet web portal/server 36 includes a copy of the flat file database 28 so that when a new smart card is issued to replace the lost smart card 50, the lost card database 42 belonged to the patient is copied onto the new smart card.
• the user profile of the system 96 is similar to that is shown in Figure 3.
• One group of the users of the system 96 is patients 60 who hold the smart cards 50.
• Another group is patients' primary care providers 62 who provide primary medical/health care for the patients 60.
• An additional group can be clinic/general physicians 64 who are care providers other than the patients' primary care providers.
• Still another group can be pharmacists or other similar outpatient service providers 66 who supply patients' medications or other similar functions.
• Yet another group can be emergency teams/paramedics 68 who provide emergent, first response medical care for the patients.
• Further another group may be lost card administrators 70 who issue new smart cards to the patients who lost the smart cards.
• Still another group may be smart card issuers 72 who initially issue smart cards to the patients.
• the smart card issuers 72 can be the same people as the lost card administrators 70 without departing from the principles of the present invention.
• the patient/smart cardholder 60 enters a security code, for example, a Personal Identification Number (PIN), a biometric identification, and/or a password, etc.
• a security code for example, a Personal Identification Number (PIN), a biometric identification, and/or a password, etc.
• the patient/smart cardholder 60 Upon verification of the entered security code, the patient/smart cardholder 60 is able to access an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that a patient is authorized to access may be defined in a database which stores the access rules of various users.
• a patient may be able to view certain information, for example, the lab test results, recent medical treatment, and/or ancillary services 56, etc.
• the patient may also be able to update the patient's general information, for example, the current address, etc.
• the flat file database 28 is then updated.
• the patient healthcare database 40 and/or the lost card database 42 are updated automatically.
• a warning or notice may be presented to the user on the web browser device 54 to ask the user whether an update should be made in the patient healthcare database 40 immediately. The user enters yes or no. If the entry is yes, the update is made immediately, and the lost card database 42 is automatically updated immediately. If the entry is no, the update is put on hold until next time the smart card 50 is used. It is appreciated that the synchronization between the flat file database 28 stored on the smart card 50 and the patient healthcare database 40 stored on the Internet web portal/server 36 can be implemented in a variety of ways within the scope of the present invention.
• the primary care provider 62 inserts the patient's smart card 50 and a primary care provider's own smart card 72 in the smart card reader 38.
• the primary care provider 62 Upon verification of the entered security code using a key data file 74 of the primary care provider's smart card 72 and the flat file database 28 of the patient's smart card 50, the primary care provider 62 is able to access an authorized portion or field of the flat file database 28 and an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that a primary care provider is authorized to access may be defined in a database which stores the access rules of various users.
• the primary care provider 62 may be able to view patient's healthcare records and update current treatments, conditions, and/or prescriptions, etc. Since the system 96 is ubiquous, the primary care provider 62 is also able to view the past treatments, conditions, and/or prescriptions made by the clinic/general physician 64 in a prompt manner.
• the clinic/general physician 64 may insert the patient's smart card 50 and the clinic/general physician's own smart card 76 in the smart card reader 38.
• the clinic/general physician's 64 Upon verification of the entered security code using a key data file 78 of the clinic/general physician's smart card 76 and the flat file database 28 of the patient's smart card 50, the clinic/general physician's 64 is able to access an authorized portion or field of the flat file database 28 and an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that the clinic/general physician is authorized to access may be defined in a database which stores the access rules of various users.
• the clinic/general physician 64 may be able to view patient's healthcare records and update current treatments, conditions, and/or prescriptions, etc.
• the clinic/general physician 64 is also able to view the past treatments, conditions, and/or prescriptions made by the primary care provider 62 or the other clinic/general physician in a prompt manner. If the user of the system 96 is the pharmacist/outpatient service 66, the pharmacist/outpatient service 66 inserts the patient's smart card 50 and the pharmacist/outpatient service's own smart card 80 in the smart card reader 38.
• the pharmacist/outpatient service 66 Upon verification of the entered security code using a key data file 82 of the pharmacist/outpatient service's own smart card 80 and the flat file database 28 of the patient's smart card 50, the pharmacist/outpatient service 66 is able to access an authorized portion or field of the flat file database 28 and an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that the pharmacist/outpatient service 66 is authorized to access may be defined in a database which stores the access rules of various users.
• the pharmacist/outpatient service 66 may be able to view patient's prescription, insurance company, etc., and update the information of the prescribed medication. Since the system 96 is ubiquous, the pharmacist/outpatient service 66 is able to view and update the above information in a prompt manner.
• the paramedics/emergency team 68 inserts the patient's smart card 50 and the paramedics/emergency team own smart card 84 in the smart card reader 38.
• the paramedics/emergency team 68 is able to access an authorized portion or field of the flat file database 28 and an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36.
• the portion or field that the paramedics/emergency team 68 is authorized to access may be defined in a database which stores the access rules of various users.
• the paramedics/emergency team 68 may be able to view patient's prescription and recent medical treatment and condition records, etc., and update their treatments, observed conditions, etc. Since the system 96 is ubiquous, the paramedics/emergency team 68 is able to view and update the above information in a prompt manner. If the user of the system 96 is the lost card administrator 70, the lost card administrator 70 inserts the lost card administrator own smart card 88 in the smart card reader 38.
• the lost card administrator 70 Upon verification of the entered security code using a key data file 90 of the lost card administrator own smart card 88, the lost card administrator 70 is able to access the lost card database 42, an authorized portion or field of the flat file database 28, and an authorized portion or field of the patient healthcare records stored on the Internet web portal/server 36, for example, the portion or field that validates the new smart card.
• the portion or field that the lost card administrator 70 is authorized to access may be defined in a database which stores the access rules of various users. If the user of the system 96 is the smart card initial issuer 72, the smart card initial issuer 72 inserts the smart card initial issuer's own smart card 92 in the smart card reader 38.
• the smart card initial issuer 72 Upon verification of the entered security code using a key data file 94 of the smart card initial issuer's own smart card 92, the smart card initial issuer 72 is able to enter patient's registration information into the patient's healthcare database 40, define which user is authorized to access/read/write which portions or fields of the patient's healthcare database 40, flat file database 28, and the lost card database 42, define which portions or fields should be stored on the flat file database 28, the patient healthcare database 40, and/or the lost card database 42, store the information on the smart card, and validate the smart card, etc.
• a care provider or smart card administrator uses his/her own smart card to gain access to the system and/or databases. It is appreciated that in alternative embodiments, instead of using his/her own smart card, a care provider or smart card administrator may access the system and/or databases via a variety of other methods, such as entering an authorized key code, or biometric identification, etc.
• FIG. 5 shows a flow operation 98 of storing patient's information and issuing a new patient's smart card in accordance with the principles of the present invention.
• the operation 98 starts with an operation 100 of entering patient's general information in a new smart card data file.
• the entry can be done by a patient filling general information in a kiosk or a pre-printed paper form, and then by a care provider electronically scanning the general information into the new smart card data file or manually entering the general information into the new smart card data file.
• a patient selects a smart card PIN in an operation 102.
• the patient authorizes emergency or first response access in the new smart card data file in an operation 104.
• the new smart card data file is sent to a new smart card issuer in an operation 108.
• the new smart card issuer then issues a new smart card with a flat file database stored on the smart card in an operation 110.
• the flat file database on the smart card contains at least a portion of patient's new smart card data file, and the new smart card data file is stored on a PC, a PC server, or an Internet web portal/server. It is appreciated that the sequence of the flow operation 98 does not need to be in an order shown in FIG. 5. For example, the operation 102 of selecting a smart card PIN can be performed after the operation 104 of authorizing emergency, first response access. It is also appreciated that the operation 106 may be omitted if no treatment is performed.
• FIG. 6 shows a flow operation 112 of accessing and updating a return patient's smart card by a care provider in accordance with the principles of the present invention.
• the operation 112 starts with an operation 114 of inserting a patient's smart card in a smart card reader at a care provider. Then, the flat file database stored on the patient's smart card is accessed in an operation 116. In another embodiment, the care provider may not be able to access the flat file database on the smart card unless authorized.
• the smart card reader reads a care provider's smart card to obtain authorization to access the patient's database stored on the server in an operation 118. Once authorized in the operation 118, the patient's medical information stored on the server is accessed in an operation 120.
• FIG. 7 illustrates a flow operation 126 of accessing and updating a referral patient's smart card by a care provider in accordance with the principles of the present invention.
• the operation 126 starts with an operation 128 of inserting a patient's smart card in a smart card reader at a care provider.
• the patient's database stored on the smart card is accessed in an operation 130.
• the care provider may not be able to access the flat file database store on the smart card unless authorized.
• the smart card reader reads a care provider's smart card to obtain authorization to access the patient's database stored on the server in an operation 132.
• the patient's medical information stored on the server for example, the medical information entered previously by another care provider, is accessed in an operation 134.
• the database stored on the server is updated in an operation 136, and the database stored on patient's smart card is updated in an operation 138. It is appreciated that the sequence of the flow operation 126 does not need to be in an order shown in FIG. 7.
• the operation 138 of updating the database stored on patient's smart card can be performed before the operation 136 of updating the database stored on the server.
• FIG. 8 shows a flow operation 140 of accessing and updating a patient's smart card by an authorized paramedic/emergency team in accordance with the principles of the present invention.
• the operation 140 starts with an operation 142 of inserting emergency provider's smart card and patient's smart card to obtain authorization to access the patient's database stored on the smart card. If authorized, the patient's database stored on the smart card is accessed in an operation 144, and the patient's database stored on the server is accessed in an operation 146. After the emergency provider provides a new treatment, the database stored on the server is updated in an operation 148, and the database stored on patient's smart card is updated in an operation 150. It is appreciated that the sequence of the flow operation 140 does not need to be in an order shown in FIG. 8. For example, the operation 150 of updating the database stored on patient's smart card can be performed before the operation 148 of updating the database stored on the server.
• FIG. 9 illustrates a flow operation 152 of accessing and updating a patient's smart card by the patient in accordance with the principles of the present invention.
• the operation 152 starts with an operation 154 of inserting a patient's smart card to obtain authorization to access the database stored on the smart card. Then, the patient accesses the authorized portion of the database stored on the smart card in an operation 156. Next, the patient updates the flat file database in the authorized portion of the database stored on the smart card in an operation
• the database stored on the server is updated by the smart card application stored on the server in an operation 160. It is appreciated that the sequence of the flow operation 152 does not need to be in an order shown in FIG. 9.
• FIG. 10 shows a flow operation 162 of accessing a lost card database and issuing a new smart card in accordance with the principles of the present invention.
• the operation 162 starts with an operation 164 of entering an administrator's identification to obtain authorization to a lost card database stored on a server.
• the administrator may enter a security code or insert an administrator smart card to obtain authorization. If authorized, the administrator enters patient's general information to search lost card database information of the patient stored on the server in an operation 166.
• the administrator accesses the patient's lost card database stored on the server in an operation 168.
• the administrator issues a new smart card with a flat file database stored on the smart card being the same as the lost card database in an operation 170. It is appreciated that the sequence of the flow operation 162 does not need to be in an order shown in FIG. 10.
• a smart card of the patient's healthcare system provides the implementation of one embodiment of: (I) a smart card of the patient's healthcare system; and (II) a smart card application using a database interface, such as an Object Linking and Embedding Database (OLE DB), of the patient's healthcare system in accordance with the principles of the present invention.
• OLE DB Object Linking and Embedding Database
• the patient's healthcare system is a combination of physical components, such as a smart card and a smart card software application.
• the physical components may also include a PC-based workstation and the associated smart card reader.
• the smart card application may include a complete turnkey user interface package that provides the user all of the functionality required to capture data and store the data to both a database and a smart card.
• ISO/IEC 7816-1 1987
• Identification cards - Integrated circuit(s) cards with contacts - Part 1 Physical characteristics
• the system may include a biometrics capture device, such as an eye scan or a finger print identification device.
• a flat file database is stored on the smart card.
• the flat file database may include a plurality of database fields.
• the database fields may include the following pre-defined properties:
• Name with a name including 1-32 alphanumeric and underscore characters.
• Each table includes at least one index field.
• An index is a specially defined database field by which the database stores records. Because databases store their records according to the indexed field's value, searching on indexed fields is much faster than on non-indexed fields.
• Unique off for all fields but the unique identifier. At least one index field is set to contain a unique value for each record.
• the flat file database may also include a security code field. As an example, the security code field may be selected from the following sections:
• Patient's ID number 1-16 alphanumeric string. This is a unique identifier for each patient in the database.
• Patient's social security number zero length or 9-digit string with an input mask.
• Last name 1-20 character text string. This is a patient's last name.
• First name 1-20 character text string. This is a patient's first name.
• Middle name 0-20 character text string. This is a patient's middle initial or name.
• Suffix 0-16 character text string. This is a patient's post-title (e.g. Jr., Sr., II, III, IV, PhD, DDS).
• the flat file database may also include a personal contact field, an employment information field, an emergency contact field, an insurance information field, a guarantor information field, a patient's preference field (e.g. a preferred primary care physician information, a preferred hospital, a preferred pharmacy, living will information, organ donor information, or other demographic information), and a medical history field (such as allergies information, diabetes information, e.g. date of diagnosis, etc., past surgery information, e.g. the surgeon's name, etc., medication information, e.g. the refill frequency, etc., radiology and lab test information, child and/or adult immunization information, maternity information if applicable, pregnancy information if applicable, past medical problems, e.g. seizure, etc.), etc.
• a personal contact field e.g. a preferred primary care physician information, a preferred hospital, a preferred pharmacy, living will information, organ donor information, or other demographic information
• a medical history field such as allergies information, diabetes information, e.g. date of
• a system administrator or database administrator may specify directories and sub-directories into which various data files and defaults can be stored and defined.
• the data files may include a user path name, an audit log path name, and a database path name.
• a smart card application using a database interface such as an Object Linking and Embedding Database (OLE DB), of the patient's healthcare system.
• OLE DB Object Linking and Embedding Database
• the patient healthcare system may be distributed with three DLLs (Dynamic Link Library): DSCOleDB.DLL, SCDBLib.DLL, and CommonDLL.DLL, that provide an OLE DB interface to a smart card to allow the system to use a smart card in the same way that it would use another database to store information.
• DLLs Dynamic Link Library
• SCDBLib.DLL SCDBLib.DLL
• CommonDLL.DLL CommonDLL.DLL
• the smart card application is used for communication with a smart card.
• the smart card application may use a database interface, such as an Object Linking and Embedding Database (OLE DB), and is designed to allow database operations to be performed on a variety of data sources or flat files even if these data sources or flat files are not actually a database in a traditional sense.
• OLE DB Object Linking and Embedding Database
• an application may communicate with a spreadsheet through the OLE DB provided that a spreadsheet vendor supplies a proper interface layer. Because the OLE DB architecture provides this type of flexibility, the OLE DB is used to store data on a smart card. With this design, the system is able to use a smart card for data storage in much the same way that it uses an Access database.
• the smart card OLE DB will return rowsets that can then be displayed and modified. Since the smart card application using an OLE DB is independent of the system core design, changes to the smart card application using an OLE DB do not require the system core design to be changed. For example, changing the type of smart card reader used and/or changing the type of smart cards used do not require changes in the source code of the smart card application using an OLE DB. Secondly, the smart card application using an OLE DB provides more independence to the system. Also, the smart card application using an OLE DB provides greater flexibility so as to minimize code changes in the smart card application.
• the smart card application using an OLE DB includes several layers that perform different functions.
• the system can communicate with a top layer using, for example, Microsoft's OLE DB COM interfaces.
• no layer beneath this one is accessed directly by other applications, and each layer only interacts with the layers above and below.
• One exception to this is the CommonDLL.
• the CommonDLL includes some functionality that is used by all of the other layers or components. Although these layers are largely independent of each other in terms of the functionality that they provide, there are some notable parallels between the different layers.
• the interface that the OLE DB uses to communicate with a DSM (Data Store Manager) layer is similar to a layer that the DSM uses to communicate with an IOS (Input/Output Security) layer.
• a Standard Template Library (STL) is used throughout the layers and components.
• the DSCOleDB of the OLE DB is to implement a set of OLE DB interfaces to allow database operations to be performed by an application. This may be the only layer that is generally accessible to an outside application.
• the application using an OLE DB performs several functions. Primarily, it is responsible for receiving and parsing commands.
• the commands include a small number of simple, proprietary or customized commands that perform database operations. For example, the five basic commands in a database, i.e., "select,” “update,” “insert,” “delete” and “flush,” are supported. Each of these commands, with the exception of the flush command, may be performed on a single table.
• DSM Data Store Manager
• DSM Data Store Manager
• objects represent data stores and tables on the smart card and are stored in memory until a "flush” operation is performed.
• a "flush” operation is performed.
• an "update” operation followed by a "flush” operation will change the appropriate information in the tables on the smart card.
• the SCDBLib of the OLE DB includes the functionality and classes that are used by the OLE DB.
• the interface to the SCDBLib is not a COM interface. Instead, the classes and functions that are used by the OLE DB are exported from the DLL.
• Three distinct layers may exist within the SCDBLib, each of which provides a different type of functionality . These layers are described below:
• DSM Data Store Manager
• the DSM layer has three main purposes. First, this layer provides the decision-making logic that is used to determine what should and should not be stored on a smart card, as well as the format for the information that is stored on the smart card. For example, some fields provide information that is useful, but not critical. Since the amount of space available on the smart card is quite small compared to the amount of space that is available in the database, some fields that are stored in the database may not be stored on the smart card. In these cases, the DSM layer will not store the information on the card. In other cases, a field may be stored in the database in a manner that is straightforward, but inefficient. In such cases, the DSM layer may store the information in a format that is less straightforward, but takes up less room on the smart card. To the layers above the DSM layer, these format translations are transparent.
• the second purpose of the DSM layer is to translate table names as they are requested by the application into table numbers that are used by the IOS layer below it, as well as dividing fields of tables into records. Since the IOS layer handles tables as raw sequences of data while the application handles data according to table names and field names, the DSM layer provides a bridge between these two different ways of representing the data.
• the third purpose of the DSM layer is to provide versioning support. Since a single smart card can be carried between different medical facilities that may have different versions of the system, the DSM layer is able to translate between older and newer versions of the system. In other words, the DSM layer should be able to recognize information on the smart card that has been stored by an older version of the application and to return that information to the application in the format that the application expects. This should again be transparent to the layers above the DSM.
• the DSM layer includes the classes that are exported from the DLL to be used by the OLE DB.
• the three primary exported classes are the ReaderConnection class, the DataStoreConnection class, and the TableConnection class. These three classes provide an abstraction of the database operations that are performed by the application.
• IOS Input/Output/Security
• the primary purpose of the IOS layer is to manage the directories that are stored on a smart card.
• the DSM layer requests information using the database abstractions data stores and tables. Since the card itself uses file system abstractions instead of database abstractions, this layer is responsible for bridging those two abstractions.
• the IOS layer accepts table data in the form of tables composed of uniform-sized records. Each record may include a sequence of raw bytes and the IOS layer does not interpret this data in any way. Each record may be indexed by an unsigned integer.
• the directory and file abstractions allow for different smart cards to be used transparently with minimal changes to existing code.
• the WindowsTM implementation of PC/SC uses a C-style API (Application Programming Interface) that provides support for the functionality described in a PC/SC standard.
• C-style API Application Programming Interface
• C++ wrapper classes were written. The organization of these classes and their relationship to each other is based upon the PC/SC standard. The classes will translate error values that are returned by the API into exceptions.
• the PC/SC layer is largely independent of the layers above it.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Physics & Mathematics (AREA)
• Medical Informatics (AREA)
• Health & Medical Sciences (AREA)
• General Physics & Mathematics (AREA)
• Accounting & Taxation (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Theoretical Computer Science (AREA)
• Epidemiology (AREA)
• General Health & Medical Sciences (AREA)
• Primary Health Care (AREA)
• Public Health (AREA)
• Computer Networks & Wireless Communication (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Biomedical Technology (AREA)
• Pathology (AREA)
• Medical Treatment And Welfare Office Work (AREA)

Applications Claiming Priority (5)

Publications (1)

Family

ID=26842059

Family Applications (1)

Country Status (3)

Families Citing this family (42)

Citations (1)

Family Cites Families (6)

• 2000
  • 2000-07-19 WO PCT/US2000/019706 patent/WO2001006468A1/en not_active Application Discontinuation
  • 2000-07-19 EP EP00952164A patent/EP1200943A1/de not_active Withdrawn
  • 2000-07-19 AU AU64913/00A patent/AU6491300A/en not_active Abandoned

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events