CN114746948A - Method and apparatus for interacting with medical worksheets - Google Patents

Abstract

Certain embodiments relate to a method, system, or apparatus, such as a medical imaging apparatus. The method may include retrieving data from a worksheet or table 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 a user identification, a location of the medical imaging device, or a medical department using the medical imaging device. The method may further comprise: re-creating a customized worksheet or form at the medical imaging device based on the received data; and displaying the re-created customized worksheet or form on a graphical user interface connected to the medical imaging device. Further, the method may comprise: generating a medical image via a medical imaging device; and automatically forwarding the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

Description

Method and apparatus for interacting with medical worksheets

Cross Reference to Related Applications

This application claims priority from us patent application No. 16/706,244 filed on day 6, 12, 2019, the No. 16/706,244 application is a partial continuation of us patent application No. 16/144,795 filed on day 27, 9, 2018, the No. 16/144,795 application claims priority from us provisional patent application No. 62/578,277 filed on day 27, 10, 2017, which is incorporated herein by reference in its entirety.

Technical Field

The disclosed technology relates to point-of-care medical systems, and in particular to systems that complete patient care worksheets on point-of-care ultrasound systems without a real-time server connection.

Background

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

A doctor or technician may use the point-of-care medical system to complete a worksheet. The point-of-care medical system may be integrated with a medical device, such as an ultrasound apparatus, may be operatively connected to such a medical device, either directly or via a network, or may be another computing system (e.g., a computer or tablet) that may execute system software and receive worksheet input from a user. Existing point-of-care medical systems typically come with a default set of hard-coded worksheets. These worksheets may be too long or cumbersome for many situations, making their use less likely by physicians. In some cases, the worksheet may be customized by the clinic or practice team to reflect the desired workflow of a particular program. The worksheet server system may facilitate use and customization of worksheets and allow downloading of worksheets to remote computers or medical devices, such as point-of-care systems. In addition, a worksheet server or other system may receive data entered in completed worksheets and other DICOM data, may store worksheet data and still or video images (e.g., in a Picture Archiving and Communication System (PACS)), and may interact with a billing system. For example, one such worksheet server system may be Sonosilicate synchronization, available from FUJIFILM Sonosilicate, Inc. of Bothell, Washington, Wash, USA, while another worksheet server system may be a QPath E Tm server system, available from Telex Fletlhcare, Inc. of Maple Ridge, British, Calif.

In the prior art, the point-of-care system needs to have a real-time web server connection to download and view the worksheet and to allow the data entered into the worksheet to be signed (approved for the next phase of the data review workflow) for transmission to the server. If the connection is lost, the worksheet cannot be viewed or completed before the connection is re-established when the point-of-care device is used in the field or in a location where an internet or other computer communication connection is unavailable or unreliable.

Disclosure of Invention

The inventors have recognized a need for techniques that allow 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 real-time connection to a worksheet server. The disclosed technology addresses this need through a point-of-care system that includes system software that interfaces with a browser component. An interface connection between the system software and the browser component allows the system software to retrieve the worksheet data from the browser component and store it in local memory. The interface connection also allows the system software to retrieve stored worksheet data from local memory and can cause the worksheet data to be automatically populated into the worksheets in the browser component. 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 "real-time" connection refers to the ability to communicate between two or more devices. For example, when a point-of-care imaging system is able to send DICOM packets to a server, e.g., via the internet, it has a real-time connection to the server. However, if the point-of-care imaging system attempts to contact the server but cannot, it does not have a real-time connection to the server.

In some embodiments, the point-of-care system may include system software that includes a browser component. The system software may include a browser component as an integrated element in its display, thereby maintaining the look and feel of the system software. The browser component may render the worksheets previously stored in the local memory of the point-of-care imaging system, or may retrieve them dynamically from a worksheet server.

When a user opens a worksheet via the browser component, the point-of-care imaging system software may determine whether there is data associated with the worksheet stored in the local memory of the point-of-care imaging system. If so, the system software of the point-of-care imaging system may retrieve the local data and interface with the browser component to automatically fill in the fields in the worksheet. The user may then interact with the worksheet, whether or not it has data that has been automatically populated.

When a triggering event occurs that saves the worksheet data, such as when a user performs an action to navigate away from the current Document Object Model (DOM), the system software of the point-of-care system may again interface with the browser component to obtain the worksheet data entered in the worksheet fields. Data from the worksheet may be stored in local memory. If the worksheet has completed (e.g., if it has been signed), the worksheet data may be incorporated into the DICOM package by entering the data from the worksheet and other associated data into a "tag" in the DICOM package. DICOM tags may be standardized fields defined for specific types of data. In some embodiments, a DICOM packet may include a "private" tag, which may have various data structures that may be used by different organizations for different purposes. Although the data transfer described herein is described using DICOM packets, other data packages are also contemplated, such as JSON blocks or xmlblocks. When the DICOM packet is complete, e.g., adding images, reports, other worksheet data, etc., the DICOM packet may be added to a queue that transmits the DICOM packet to the server when a real-time network connection is available.

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

In some embodiments, the intermediate component is a Component Object Model (COM). COM may include a Dispatch function to get a pointer reference in the DOM of the browser component given the function name, parameters, and result data. COM may also include! And the Invoke function is used for executing the corresponding function by using the pointer and obtaining the result.

In some embodiments, interfacing between the system software and the browser component may include injecting code into a script interpreter of the browser component. For example, injecting code may include passing code through an API of a browser component. The browser may execute the injected code, for example, to automatically populate worksheet values or to retrieve already entered worksheet values. The process for injecting code may provide a handle to the results. For example, the handle may be a return value from an API function call, or may be a specified memory location, accessible by system software, to which the result will be written.

Certain embodiments relate to a method performed by a medical imaging device. The method may include retrieving data from a worksheet or table repository server. The data may include one or more fields of a custom worksheet or form. The one or more fields may be based on at least one of a user identification, a location of the medical imaging device, or a medical department using the medical imaging device. The method may further comprise: re-creating a customized worksheet or table at the medical imaging device based on the received data; and displaying the recreated customized worksheet or form on a graphical user interface connected to the medical imaging device. Further, the method may comprise: generating a medical image via a medical imaging device; and automatically forwarding the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

Certain non-limiting embodiments relate to a medical imaging apparatus. The medical imaging apparatus may include: at least one memory including computer program code; and at least one processor. The computer program code may be configured to, when executed by the at least one processor, cause the client medical imaging apparatus to retrieve data from a worksheet or table repository server. The data may include one or more fields of a custom worksheet or form. The one or more fields may be based on at least one of a user identification, a location of the medical imaging device, or a medical department using the medical imaging device. The computer program code may also be configured to, when executed by the at least one processor, cause the medical imaging apparatus to: re-creating a customized worksheet or form on the medical imaging device based on the received data; and displaying the recreated customized worksheet or form on a graphical user interface connected to the medical imaging device. Further, the computer program code may be configured to, when executed by the at least one processor, cause the client station to generate a medical image via the medical imaging apparatus; and automatically forwarding the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

Drawings

FIG. 1 illustrates a system for allowing a user to complete a worksheet for review while disconnected from a worksheet server in accordance with some embodiments of the disclosed technology.

FIG. 2 is a block diagram of a system for accessing information included in a worksheet in accordance with some embodiments of the disclosed technology.

Fig. 3 is a block diagram of a system for interacting with embedded JavaScript functions via system software running on a medical imaging device in accordance with some embodiments of the disclosed technology.

FIG. 4 is a flow diagram of steps for interfacing between point-of-care system software and a browser component to extract or automatically populate worksheet data using an intermediary component in accordance with some embodiments of the disclosed technology.

FIG. 5 is a flowchart of steps for interfacing between point-of-care system software and a browser component to extract or automatically populate worksheet data using code injection in accordance with some embodiments of the disclosed technology.

FIG. 6 is a flowchart of steps performed by system software to operate a worksheet using local memory rather than a real-time server connection, and to transfer worksheet data upon server availability, in accordance with some embodiments of the disclosed technology.

Fig. 7 is a block diagram of an example computing component for executing system software on a point-of-care medical imaging system in accordance with some embodiments of the disclosed technology.

Fig. 8 is an example of a diagram illustrating the general architecture of a system according to some embodiments.

Fig. 9 a-9 f are examples of diagrams illustrating a portion of a system according to some embodiments.

FIG. 10 is an example of a flow chart according to some embodiments.

FIG. 11 is an example of a flow chart illustrating a method according to some embodiments.

Detailed Description

The ability to use and complete worksheets in an offline environment improves point-of-care medical devices for providers operating in the field or in an environment where the computer communication link is only periodic or suboptimal. For example, the operator of the ultrasound machine may examine the patient on-site or at remote clinics that do not have a computer communication link with sufficient bandwidth to allow connection between the ultrasound machine and the remote worksheet server for the entire duration of the examination. Alternatively, the medical imaging device may be used at the patient bedside without the need for a cable or wireless connection to a computer communication link. Sometimes in operating rooms or other emergency care situations, wired network connections may be impractical, and wireless transmissions and connections in these environments may be limited by hospital policy interference requirements and the like. In existing systems, if a doctor does not have access to a real-time network connection, the doctor or assistant takes notes during the exam and then transcribes the notes into a worksheet when a connection is available. Such a process slows down the workflow, requires additional effort, and introduces potential errors when the data is recorded and converted into electronic format.

To address these and other problems, the disclosed technology provides for interaction with a worksheet on a point-of-care system without requiring a real-time connection to a remote worksheet server.

In many ultrasound point-of-care systems, and often in emergency medicine, a scan is performed by a physician rather than a full-time sonographer. Doctors who are not full-time sonographers scan as part of their overall care provided for the patient in an emergency (an unplanned patient). Currently, there is no national or global certification system for these physicians. Thus, each hospital must develop its own policy for determining whether the physician has the level of skill required to operate the device. One advantage of the techniques disclosed herein is that hospitals can use it to record training times and QA/review doctors' examinations in training until they obtain certificates in various applications. The disclosed technology helps record these exams by allowing the physician to complete the worksheet after each exam.

Furthermore, in emergency use situations, it is known that about 90% of ultrasound scans are not billed. In order to bill for the services presented, the medical service provider must be able to indicate that the attending physician is authenticated so that they can bill for the exam. The physician is busy and does not have the time to record the exam from each modality and thus does not receive revenue. The disclosed technology provides an automatic acquisition pair of "what ultrasound examinations do you make on the patient for diagnosis and treatment? "the answer to this question and pass it to the billing system. This information may be obtained through completed worksheets so that the hospital or other service provider may charge for the services presented.

An organization may generate a set of customized worksheets, e.g., worksheets tailored to various departments, such as emergency medicine or radiology departments, and to the most common type of procedure performed. This facilitates the use of such custom worksheets on default software embedded worksheets where a cutting method is impractical and results in infrequent or improper use.

The disclosed technology allows physicians to complete their worksheets while performing an exam without an active computer communication connection and without the need to log in to a remote server, such as a Qpath E server and record their notes and "sign" on the worksheets at the end of the exam (or the end of the day).

Fig. 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 techniques may be used with other medical devices that implement a worklist (e.g., electrocardiographs, PET scanners, X-ray machines, etc.).

In the illustrated embodiment, the point-of-care system 10 is connected to a worksheet server 20 via a computer communication connection 15. The point-of-care system 10 includes one or more processors (not shown) configured to execute programmed instructions ("system software") stored in a computer-readable memory to control the operation of the imaging system. The communication connection 15 to the worksheet server 20 may be a private wired or wireless LAN, or may be a public network such as the Internet. The worksheet server 20 stores a number of worksheets, which may be customized for a particular user, machine, group of machines, or may be common throughout an organization. The user may edit the worksheet, for example to place their own clinic logos on the form or make more substantial changes, such as deciding which information or fields to include or not and in what order, the space for the doctor or technician to note and the area to place the measurements or calculations.

The worksheet server 20 may store the completed worksheet data in a DICOM (Digital Imaging and Communications in Medicine) archiver. DICOM is a standard for processing, storing, printing and transmitting information in medical imaging and recording. It includes file format definitions and network communication protocols. The information in the worksheet may be sent by the DICOM archive to an Electronic Medical Record (EMR) and billing system 30. In addition, images or video clips obtained during the review may be stored on a Picture Archiving and Communication (PACS) system 40. In some embodiments, when the patient records are retrieved on the DICOM archive, the worksheet server 20 retrieves the referenced information from the EMR system 30 and PACS system 40.

When connected to the worksheet server 20, the ultrasound imaging system receives custom server commands and worksheets and other information via computer communication connection 15. In various embodiments, the worksheets may be obtained at various times, such as periodically, when loaded onto the point-of-care system, under the command of an administrator of the point-of-care system (i.e., a "pull" operation), or as a "push" from the worksheet server. The worksheets may be transmitted from the worksheet server 20 to the ultrasound imager in a browser readable format, such as HTML. In some implementations, the worksheet may comprise JavaScript. In some cases, the worksheet may include references to other content, such as images, scripts, CSS files, and the like. These references may be web-based or may be downloaded locally to the point-of-care system. For example, when a real-time network connection is available, the worksheet and any referenced items may be downloaded and saved in the local memory of the point-of-care system. The worksheet may then be used by the point-of-care system, regardless of whether a real-time network connection is available, because the worksheet and the project referenced by the worksheet are available locally.

A browser component implemented by system software running on the point-of-care system 10 may display the worksheet, allowing 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 may be transmitted back to the worksheet server 20 for storage in the DICOM archive server once the computer communication connection is established.

In some implementations, when a user signs a worksheet within the browser component, the browser component can transmit the worksheet, such as by submitting a form that encapsulates the worksheet. However, this option is not available if there is no real-time network connection with the server. As described above, in conventional systems, the worksheets received from the worksheet server 20 are designed to operate in a browser environment that is continuously connected to the worksheet server 20 through the active computer communication connection 15. If the communication link fails or is unavailable, any information entered into the worksheet that has not yet been saved may be lost. Furthermore, switching between worksheets may result in errors or data loss.

To allow the operator of the point-of-care system to complete a worksheet when not connected to the worksheet server 20, the disclosed technology provides a mechanism by which system software running on the point-of-care system 10 can run functions related to the HTML of a particular worksheet (e.g., JavaScript functions). Once retrieved, the system software may encapsulate the worksheet data in a DICOM packet, e.g., as one or more private tags or in a standard DICOM field, and place the DICOM packet in an outbound queue for transmission to the server when a real-time network connection is available. In some embodiments, the system software interfaces with the browser component to extract the worksheet data, regardless of whether a real-time network connection exists. In other embodiments, the browser component directly submits the worksheet data when a real-time network connection is available and interfaces with the system software when a real-time 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 real-time connection to the remote server. In the illustrated embodiment, the worksheet server 20 is connected to the point-of-care system 10 using a communication connection 15. Local memory 100 in the point-of-care system 10 stores HTML and other files defining 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 a user to view and interact with the worksheet. Using the browser component, the user can enter information, make and record measurements, and sign worksheets. The browser component or system software may also be used to associate video clips, still images, or other information with the worksheet data.

As will be understood by those skilled in the art, the worksheets received from the worksheet server may include or reference a plurality of functions (e.g., JavaScript) that provide information about the worksheets rendered in the browser. For example, the function may generate a drop down menu, control radio buttons, display check boxes, and perform other operations that control the manner in which the worksheet is displayed. Some functions may provide metadata about the worksheet, such as whether the sheet contains any information, has been signed by the physician or technician performing the examination, and so forth. Such functions are typically designed to be within the browser component and not to communicate with external applications such as other point-of-care system software. The disclosed techniques provide such external software with a way to cause these functions to execute and obtain their results.

According to some embodiments of the disclosed technology, the system software 25 of the point-of-care system interfaces with the browser component to perform the function either by using an intermediate component (e.g., interface 35) to gain access to predefined functions included in or referenced by the worksheet or by injecting the functions into a script interpreter of the browser component. In some implementations, the interface 35 may be a Component Object Model (COM) interface provided by an operating system of the point-of-care system. In some embodiments, the interface may cause the browser to perform functions including:

getworks hetdata () -get user input data of the form and any signing/approval certificates encapsulated in the data object represented by the string. The packaged data will be transmitted to the worksheet server via DICOM packaging and private tags or by mapping the data to DICOM fields.

Setworkseetdata (workhetedata) -the entire worksheet input data, including any signing/approval data, is set according to workhetedata, which may be a data object (e.g., JSON) package represented by a string of characters.

lsWorksheetSigned () -returns a Boolean value indicating whether the worksheet is signed or not.

lsWorksheetActive () -returns a Boolean value indicating whether the worksheet has any user input data, saved or not.

As will be appreciated, other functions that provide the above information may also be used. The details of the way these functions are written are considered to be known to those skilled in the art of HTML and JavaScript. In embodiments that use intermediate components, the system software knows the identifying information of the function, such as the name of the function, what type of variable to pass to the function, what return value and its type to expect from the function, the code line number, memory location, identifier number, parent object, or other identifying information. The intermediary component may use this information to obtain a facility for performing the functions and obtaining the results of the functions. In other embodiments, access may be obtained by the system software injecting a function directly into the script interpreter of the browser component and receiving any resulting results in response.

With this access, the system software can retrieve information that has been entered into the worksheet by the user using the browser component and metadata about the worksheet itself. The system software stores the retrieved information in local memory. This access also allows the system software to automatically populate the worksheet data back into the worksheet when the worksheet is reopened. In addition, the system may retrieve information from the form and reconfigure the information into a DICOM file, enter pieces of information into corresponding standard DICOM fields or into one or more private tags. The DICOM archive server may extract this information and the worksheet identification information to determine that the information is for a particular worksheet. When a real-time computer communication connection is established, the system software sends a DICOM file.

By allowing 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 may then repackage the information into a DICOM file and transmit the information back to the DICOM archive server when the computer communication connection is reestablished. In some embodiments, the system software stores the DICOM information periodically for each worksheet and when it is closed. If the worksheet is opened again before the information is transmitted to the worksheet server 20, the system may invoke JavaScript commands to restore the information to the previous state in the worksheet so that the doctor or technician can complete the report.

In another embodiment, information about the worksheets being rendered by the browser components is not obtained by invoking embedded scripts, but rather by injecting additional scripts into the HTML DOM using support functions specific to certain browser components, such as those used in WPF and UWP platforms.

FIG. 3 illustrates further details of how system software may interact with a browser component using an intermediary component to retrieve information about a worksheet in accordance with some embodiments of the disclosed technology. Information required for presentation of 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 comprising the worksheet may include HTML text files, JavaScript files, Cascading Style Sheets (CSS) files, or media (e.g., image, audio, video, etc.) files. These files may be stored in directories (and subdirectories, if desired) of the local disk storage on the medical imaging device. When a user selects a worksheet using the graphical user interface, the browser component loads the information for the worksheet and creates a Document Object Model (DOM) corresponding to the worksheet.

In the example shown in FIG. 3, to access information in the DOM for a rendered worksheet, the system software uses a Component Object Model (COM) intermediate interface that provides Dispatch and! lnvoke command. COM may use Dispatch to retrieve pointers to predefined JavaScript functions that provide information about the worksheet or automatically populate the worksheet. The system software may also configure the arguments expected by the function and define the expected result in a manner understandable by the COM interface. Then, use! Invok Command System software instructs COM middleware components to request execution of functions. Any results returned from the function are placed into memory locations in local memory 100 that are known to the system software.

Those skilled in the art will appreciate that the block diagram and flow diagram components shown may be varied in many ways. For example, the order of logic may be rearranged, sub-steps may be performed in parallel, illustrated logic may be omitted, other logic may be included, and so on. In some embodiments, one or more of the above-described components may perform one or more of the following processes.

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

Beginning at 200, the system software calls the Dispatch function of the COM interface to get a pointer to the currently loaded DOM in the browser component. The pointer provides a handle to the worksheet currently being rendered. If the user switches between worksheets, the pointers may be stored and used with the correct pointers for the currently presented worksheets.

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

At 220, the system software calls the Dispatch function, passing an identification to one of the functions of the worksheet to retrieve a pointer to that function. As described above, the identifier may include the names of these functions, which are known a priori to the system software. In some implementations, the system software requests the Dispatch function to return a pointer to one or more of the JavaScript functions, having the following names for the current DOM in the browser component: "GetWorksheetData ()"; "SetWorkSheetData (worktheetaData)"; "IsWorksheetSigned ()"; and "IsWorksheetActive ()". Although these functions may have any names as long as the names are known to the system software, this naming convention is used here as an example, as one skilled in the art would understand what the functions with these names are expected to do and would be able to create them. In some implementations, retrieving the pointer to the identified function can be based on a pointer to a portion of the DOM that includes the script function. For example, a pointer to a portion of the DOM that includes a script function may provide a scope or other context for a function that will obtain a pointer to the identified function.

The variable types used and returned by these functions (e.g., in JavaScript) may be different from the variable types used by COM interfaces. Thus, in the disclosed embodiments, parameters passed to and from functions can be translated into types that can be understood by COM interfaces. At 230, the system software assembles the function call into a set of COM compatible values (VARIANT types). In some embodiments, the function call is created as a structure. For example, one JavaScript function:

functionName (Argl, Arg2, Arg 3, etc.)

Can be encoded as a structure:

COM：

character string name of JavaScript function

BSTR (function name)

Parameter list

BSTR (string argument)

Or VARIANT type

VARIANT _ BOl, VARIANT numerical units

At 240, system software uses! The lnvoke COM interface instructs COM to execute a function. For example, to execute the getWorksheetData () function, the COM interface is instructed to execute the following pseudo code:

{

a COM VARIANT structure/union is created for the return value varResult of the script function.

A COM BSTR is created that represents the name strFunc of the script function to be executed, set to "getworks hetdata".

A COM BSTR representing an empty string is created for the input parameter paraml of the script function, set to ".

A COM Dispatch parameter structure/union is created for the argument dispparams of the script function.

A single parameter paraml is added to disparams.

if (document pointer free, pDIsp) ready pocket

// new documents are already loaded into the browser component.

A COM Dispatch pointer to the currently loaded HTML document is created and saved in pDisp.

}

Using pDispip, a COM Dispatch pointer to the script portion pScript of the HTML document is obtained.

Using pScript, the script function specified by strFunc is found and a Dispatch identifier disk is created for it.

Using pScript and COM Invoke, a script function, denoted discrete, is executed, with an argument of disparams, and a return value, denoted varResult.

Wait for the script function to complete and wait for the COM interface to copy the result into varResult.

Since the expected returned result of the script function is a string result, the BSTR portion of the varResult is converted to a string (e.g., char) that is usable by the system software.

}

At 250, the results of the called function (if any) within the current DOM are stored in memory of 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, BSTR used by COM interfaces, which contains data in JSON format, may be converted to an array of string characters, char [ ], char @, for use by system software.

FIG. 5 illustrates more details of actions performed by system software to inject functions into a browser component that implements a worksheet, in accordance with some embodiments of the disclosed technology. In some embodiments, the process of FIG. 5 is implemented as a sub-process of block 610 or 616 of the process shown in FIG. 6.

At block 502, system software of the point-of-care system may inject code (e.g., JavaScript) into a browser component of a script interpreter for the browser component. In various embodiments, injecting code into the browser may be performed using calls to an API provided by the browser component, through the use of a plug-in installed for the browser component and configured to receive scripts and inject them into the script portion of the worksheet; code is added by accessing and adding script code to the active DOM in the browser component, or by an access point of the browser component, such as a URL bar. In each case, injecting code into the browser component may have one or more handles for obtaining results, if any, of the injected code. For example, the result handle may be a return value from an API or plug-in function call, a memory location shared between the browser component and the system software to which the injected code configuration is written, a call made by the injected code to a Web service local to the point-of-care system, or the system software may be configured to intercept an outgoing request from the browser component and process locally those requests with an identifier (e.g., a specified target, port, etc.) indicating that it is from the injected code.

At block 504, the browser component may execute the injected code. As described above, the injected code may include GetWorksheetData (), discussed above; SetWorkSheetData (workschet data); lsWorksheetSigned (); or one or more functions to which the lsWorkshetActive () function may be compared.

In some embodiments, blocks 506 and 508 may be performed only when the injected code is expected to produce a result, as indicated by the blocks shown in dashed lines. At block 506, the system software may inject a type use handle for the code used to obtain the results of the executed code.

In some implementations, the system software may receive a function call return value for an API or plug-in function call. In other embodiments, the system software may read from a memory location shared between the browser component and the system software, the injected code configured to write the results to the memory location. In other implementations, the injected code may include operations to make a Web request (e.g., operations using XMLHttpRequest () in JavaScript), where the request may be targeted to a Web service local to the point-of-care system, and the data encapsulated in the request (e.g., as GET or POST data) may be extracted through a script hosted by the local Web service. In addition, the system software can intercept outgoing requests from the browser component and extract data encapsulated in the requests.

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

FIG. 6 is a flowchart of steps performed by system software to operate a worksheet, use local memory instead of a real-time server connection, and transmit worksheet data when a server is available, in accordance with some embodiments of the disclosed technology. At block 602, the system software may obtain worksheets from the worksheet server and store them in local memory. In various embodiments, obtaining the version of the worksheet may be initiated by the requesting device (i.e., a "pull" operation) or by the worksheet server (i.e., a "push" operation). In various embodiments, obtaining a version of a worksheet may be triggered by an administrator command (local or from a remote system), by a periodic automatic update request, in response to a user request to access the worksheet when a new version of the worksheet is available, or when an active connection is established with the worksheet server.

By using a worksheet from the worksheet server, the worksheet may be customized for a particular organization, for example, to maintain a particular look and feel, to include particular fields corresponding to data that the organization wishes to collect at the point-of-care system, or to specify how fields in the worksheet are organized to enable a particular data collection workflow. The worksheet may be customized for a particular point-of-care system or set of point-of-care systems. In some embodiments, the worksheet may be a file that defines fields using HTML. In some implementations, the worksheet file may include other content, such as scripts (e.g., JavaScript), images or other media, CSS, and the like. Alternatively or additionally, the worksheet file may include references to other content stored in the local memory of the point-of-care system. This allows other content to be shared between worksheets and allows the worksheets to be updated without having to re-download the unchanged portions of the worksheets. In some implementations, the worksheet and/or additional content may be stored in a solid state drive of the point-of-care system. In some embodiments, the worksheet and/or additional content may be stored in a secure manner, such as by encryption.

Once block 602 is complete, the worksheets and their corresponding other content have been stored locally. Additionally and as described below, the point-of-care system can extract and locally store data entered into the worksheet. Thus, once block 602 is complete, the point-of-care system may implement the remaining blocks 604 through 624 without a real-time server connection.

At block 604, the system software of the point-of-care system may execute the 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 configured to be integrated with or embedded into the system software such that it is not readily apparent that the browser component is separate from other aspects of the system software. In various embodiments, executing the browser component may be performed as part of system software initialization or in response to a user selecting to open a worksheet.

At block 606, the browser component can load the selected worksheet from local memory, such as the worksheet selected by the user during a patient examination. This may be accomplished by providing the worksheet to the browser component from its location stored in local memory at block 602. Where the worksheet has references to other content stored in local memory, the browser component can parse these references and retrieve the other content to fully render the worksheet and execute additional code, such as the referenced JavaScript or CSS.

At block 608, the system may determine whether unsigned or other portions of data are stored in local memory for the worksheet loaded at block 606. In some embodiments, this is done by examining which worksheet was loaded at block 606 and determining whether corresponding worksheet data has been stored. For example, metadata identifying the worksheets may be stored in association with the worksheet data in local memory. Worksheet data may be identified without having been signed 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 further identifies the unsigned worksheet data only if it also has an identifier of the current patient, at block 608. If at block 608, worksheet data is identified, processing continues to block 610. Otherwise, processing continues to block 612.

At block 610, the worksheet data identified at block 608 may be obtained from local storage and provided to the browser component. Code included in the worksheet or injected by the system software may automatically populate fields of the worksheet using the already provided worksheet data. The process for inserting worksheet data into worksheet fields using the middleware component is described above in connection with FIG. 4. The process for inserting worksheet data into a worksheet using code injection is described above in connection with FIG. 5.

At block 612, the user and/or the automated system may interact with the worksheet. For example, a user may enter information into a field, or other collected data may be entered or associated with a worksheet, such as data scanned from a code (e.g., barcode, two-dimensional code, etc.), calculations, measurements, images, readings, other scan results, and the like.

At block 614, a trigger condition for saving the worksheet data may be identified. In some implementations, the trigger condition can be an event that will cause the browser component to navigate away from the current page, which will cause the browser component to clear the DOM of the current worksheet. For example, such events may include a user actuating a control to end a patient examination, 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.), which will cause the system software to close the browser component.

At block 616, the data entered into the current worksheet may be extracted and saved to local memory. For example, extracting data from the worksheet may be accomplished by using an intermediate component to identify a reference to the GetWorkshetData () function and execute the function or by injecting the code of the GetWorkshetData () function into a browser component and retrieving the result. The process for extracting data from a worksheet using the middleware component is described above in connection with FIG. 4. The process for extracting data from a worksheet using code injection is described above in connection with FIG. 5. The extracted worksheet data may be saved in a secure manner, such as by encryption.

At block 618, the system software may determine whether the worksheet data is signed. In various embodiments, this may be done by examining variables embedded or otherwise associated with the extracted worksheet data (e.g., metadata) or by performing an lsWorksheetSigned () function using intermediate components or code insertions. If the worksheet has not yet been signed, processing returns to block 606 when the worksheet is selected again for loading into the browser component. If the worksheet is signed, processing continues to block 620.

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

At block 622, the system software may determine whether the DICOM packet is complete. In some embodiments, the system software may determine that the DICOM package is complete when a specified set of material, such as images, reports, worksheet data, other metadata, etc., is included. In other embodiments, when the user provides an indication of this effect, for example by clicking on the end check control, the system software identifies the DICOM package as complete. If the DICOM packet is incomplete, processing remains at block 622 until additional input is received indicating that the DICOM packet is complete. Once the DICOM packet is complete, processing continues to block 624.

At block 624, the system software may add the completed DICOM packet to a queue configured to transmit the DICOM packet in the queue to one or more servers when a real-time network connection is available.

Fig. 7 is a block diagram of an example of a computing component 700 for executing system software on a point-of-care medical imaging system in accordance with some embodiments of the disclosed technology. The elements of the computing assembly 700 may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. The computing component 700 can include one or more input devices 720, the input devices 720 providing input to the processor 710 (e.g., CPU, GPU, HPU, etc.), notifying it of actions. These actions may be mediated by a hardware controller that interprets signals received from the input device and communicates the information to the processor 710 using a communication protocol. Input devices 720 include, for example, a mouse, keyboard, touch screen, ultrasound, X-ray or other medical scanning component, infrared sensor, touch pad, wearable input device, camera or other vision-based input device (e.g., barcode or two-dimensional code reader), microphone, or other user input device.

Processor 710 may be a single processing unit or multiple processing units in one device or distributed across multiple devices. Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. For example, the processor 710 may be coupled to other hardware devices using a bus, such as a PCI bus or SCSI bus. The processor 710 may communicate with a hardware controller for a device such as a display 730. The display 730 may be used to display text and graphics. In some implementations, the display 730 provides graphical and textual visual feedback to the user. In some implementations, the display 730 includes an input device as part of the display, such as when the input device is a touch screen or is equipped with an eye direction monitoring system. In some embodiments, the display is separate from the input device. Examples of display devices are: LCD display screens, LED display screens, projection, holographic or augmented reality displays (e.g., heads-up display devices or head-mounted devices), and the like. Other I/O devices 740 may also be coupled to the processor, such as a network card, video card, sound card, USB, camera, printer, speaker, CD-ROM drive, DVD drive, disk drive, or Blu-ray device.

In some implementations, the computing component 700 also includes a communication device capable of wireless or wired communication with the network node. The communication device may communicate with another device or server over a network using, for example, the TCP/IP protocol. The computing component 700 can distribute operations among a plurality of network devices utilizing a communication device.

The processor 710 may access the memory 750 of the point-of-care system. The memory includes one or more of a variety of hardware devices for volatile and non-volatile memory, and may include read-only memory and writeable memory. For example, the memory may include Random Access Memory (RAM), various caches, CPU registers, read-only memory (ROM), and writable non-volatile memory, such as flash memory, hard disk drives, floppy disks, CDs, DVDs, magnetic storage devices, tape drives, device buffers, and the like. The memory is not a propagated signal off the underlying hardware; thus, the memory is non-transitory. Memory 150 may include program memory 760 that stores computer programs, such as an operating system 762 (e.g., Windows, AppleOS, Unix, etc.), system software (with browser component) 764, and other application programs 766. The memory 750 may also include a data store 770, which data store 770 may store data, such as worksheets and worksheet data, to be provided to the program store 760 or any element of the computing assembly 700.

As described below, certain embodiments may allow a user to download customized worksheets directly to a medical imaging device based on the user's role, workflow preferences, and/or the location or department that is using the medical imaging device. In some embodiments, the system may provide automated acceleration of workflow for customized worksheets or forms. In one particular example, an automated workflow can facilitate expediting the creation of worksheets or forms for studies that have not yet been ordered from an electronic medical record system. Using an accelerated workflow may allow automated reconciliation of patient orders with demographic data, allowing the healthcare facility to process patients who did not originally generate orders. This may be particularly beneficial to emergency rooms or trauma patients where the timeliness of medical orders is critical.

In some 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. Middleware may be computer software that sits between an operating system and one or more software applications. The middleware application may provide the ability for system users to create one or more customized worksheets or tables. In one example, the software application may be a browser through which a worksheet or form is displayed. For example, the custom worksheet or form may be notes made by a physician for accompanying medical images. These notes may then be forwarded to one or more departments, such as a billing department in a medical facility and/or a pharmacy of the medical facility. The user may be a doctor, non-doctor, health care professional, or any other person using a point-of-care ultrasound device. In other embodiments, the user may use one or more other medical imaging devices, such as a Magnetic Resonance Imaging (MRI) machine, a Computed Tomography (CT) scanner, a Nuclear Medicine (NM) imaging device, an electrocardiograph, a Positron Emission Tomography (PET) scanner, and/or an X-ray machine, instead of or in addition to using a point-of-care ultrasound device.

The system may include one or more processes or methods that may be customized to create or create a worksheet or table. For example, one or more of the processes or methods may be a custom program or an educational clinical imaging workflow. The processes or methods may be customized according to the following non-exclusive factors: the type of exam, the location where the exam occurred, the department in which the exam was performed, the identity of the physician performing the exam, the location within the medical facility where the exam occurred, and/or any other factors that may be used to determine the fields included in the worksheet or form. In some embodiments, the workflow may be a custom or default inspection workflow type that may be used for multiple modality types. For example, the modality types may be different imaging devices, such as ultrasound, MRI, CT scanner, NM imager, PET scanner, electrocardiograph, and X-ray. The custom fields of the worksheet or form may be saved as metadata to a database included in the physical server or the cloud-based server. In certain embodiments discussed herein, the term "data" may include metadata.

Customization of the worksheet or form may occur before the workflow begins. In other words, the user may create a customized template of a worksheet or form. The user may determine one or more fields to include in the worksheet or form depending on the factors described above. When using the medical imaging apparatus, a user may manually input the identification information into a Graphical User Interface (GUI), a display, or a computer attached to the medical imaging apparatus using an Application Programmable Interface (API). In some embodiments, the workflow accelerator application may be vendor independent, meaning that the application may run on medical imaging devices manufactured by a number of different vendors. In other embodiments, the identification information of the user may be automatically input via a sensing or detection device that may sense or detect the user identification. For example, automatic entry of user identification may include barcode scanning using a standard matrix (2d) or Quick Response (QR) code in a particular format. For example, the format may be < FFSS >,,,, BADGEID </FFSS >. Once the identification is scanned, the scanned identification field may be automatically populated into the device. In some embodiments, the worksheet code may include an interface that allows a user to obtain one or more execution fields. The user identification may be a user name, a user identification issued by a medical facility, or any other identification used to identify a user. Once the user identification is entered, the contents of the custom template worksheet or form may be downloaded to the medical imaging device from a worksheet server or any other database. The content may then populate the worksheet or form to create or display a customized worksheet or form for the user.

In certain embodiments, the workflow accelerator application may provide an API on a GUI attached to the medical device. The API may be used by a user to enter a user identification and fill out one or more fields of a custom worksheet or form. In some embodiments, the API may accept Hypertext Transfer Protocol (HTTP) requests according to RFC (request for comments)2616, and/or HTTP secure (HTTPS) requests according to RFC 2818. The request body sent to the API to request customization of the worksheet or form metadata is in JSON format, compliant with RFC 8259. The entire disclosures of RFC 2616, RFC 2818, and RFC 8259 are incorporated herein by reference.

In some embodiments, the workflow accelerator application may allow a user, such as a physician, to record findings from the medical imaging device on a custom worksheet or form. In some embodiments, the user may insert the electronic signature into a custom worksheet or form. For example, the electronic signature may be a signature in compliance with the U.S. food and Drug Administration (U.S. food and Drug Administration) under part 11 of Code of Federal Regulations, title 21, part 11 of the united states. Thus, the user may use the workflow accelerator application to generate a customized worksheet or form that conforms to any electronic records and electronic signature requirements of the medical facility.

The workflow accelerator application may classify the filled-in customized worksheet or form into one or more categories. The category may be based on the purpose of the imaging performed by the user. For example, one category may be education, where imaging is performed for educational purposes. Another category may be billable, where imaging is performed as part of the patient's medical care and insurance for the patient may be billed. One or more categories may be used to determine through which workflow a customized worksheet or form is transported. For example, worksheets or forms classified as educational may be automatically or manually forwarded to an educational workflow, while worksheets or forms classified as billable may be automatically or manually forwarded to a billable workflow.

As described above, based on the category, the application may transmit the filled-in customized worksheet or form to one or more locations. For example, when the performed imaging is classified as billable, the application may transmit the custom worksheet or form and the contents therein to the billing system. In some other embodiments, the customized worksheet or form may be transmitted to any database or server, such as a worksheet or form repository or worksheet server. The transfer may be automatic, without input from the user or end-user interaction, based only on at least the categories of the customized worksheet or form. Alternatively or additionally, the transmission may be manual, requiring input from the user. In a manual transmission, the user may determine where to send the customized worksheet or form. Imaging that may be included as part of the study may be transmitted using Health care standards, such as Health Level Seven Messaging (HL 7), Digital Imaging over Messaging (DICOM), or any other Messaging standard for medical Imaging.

Fig. 8 is an example of a diagram illustrating the general architecture of a system according to some embodiments. The user may create a template for a worksheet or form using browser 810. In another embodiment, the template may be created by an administrator other than the user. The template may be created directly on the medical imaging device or on a separate computer. The template may be created according to the following factors: the type of exam, the location where the exam occurred, the department in which the exam was performed, the identity of the physician performing the exam, the location within the medical facility where the exam occurred, and/or any other factors that may determine the fields or questions included in the worksheets or forms. These factors may be used to define the user's workflow preferences. In other words, these factors may determine whether one or more fields are included in a custom worksheet or form.

For example, one field in the custom worksheet or form may be the applicable billing code. The billing code may be associated with any of the factors discussed above. In some embodiments, the billing code may be specific to the medical facility in which the imaging device is located. The presence of billing codes may be helpful in facilitating automatic or manual transmission of customized worksheets or forms. A user of the system or a separate administrator may assist in programming billing codes for a given medical facility into a custom worksheet or form.

In some embodiments, information entered by a user or administrator when creating a template worksheet or form may be stored or saved in a database as metadata (also referred to below as data). The database may be included in the worksheet server 20 shown in FIGS. 1 and 2, or any other server accessed by the system, such as the application managed worksheet/table repository 820. The metadata may be retrieved by a user through an API. For example, a medical device used by a user may contact an API to retrieve metadata for a worksheet or table via HTTP, HTTPs, or any other internet application protocol.

FIG. 8 illustrates a system in which a workflow accelerator application may create a customized worksheet or form based on factors and automatically or manually transmit or route the filled-in worksheet to a desired location or workflow. Templates for custom worksheets or forms may be created using browser 810. In some embodiments, the template may be automatically generated, taking into account one or more factors, without any input from a user or administrator. For example, the template may be automatically generated based on a given medical facility or approved vendor. The customized worksheets or forms may be stored as metadata in an application managed worksheet or form repository 820. When using an imaging device 830, referred to as a modality, API requests may be transmitted to repository 820 requesting stored metadata for a customized worksheet or form. The API request may be a JSON formatted HTTP or HTTPs Web request. Although the imaging device shown in fig. 8 is an ultrasound machine, such as a point-of-care ultrasound device, any other modality may be used, such as MRI, CT scan, NM imaging, or X-ray.

After receiving or retrieving the metadata, the imaging apparatus 830 may populate or recreate the custom worksheet or form. The customized worksheet or form 840 may be displayed on the imaging device or a computer, GUI, or display capable of communicating or connecting with the imaging device. In some embodiments, the application for displaying the customized worksheet or form 840 may include fields that allow the physician to enter an electronic signature into the customized worksheet or form 840. The electronic signature may be entered using a variety of methods, including at least a touch screen that allows the doctor to enter the signature, a checkbox that can be clicked to enter a previously saved digital signature, or a drop-down menu that allows the doctor to select the electronic signature. In another example, the electronic signature may be entered using any available authentication or re-authentication method, wherein the user may be prompted to enter one or more credentials for verifying the user's identity. The imaging device 830 may also be used to image the patient and send or transmit the resulting image 850 to a memory server or cloud via DICOM. A custom worksheet or form 840, with or without a doctor's electronic signature, may be associated with the image 850. For example, only DICOM private tags, which may be in JSON format, may be associated.

The images and/or associated worksheets or table data may be routed automatically or manually using application services router 860. In certain embodiments, the images and/or associated worksheets or forms data may be transferred or routed through the educational workflow to an application managed worksheet or forms repository 820. For example, in such embodiments, a worksheet or table may be categorized as educational. The user may then review the customized worksheet or form using browser 810. During review, the user may edit, change, add, or remove custom worksheets or forms. After review, the custom worksheet or form may be signed using an electronic signature and/or converted into a signed worksheet or form report 870, which may be transmitted to the EMR 880. The customized worksheet or form may be transferred manually or automatically.

In some other embodiments, the image and/or associated worksheet or table data may be routed to the EMR 880 through the billable workflow using the application services router 860. For example, a worksheet or table may be classified as billable. The images and/or associated worksheet or table data may be automatically or manually routed or reported to the electronic health record system in the form of text or encoded Portable Document Format (PDF). The images and/or associated worksheets or table data may alternatively be routed via medical delivery standards using any other format. The output of the routing image and/or associated worksheets or tables may be signed worksheets or table reports 870. The report may be forwarded and stored in the EMR 880.

Fig. 9a is an example of a diagram illustrating a portion of a system according to some embodiments. Portions of the system may include a worksheet server 910 and a medical imaging device 920, and the worksheet server 910 may also be an application managed worksheet or form repository 820 shown in FIG. 8. In particular, fig. 9a illustrates an API request architecture for verifying connectivity from a medical imaging device 920. As shown in fig. 9a, the medical machine 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 connectivity, and in response thereto, the worksheet server 920 may send a response message in the form of an HTTP 200 response indicating that the request has succeeded. For example, the request may be http:// < full qualified domain name >/external/verify. The content type of the response message may be HyperText Markup Language (html) or text, allowing the medical imaging apparatus 200 to connect to the worksheet server 910.

Fig. 9b is an example of a diagram illustrating a portion of a system according to some embodiments. In particular, FIG. 9b illustrates retrieving a custom file for presenting a worksheet or form template. For example, the retrieval may be triggered by a user of the medical imaging device entering identification information into the device itself or a computer connected to the device. The medical imaging device 920 may transmit a request message to retrieve all metadata from the worksheet server 910. For example, the request may be http:// < full qualified domain name >/external/Get AIIFiliePaths. In response, the worksheet server 910 may send a response message in the form of an HTTP 200 response indicating that the request has succeeded. The content type of the response message may be an application or JSON. The body of the response message may include data or metadata that may be used by the medical imaging device to create a template worksheet or table.

Fig. 9c is an example of a diagram illustrating a portion of a system according to some embodiments. In particular, fig. 9c illustrates retrieving individual artifact files (artifact files) for presentation by the medical imaging device 920. For example, each artifact file may include one or more JavaScript libraries, one or more stylesheets for formatting a worksheet in the medical imaging device, or various icons for identification and/or rendering. The medical imaging device 920 may transmit the request message in the form of an HTTP GET message to obtain one or more files from the worksheet server 910. For example, the request may be http:// < full qualified domain name >/external/download filename > < filename >. In response, the worksheet server 910 may send a response message in the form of an HTTP 200 response indicating that the request has succeeded. The content type of the response message may be, for example, an application or an octet stream. The response may be a byte stream that includes the requested file and the content included therein.

Fig. 9d is an example of a diagram illustrating a portion of a system according to some embodiments. In particular, fig. 9d shows retrieving a list of worksheets or tables available on the system for a virtual location/department based on the application entity name of the medical imaging device. For example, the virtual location of the medical imaging device may be an emergency room of a hospital or medical facility. The term "location" as used herein may include a virtual location. For example, the department may be an emergency department of a hospital or medical facility. The medical imaging device 920 may transmit the request message in the form of an HTTP GET message that includes the application entity name of the medical imaging device. For example, the request may be http:// < full qualified domain name >/external/GetWorksheetl _ istvidence name ═ AETITLE. In response, the worksheet server 910 may send a response message in the form of an HTTP 200 response indicating that the request has succeeded. The content type of the response message may be an application or JSON. In some embodiments, the response may include a review type identification, a review type name, a review type description, a worksheet identification, a worksheet name, and/or a worksheet description.

Fig. 9e is an example of a diagram illustrating a portion of a system according to some embodiments. In particular, FIG. 9e illustrates retrieving individual worksheets or tables based on the worksheet identification number. The medical imaging device 920 may transmit the request message in the form of an HTTP GET message that includes the worksheet identification. For example, the request may be http:// < full qualified domain name >/external/GetWorksheetl _ istworkheetid [ < workheetid >. In response, the worksheet server 910 may send a response message in the form of an HTTP 200 response indicating that the request has succeeded. The content type of the response message may be text or HTML. The response may include a worksheet template with a worksheet identification included in the request message sent from the medical imaging device 920.

Fig. 9f is an example of a diagram illustrating a portion of a system according to some embodiments. In particular, fig. 9f illustrates retrieving metadata or content for one or more worksheets or tables for a virtual location or department based on the application entity name of the medical imaging device. The medical imaging device 920 may transmit the request message in the form of an HTTP GET message that includes the application entity name. For example, the request may be http:// < full qualified domain name >/external/workhetesdevicenName ═ AETITLE. In response, the worksheet server 910 may send a response message in the form of an HTTP 200 response indicating that the request has succeeded. The content type of the response message may be an application or JSON. The response may include metadata associated with the virtual location or department. The medical imaging device 920 may use the retrieved metadata to generate a customized worksheet or table.

In certain embodiments, the customized worksheet or form data may be sent back to the system from the medical device. The data may be appended as JSON. In addition, or in the alternative, data may be appended to or associated with one or more images in the series contained in the DICOM private tag, the data type being infinite text. Upon receiving one or more images and associated data, the system can automate various workflow results. For example, one or more images and associated data may be transmitted to a billable workflow or an educational workflow.

FIG. 10 is an example of a flow chart according to some embodiments. In particular, FIG. 10 illustrates a process for automating various workflow results. Application service router 1010 may be similar to application service router 860 shown in fig. 8. In some embodiments, a determination 1020 may be made whether to automate the billable reporting. A study, which may include one or more images generated by a medical imaging device, may not qualify if performed by a non-certified student or a learner in the certification program of a particular worksheet. In such embodiments, the images and/or associated data may be transmitted to the educational workflow 1040. Educational workflow 1040 may include routing to an application for review by a doctor or non-doctor, as shown in fig. 8.

In other embodiments, the study may be eligible for automated billable transfer. In such embodiments, the report may be communicated to a clinical, automated billable workflow 1030. For example, the automated billable workflow 1030 may include transferring populated or filled worksheets and/or forms to one or more internal or external billing systems, for which the worksheets or form data may be used to bill one or more hospital or medical facility charges. For example, the study may be eligible for automated billable transfers if there are approved provider signatures, according to Code of Federal Regulations, title 21, part 11, Electronic Records and Electronic signatures (Electronic Records and Electronic signatures) FDA requirements. A study may also be eligible when the study has a corresponding order, encounter, or visit identified by the system, and/or the study has a corresponding patient identifier in the system. In some embodiments, a study may be eligible for automated billable transfer when the study has been performed by a student or learner in an authentication provider or authentication procedure. The study is also eligible for automated billable transfer when the study has been determined to be submitted to a downstream billing or electronic medical record system.

The order may be a clinical transaction that is conducted in order to inform the system to plan or schedule a procedure for the patient. For example, a doctor may create an order for a planned ultrasound scan. In some embodiments, the order may be passed to a billable workflow, meaning that the program for which the order is intended may be billed. For billing purposes, it may be desirable to provide evidence of the program in the form of results. For example, the results may be populated or filled-in worksheets or forms that the user may use to enter findings. On the other hand, a study may be identified as billable when one or more of the following applies: i) the order is associated with a study; ii) patient encounter or visit is identified or associated with the study; or iii) the worksheet or table includes at least one Current medical procedure Terminology (CPT) code currently in use and/or signed by a certified doctor. In other embodiments, the study may be identified as billable using any other available method.

Fig. 11 is an example of a flow chart illustrating a method according to some embodiments. In particular, fig. 11 shows a method performed by a medical imaging apparatus. In step 1110, the medical imaging device retrieves data from the worksheet or table repository server data. The data may include one or more fields of a custom worksheet or form. The one or more fields are based on at least one of a user identification, a location of the medical imaging device, or a medical department using the medical imaging device. In some embodiments, one or more fields of a customized worksheet or form may be predefined by a user or administrator prior to retrieving data from a worksheet or form repository server as part of a billable workflow or educational workflow. For example, 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 an application entity name or a worksheet identification number of the medical imaging device. In some embodiments, prior to retrieving the data, a request may be transmitted from the medical imaging device to a worksheet or table repository server to verify connectivity thereof.

In step 1120, the medical imaging device may recreate a custom worksheet or table based on the received data. The re-created customized worksheet or form may then be displayed on a graphical user interface connected to the medical imaging device, as shown in step 1130. The middleware application may be used to display the recreated customized worksheet or form. In step 1140, a medical image may be generated via a medical imaging device. The customized worksheet or form may be associated with the medical image via DICOM proprietary tags or standard structured reports. In some embodiments, the user's electronic signature may be inserted into a custom worksheet or form, as shown in step 1150.

In step 1160, the customized worksheet or form and the medical image may be automatically forwarded to a billable workflow or an educational workflow. In some embodiments, the customized worksheet or form and the medical image may be automatically forwarded to the educational workflow when the user is a non-authenticated student, a learner in the authentication program, or a provider not included in the authentication program. In such embodiments, the customized worksheet or form may be routed to a worksheet or form repository server. The user may then use the browser to review, provide security feedback, or approve the customized worksheet or form for the billable workflow. The security feedback may include using any known encryption, such as transport layer security protocols. For example, review may include making changes, edits, additions, or deletions to the customized worksheet or form. Thus, the authentication procedure may include a list of learners, students, or providers, which may include doctors or non-doctors. In some embodiments, learners, students, or providers in the authentication program may review and/or modify the customized worksheet or form, while in other embodiments learners, students, or providers not included in the authentication program may review and/or modify the customized worksheet or form.

In certain other embodiments, the customized worksheet or form and the medical image may be automatically forwarded to the billable workflow when: i) approved providers are signed on a custom worksheet or form; ii) the medical image corresponds to an identified order, encounter, or visit; iii) the customized worksheet or form comprises a patient identifier; iv) the user is an authentication provider of the student in the authentication procedure; or v) the medical image has been identified for submission to a billable workflow. The customized worksheets or forms and medical images may be routed to the EMR system as part of a billable workflow or an educational workflow.

In certain embodiments, the methods or processes illustrated in FIG. 11 and in other exemplary embodiments described herein may be vendor independent. In other words, the method or process may be performed on medical imaging devices manufactured by one vendor, and may be performed on different medical imaging devices manufactured by different vendors. In some other embodiments, the methods or processes discussed above may be performed by a server, such as the worksheet or table repository server 820 shown in FIG. 8.

Accordingly, the above disclosed embodiments facilitate improving the system by generating a customized worksheet or form specific to the location of the medical imaging device in the user, department, or medical facility. Some embodiments may also automate the forwarding of customized worksheets or forms to billable workflows or educational workflows for processing. Such automated forwarding and generation of customized worksheets may help to improve workflow efficiency by reducing the amount of network and system resources used to process medical orders, worksheets or forms. Reducing resource usage, increasing network efficiency, and allowing custom worksheets and forms that may take the form of medical orders may help increase the processing speed of electronic medical records through the system. Accordingly, the above-described systems, methods, and devices help provide significant improvements in the functionality of servers, medical imaging devices, and any other components of an EMR system.

A computer program (also known as a program, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including 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 may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that contains other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

Several embodiments of the disclosed technology are described above with reference to the accompanying drawings. Reference in the specification to "an example" or "an embodiment" (e.g., "some embodiments," "various embodiments," "one embodiment," "an embodiment," etc.), etc., means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. In addition, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not other embodiments.

Relative terms, such as high or unimportant, when not otherwise defined, may be understood as assigning a value and determining how the value is compared to a given threshold. For example, the phrase "selecting a quick connection" may be understood to mean selecting a connection having an assigned value corresponding to its connection speed being above a threshold value. As used herein, the word "or" refers to any possible permutation of a group of items. For example, the phrase "A, B, or C" refers to at least one of A, B, C, or any combination thereof, such as any one of: a; b; c; a and B; a and C; b and C; A. b, and C; or multiples of any of the items, such as a and a; B. b, and C; A. a, B, C, and C; and the like.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Specific examples and implementations have been described herein for illustrative purposes, but various modifications can be made without departing from the scope of the examples and implementations. The specific features and acts described above are disclosed as example forms of implementing the claims. Accordingly, the examples and embodiments are not to be limited by the claims that follow.

Any of the above patents, patent applications, and other references are incorporated herein by reference. Aspects can be modified, if necessary, to employ the systems, functions and concepts of the various references described above to provide yet further embodiments. To the extent statements or subject matter in the documents incorporated by reference conflict with statements or subject matter of the present application, the present application shall control.

Claims (20)

1. A method for a medical imaging apparatus, comprising:

retrieving data from a worksheet or form repository server, wherein the data comprises one or more fields of a customized worksheet or form, wherein the one or more fields are based on at least one of an identification of a user, a location of the medical imaging device, or a medical department using the medical imaging device;

re-creating the customized worksheet or form at the medical imaging device based on the received 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; and

automatically forwarding the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

2. The method of claim 1, wherein the one or more fields of the customized worksheet or form are predefined by the user or administrator as part of the billable workflow or educational workflow prior to retrieving the data from the worksheet or form repository server.

3. The method of claim 1, further comprising:

routing the customized worksheet or form and the medical image to an electronic medical record system as part of the billable workflow or educational workflow.

4. The method of claim 1, further comprising:

inserting the user's electronic signature into the customized worksheet or form.

5. The method of claim 1, wherein the customized worksheet or form and the medical image are automatically forwarded to the educational workflow when the user is a non-authenticated student, a learner in an authentication procedure, or a provider not included in the authentication procedure.

6. The method of claim 5, further comprising:

routing the customized worksheet or form to the worksheet or form repository server, wherein the user may use a browser to at least one of: review the custom worksheet or form, provide security feedback, or approve the custom worksheet or form.

7. The method of claim 1, wherein the customized worksheet or form and the medical image are automatically forwarded to the billable workflow when: i) approved providers are signed on the custom worksheet or form; ii) the medical image corresponds to an identified order, encounter, or visit; iii) the customized worksheet or form comprises a patient identifier; iv) the user is an authentication provider of a student in an authentication procedure; or v) the medical image has been identified for submission to the billable workflow.

8. The method of claim 1, wherein the one or more fields comprise a billing code for the medical image.

9. The method of claim 1, further comprising:

transmitting a request from the medical imaging apparatus to the worksheet or form repository server, wherein the request is to verify connectivity of the medical imaging apparatus and the worksheet or form repository server.

10. 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 application entity name or a worksheet identification number of the medical imaging device.

11. The method of claim 1, further comprising:

associating the customized worksheet or form with the medical image via digital imaging communications through messaging (DICOM) proprietary tags or standard structured reports.

12. The method of claim 1, further comprising:

using a middleware application for displaying the recreated customized worksheet or form.

13. The method of claim 12, further comprising: using the middleware application for modifying, deleting, or appending the recreated customized worksheet or form by the user.

14. The method of claim 1, wherein the method is performed on the medical imaging device manufactured by a vendor and a different medical imaging device manufactured by a different vendor.

15. The method of claim 1, wherein the medical imaging device is an ultrasound machine, a magnetic resonance imaging device, a computed tomography scanner, a nuclear medicine imaging device, an electrocardiograph, a Positron Emission Tomography (PET) scanner, or an X-ray machine.

16. A medical imaging apparatus, comprising:

at least one memory including computer program code; and

at least one processor for executing a program code for the at least one processor,

wherein the computer program code may be configured to, when executed by the at least one processor, cause the client medical imaging apparatus to:

retrieving data from a worksheet or form repository server, wherein the data comprises one or more fields of a customized worksheet or form, wherein the one or more fields are based on at least one of an identification of a user, a location of the medical imaging device, or a medical department using the medical imaging device;

re-creating the customized worksheet or form on the medical imaging device based on the received 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; and

automatically forwarding the customized worksheet or form and the medical image to a billable workflow or an educational workflow.

17. The medical imaging apparatus of claim 16, wherein the computer program code is configurable, when executed by the at least one processor, to cause the client medical imaging apparatus to:

routing the customized worksheet or form and the medical image to an electronic medical record system as part of the billable workflow or educational workflow.

18. The medical imaging apparatus of claim 16, wherein the computer program code is configurable, when executed by the at least one processor, to cause the client medical imaging apparatus to:

inserting the user's electronic signature into the customized worksheet or form.

19. The medical imaging device of claim 16, wherein the customized worksheet or form and the medical image are automatically forwarded to the educational workflow when the user is a non-authenticated student, a learner in an authentication procedure, or a provider not included in the authentication procedure.

20. The medical imaging device of claim 16, wherein the customized worksheet or table and the medical image are automatically forwarded to the billable workflow when: i) approved providers are signed on the custom worksheet or form; ii) the medical image corresponds to an identified order, encounter, or visit; iii) the customized worksheet or form comprises a patient identifier; iv) the user is an authentication provider of a student in an authentication procedure; or v) the medical image has been identified for submission to the billable workflow.

Images