JP7628545B2 - Method and apparatus for interacting with a medical worksheet - Patents.com - Google Patents

Description

[Cross-reference to related applications]

This application claims priority to U.S. Patent Application No. 16/706,244, filed December 6, 2019, which is a continuation-in-part of U.S. Patent Application No. 16/144,795, filed September 27, 2018, which claims priority to U.S. Provisional Patent Application No. 62/578,277, filed October 27, 2017, and which is incorporated herein by reference in its entirety.

The disclosed technology relates to point-of-care medical systems, and in particular to a system for completing patient care worksheets on a point-of-care ultrasound system without connecting to a live server.

During or at the end of most medical procedures, the physician or technician is asked to complete a form or worksheet that documents the examination that was performed. Such a worksheet can store basic information such as the patient's name, the physician's name, the type of procedure or imaging modality, the date and location. In addition, the electronic worksheet can also include still or video images taken during the examination, measurements, calculations or annotations, physician's notes, diagnosis, etc. The completed worksheet is stored in a system that can receive or accept DICOM (Digital Imaging and Communications in Medicine) protocols. In addition, some of the information in the completed worksheet can be used by a medical billing system to request payment for the procedure.

A physician or technician can complete the worksheet using a point-of-care medical system. The point-of-care medical system can be integrated with a medical device such as an ultrasound machine, can be operatively connected to such a medical device, either directly or via a network, or can be another computer system (e.g., a computer or tablet) that can run system software and receive worksheet input from a user. Existing point-of-care medical systems often come with a set of default, hard-coded worksheets. These are overly long or cumbersome for many situations, and as a result, physicians are unlikely to use them. In some cases, the worksheets can be customized by a clinic or practice group to reflect the desired workflow for a particular procedure. A worksheet server system facilitates the use and customization of the worksheets, and can download the worksheets to a remote computer or medical device, such as a point-of-care system. Additionally, the worksheet server or other system can receive the completed worksheet and other DICOM data entered into it, store the worksheet data and still or video images (e.g., in a picture archiving and communication system (PACS) system), and provide interactive input to a billing system. For example, one such worksheet server system may be the Sonosite Synchronicity available from FUJIFILM SonoSite, Inc. of Bothell, Washington, USA, and another may be the QPath E Tm server system available from Maple RidgenoTelexy Healthcare, Inc. of BC, Canada.

Prior art techniques required the point-of-care system to maintain a live network server connection so that the point-of-care system could download and display worksheets and sign off (approve for the next step in the data review workflow) on data entered into the worksheets for transmission to the server. If the connection is lost, when the point-of-care device is used in the field or in locations where the Internet or other computer communication connection is unavailable or unreliable, the worksheets cannot be viewed or completed until the connection is re-established.

The inventors have recognized a need for a technique that allows a user of a point-of-care system, such as an ultrasound point-of-care system, to interact with and complete a worksheet without a live connection to a worksheet server. The disclosed technique addresses this need in a point-of-care system that includes system software for interfacing with a browser component. The interface between the system software and the browser component allows the system software to retrieve worksheet data from the browser component and store it in local storage. The interface also allows the system software to retrieve stored worksheet data from local storage and to auto-populate worksheets in the browser component with the worksheet data. When an Internet or other computer communication connection is available, the point-of-care imaging system transmits the worksheet data to the server. As used herein, a "live" connection refers to the ability to communicate between two or more devices. For example, if a point-of-care imaging system can transmit a DICOM package to a server, for example, via the Internet, it has a live connection with that server. However, if the point-of-care imaging system attempts to connect to the server but is unable to do so, it does not have a live connection to the server.

In some embodiments, a point-of-care system may include system software that includes a browser component. The system software may include the browser component as an integrated element within its display while maintaining the look and feel of the system software. The browser component may render worksheets that have been previously stored in local storage of the point-of-care imaging system or may be dynamically retrieved from a worksheet server.

When a user opens a worksheet via the browser component, the point-of-care imaging system software can determine whether there is data associated with the worksheet stored locally in memory of the point-of-care imaging system. If so, the point-of-care imaging system system software can retrieve the local data and interface with the browser component to auto-populate fields in the worksheet. The user can then interact with the worksheet regardless of whether there is auto-populated data.

When a trigger event occurs to save the worksheet data, such as when a user performs an action that navigates away from the current Document Object Model (DOM), the system software of the point-of-care system can again interface with the browser component to retrieve the worksheet data entered into the worksheet fields. The data from the worksheet can be stored in local memory. If the worksheet is complete (e.g., it has been signed), the worksheet data can be incorporated into a DICOM package by entering the data from the worksheet and other relevant data into a "tag" in the DICOM package. A DICOM tag can be a standardized field defined for a particular type of data. In some embodiments, a DICOM package can include a "private" tag that can have various data structures that can be used by different organizations for different purposes. Although the data transfer described herein is described as using a DICOM package, other data encapsulations are also contemplated, such as JSON blobs or XML blocks. Once the DICOM package is complete, e.g., adding images, reports, other worksheet data, etc., the DICOM package can be added to a queue to be sent to the server when a live network connection is available.

In some embodiments, the interface between the system software element and the browser component element includes employing an intermediate component that interacts with both software elements. Worksheets provided in the browser component can use predefined functions (e.g., JavaScript functions) that provide information about the worksheet. The system software running on the point-of-care imaging device can be configured with the identity of these predefined functions, such as their names, arguments passed to the functions, and the type of results to be returned. The system software can use the intermediate component to obtain references to one or more predefined functions for an intended action, such as obtaining worksheet data or automatically populating the worksheet with specified fields. The intermediate component can use these references to execute the predefined functions in the browser component and obtain the results, if any. The results can be reformatted for use by the system software. When retrieving information from the worksheet, the system software can package the results of the functions into one or more private DICOM tags or other DICOM package fields.

In some embodiments, the intermediate component is a Component Object Model (COM). The COM may include a dispatch function to obtain a pointer reference in the DOM of the browser component, given the name of the function, parameters, and result data. The COM may also include an !Invoke function to execute the corresponding function using the pointer and obtain the results.

In some embodiments, the interface between the system software and the browser component can include injecting code into a script interpreter of the browser component. For example, to inject code, the code can be passed through an API of the browser component. The browser can execute the injected code, such as auto-filling worksheet values or retrieving filled worksheet values. The procedure for injecting code can provide a handle to the results. For example, the handle can be a return value from an API function call or a designated memory location accessible by the system software where the results are written.

Certain embodiments are directed to a method performed by a medical imaging device. The method can include retrieving data from a worksheet or form repository server. The data can include one or more fields of a customized worksheet or form. The one or more fields can be based on at least one of an identity of a user, a location of the medical imaging device, or a medical department using the medical imaging device. The method can also recreate the customized worksheet or form at the medical imaging device based on the received data and display the recreated customized worksheet or form on a graphical user interface connected to the medical imaging device. Additionally, the method can generate a medical image via the medical imaging device and automatically transfer the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

Certain non-limiting embodiments are directed to a medical imaging device. The medical imaging device may include at least one memory including computer program code and at least one processor. The computer program code, when executed by the at least one processor, may be configured to cause the client medical imaging device to retrieve data from a worksheet or form repository server. The data may include one or more fields of a customized worksheet or form. The one or more fields may be based on at least one of an identity of a user, a location of the medical imaging device, or a medical department using the medical imaging device. The computer program code, when executed by the at least one processor, may also be configured to cause the medical imaging device to recreate a customized worksheet or form at the medical imaging device based on the received data and display the recreated customized worksheet or form on a graphical user interface connected to the medical imaging device. Additionally, the computer program code, when executed by the at least one processor, may be configured to cause the client station to generate a medical image via the medical imaging device and automatically transfer the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

1 illustrates a system for allowing a user to complete a worksheet for an examination while disconnected from a worksheet server in accordance with some embodiments of the disclosed technology. FIG. 1 is a block diagram of a system for accessing information contained in a worksheet in accordance with some embodiments of the disclosed technology. FIG. 1 is a block diagram of a system for interacting with embedded JavaScript functionality by system software executing on a medical imaging device, in accordance with some embodiments of the disclosed technology. 1 is a flowchart of steps for interfacing between point-of-care system software and a browser component to extract or auto-populate worksheet data using an intermediary component in accordance with some embodiments of the disclosed technology. 1 is a flowchart of steps for interfacing between point-of-care system software and a browser component to extract or auto-populate worksheet data using code injection in accordance with some embodiments of the disclosed technology. 1 is a flowchart of steps performed by system software to manipulate a worksheet using local storage instead of a live server connection and transmit worksheet data depending on server availability in accordance with some embodiments of the disclosed technology. FIG. 1 is a block diagram of exemplary computer components for executing system software on a point-of-care medical imaging system in accordance with some embodiments of the disclosed technology. 1 is an example diagram showing the general architecture of a system according to a specific embodiment (part 1) . FIG. 1 illustrates a general architecture of a system according to certain embodiments. Example 2. FIG. 1 is an example diagram showing a portion of a system in accordance with certain embodiments; FIG. 2 is an example diagram showing a portion of a system in accordance with certain embodiments (part 2). FIG. 3 is an example diagram showing a portion of a system in accordance with certain embodiments; FIG. 4 is an example diagram showing a portion of a system in accordance with certain embodiments. FIG. 5 is an example diagram showing a portion of a system in accordance with a specific embodiment. FIG. 6 is an example diagram showing a portion of a system in accordance with certain embodiments. FIG. 1 is an example of a flow chart diagram in accordance with certain embodiments. 1 is an example of a flow diagram illustrating a method according to certain embodiments.

The ability to utilize and complete worksheets in an offline setting improves point-of-care medical devices for providers operating in the field or in settings where computer communication links are only periodic or suboptimal. For example, an ultrasound machine operator may examine a patient in the field or in a remote clinic where there is no computer communication link with sufficient bandwidth to allow a connection between the ultrasound machine and a remote worksheet server for the entire duration of the examination. Alternatively, a medical imaging device may be used at the patient's bedside without a cable or wireless connection to a computer communication link. Sometimes, in an operating room or other acute care situation, a cabled network connection may not be practical, and wireless transmissions and connections in these environments may be limited by requirements such as conflicting hospital policies. In existing systems, if a physician does not have access to a live network connection, the physician or assistant takes notes during the examination and writes them later on the worksheet when a connection is available. Such a process slows workflow, requires additional labor, and introduces potential errors as data is recorded and transferred to an electronic format.

To address these and other problems, the disclosed technology provides interactive input to a worksheet on a point-of-care system without a live connection to a remote worksheet server.

Many ultrasound point-of-care systems are used by physicians, not full-time sonographers, typically in emergency care. Physicians who are not full-time sonographers perform scans as part of the larger imaging care they provide to emergency (unscheduled) patients. Currently, there is no national or global credentialing system for these physicians. Therefore, each hospital must develop its own policy to determine that physicians have the necessary proficiency to operate the equipment. One advantage of the technology disclosed herein is that it can be used by hospitals to record training time and QA/training physician testing until proof of reliability is achieved in various applications. The disclosed technology aids in recording such testing by allowing physicians to complete a worksheet after each test.

It is also known that in emergency use, approximately 90% of ultrasound scans are not billed. In order to bill for services rendered, the medical service provider must be able to show that the attending physician is certified so that the attending physician can bill for the exam. Physicians are busy and do not have the time to record exams from each modality, so no revenue is generated. The disclosed technology provides a way to automatically obtain and pass to the billing system the answer to the question, "What ultrasound exams were performed on this patient that led to the diagnosis and treatment?" This information can be secured through a completed worksheet so that the hospital or other service provider can bill for the services rendered.

Organizations can create customized sets of worksheets tailored to different departments, such as emergency medicine or radiology, and the most common types of procedures performed. This makes it easier to use such customized worksheets than the default software-embedded worksheets that are impractical, rarely used, and not appropriate for one-size-fits-all approaches.

The disclosed technology allows a physician to complete a worksheet, record their notes, and "sign off" on the worksheet as the exam is being performed, without being connected to active computer communications and without having to sign on to a remote server, such as a Qpath E server, at the end of the exam (or end of the day).

Figure 1 is a block diagram of an ultrasound point-of-care system 10 in accordance with some embodiments of the disclosed technology. However, the disclosed technology can be used with other medical devices that employ worksheets (e.g., electrocardiogram devices, PET scanners, x-ray devices, etc.).

In the illustrated embodiment, the point-of-care system 10 is connected to a worksheet server 20 by a computer communications connection 15. The point-of-care system 10 includes one or more processors (not shown) configured to execute programmed instructions ("system software") stored in computer readable memory to control the operation of the imaging system. The communications connection 15 to the worksheet server 20 may be a private wired or wireless LAN, or a public network such as the Internet. The worksheet server 20 stores a large number of worksheets that can be customized for a particular user, machine, group of machines, or generically across an entire organization. A user can edit the worksheets, for example, to include their own clinic logo on the form, or to make more practical changes such as determining what information or fields to include or not include and in what order, space for physician or technician notes, and areas for making measurements or calculations.

The worksheet server 20 can store the completed worksheet data in a DICOM (Digital Imaging and Communications in Medicine) archive. DICOM is a standard for handling, storing, printing, and transmitting information in medical images and records. It includes file format definitions and network communication protocols. The information in the worksheet can be sent to an electronic medical record (EMR) and billing system 30 by the DICOM archive. In addition, images or video clips acquired during the exam can be stored on a picture archiving and communication system (PACS) system 40. In some embodiments, once the patient record is on the DICOM archive, the worksheet server 20 pulls back the referenced information from the EMR system 30 and the PACS system 40.

Once connected to the worksheet server 20, the ultrasound imaging system receives worksheets and other information as well as custom server commands via the computer communication connection 15. In various embodiments, the worksheets can be retrieved at various times, such as when the worksheets are loaded into the point-of-care system, in response to an administrator command (i.e., a "pull" operation) at the point-of-care system, or periodically, such as by "pushing" from the worksheet server. The worksheets can be sent to the ultrasound imaging device from the worksheet server 20 in a browser-readable format such as HTML. In some embodiments, the worksheets can include JavaScript. In some cases, the worksheets can include references to other content such as images, scripts, CSS files, etc. These references can be network-based, but can also be downloaded locally to the point-of-care system. For example, if a live network connection is available, the worksheet and any referenced items can be downloaded and stored in the local memory of the point-of-care system. The worksheets can be used by the point-of-care system whether or not a live network connection is available, because the worksheets and items referenced by the worksheets are available locally.

A browser component executed by system software running on the point-of-care system 10 can display the worksheet and allow the user to enter data, attach images or video clips, and electronically sign the worksheet. Once the user has completed the worksheet, the entered data, images, and video clips can be sent back to the worksheet server 20 for storage in the DICOM archive server once a computer communication connection is established.

In some embodiments, once a user signs a worksheet in the browser component, the browser component may submit the worksheet, such as by submitting a form that encapsulates the worksheet. However, this option is not available if there is no live network connection to the server. As noted above, conventional systems are designed to operate in a browser environment where worksheets received from a worksheet server 20 are continuously connected to the worksheet server 20 via an active computer communications connection 15. If the communications line fails or becomes unavailable, information entered into the worksheet and not yet saved may be lost. Additionally, switching between worksheets may cause data errors or data loss.

To allow point-of-care system operators to complete worksheets when not connected to a worksheet server 20, the disclosed technology provides a mechanism by which system software running on the point-of-care system 10 can execute HTML-related functions (e.g., JavaScript functions) for a particular worksheet. Once retrieved, the system software can encapsulate the worksheet data into a DICOM package, for example as one or more private tags or into standard DICOM fields, and queue the DICOM package in an outbound queue for transmission to the server once a live network connection is available. In some embodiments, the system software interfaces with a browser component to extract the worksheet data, regardless of whether a live network connection is available. In other embodiments, the browser component transmits the worksheet data directly if a live network connection is available, or interfaces with the system software if a live network connection is not available.

FIG. 2 is a block diagram of a system for allowing a user to complete a previously downloaded worksheet from a remote worksheet server without a live connection to the remote server. In the illustrated embodiment, a worksheet server 20 connects to a point-of-care system 10 using a communications connection 15. A local memory 100 in the point-of-care system 10 stores HTML and other files that define one or more worksheets received from the worksheet server 20.

The system software 25 on the point-of-care system 10 includes a browser component 120 that allows the user to view and interact with the worksheet. The browser component allows the user to enter information, take and record measurements, and sign the worksheet. The browser component or system software can also be used to associate video clips, still images, or other information with the worksheet data.

As will be appreciated by those skilled in the art, the worksheet received from the worksheet server may contain or reference a number of functions (e.g., JavaScript) that provide information about the worksheet to be rendered in the browser. For example, functions may generate drop-down menus, control radio buttons, display checkboxes, and perform other operations that control how the worksheet is displayed. Some functions may provide metadata about the worksheet, such as if any information was included in the form, if it was signed by the physician or technician performing the exam, etc. Such functions are generally designed to be within the browser component and do not communicate with external applications as other point-of-care system software does. The disclosed technology provides a way for such external software to execute these functions and obtain their results.

In accordance with some embodiments of the disclosed technology, the system software 25 of the point-of-care system uses an intermediate component (e.g., interface 35) to gain access to predefined functions contained in or referenced by the worksheet, or to connect the browser component to the interface to execute the functions by injecting the functions into the script interpreter of the browser component. In some embodiments, the interface 35 can be a Component Object Model (COM) interface provided by the operating system of the point-of-care system. In some embodiments, the interface includes the following functions that can be executed by the browser:

GetWorksheetData(): Gets the data of the user input on the form and any sign-off/approval authentication information encapsulated in a data object represented as a string. This packaged data is transferred to the worksheet server via DICOM encapsulation and private tags or by mapping the data to DICOM fields.
SetWorkSheetData(worksheetData): Sets the entire worksheet populated with data, including any sign-off/approval data, according to worksheetData, which can be an encapsulation of a data object (e.g. JSON) represented as a string.
IsWorksheetSigned(): Returns a Boolean value indicating whether the worksheet is signed.
IsWorksheetActive(): Returns a Boolean value indicating whether the worksheet has user-entered data saved or not.

As will be appreciated, other functions that provide the above information may also be used. Details of how to write such functions in HTML or JavaScript are believed to be known to those skilled in the art. In embodiments that use an intermediate component, the system software knows the function's identity, such as the function name, the types of variables passed to the function, what values and their types are expected to be returned from the function, the code line number, memory location, identifier number, parent object, or other identifying information. The intermediate component can use this information to gain access to execute these functions and obtain the results of the functions. In other embodiments, access can be gained by the system software directly injecting the functions into the script interpreter of the browser component and receiving the results generated in response.

This access allows the system software to obtain information that the user has entered into the worksheet in the browser component, as well as metadata about the worksheet itself. The system software stores the obtained information in local memory. This access also allows the system software to auto-populate the worksheet with data when the worksheet is reopened. In addition, the system can obtain information from the form as a step of entering portions of the information into corresponding standard DICOM fields or one or more private tags, and reconstruct the information as a DICOM file. The DICOM archive server can extract this information and the worksheet identification information to determine if the information pertains to a particular worksheet. The system software transmits the DICOM file once a live computer communication connection is established.

By enabling the system software to call these functions, the system software can retrieve the information entered into the worksheet and store it in local memory. The system software can then repackage the information into a DICOM file and send the information back to the DICOM archive server once the computer communication connection is re-established. In some embodiments, the system software stores the DICOM information for each worksheet periodically and also when it is closed. If the worksheet is reopened before the information has been sent to the worksheet server 20, the system can call a JavaScript command to restore the information to the worksheet's previous state, allowing the doctor or technician to finish the report.

In another embodiment, information about the worksheet being rendered by the browser component is obtained not by invoking an embedded script, but by injecting additional script into the HTML DOM using supported functions specific to some browser components, such as those used in the WPF and UWP platforms.

Figure 3 provides further details on how the system software can use the intermediate component to interact with the browser component to retrieve information about the worksheet, according to some embodiments of the disclosed technology. The information required to render the worksheet by the browser component is retrieved from the worksheet server 20 and stored in the local memory of the medical imaging device. The information that makes up the worksheet can include HTML text files, JavaScript files, Cascading Style Sheets (CSS) files, or media (image, audio, video, etc.) files. These files can be stored in a directory (and subdirectories, if necessary) of storage on the local disk on the medical imaging device. When the user selects a worksheet using the graphical user interface, the browser component loads the worksheet information and creates a Document Object Model (DOM) that corresponds to the worksheet.

In the example shown in FIG. 3, to access information in the rendered worksheet's DOM, the system software uses a Component Object Model (COM) intermediate interface that provides the Dispatch and !Invoke commands. In COM, Dispatch can be used to obtain pointers to predefined JavaScript functions that provide information for the worksheet or auto-fill information. The system software can also set arguments expected by the function and define the expected results in a way that is understood by the COM interface. The system software then uses the !Invoke command to tell the COM intermediate component to request the execution of the function. Any results returned from the function are placed in a memory location in local memory 100 that is recognized by the system software.

Those skilled in the art will appreciate that the components of the illustrated block and flow diagrams may be modified in various ways. For example, the order of logic may be rearranged, substeps may be performed in parallel, and illustrated logic may be omitted or other logic may be included, for example. In some embodiments, one or more of the components described above may perform one or more of the processes described below.

Figure 4 illustrates in more detail the actions performed by system software to invoke a function in a DOM corresponding to a worksheet, in accordance with some embodiments of the disclosed technology. In some embodiments, the process of Figure 4 is implemented as a sub-process of block 610 or block 616 of the process shown in Figure 6.

Starting at 200, the system software calls the Dispatch function of the COM interface to get a pointer to the DOM currently loaded in the browser component. The pointer provides a handle to the currently rendered worksheet. If the user is switching between worksheets, the pointer can be saved and the correct pointer for the currently rendered worksheet will be used.

At 210, the system software calls the Dispatch function of the COM interface to obtain a pointer to the portion of the DOM that contains the script function. In some embodiments, obtaining the pointer to the portion of the DOM that contains the script function can be based on a pointer to the currently loaded DOM. For example, the pointer to the currently loaded DOM can provide a scope or other context for the function that obtains the pointer to the portion of the DOM that contains the script function. In some embodiments, the script is JavaScript, although other script types can be used. For example, script and other languages such as VBScript, AJAX, jQuery, C#, Java, etc. can be used.

At 220, the system software calls the Dispatch function, passing in an identification of one of the worksheet's functions to obtain a pointer to that function. As discussed above, the identifier can include names of those functions that the system software knows in advance. In some embodiments, the system software asks the Dispatch function to return a pointer to one or more JavaScript functions named "GetWorksheetData()", "SetWorkSheetData(worksheetData)", "IsWorksheetSigned()", and "IsWorksheetActive()" for the current DOM in the browser component. The functions can be named anything that the system software knows, but this naming convention is used herein as an example so that one of ordinary skill in the art can use these names to predict which functions will be executed and how they can be created. It will be appreciated that in some embodiments, obtaining a pointer to the identified function can be based on a pointer to the portion of the DOM that contains the script functions. For example, a pointer to a portion of the DOM that contains a script function can provide a scope or other context for a function that obtains a pointer to a specified function.

The types of variables used and returned by these functions (e.g., JavaScript) may not be the same as those used by the COM interface. Thus, in disclosed embodiments, parameters passed to and returned from the functions can be converted to types understood by the COM interface. At 230, the system software constructs the function call as a collection of COM compatible values (VARIANT type). In some embodiments, the function call is created as a structure. For example,
JavaScript function:
FunctionName (Argl , Arg2, Arg 3 etc)
It can be encoded as a struct:
COM:
JavaScript function name string
BSTR(FunctionName)
Parameter List
BSTR (string arguments)
Or VARIANT type
VARIANT_Bool, VARIANT Numeric units

At 240, the system software instructs COM to execute a function using the !Invoke COM interface. For example, to execute the GetWorksheetData() function, the COM interface is instructed to execute the following pseudocode:
{
Creates a COM VARIANT structure/union for the script function's return value varResult.
Creates a COM BSTR strFunc that represents the name of the script function to execute and sets it to "GetWorksheetData".
Creates and sets a COM BSTR representing the empty string for the script function's input parameter paraml.
Creates a COM dispatch parameter structure/union for the arguments to the script function dispparams.
Adds a single parameter, paraml, to dispparams.
if(no document pointer, pDisp) {
// A new document is loaded into the browser component.
Creates a COM dispatch pointer to the currently loaded HTML document and stores it in pDisp.
}
pDisp is used to obtain a COM dispatch pointer to the script section of the HTML document pScript.
Uses pScript to find the script function specified by strFunc and generates its dispatch identifier, dispid.
Uses pScript and COM Invoke to execute the script function dispid with arguments dispparams and return varResult.
Wait for the script function to complete and for the COM interface to copy the result into varResult.
The expected return result of this script function is a string result, so convert the BSTR part of varResult to a string (such as char*) that can be used by the system software.
}

At 250, the results (if any) of the called function in the current DOM are stored in memory in the structure used to call the function and converted from the format used by the COM interface to the format used by the system software. For example, a BSTR used by the COM interface containing data in JSON format can be converted to a character array char[], char* for strings used by the system software.

Figure 5 illustrates in more detail the actions taken by system software to inject a function into a browser component that implements a worksheet, in accordance with some embodiments of the disclosed technology. In some embodiments, the process of Figure 5 is implemented as a sub-process of blocks 610 or 616 of the process shown in Figure 6.

In block 502, the system software of the point-of-care system can inject code (e.g., JavaScript) into the browser component for the scripting interpreter of the browser component. In various embodiments, the injection of code into the browser can be performed using calls to APIs provided by the browser component, using a plug-in installed to the browser component and configured to receive scripts and inject them into the script section of a worksheet, by accessing an Active DOM in the browser component and adding script code thereto, or by adding and executing the code through an access point of the browser component, such as the URL bar. In any case, the injection of code into the browser component can have one or more handles for obtaining the results (if any) of the injected code. For example, the result handle can be a return value from an API or plug-in function call, a memory location shared between the browser component and the system software that the injected code is configured to write to, a call made by the injected code to a web service local to the point-of-care system, or the system software can be configured to intercept outgoing requests from the browser component and locally process requests that have an identifier (e.g., a specified destination, port, etc.) that indicates they are from the injected code.

At block 504, the browser component may execute the injected code. As described above, the injected code may include one or more functions equivalent to the GetWorksheetData(), SetWorkSheetData(worksheetData), IsWorksheetSigned(), or the IsWorksheetActive() functions described above.

In some embodiments, blocks 506 and 508, which are shown in dashed lines, may be executed only if the injected code is expected to produce a result. In block 506, the system software may use a handle for the type of code injection used to obtain the result of the executed code.

In some embodiments, the system software can receive function call return values for API or plug-in function calls. In other embodiments, the system software can be configured to read from a memory location shared between the browser component and the system software, to which the injected code writes the results. In yet other embodiments, the injected code can include an operation that makes a network request (e.g., an operation in JavaScript using XMLHttpRequest()), where the request is directed to a local web service for the point-of-care system, and data encapsulated in the request (e.g., as GET data or POST data) can be extracted by a script hosted by the local web service. Additionally, the system software can intercept outgoing requests from the browser component to extract data encapsulated in the request.

At block 508, the results from the injected code may be converted into a format usable by the system software. For example, the results may be a string representation of the results, such as a JSON data string. In some embodiments, the string may be tokenized and values may be made available with specific keys, for example, by mapping them to corresponding DICOM fields. In other embodiments, the entire string or values from the tokenized string may be encapsulated into a DICOM private tag.

Figure 6 is a flow chart of steps performed by system software to manipulate worksheets using local storage instead of a live server connection and to transmit data for the worksheet upon server availability in accordance with some embodiments of the disclosed technology. At block 602, the system software can retrieve worksheets from the worksheet server and store them in local memory. In various embodiments, retrieval of a version of the worksheet can be initiated by a request of the device (i.e., a "pull" operation) or by the worksheet server (i.e., a "push" operation). In various embodiments, retrieval of a version of the worksheet can be triggered by an administrator command (from a local or remote system), a periodic automatic request for an update when a new version of the worksheet becomes available, or in response to a user requesting access to the worksheet while there is an active connection to the worksheet server.

By using worksheets from a worksheet server, worksheets can be customized for a particular organization, such as specifying how fields in the worksheet are organized to maintain a particular look and feel, to include specific fields that correspond to data the organization wants to collect at its point of care system, or to enable a particular data collection workflow. Worksheets can be customized for a particular point of care system or group of point of care systems. In some embodiments, a worksheet can be a file that defines fields using HTML. In some embodiments, a worksheet file can include other content, such as scripts (e.g., JavaScript), images or other media, CSS, etc. Alternatively or additionally, a worksheet file can include references to other content stored in the point of care system's local storage. This allows other content to be shared between worksheets, and allows worksheets to be updated without re-downloading parts of the worksheet that have not changed. In some embodiments, the worksheet and/or additional content can be stored on a solid state drive of the point of care system. In some embodiments, the worksheet and/or additional content can be stored in a secure manner, such as encrypted.

Upon completion of block 602, the worksheets and their corresponding other content are stored locally. Additionally, as described below, the point-of-care system may extract and store locally the data entered into the worksheets. As a result, upon completion of block 602, the point-of-care system may implement the remaining blocks 604-624 without connecting to a live server.

At block 604, the system software of the point-of-care system may execute a browser component. This may be a custom browser specific to the point-of-care system or a version of a commercial browser such as Chrome, Safari, Internet Explorer, etc. In some embodiments, the browser component may be integrated with or configured to be built into the system software such that it is not readily apparent that it is separate from other aspects of the system software. In various embodiments, executing the browser component may be performed as part of the initialization of the system software or in response to a user selection to open a worksheet.

In block 606, the browser component can load a selected worksheet from local memory, e.g., selected by a user during a patient exam. This can be accomplished by providing the worksheet stored in local memory to the browser component in block 602. If the worksheet has references to other content stored in local memory, the browser component can resolve the references and obtain the other content to fully render the worksheet and execute additional code, such as referenced JavaScript or CSS.

In block 608, the system may determine whether there is any unsigned or other partial data in the data stored in the local memory for the worksheet loaded in block 606. In some embodiments, this is done in block 606 by checking which worksheet was loaded and determining whether the corresponding worksheet data is stored. For example, metadata identifying the worksheet may be stored in association with the data for the worksheet in the local memory. The worksheet data may be known to be not yet signed off for transmission to the DICOM server (which may be indicated by further metadata). In some embodiments, the point-of-care system may include session data identifying the current patient, in which case the determination in block 608 further identifies the unsigned worksheet data only if there is a current patient identifier. If the worksheet data is identified in block 608, processing proceeds to block 610. If not, processing continues to block 612.

At block 610, the worksheet data identified at block 608 may be retrieved from local storage and provided to the browser component. Code contained in the worksheet or injected by system software may populate fields in the worksheet using the attached worksheet data. The process of inserting worksheet data into worksheet fields using an intermediate component is described above in conjunction with FIG. 4, and the process of inserting worksheet data into a worksheet using code injection is described above in conjunction with FIG. 5.

At block 612, a user and/or an automated system can interactively input information into the worksheet. For example, a user can type information into fields, or other collected data can be entered or associated with the worksheet, such as scanned data from encodings (e.g., bar codes, QR codes, etc.), calculations, measurements, images, readings, other scan results, etc.

At block 614, a trigger condition for saving the worksheet data may be identified. In some embodiments, the trigger condition may be an event in which the browser component navigates away from the current page, causing the browser component to clear the DOM of the current worksheet. For example, such events may include the user activating a control to end a patient exam, navigating to a different worksheet or other page, or activating a different subsystem of the point-of-care system (e.g., imaging, transducer, system menu, help menu, etc.) that causes the system software to close the browser component.

At block 616, data entered into the current worksheet may be extracted and stored in local memory. For example, to extract data from a worksheet, an intermediate component may be used to identify a reference to a GetWorksheetData() function and execute the function, or code for the GetWorksheetData() function may be inserted into the browser component to obtain the results. The process of extracting data from a worksheet using an intermediate component is described above with reference to FIG. 4, and the process of extracting data from a worksheet using code injection is described above with reference to FIG. 5, and the extracted worksheet data may be stored in a secure manner, such as encrypted.

At block 618, the system software may determine whether the worksheet data is signed. In various embodiments, this may be accomplished by examining a variable embedded in or otherwise associated with the extracted worksheet data (e.g., metadata), or by using an intermediate component or code insertion to perform an IsWorksheetSigned() function. If the worksheet is not signed, processing returns to block 606 when the worksheet is again selected to be loaded into the browser component. If the worksheet is signed, processing continues to block 620.

At block 620, the system software can incorporate the version of the signed worksheet data into the DICOM package. In some embodiments, this is done by adding the version of the worksheet data, for example as a string, to a private tag in the DICOM package. When the server receives this DICOM package, it can extract the individual values from the worksheet data in the private tag. In other implementations, the version of the worksheet data can be extracted from the worksheet data and made into values of individual fields of the worksheet that are added to the corresponding standard fields in the DICOM package.

At block 622, the system software may determine whether the DICOM package is complete. In some embodiments, the system software may determine that the DICOM package is complete when it contains a specified set of material, such as images, reports, worksheet data, other metadata, etc. In other implementations, the system software identifies the DICOM package as complete when the user performs an indication to this effect, such as clicking an end exam control. If the DICOM package is not complete, processing remains at block 622 until additional input is received indicating that the DICOM package is complete. Once the DICOM package is complete, processing continues at block 624.

In block 624, the system software can add the completed DICOM package to a queue configured to transmit the queued DICOM packages to one or more servers when a live network connection is available.

7 is a block diagram of an exemplary computer component 700 for executing system software on a point-of-care medical imaging system according to some embodiments of the disclosed technology. The elements of the computer component 700 can be implemented in digital electronic circuitry, or computer software, firmware, or hardware, or one or more combinations thereof, including structures disclosed herein and their structural equivalents. The computer component 700 can include one or more input devices 720 that provide input to and inform actions of the processor 710 (e.g., CPU(s), GPU(s), HPU(s), etc.). Actions can be mediated by a hardware controller that interprets signals received from the input devices and communicates information to the processor 710 using a communication protocol. The input devices 720 include, for example, a mouse, keyboard, touch screen, ultrasound, x-ray or other medical scanning components, infrared sensors, touch pads, wearable input devices, cameras or other vision-based input devices (e.g., barcode readers or QR code readers), microphones, or other user input devices.

The processor 710 may be a single processing unit or multiple processing units in a device, or may be distributed across multiple devices. Processors suitable for executing computer programs include, by way of example, both general purpose and special purpose microprocessors, and any one or more processors of any type of digital computer. The processor 710 may be coupled to other hardware devices, for example, using a bus such as a PCI bus or a SCSI bus. The processor 710 may communicate with a hardware controller for the device, such as a display 730. The display 730 may be used to display text and graphics. In some embodiments, the display 730 provides graphical and textual visual feedback to the user. In some embodiments, the display 730 includes an input device as part of the display, such as a touch screen or a line of sight monitoring system. In some embodiments, the display is separate from the input device. Examples of display devices are LCD display screens, LED display screens, projected holographic or augmented reality displays (such as head-up display devices or head-mounted devices), and the like. Other input/output devices 740 may also be connected to the processor, such as a network card, video card, audio card, USB, camera, printer, speaker, CD-ROM drive, DVD drive, disk drive, or Blu-Ray (registered trademark) device.

In some embodiments, computer component 700 also includes a communication device capable of wireless or wire-based communication with network nodes. The communication device can communicate with other devices or servers over the network, for example using TCP/IP protocols. Computer component 700 can utilize the communication device to distribute operations across multiple network devices.

The processor 710 can access the memory 750 of the point-of-care system. The memory can include one or more of a variety of hardware devices for volatile and non-volatile storage, and can include both read-only and writeable memory. For example, the memory can include random access memory, various caches, CPU registers, read-only memory, and writeable non-volatile memory such as flash memory, hard drives, floppy disks, CDs, DVDs, magnetic storage devices, tape drives, device buffers, and the like. Memory is not a propagating signal separate from the underlying hardware, and thus the memory is non-transient. The memory 150 can include a program memory 760 that stores computer programs such as an operating system 762 (e.g., Windows, Apple OS, Unix, etc.), system software 764, and other application programs 766. The memory 750 can also include a data memory 770 that can store data such as worksheets and worksheet data provided to the program memory 760 or any element of the computer component 700.

As described below, certain embodiments may allow users to download customized worksheets directly to the medical imaging device based on the user's role, workflow preferences, and/or the location or department where the medical imaging device is being used. In some embodiments, the system may facilitate workflow automation for customized worksheets or forms. In one particular example, an automated workflow may help facilitate the creation of worksheets or forms for tests not ordered from an electronic medical record system. The use of an accelerated workflow may allow for automatic matching of patient orders and demographics, thereby allowing a medical facility to handle patients for whom an order was not initially generated. This may be particularly beneficial for emergency room or trauma patients, where promptness of medical orders is paramount.

In certain embodiments, a system such as the system shown in FIG. 1 or FIG. 2 may include a middleware application, which may be referred to as a workflow accelerator application. The middleware may be computer software that sits between an operating system and one or more software applications. The middleware application may provide a user of the system with the ability to create one or more customized worksheets or forms. In one example, the software application may be a browser on which the worksheets or forms are displayed. The customized worksheets or forms may be, for example, notes taken by a physician to attach to medical images. These notes may then be forwarded to one or more departments, such as a billing department within a medical facility and/or a pharmacy at the medical facility. The user may be a physician, a non-physician, a medical professional, or any other person using a point-of-care ultrasound device. In other embodiments, instead of or in addition to using a point-of-care ultrasound device, the user may utilize one or more other medical imaging devices, such as a magnetic resonance imaging (MRI) device, a computed tomography (CT) scanner, a nuclear medicine (NM) imaging device, an electrocardiogram device, a positron emission tomography (PET) scanner, and/or an x-ray device.

The system may include one or more customizable processes or methods for creating or generating worksheets or forms. The one or more processes or methods may be, for example, customized procedural or educational clinical imaging workflows. The process or method may be customized based on the following overarching factors: type of exam, location where the exam is performed, department performing the exam, identity of the physician performing the exam, location in the medical facility where the exam is performed, and/or any other factors that may be used to determine the fields to be included in the worksheet or form. In some embodiments, the workflow may be a customized exam workflow type or a default exam workflow type that is available for multiple modality types. The modality types may be, for example, different imaging devices such as ultrasound, MRI, CT scanner, NM imaging device, PET scanner, ECG device, and X-ray device. The customized fields of the worksheet or form may be stored as metadata in a database included in a physical server or a cloud-based server. In certain embodiments discussed herein, the term "data" may include metadata.

Customization of the worksheet or form can be done before the workflow is started. In other words, the user can create a customized template of the worksheet or form. The user can decide which field or fields to include in the worksheet or form depending on the factors mentioned above. When using a medical imaging device, the user can manually input the identification information into a graphical user interface (GUI), display, or computer attached to the medical imaging device using an application programming interface (API). In certain embodiments, the workflow accelerator application can be vendor independent, meaning that the application can run on medical imaging devices manufactured by multiple different vendors. In other embodiments, the user's identification information can be automatically input via a sensor or detection device that can sense or detect something that identifies the user. For example, the automatic input of the user's identification information can include barcode scanning of a standard matrix (2d) code or a QR (Quick Response) code, utilizing a specific format. The format can be, for example, <FFSS>, ,,,,,,,BADGEID</FFSS>. When the identification information is scanned, the scanned identification field is automatically input into the device. In some embodiments, the worksheet code may include an interface that allows the user to capture one or more implementation fields. The user's identification may be the user's first and last name, the user's identification issued by the medical facility, or any other identification used to identify the user. Once the user's identification is entered, the content of the customized template worksheet or form may be downloaded from the worksheet server, or any other database, to the medical imaging device. The content may then be entered into the worksheet or form to generate or display a customized worksheet or form for the user.

In certain embodiments, the workflow accelerator application can provide an API on a GUI attached to the medical device. The API can be used by a user to enter user identification information and to complete one or more fields of a customized worksheet or form. The API can accept HyperText Transfer Protocol (HTTP) requests in accordance with RFC 2616 and/or HTTP Secure (HTTPS) requests in accordance with RFC 2818 in some embodiments. The request body sent to the API to request customized worksheet or form metadata is formatted in JSON conforming to RFC 8259. The entire disclosures of RFC 2616, RFC 2818, and RFC 8259 are incorporated herein by reference.

The workflow accelerator application, in some embodiments, can enable a user, such as a physician, to document findings from a medical imaging device on a customized worksheet or form. In certain embodiments, the user can insert an electronic signature into the customized worksheet or form. The electronic signature can be, for example, a signature compliant with the U.S. Food and Drug Administration per Part 11, Title 21, Code of Federal Regulations. Thus, a user can use the workflow accelerator application to create a customized worksheet or form that complies with any electronic records and electronic signature requirements of a medical facility.

The workflow accelerator application can classify the completed customized worksheet or form into one or more categories. The categories can be based on the purpose of the imaging performed by the user. For example, one category can be educational, where the imaging is performed for educational purposes. In another category, the imaging can be billable, where the imaging is performed as part of a patient's medical procedure and may be billed using the patient's insurance. The one or more categories can be used to determine which workflow the customized worksheet or form is sent through. For example, a worksheet or form categorized as educational can be automatically or manually routed to an educational workflow, while a worksheet or form categorized as billable can be automatically or manually routed to a billable workflow.

As discussed above, based on the category, the application can send the completed customized worksheet or form to one or more locations. If the performed imaging is classified as billable, for example, the application can send the customized worksheet or form and the content therein to a billing system. In some other embodiments, the customized worksheet or form can be sent to any database or server, such as a repository of worksheets or forms or a worksheet server. The sending can be automatic without user or end-user interactive input, simply based on at least the category of the customized worksheet or form. Alternatively, or in addition, the sending can be manual, requiring input from a user. In a manual sending, the user can determine where to send the customized worksheet or form. Images that can be included as part of the exam can be sent using a healthcare standard, such as Health Level Seven messages (HL7), Digital Imaging Communication over Messaging (DICOM) for messages, or any other messaging standard used for medical imaging.

8, 8b are diagrams showing an example of a general architecture of the system according to certain embodiments. A user can create a worksheet or form template using a browser 810. In another embodiment, the template can be created by an administrator separate from the user. The template can be created directly on the medical imaging device or on a separate computer. The template can be created based on the type of exam, the location where the exam is performed, the department performing the exam, the identity of the physician performing the exam, the location in the medical facility where the exam is performed, and/or any other factors that can determine the fields or questions to be included in the worksheet or form. These elements can be used to define the user's workflow selection preferences. In other words, the factors can determine whether one or more fields are included in the customized worksheet or form.

For example, one field on the customized worksheet or form can be the applicable billing code. The billing code can be associated with any of the factors discussed above. In some embodiments, the billing code can be specific to the medical facility where the imaging device is located. The presence of the billing code can aid in facilitating automatic or manual submission of the customized worksheet or form. A user or a separate administrator of the system can aid in programming the billing code into the customized worksheet or form for a given medical facility.

In certain embodiments, information entered by a user or administrator when creating a template worksheet or form can be stored or saved as metadata (hereinafter also referred to as data) in a database. The database can be included in the worksheet server 20 or any other server accessed by the system, such as the application management worksheet/form repository 820, shown in Figures 1 and 2. The metadata can be obtained by the user via an API. For example, a medical device used by the user can connect to the API to obtain the worksheet or form metadata via HTTP, HTTPS, or any other Internet application protocol.

8, 8b show a system in which a workflow accelerator application can create customized worksheets or forms based on factors and automatically or manually send or route the completed worksheets to a desired location or workflow. A customized worksheet or form template can be created using a browser 810. In certain embodiments, a template may be automatically generated without user or administrator input, taking into account one or more factors. For example, a template can be automatically generated based on a given medical facility or a recognized vendor. The customized worksheet or form can be stored as metadata in an application management worksheet or form repository 820. When using an imaging device 830, referred to as a modality, an API request can be sent to the repository 820 requesting the stored metadata for the customized worksheet or form. The API request can be a JSON formatted HTTP or HTTPS web request. The imaging device shown in Figures 8, 8b is an ultrasound device, such as a point-of-care ultrasound device, although any other modality may be used, such as MRI, CT scan, NM imaging, or X-ray.

After receiving or retrieving the metadata, the imaging device 830 can add to or recreate the customized worksheet or form. The customized worksheet or form 840 can be displayed on the imaging device or on a computer, GUI, or display that can communicate or connect with the imaging device. In certain embodiments, the application used to display the customized worksheet or form 840 can include a field that allows the physician to enter an electronic signature into the customized worksheet or form 840. The electronic signature can be entered using a variety of methods, including at least a touch screen that allows the physician to enter the signature, a check box that can be clicked to enter a previously saved digital signature, or a drop-down menu that allows the physician to select an electronic signature. In another example, the electronic signature can be entered using any available authentication or re-authentication method, in which case the user may be prompted for one or more authentication information used to verify the user's identity. The imaging device 830 can also be used to image the patient and transmit or communicate the resulting images 850 to a storage server or cloud via DICOM. A customized worksheet or form 840, with or without a physician's electronic signature, can be associated with the image 850. The association can be via a DICOM private tag, which can be in JSON format, for example.

The image and/or associated worksheet or form data can be routed automatically or manually using the application services router 860. In certain embodiments, the image and/or associated worksheet or form data can be sent or routed through an education workflow to the application management worksheet or form repository 820. For example, in such an embodiment, the worksheet or form can be classified as education. The user can then review the customized worksheet or form using the browser 810. During the review, the user can edit, change, add, or delete the customized worksheet or form. After review, the customized worksheet or form can be signed using an electronic signature and/or converted into a signed worksheet or form report 870 that can be sent to the EMR 880. The customized worksheet or form can be sent manually or automatically.

In certain other embodiments, the images and/or associated worksheet or form data can be routed to the EMR 880 using the application service router 860 through a billable workflow. For example, the worksheet or form can be classified as billable. The images and/or associated worksheet or form data can be sent or reported to the electronic medical record system as text or in encoded portable document format (PDF), either automatically or manually. Alternatively, the images and/or associated worksheet or form data can be routed using any other format via medical transfer standards. The output of the routed images and/or associated worksheet or form can be a signed worksheet or form report 870. The report can be transferred and stored in the EMR 880.

FIG. 9a is an example diagram showing parts of a system according to certain embodiments. The parts of the system may include a worksheet server 910, which may be an application management worksheet or form repository 820 as shown in FIG. 8, FIG. 8b , and a medical imaging device 920. Specifically, FIG. 9a shows an API request architecture used to verify a connection from a medical imaging device 920. As shown in FIG. 9a, the medical device 920 may use an API to send an HTTP or HTTPS GET request message to the worksheet server 910. The GET message may include a request to verify the connection, and in response, the worksheet server 920 may send a response message in the form of an HTTP 200 response indicating that the request was successful. For example, the request may be http://<fully qualified domain name>/external/verify. The content type of the response message may be HyperText Markup Language (html) or text, allowing the medical imaging device 200 to connect to the worksheet server 910.

9b is an example diagram showing a portion of a system according to certain embodiments. In particular, FIG. 9b shows a search for a custom file to be used to render a worksheet or form template. The search can be triggered, for example, by a user of the medical imaging device entering identifying information into the device itself or into a computer connected to the device. The medical imaging device 920 can send a request message to retrieve all metadata from the worksheet server 910. For example, the request can be http://<fully qualified domain name>/external/Get AllFilePaths. In response, the worksheet server 910 can send a response message in the form of an HTTP 200 response indicating that the request was successful. The content type of the response message can be application or JSON. The body of the response message can include data or metadata that can be used by the medical imaging device to create the template worksheet or form.

FIG. 9c is an example diagram illustrating a portion of a system according to certain embodiments. In particular, FIG. 9c illustrates retrieving an individual artifact file for rendering by the medical imaging device 920. For example, the individual artifact file may include one or more libraries in JavaScript, one or more style sheets used to format the worksheet in the medical imaging device, or various icons used for identification and/or rendering. The medical imaging device 920 may send a request message in the form of an HTTP GET message to retrieve one or more files from the worksheet server 910. For example, the request may look like http://<fully qualified domain name>/external/DownloadFile?name=<filename>. In response, the worksheet server 910 may send a response message in the form of an HTTP 200 response indicating that the request was successful. The content type of the response message may be, for example, application or octet stream. The response may be a byte stream containing the requested file and the content contained therein.

FIG. 9d is an example diagram illustrating a portion of a system according to certain embodiments. In particular, FIG. 9d illustrates retrieval of a list of worksheets or forms available on the system for a virtual location/department based on the entity name of the medical imaging device's application. The virtual location of the medical imaging device can be, for example, an emergency room of a hospital or medical facility. The term "location" as used herein can include a virtual location. The department can be, for example, an emergency department of a hospital or medical facility. The medical imaging device 920 can send a request message in the form of an HTTP GET message that includes the entity name of the medical imaging device's application. For example, the request can be http://<fully qualified domain name>/external/GetWorksheetList?deviceName=AETITLE. In response, the worksheet server 910 can send a response message in the form of an HTTP 200 response indicating that the request was successful. The content type of the response message can be application or JSON. In some embodiments, the response may include a test type identification, a test type name, a test type description, a worksheet identification, a worksheet name, and/or a worksheet description.

9e is an example diagram of a portion of a system according to certain embodiments. In particular, FIG. 9e illustrates retrieval of an individual worksheet or form based on a worksheet identification number. The medical imaging device 920 can send a request message in the form of an HTTP GET message that includes the worksheet identification information. For example, the request can be http://<fully qualified domain name>/external/GetWorksheetList?worksheetid=<worksheetid>. In response, the worksheet server 910 can send a response message in the form of an HTTP 200 response indicating that the request was successful. The content type of the response message can be text or HTML. The response can include a template of the worksheet with the worksheet identification information included in the request message sent from the medical imaging device 920.

FIG. 9f is an example diagram illustrating a portion of a system according to certain embodiments. In particular, FIG. 9f illustrates retrieval of metadata or content of one or more worksheets or forms for a virtual location or department based on the entity name of the medical imaging device's application. The medical imaging device 920 can send a request message in the form of an HTTP GET message that includes the entity name of the application. For example, the request is http://<fully qualified domain name>/external/worksheets?deviceName=AETITLE. In response, the worksheet server 910 can send a response message in the form of an HTTP 200 response indicating that the request was successful. The content type of the response message can be application or JSON. The response can include metadata associated with the virtual location or department. The medical imaging device 920 can use the retrieved metadata to generate a customized worksheet or form.

In certain embodiments, customized worksheet or form data may be sent back to the system from the medical device. The data may be attached as a JSON. Additionally or alternatively, the data may be attached or associated with one or more images in a series contained in private DICOM tags, and the data type may be text without limitation. Upon receiving one or more images and associated data, the system may automate the outcome of various workflows. For example, one or more images and associated data may be sent to a billable workflow or an educational workflow.

FIG. 10 is an example of a flow chart diagram according to certain embodiments. In particular, FIG. 10 illustrates a process for automating various workflow results. The application service router 1010 may be similar to the application service router 860 shown in FIG. 8, 8b , but in certain embodiments, may determine 1020 whether to automate a billable report. An exam including one or more images generated by a medical imaging device may not be eligible for a particular worksheet if it is performed by either an uncertified student or a learner in a certified program. In such an embodiment, the images and/or associated data may be sent to an education workflow 1040. The education workflow 1040 may include forwarding to an application for review by a physician or non-physician, as shown in FIG. 8, 8b .

In other embodiments, a test may be eligible for automatic billable transfer. In such embodiments, the report may be transferred to a clinical automatic billable workflow 1030. The automatic billable workflow 1030 may use the worksheet or form data, for example, to bill one or more hospitals or medical facilities, including transferring the added or completed worksheets and/or forms to one or more internal or external billing systems. For example, a test may be eligible for automatic billable transfer if an approved provider signature is present in accordance with the FDA requirements for electronic records and electronic signatures per Part 11, Title 21, Code of Federal Regulations. A test may also be eligible if it has a corresponding order, encounter, or visit identified by the system and/or if it has a corresponding patient identifier in the system. In some embodiments, a test may be eligible for automatic billable transfer if it was performed by either an authorized provider or a student or learner in an authorized program. Tests may also be eligible for automated billable transfer when the test is identified for submission to a downstream billing or electronic medical record system.

An order may be a transfer of clinical care made to inform the system that a care is planned or booked for a patient. For example, a physician may create an order for a planned ultrasound scan. In certain embodiments, the order may be passed to a billable workflow, meaning that the care to which the order is directed can be billed. For billing purposes, evidence of the care may be required in the form of a result. The result may be, for example, a typed worksheet or a filled-in form with which the user can enter the result. On the other hand, an exam may be identified as billable if one or more of the following are applicable: i) an order is associated with the exam, ii) a patient visit or visit is identified or associated with the exam, or iii) a worksheet or form contains at least one CPT (Current Procedural Terminology) code and/or is signed by a certified physician. In other embodiments, an exam may be identified as billable using any other available method.

11 is an example flow diagram illustrating a method according to certain embodiments. In particular, FIG. 11 illustrates a method performed by a medical imaging device. In step 1110, the medical imaging device retrieves data from the data of the worksheet or form repository server. The data may include one or more fields of a customized worksheet or form. The one or more fields are based on at least one of the identity of the user, the location of the medical imaging device, or the medical department using the medical imaging device. In certain embodiments, the one or more fields of the customized worksheet or form may be predefined by a user or administrator before the data is retrieved from the worksheet or form repository server as part of a billable or educational workflow. For example, the one or more fields may include a billing code for the medical image. The one or more fields of the customized worksheet or form may also or alternatively be based on at least one of the entity name or worksheet identification number of the application of the medical imaging device. In some embodiments, a request may be sent from the medical imaging device to the worksheet or form repository server to verify that they are connected before retrieving the data.

In step 1120, a customized worksheet or form may be recreated based on the data received by the medical imaging device. The recreated customized worksheet or form may then be displayed on a graphical user interface connected to the medical imaging device, as shown in step 1130. A middleware application may be used to display the recreated customized worksheet or form. In step 1140, a medical image may be generated via the medical imaging device. The customized worksheet or form may be associated with the medical image via a DICOM private tag or standard structured report. In certain embodiments, a user's electronic signature may be inserted into the customized worksheet or form, as shown in step 1150.

At step 1160, the customized worksheet or form and medical image may be automatically forwarded to a billable workflow or an educational workflow. In some embodiments, when the user is an unauthenticated student, a learner in an authenticated program, or a provider not included in an authenticated program, the customized worksheet or form and medical image may be automatically forwarded to an educational workflow. In such an embodiment, the customized worksheet or form may be routed to a worksheet or form repository server. The user may then use a browser to review the customized worksheet or form in the billable workflow and provide or approve secure feedback. Secure feedback may include using any known encryption, such as Transport Layer Security Protocol. For example, the review may include changes, edits, additions, or deletions to the customized worksheet or form. Thus, an authenticated program may include a list of learners, students, or providers, including physicians or non-physicians. In some embodiments, learners, students, or providers in an authenticated program may review and/or modify the customized worksheets or forms, and in other embodiments, learners, students, or providers not included in an authenticated program may review and/or modify the customized worksheets or forms.

In certain other embodiments, the customized worksheet or form and medical images can be automatically routed to a billable workflow if i) an approved provider signature is on the customized worksheet or form, ii) the medical images correspond to an identified order, visit, or clinic visit, iii) the customized worksheet or form includes a patient identifier, iv) the user is an authorized provider for a student in an authorized program, or v) the medical images are identified to be submitted to a billable workflow. The customized worksheet or form and medical images can be routed to the EMR system as part of a billable workflow or an educational workflow.

In certain embodiments, the method or process illustrated in Figure 11 may be vendor independent throughout other exemplary embodiments described herein. In other words, the method or process may be performed on medical imaging devices manufactured by a vendor, as well as on different medical imaging devices manufactured by different vendors. In some other embodiments, the method or process described above may be performed by a server, such as the worksheet or form repository server 820 illustrated in Figures 8, 8b .

Thus, the above disclosed embodiments help improve the system by generating customized worksheets or forms specific to a user, department, or location of a medical imaging device within a medical facility. Certain embodiments can also automate the transfer of customized worksheets or forms to a billable or educational workflow for processing. This automated transfer, as well as the generation of customized worksheets, can help improve workflow efficiency by reducing the amount of network and system resources used to process medical orders, worksheets, or forms. Reducing resource usage, improving network efficiency, and enabling customized worksheets and forms that can take the form of medical orders can help increase the speed of processing electronic medical records through the system. Thus, the above-described systems, methods, and apparatuses help provide significant improvements to the functionality of servers, medical imaging devices, and any other components of an EMR system.

A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted, declarative, or procedural, and can be arranged in any form, either as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program can correspond to a file in a file system, but this is not required. A program can be stored in part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in one file dedicated to the program in question, or in several cooperating files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be arranged to be executed on one computer, or on several computers located at one site, or distributed across several sites and interconnected by a communications network.

Several implementations of the disclosed technology are described above with reference to the drawings. References herein to "embodiments" or "examples" (e.g., "several embodiments," "various embodiments," "one embodiment," "embodiments," etc.) mean that a particular feature, configuration, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. The appearances of these phrases in various places in the specification do not necessarily all refer to the same embodiment, nor are they mutually exclusive separate or alternative embodiments from other embodiments. In addition, various features that are exhibited by some embodiments and not exhibited by other embodiments are described. Similarly, various requirements that are requirements for some embodiments but not other embodiments are described.

Unless otherwise defined, relative terms such as high or insignificant may be understood as assigning a value and determining how that value compares to an established threshold. For example, the phrase "selecting a high-speed connection" may be understood to mean selecting a connection having an assigned value corresponding to a connection speed that exceeds a threshold. As used herein, the word "or" refers to any possible permutation of a set of items. For example, the phrase "A, B, or C" refers to at least one of A, B, C, or at least one of any combination thereof, such as "A", "B", "C", "A and B", "A and C", "B and C", "A, B and C", or a plurality of any items such as "A and A", "B, B and C", "A, A, B, C and C".

Although the subject matter has been described in language specific to structural features and/or methodological operations, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described above. While specific embodiments and implementations have been described herein for purposes of illustration, various modifications can be made without departing from the scope of the embodiments and implementations. The specific features and operations described above are disclosed as exemplary forms of implementing the following claims. Accordingly, the embodiments and examples are not limited, except as set forth in the appended claims.

Any patents, patent applications, and other references listed above are incorporated herein by reference. The form can be modified, if necessary, to employ the systems, functions, and concepts of the various references described above to provide further embodiments. In the event that the content or subject matter of a document incorporated by reference conflicts with the content or subject matter of this application, this application will control.

Claims (20)

1. A method for a medical imaging device, comprising:
retrieving data from a worksheet or form repository server, the data including one or more fields of a customized worksheet or form based on at least one of a user's identity, a location of the medical imaging device, or a medical department using the medical imaging device;
recreating the customized worksheet or form at the medical imaging device based on the retrieved data;
displaying the recreated customized worksheet or form on a graphical user interface connected to the medical imaging device;
generating a medical image via the medical imaging device;
automatically transferring the customized worksheet or form and the medical images to a billable or educational workflow;
The method according to claim 1, The method of claim 1, wherein one or more fields of the customized worksheet or form are predefined by the user or administrator before data is retrieved from the worksheet or form repository server as part of the billable workflow or the educational workflow. The method of claim 1, further comprising routing the customized worksheet or form and the medical images to an electronic medical record system as part of the billable workflow or the education workflow. The method of claim 1, further comprising inserting the user's electronic signature into the customized worksheet or form. The method of claim 1, wherein the customized worksheet or form and the medical image are automatically transferred to the educational workflow if the user is an uncertified student, a learner of an authenticated program, or a provider not included in the authenticated program. routing the customized worksheet or form to the worksheet or form repository server;
6. The method of claim 5, wherein the user can use a browser to at least one of review, provide secure feedback, or approve the customized worksheet or form for the chargeable workflow. 10. The method of claim 1, wherein the customized worksheet or form and the medical image are automatically routed to the billable workflow if i) an approved provider signature is present on the customized worksheet or form, ii) the medical image corresponds to an identified order, visit, or outpatient visit, iii) the customized worksheet or form includes a patient identifier, iv) the user is an authorized provider of a student in an authorized program, or v) the medical image is identified for submission to the billable workflow. The method of claim 1, wherein the one or more fields include a billing code for the medical image. transmitting a request from the medical imaging device to the worksheet or form repository server;
The method of claim 1 , wherein the request is used to verify connectivity between the medical imaging device and the worksheet or form repository server. The method of claim 1, wherein the one or more fields of the customized worksheet or form are further based on at least one of an entity name of the medical imaging device application or a worksheet identification number. The method of claim 1 , further comprising associating the customized worksheet or form with the medical image via digital image communication via private tags in messages or standard structured reporting. The method of claim 1, further comprising using a middleware application to display the recreated customized worksheet or form. The method of claim 12, further comprising the step of the user using the middleware application to modify, delete, or add to the recreated customized worksheet or form. The method of claim 1, which is performed on the medical imaging device manufactured by a vendor and on a different medical imaging device manufactured by a different vendor. The method of claim 1, wherein the medical imaging device is an ultrasound device, a magnetic resonance imaging device, a computed tomography scanner, a nuclear medicine imaging device, an electrocardiogram device, a positron emission tomography (PET) scanner, or an x-ray device. at least one memory containing computer program code;
at least one processor,
The computer program code, when executed by the at least one processor,
said medical imaging device of a client,
Retrieving data from a worksheet or form repository server, the data including one or more fields of a customized worksheet or form based on at least one of a user's identity, a location of the medical imaging device, or a medical department using the medical imaging device;
recreating the customized worksheet or form at the medical imaging device based on the retrieved data;
displaying the recreated customized worksheet or form on a graphical user interface connected to the medical imaging device;
generating a medical image via said medical imaging device;
A medical imaging device that automatically transfers the customized worksheet or form and the medical images to a billable or educational workflow. The computer program code, when executed by the at least one processor, causes the client medical imaging device to:
20. The medical imaging device of claim 16, further comprising: routing the customized worksheets or forms and the medical images to an electronic medical record system as part of the billable workflow or the educational workflow. The computer program code, when executed by the at least one processor,
said client's medical imaging device;
17. The medical imaging device of claim 16, further comprising inserting an electronic signature of the user into the customized worksheet or form. The medical imaging device of claim 16, wherein the customized worksheet or form and the medical image are automatically transferred to the educational workflow if the user is an uncertified student, a learner of an authenticated program, or a provider not included in the authenticated program. 17. The medical imaging device of claim 16, wherein the customized worksheet or form and the medical image are automatically forwarded to the billable workflow if i) an approved provider signature is on the customized worksheet or form, ii) the medical image corresponds to an identified order, visit, or outpatient visit, iii) the customized worksheet or form includes a patient identifier, iv) the user is an authorized provider of a student in an authorized program, or v) the medical image is identified for submission to the billable workflow.