EP1410248A2 - Procede et dispositif destines a des affichages sur ecran produits par des applets, et employant une base de donnees informatique et un langage de programmation - Google Patents

Procede et dispositif destines a des affichages sur ecran produits par des applets, et employant une base de donnees informatique et un langage de programmation

Info

Publication number
EP1410248A2
EP1410248A2 EP01926933A EP01926933A EP1410248A2 EP 1410248 A2 EP1410248 A2 EP 1410248A2 EP 01926933 A EP01926933 A EP 01926933A EP 01926933 A EP01926933 A EP 01926933A EP 1410248 A2 EP1410248 A2 EP 1410248A2
Authority
EP
European Patent Office
Prior art keywords
data
database
screen
applet
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01926933A
Other languages
German (de)
English (en)
Inventor
Richard C. Skarnes
Kenneth S. Poindexter
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Medical Software Solutions Inc
Original Assignee
Medical Software Solutions Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Medical Software Solutions Inc filed Critical Medical Software Solutions Inc
Publication of EP1410248A2 publication Critical patent/EP1410248A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation

Definitions

  • the present invention relates to the field of electronic screen displays and electronic data storage and retrieval. 2. Discussion of Background Information
  • a two-dimensional (or relational) database is based on a flat (or linear) filing structure that uses a predefined numeric structure to organize records. Each record occupies a predefined space along a continuum of all records.
  • record number 183 lies between record numbers 182 and 184.
  • the location of each record is predefined, and the amount of space each record occupies also is predefined.
  • the character length for record fields and the file size for each record must be pre- allocated, and they cannot be changed without a major restructuring of the entire database. The problem is a tremendous amount of wasted disk space and inflexibility in the database structure.
  • the first approach may be classified as a "PC-to-PC" network approach.
  • a PC-to-PC network approach may be structured as a PC-to-PC LAN. All software resides on each PC. Due to hardware limitations, a database may have to be fragmented into separate components and stored on separate PCs. This approach has the benefit of having the software processing speed optimized at each PC. Additionally, familiar WindowsTM-based interface and functionality of software may be found at each PC on the network.
  • PC-to-PC network approach also has its problems. The fragmenting of the database minimizes data integration and interactivity. Additionally, there is a high cost for maintenance, because software updates and database backups must be performed at each PC. The PC-to-PC network software approach also lacks web functionality, except as a separate process not inherent to the software itself. Finally, because the PC- to-PC network approach is based on a low flexibility two-dimensional relational database, it lacks the ability to have a completely on the fly, hierarchy of data relationships and interactivity. Despite these limitations, the PC-to-PC network approach is still widely used in many industries.
  • a second data management approach may be classified as a "legacy- system- attached-to-HTML-web-page.”
  • This approach typically uses a two-dimensional relational database and is structured on HTML or XML web pages based on standard, web-site design protocols. These pages draw upon a legacy mainframe system operating as a server that uses all the components of a two-dimensional/relational database to populate predefined fields on each web page.
  • This approach offers greater flexibility in data retrieval by allowing users to access information on the mainframe database via the Internet.
  • This second approach offers the benefit of a centralized database. With this benefit comes the efficient maintenance of the database using, for example, single-source updates and backups.
  • a centralized legacy-system-attached-to-HTML-web-page also offers remote access via the Internet via a web browser and the ability to introduce JAVA applets to enhance interactivity between the user and the database.
  • the legacy-system-attached-to-HTML-web-page approach has some problems. No new functionality is typically added to existing legacy systems. User interface speed is slow, due to one-way (server-to-browser) communication. The web browser screens are static, and the entire approach is heavily programmer dependent, thus making maintenance and updates to screens costly and time-consuming. More specifically, an Internet, Intranet, or network connect a user terminal to a remote web server with associated database. When the web browser loads onto a user terminal, a screen appears on the user's display.
  • the present invention relates to a method and apparatus for generation of screen displays using a scalable, web-based, multi-dimensional dynamic database.
  • the invention allows for the adding or updating of one or more screen elements on an already existing screen.
  • the invention provides for variable access and interactivity with multiple users to achieve complex functions in real-time via an Internet/Extranet interface.
  • the present invention may be embodied in a suite of programs that function as a fully integrated, web-deployed, and interactive data management system. Other exemplary embodiments and advantages of the present invention may be ascertained by reviewing the present disclosure and the accompanying drawings.
  • FIG. 1 illustrates the apparatus of a preferred embodiment of the present invention.
  • FIG. 2 illustrates the structure of a database.
  • FIG. 3 is a flowchart showing a method of providing access to a database application.
  • FIG. 4 is a flowchart representation showing another method of providing access to a database application.
  • FIG. 5 is a flowchart representation showing a method of providing pseudo code to an applet.
  • FIG. 6 is a flowchart of an initialization of a screen display.
  • FIGS. 7-10 are examples of display screens. DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE
  • FIG. 1 illustrates a system embodying the present invention.
  • the system of FIG. 1 includes a database server 10, a web server 18, and a plurality of remote sites 28.
  • the web server 18 interfaces with each of several remote sites 28 via a communication network 26, such as the Internet.
  • Remote sites 28 each may have a computer 30 or any sort of communications device (fixed or mobile) that can interface to the network 26.
  • Remote site interface devices will be referred to hereafter as "PCs” or “workstations” for convenience without intending to limit the generality of the remote sites.
  • the web server 18 preferably includes an applet 20, a firewall 22, and a security function 24.
  • the firewall 22 protects against unauthorized entry and is well known in the art.
  • the security function 24 may be Secure Sockets Layer (“SSL”) 128-bit encryption and may include authentication and password protection.
  • SSL Secure Sockets Layer
  • the applet 20 is stored in the web server 18 and is downloaded to each remote site 28 PC or workstation 30, 32, 34 etc. upon connection of the remote site 28 to the web server 18. Once the applet 20 is completely downloaded from the web server 18, it runs entirely within the PC or workstation 30, 32, and 34.
  • the applet 20 may be based on a scripted programming language, such as, for example, JAVA. In the preferred embodiment, the applet 20 is based on the JAVA programming language, although other languages may be used.
  • the database server 10 includes a database 12, an application 14, and a development toolkit 16.
  • database 12 is a CacheTM database.
  • CacheTM a product of Intersystems, Inc.
  • B-tree post-relational structure
  • M programming language
  • Data may be imported from any type of database, including CacheTM.
  • the invention is not so limited, as other multi-dimensional and two-dimensional databases may also be used with the present invention.
  • database 12 preferably includes five components: data 36, screen elements 38, a "control box program” 40, data manager 42, and process tracking 44.
  • data manager 42 provides an intelligent and dynamic database system, wherein each piece of data is aware of itself, its relationship to all other data, and its relationship to the database structure itself.
  • the data 36 may be data that is read into the database from, for example, magnetic tape, CD-ROM, or some other mass storage device.
  • the data 36 also may also be entered into the database by manual keyboard entry or other known forms of data input.
  • the preceding examples of data and data entry are exemplary rather than limiting.
  • the screen elements 38 represent data for a graphical user interface ("GUI").
  • Screen elements 38 include a file structure that stores information about how to set up a screen and the components that are part of that screen. For example, screen elements 38 keep track of locations of labels, check boxes, list boxes, text boxes, etc. Screen elements include information that allows an applet 20 (not shown in Fig. 2) to draw items to be displayed for a user, such as required fields for displaying each piece of data and background colors for screen displays. Screen elements 38 also include definitions of user events (e.g., actions that will trigger an action, such as a mouse click or tab key depression by the user), that will trigger a response.
  • user events e.g., actions that will trigger an action, such as a mouse click or tab key depression by the user
  • the control box program 40 is a program including a series of commands (in pseudo-code language) that are triggered by a user event. Pseudo-code commands execute predefined program objects that are used by system designers. Pseudo-code commands control interactions among the data 36, data manager 42, screen elements 38, process tracking 44, and remote sites 28 (FIG. 1). The control box program 40 also sends information to the remote sites 28 using pseudo-code that is interpreted by a downloaded applet 21. For example, the Control box 40 may send a complete screen definition. A screen definition includes the screen element 38, data 36, and any data dictionary 50 information necessary to display the GUI screen. Or, by example, the Control box 40 may send information to update or add one or more screen elements to an existing GUI screen.
  • the remote sites 28 send to the control box program 40 a block of information, which may contain information including data values stored in data fields and associated identification information (possibly including the tracking information discussed below), but without sending all of the screen specification information.
  • the data transfer only occurs in complete predetermined blocks of information, thus avoiding corruption.
  • Process tracking software 44 creates a log of all user information and activity and maintains information about an environment so that a user may return to any interrupted process at any time. Interrupted processing with the remote site 28, coupled with the processing power of the downloaded applet 21, minimizes the need for communication with the database. Consequently, significantly fewer database hits occur, and fewer system access ports are required.
  • Process tracking 44 performs the following user activity. 1) Assignment of a unique process tracking number 46 to each PC or Workstation
  • the application (reference screen) at the remote sites is tagged with the process 46 and application 48 numbers for user tracking purposes.
  • the process tracking number 46 and application number 48 are also sent.
  • the database 12 is preferably structured as a "multi-dimensional" database. Unlike a two-dimensional database, a multi-dimensional database has a nonlinear structure that allows for minimized system response times and maximized data storage efficiency. Two-dimensional databases, in contrast, have a linear structure and have at least four major disadvantages relative to multi-dimensional databases. Each disadvantage will be discussed in turn.
  • each record field length is also predefined. Field lengths must be set very high to accommodate as many entries as possible, without cutting off longer entries. When actual field entries are shorter than the predefined length, the extra space remains unused. As the number of records increases, the amount of unused space also increases.
  • One example would be an address field that has been pre-allocated to accept 80 characters. If the address of a particular record only contains 15 characters, such as "123 15 th Street," 65 character spaces (or 81.25%) of that field remain unused. The amount of unused disk space can be enormously high considering that the number of records stored in a database can be in the millions. Additionally, extra space for each record must also be pre-allocated to accept future data fields, further increasing the amount of unused space. In contrast, record space in a multi-dimensional database is variable.
  • This process allows the database 12 to access the location of each record based on data definitions 42 (FIG. 2) that define a record's relationship to other records.
  • data definitions 42 FIG. 2
  • the data 36 is tagged with a code and automatically sorted.
  • This on-the-fly tagging process allows for optimized system response and data retrieval times. Any record can be found quickly, irrespective of the size of the file. Therefore, there is no predefined limit to the size or number of records in the database 12.
  • the database 12 structure itself is infinitely flexible and expandable.
  • CacheTM includes a programming language known as "M" which allows for data to be “aware” of itself, its relationship to all other data, and its relationship to the database structure itself. Alternatively, a language separate from the database, but which could interact with the database to manipulate the data could generate screens, etc., could be used in the same manner.
  • Data manager 42 predefines the type of data (as stored in the data dictionary 50), its record structure 52 and file structure 54.
  • the data dictionary 50 contains definitions for each item of data and indicates the location where data 36 is stored.
  • the record structure 52 contains the location for all stored data 36..
  • the file structure 54 contains the file name and a listing of records stored as data 36.
  • Each application 14 is created from the development toolkit 16.
  • the development toolkit is operable through, for example, simple English commands and graphical representations of commands. Therefore, development, modification, and enhancements may be conducted by systems analysts as opposed to programmers, thus preferably reducing the cost for application development and modification.
  • the toolkit 16 also allows a user to create or edit the entire application (screen and database) using only the one development tool. Further cost savings may be realized because of the reduction in time required to develop or modify a program.
  • the development toolkit 16 which comes with database 12, may be a fully integrated suite of rapid application development tools used to develop and enhance specific iterations of the present invention in a web-based environment.
  • the preferred embodiment includes a user-friendly interface, uses industry-standard terminology, and is structured as an easy-to-use set of functions based on commands associated with the control box program 40. These functions may include screen design, database design, pseudo-code generation, and external interface creation (both file and transactional types).
  • the application development process is streamlined and optimized, because systems analysts may have direct interaction with clients (i.e., users), and systems analysts also may have industry-specific knowledge. Modifications, such as adding a new data entry field, can be deployed in less time that would have been previously required for programmers to write code to perform the same function. New industry-specific applications can be developed and deployed at a fraction of the cost and time traditionally necessary. Global changes to the system can also be made at a single instance. Additionally, in the preferred embodiment, the toolkit is browser based, allowing the user to manipulate it while being on-site.
  • JAVA is a programming language optimized for Internet use. JAVA allows a user to add more functionality than, for example, HTML or XML languages (collectively described hereinafter as "HTML"). HTML enables users to create simple GUIs such as text boxes, drop down boxes, and check boxes using simple commands. In HTML, once a send button or other equivalent button is clicked, information in all of the fields, (even fields where data has not been entered) is sent to the web server. HTML may be thought of as a one-way system; there is no two-way interactivity between the user and the database. JAVA is a scripting language in which a programmer expresses a set of commands to create a desired GUI which, in this embodiment, is interpreted by a browser.
  • a JAVA program (preferably an applet) will allow for two-way communication between the user and a database.
  • the JAVA applet also has a number of data editing capabilities.
  • a triggering event such as the tabbing-out of the data entry field
  • a JAVA script would alert the user that an invalid character had been entered into a numeric field.
  • the downloaded applet 21 may function as a dynamic screen and data delivery engine.
  • the downloaded applet 21 can run on any JAVA- enabled web browser.
  • the downloaded applet 21 is used to send and receive (i.e., two- way communication) pseudo-commands between the application and the user, and to then interpret and transform the pseudo-commands into a familiar Windows-based GUI, which is displayed through the web-browser on the PC or workstation 30, 32, 34.
  • This two-way communication is optimized for speed because the applet 20 is fully downloaded to the remote site's 28 PC or workstation 30, 32, 34 (i.e., user) upon connection to the web server 18.
  • the downloaded applet 21 performs at least two main functions: 1) screen engine and 2) enhanced data delivery engine.
  • the downloaded applet 21 receives and interprets pseudo- commands sent from the 12, and translates them into GUI screens and their components with which a user can interact.
  • the screen engine can draw context-sensitive, interactive, and dynamic screens.
  • the screen engine may be asked to update a screen component or attribute on an already existing screen display or create an entirely new screen display.
  • system administrators may decide that the number of requests for that information is too small, relative to the high cost of development. As a result, the user must refer to alternate, more traditional forms of information retrieval, such as retrieving data from paper records.
  • the downloaded applet 21 in conjunction with the data manager 42 eliminates this tradeoff between time, cost, and limited information availability by providing instant access to all database information.
  • the development toolkit 16 permits this rapid response to user requests for system modification. Additionally, the downloaded applet 21 minimizes hits against the server and improves response times by sending only those requests or screen components needing server responses.
  • the control box program 40 sends small packets of information containing pseudo-code.
  • the pseudo-code includes the information required for the downloaded applet 21 to create a set of commands with attributes to allow the downloaded applet 21 to create screens and events, for example.
  • the data sent by applet 21 preferably includes the information entered into the field, and any other information necessary to identify that information (e.g. the field and screen where the information was entered).
  • the data may also include information from previous fields on the screen along with associated identification information.
  • the downloaded applet 21 can also function as an enhanced data delivery engine by automatically validating and formatting user-provided data. It can also fill related data fields based on user-provided data. These data delivery engine functions happen before final data is delivered to the database 12. These predefined features allow the downloaded applet 21 to automatically recognize and decipher valid and invalid data and to respond accordingly.
  • Three key enhancements of the present embodiment of the downloaded applet 21 include: 1) auto-validation, 2) auto-fill, and 3) auto-format.
  • fields within the downloaded applet 21 GUI can be predefined to accept only specific data content or format. If the user enters invalid data, he/she is directed to the invalid data field, informed of the error, and prompted for corrections. This process eliminates the filing of invalid data and reduces the amount of network traffic (hits against the server), because invalid data is detected and corrected before being sent to the server.
  • a social security number field can be predefined to contain only nine numeric characters. If a user inputs either non-numeric characters or an invalid number of characters, the downloaded applet 21 will direct the user to the social security number field, display an error message, and prompt the user to make corrections.
  • data fields within the downloaded applet 21 GUI can be predefined in the data definition 42 (FIG. 2) to recognize their relationship to other data fields and automatically populate or create related fields. Because these relationships are predefined, the auto-fill feature works nearly instantaneously through a two-way communication with the database 12. This may eliminate tedious data entry procedures for users and may drastically reduce erroneous data filing.
  • a zip-code data field can be predefined to recognize (as defined in the data definition 42) its relationship to the city and state fields. Once a user enters a zip code, the downloaded applet 21 can quickly query the database and automatically enter the city and state field with the corresponding data.
  • data fields within the downloaded applet 21 GUI can be predefined to reformat user entries based on industry-standard or client-specified protocols. This feature facilitates efficient and accurate data searches and retrievals by eliminating formatting inconsistencies within the database 12, which can result in multiple entries of the same information. For example, a "last name" field can be predefined to reformat any entry to all upper-case characters. If a user enters a last name in any combination of lower and upper cases, the downloaded applet 21 will automatically reformat the entry to all upper case, thus eliminating duplicate entries due to inconsistent formatting.
  • the "M” formatting conventions (auto- validation, auto-fill, and auto-format) are now available via a web browser (i.e., on a PC or workstation 30, 32, 34) connected to the Internet/intranet 26, for the first time.
  • FIG. 3 is a flowchart showing a first method of providing access to a database application.
  • a user at a remote site 28 enters an address for web server 18 (FIG. 7).
  • web server 18 downloads a web-browser-specific applet 20 (either simultaneously with or following download of an HTML based web-browser screen) to the remote site 28 to create the downloaded applet 21.
  • the downloaded applet 21 triggers the control box program event that assigns a unique process tracking number 46 to the particular instantiation of the applet and triggers a sign-on security screen.
  • FIG. 8 illustrates an exemplary security screen 134 generated by the applet 21.
  • the user enters log-on information.
  • the user triggers an event, for example, by mouse clicking an "OK" sign-on button on the display screen.
  • the control box program 40 recognizes the event and validates the user.
  • the control box program transmits (1) an instruction to dispose of the previous screen, and (2) screen definition information for the applet to create a menu at the remote site 28.
  • FIG. 9 is an example of a menu screen 136 with several menu elements accessed.
  • the user triggers an event, for example, mouse clicking on a menu item on the display screen.
  • the control box program 40 transmits screen definition information for the applet 21 to create a screen application.
  • the user interacts with the application screen.
  • FIG. 10 illustrates an application screen 138 with data fields that have already been filled in (either by the user or the auto-fill feature). The following diagrams Fig. 4 through Fig. 6 describe the user interaction with a single data entry field on a screen.
  • FIG. 4 is a block diagram showing a method of use of an embodiment of the invention.
  • the user is attempting to transmit invalid data to the database 12 via the user's web browser.
  • This illustration exemplifies the two-way communicative nature of the present invention.
  • a user at a remote site 28 uses a web browser at a PC or workstation 30, 32, 34 to access a web server 18 hosting the database 12.
  • the web server 18 downloads a web browser-specific applet 20.
  • the downloaded applet 21 acts as a screen engine and displays a data entry screen on the user's PC or workstation.
  • the user enters data into a field on the data-entry screen created by the applet.
  • the user can then perform several actions such as, for example, mouse click, tab, and/or enter, which the applet will interpret as an "event," either singularly, sequentially, or in combination.
  • the user tabs-out of the data entry field, which triggers an event recognized by the downloaded applet 21.
  • the applet responds to the event and, using its data delivery engine functions, evaluates the data entered into the data field for conformity with predefined criteria for the data field.
  • the downloaded applet 21 may, among other things, auto validate and/or auto format the data. For purposes of the illustration of FIG.
  • the downloaded applet 21 informs the user that the data entered into the data field is invalid.
  • the downloaded applet 21 has interacted with the user in an example of two-way communication. Incorrect data has not been transmitted to the web server 18, thus speeding the web server's 18 performance for other users.
  • a screen may have a field for entering a first name. If a user then enters a name that includes improper characters (e.g., numbers) and enters the data by pressing TAB, applet 21 recognizes an improper format and advises the user (e.g., applet 21 displays an error message screen) without transmitting the incorrect data to web sever 18. This error correction thus occurs without having to (1) enter data in all of the fields or (b) sending the entire screen back to web server 18.
  • improper characters e.g., numbers
  • applet 21 displays an error message screen
  • FIG. 5 is a block diagram showing another method of use of an embodiment of the invention.
  • the data entered by a user is valid, however the data comprises information that explicitly or inherently indicates that the database need not be queried. In other words, the control box program 40 need only operate upon the data.
  • This illustration exemplifies the dynamic versatility of the present invention.
  • a user at a remote site 28 uses a web browser at a PC or workstation 30, 32, 34 to access a web server 18 hosting the database 12.
  • the web server 18 downloads a web browser-specific applet 20.
  • the downloaded applet 21 acts as a screen engine and displays a data entry screen on the user's PC or workstation 30, 32, 34.
  • the user enters data into a field on the data entry screen.
  • the user triggers an event recognized by the downloaded applet 21.
  • the downloaded applet 21 responds to the event and evaluates the data entered into the data field for conformity with predefined criteria for the data field (although this step may be omitted).
  • the downloaded applet 21 transmits the data, via the Internet/intranet to the web server 18.
  • the data is applied to the control box program 40.
  • the data has a function associated with it.
  • the function associated with the data is not set to access the database 12; therefore the control box program 40 does not access the database. Rather, at step 108, the control box program 40 sends pseudo-code back to the downloaded applet 21 to, for example, perform a new screen display or disable a function on an existing screen display.
  • a screen may have a field for a person's employment status, and another field for employment information. If the user enters "unemployed" in the first field and presses TAB, applet 21 sends this information to control box program 40. Since the second field may be considered irrelevant (as the user has no employment information), control box program 40 sends instructions to the applet 21 to disable the employment information field. Preferably, both the entry of the data and the subsequent disabling of the field would occur without transmitting the entire screen of data back to the web server, or refreshing the screen upon receipt of new data/instructions (unless the instructions specifically call for a new screen). In another example, control box program 40 could send an error message to applet 21 in response to certain types of erroneous or incomplete data.
  • FIG. 6 is a block diagram showing another method of use of an embodiment of the invention.
  • the data entered by a user is valid and the data requires that information be stored to, or retrieved from, the database 12.
  • a user at a remote site uses a web browser at a PC or workstation 30, 32, 34 to access a web server 18 hosting the database 12.
  • the web server 18 downloads a web browser-specific applet 20.
  • the downloaded applet 21 acts as a screen engine and displays a data entry screen on the user's PC or workstation 30, 32, 34.
  • the user enters data into a field on the data entry screen.
  • the user triggers an event recognized by the downloaded applet 21.
  • the downloaded applet 21 responds to the event and evaluates the data entered into the data field for conformity with predefined criteria for the data field (although this step may be omitted).
  • the downloaded applet 21 transmits the data, via the Internet/intranet
  • the data is applied to the control box program 40.
  • the function associated with the data was set to access the database 12; therefore the control box program 40 passes the data to the database 12. In the alternative, control box 40 may elect to access only screen elements 38, or a combination thereof.
  • the database 12 passes a response to the control box program 40.
  • the control box program 40 generates pseudo code which is transmitted, via the Internet/intranet to 26 the downloaded applet 21.
  • the downloaded applet 21 disposes of the previous screen and now generates a screen display.
  • the response to the event triggered by the user at step 118 completes a round of communication with the database.
  • entry of appropriate identification data in the fields of FIG. 8 causes control box program 40 to send information/instructions to dispose of the screen (FIG. 8), and to generate the menu screen in FIG. 9.
  • the TABLE data type allows a pre-defined list of values. Typically each value within a table will have a code, description and a flag indicating whether or not a user can select this value.
  • the user can select either M or F.
  • the database engine files this data into the database, it files M instead of MALE in order to reduce the amount of space required to store the value.
  • a table DDN may also make an indirect reference to another table DDN if the same table values are used. For example, to avoid recreating identical tables of state county codes every time data is stored (e.g., Patient's county code or Provider's county code), the DDN's have an indirect link to the original table. The Patient's county code and Provider's county code are thus indirectly tied to the State county code table. DATE
  • DATE data type causes dates to be converted to a century independent format for storage. When dates are extracted from the database they are automatically converted to a standard external date format. For example:
  • NUMERIC ensures that the data is numeric. Due to the fact that NUMERIC values are often treated differently than text or GENERAL values, they can be used in a CALCULATED DDN. GENERAL
  • a GENERAL DDN causes the data received to be stored and displayed in the same fashion. No conversions are done on the data.
  • COUNTER COUNTERS allow for the automatic assignment of sequential values.
  • COUNTERS may be system wide, customer specific, or file specific.
  • CALCULATED data type causes the value of the DDN assigned to it to be calculated from a predefined equation.
  • the calculation may be straight arithmetic or a combination of arithmetic and other DDN values.
  • Calculated DDN's can also contain nested calculations.
  • CONSTRUCTED CONSTRUCTED causes the DDN value to be derived by combining the values of one or more DDN's separated by a predefined delimiter character.
  • REPLACED-WITH allows indirect reference to another DDN with the same meaning.
  • 'PROVIDER NAME' and 'REFERRING PROVIDER NAME' are both provider names. Both have the same data type and format and are stored in the same file.
  • the system actually displays the provider name value using a MAPPED-KEY as a reference to the data.
  • MAPPED-KEY a reference to the data.
  • Another example is Patient, Insurance Subscriber and Visit Guarantor, for which demographic data are stored in the same file, but Patient address, Subscriber address and Guarantor address information must be extracted separately using a MAPPED-KEY DDN as reference.
  • a MAPPED-KEY allows a relationship between a key piece of data stored in one file with a record or set of records from another file.
  • the DDN 'VISITINTPRP' is the internal provider pointer of the visit provider and is stored with each visit.
  • the 'VISITINTPRP' is a mapped key to the DDN 'INTPRP', which is the key used to uniquely identify a provider within the provider file. Therefore, the mapped key can be used to extract general information about the visit provider from the general provider file.
  • SWITCH allows either a TRUE or a FALSE value.
  • MONEY allows standard display and storage of values that are considered money. For example:
  • MULTI-LINE TEXT DDN stores a block of text.
  • the text block is stored as a whole rather than line-by-line.
  • a block text is extracted from the database, it is extracted as a whole.
  • the data management system allows the System Analyst using the present invention tool the ability to create or change applications.
  • a DDN may be used in many powerful ways.
  • a DDN may be associated with a screen component. Once the DDN is tied to a screen component, the system has the information necessary to retrieve the DDN value, validate the DDN, or to store the DDN value.
  • - A DDN can import data from outside sources. When data from a file needs to be stored, each imported data value is assigned a specific DDN. Once assigned, the system has the information to validate and store the imported value.
  • a DDN can export data to outside sources.
  • a System Analyst can create an export file by assigning DDN's to specific locations on the export records. Once assigned, the system has the information to extract and create the export file.
  • the Data Management system can also be used to extract data for reporting purposes.
  • the system is ODBC compliant, which allows third party reporting system the ability to view another's file structures, record structures, and data dictionary names.
  • the data manager 42 is a map to the stored data values in data 36.
  • the system looks up the file where the DDN is located. Once the file is known, the system uses the file structure 54 to look up what keys are needed, the record the data value will be stored in, and the DDN position in the data record that the data value will be stored in. The system then sets the data value into the proper position on the data record, creates a reference on-the-fly using the file name, file keys and record identifier of where the DDN data value will be stored, and stores the record containing the DDN value using the created file reference. To lookup a data value for a specific DDN, the system looks' up the file where the
  • DDN data value is located. Once the file is known, the system use the file structure 54 to look up the keys needed, the record where the data value for that DDN is stored, and the DDN position in the record. The system then creates a reference on-the-fly using the file name, file keys and record identifier where in the DDN data value is stored, extracts the record from data 36 using the created file reference, and extracts the data value from the record using the DDN position.
  • a screen display process demonstrates how the screen elements 38, in conjunction with data manager 42 and data 36, transfer to a downloaded applet to generate a screen interface for use at a remote site.
  • Screen elements 38 stores the information that creates the screen frames and keeps track of the screen components on the frame. It also stores any DDN's associated with the various screen components. The following is a non-exclusive list of screen frame properties that may be sent to the downloaded applet for processing: AssignAppNumber
  • Control box code that will be executed when the user executes an appropriate control event (preferably the X control button) on the frame.
  • ExecuteOnlnit Identifies Control box code that will be executed once the frame has been completely drawn.
  • Event Allows an event to be placed on every component within the frame. This is typically used to enable shortcut keys within the frame.
  • This name can be used to identify the frame for future commands.
  • This parameter Indicates whether or not the user can resize the frame, although default frames are typically not resizable. This parameter may be True or False.
  • Frame positioning is preferably specified in pixel offset from 0.
  • the top left pixel on the screen is preferably X position 0.
  • Frame positioning is preferably specified in pixel offset from 0.
  • the top left pixel on the screen is preferably Y position 0
  • Several supported screen components may be sent to the downloaded applet and applied to a screen frame on the remote site. Non-limiting examples include: Button
  • a button is a raised area on the screen that when pressed will initiate a given action.
  • Check Box A check box is a component that has either an on or off (checked or unchecked) value.
  • Choice allows the user to select from a drop down list of choices. Preferably, only one item from the list can be selected. Horizontal Line
  • List is a rectangular component that displays a list of items for the user to select from. The user may select one or more items depending on how the component is configured.
  • Numeric Spinners allow the user to select a single number from a predefined range.
  • the box may be made to appear raised or lowered, giving a 3D appearance.
  • Text Areas allow multi-line text to be entered.
  • Control box program 40 generates a screen as follows. The system looks up the different screen frame properties (described above) for the screen display requested and sends pseudo code based on the frame properties to the downloaded applet at the remote site. The system then looks up the different screen components (described above) for the requested screen. If a screen component has an associated DDN, the DDN properties are looked up in the data dictionary 50. The system may also look up the data value associated with the DDN, using the data management process (described above). The system sends pseudo code based on the screen components, DDN properties and DDN data values to the downloaded applet at the remote site.
  • control box program 40 When the control box program 40 is finished with the triggered event, it sends a process-completed flag to the downloaded applet.
  • the applet interprets all of the received screen display pseudo code sent to generate a user screen, which will appear to generate the screen display all at once rather than component by component.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne le domaine des affichages sur écran électronique et celui du stockage et de l'extraction de données électroniques. Le dispositif de l'invention comprend plusieurs sites à distance, un serveur Web, ainsi qu'un serveur de base de données, ce dernier comportant un programme contenant une série de commandes servant à produire et interpréter un pseudo code. Un utilisateur situé dans un endroit à distance utilise un navigateur Web sur son PC ou poste de travail afin d'accéder à un serveur Web hébergeant une base de données, une application et un outil logiciel de mise en oeuvre. Après que le navigateur Web spécifique de l'utilisateur ait été identifié, le serveur Web télécharge un applet spécifique de ce navigateur, l'applet téléchargé servant de moteur d'écran et affichant un écran d'entrée de données sur le PC ou poste de travail de l'utilisateur, lequel entre des données dans un champ de l'écran d'entrée de données et déclenche un événement reconnu par l'applet. L'applet répond à cet événement et, à l'aide de ses fonctions de moteur de distribution de données, évalue les données entrées dans le champ de données afin de déterminer leur conformité avec des critères prédéfinis pour le champ de données. L'applet transmet les données au serveur Web par l'intermédiaire de l'Internet/Intranet. Les données sont appliquées au programme contenant la série de commandes, lequel passe ces données à la base de données qui envoie une réponse au programme, celui-ci produisant alors un pseudo code transmis à son tour à l'applet, par l'intermédiaire de l'Internet/Intranet. L'applet met à jour un ou plusieurs champs dans un écran utilisateur existant ou peut produire un ou plusieurs affichages d'écran au moyen des informations qui lui sont renvoyées à partir du programme contenant la série de commandes.
EP01926933A 2000-04-17 2001-04-13 Procede et dispositif destines a des affichages sur ecran produits par des applets, et employant une base de donnees informatique et un langage de programmation Withdrawn EP1410248A2 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US19813500P 2000-04-17 2000-04-17
US198135P 2000-04-17
US22261400P 2000-08-02 2000-08-02
US222614P 2000-08-02
US67081400A 2000-09-28 2000-09-28
US670814 2000-09-28
PCT/US2001/012026 WO2001080056A2 (fr) 2000-04-17 2001-04-13 Procede et dispositif destines a des affichages sur ecran produits par des applets, et employant une base de donnees informatique et un langage de programmation

Publications (1)

Publication Number Publication Date
EP1410248A2 true EP1410248A2 (fr) 2004-04-21

Family

ID=27393838

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01926933A Withdrawn EP1410248A2 (fr) 2000-04-17 2001-04-13 Procede et dispositif destines a des affichages sur ecran produits par des applets, et employant une base de donnees informatique et un langage de programmation

Country Status (3)

Country Link
EP (1) EP1410248A2 (fr)
AU (1) AU2001253434A1 (fr)
WO (1) WO2001080056A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120173267A1 (en) * 2010-12-31 2012-07-05 Julian Omidi Database System for Medical Back-Office
CN102880708B (zh) * 2012-09-28 2016-05-04 用友网络科技股份有限公司 用于实现html页面的可视化设计的系统和方法

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701451A (en) * 1995-06-07 1997-12-23 International Business Machines Corporation Method for fulfilling requests of a web browser
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software
US5966126A (en) * 1996-12-23 1999-10-12 Szabo; Andrew J. Graphic user interface for database system
US6470386B1 (en) * 1997-09-26 2002-10-22 Worldcom, Inc. Integrated proxy interface for web based telecommunications management tools
GB9909599D0 (en) * 1998-05-14 1999-06-23 Peopledoc Ltd A document storing and retrieving system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO0180056A3 *

Also Published As

Publication number Publication date
WO2001080056A3 (fr) 2004-02-19
WO2001080056A2 (fr) 2001-10-25
AU2001253434A1 (en) 2001-10-30

Similar Documents

Publication Publication Date Title
US9454609B2 (en) Data source-independent search system architecture
US8806345B2 (en) Information exchange using generic data streams
JP4437918B2 (ja) 選択的に情報を検索しその後その情報の表示を可能にする装置および方法
US7013306B1 (en) XML input definition table for transforming XML data to internal format
EP1520225B1 (fr) Integration d'applications heterogenes
US7315853B2 (en) Service-oriented architecture for accessing reports in legacy systems
US20020169789A1 (en) System and method for accessing, organizing, and presenting data
US9697181B2 (en) Centralized field rendering system and method
US20020026441A1 (en) System and method for integrating multiple applications
WO1997015018A1 (fr) Procede et systeme permettant un acces homogene a des informations heterogenes
WO2005024629A2 (fr) Procede et systeme a agent extensible
US20020091818A1 (en) Technique and tools for high-level rule-based customizable data extraction
EP1652071A2 (fr) Systeme et methode pour une generation dynamique d'une interface d'utilisateur graphique
US20060004854A1 (en) Bi-directional data mapping tool
US20070198987A1 (en) API for obtaining unambiguous representation of objects in a relational database
US7158967B1 (en) XML output definition table for transferring internal data into XML document
US20090171997A1 (en) Method and system for obtaining user data having user-defined data types
US20080172601A1 (en) Tool for configuring available functions of an application
US7519578B2 (en) Ubiquitous search framework
US7861253B1 (en) Systems and methods for accessing a business intelligence system through a business productivity client
US10534588B2 (en) Data processing simulator with simulator module and data elements
EP1410248A2 (fr) Procede et dispositif destines a des affichages sur ecran produits par des applets, et employant une base de donnees informatique et un langage de programmation
US7124135B1 (en) Step to access native script in a legacy database management system using XML message
US8204849B2 (en) Web product interface system and method
US7315868B1 (en) XML element to source mapping tree

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021115

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

17Q First examination report despatched

Effective date: 20040524

17Q First examination report despatched

Effective date: 20040524

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20070510