WO2000003526A1 - System and method for establishing and retrieving data based on global indices - Google Patents
System and method for establishing and retrieving data based on global indices Download PDFInfo
- Publication number
- WO2000003526A1 WO2000003526A1 PCT/US1999/014553 US9914553W WO0003526A1 WO 2000003526 A1 WO2000003526 A1 WO 2000003526A1 US 9914553 W US9914553 W US 9914553W WO 0003526 A1 WO0003526 A1 WO 0003526A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- ddns
- establishing
- ofthe
- user
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4552—Lookup mechanisms between a plurality of directories; Synchronisation of directories, e.g. metadirectories
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/535—Tracking the activity of the user
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Definitions
- This invention relates generally to storage to data and retrieval of records. More
- this invention relates to a universal method for generating an index of medical
- medical records may be critical to the treatment ofthe patient in any particular circumstance. If the total medical record for individual patient is not available, certain diagnoses may be overlooked or erroneously made.
- central storage area may be accessed by individual practitioners
- identification information is the telemed system in use at Los Alamos labs. That system
- the master ID is then used to determine where to find data related to a particular patient.
- Telemed system deals with topological information normally characterizing patient records.
- the telemed system still requires a master patient index as a form of central registration.
- the present invention does not rely on a root
- the present invention comprises the data transfer protocol to allow for global addressing and retrieval of information from sites remote from the location at which the patient is present. In this matter, all information concerning a particular patient maybe retrieved by the location treating the patient.
- identifiers that identify a objects that are the subject of transactions using the system.
- a user ofthe present invention the first time that a user uses the present invention. It is yet another objective ofthe present information to establish a persistent identifier
- the present invention uses a device-based paradigm to avoid the confusion and restrictions associated with root registration systems. For example, a particular manufacturer
- a date/time stamp is also added to this equipment ID to designate the source and when the equipment is used.
- the present invention also comprises a simple network transport up protocol, defined
- SDTP Simple Data Transfer Protocol
- the SDTP allows for the transmission, reception, and recovery of data from disparate locations.
- the present invention also provides a network delivery mechanism for addressing
- DDN S is the reference system by which SDTP operates. This is not meant however as a limitation.
- Hewlett-Packard may register the name "HP" to be used with the system.
- a patient receives an ID number, the first time the patient receives an ECG or is x-
- the present invention also comprises a user identification token or barcode label
- any card of any variety which may be in the form of a credit card, smart card or
- the patient identification card is "registered" within the system. Further, the health care provider simply uses the imaging equipment available based upon the patient identification card, the universal encoding ofthe system, and images recorded with appropriate patient identification information and image information.
- the image created is universally available immediately after creation.
- the present invention tracks indices to locations of information. If the location ofthe device changes, that information could be tracked by the present invention.
- the device is currently housed.
- the information can change as necessary while the index
- the present invention also does not require standardized
- the system ofthe present invention transports, sends, delivers, receives, and
- the present invention is a device driven addressing system rather than a
- top-down addressing system Individual devices create the namespace address necessary to retrieve information created by the individual device.
- the present invention allows the minimal set of possible information at the top-level, which is used for routing requests for information, with actual information created by individual devices or sites stored and located at those devices or sites.
- the present invention comprises a Simple Data Transport Protocol (SDTP), Distributed Data Name Service (DDNS) software implementation, and a paradigm for automated indexing of global databases.
- SDTP Simple Data Transport Protocol
- DDNS Distributed Data Name Service
- the DDNS design is similar in function to the domain name service which supports
- DDNS is generalized and optimized for resolving database locations and database service
- the DDNS exists in a series of servers in a tree structure whereby medical diagnostic
- the parent server is referred to as a DDNS Level 2 server or
- DDNS-2 server This situation can exist in the medical sense if a patient, having a medical ID card ofthe present invention, visits an emergency room in other than the patient's home city. In that situation the patient may use the patient ID card which will not be recognized by
- the Interaction stops. If the server does not have the information, it in turn, asks its parent server, and so on up a tree structure of parent-child DDNS servers until the requested information is found. Once the patient index information is found, it is passed back down to
- the originating client which receives address/index information for a direct site to site request.
- SDTP Simplified Data Transport Protocol
- SDTP Internet- wide
- SDTP structures transmission, reception, and recovery of data.
- Figure 1 illustrates the DDNS server nodes
- Figure 2 illustrates a DDNS network topology
- Figure 3 illustrates a specific example of an instance of use ofthe DDNS network topology Detailed Description of the Preferred Embodiment
- the present invention comprises a Distributed Domain Name Service
- SDTP Simple Data Transport Protocol
- DDNS Distributed Data Name Service
- DDNS Distributed Data Name Service
- SDTP Secure Transfer Protocol
- the DDNS implementation is similar to DNS (Domain Name Service), which
- server where to find that information. If that server has the information, it answers the requesting client and the interaction stops. If the server does not have the information, it in turn asks its parent server, and so on, up a tree structure of parent-child DDNS machines,
- DDNS is not “Middleware”. Although it can appropriately interact with Middleware as necessary.
- DDNS provides efficient recovery of records from anywhere on a network, and has no
- DDNS will seamlessly migrate to new network protocols such as "IP2" whenever
- the SDTP/DDNS combination provides an automatic, low-level addressing and retrieval mechanism on which other functionality can be conveniently built.
- functionality may include automatic invoicing, automatically generated statistical polling of
- Such functionality supports electronic interaction and electronic commerce.
- DDNS Used with SDTP and other naming and classification conventions, DDNS can provide global indexing of any kind of image, produced on any kind of image-producing device,
- SDTP/DDNS functionality may conveniently extend
- Such applications may include automated part tracking, automated
- DDNS design The major advantages supporting DDNS design include:
- SDTP/DDNS only stores addressing information, it can provide information on many such
- Each machine may cache its previous lookups and thus avoiding vertical
- the caching mechanism allows site-to-site connections without making
- DDNS Secure Digital Network
- SDTP Simple Data Transport Protocol
- Database A collection of records. SDTP supported databases can be local and/or
- transactions include modifying a global database and finding a record
- Client Query A request from a client sent to a server.
- Server Response A response from a server sent to a client.
- Message Generally, a client query or server response. Specifically, a content
- Data Object A header and body. Data objects may include text, images, video, sound, etc.
- Header Header information in a data object, employing MIME conventions.
- Body Body information in a data object, employing MIME conventions.
- SDTP Simple Data Transport Protocol
- the SDTP protocol provides universal addressing of database systems, and universal search and retrieval of data stored on such systems. SDTP supports any encoding
- SDTP distributed database functionality can seamlessly traverse any network topology, machine-type, operating system, database system, etc.
- the protocol supports all
- SDTP permits intelligent, efficient, fully automated data-sharing on a site-to-site
- Data sets can be located
- Searching can be
- SDTP views data as query relations, in which a single, very simple query mechanism
- the basic mechanism works such that when a client query is fully satisfied locally, a search can halt. When a client query is not satisfied locally, within a couple of network
- a given client needs no initial knowledge that related data even exist, or
- SDTP can support machine clusters, LANs, WANs, heterogeneous networks,
- SDTP operations rely on client-server transactions.
- a transaction is characterized by a client sending a message to a server, and the server sending back a message to the client.
- SDTP/0.9 supports two basic transactions, Lookup and Modify, each of which has two
- Table 2 summarizes these relations. Lookup index Retrieve a record's index, but not the record itself query retrieve a record.
- SDTP applies to any kind of database, existing anywhere on the Internet, SDTP transactions provide genuinely global searching, retrieving, adding, and removing records
- a message is a client query or a server response.
- a content identifier identifies SDTP version, command, and any arguments.
- a data object Content Identifier
- a header contains
- a body contains data, which can include MIME multipart documents, among other data.
- SDTP relies on uniform interaction between clients and servers, transacted through
- client query and server response messages A client query requests actions from a server.
- a server response answers client queries, and sometimes also performs actions on behalf ofthe client called server actions. Both client queries and server responses rely on the data structure
- Table 4 summarizes protocol relations. Since transactions are interactions between
- client queries and server responses are
- a message is a content identifier and a data object.
- the SDTP client query content
- identifier syntax is:
- a data object includes (1) a header and (2) a body.
- a data object may include text
- a header consists in one or more lines and is terminated by a blank line.
- the argument data may have any number of additional arguments separated by
- fieldname Label for data field e.g., Date, Content-Length,Content-Type, etc.
- data Data e.g., for content-type, cookies etc.
- Client query data object headers additionally can contain preferences for server responses, but SDTP/0.9 does not yet specify these.
- a body consists in a MIME body, including multipart bodies [FB96a]. This structure facilitates transmission of all data types such as text, graphics, sound, video, etc.
- a body contains content or is null. The exact format ofthe body depends upon
- a client query is a message, and consists in (1) a content identifier and (2) a data object.
- a server response is a message, and consists in (1) always a data object, and (2) sometimes an additional server action (e.g., a record deletion). See also Message Data
- SDTP server responses have no content identifier.
- Server response data object headers are transaction types. For example, consider the following server response data object header.
- the Transaction type illustrates address forwarding.
- Content-Type: application/sdtp; transaction "forwarding"
- the Server response data object body syntax is determined in the data object header according to the transaction specification.
- a body contains content or is null. For example,
- Example Server Response Data Object Consider this example of a server response data object, including both header and body:
- a server response may invoke a server action, such as adding or deleting a record
- SDTP specifies the structure and syntax of data objects. SDTP specifies a
- a transaction consists of (1) a client query (to server), and (2) a server response (to
- SDTP 0.9 The current version, SDTP 0.9, provides two types of transactions, Lookup and
- Table 5 illustrates these relations.
- Table 5 Transaction Summary Lookup: A Lookup transaction determines if a node has knowledge of requested record(s).
- Client Query A Lookup client query is a message, and thus contains (1) a content identifier
- Content Identifier An sample Lookup content identifieris as follows: SDTP/0.9 MODIFY Medlmages 123.abc
- Data Object A Modify data object will contain (A) a header and (B) a body.
- a Lookup data object header has syntax:
- Value Meaning query Transfer a record index Transfer a record's index, but not the record itself
- (2B) Body A Lookup client query data object body is empty in SDTP/0.9.
- a Lookup response (1) has no content identifier, and (2) has a data object.
- the Lookup server response data object has (A) a header and (B) a body.
- application/sdtp with attribute transaction set to forwarding.
- a following data object body would contain a list of addresses to query for records.
- Compound responses structured as MIME multipart documents. Each part of a multipart document will be: (a) Form 1, One or more records (b) Form 2, Forwarding instructions (c) Form 3, Compound responses.
- Example Lookup Transaction This example illustrates a Lookup transaction, in which
- record '123.abc' is retrieved from universal database 'Medlmages'.
- the transaction consists in a client query and a server response.
- Client Query The following 3 line transcript is a plausible client query Lookup record
- Server Response The following 7 line server response indicates a plausible server reply to
- ddns-2.uch.net ddns-2.mag.net ddns-2.nyc.net The server forwards the client addresses where questions are answered about record '123. abc' in universal database 'Medlmages'.
- Modify A Modify transaction synchronizes databases.
- a client query asks for modification of server-stored data, such as adding or deleting a record.
- a Modify client query includes (1) a content identifier and (2)a data object.
- a Modify data object will contain (A) a header and (B) a body.
- a Modify data object header specifies a Content-Type using
- This header specifies the Content-Type of the server response, but may also include other information such as MD5 encrypted signatures, etc.
- (2B) Body The body follows MIME message body conventions [FB96a].
- the Modify data obj ect body may also contain verification information, such as the success or failure of a request. Verification information often is null.
- Example Modify Transaction The following example illustrates a Modify transaction. This example modifies the
- the transaction consists in a client query and a server response.
- Blank line identifies separation between data object header and data object body.
- Server Response The following 6 line server response indicates a plausible reply to the previous client query.
- Line 1 Server response identifies protocol and acknowledges request for modification of database Medlmages .
- Line 2. 'Content-Type' identifies a SDTP application; 'trisection' specifies a
- Blank line identifies separation between data object header and data object body.
- electrocardiogram analyzer 10 has unique identifier which, for purposes of this illustration is
- the user might be subject to electrocardiogram analyzer testing on, for example,
- DDNS server 14 “one” is then registered was in DDNS server 14 and.
- the DDNS server is noted as a Level-2 server located at the University of Chicago noted with the abbreviation "UCH.”
- Electrocardiogram analyzer 12 is connected to DDNS server 14. Electrocardiogram analyzer 16
- DDNS server 20 which, in the present example is noted as being associated with
- Electrocardiogram analyzer 18 having the unique identifier "4" is connected to DDNS server 22 in New York City.
- DDNS level 2 servers 22, 20, and 14 are connected to a DDNS Level-1 server 24.
- the purpose ofthe DDNS Level-1 server 24 is to receive and store a record ofthe identifiers of of
- DDNS Level-1 server 24 does not contain the ultimate information, that is, the results of electrocardiograms that have been administered to the particular patient at the various hospitals. (It should be noted that DDNS level 1 server may actually be serval machines as is later illustrated.) DDNS Level- 1 server 24 only contains a
- a query would proceed from electrocardiogram analyzer 18 to DDNS Level-2 server 22 to inquire if a record of that patient exists. If no such record exists at
- DDNS Level-2 server 22 that server will send a query to DDNS Level-1 server 24 to determine if it has a record of the particular patient.
- DDNS Level-1 server or 24 will have such are record ofthe existence ofthe particular
- DDNS Level-2 22 will make contact with DDNS Level-2 server 14 on behalf of electrocardiogram analyzer 18, with electrocardiogram analyzer 10.
- DDNS servers of two different levels are shown.
- the level 2 servers store and broker requests for indices relating to medical equipment that is connected to them.
- the level 1 DDNS servers store and broker requests for indices relating to patients from Level 2 servers connected to them. Thus information is not generally passed when a query is made, only the identification ofthe location ofthe data is transferred. It should also be noted that this example of use in the medical arena is not meant to be limiting. As will be explained later, other
- the network topology of the present invention is illustrated.
- the present invention is device driven rather than driven by a top-down
- a series of medical devices may be attached to a workstation at a
- ECG 4, CT 6, and ECG 12 may all be attached to a workstation
- ECG 4 will have its own unique
- ECH 4 becomes registered on the
- CT 6 also has a unique identifier as does ECG 12.
- medical devices may be self-contained and amenable to being attached or
- ECG 10 is also shown as directly connected to second level DDNS 14. Additionally, ECG 10 is also shown as
- a date time stamp is also used in conjunction with
- the unique identifier to create a unique patient identifier the first time that the patient uses any device that is registered on the system.
- ECG devices 13.15, and 16 may all be resident at, for example, Massachusetts General Hospital
- ECG 15 and 16 may be located in emergency room 21 while
- ECG 13 may be located in and the attached to a workstation and cardiology 19.
- MRI 11 and CT 9 may be connected to workstation 17 in radiology.
- ECG 18 is connected to a PC 32. That PC is in turn connected to a display 30 was
- ECG 34 is directly
- Display 30 is connected to display 30.
- Display 30 is connected to a workstation 26 which has an MRI
- This workstation 26 is in turn attached to DDNS level-2 server 22.
- DDNS level-2 servers 14,20, and 22 are connected to DDNS level-1 servers
- DDNS level-2 server 22 will add a new record to its
- DDNS Level -1 server knows about the
- DDNS level-2 server 14 which will respond with the various indices which indicate that location of records relating to the patient of interest.
- Figure 3 Since only data regarding indices to information os being searched, the system ofthe present invention responds very quickly to queries for the location
- Jane comes the University of Chicago Hospital on 11 December 1998 for the first time, to receive her first ECG ever, where she receives a University of Chicago Hospital medical card as a normal part of her admission.
- Jane's reading is automatically entered into the University of Chicago Hospital's local database system, and a printer produces a small sticker which a nurse affixed to Jane's medical card.
- DDNS-1 Servers receive and process the following client query request to ADD record '1998121 l@l 'to the global 'Medlmages' database:
- DDNS-1 Servers Since DDNS-1 Servers have not yet seen record '19981211@1' DDNS-1 Servers store it. Usingthe From: field, DDNS-1 Serviers furtherassociate ' 1998121 1@l' with address 'ddns-
- DDNS-1 Servers return a SDTP server response to DDNS-2:UCH.
- the DD' command now saves the 22 Dec 1998 reading, associating it with the 1 1 Dec 1998 reading through the global index (database "key”) ' 19981211 @ 1 '.
- the SDTP interaction looks like: SDTP/0.9 MODIFY Medlmages Convent-Type: application sdtp; transaction- 'modification" From: ddns-2.uch.edu ADD 19981211@1
- the attending physician refers Jane to a Networked Specialist Physician, who makes an appointment of 5 Jan 1999.
- DDNS-1 Servers store a mapping from record '19981211@1' to DDNS-2:UCH.
- DDNS- 2UCH has a mapping to whatever internal mechanism the University of Chicago Hospital uses to record its data.
- DDNS-1 Servers and DDNS-2:UCH only know about one record ('1998121 l@l'),while the University of Chicago Hospital knows about two records. A "one-to-many" relationship is
- the NSP local machine does an internal client query 'Lookup' for the number encoded onto Jane's card )' 19981211@1'). This record is not found on the local machine, and so the machine sends a client query to DDNS-2:UCH. SDTP/0.9 LOOKUP Medlmages 19981211@1
- DDNS-2 UCH receives the previous client query and does an internal 'Lookup' for ' 19981211@1', which it finds. Since the search for record ' 19981211@1' is satisfied, DDNS-
- DDNS-2 UCH does not query DDNS-1 Servers.
- DDNS-2 UCH returns records from 11 Dec 1998 and
- the NSP local system sends this command to it DDNS server, DDNS-
- DDNS-2:UCH receives the previous client query 'ADD'. Since DDNS-2:UCH has already registered record ' 19981211@1', it now associates the NSP address with record
- DDNS- 2 UCH returns a server response indicating the successful status ofthe client query ADD: SDTP/0.9 MODIFY Medlmages Convent-Type: application/sdtp; transaction- 'modification" From: specialist.uch.edu
- DDNS-1 Servers receive DDNS-2:MaG's previous client query Lookup for record
- DDNS-1 Servers send a server response indicating that DDNS-2:UCH answers queries about record '19981211@1'.
- DDNS-2 MAG directly connects to DDNS-2:UCH, which queries machine specialist.uch.edu, requesting records related to '19981211@1': SDTP/0.9 LOOKUP Medlmages 19981211@1
- DDNS-2 UCH returns records for ECG readings taken on 5 Jan 1999, 22 Dec 1998, and 11 Dec 1998.
- DDNS-2 MAG sends a client query ADD to DDNS-1 Servers.
- DDNS-1 Servers store the address in the From: header (ddns-2.mag.org) as a
- DDNS-1 Servers now sends a server response indicating status ofthe request:
- DDNS-L Servers receive a client query Lookup request from DDNS-2:NYC: SDTP/0.9 LOOKUP Medlmages 1998121 1@1 DDNS-l Servers know about record '19981211@1'. and have two forwarding address associations: DDNS-2:MAG and DDNS-2:UCH. 17. DDNS-1 ServersknowthatDDNS-2:UCHandDDNS-2:MAGanswerqueries forrecord
- DDNS-2:NYC directly connects to DDNS-2:MAG and DDNS-2:UCH, querying for
- DDNS-2 MAG 5 Jan 1999 DDNS-2:UCH 22 Dec 1998 DDNS-2:UCH 11 Dec 1998 DDNS-2:UCH
- DDNS-1 Servers only knows about global record '19981211@1', the New York Hospital emergency room now views four records, from three
- DDNS-1 Servers receives the following client query request to ADD record
- DDNS- 1 Servers add the address in the From: header (ddns-2. nyc.com) to the list of addresses that will answer queries for global record '19981211@1'.
- DDNS-1 Servers add the address in the From: header (ddns-2. nyc.com) to the list of addresses that will answer queries for global record '19981211@1'.
- DDNS-1 Servers will answer future Lookup requests for record ' 19981211 @ 1' with forwarding instructions to :
- DDNS-2 NYC DDNS-2:MAG DDNS-2:UCH.
- the physician's local machine does an internal client query 'Lookup' for the number encoded onto Jane's University of Chicago card (' 19981211 @ 1'). This record is not found on the local machine, and so the local machine sends a client query to DDNS-2:ISP. SDTP/0.9 LOOKUP Medlmages 19981211@1
- DDNS-1 Servers SDTP/0.9 LOOKUP Medlmages 19981211@1 23.
- DDNS-1 Servers receive DDNS-2:ISP's previous client query Lookup for record
- DDNS-2 NYC DDNS-2:MAG DDNS-2:UCH.
- DDNS-1 Servers send a server response indicating forwarding addresses that answer queries about global record '19981211@1 ⁇
- the forwarding message sent is: SDTP/0.9 LOOKUP Medlmages Content-Type: application/sdtp; transaction- 'forwarding" ddns-2.nyc.com ddns-2.mag.org ddns-2.uch.edu 25.
- DDNS-2:ISP directly connects to DDNS-2:ISP, DDNS-2:MAG, and DDNS2:UCH,
- Practitioner has instantaneous access to live records, from four devices, from different sites thou-
- the IP's local system sends a client query ADD to DDNS-2:ISP.
- DDNS-2:ISP receives the previous client query request from the Independent
- DDNS-2:ISP returns a server response
- DDNS-2:ISP sends the following client query ADD request to DDNS-
- DDNS-1 Servers receive the previous client query request to ADD record '19981211 @V
- DDNS-2 MAG and DDNS-2:UCH
- DDNS-1 Servers store the address in the From: header ('ddns-2. isp. net), associating it with the other addresses that answer queries for global record
- DDNS- 1 Servers return a server response indicating the status ofthe previous client query ADD request from DDNS-2:ISP.
- SDTP/DDNS provides uniform access to the ECGs stored at
- SDTP/DDNS databases can be arbitrarily deep rather than two layers deep.
- new servers can be added at any level in the hierarchy, providing each orga-
- the DDNS system is driven by manipulation of names, by design permitting easy
- ddns- 2.nyc.com could be a single machine, or a pointer to other machines; and/or the New York Hospital could change the type of machine supporting the ddns-2.nyc.com namespace without interrupting service to its local or global community.
- the present invention comprises software on computers and firmware in certain ofthe
- the devices ofthe present invention comprise those medical diagnostic devices known in the art which have the ability to store and output information.
- the DDNS servers ofthe present invention comprise hardware and software and local storage for storing information comprising indices relating to uses of devices on the network. Any of
- the DDNS level-1 servers can also be
- IBM PC Sun workstations or indeed any server capable of storing and retrieving information and communicating that information via modems or otherwise to other servers or
- indices are typically located at the high levels servers ofthe system.
- the manufacturer not only automatically tracks muffler repairs for a given model, but
- a system and method for establishing and retrieving data based on global indices has
Abstract
Description
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU47233/99A AU4723399A (en) | 1998-07-08 | 1999-06-25 | System and method for establishing and retrieving data based on global indices |
JP2000559682A JP2002520725A (en) | 1998-07-08 | 1999-06-25 | System and method for setting and retrieving data based on a global index |
EP99930775A EP1093692A1 (en) | 1998-07-08 | 1999-06-25 | System and method for establishing and retrieving data based on global indices |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11189698A | 1998-07-08 | 1998-07-08 | |
US09/111,896 | 1998-07-08 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2000003526A1 true WO2000003526A1 (en) | 2000-01-20 |
Family
ID=22341021
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US1999/014553 WO2000003526A1 (en) | 1998-07-08 | 1999-06-25 | System and method for establishing and retrieving data based on global indices |
Country Status (4)
Country | Link |
---|---|
EP (1) | EP1093692A1 (en) |
JP (1) | JP2002520725A (en) |
AU (1) | AU4723399A (en) |
WO (1) | WO2000003526A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001061920A1 (en) * | 2000-02-15 | 2001-08-23 | Jihun Kang | The method and the system for accessing multiple services using a single identifier |
WO2001061561A2 (en) * | 2000-02-14 | 2001-08-23 | Overx, Inc. | Automated system for image archiving |
US7103640B1 (en) | 1999-09-14 | 2006-09-05 | Econnectix, Llc | Network distributed tracking wire transfer protocol |
US7233978B2 (en) | 1998-07-08 | 2007-06-19 | Econnectix, Llc | Method and apparatus for managing location information in a network separate from the data to which the location information pertains |
CN111324611A (en) * | 2020-02-28 | 2020-06-23 | 北京瑞卓喜投科技发展有限公司 | Asset type evidence retrieval method and device |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104509012B (en) | 2012-08-24 | 2019-04-19 | 太阳专利信托公司 | communication method and user equipment |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998015910A1 (en) * | 1996-10-09 | 1998-04-16 | Schultz Myron G | Global electronic medical record |
-
1999
- 1999-06-25 WO PCT/US1999/014553 patent/WO2000003526A1/en not_active Application Discontinuation
- 1999-06-25 AU AU47233/99A patent/AU4723399A/en not_active Abandoned
- 1999-06-25 EP EP99930775A patent/EP1093692A1/en not_active Withdrawn
- 1999-06-25 JP JP2000559682A patent/JP2002520725A/en active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998015910A1 (en) * | 1996-10-09 | 1998-04-16 | Schultz Myron G | Global electronic medical record |
Non-Patent Citations (3)
Title |
---|
"METHOD FOR NETWORK NAMING AND ROUTING", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 37, no. 9, 1 September 1994 (1994-09-01), pages 255/256, XP000473404, ISSN: 0018-8689 * |
BOURKE D G ET AL: "PROGRAMMABLE MODULE AND CIRCUIT FOR MACHINE-READABLE UNIQUE SERIAL NUMBER", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 27, no. 4A, 1 September 1984 (1984-09-01), pages 1942 - 1944, XP000715172, ISSN: 0018-8689 * |
KLEINHOLZ L ET AL: "SUPPORTING COOPERATIVE MEDICINE: THE BERMED PROJECT", IEEE MULTIMEDIA, vol. 1, no. 4, 21 December 1994 (1994-12-21), pages 44 - 53, XP000484150, ISSN: 1070-986X * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7233978B2 (en) | 1998-07-08 | 2007-06-19 | Econnectix, Llc | Method and apparatus for managing location information in a network separate from the data to which the location information pertains |
US7103640B1 (en) | 1999-09-14 | 2006-09-05 | Econnectix, Llc | Network distributed tracking wire transfer protocol |
WO2001061561A2 (en) * | 2000-02-14 | 2001-08-23 | Overx, Inc. | Automated system for image archiving |
WO2001061561A3 (en) * | 2000-02-14 | 2004-02-26 | Overx Inc | Automated system for image archiving |
WO2001061920A1 (en) * | 2000-02-15 | 2001-08-23 | Jihun Kang | The method and the system for accessing multiple services using a single identifier |
CN111324611A (en) * | 2020-02-28 | 2020-06-23 | 北京瑞卓喜投科技发展有限公司 | Asset type evidence retrieval method and device |
CN111324611B (en) * | 2020-02-28 | 2023-12-29 | 北京瑞卓喜投科技发展有限公司 | Certificate retrieval method and device for asset type certificate |
Also Published As
Publication number | Publication date |
---|---|
JP2002520725A (en) | 2002-07-09 |
EP1093692A1 (en) | 2001-04-25 |
AU4723399A (en) | 2000-02-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7814169B2 (en) | System and method for establishing and retrieving data based on global indices | |
US7756728B2 (en) | Healthcare system and user interface for consolidating patient related information from different sources | |
US8452617B2 (en) | Gathering, storing, and retrieving summary electronic healthcare record information from healthcare providers | |
US5903889A (en) | System and method for translating, collecting and archiving patient records | |
US6247021B1 (en) | Searchable bookmark sets as an internet advertising medium | |
US5664109A (en) | Method for extracting pre-defined data items from medical service records generated by health care providers | |
US6871780B2 (en) | Scalable distributed database system and method for linking codes to internet information | |
JP3071929B2 (en) | Medical support system and medical support method | |
US7392237B2 (en) | Identifier code translation system | |
US20050177458A1 (en) | Wish list | |
CA2397907A1 (en) | Electronic provider-patient interface system | |
US9020828B2 (en) | Referencing of patient-related information in a distributed medical system | |
GB2403041A (en) | Data format conversion | |
US7069269B2 (en) | Method, system and program product for mapping data fields between a data source and a data target | |
US20030139943A1 (en) | Healthcare information system with clinical information exchange | |
US20060041618A1 (en) | System and method for sharing information among provider systems | |
WO2000003526A1 (en) | System and method for establishing and retrieving data based on global indices | |
US8930226B1 (en) | Gathering, storing, and retrieving summary electronic healthcare record information from healthcare providers | |
WO1996041275A1 (en) | Apparatus and method for centralized storage of heterogeneous medical records in managed health care organization | |
CN107391936A (en) | A kind of ophthalmology image based on distributed website integrates and dissemination method | |
JP2005122606A (en) | Information-reading device, information-reading system and information reading program | |
Fritz et al. | Implementing a DICOM-HL7 interface application | |
Sakusabe et al. | Expand the Internet standard to the DICOM standard: DICOM-QR URL scheme | |
Noumeir | Sharing Medical Records | |
TW200422908A (en) | DICOM processing server |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW SD SL SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
WWE | Wipo information: entry into national phase |
Ref document number: 1999930775 Country of ref document: EP |
|
ENP | Entry into the national phase |
Ref country code: JP Ref document number: 2000 559682 Kind code of ref document: A Format of ref document f/p: F |
|
WWP | Wipo information: published in national office |
Ref document number: 1999930775 Country of ref document: EP |
|
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
WWW | Wipo information: withdrawn in national office |
Ref document number: 1999930775 Country of ref document: EP |