JP2023506149A - Method and Apparatus for Interacting with Medical Worksheets - Google Patents

Abstract

Certain embodiments are directed to methods, systems, or apparatus, such as medical imaging devices. The method includes retrieving data from a worksheet or form repository server. The data includes one or more fields of a customized worksheet or form. The one or more fields are based on at least one of the user's identifier, the location of the medical imaging device, or the medical department using the medical imaging device. The method also includes re-creating the customized worksheet or form at the medical imaging device based on the received data, and connecting the re-created customized worksheet or form to the medical imaging device. displayed on the GUI. Additionally, medical images are generated via a medical imaging device and the customized worksheets or forms and medical images are automatically transferred to a billable or educational workflow. [Selection diagram] Figure 1

Description

[Cross reference to related applications]

This application claims priority to U.S. patent application Ser. No. 16/144,795, filed Sep. 27, 2018, claiming priority to No. 578,277, which is hereby incorporated by reference in its entirety. .

TECHNICAL FIELD The disclosed technology relates to point-of-care medical systems and, more particularly, to systems for completing patient-care worksheets on point-of-care ultrasound systems without connecting to a live server.

During or at the end of most medical procedures, a physician or technician is asked to complete a form or worksheet documenting the tests performed. Such worksheets can store basic information such as patient name, physician name, procedure type or imaging modality, date and location. Additionally, the electronic worksheets may include still or video images taken during the exam, measurements, calculations or annotations, physician notes, diagnoses, and the like. Completed worksheets are stored in a system that can receive or accept the DICOM (Digital Imaging and COmmunications in Medicine) protocol. Additionally, some of the information in the completed worksheet can be used by the medical billing system to request payment for procedures.

A physician or technician can complete the worksheet using the point-of-care medical system. A point-of-care medical system can be integrated with medical equipment, such as an ultrasound machine, can be operably connected to such medical equipment, either directly or through a network, or can run system software. and can be another computer system (eg, computer or tablet) capable of receiving worksheet input from a user. Existing point-of-care medical systems often come with a set of default hard-coded worksheets. These are too long or cumbersome for many situations, and as a result doctors are less likely to use them. In some cases, worksheets can be customized by a clinic or practice group to reflect the desired workflow for a particular procedure. A worksheet server system facilitates the use and customization of worksheets, and allows worksheets to be downloaded to remote computers or medical devices, such as point-of-care systems. Additionally, a worksheet server or other system can receive completed worksheets and data entered into other DICOM data, and render worksheet data and still or video images (e.g., PACS systems (picture archiving)). and communication system) and can be interactively entered into the billing system. For example, one such worksheet server system is FUJIFILM SonoSite, Inc. of Bothell, Washington, USA. and another worksheet server system available from Maple Ridgeno Telexy Healthcare, Inc. of BC, Canada. may be the QPath E Tm server system available from

Conventional technology allows point-of-care systems to download and display worksheets and sign off (approve the next step in the data review workflow) for sending the data entered in the worksheets to a server. Therefore, it was required to maintain a live network server connection. In the event of a loss of connectivity, re-establishment of connectivity when point-of-care devices are used in the field or where Internet or other computer communications connectivity is unavailable or unreliable. A worksheet cannot be viewed or completed until it is established.

The inventor has developed a technology that allows users of point-of-care systems, such as ultrasound point-of-care systems, to interact with and complete worksheets without a live connection to a worksheet server. recognized the need. The disclosed technology addresses this need in a point-of-care system that includes system software for interfacing with browser components. An interface between the system software and the browser component allows the system software to retrieve worksheet data from the browser component and save it to local storage. This interface also allows the system software to retrieve stored worksheet data from local storage, or to auto-populate worksheet data in a worksheet within the browser component. When an Internet or other computer communication connection becomes available, the point-of-care imaging system transmits worksheet data to the server. As used herein, a "live" connection refers to the ability to communicate between two or more devices. For example, if a point-of-care imaging system can send DICOM packages to a server, eg, via the Internet, it has a live connection with that server. However, if the point-of-care imaging system tried to connect to the server and was unable to do so, it does not have a live connection to the server.

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

When a user opens a worksheet via the browser component, the point-of-care imaging system software determines whether there is data associated with this worksheet stored in memory local to the point-of-care imaging system. be able to. In that case, the system software of the point-of-care imaging system can acquire the local data and interface with the browser component to automatically populate the worksheet fields. The user can then interact with the worksheet with or without auto-entered data.

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

In some embodiments, the interface between the system software element and the browser component element includes employing an intermediate component that interacts with both software elements. Worksheets provided by the browser component can use predefined functions (such as JavaScript functions) that provide information about the worksheet. The system software running on the point-of-care imaging device should be configured with the identities of these predefined functions, such as their names, the arguments passed to the functions, and the types of results to be returned. can be done. System software uses intermediate components to provide references to one or more predefined functions for the intended action, such as retrieving worksheet data or autofilling a worksheet with specified fields. can be obtained. Intermediate components can use these references to execute predefined functions within the browser component and retrieve the results (if any). Results can be reformatted for use by system software. When retrieving information from a worksheet, the system software can package the function results into one or more private DICOM tags or other DICOM package fields.

In some embodiments, the intermediate component is a Component Object Model (COM). The COM can include a dispatch function to obtain a pointer reference in the browser component's DOM, given the function's name, parameters, and result data. COM uses a pointer to execute the corresponding function and get the result! An Invoke function can also be included.

In some embodiments, the interface between the system software and the browser component may include injecting code into the browser component's script interpreter. For example, to inject code, the code can be passed through the browser component's API. The browser can execute injected code, such as autofilling worksheet values or retrieving worksheet values as they are entered. A procedure that injects code can provide a handle to the result. For example, a handle can be a return value from an API function call, or a designated memory location accessible by system software where results are written.

Certain embodiments are directed to methods performed by medical imaging devices. The method can include retrieving data from a worksheet or form repository server. The data can include one or more fields of customized worksheets or forms. The one or more fields can be based on at least one of the user's identity, the location of the medical imaging device, or the medical department that uses the medical imaging device. The method also regenerates a customized worksheet or form on the medical imaging device based on the received data, and connects the regenerated customized worksheet or form to the medical imaging device. can be displayed on a designed graphical user interface. Additionally, the method can generate medical images via a medical imaging device and automatically transfer customized worksheets or forms and medical images to billable or educational workflows.

Certain non-limiting embodiments are directed to medical imaging devices. A medical imaging device may include at least one memory containing computer program code and at least one processor. The computer program code, when executed by the at least one processor, can be configured to retrieve data from a worksheet or form repository server to a client medical imaging device. Data can include one or more fields of a customized worksheet or form. The one or more fields can be based on at least one of the user's identity, the location of the medical imaging device, or the medical department that uses the medical imaging device. The computer program code, when executed by the at least one processor, causes the medical imaging device to recreate the customized worksheet or form based on the received data, and the regenerated customizations. The completed worksheet or form can also be configured to be displayed on a graphical user interface connected to the medical imaging device. Further, the computer program code, when executed by the at least one processor, causes the client station to generate medical images via a medical imaging device, and a workflow capable of billing customized worksheets or forms and medical images. Or it can be configured to automatically transfer to the teaching workflow.

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

The ability to utilize and complete worksheets in an offline setting improves point-of-care medical devices for providers that operate in the field or in settings where computer communication lines are cyclical or sub-optimal. For example, an ultrasound machine operator may need a local or remote clinic where there is no computer communication line with sufficient bandwidth to allow a connection between the ultrasound machine and a remote worksheet server for the entire duration of the exam. A patient may be examined. Alternatively, a medical imaging device may be used at the patient's bedside without a cable or wireless connection to a computer communication line. Sometimes, in operating rooms or other emergency care situations, a wired network connection may be impractical, and wireless transmission and connectivity in these environments is limited by requirements such as conflicting with hospital policy. Sometimes. In existing systems, if a physician does not have access to a live network connection, the physician or assistant takes notes during the exam and fills out the worksheet later when the connection becomes available. Such processing slows down the workflow, requires additional effort, and introduces potential errors when the data is recorded and transferred to electronic format.

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

In many ultrasound point-of-care systems, typically in emergency medicine, it is the doctor doing the scanning, not the full-time sonographer. A physician who is not a full-time sonographer is performing a scan as part of a larger imaging care offering to emergency patients (unscheduled patients). There is currently no national or global accreditation system for these physicians. Therefore, each hospital must develop its own policy to determine that its physicians have the necessary proficiency to operate the equipment. One advantage of the technology disclosed herein is that hospitals can use it in a variety of applications to record training time and QA/physician testing during training until proof of its reliability is achieved. , is to be able to use the hospital. The disclosed technology helps record such examinations by allowing the physician to complete a worksheet after each examination.

It is also known that approximately 90% of ultrasound scans are uncharged for emergency use. In order to charge for the services provided, the medical service provider must be able to show that the attending physician is certified so that the attending physician can charge for the examination. Physicians are busy and do not have time to record tests from each modality, so they do not earn income. The disclosed technology provides a way to automatically obtain and pass to the billing system the answer to the question, "What ultrasounds have you done on this patient that led to diagnosis and treatment?" This information can be secured through completed worksheets so that the hospital or other service provider can charge for the services provided.

Organizations can generate customized sets of worksheets tailored to different departments, such as emergency medicine or radiology, and to the most common types of procedures performed. This makes the use of such customized worksheets preferable to the default software-embedded worksheets that are impractical, infrequently used, and inappropriate, one-size-fits-all, and applicable to all approaches. It's easy.

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

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 can be used with other medical devices that employ worksheets (eg, electrocardiogram machines, PET scanners, X-ray machines, etc.).

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

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

When connected to worksheet server 20, the ultrasound imaging system receives worksheets and other information as well as custom server commands via computer communications connection 15. FIG. In various embodiments, in response to an administrator command (i.e., a "pull" action) at the point-of-care system, when a worksheet is loaded into the point-of-care system, or such as a "push" from a worksheet server. Worksheets can be retrieved at various times, such as at regular intervals. The worksheets can be sent from the worksheet server 20 to the ultrasound imaging device in a browser readable format such as HTML. In some embodiments, worksheets can include JavaScript. In some cases, worksheets can contain references to other content such as images, scripts, CSS files, and so on. These references can be network-based, but can also be downloaded locally to the point-of-care system. For example, if a live network connection is available, the worksheet and any reference items can be downloaded and saved to the local memory of the point-of-care system. Worksheets can be used by point-of-care systems regardless of whether a live network connection is available. This is because the worksheets and items referenced by worksheets are available locally.

A browser component executed by system software running on the point-of-care system 10 can display worksheets in which users enter data, attach images or video clips, and electronically fill worksheets. can be signed. As the user completes the worksheet, the entered data, images and video clips can be sent back to the worksheet server 20 for storage on the DICOM archive server once the computer communication connection is established.

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

To allow point-of-care system operators to complete worksheets when not connected to the worksheet server 20, the disclosed technology uses system software running on the point-of-care system 10. provides a mechanism by which HTML-related functions (eg, JavaScript functions) for a particular worksheet can be executed. Once retrieved, the system software encapsulates the worksheet data, e.g., as one or more private tags into a DICOM package, or into standard DICOM fields, and sends it to the server when a live network connection becomes available. DICOM packages can be placed in an outbound queue for transmission of In some embodiments, with or without a live network connection, the system software interfaces with a browser component to extract worksheet data. In another embodiment, the browser component sends the worksheet data directly if a live network connection is available, or interfaces with the system software's interface if a live network connection is not available.

FIG. 2 is a block diagram of a system for allowing users to complete previously downloaded worksheets from a remote worksheet server without a live connection to the remote server. In the illustrated embodiment, worksheet server 20 connects to point-of-care system 10 using communication connection 15 . Local memory 100 within point-of-care system 10 stores HTML and other files defining one or more worksheets received from worksheet server 20 .

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

As will be appreciated by those skilled in the art, the worksheet received from the worksheet server contains or references a number of functions (e.g., JavaScript) that provide information about the worksheet being rendered in the browser. be able to. For example, functions can generate drop-down menus, control radio buttons, display checkboxes, and perform other operations that control how worksheets are displayed. Some functions can provide metadata about the worksheet, such as if the form contains some information, is signed by the doctor or technician performing the test, and so on. Such functions are generally designed to reside within the browser component and do not communicate with external applications like other point-of-care system software. The disclosed technology provides methods for causing such external software to perform these functions and obtain their results.

In accordance with some embodiments of the disclosed technology, the system software 25 of the point-of-care system uses an intermediary component (eg, interface 35) to store predefined data contained in or referenced by worksheets. The browser component is connected to the interface to execute the function by either gaining access to the function or by injecting the function into the browser component's script interpreter. In some embodiments, interface 35 may be a Component Object Model (COM) interface provided by the operating system of the point-of-care system. In some embodiments, the interface includes the following functions that the browser can perform.

GetWorksheetData( ): Gets the user-entered data of a form and any signoff/approval credentials that encapsulate a data object represented as a string. This packaged data is transferred to the worksheet server via DICOM encapsulation and private tags or by mapping the data to DICOM fields.
SetWorkSheetData(worksheetData): Sets the entire populated worksheet according to worksheetData, including any signoff/approval data. A worksheetData can be an encapsulation of a data object (such as JSON) represented by a string.
IsWorksheetSigned(): Returns a Boolean value indicating whether the worksheet is signed.
IsWorksheetActive(): Returns a Boolean value indicating whether the worksheet has user input data saved or not.

As will be appreciated, other functions that provide the above information can also be used. It is believed that those skilled in the art know the details of how to write such functions in HTML or JavaScript. In embodiments that use an intermediate component, the system software can specify the function name, the type of variable passed to the function, the expected return value from the function and what its type is, code line number, memory location, identifier number, parent The identity of the function, such as an object or other identity, is known. Intermediate components can use this information to gain access to perform these functions and obtain the function results. In other embodiments, system software may gain access by injecting functions directly into the browser component's script interpreter and receiving the results generated accordingly.

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

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

In another embodiment, information about the worksheet being rendered by the browser component is not by calling an embedded script, but rather through support specific to some browser components, such as those used on WPF and UWP platforms. It is obtained by injecting an additional script into the HTML DOM using the function

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

In the example shown in FIG. 3, the system software uses Dispatch and ! to access information in the DOM of the rendered worksheet. It uses a Component Object Model (COM) intermediate interface that provides an Invoke command. In COM, Dispatch can be used to get a pointer to a predefined JavaScript function that provides information to a worksheet or autofill information. System software can also set the arguments expected by the functions and define the expected results in a way understood by the COM interface. Then the system software is ! Use the Invoke command to tell the COM intermediate component to request the execution of a function. All results returned from the functions are placed in memory locations in local memory 100 that are recognized by the system software.

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

FIG. 4 shows in more detail the actions performed by the system software to call the functions of the DOM corresponding to the worksheet, according to some embodiments of the disclosed technology. In some embodiments, the process of FIG. 4 is implemented as a subprocess of block 610 or block 616 of the process shown in FIG.

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

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

At 220, the system software calls the Dispatch function, passing the identification of one of the worksheet's functions to obtain a pointer to that function. As noted above, the identifiers may include the names of those functions that the system software knows a priori. In some embodiments, the system software calls one of the names "GetWorksheetData()", "SetWorkSheetData(worksheetData)", "IsWorksheetSigned()", and "IsWorksheetActive()" for the current DOM in the browser component. Request the Dispatch function to return a pointer to the above JavaScript function. The functions can have any name as long as the names are known to the system software, but those skilled in the art can use these names to predict which functions will be performed, and they This naming convention is used here as an example so that you can understand how you can create a . It will be appreciated that in some embodiments obtaining a pointer to the identified function may be based on a pointer to the portion of the DOM that contains the script function. For example, a pointer to the portion of the DOM that contains the script function can provide a scope or other context for the function that obtains the pointer to the specified function.

The types of variables used and returned by these functions (such as JavaScript) may not be the same as those used in the COM interface. Thus, in the disclosed embodiments, parameters passed to and returned from functions can be converted to types understood by the COM interface. At 230, the system software constructs the function call as a collection of COM compatible values (VARIANT type). In some embodiments, function calls are created as structures. for example,
JavaScript functions:
FunctionName (Argl , Arg2, Arg3 etc)
Can be encoded as a struct:
COM:
String of JavaScript function name
BSTR (Function Name)
Parameter list
BSTR (string arguments)
or VARIANT type
VARIANT_Bool, VARIANT numeric unit

At 240, the system software uses the ! Instruct COM to execute a function using the Invoke COM interface. For example, to execute the GetWorksheetData() function, the COM interface is instructed to execute the following pseudocode:
{
Generate a COM VARIANT structure/union for the return value varResult of the script function.
Create a COM BSTR strFunc representing the name of the script function to execute and set it to "GetWorksheetData".
Create and set a COM BSTR that represents an empty string for the input parameter paraml of the script function.
Create a COM dispatch parameter structure/union for the arguments to the script function dispparams.
Add a single parameter paraml to dispparams.
if (no document pointer, pDisp) {
// A new document has been loaded in the browser component.
Create a COM dispatch pointer to the currently loaded HTML document and store it in pDisp.
}
Use pDisp to get the COM dispatch pointer to the script section of the HTML document pScript.
Uses pScript to find the script function specified by strFunc and generate its dispatch identifier dispid.
Use pScript and COM Invoke to execute the script function dispid with arguments dispparams and return varResult.
Wait for the script function to complete and the COM interface to copy the result to varResult.
The expected return result of this script function is a string result, so convert the BSTR portion of varResult to a string (such as char*) that can be used by system software.
}

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

FIG. 5 shows in more detail the actions performed by the system software to inject functions into the browser component that implements the worksheet, according to some embodiments of the disclosed technology. In some embodiments, the process of FIG. 5 is implemented as a sub-process of blocks 610 or 616 of the process shown in FIG.

At block 502, the system software of the point-of-care system may inject code (eg, JavaScript) into the browser component for the browser component's scripting interpreter. In various embodiments, the injection of code into the browser can be performed using calls to APIs provided by the browser component, or it can receive scripts installed on the browser component and apply them to worksheets. , by accessing the active DOM in the browser component and adding script code to it, or by using a plugin configured to inject into the script section of the URL bar. Code can be added and executed through the browser component's access point. In either case, the injection of code into the browser component can have one or more handles for retrieving the results (if any) of the injected code. For example, a result handle can be a return value from an API or plug-in function call, a memory location shared between the browser component and the system software that the injected code is configured to write to, a point-of-care system It can be a call made by code injected into a local web service, or system software intercepts an outgoing request from a browser component and returns an identifier ( For example, it can be configured to locally process requests with specified destinations, ports, etc.).

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

In some embodiments, blocks 506 and 508 may only be executed when the injected code is expected to produce a result, although these blocks are shown with dashed lines. At block 506, the system software can use the handle for the type of code injection used to obtain the results of the executed code.

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

At block 508, 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 can be broken into tokens and values can be made available with specific keys, for example by mapping them to corresponding DICOM fields. In other embodiments, the entire string or value from the tokenized string can be encapsulated in a DICOM private tag.

FIG. 6 illustrates a method for manipulating a worksheet using local storage instead of a live server connection and transmitting worksheet data depending on server availability in accordance with some embodiments of the disclosed technology. 4 is a flow chart of steps performed by system software; At block 602, system software may obtain worksheets from a worksheet server and store them in local memory. In various embodiments, obtaining worksheet versions can be initiated by a device request (ie, a “pull” operation) or by a worksheet server (ie, a “push” operation). In various embodiments, obtaining the version of the worksheet can be done via an administrator command (from a local or remote system), a periodic automatic request for an update when a new version of the worksheet is available, or The trigger can be a response to a user requesting access to a worksheet while there is an active connection to the worksheet server.

By using worksheets from the Worksheet Server, worksheets can be configured to maintain a specific look and feel, contain specific fields corresponding to the data an organization wishes to collect in its Point of Care system, or use specific data It can be customized for a particular organization, such as specifying how fields in a worksheet are organized to enable collection workflows. Worksheets can be customized for a specific point-of-care system or group of point-of-care systems. In some embodiments, a worksheet can be a file that uses HTML to define fields. In some embodiments, the worksheet file may include scripts (eg, JavaScript), images or other media, other content such as CSS. Alternatively or additionally, the worksheet file may contain references to other content stored in the point-of-care system's local storage. This allows other content to be shared between worksheets and allows worksheets to be updated without re-downloading portions of the worksheet that have not changed. In some embodiments, worksheets and/or additional content may be stored on the solid state drive of the point-of-care system. In some embodiments, worksheets and/or additional content may be stored in a secure manner, such as encrypted.

Upon completion of block 602, the worksheets and other content corresponding to them are stored locally. Additionally, as described below, the point-of-care system can extract and store locally the data entered in the worksheet. As a result, once block 602 is completed, the point-of-care system can implement the remaining blocks 604-624 without contacting the live server.

At block 604, the system software of the point-of-care system can execute a browser component. This can be a custom browser specific to the point-of-care system or a version of a commercial browser such as Chrome, Safari, Internet Explorer. In some embodiments, the browser component may be integrated with the system software such that the browser component is not easily found separate from other aspects of the system software, or may be integrated into the system software. You may make it comprise so that it may incorporate. In various embodiments, executing the browser component may execute as part of system software initialization, or in response to a user selection to open a worksheet.

At block 606, the browser component can load from local memory selected worksheets selected by the user, for example, during an examination of the patient. This can be accomplished at block 602 by providing a worksheet stored in local memory to the browser component. If the worksheet has references to other content stored in local memory, the browser component resolves the references, retrieves the other content, and fully renders the worksheet, including the referenced JavaScript and Additional code such as CSS can be executed.

At block 608, the system may determine whether the data stored in local memory for the worksheet loaded at block 606 has unsigned data or other partial data. In some embodiments, this is done at block 606 by checking which worksheet has been loaded and determining if the corresponding worksheet data is stored. For example, metadata identifying a worksheet can be stored in association with the data for the worksheet in local memory. Worksheet data can be recognized if it has not yet been signed off for transmission to a DICOM server (which can be indicated by further metadata). In some embodiments, the point-of-care system may include session data that identifies the current patient, in which case the determination at block 608 further determines that only if there is an identifier for the current patient , to identify unsigned worksheet data. Once the worksheet data has been identified at block 608 , processing proceeds to block 610 . Otherwise, processing continues to block 612 .

At block 610, data for the worksheet identified at block 608 can be retrieved from local storage and provided to the browser component. Code contained in the worksheet or code injected by the system software can be used to populate worksheet fields using data from the accompanying worksheet. The process of using an intermediate component to insert worksheet data into a worksheet field is described above with FIG. The process is described above with FIG.

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

At block 614, trigger conditions for saving worksheet data may be specified. In some embodiments, the triggering condition may be an event in which the browser component navigates away from the current page, resulting in the browser component clearing the DOM of the current worksheet. For example, such an event could be a point-of-care system where the user activates a control to end a patient exam, navigates to a different worksheet or other page, or causes the system software to close the browser component. (eg, imaging, transducer, system menu, help menu, etc.).

At block 616, the data entered in the current worksheet may be extracted and saved to local memory. For example, to extract data from a worksheet, use an intermediate component to locate a reference to the GetWorksheetData() function and execute the function, or insert the code for the GetWorksheetData() function into the browser component to retrieve the result to get The process of extracting data from a worksheet using intermediate components is described above with FIG. 4, and the process of extracting data from a worksheet using code injection is described above with FIG. , and the extracted worksheet data can be stored in a secure manner, such as encrypted.

At block 618, the system software may determine whether the worksheet data has been signed. In various embodiments, this is done by examining variables embedded in or otherwise associated with the extracted worksheet data (e.g., metadata), or to execute the IsWorksheetSigned() function. , intermediate components or code insertion. If the worksheet is not signed, processing returns to block 606 when the worksheet to be loaded into the browser component is selected again. 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, eg, as a string, to a private tag within the DICOM package. When the server receives this DICOM package, it can extract individual values from the worksheet data in private tags. In other implementations, versions of the worksheet data can be the values of individual fields of the worksheet that are extracted from the worksheet data and added to the corresponding standard fields in the DICOM package.

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

At block 624, the system software adds the completed DICOM package to a queue configured to transmit the DICOM packages in the queue to one or more servers when a live network connection is available. can be done.

FIG. 7 is a block diagram of exemplary computer components 700 for executing system software on a point-of-care medical imaging system, according to some embodiments of the disclosed technology. Elements of computer component 700 are implemented in digital electronic circuitry, or computer software, firmware, or hardware, or combinations of one or more thereof, including the structures disclosed herein and their structural equivalents. can do. Computer component 700 includes one or more input devices 720 for providing input to processor 710 (eg, CPU(s), GPU(s), HPU(s), etc.) and informing it of actions. be able to. Actions may be mediated by a hardware controller that interprets signals received from input devices and communicates information to processor 710 using a communications protocol. Input device 720 may be, 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 ( For example, a bar code reader or QR code reader), a microphone, or other user input device.

Processor 710 may be a single processing unit or multiple processing units within a device, and may be 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. Processor 710 may be coupled to other hardware devices using a bus such as a PCI bus or a SCSI bus. Processor 710 may communicate with hardware controllers for devices such as display 730 . Display 730 can be used to display text and graphics. In some embodiments, the display 730 provides graphical and textual visual feedback to the user. In some embodiments, the display 730 includes an input device as part of the display, such as where the input device is a touch screen or includes an eye gaze monitoring system. In some embodiments, the display is separate from the input device. Examples of display devices are LCD display screens, LED display screens, projected holographic or augmented reality displays (such as head-up display devices or head-mounted devices), and the like. Other input/output devices 740 may also include processors such as network cards, video cards, audio cards, USBs, cameras, printers, speakers, CD-ROM drives, DVD drives, disk drives, or Blu-Ray (registered trademark) devices. can be connected to

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

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

As described below, in certain embodiments, users may create customized worksheets based on the user's role, workflow preferences, and/or the location or department in which the medical imaging device is being used. Direct download to the imaging device may be enabled. In some embodiments, the system can facilitate workflow automation for customized worksheets or forms. In one particular example, an automated workflow can help expedite the creation of worksheets or forms for tests not ordered from an electronic medical record system. The use of accelerated workflow enables automatic reconciliation of patient orders and demographics, thereby enabling medical facilities to handle patients for whom orders were not initially generated. This can be particularly beneficial for emergency rooms or trauma patients where speed of medical orders is of utmost importance.

In certain embodiments, a system such as the system shown in Figures 1 or 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. Middleware applications can provide users of the system with the ability to create one or more customized worksheets or forms. In one example, the software application may be a browser in which worksheets or forms are displayed. The customized worksheet or form may be, for example, notes taken by a doctor to accompany the medical images. These notes can then be forwarded to one or more departments, such as the billing department within the medical facility and/or the medical facility's pharmacy. A user may be a physician, non-physician, medical professional, or any other person using a point-of-care ultrasound device. In other embodiments, instead of or in addition to using a point-of-care ultrasound device, the user may use a magnetic resonance imaging (MRI) device, a computed tomography (CT) scanner, a nuclear medicine (NM) imaging device, an electrocardiogram One or more other medical imaging devices such as devices, positron emission tomography (PET) scanners, and/or X-ray devices may be utilized.

The system can include one or more customizable processes or methods for creating or creating worksheets or forms. The one or more processes or methods may be, for example, a customized procedural or educational clinical imaging workflow. A process or method can be customized based on the following overarching factors. To determine the type of test, the location where the test is performed, the department performing the test, the identity of the physician performing the test, the location within the healthcare facility where the test is performed, and/or the fields included in the worksheet or form. Any other factor that can be used. In some embodiments, a workflow can be a customized examination workflow type or a default examination workflow type that can be used for multiple modality types. The modality types can be different imaging devices such as, for example, ultrasound, MRI, CT scanners, NM imagers, PET scanners, electrocardiogram devices, and X-ray devices. Customized fields in worksheets or forms can be saved as metadata in databases contained on physical or cloud-based servers. In certain embodiments discussed herein, the term "data" may include metadata.

Customization of worksheets or forms can be done before the workflow is started. In other words, users can create customized templates of worksheets or forms. A user may decide which field or fields to include in a worksheet or form, depending on the above factors. When using a medical imaging device, a user manually enters identification information into a graphical user interface (GUI), display, or computer attached to the medical imaging device using an application programming interface (API). be able to. In certain embodiments, the workflow accelerator application can be vendor independent, meaning that the application can run on medical imaging devices manufactured by multiple different vendors. In other embodiments, the user's identification information may be entered automatically via a sensor or detection device capable of sensing or detecting what identifies the user. For example, automatic entry of user identification information can include bar code scanning of standard matrix (2d) codes or QR (Quick Response) codes using a particular format. The format can be, for example, <FFSS>,,,,,,,BADGEID</FFSS>. When the identification information is scanned, the scanned identification fields are automatically entered into the device. In some embodiments, worksheet code may include an interface that allows a user to obtain one or more action fields. The user's identification information may be the user's first and last names, the user's identification information issued by the medical facility, or any other identification information used to identify the user. Once the user's identification information is entered, the contents of the customized template worksheet or form can be downloaded from the worksheet server, or any other database, to the medical imaging device. Content can then be entered into a worksheet or form to generate or display a customized worksheet or form for the user.

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

A workflow accelerator application, in some embodiments, may allow a user, such as a physician, to document findings from a medical imaging device on a customized worksheet or form. Certain embodiments allow a user to insert an electronic signature into a customized worksheet or form. The electronic signature may be, for example, a US Food and Drug Administration compliant signature under Title 21, Section 11 of the Code of Federal Regulations. Thus, a user can use the workflow accelerator application to create customized worksheets or forms that comply with any electronic record and electronic signature requirements of the medical facility.

The workflow accelerator application can classify completed customized worksheets or forms into one or more categories. The categories may be based on imaging objectives performed by the user. For example, one category may be educational where the imaging was done for educational purposes. In another category, the imaging may be billable, where the imaging is performed as part of the patient's medical procedure and may be billed using the patient's insurance. One or more categories can be used to determine through which workflow the customized worksheet or form is sent. For example, worksheets or forms classified as educational can be automatically or manually transferred to an educational workflow, while worksheets or forms classified as chargeable can be automatically or manually transferred to an educational workflow. Can be transferred to billable workflows.

As described above, based on the categories, the application can send completed customized worksheets or forms to one or more locations. If the imaging performed is classified as billable, for example, the application can send the customized worksheet or form, and the content therein, to the billing system. In some other embodiments, the customized worksheet or form may be sent to any database or server, such as a worksheet or form repository or worksheet server. Submission can be automatic without user or end-user interaction simply based on at least categories of customized worksheets or forms. Alternatively or additionally, the submission may be manual requiring input from the user. Manual submission allows the user to decide where to send the customized worksheet or form. The images that can be included as part of the study include Health Level Seven messages (HL7), DICOM (Digital Imaging Communication over Messaging) for messages, or any other message standard used for medical imaging. Can be sent using healthcare standards.

FIG. 8 is an example diagram illustrating the general architecture of a system in accordance with certain embodiments. A user can use the browser 810 to create a worksheet or form template. In another embodiment, templates can be created by an administrator separate from the user. The template can be created directly on the medical imaging device or on a separate computer. The template may include the type of test, the location where the test is performed, the department where the test is performed, the identity of the physician performing the test, the location within the healthcare facility where the test is performed, and/or the fields included in the worksheet or form. or based on any other factor that can determine the question. These elements can be used to define the user's workflow preference preferences. In other words, factors can determine whether one or more fields are included in a customized worksheet or form.

For example, one field in a customized worksheet or form can be the applicable billing code. Billing codes can be associated with any of the factors described above. In some embodiments, the billing code can be unique to the medical facility where the imaging device is located. The presence of billing codes can help facilitate automatic or manual submission of customized worksheets or forms. A user or separate administrator of the system will be assisted in programming the billing code into a customized worksheet or form for a given medical facility.

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

FIG. 8 illustrates that the workflow accelerator application creates customized worksheets or forms based on factors and either automatically or manually sends or routes the completed worksheets to a desired location or workflow ( routing). A customized worksheet or form template can be created using the browser 810 . In certain embodiments, templates may be automatically generated considering one or more factors without user or administrator input. For example, templates can be automatically generated based on a given medical facility or recognized vendor. Customized worksheets or forms can be stored as metadata in the application management worksheets or forms repository 820 . When using an imaging device 830 called a modality, an API request can be sent to repository 820 requesting stored metadata for a customized worksheet or form. API requests can be JSON formatted HTTP or HTTPS web requests. The imaging device shown in FIG. 8 is an ultrasound device, such as a point-of-care ultrasound device, but any other modality such as MRI, CT scan, NM imaging, or X-ray may be used.

After receiving or retrieving the metadata, the imaging device 830 can add to or recreate the customized worksheet or form. The customized worksheet or form 840 can be displayed on the imaging device or a computer, GUI, or display capable of communicating or connecting to the imaging device. In certain embodiments, the application used to display the customized worksheet or form 840 includes a field that allows a physician to enter an electronic signature on the customized worksheet or form 840. can be done. An electronic signature can be at least a touchscreen that allows the doctor to enter a signature, a checkbox that can be clicked to enter a previously saved digital signature, or an option that allows the doctor to select an electronic signature. It can be entered using a variety of methods, including drop-down menus that allow. In another example, any available authentication or re-authentication method can be used to enter an electronic signature, where the user has one or more signatures used to verify the user's identity. You may be prompted for authentication information. Imaging device 830 can also be used to image a patient and send or communicate the resulting image 850 to a storage server or cloud via DICOM. A customized worksheet or form 840 can be associated with the image 850, with or without the doctor's electronic signature. The association can be done via DICOM private tags, which can be in JSON format, for example.

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

In certain other embodiments, images and/or associated worksheet or form data can be routed to EMR 880 using application services router 860 through billable workflows. For example, a worksheet or form can be categorized as billable. The images and/or associated worksheet or form data can be automatically or manually sent or reported to the electronic medical record system as text or in encoded Portable Document Format (PDF). Alternatively, images and/or associated worksheet or form data can be routed using any other format via medical transfer standards. The routed image and/or associated worksheet or form output may be a signed worksheet or form report 870 . Reports can be transferred and stored in EMR 880 .

FIG. 9a is an example diagram showing part of a system in accordance with certain embodiments. Portions of the system may include a worksheet server 910, which may also be an application management worksheet or form repository 820 and medical imaging device 920 shown in FIG. Specifically, FIG. 9a shows the API request architecture used to validate the connection from the medical imaging device 920. FIG. As shown in FIG. 9a, the medical device 920 can send an HTTP or HTTPS GET request message to the worksheet server 910 using the API. The GET message can include a request to verify the connection, and in response, worksheet server 920 can send a response message in the form of an HTTP 200 response indicating that the request was successful. can. For example, the request looks like http://<fully qualified domain name>/external/verify. The content type of the response message is hypertext markup language (html) or text, allowing the medical imaging device 200 to connect to the worksheet server 910 .

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

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

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

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

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

In certain embodiments, customized worksheets or form data may be sent back to the system from the medical device. Data can be attached as JSON. Additionally or alternatively, data may be attached to or associated with one or more images in a series contained in a private DICOM tag, the data type being text without restriction. I wish I had. Upon receiving one or more images and associated data, the system can automate various workflow outcomes. For example, one or more images and associated data can be sent to a billable or educational workflow.

FIG. 10 is an example flow chart diagram in accordance with certain embodiments. In particular, FIG. 10 illustrates processes for automating various workflow outcomes. Application services router 1010 may be similar to application services router 860 shown in FIG. 8, but in certain embodiments may make determination 1020 whether to automate billable reports. If a study containing one or more images produced by a medical imaging device is performed on a particular worksheet by either an unauthenticated student or an authenticated in-program learner , may not be eligible. In such embodiments, the images and/or associated data may be sent to the educational workflow 1040. The education workflow 1040 may include forwarding to an application for physician or non-physician review, as shown in FIG.

In other embodiments, a test may be eligible for auto-billable transfers. In such embodiments, the report can be forwarded to clinical auto-billable workflow 1030 . Auto-billable workflow 1030 can use worksheets or form data, for example, to bill one or more hospitals or medical facilities, and one or more internal or external billing systems. to, including transferring additional or completed worksheets and/or forms. For example, a study may be eligible for automatic billable transfer if an approved provider signature is present pursuant to FDA requirements for electronic records and electronic signatures pursuant to Code of Federal Regulations, Title 21, Section 11. An exam also has a corresponding order, encounter, or visit identified by the system and/or if the exam has a corresponding patient identifier in the system. Eligible. In some embodiments, a test may be eligible for auto-chargeable transfer if the test is performed either by an authenticated provider or by a student or learner within an authenticated program. A study may also be eligible for automatic billable transfer when the study is identified for downstream billing or submission to an electronic medical record system.

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

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

At step 1120, the customized worksheet or form can be regenerated based on the data received by the medical imaging device. The re-created customized worksheet or form can then be displayed on a graphical user interface connected to the medical imaging device, as shown in step 1130 . Middleware applications can be used to display re-created customized worksheets and forms. At step 1140, a medical image may be generated via a medical imaging device. Customized worksheets or forms can be associated with medical images via DICOM private tags or standard structured reports. In certain embodiments, the user's electronic signature can be inserted into the customized worksheet or form, as shown in step 1150 .

At step 1160, customized worksheets or forms and medical images can be automatically transferred to billable or educational workflows. In some embodiments, customized worksheets or forms and medical images when the user is an unauthenticated student, a learner in an accredited program, or a provider not included in an accredited program can be automatically transferred to teaching workflows. In such embodiments, customized worksheets or forms can be routed to a worksheet or form repository server. The user can then use the browser to review the customized worksheet or form of the billable workflow and provide secure feedback or approval. Secure feedback can include using any known cryptography, such as transport layer security protocols. For example, review may include changes, edits, additions, or deletions to customized worksheets or forms. Thus, an approved program can include a list of learners, students, or providers, including physicians or non-physicians. In some embodiments, a learner, student, or provider within a certified program can review and/or modify a customized worksheet or form; A learner, student, or provider who is not included in the WS can review and/or modify the customized worksheet or form.

In certain other embodiments, the customized worksheet or form and medical images are i) provided that an approved provider signature is on the customized worksheet or form; , in response to a clinic visit or outpatient visit; iii) the customized worksheet or form contains a patient identifier; iv) the user is an authorized provider of students within an authorized program; or v) If medical images are specified to be submitted to a billable workflow, they can be automatically transferred to the billable workflow. Customized worksheets or forms and medical images can be transferred to the EMR system as part of a billable or educational workflow.

In certain embodiments, the method or process illustrated in FIG. 11 may be vendor independent across other exemplary embodiments described herein. In other words, the method or process can be performed not only on medical imaging devices manufactured by a vendor, but also on different medical imaging devices manufactured by different vendors. In some other embodiments, the methods or processes described above may be performed by a server, such as worksheet or form repository server 820 shown in FIG.

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

A computer program (also called a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted, declarative, or procedural languages, and can be written as a stand-alone program. , or arranged in any form as modules, components, subroutines, objects, or other units suitable for use in a computing environment. A computer program can correspond to a file in a file system, but that is not required. A program may be part of a file holding other programs or data (e.g., one or more scripts stored in a markup language document), one file dedicated to the program in question, or multiple collaborations. It can be stored in a file (eg, a file that stores one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

Some implementations of the disclosed technology are described above with reference to the drawings. References herein to "an embodiment" or "examples" (e.g., "some embodiments," "various embodiments," "one embodiment," "an embodiment," etc.) It is meant that a particular function, configuration or feature described in connection with an embodiment is included in at least one embodiment of the invention. The appearances of these phrases in various places in this specification are not necessarily all referring to the same embodiment, nor are they necessarily referring to separate or alternative embodiments that are mutually exclusive of each other. Nor is it. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described that are requirements for some embodiments but not others.

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

While 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. . Although specific embodiments and embodiments have been described herein for purposes of illustration, various modifications can be made without departing from the scope of the embodiments and embodiments. The specific features and acts described above are disclosed as example forms of implementing the following claims. Accordingly, the embodiments and examples are not limited except as in the appended claims.

Any patents, patent applications, and other references mentioned above are incorporated herein by reference. The forms can be modified, if necessary, to employ the systems, functions, and concepts of the various references above to provide further embodiments. If the content or subject matter of any document incorporated by reference conflicts with the content or subject matter of this application, this application will control.

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

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

8, 8b , the workflow accelerator application creates a customized worksheet or form based on factors and automatically or manually sends the completed worksheet to a desired location or workflow, or It shows a system that can be routed. A customized worksheet or form template can be created using the browser 810 . In certain embodiments, templates may be automatically generated considering one or more factors without user or administrator input. For example, templates can be automatically generated based on a given medical facility or recognized vendor. Customized worksheets or forms can be stored as metadata in the application management worksheets or forms repository 820 . When using an imaging device 830 called a modality, an API request can be sent to repository 820 requesting stored metadata for a customized worksheet or form. API requests can be JSON formatted HTTP or HTTPS web requests. The imaging device shown in Figures 8, 8b is an ultrasound device, such as a point-of-care ultrasound device, but may use any other modality such as MRI, CT scan, NM imaging, or X-ray. good.

FIG. 9a is an example diagram showing part of a system in accordance with certain embodiments. Part of the system can include a worksheet server 910, which can also be an application management worksheet or form repository 820 and a medical imaging device 920 shown in FIGS. 8, 8b . Specifically, FIG. 9a shows the API request architecture used to validate the connection from the medical imaging device 920. FIG. As shown in FIG. 9a, the medical device 920 can send an HTTP or HTTPS GET request message to the worksheet server 910 using the API. The GET message can include a request to verify the connection, and in response, worksheet server 920 can send a response message in the form of an HTTP 200 response indicating that the request was successful. can. For example, the request looks like http://<fully qualified domain name>/external/verify. The content type of the response message is hypertext markup language (html) or text, allowing the medical imaging device 200 to connect to the worksheet server 910 .

FIG. 10 is an example flow chart diagram in accordance with certain embodiments. In particular, FIG. 10 illustrates processes for automating various workflow results. The application services router 1010 may be similar to the application services router 860 shown in FIGS. 8, 8b , but in certain embodiments may make a determination 1020 whether to automate billable reports. If a study containing one or more images produced by a medical imaging device is performed on a particular worksheet by either an unauthenticated student or an authenticated in-program learner , may not be eligible. In such embodiments, the images and/or associated data may be sent to the educational workflow 1040. The education workflow 1040 may include forwarding to an application for physician or non-physician review, as shown in Figures 8 and 8b .

In certain embodiments, the method or process illustrated in FIG. 11 may be vendor independent across other exemplary embodiments described herein. In other words, the method or process can be performed not only on medical imaging devices manufactured by a vendor, but also on different medical imaging devices manufactured by different vendors. In some other embodiments, the methods or processes described above may be performed by a server, such as the worksheet or form repository server 820 shown in Figures 8, 8b .

Claims (20)

A method for a medical imaging device comprising:
One of the customized worksheets or forms from a worksheet or form repository server based on at least one of a user's identity, the location of the medical imaging device, or the medical department using the medical imaging device. retrieving data comprising one or more fields;
recreating the customized worksheet or form on the medical imaging device based on the retrieved data;
displaying the regenerated customized worksheet or form on a graphical user interface connected to the medical imaging device;
generating a medical image via the medical imaging device;
automatically transferring the customized worksheet or form and the medical images to a billable or educational workflow;
A method with As part of the billable workflow or the educational workflow, one or more fields of the customized worksheet or form are defined by the user or administrator before data is retrieved from the worksheet or form repository server. 2. The method of claim 1, predefined by: 2. The method of claim 1, further comprising routing the customized worksheet or form and the medical images to an electronic medical record system as part of the billable workflow or the educational workflow. 2. The method of claim 1, further comprising inserting the user's electronic signature into the customized worksheet or form. The customized worksheets or forms and the medical images may be used in the education if the user is an unauthenticated student, a learner of an authenticated program, or a provider not included in the authenticated program. 2. The method of claim 1, automatically transferred to a workflow. further comprising routing the customized worksheet or form to the worksheet or form repository server;
6. The user of claim 5, using a browser, can at least one of review, provide secure feedback, or approve the customized worksheet or form of the billable workflow. the method of. The customized worksheet or form and the medical image are: i) if an approved provider signature is on the customized worksheet or form; iii) the customized worksheet or form includes a patient identifier; iv) the user is an authorized provider of a student in an authorized program; or v) the medical image 2. The method of claim 1, wherein a document is automatically forwarded to the billable workflow if specified to be submitted to the billable workflow. 2. The method of claim 1, wherein the one or more fields comprise a billing code for the medical image. further comprising sending a request from the medical imaging device to the worksheet or form repository server;
2. The method of claim 1, wherein the request is used to verify connectivity of the medical imaging device and the worksheet or form repository server. 2. The method of claim 1, wherein the one or more fields of the customized worksheet or form are further based on at least one of an entity name or a worksheet identification number of the medical imaging device application. . 2. The method of claim 1, further comprising associating the customized worksheet or form with the medical image via digital image communication via message (DICOM) private tags or standard structured reporting. . 2. The method of claim 1, further comprising using a middleware application to display the recreated customized worksheet or form. 13. The method of claim 12, further comprising the user using the middleware application to modify, delete, or add the recreated customized worksheet or form. 2. The method of claim 1, performed on the medical imaging device manufactured by a vendor and a different medical imaging device manufactured by a different vendor. 2. The medical imaging device of claim 1, wherein the medical imaging device is an ultrasound device, a magnetic resonance imaging device, a computed tomography scanner, a nuclear medicine imaging device, an electrocardiogram device, a positron emission tomography (PET) scanner, or an X-ray device. Method. at least one memory containing computer program code;
1. A medical imaging device comprising at least one processor,
said computer program code being executed by said at least one processor,
the medical imaging device of the client,
One of the customized worksheets or forms from a worksheet or form repository server based on at least one of a user's identity, the location of the medical imaging device, or the medical department using the medical imaging device. retrieves data containing one or more fields,
regenerating the customized worksheet or form on the medical imaging device based on the retrieved data;
displaying the regenerated customized worksheet or form on a graphical user interface connected to the medical imaging device;
generating a medical image via the medical imaging device;
A medical imaging device that automatically transfers the customized worksheet or form and the medical images to a billable or educational workflow. The computer program code, when executed by the at least one processor, causes the medical imaging device of the client to:
17. The medical imaging device of claim 16, wherein the customized worksheet or form and the medical images are routed to an electronic medical record system as part of the billable workflow or the educational workflow. The computer program code, when executed by the at least one processor,
the client medical imaging device comprising:
17. The medical imaging device of Claim 16, wherein the user's electronic signature is inserted into the customized worksheet or form. The customized worksheets or forms and the medical images may be used in the education if the user is an unauthenticated student, a learner of an authenticated program, or a provider not included in the authenticated program. 17. The medical imaging device of claim 16, automatically transferred to workflow. The customized worksheet or form and the medical image are: i) if an approved provider signature is on the customized worksheet or form; iii) if the customized worksheet or form includes a patient identifier; iv) if the user is an authorized provider of a student within an authorized program; or v) if the medical 17. The medical imaging device of claim 16, wherein images are automatically transferred to the billable workflow if specified to be submitted to the billable workflow.

Images