Cloud-based radiology comment insertion and workspace sharing.

Abstract

To provide a method of incorporating a comment into a DICOM image file.SOLUTION: This disclosure relates to a medical image viewer for incorporating multi-user collaboration features, such as in-image commenting and workspace sharing. An example method includes receiving a comment location including image coordinates and comment information associated with the comment from a user device. The comment information includes a text body, identify identity information related to a user, and a comment creation date. The example method further includes determining world coordinates based on the image coordinates, and storing the world coordinates and the comment information as a subset of header attributes of a DICOM image file.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present disclosure generally relates to medical imaging applications, and more particularly to a medical image viewer for incorporating multi - user collaboration features such as in - image comment insertion and workspace sharing.

Background Art

[0002] Cross - reference to Related Applications This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 770,051, filed on November 20, 2018, the entire disclosure of which is incorporated herein by reference.

[0003] Typically, radiological medical images are composed of two - dimensional images, three - dimensional images, or reconstructed fused images generated through imaging devices utilizing modern nuclear medicine techniques such as PET (Positron Emission Tomography), CT (Computed Tomography), MRI (Magnetic Resonance Imaging), fMRI (Functional MRI), X - rays, mammography, tomosynthesis, ultrasound, or other modalities. Radiological medical images are generally stored in a patient's medical record (e.g., an electronic medical record or EMR), EHR (electronic health record), or PACS (Picture Archiving and Communication System), and these images can be viewed by patients or healthcare professionals in the process of providing diagnosis, treatment, or other healthcare. However, communication related to radiological medical images can be unsafe, inefficient, and / or restricted in emergency situations. Users may share login and passwords, use handwritten notes, create CDs, or call other users to convey important, sometimes time - constrained information about specific features in radiological medical images.

[0004] Modern EMR and EHR software systems, as well as PACS, provide several communication functions between providers and patients. However, radiological images shared through these channels may lack diagnostic information generated during the radiologist's examination. Even when diagnostic metadata is provided, physicians are unable to transmit rich data, such as location and measurements, and are unable to continue conversations or collaborations with other physicians or their own patients. One example is Horos, which provides cloud sharing with other users but lacks features for conversation or collaboration.

[0005] Generally, radiological imaging adheres to the DICOM (Digital Imaging and Communications in Medicine) standard, which sets the file / data format, data exchange protocol, and network protocol architecture used for digital radiological imaging. The DICOM standard has played a significant role in the emergence of PACS (Picture Archiving and Communication System), which integrates with HIS (Hospital Information System) and RIS (Radiological Information System).

[0006] As the adoption of digital imaging at the enterprise level increases, the demand for collaboration, as well as streamlined communication, will also increase. Current imaging applications make it impossible for radiologists to collaborate on imaging studies with other healthcare professionals who lack the necessary equipment or software, providing appropriate, feature-specific feedback in a timely manner. While digital radiology imaging applications offer sophisticated toolsets and browsing environments, they fail to facilitate collaboration in specific situations, such as longitudinal studies involving comprehensive collections of digital images and annotations created on them.

[0007] Current PACS systems do not provide the accuracy required for sharing persistent diagnostic information, nor do they facilitate collaboration in digital image viewing environments. Therefore, there is a need for a PACS that provides communication and collaboration tools accessible across platforms and geographical areas.

[0008] Embodiments of the present disclosure are shown as examples, not limitations, in the accompanying drawings, where similar reference numerals indicate similar elements. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an exemplary method for creating and storing one or more comments within a DICOM image file according to one or more embodiments. [Figure 2] This figure shows an exemplary workspace for placing comments on a DICOM image file. [Figure 3] This diagram shows an exemplary workspace for displaying placed comments. [Figure 4] This diagram shows an exemplary workspace for displaying a comment list. [Figure 5] This figure shows an exemplary workspace demonstrating the placement of annotations. [Figure 6] This figure shows a block diagram of an exemplary medical imaging viewer system. [Figure 7] This diagram shows a workspace demonstrating how to edit comments. [Figure 8] This diagram illustrates a workspace for replying to comments. [Modes for carrying out the invention]

[0010] Other features of these embodiments will become apparent from the accompanying drawings and from the following detailed description.

[0011] Various applications, methods, and systems for providing improved communication and collaboration for digital radiology imaging environments are disclosed herein. The embodiments described can facilitate the storage of comments within digital biomedical images (hereinafter, “Images”) in accordance with one or more communication standards, such as the DICOM 3.X standard. It will be understood that the disclosed embodiments are applicable to future standards, i.e., updates to the DICOM standard or any other standard. The embodiments described can also facilitate the sharing of workspaces within digital biomedical image viewing applications with other users. Such embodiments may, among other things, employ cloud-based software applications configured to interpret and display DICOM image data without requiring end-users to locally store image data or metadata.

[0012] Referring to Figure 1, an exemplary method 100 for creating one or more comments and storing them in a DICOM image file is illustrated. As shown, method 100 begins in step 110, in which the viewer system receives comment location and comment information from a user. The user may access the viewer system through a thin client device (user device), which includes processing and storage hardware and is configured to run a viewer application accessible via an Internet or intranet application on which it is stored.

[0013] Referring to Figure 2, a workspace 200 for placing comments is shown. In one or more embodiments, the viewer system may allow a user to create, store, and share workspaces, for example, workspace 200. As used herein, “workspace” means a collection of DICOM image files associated with one or more studies configured by the user, and one or more user interfaces configurable by the viewer application to enable collaboration. Collections of DICOM image files, comments, and annotations can all be attributes of a workspace that can be configured by the user. Thus, a workspace may include annotations, comments, visual analysis, patient demographic information, or any other arbitrary toolset associated with a study. Any such arbitrary configuration of a workspace may be stored in the viewer system’s memory as described below.

[0014] In one embodiment, the user selects a location on a DICOM image 202, which is received from a viewer system via a network and displayed through a viewer application as shown, through the workspace 200 of the viewer application, which is run by the user's data processing device (user device). Once a location is selected, a short form of comment, i.e., an icon 204, is displayed at the image coordinates associated with that location. A user interface window 206 may also pop up, prompting the user to enter text 208 and then choose to place a comment ("Comment" button 210) or cancel the placement ("Cancel" button 212).

[0015] Comment information includes the text body, user identity (e.g., email, first name, last name), and creation date (e.g., timestamp) generated by the viewer application when the comment is created. The user identity can be retrieved from the user's profile information, which may be generated during the initial login. In one embodiment, the text body may contain alphanumeric characters. In a further embodiment, the text body may contain HTML formatting elements.

[0016] As described above, when a user submits a comment, the viewer application sends the comment information to the viewer system so that it is stored in persistent memory, such as non-volatile memory. The comment information stored in the user device's memory can then be removed. Therefore, the viewer application can leave a limited footprint on the user device by relying on the computing power and storage provisioning of the viewer system and third-party systems, such as HIS, RIS, and / or other PACS.

[0017] Referring again to Figure 1, in a further step 120, the viewer system converts the image coordinates to world coordinates. The world coordinates may be converted back to image coordinates when the same image is viewed through another viewer application instance and comments are displayed at a location on the image.

[0018] The final step 130 involves storing the world coordinates and comment information within a value field of a DICOM attribute, such as a STUDY ID. The STUDY ID attribute may be a preferred embodiment because it is a required element of any DICOM image file and is stored within the DICOM standard as a modality-specific attribute; i.e., the STUDY ID is generated by the instrument and optionally used to carry study-related information to identify the study for future reference. However, it will be understood that various header attributes or other elements of a DICOM image file, such as a STUDY UID, may be employed as alternatives or additions to store comment information, including content, creation time, user identity, and hierarchical relationships between them.

[0019] In addition, image properties can be stored along with world coordinates and comment information. Image properties can include image metadata at the time of comment creation, such as multi-planar reconstruction (MPR) properties, allowing for the pre-comment preservation of the image state within the comment. When a comment is viewed, its associated image properties can also be applied. Therefore, clicking a comment displays a snapshot of the image file at the time of comment creation. Sharing context in this way reduces ambiguity and streamlines communication.

[0020] Referring to FIG. 3, a work space 300 showing the placed comment 314 is shown. The comment 314 may be viewable by other users through the viewer application of the corresponding user device. The comment 314 can display a user entity, a text body, and a creation date. A delete button 316 for deleting the comment may be provided. Clicking on the comment icon 304 makes it possible to minimize the comment, i.e., to hide the comment information and show only the comment icon. Clicking on the corresponding icon later will redisplay the comment.

[0021] In other embodiments, the comment window may further include one or more selectable actions, such as an "Edit" button 315 or a "Reply" button 317. Editing may be shown in FIG. 7. Selecting to edit can enable the user to modify the comment information, i.e., the text body 719. In some embodiments, the comment information can only be edited by a user having the same associated user identity information. In other embodiments, the original posting user can provide access to individual users or share the associated work space with other users within the organization to enable editing and / or replying to the comment. Or the user can invite another organization or users of that organization to collaborate. In one embodiment, editing may include the user device retrieving the comment information from the viewer system, updating the comment information, and sending the updated comment information back to the viewer system. When the editing is complete, the user can select a "Save button" 721 to store the text body 719 in the viewer system (i.e., replace the comment information previously stored in the study ID).

[0022] Replies to comments can be shown in FIG. 8. The user replying may be prompted to enter a text body 819 and to confirm the text body by selecting a "Comment" button 823 and storing the reply in the comment information.

[0023] The reply function can utilize threads to store the parent-child relationships among parts of the comment thread and enable conversations among experts based on world coordinates. A comment thread can include the original comment and one or more replies made thereto. The comment thread can be sorted by date.

[0024] In some embodiments, the viewer application can display a list of one or more comments associated with a plurality of comment icons at any number of positions on an image. When a comment icon is selected, the comment information associated with that comment icon can be viewed in a comment window generated substantially proximal to that location, as shown in FIG. 3.

[0025] Referring to FIG. 4, a work space 400 is shown that displays a comment list 418 associated with an image stack 420. As shown, the viewer application can display a plurality of comments in the comment list 418 associated with a plurality of image files that make up the image stack 420. An image stack can refer to a collection of related DICOM image files, such as a series of cross-sections of a heart, or a multimodal compilation of DICOM image files.

[0026] Batch comment actions, such as minimizing all comments (i.e., to their icons), hiding all comments (i.e., including the icons), deleting all comments, and exporting comment information to a third-party database management system, can be applied to the entire image stack 420.

[0027] When a comment is selected from comment list 418, the comment information may be displayed through the viewer application (i.e., if the correct image file is displayed). If the image file corresponding to the selected comment is not yet displayed, the viewer application will first display the appropriate image file in image stack 420 before displaying the comment on top of it.

[0028] In another embodiment, the position of a placed comment may be modified by directly modifying the world coordinates associated with that comment. For example, a moved comment may be associated with a new position, i.e., new image coordinates. By comparing the new image coordinates with the image coordinates of the previous position, the viewer application can determine an update to the comment's world coordinates and send it to the viewer system so that it is stored in its memory.

[0029] Referring to Figure 5, the workspace 500 shows the arrangement of annotation 522 and comment 506 created on it. As shown, comment 506 may be associated with image annotation 522, for example, a measurement. Image annotations may be fully encoded using standard DICOM tags contained in the DICOM image file. Alternatively, image annotations may be encoded in one or more private data elements of the DICOM image file. In yet another example, image annotations may be a sequence of graphic annotations embedded in an annotation object, either embedded in the DICOM image or configured to reference an annotated DICOM image file. An annotation object may include a graphic annotation, a pointer to the corresponding DICOM image file, and a location in the DICOM image. The location may include world coordinates (these are converted to image coordinates before the image is displayed by a viewer application) or image coordinates. In one embodiment, the location of a comment associated with an annotation object may be the same as the location of that annotation object. In either case, the comment may further include a pointer to a measurement object (separate from the DICOM image file) or a private data element.

[0030] In one or more embodiments, the viewer system may allow the user to create, store, and share workspaces. As used herein, “workspace” means a collection of DICOM image files associated with a study and one or more user interface views thereof. A study may be associated with multiple workspaces. The user interface may be configured by the user to include annotations, comments, visual analysis, patient demographic information, or any other set of tools that may be used in the process of image analysis and other professional collaborations. Any such configuration of a workspace may be stored in the viewer system’s memory.

[0031] In one embodiment, a workspace may be associated with identity information. This identity information may include an organization ID associated with a particular organization and a name ID associated with a particular user. In one embodiment, workspace permissions may be set by the workspace creator to restrict read / write access to the workspace, and may be subsequently modified. In the simplest use case, an organization's policy may pre-approve all or a subset of users, for example, assigned radiologists, to facilitate user collaboration in imaging studies.

[0032] In a preferred embodiment, the organization ID is a required attribute of the workspace. The name ID can be an optional attribute, which allows authorized users to assume only the organization's identity, i.e., a workspace that is not user-specific. For example, any user within an organization associated with an organization ID can access the workspace that has the organization ID. However, if multiple users from the same organization access the organization's workspace, only one user should be selected to preserve the workspace configuration. Multiple simultaneous users editing a single workspace may result in branching in the version history. Therefore, the viewer system facilitates workspace sharing by, among other things, applying workspace locks, resolving simultaneous editing and comment insertion, and introducing auditing capabilities.

[0033] A workspace lock can be a key / value pair generated by the viewer system and stored in the viewer system's database or a third-party data store, such as REDIS, MongoDB, or Memcached. The workspace lock key may include the organization ID, name ID, and study ID. The workspace lock value can be a stringified object that internally contains the app ID associated with the app ID that owns the workspace lock, the email address associated with the user who owns the app ID that owns the workspace lock, the organization ID of the user who owns the app ID that owns the workspace lock, and the name ID of the user who owns the app ID that owns the workspace lock.

[0034] In one embodiment, the method for acquiring a workspace lock may include receiving a STUDY ID and user identity input from a user device. Based on the STUDY ID and user identity input, the viewer system may temporarily generate a session hash containing the current workspace identifier and store the hash in memory. In a further step, the viewer system may determine one or more other workspace identifiers associated with the received STUDY ID.

[0035] In a further step, the viewer system generates a separate workspace lock for each workspace identifier associated with the received STUDY ID. To generate the corresponding key-value pairs for each workspace lock, the viewer system may utilize the received user identity input or rely on a default user identity. In the separate embodiments described below, if multiple users are competing for workspace locks for the same study, the viewer system must resolve the lock conflict.

[0036] In the final step, the viewer system generates a lock on the workspace, allowing the user to use it. If the workspace lock has not been acquired (i.e., the workspace lock has already been acquired by another user), the user can only browse the workspace, but cannot influence the user interface or its layout. This can occur if any workspace associated with the desired study ID is currently locked (i.e., in use) by another user.

[0037] In one embodiment, the viewer system may resolve conflicts between workspace lock requests from different users. In a first step, the first user device may issue a first detection request to the viewer system to detect changes made to the workspace key. For example, the REDIS WATCH command may be used. In a second step, the second user device may issue a second detection request to the viewer system to detect changes made to the workspace lock key. In a further step, the first user sends a first request request to claim the workspace lock (see the workspace lock acquisition method described above). In another step, the second user sends a second request request to claim the workspace lock. In yet another step, if no changes were detected by the first detection request, the viewer system processes the first request request and transfers ownership of the workspace lock key to the first user device, i.e., the user identity associated with the first user device is applied to the workspace lock key. In a further step, the viewer system rejects the second request (i.e., sends a null response) based on the second detection request detecting changes made to the workspace lock key as a result of processing the first request.

[0038] In another embodiment, the viewer system is configured to prevent multiple simultaneous viewer application instances by the same user. A user may forget that an instance of the viewer application is running on their device (for example, the viewer application may be idle in a browser tab). A preferred embodiment is for the viewer system to detect new instances run by the user and terminate any previously running instances. In doing so, the viewer system reduces the overall bandwidth for the viewer system and the user device and prevents simultaneous changes from corrupting the workspace configuration.

[0039] This can be achieved by utilizing the app ID element of the workspace lock value. The app ID describes the context in which the instance is running. In an event where a new instance of the viewer application is commissioned by a user device using the same app ID, the viewer system may detect that same instance, lock the workspace for the new instance, and close the previous instance. The user interface of the previous instance may no longer display the locked workspace, and optionally, a dialog may be displayed to guide the user to a running instance or a different workspace, and / or to close the existing tab.

[0040] In one embodiment, the workspace lock expires after a threshold period, such as 30 seconds. To prevent expiration, the viewer application used by the user device may periodically ping the viewer system to maintain the connection. In the event of the workspace lock expiring, the viewer system may proceed with the unlocking method described below.

[0041] In one embodiment, the viewer system may unlock a workspace when the workspace lock expires, for example, when the user logs out of the viewer application, or when the user switches to a workspace related to a different study.

[0042] In the first step, the viewer system may detect one or more groups consisting of user logout events from the current workspace and workspace exit events from the current workspace, where the current workspace is associated with a workspace identifier, STUDY ID, and user identity information. In a further step, the viewer system may determine one or more other workspace identifiers that share a STUDY ID with the current workspace identifier. In the final step, the viewer system may remove locks from memory for all workspaces associated with matching workspace identifiers.

[0043] Referring to Figure 6, a block diagram showing an exemplary medical imaging viewer system 600 is shown. As shown, the system 600 includes any number of user devices 602A-N that can access the viewer system 606 and third-party system 608 through a network 604 (e.g., the Internet, a local area network, a wide area network, cellular, an intranet, etc.). The viewer system 606 is capable of, among other things, performing the comment creation and storage method 100 described above. Alternatively, various steps of the method described above and any other method described herein may be performed by user devices 602A-N or third-party system 608.

[0044] In one embodiment, the viewer system 606 may be implemented entirely or partially on one or more servers 610 including hardware 628 such as any number of processors 632, random access memory (RAM) 634, and internal or external memory 636. The server 610 may include a network interface 630, thereby enabling it to access and transmit or receive information through the network 604.

[0045] As shown, at least one database 612 may be accessed by the server 610. Although database 612 is shown as internal to the server 610, it will be understood that it may be accessed by the server 610 via network 604 or via another wired or wireless connection. The server 610 may store desired or required information in database 612 and may access that same database 612 to retrieve that information. As shown, database 612 may contain one or more database tables 614-618.

[0046] Database 612 can be in communication with an object-relational mapping (ORM) tool, also known as an object-relational model 620 or object-relational database management system. Although ORM 620 is presented as internal to server 610, it will be understood that it can be accessed by server 610 via network 604 or via a physical connection.

[0047] ORM620 can communicate with one or more of the Universal Resource Indicator (URI) mapper 622 and the Rest API generator 624. Initially, the URI mapper 622 can map URIs to pointers to internal programs, views, logic, or presentations of data within the system, based on one or more rules of matching objects specified in a collection of mapping objects. Matching objects can be regular expressions. The URI mapper 622 can also communicate with the web server 626.

[0048] The Rest API generator 624 can communicate with a web server to send and / or receive data to and from a user device communicating with the server 610 using HTTP and / or HTTPS. The Rest API generator 624 can prepare data stored in the database 612 for delivery to the user device, can receive data from connected systems, and / or can prepare received data for storage or transmission to one or more connected systems. The Rest API generator 624 may be able to perform conversions between formats including but not limited to JSON, DICOM, XML, and CSV. The Rest API generator 624 may be able to automatically generate URIs based on the data structure observed in the ORM 620 for access by client devices and connected systems.

[0049] A web server 626 can be adapted to deliver web pages to user devices on demand using a hypertext transfer protocol (HTTP and / or HTTPS) or a similar protocol. This allows for the delivery of HTML documents along with any further content that the document may contain, such as images, stylesheets, and scripts.

[0050] User devices 602A-N can engage in communication with a web server by employing a web browser or similar client application. For example, a client application can make a request for a specific resource using HTTP / HTTPS, and the web server can respond with the content of that resource, or with an error message if that is not possible. That resource could be data or a file stored in a database. The web server can, in some cases, receive content from the user device using HTTP / HTTPS.

[0051] In certain embodiments, user devices 602A-N can access server 610 (i.e., applications running on that server) via network 604. User devices may run client applications or other software such as a web browser or web browser-like application (e.g., a viewer application). In one embodiment, user devices 602A-N may include, for example, input / output devices, displays, processors, memory, and / or audio equipment. Exemplary user devices include, but are not limited to, general-purpose computers, laptops, mobile phones, smartphones, personal digital assistants, televisions, tablets, and wearable devices.

[0052] An exemplary viewer application may include HTML data, images, icons, and / or executable code. The executable code may consist of JavaScript, ECMAscript, CoffeeScript, Python, Ruby, or other programming languages ​​suitable for execution within a client application or conversion into a form executable by a client application.

[0053] It will be apparent to a standard technician in the art that in certain embodiments, any of the functions of user devices 602A-N, viewer system 606, and third-party system 608 may be incorporated into server 610, and vice versa. Similarly, any of the functions of viewer applications may be incorporated into a browser-based client, and such embodiments are intended to be entirely within the scope of this disclosure.

[0054] In one embodiment, communication between the viewer system and the connected device or system may involve the use of a conversion and / or serialization module. The serialization module can convert an object from an in-memory representation to a serialization representation suitable for transmission over HTTP or another transport mechanism. For example, the serialization module can convert data from a native Python, Ruby, or Java in-memory representation to a JSON string for communication over a client-to-server transport protocol.

[0055] Embodiments of subject matter and functional operations described herein can be implemented in one or more of the following: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including structures disclosed herein and their structural equivalents, and combinations thereof. The above embodiments can be implemented as one or more modules of computer program instructions (i.e., one or more computer programs) encoded on a tangible, non-temporary program carrier for execution by a data processing device or for controlling the operation of a data processing device. The program instructions may, as an alternative or additional, be encoded on artificially generated propagating signals (e.g., machine-generated electrical, optical, or electromagnetic signals) generated to encode information for transmission to a suitable receiver device for execution by a data processing device. The computer storage medium may be one or more of the following: machine-readable storage devices, machine-readable storage boards, random or serial access memory devices, and combinations thereof.

[0056] As used herein, the term “data processing device” includes, but is not limited to, programmable processors, computers, and / or multiple processors or computers, all types of devices, devices, and machines for processing data. Illustrative devices may include specialized logic circuits such as field-programmable gate arrays (FPGAs) and / or application-specific integrated circuits (ASICs). In addition to hardware, illustrative devices may include code that creates an execution environment for computer programs (e.g., code that constitutes one or more of the following: processor firmware, protocol stacks, database management systems, operating systems, and combinations thereof).

[0057] The term “computer program” may also be referred to herein as “program,” “software,” “software application,” “module,” “software module,” “script,” or simply “code.” A computer program can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, such as a standalone program, or as a module, component, subroutine, or other unit suitable for use in a computing environment. Such software can correspond to a file in a file system. A program may be stored as part of a file that holds other programs or data. For example, a program may include one or more scripts stored in a markup language document, in a single file dedicated to the program in question, or in a series of interconnected files (e.g., a file containing one or more modules, subprograms, or parts of code). A computer program may be deployed and / or run on a single computer, or on multiple computers located in one site, or distributed across multiple sites and interconnected by a communication network.

[0058] The processes and logic flows described herein may be executed by one or more programmable computers that execute one or more computer programs to perform functions by performing calculations on input data and generating outputs. The processes and logic flows may also be executed by dedicated logic circuits, such as but not limited to FPGAs and / or ASICs, and the device may be implemented as such dedicated logic circuits.

[0059] A computer suitable for running one or more computer programs includes, but is not limited to, a general-purpose microprocessor, a dedicated microprocessor, and / or any other type of central processing unit (CPU). Generally, the CPU will receive instructions and data from read-only memory (ROM) and / or RAM. Essential elements of a computer are the CPU for issuing or executing instructions, and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, and / or optical disks) for storing data, or will be operablely coupled to those mass storage devices to receive data, transfer data, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device such as a mobile phone, personal digital assistant (PDA), mobile audio or video player, game console, global positioning system (GPS) receiver, or portable storage device (e.g., Universal Serial Bus (USB) flash drive), but is not limited to these.

[0060] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices. For example, computer-readable media may include one or more of the following: semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and / or flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and / or CD-ROM and DVD-ROM disks. Processors and memory can be complemented by or incorporated into dedicated logic circuits.

[0061] To provide interaction with a user, embodiments may be implemented on a computer having any type of display device for displaying information to the user. Exemplary display devices include, but are not limited to, one or more of projectors, cathode ray tube (CRT) monitors, liquid crystal displays (LCDs), light-emitting diode (LED) monitors, and / or organic light-emitting diode (OLED) monitors. The computer may further include one or more input devices on which the user can provide input to the computer. Input devices may include one or more of keyboards and pointing devices (e.g., a mouse or trackball). Input from the user can be received in any form, including acoustic, voice, or haptic input. Furthermore, feedback may be provided to the user via any form of sensory feedback (e.g., visual feedback, auditory feedback, or haptic feedback). The computer may interact with the user by sending documents to and receiving documents from a device used by the user (e.g., by sending a web page to a web browser on the user's device in response to a request received from a web browser).

[0062] Embodiments of the subject matter described herein can be implemented in a computing system comprising one or more components, such as backend components (e.g., data servers), middleware components (e.g., application servers), frontend components (e.g., client computers having a graphical user interface (GUI) and / or a web browser through which a user can interact with an implementation of the subject matter described herein), and / or combinations thereof. The components of the system can be interconnected by digital data communications of any form or medium, but not limited to, such as a communications network. Non-exclusive examples of communications networks include local area networks (LANs) and wide area networks (WANs), such as the Internet.

[0063] A computing system may include clients and / or servers. Clients and servers may be remote from each other and can interact through a communication network. The relationship between a client and a server arises from computer programs running on each computer that have a client-server relationship with each other.

[0064] Various embodiments are described herein with reference to the detailed description above, the accompanying drawings, and the claims. Many specific details are described to provide a complete understanding of the various embodiments. However, in certain cases, well-known or conventional details are omitted to provide a concise discussion. The figures are not necessarily to scale, and some features may be exaggerated or minimized to illustrate the details of certain components. Therefore, the specific structural and functional details disclosed herein should not be construed as restrictive, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to adopt various embodiments.

[0065] The embodiments described and claimed herein, as well as the drawings, are illustrative and should not be construed as limiting the embodiments. The subject matter of this specification should not be limited by specific examples, for these examples are intended to illustrate some aspects of the embodiments. Any equivalent example is intended to fall within the scope of this specification. Indeed, in addition to those shown and described herein, various modifications of the disclosed embodiments will be apparent to those skilled in the art, and such modifications are also intended to fall within the scope of the appended claims.

[0066] This specification includes many specific implementation details, but these should not be construed as limitations on the scope of any disclosure or claim, but rather as descriptions of features that may be specific to particular embodiments of a particular invention. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, features may be described above as acting in a particular combination, and may even be initially claimed as such, but in some cases, one or more features from a claimed combination may be extracted from that combination, and the claimed combination may be derived into a subcombination or a variation thereof.

[0067] Similarly, while operations are shown in a specific order in the drawings, this should not be understood as requiring that such operations be performed in a specific or sequential order, or that all shown operations be performed, in order to achieve the desired result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0068] All references cited herein, including patents, patent applications, and published documents, are incorporated herein by reference in their entirety for all purposes to the same extent as each published document or patent or patent application is specifically and individually indicated to be incorporated by reference in its entirety for all purposes.

Claims

1. A method for embedding comments within a DICOM image file, The image viewer system's processor receives the comment location of the medical image in the DICOM image file and the comment information associated with the comment from a user device associated with the user, The aforementioned comment location includes image coordinates used by the viewer application running on the user device, The aforementioned comment information includes the text body, identity information relating to the user, and the comment creation date. Steps and The incorporation of the comments into the DICOM image file in accordance with one or more DICOM standards, at least A step of converting the image coordinates used in the viewer application to world coordinates used in the image viewer system, wherein the world coordinates can be converted to other image coordinates used in the other viewer application when the medical image is presented via another viewer application and the comments are displayed at the comment locations. The steps to standardize by, A step of storing the world coordinates and comment information as a subset of one or more header attributes of the DICOM image file on the storage media of the image viewer system, wherein the one or more header attributes are stored in accordance with one or more DICOM standards to provide future references to the study information. A step of receiving a reply to the comment from another user's device, wherein the reply is associated with the comment location and includes the reply text body, identity information relating to the other user, and the reply creation date, and the comment and the reply are stored in one or more header attributes and threaded based on the corresponding creation date. A method characterized by comprising:

2. The step of receiving an edit request from the user device and modifying the text body of the comment. The method according to claim 1, further comprising:

3. The step of receiving a move request from the user device that includes updated image coordinates and correcting the world coordinates accordingly. The method according to claim 1, further comprising:

4. Steps to receive a pin request to prevent the aforementioned comment location from being modified. The method according to claim 1, further comprising:

5. The method according to claim 1, characterized in that the comment shares the annotation object associated with the DICOM image file and the image coordinates.

6. The method according to claim 1, characterized in that the DICOM image file includes a plurality of DICOM images.

7. The method according to claim 1, characterized in that one of the one or more header attributes is an attribute of the study ID.

8. A method for incorporating comments into a DICOM image file, The image viewer system's processor receives the comment location of the medical image in the DICOM image file and the comment information associated with the comment from a user device associated with the user, The aforementioned comment location includes image coordinates used by the viewer application running on the user device, The aforementioned comment information includes the text body, identity information relating to the user, and the comment creation date. Steps and The incorporation of the comments into the DICOM image file in accordance with one or more DICOM standards, at least A step of converting the image coordinates used in the viewer application to world coordinates used in the image viewer system, wherein the world coordinates can be converted to other image coordinates used in the other viewer application when the medical image is presented via another viewer application and the comments are displayed at the comment locations. The steps to standardize by, A step of storing the world coordinates and comment information as a subset of one or more header attributes of the DICOM image file on the storage media of the image viewer system, wherein the one or more header attributes are stored in accordance with one or more DICOM standards to provide future references to the study information. Equipped with, Before incorporating the comments into the DICOM image file, the method, as a procedure for requesting access to the workspace in the environment in which the DICOM image file is used, The steps include: receiving a study ID and user identity related to a medical imaging study from the user device using the processor of the image viewer system, wherein the user identity includes one or more groups consisting of an organization ID, a name ID, an app ID, and an email address; The steps include generating a session hash that includes the study ID and the workspace identifier associated with the user identity, A step of storing the session hash in memory in order to further generate at least one workspace lock for resolving simultaneous access to the workspace by the user and one or more users, wherein the workspace includes the collection of DICOM image files associated with the medical imaging study and one or more user interface views. A method characterized by further comprising the following features.

9. The steps include determining one or more other workspace identifiers associated with the same study ID, For each workspace identifier determined to be associated with the aforementioned study ID, the step of generating one or more workspace locks, each including a key-value pair comprising a workspace key and a workspace value, The aforementioned workspace key includes the organization ID, name ID, and study ID, The aforementioned workspace value includes the app ID, the email address, the organization ID, and the name ID. Steps and The steps include storing the workspace lock in memory and The method according to claim 8, further comprising:

10. The method according to claim 9, characterized in that the one or more workspace locks are configured to expire after a predetermined period of time during which no "keep continue" request is received by the image viewer system from the user device.

11. The user logout event from the aforementioned workspace, Exit event from the aforementioned workspace and A step of detecting at least one of the following, The step of removing the one or more workspace locks associated with the one or more workspace identifiers. The method according to claim 9, further comprising:

12. The steps include receiving a first detection request from the user device and detecting a change made to the workspace key, The steps include receiving a second discovery request from another user device, The steps include receiving a first request from the user device and applying the user identity of the user to the workspace key, The steps include receiving a second billing request from the aforementioned other user device, The steps include writing the user identity of the user to the workspace key and sending a confirmation in response to the first request, When the second detection request detects a change to the workspace key, the second request sends a null response to the second request. The method according to claim 9, further comprising:

13. The method according to claim 9, characterized in that the generating step includes the step of detecting another workspace identifier stored in the memory of the image viewer system that shares the workspace identifier and the application ID, wherein the other workspace identifier is associated with a previously executed workspace instance.

14. The method according to claim 13, further comprising the step of terminating an instance that was previously running.

Images