Mobile image capture and transmission of documents to a secure repository

Various methods and systems are provided for capture and transmission of images to a secure repository. In one example, among others, a method includes capturing an image of a document as an image file using a mobile device, adding metadata to the image file, and securely transmitting the image file to a server. The image file can be stored in a secure repository. In another example, a mobile device includes a secure transfer application that causes the mobile device to capture an image as an image file, add metadata to the image file, and transmit the image file to a server via a secure connection. The server may store the image file in a secure repository. In another example, a non-transitory computer-readable medium includes a program that captures an image, adds metadata to the image file, and transmits the image file securely to a server.

BACKGROUND

In general, healthcare institutions have large volumes of medical records containing protected health information (PHI). Insurance companies, government agencies, educational institutions and other medical groups need access to these records to verify billing, check compliance, monitor quality and conduct research. Current methods of transmitting these records are inefficient, unsecure and cost-intensive. Many transmittal processes still rely on outmoded technologies such as email, postal mail and fax.

SUMMARY

Embodiments of the present disclosure are related to automated document capture and secure transmittal and more particularly, to methods and systems for document image capture and secure transmittal using mobile devices. In accordance with various embodiments, methods and systems for document image capture on a mobile communication device are provided such that the image is optimized and enhanced for data extraction from the document as depicted. These methods and systems may comprise capturing an image of a document using a mobile communication device; adding metadata to the image file; transmitting the image securely to a server; and archiving the image in the secure repository for later retrieval. Additionally, these methods and systems may comprise capturing a first image of a document using the mobile communication device; automatically detecting the document within the image; geometrically correcting the image; binarizing the image; correcting the orientation of the image; correcting the size of the image; and outputting the resulting image of the document.

DETAILED DESCRIPTION

Disclosed herein are various embodiments of methods related to automated document capture and secure transmittal. Reference will now be made in detail to the description of the embodiments as illustrated in the drawings, wherein like reference numbers indicate like parts throughout the several views.

A software program or application (or “app”) may be executed by processing capabilities of a mobile device such as, e.g., a smart phone, tablet, personal digital assistant (PDA), or other appropriate mobile device. When executed by the model device, the application verifies the identity of the user through the use of, e.g., a username and password. In other embodiments, the user identity may be verified using movement patterns on an interactive display of the mobile device or by other biometric measurements. Once the user has logged in, the application allows the user to initiate document capture by providing a form on which the user can enter metadata pertinent to the document such as patient name or image type. In some cases, the metadata may be entered through a visual input such as, e.g., a quick response (QR) code. The user enters data and, when the form is completed, is directed to a capture page where the view through a built-in camera of the mobile device is displayed. The user orients the camera to provide the best image quality and presses an on-screen button to capture the document image. The user then reviews the image and if necessary may discard the image and then take another picture of the document. Once the user is satisfied with the image quality, the image can be saved to an encrypted storage or memory on the file system of the mobile device.

In some cases, the user may capture images of one or more documents and save them to a secure encrypted storage on the mobile device. By storing the images in the secure encrypted storage, the document images are not visible to the operating system of the mobile device and may only be viewed by the user once their credentials are verified and they are logged-in to the application. Thus, the user may create a collection of documents for transmission to a secure repository on a remote server. Once images of the documents are captured and annotated with metadata, the user may “save” the scanned images to the secure geographically-remote repository. A “save images” icon may be provided on the mobile device for the user.

Once the “save images” button is pressed on the touch screen, an SSL-encrypted connection can be opened to the remote server. The connection may be, e.g., a cellular link, WiFi link, Bluetooth link, or other wireless or wired communication link. The application may check for connectivity before transmission is initiated. After the communication link has been verified, the document images are transmitted using, e.g., a messaging format, which provides for data validation. After the remote server accepts the images, multiple copies of the document images may be stored on redundant storage media and notice is returned to the user that the transmission was successful. The captured images may be automatically deleted after successful transfer. If the download is unsuccessful, a notification such as, e.g., a text message or prompt from the mobile device is provided to the user. The document images that have not been transferred can be retained on the mobile device for subsequent transfer.

Other features and advantages of the present disclosure should become apparent from the following description of an example of the capture and secure transmission of document images, taken in conjunction with the flowchart ofFIGS. 1A and 1B, which illustrate, by way of example, the principles of the disclosure. Referring toFIG. 1A, shown is a first portion of the flowchart100. Beginning with block103, the user obtains a document for scanning and transmission to the secure repository. The user may launch the application (or “app”) on the mobile device in block106.FIG. 2Aillustrates a mobile device200with an example of an icon or “button”203rendered on the display, which may be selected by the user to initiate the application. When the application is launched, a login screen is presented on the mobile device200in block109to verify the identity of the user.FIG. 2Billustrates the mobile device200with an example of a login screen206rendered on the display. The login screen206may allow for entering user identification information or credentials such as, e.g., a Facility ID (identification)209, a Username212and/or a Password215. Various options may also be initiated from the login screen206by, e.g., selecting an options icon218. For example, in block112ofFIG. 1Aan option may be presented on the mobile device display which allows the credentials of a user to be stored to facilitate future access to the scanned and/or stored documents by the user. If the option to save the credentials on the mobile device200is not selected in block112, the user enters identification information or credentials such as, e.g., the Facility ID209, Username212and/or Password215in block115.

If the user's credentials differ from the previously stored credentials, the user may create a new account in block118by selecting a “new account” button or icon that may be rendered on the display of the mobile device200. If the displayed credentials match the current user's credentials, the user can authenticate his or her identity in block121using, e.g., the appropriate username and password combination, finger-swipe pattern, voice recognition, biometric information (e.g., fingerprint or eye scan), or other form of authentication. In block124, the credentials can be transmitted to a remote authentication server using an SSL-encrypted secure channel for verification. If the credentials do not match the stored credentials on the remote authentication server in block127, then an invalid login message is returned to the application over the secure SSL channel and the application returns to the login screen in block109.

Referring now toFIG. 1B, if the credentials match the remote authentication server credentials for the user, then the main page is displayed on the mobile device200in block130. When a new account has been indicated, the Facility ID209, Username212, and/or other user settings may be stored in a local database or memory of the mobile device200in block133. From the main (or menu) page of block130, the user can select a “new capture” button or icon rendered on the mobile device200to obtain a document image. In block136, the user may be offered the option of capturing a new image or selecting a file from a secure data store (or repository) on the mobile device200. If the user chooses to obtain a document image from the secure local data store, a select dialog screen displaying thumbnails or other listing of document images awaiting transmittal is shown in block139.FIG. 2Cillustrates the mobile device200with an example of a select dialog screen221rendered on the display including a plurality of thumbnails of the stored document images224. The user may then select one or more documents224in block142ofFIG. 1Bfor secure transmittal to the remotely located secure repository. When the user completes his or her selection, a cancel or “done” button or icon227(FIG. 2C) may be selected. If the cancel or “done” button or icon227is “clicked” without the selection of a document224, the application may provide a “no image selected” confirmation in block145and the user is returned to block136where the user may again be offered the option of capturing a new image or selecting a file from the secure data store (or repository). In the select dialog screen221ofFIG. 2C, the user is offered the option to capture another image by selecting a “capture another” button or icon230.

If the camera capture option is selected in block136, the mobile device provides the user with a camera capture screen in block148.FIG. 2Dillustrates the mobile device200with an example of a camera capture screen233rendered on the display. The camera capture screen233may include a viewfinder with a select button or icon236. The user adjusts the mobile device until the document to be captured is fully in the frame and in focus and takes the picture by “clicking” the select button236. The capture screen233may include image boundary markers such as, e.g., brackets in the corners of the capture screen233to delineate the edges of the captured image. The capture screen233may also include other icons for controlling camera features such as, e.g., flash control and contrast. In some implementations, the mobile device200may automatically detect the document within the image and geometrically correct the image, binarize the image, correct the orientation of the image, and/or correct the size of the image. The captured image is displayed in the viewfinder and the user can select an accept button or icon239or a cancel button or icon242in block151ofFIG. 1B. If the captured image is not accepted in block151, then the application returns to the camera capture screen233(FIG. 2C) in block148.

If the captured image is accepted in block151, the application may display a metadata screen to obtain additional document information in block154ofFIG. 1B.FIG. 2Eillustrates the mobile device200with an example of a metadata screen245rendered on the display. The additional data may include the first name248, last name251, insurance identification254, date of birth257, or other information associated with the patient of the document. For example, the metadata screen245may include areas to add a description and/or comments regarding the image. A warning message may be provided to the user if no data has been entered to identify the image. If the user selects the “cancel” button or icon260, the application provides a cancellation indication in block157ofFIG. 1Band the user is returned to the main page in block130. If the additional data is entered by selecting the “next” button or icon263inFIG. 2E, the application may prompt the user to determine if an additional image should be captured.FIG. 2Fillustrates the mobile device200with an example of a capture prompt screen266rendered on the display, which provides the option to capture another image by selecting a “capture another” button or icon269or complete the image capture by selecting a “done” button or icon272. The application may allow multiple document images to be captured by the mobile device200before secure transmission to the remotely located secure repository. Referring back toFIG. 1B, when the user enters the metadata associated with the document(s), the user can initiate transmission by selecting a “send” button or icon in block160.

When an image is captured, the image file is saved in a private mode (MODE_PRIVATE) where only the application has access to the image file. The image file(s) can be maintained in a directory that is restricted to the application such that the user will not have access to the file system and/or image file. Access to the directory from outside of the application is excluded. Document information such as identifying information, descriptions and/or comments supplied by the user is also stored in the application specific directory. The image file(s) can be stored in the application specific directory until it is sent to the secure repository or the user no longer has access to the directory. For example, the user can lose access by a crash or power down of the application and/or mobile device200or a home key close or logout by the user may cashed the image file(s) for later access.

If the application and/or mobile device200crashes or powers down, then all references to the image files are lost. The image data will be removed from memory because the image data only exists within the running application. Selection of a home key (button or icon) may remove the application from the foreground or may close the application. If the application closes, then the image file(s) are removed. If selecting the home key simply removes the application from the foreground of the mobile device, then the image file(s) are retained for later access. Logout by the user deletes the document information (or data), but does not remove the images. In that case, the image file(s) can be deleted after logging back in and sending the image file(s) to the secure repository. When the application is uninstalled from the mobile device200, all data and image files associated with application will be removed from the mobile device200.

Although the flow chart ofFIGS. 1A and 1Bshows a specific order of execution, the order of execution may differ from that which is depicted. For example, after the user's identity is verified through the login screen, the user may be able to select between securely transmitting one or more document image to the remotely located secure repository or to logout or exit the application from the main (or menu) page. When sending to the repository is selected, a metadata screen may be presented that is configured to allow the user to enter identifying information, descriptions and/or comments regarding the document image that will be captured. If no data is entered by the user before continuing to image capture, a warning message may be presented. For example, the warning message may indicate the benefit of adding information for subsequent identification of the image. The warning message may include the ability to return to the metadata screen to enter data or proceed without user provided information. If a group of document images are captured together, the identifying information, description and/or comments may be applied to all images of the group. Information for each document image may be subsequently edited.

A camera capture screen may then be provided to capture a document image. The capture screen may include image boundary markers such as, e.g., brackets in the corners of the camera capture screen to delineate the edges of the captured image. A button or icon may be presented on the camera capture screen to initiate image capture by the user. The camera capture screen may also include icons for controlling camera features such as, e.g., turning on or off the camera flash, adjusting image contrast, or selecting capture of color or black/white images. The captured document image may then be displayed (e.g., in a preview screen) with options to retake or accept the captured image. By selecting a “retake” button or icon, the user is returned to the camera capture screen. The user may accept the captured image by selecting a “done” button or icon.

Once the image has been accepted, the application may prompt the user to determine if an additional image should be captured. For example, a capture prompt screen may be rendered on the display that provides the option to capture another document image by selecting an “capture another” or “add image” button or icon. The capture prompt screen may also include an option to edit the identifying information, descriptions and/or comments associated with the document image. In some embodiments, a listing of the document images transferred to the secure repository may be displayed with, e.g., user name, creation date, etc. to allow selection for editing the data. The image capture may be completed by selecting a button or icon to initiate sending the image(s) to the secure repository.

Referring back toFIG. 1B, the user can initiate transmission by selecting a “send” button or icon in block160. The application checks for an active connection such as, e.g., a active TCP/IP connection in block163and if one is available, the documents can be sent as a secure message over SSL and the progress bar (or other indication) is displayed.FIG. 2Gillustrates the mobile device200with an example of a transfer progress bar275rendered on the display. If a connection is not available in block163ofFIG. 1B, the application may notify the user that service is unavailable in block166. In some implementations, the application may prompt to see if the availability of an active TCP/IP connection should be reconfirmed before returning to the main page in block130. Once the progress bar reaches 100% in block163, a success or failure message can be transmitted from the remote secure server to the app. If the upload failed, a notification is provided to the user in block166and the application can return to the main page in block130. If the secure transfer to the secure servers was successful in block169, copies of the transferred documents may be distributed in block172to multiple databases within the secure repository for redundancy. The captured images may be automatically deleted from the mobile device200after successful transfer. Once a document is stored securely, a message can be sent in block175by the remote server and displayed to the user on the mobile device200or through other appropriate notification avenues in block172before returning to the main page in block130.FIG. 2Hillustrates the mobile device200with an example of a transfer confirmation278rendered on the display. The transfer confirmation may include confirmation identification information for later reference.

With reference now toFIG. 3, shown is a schematic block diagram of a mobile device300that may be used to implement automated document capture and secure transmittal according to various embodiments of the present disclosure. The mobile device300includes at least one processor circuit, for example, having a processor303and a memory306, both of which are coupled to a local interface309. To this end, the mobile device300may comprise, for example, at least one smart phone, tablet, computer, or like device. The local interface309may comprise, for example, a data bus with an accompanying address/control bus or other bus structure as can be appreciated. The mobile device300includes a display for rendering of generated graphics such as, e.g., a user interface and an input interface such, e.g., a touch screen to allow for user input. In addition, the mobile device300includes communication interfaces (not shown) that allow the mobile device300to communicatively couple with other devices such as, e.g., components of a communication network. The communication interfaces may include one or more wireless connection(s) such as, e.g., Bluetooth or other radio frequency (RF) connection and/or one or more wired connection(s).

Stored in the memory306are both data and several components that are executable by the processor303. The memory306may include a data store312, which may be capable of secure encrypted storage of data. In particular, stored in the memory306and executable by the processor303are a secure document capture and transmission application315, an operating system318, and/or other applications321. It is understood that there may be other applications that are stored in the memory306and are executable by the processor303as can be appreciated. Where any component discussed herein is implemented in the form of software, any one of a number of programming languages may be employed such as, for example, C, C++, C#, Objective C, Java®, JavaScript®, Perl, PHP, Visual Basic®, Python®, Ruby, Delphi®, Flash®, or other programming languages.

A number of software components are stored in the memory306and are executable by the processor303. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor303. Examples of executable programs may be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory306and run by the processor303, source code that may be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory306and executed by the processor303, or source code that may be interpreted by another executable program to generate instructions in a random access portion of the memory306to be executed by the processor303, etc. An executable program may be stored in any portion or component of the memory306including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

Also, the processor303may represent multiple processors303and the memory306may represent multiple memories306that operate in parallel processing circuits, respectively. In such a case, the local interface309may be an appropriate network that facilitates communication between any two of the multiple processors303, between any processor303and any of the memories306, or between any two of the memories306, etc. The local interface309may comprise additional systems designed to coordinate this communication, including, for example, performing load balancing. The processor303may be of electrical or of some other available construction.