Method, apparatus and computer program to provide access to client records and data resources

A method, computer program and apparatus are disclosed that include accessing client data records, such as, medical records. The method may include receiving a data file at a server sent from at least one client and including client requirements. The method may also include storing the received data file locally at the server, executing an application that scans the server to determine if any new data files have been received. The method may also include storing the copied data file in a data folder stored in a file cluster, updating a table stored in a database to indicate that a new file has been stored, deleting the locally stored file from the server, and moving files specified by the client requirements from an export folder of the file cluster to the server so that the at least one client may access the exported files.

FIELD OF THE INVENTION

The present inventive concept is related to a data records configuration that allows clients to access their personal data records and to receive updated information pertaining to their personal records information.

BACKGROUND OF THE INVENTION

Conventional data record systems that provide client access to their personal records may be provided by a variety of different mediums and networking systems. One example of a data record system may be a telephony-based system which allows clients to access their personal record information by operating a telephone. For instance, a client may wish to access personal medical records stored in a remote database by calling a phone-based data record system and accessing their records via keypad entries or voice commands made over their telephones.

The telephony-based data record systems may provide access to client records through a remote web server and a corresponding database. For example,FIG. 1illustrates a conventional data record accessing system10A. Referring toFIG. 1, client100uses a hypertext transfer protocol script secure (HTTPS) web posting application to connect to a web server101over the network, which is illustrated by the network cloud that may represent a wide area network, the Internet, etc. Once a connection is established the client may send a data file to the web server101.

The data file is originally sent to the web server101which provides a connection to a file server102. After the file has been moved to the file server102, a record is generated based on the received file, and that record is sent to a database server, such as, for example, a SQL server103. The SQL server103receives the data file and a record may be generated and added to the SQL database in the SQL server103.

The file server102includes two server engines, which include a parser server engine102A and an image parser engine102B. These file server engines provide additional features for processing the data files which are sent to the file server102. For example, parser server102A may read and write the data files to the SQL cluster at the SQL server103. Other applications performed by the file server102may include file branding, storing and accessing of appointment file information and voice files (i.e., VCE files).

The SQL sever103may also provide additional applications, such as, a parse queue to parse data received from the data file, appointment data organization and storage, email applications for sending reminders to individuals including bulk email, news letter creation and updating procedures, after hours data access services for clients, and short messaging services (SMS) for clients.

The parser server102A may also parse information for the client, such as, appointment data, and then format the appointment data for storage in appointment tables. The image parser may obtain image information stored in a remote storage unit104, which may be a database of pre-stored data records, for example, dental records, medical records, x-rays, client chart information, etc.

After data has been stored and processed by the data record accessing system10A, the clients may access the data records by using an internet portal link to connect to the web server101and access client data records. For example, a client may access pre-stored records to obtain appointment information of an approaching doctor appointment based on client data records previously stored in the appointment tables by the file server102and the parser server102A.

Upon accessing the client's records, certain information may be provided automatically or in response to a request submitted by the client accessing the client's records. For instance, images that are stored in the storage104and that are associated with the client's personal data may be offered to the client and downloaded to the client's terminal device (not shown).

A similar access scheme may be performed by a client calling in over a telephone to a telephone server106, which includes an engine106A and a voice board106B. For example, after the offices are closed, clients may desire to access their personal data records so that certain information may be confirmed, such as, their appointment time for their next doctor visit.

The engine106A and the voice board106B provide the clients with the necessary options to access their personal information. The client may access appointment information and pre-recorded voice file (VCE) information from the file server102regarding personal record information. In addition, the telephone server106may provide an emergency service that calls the clients when their related personal medical information requires immediate attention. The emergency notifications may also be provided by e-mail, text messaging and other notification techniques via the e-mail server105.

The conventional data record accessing system10A performs data record storage and accessing options without anticipating changes to the clients' needs and without providing a dynamic updating platform. Clients need access to all of their personal records, and also need to update their personal records based on the changes that may occur since their last information accessing session and/or during their current sessions with the data record assessing system.

SUMMARY OF THE INVENTION

Disclosed is an optimized method, computer program and apparatus to access data records that allows clients to access their personal data records and to receive updated information pertaining to their personal records information.

One example embodiment of the present inventive concept is a method of handling incoming data files at a data file handling network. The method includes receiving a data file at a server, the file being sent from at least one client and including client requirements. The method also includes storing the received data file locally at the server. The method further includes executing an application that scans the server to determine if any new data files have been received since a prior scanning operation. The method also includes copying the data file, storing the copied data file in a data folder stored in a file cluster, updating a table stored in a database to indicate that a new file has been stored, and deleting the locally stored file from the server. The method further includes moving files specified by the client requirements from an export folder of the file cluster to the server so that the at least one client may access the exported files.

Another example embodiment according to the present inventive concept includes a server configured to handle incoming data files. The server includes a receiver configured to receive a data file, the file is sent from at least one client and including client requirements. The apparatus also includes a memory configured to store the received data file locally at the server. The apparatus further includes a processor configured to execute an application that scans the server to determine if any new data files have been received since a prior scanning operation, copy the data file, store the copied data file in a data folder stored in a file cluster, and update a table stored in a database to indicate that a new file has been stored. The apparatus is further configured to delete the locally stored file from the server, and locate the files specified by the client requirements from an export folder of the file cluster so that the at least one client may access the exported files.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 2illustrates a data record accessing system10B according to an example embodiment of the present inventive concept. Referring toFIG. 2, client100uses a web posting application to connect to a file transfer protocol (FTP) application server110over a network illustrated by the network cloud that may represent a wide area network, the Internet, etc. Once a connection is established, the client100may send a data file to the FTP post server110(which may also include a secure shell (SSH) application).

The data file is originally sent to the FTP post server110which provides a connection to a file server112. After the file has been moved to the file server112, a record is generated based on the received file, and that record is sent to a database server, such as, for example, a SQL server113. The SQL server113receives the data file and a record may be generated and added to the SQL database in the SQL server113.

The file server112includes multiple server engines, which include a parser server engine112A, an image parser engine112B, a pre-builder engine112C, a reporter engine112D and a call builder engine112E. The file server112may store VCE voice files and a CallQ.DBF file112G in its internal memory. Operations performed by file server112may include creation and updating of scheduling lists, auto scheduling of client applications and appointments, storing and accessing of common files associated with client information, creating and accessing of custom folders, and reporting of assets to clients.

The file server engines112A-112E provide additional features for processing the data files which are sent to the file server112. For example, parser server112A may read and write the data files to the SQL cluster at the SQL server113. The parser server112A may also parse information for the client, such as, appointment data, and then format the appointment data for storage in appointment tables. The schedule builder112B reviews schedules of clients and builds a record file database file (i.e., CallQ.dbf file112G).

The pre-builder112C builds the voice files (VCE files) for the clients' records so that the clients may access their records and listen to the voice files corresponding to their records. The pre-builder112C also performs a query for the scheduled call information that is setup by the schedule builder112B. The pre-builder will then create a new file build on the file server112for client access and for future updates.

The file server112may provide certain applications, such as, automatic scheduling of client appointment times, storing and accessing of common files needed for client resources, creating and updating of custom folders for client resources, etc. The file server112may also provide a reporter engine112E that reports resources to other components of the data accessing system10B and to the clients. Voice data may be accessed from the VCE voice files112F and other information may be accessed from the database file CallQ.dbf112G.

One example operation of the data accessing system10B is discussed in detail below. Next generation future phone calls are created at the telephone server117. Each of the telephone server lines will access another database file Schlist.dbf to determine schedule information for clients. The database file Schlist.dbf is also used to associate client information with the future calls and to access the existing file build in the file server112and/or create a new file build. Additionally, if data for a future call is not built on an existing file build, then, the call may be built on the file telephone server117.

The calls may then be made to a corresponding set of pre-established clients informing them of their personal information, schedule information, etc. The telephone server117may then initiate the calls to the client telephones or call accessing stations (i.e., mobile stations). Once the calls are dialed out, the calls may be further monitored by the telephone server117to track the calls progress. During the calls, the call status may be updated periodically and the call status information may be in the CallQ.dbf file112G on the file server112.

The reporter engine112D will query the schedule lists, discover the schedules that are complete and the corresponding client reports that are ready to be sent to the clients. Other operations of the reporter engine112D may include inserting the record into the SQL server113, which may offer a Histran application and an email queue service. The files that are ready to be transferred to clients are placed in an export file in the file server112. The export files are then sent via FTP, SSH, email, autodial applications, fax or a web posting application to the clients. In one example, the emails may be sent in bulk to the various clients in email notifications sent from the email server116. The FTP server110provides a file transfer protocol application that provides easy access to the clients' records.

FIG. 3illustrates a data record accessing system10C according to another example embodiment of the present inventive concept. Referring toFIG. 3, client100uses a web posting application to connect to web server120over a network illustrated by the network cloud that may represent a wide area network, the Internet, etc. Once a connection is established, the client100may send a data file to the web server120.

The data file is originally sent to the web120which provides a connection to a file server112. After the file has been moved to the file server112, a record is generated based on the received file, and that record is sent to a database server, such as, for example, a SQL server113. The SQL server113receives the data file and a record may be generated and added to the SQL database in the SQL server113.

The file server112includes multiple server engines, which include a parser server engine112A, an image parser engine112B, a pre-builder engine112C, a reporter engine112D and a call builder engine112E. The file server112may store VCE voice files and a CallQ.DBF file112G in its internal memory. Operations performed by file server112may include creation and updating of scheduling lists, auto scheduling of client applications and appointments, storing and accessing of common files associated with client information, creating and accessing of custom folders, and reporting of assets to clients.

The file server engines112A-112E provide additional features for processing the data files which are sent to the file server112. For example, parser server112A may read and write the data files to the SQL cluster at the SQL server113. The parser server112A may also parse information for the client, such as, appointment data, and then format the appointment data for storage in appointment tables. The schedule builder112B reviews schedules of clients and builds a record file database file (i.e., CallQ.dbf file112G).

The pre-builder112C builds the voice files (VCE files) for the clients' records so that the clients may access their records and listen to the voice files corresponding to their records. The pre-builder112C also performs a query for the scheduled call information that is setup by the schedule builder112B. The pre-builder will then create a new file build on the file server112for client access and for future updates.

In another example, pre-scheduled intervals may be used to perform the various operations of file server112. For example, the parser server112A may operate between 12 AM and 3 PM, the schedule builder112B may operate at mid-day after 3 PM until early evening, and the reporter112D may finalize and send out reports in the evening so that the clients are reminded of their next-day obligations the evening before their appointments.

The file server112may provide certain applications, such as, automatic scheduling of client appointment times, storing and accessing of common files needed for client resources, creating and updating of custom folders for client resources, etc. The file server112may also provide a reporter engine112E that reports resources to other components of the data accessing system10C and to the clients. Voice data may be accessed from the VCE voice files112F and other information may be accessed from the database file CallQ.dbf112G. One or more of these operations may be performed with foxpro and/or other data customization software applications.

One example operation of the data accessing system10C is discussed in detail below. Next generation future phone calls are created at the telephone server117. Each of the telephone server lines will access another database file Schlist.dbf to determine schedule information for clients. The database file Schlist.dbf is also used to associate client information with the future calls and to access the existing file build in the file server112and/or create a new file build. Additionally, if data for a future call is not built on an existing file build, then, the call may be built on the file telephone server117.

The calls may then be made to a corresponding set of pre-established clients informing them of their personal information, schedule information, etc. The telephone server117may then initiate the calls to the client telephones or call accessing stations (i.e., mobile stations). Once the calls are dialed out, the calls may be further monitored by the telephone server117to track the calls progress. During the calls, the call status may be updated periodically and the call status information may be in the CallQ.dbf file112G on the file server112.

The reporter engine112D will query the schedule lists, discover the schedules that are complete and the corresponding client reports that are ready to be sent to the clients. Other operations of the reporter engine112D may include inserting the record into the SQL server113, which may offer a Histran application and an email queue service. The files that are ready to be transferred to clients are placed in an export file in the file server112. The export files are then sent via email, autodial applications, fax or a web posting application to the clients. In one example, the emails may be sent in bulk to the various clients in email notifications sent from the email server116. The web server120provides a web portal application that provides easy access to the clients' records.

Another example embodiment of the present inventive concept is illustrated inFIG. 4. Referring toFIG. 4, operations of the data file accessing configuration may include receiving a data file at a file server comprising client records information (operation401). Other operations may include forwarding the file to a database and adding the file to a record in the database, (operation402), creating a database file and storing the database file on the file server (operation403), and scheduling a call to at least one client, the call including a portion of the information included in the received data file (operation404). Further operations may include performing the call to the at least one client (operation405), monitoring the call to determine if any additional information is provided from the at least one client during the course of the call (operation406), and updating the client records information stored in the database based on the additional information provided by the at least one client (operation407).

Examples of file handling procedures of incoming file data will no be described with reference toFIGS. 5 and 6.FIG. 5illustrates a data file handling system20A according to an example embodiment of the present inventive concept. Referring toFIG. 5, a FTP file is received from a client100similar to the example described above with reference toFIG. 2. However, inFIG. 5a local file transfer protocol, secure shell application and/or secure file transfer protocol (FTP/SSH/SFTP) server130is also included in the file handling system20A. The FTP/SSH/SFTP server may also be included in the file handling system ofFIG. 2, however, it was omitted from discussion for simplicity of the overall system.

In operation, once the FTP file is received, the file is stored on the FTP/SSH/SFTP server130locally for easy future access by other system components and applications. A FTP post application may then be executed to scan the FTP and SSH folders for new files to determine if any new files have been received since the last scan operation. The FTP post application may be stored in the computer readable medium of a separate server (i.e., FTP post server110) or may be integrated in the computer readable medium of the FTP/SSH/SFTP server130.

Any new files that are determined to be in the FTP/SSH/SFTP server130are copied and sent to a file cluster stored in the file server112. The file may be indexed and stored in a pre-specified data folder. The FTP post application then performs an update operation to a parse queue table stored in the SQL server111. The original file may then be deleted from the FTP/SSH/SFTP server130. The FTP post application may then move a file(s) that has been transferred to an export folder under the file cluster on the file server112back to the FTP/SSH/SFTP server130for client accessibility.

FIG. 6illustrates another data file handling system20B according to an example embodiment of the present inventive concept. Referring toFIG. 6, the client100uses a web posting application to connect to the web server120over a network illustrated by the network cloud that may represent a wide area network, the Internet, etc. Once a connection is established, the client100may send a FTP file to the web server120. The client100interacts with the web server120similar to the example described above with reference toFIG. 3.

Next, the received FTP file is stored in the file server112. The FTP file may be indexed and stored in a pre-specified data folder of a file cluster of the file server112. An update operation may then be performed to update the file record in the parse queue table stored in the SQL server111. The web server120may then acknowledge that the file has been received at the file server120by sending an acknowledgement message back towards the forwarding device that forwarded the FTP file, and/or back to the client100.

FIG. 7illustrates an example method700according to an example embodiment of the present inventive concept. Operation701includes receiving a data file at a server, the file being sent from at least one client and including client requirements. The method also includes operation702which includes storing the received data file locally at the server. The method further includes operation703which includes executing an application that scans the server to determine if any new data files have been received since a prior scanning operation. The method also includes operation704which includes copying the data file. The method also includes operation705which includes storing the copied data file in a data folder stored in a file cluster. Further operations include operation706which provides updating a table stored in a database to indicate that a new file has been stored. In addition, operation707provides deleting the locally stored file from the server, and moving files specified by the client requirements from an export folder of the file cluster to the server so that the at least one client may access the exported files.

The present inventive concept is preferably realized in a hardware device, such as, a computer, cellular phone, or other mobile terminal device etc. In other embodiments, the present invention may be realized in hardware, software, firmware or a combination of hardware, software and/or firmware.

The above example embodiments may also be implemented in software code and may be stored on a computer readable medium, such as, for example, non-volatile memory devices (e.g., RAM, ROM, hard disk etc.). The software code may be accessed from the computer readable medium and may be executed by a processor. The executed program may provide one or more of the features of the example embodiments.

While preferred embodiments of the present invention have been described, it is to be understood that the embodiments described are illustrative only and the scope of the invention is to be defined solely by the appended claims when considered with a full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms etc.) thereto.