Cloud-based radiology commenting and workspace sharing

The cloud-based medical imaging viewer system addresses the lack of collaboration tools by allowing users to create and share workspaces with annotations on DICOM images, improving communication and reducing ambiguity among healthcare professionals.

JP2025013858AActive Publication Date: 2025-01-28ARTERYS INC
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2024181842
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2018-11-20
Filing Date
2024-10-17
Publication Date
2025-01-28
Estimated Expiration
2039-11-19

AI Technical Summary

Technical Problem

Current medical imaging systems lack effective collaboration and communication tools for radiological images, especially in urgent situations, leading to inefficiencies in sharing diagnostic information and annotations across different healthcare professionals.

Method used

A cloud-based medical imaging viewer system that allows users to create, store, and share workspaces with comments and annotations directly on DICOM images, enabling collaboration through user interfaces and managing locks to prevent simultaneous editing.

Benefits of technology

Facilitates secure, efficient, and accurate sharing of diagnostic information and annotations, enhancing communication among healthcare professionals and reducing ambiguity in image interpretation.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025013858000001_ABST
    Figure 2025013858000001_ABST
Patent Text Reader

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
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE This disclosure relates generally to medical imaging applications and, more particularly, to medical image viewers for incorporating multi-user collaboration features such as in-image commenting and workspace sharing. [Background technology]

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 770,051, filed November 20, 2018, the entirety of which is incorporated herein by reference.

[0003] Typically, radiology images consist of two-dimensional, three-dimensional, or reconstructed fused images generated through imaging equipment utilizing modern nuclear medicine technologies, such as PET (positron emission tomography), CT (computed tomography), MRI (magnetic resonance imaging), fMRI (functional MRI), X-ray, mammography, tomosynthesis, ultrasound, or other modalities. Radiology images are typically stored in a patient's medical record (e.g., electronic medical record or EMR), EHR (electronic health record), or PACS (Picture Archiving and Communication System), and these images may be viewed by patients or health professionals in the course of diagnosis, treatment, or other health care delivery. However, communication related to radiology images can be insecure, inefficient, and / or limited in emergency situations. Users may share logins and passwords, use handwritten notes, create CDs, or call other users to communicate important, sometimes time-sensitive, information about specific features in radiology images.

[0004] Modern EMR and EHR software systems as well as PACS provide some communication capabilities between providers and patients. However, radiology images shared through these channels may lack diagnostic information generated during the course of the radiologist's examination. Even in cases where diagnostic metadata is provided, physicians are unable to communicate feature-rich data, e.g., location, measurements, and are unable to carry on conversations or collaborate with other physicians or their patients. One example is Horos, which offers cloud sharing with other users but does not provide any conversation or collaboration capabilities.

[0005] Generally, radiology images conform to the DICOM (Digital Imaging and Communications in Medicine) standard, which sets the file / data formats, data exchange protocols, and network protocol architecture used for digital radiology imaging. The DICOM standard has played a prominent role in the emergence of PACS (Picture Archiving and Communication System) integrating with HIS (Hospital Information System) and RIS (Radiology Information System).

[0006] As adoption of digital imaging at the enterprise level increases, so will the demand for collaboration as well as streamlined communication. With current imaging applications, it is not possible for radiology professionals to collaborate on imaging studies with other health professionals who lack the necessary equipment or software to provide appropriate function-specific feedback in a timely manner. Although digital radiology imaging applications provide sophisticated toolsets and viewing environments, they cannot facilitate collaboration in certain situations, e.g., longitudinal studies that include a comprehensive collection of digital images and annotations made on them.

[0007] Current PACS do not provide the precision required to share persistent diagnostic information, nor do they facilitate collaboration in a digital image viewing environment. Thus, there is a need for a PACS that provides communication and collaboration tools that are accessible across platforms and geographic areas.

[0008] Embodiments of the present disclosure are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference symbols indicate similar elements and in which: [Brief description of the drawings]

[0009] [Figure 1] FIG. 2 illustrates an exemplary method for creating and storing one or more comments in a DICOM image file according to one or more embodiments. [Diagram 2] FIG. 1 illustrates an exemplary workspace for placing comments on a DICOM image file. [Diagram 3] FIG. 1 illustrates an exemplary workspace displaying placed comments. [Figure 4] FIG. 1 illustrates an exemplary workspace displaying a list of comments. [Diagram 5] FIG. 1 illustrates an exemplary workspace demonstrating annotation placement. [Figure 6] FIG. 1 illustrates a block diagram of an exemplary medical imaging viewer system. [Figure 7] FIG. 13 illustrates a workspace demonstrating editing a comment. [Figure 8] FIG. 13 illustrates a workspace illustrating replying to a comment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Other features of these embodiments will be apparent from the accompanying drawings and from the detailed description that follows.

[0011] Disclosed herein are various applications, methods, and systems for providing improved communication and collaboration for digital radiology imaging environments. The described embodiments can facilitate storing comments within digital biomedical images (hereafter "images") according to one or more communication standards, such as the DICOM 3.X standard. It will be appreciated that the disclosed embodiments are applicable to future standards, i.e., updates to the DICOM standard or any other standard. The described embodiments can also facilitate sharing a workspace within a digital biomedical image viewing application with other users. Such embodiments can employ, among other things, cloud-based software applications configured to interpret and display DICOM image data without requiring end users to locally store image data or metadata.

[0012] 1, an exemplary method 100 for creating and storing one or more comments in a DICOM image file is illustrated. As shown, method 100 begins at step 110, where a viewer system receives a 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 a stored internet or intranet application.

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

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

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

[0016] Once the user submits comments as described above, the viewer application transmits the comment information to the viewer system to be stored in persistent memory, e.g., non-volatile memory. The comment information stored in the memory of the user device may then be removed. Thus, the viewer application can leave a limited footprint on the user device by relying on the computing power and storage provisions of the viewer system and third party systems, e.g., HIS, RIS, and / or other PACS.

[0017] 1, in a further step 120, the viewer system converts the image coordinates to world coordinates, which may be converted back to image coordinates when the same image is viewed through another viewer application instance to display comments at locations on the image.

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

[0019] In addition, image properties can be stored along with the world coordinates and comment information. The image properties can include image metadata at the time of comment creation, e.g., multiplanar reconstruction (MPR) properties, and can enable in-comment preservation of the image state before the comment was created. When a comment is viewed, its associated image properties can also be applied. Thus, clicking on a comment displays a snapshot of the image file at the time the comment was created. Sharing context in this manner can reduce ambiguity and streamline communication.

[0020] 3, a workspace 300 is shown showing a placed comment 314. The comment 314 may be viewable by other users through a viewer application on a corresponding user device. The comment 314 may display the user entity, the text body, and the creation date. A delete button 316 may be provided to delete the comment. Clicking on the comment icon 304 may minimize the comment, i.e., hide the comment information and show only the comment icon. Subsequent clicking on the corresponding icon will cause the comment to be displayed again.

[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 may allow the user to modify the comment information, i.e., the text body 719. In some embodiments, the comment information may only be edited by users with the same associated user identity information. In other embodiments, the original posting user may provide individual users access or share an associated workspace with other users within an organization to allow editing and / or replying to the comment. Or the user may invite another organization or users of that organization to collaborate. In one embodiment, editing may include retrieving the comment information from the viewer system, updating the comment information, and sending the updated comment information to the viewer system by the user device. Once editing is complete, the user may select a "Save button" 721 to store the text body 719 in the viewer system (i.e., replacing the comment information previously stored in the study ID).

[0022] A reply to a comment may be shown in Figure 8. The replying user may be prompted to enter a text body 819 and to confirm the text body by selecting the "Comment" button 823 to store the reply in the comment information.

[0023] The reply feature can utilize threads to store parent-child relationships between parts of a comment thread and enable conversations between experts based on world coordinates. A comment thread can include an original comment and one or more replies made to it. Comment threads can be organized by date.

[0024] In some embodiments, the viewer application is capable of displaying a list of one or more comments associated with multiple comment icons at any number of locations on the image. When a comment icon is selected, the comment information associated with that comment icon may be viewed in a comment window generated substantially proximate to the location, as shown in FIG.

[0025] 4, a workspace 400 is shown illustrating a comments list 418 associated with an image stack 420. As shown, a viewer application may display multiple comments in the comments list 418 associated with multiple image files that make up the image stack 420. An image stack may refer to a collection of related DICOM image files, for example, a series of cross sections of a heart, or a multimodal compilation of DICOM image files.

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

[0027] Selecting a comment from the comment list 418 may cause the comment information to 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 already displayed, the viewer application will first display the appropriate image file in the image stack 420 before displaying the comment thereon.

[0028] In another embodiment, the position of a placed comment may be modified by directly modifying the world coordinates associated with the placed comment. For example, a moved comment may be associated with a new position, i.e., new image coordinates. Comparing the new image coordinates with the image coordinates of the previous position, the viewer application can determine updates to the world coordinates of the comment and send them to the viewer system to be stored in memory therein.

[0029] With reference to FIG. 5, a workspace 500 shows an arrangement of annotations 522 and comments 506 made thereon. As shown, the comments 506 may be associated with image annotations 522, e.g., measurements. The image annotations may be fully encoded using standard DICOM tags included in the DICOM image file. Or the image annotations may be encoded in one or more private data elements of the DICOM image file. In yet another example, the image annotations may be a graphic annotation sequence embedded in the DICOM image or in an annotation object configured to reference the annotated DICOM image file. The annotation object may include the graphic annotation, a pointer to the corresponding DICOM image file, and a location in the DICOM image. The location may include world coordinates (which 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 the annotation object. In either case, the comment may further include a pointer to a measurement object (if separate from the DICOM image file) or a private data element.

[0030] In one or more embodiments, the viewer system may enable a user to create, store, and share workspaces. As used herein, a "workspace" refers to 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 toolset that may be used in the course of image analysis and collaboration with other experts. Any such configuration of a workspace may be stored in the memory of the viewer system.

[0031] In one embodiment, a workspace may be associated with identity information. 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 and subsequently modified to regulate read / write access to the workspace. In the simplest use case, an organizational policy may pre-authorize all or a subset of users, e.g., assigned radiologists, to facilitate user collaboration on an imaging study.

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

[0033] A workspace lock may be a key / value pair generated by the viewer system and stored in the viewer system's database or a third party data store, e.g., REDIS, MongoDB, Memcached, etc. A workspace lock key may include an organization ID, a name ID, and a study ID. A workspace lock value may be a stringified object that has within it the app ID associated with the app ID that owns the workspace lock, the email address associated with the user whose app ID owns the workspace lock, the organization ID of the user whose app ID owns the workspace lock, and the name ID of the user whose app ID owns the workspace lock.

[0034] In one embodiment, a method for acquiring a lock on a workspace may include receiving a STUDY ID and a user identity input from a user device. Based on the STUDY ID and the user identity input, the viewer system may temporarily generate a hash of the session including 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. The received user identity input can be utilized by the viewer system to generate the corresponding key-value pair of each workspace lock, or a default user identity can be relied upon. In a separate embodiment described below, if multiple users compete for workspace locks for the same study, the viewer system must resolve the lock conflicts.

[0036] In the final step, the viewer system creates a lock on the workspace and allows the user to use the workspace. If the workspace lock has not been acquired (i.e., the workspace lock has already been acquired by another user), the user can only view the workspace but cannot affect the user interface or its layout. This may 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, a REDIS WATCH command may be utilized. 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 to claim the workspace lock (see the workspace lock acquisition method described above). In another step, the second user sends a second request to claim the workspace lock. In another step, if no changes are detected by the first detection request, the viewer system processes the first 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 claim request (i.e., sends a null response) based on the second detection request detecting a change made to the workspace lock key as a result of processing the first claim request.

[0038] In another aspect, 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 by the user device (e.g., the viewer application may be idle in a browser tab). A preferred embodiment is for the viewer system to detect a new instance run by a user and terminate any previously running instances. In doing so, the viewer system reduces overall bandwidth for the viewer system and the user device and prevents simultaneous changes from corrupting the workspace configuration.

[0039] This may be accomplished by utilizing the App ID element of the workspace lock value. The App ID describes the context in which the instance runs. In the event a new instance of a viewer application is commissioned by a user device using the same App ID, the viewer system may detect that same instance, direct the workspace lock to 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 navigate the user to a running instance or a different workspace, and / or to close an existing tab.

[0040] In one aspect, the workspace lock expires after a threshold period, such as 30 seconds. To prevent expiration, the viewer application utilized by the user device may periodically ping the viewer system to keep the connection alive. In the event that the workspace lock expires, 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, the workspace lock may expire, for example, when a user logs out of the viewer application, or the workspace lock may expire when a user switches to a workspace associated with a different study.

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

[0043] 6, a block diagram illustrating an exemplary medical imaging viewer system 600 is shown. As shown, the system 600 includes any number of user devices 602A-N that are capable of accessing a viewer system 606 and a third party system 608 over 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 above method and any other methods described herein may be performed by the user devices 602A-N or the third party system 608.

[0044] In one embodiment, the viewer system 606 may be implemented in whole or in part 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, which enables it to access the network 604 and send or receive information through the network 604.

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

[0046] The 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 the ORM 620 is shown as internal to the server 610, it will be understood that it can be accessed by the server 610 over the network 604 or through a physical connection.

[0047] The ORM 620 may be in communication with one or more of a Universal Resource Indicator (URI) mapper 622 and a Rest API generator 624. First, the URI mapper 622 may map a URI to a pointer to an internal program, view, logic, or presentation of data in the system based on one or more rules of a matching object specified in a collection of mapping objects. The matching object may be a regular expression. The URI mapper 622 may be in communication with a web server 626.

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

[0049] The web server 626 may be adapted to deliver web pages to user devices upon request using the HyperText Transfer Protocol (HTTP and / or HTTPS) or similar protocols, which allows for the delivery of HTML documents and any further content that may be included by the documents, such as images, style sheets, and scripts.

[0050] The user devices 602A-N may employ a web browser or similar client application to engage in communication with a web server. For example, the client application may make a request for a particular resource using HTTP / HTTPS, and the web server may respond with the content of that resource or with an error message if it is unable to do so. The resource may be data or a file stored in a database. The web server may receive content from the user device, possibly using HTTP / HTTPS.

[0051] In particular embodiments, user devices 602A-N are capable of accessing server 610 (i.e., applications running on the server) through network 604. The user devices may be capable of running client applications or other software, such as a web browser or a 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, wearable devices, and the like.

[0052] An exemplary viewer application may include HTML data, images, icons, and / or executable code that may be constructed in JavaScript, ECMAscript, coffeescript, python, Ruby, or other programming languages ​​suitable for execution within or conversion into a form executable by a client application.

[0053] It will be apparent to one of ordinary skill in the art that in certain embodiments, any of the functionality of the user devices 602A-N, the viewer system 606, and the third party system 608 may be incorporated into the server 610, or vice versa. Similarly, any of the functionality of the viewer application may be incorporated into the browser-based client, and the above aspects are intended to be fully within the scope of the present disclosure.

[0054] In one embodiment, communication between the viewer system and a connected device or system may include the use of a conversion and / or serialization module. The serialization module may convert objects from an in-memory representation to a serialized representation suitable for transmission over HTTP or another transport mechanism. For example, the serialization module may 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] The subject matter and functional operations described herein may be implemented in one or more of digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware including the structures disclosed herein and their structural equivalents, and combinations thereof. The above embodiments may be implemented as one or more modules of computer program instructions (i.e., one or more computer programs) encoded on a tangible, non-transitory program carrier for execution by or to control the operation of a data processing apparatus. The program instructions may alternatively or additionally be encoded on an artificially generated propagated signal (e.g., a machine-generated electrical, optical, or electromagnetic signal) generated to encode information for transmission to a suitable receiver apparatus for execution by the data processing apparatus. And the computer storage medium may be one or more of a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, and combinations thereof.

[0056] As used herein, the term "data processing apparatus" includes all types of apparatus, devices, and machines for processing data, including but not limited to programmable processors, computers, and / or multiple processors or computers. Exemplary apparatus may include special purpose logic circuitry, such as field programmable gate arrays (FPGAs) and / or application specific integrated circuits (ASICs). Exemplary apparatus may include, in addition to hardware, code that creates an execution environment for computer programs (e.g., code that constitutes one or more of processor firmware, protocol stacks, database management systems, operating systems, and combinations thereof).

[0057] The term "computer program" may be referred to herein as "program," "software," "software application," "module," "software module," "script," or simply "code." A computer program may be written in any form of programming language, including compiled or interpreted, declarative or procedural, and may be deployed in any form, such as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. Such software may 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 multiple associated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program may be deployed and / or executed on one computer, or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0058] The processes and logic flows described herein may be performed by one or more programmable computers executing one or more computer programs to perform functions by performing operations on input data to generate output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, such as, but not limited to, an FPGA and / or an ASIC.

[0059] A computer suitable for executing one or more computer programs includes, but is not limited to, a general-purpose microprocessor, a special purpose microprocessor, and / or any other type of central processing unit (CPU). Typically, a CPU will receive instructions and data from a read-only memory (ROM) and / or a RAM. The essential elements of a computer are a CPU for performing or executing instructions, and one or more memory devices for storing instructions and data. Typically, 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 operatively coupled to receive data from or transfer data to or from those mass storage devices, or both. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, such as, but not limited to, a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive).

[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, the computer-readable media may include one or more of 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. The processor and memory can be supplemented by, or incorporated in, dedicated logic circuitry.

[0061] To provide for interaction with a user, the embodiments may be implemented on a computer having any type of display device for displaying information to a user. Exemplary display devices include, but are not limited to, one or more of a projector, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), a light emitting diode (LED) monitor, and / or an organic light emitting diode (OLED) monitor. The computer may further include one or more input devices through which a user may provide input to the computer. The input devices may include one or more of a keyboard, a pointing device (e.g., a mouse or a trackball). Input from a user may be received in any form, including acoustic, speech, or tactile input. Moreover, feedback may be provided to a user via any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback). The computer may interact with a 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 the web browser).

[0062] Embodiments of the subject matter described herein can be implemented in a computing system that includes one or more of the following components: a back-end component (e.g., a data server), a middleware component (e.g., an application server), a front-end component (e.g., a client computer 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 any form or medium of digital data communication, such as, but not limited to, a communication network. Non-limiting examples of communication 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 interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

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

[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 in scope by the specific examples, as these examples are intended as illustrations of some aspects of the embodiments. Any equivalent examples are intended to be within the scope of this specification. Indeed, various modifications of the disclosed embodiments, in addition to those shown and described herein, 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] Although the specification contains many specific implementation details, these should not be construed as limitations on the scope of any disclosure or what may be claimed, but rather as descriptions of features that may be specific to certain embodiments of a particular invention. Certain features described in the specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in a particular combination, and even initially claimed as such, one or more features from a claimed combination can in some cases be carved out of the combination, and the claimed combination can be led to a subcombination or a variation of the subcombination.

[0067] Similarly, although operations are shown in the figures in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown, or in sequential order, or that all of the shown operations be performed, to achieve desirable results. In certain situations, multitasking and parallel processing may be advantageous. Moreover, 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 program components and systems described may generally be integrated together in a single software product or packaged into multiple software products.

[0068] All references, including patents, patent applications, and publications, cited in this specification are incorporated by reference in their entirety for all purposes to the same extent as if each publication or patent or patent application was specifically and individually indicated to be incorporated by reference in its entirety for all purposes.

Claims

1. 1. A method for incorporating comments in a DICOM image file, comprising: receiving, by a processor of the image viewer system, from a user device associated with a user, comment locations of medical images in the DICOM image file and comment information associated with the comments; the comment location includes image coordinates used by a viewer application executing on the user device; The comment information includes a text body, identity information related to the user, and a comment creation date. Steps and incorporating said comments into said DICOM image file in accordance with one or more DICOM standards, at least Transforming the image coordinates used in the viewer application into world coordinates used in the image viewer system, where when the medical image is presented via another viewer application and the comment is displayed at the comment location, the world coordinates are transformable into other image coordinates used in the other viewer application; storing the world coordinates and the comment information in a storage medium of the image viewer system as a subset of one or more header attributes of the DICOM image file, the one or more header attributes being saved as one or more modality specific attributes in accordance with the one or more DICOM standards to provide future reference for study information; The step of standardizing by A method comprising:

2. receiving an edit request from the user device to modify the text body of the comment; The method of claim 1 further comprising:

3. receiving a movement request from the user device including updated image coordinates and modifying the world coordinates accordingly; The method of claim 1 further comprising:

4. receiving a pin request to prevent the comment location from being modified; The method of claim 1 further comprising:

5. receiving a reply to the comment from another user device of another user, the reply being associated with the comment location and including a reply text body, identity information related to the other user, and a reply creation date; The method of claim 1 further comprising:

6. 6. The method of claim 5, wherein the comments and replies are stored in the one or more header attributes and threaded based on corresponding creation dates.

7. The method of claim 1 , wherein the comment shares the image coordinates with an annotation object associated with the DICOM image file.

8. The method of claim 1 , wherein the DICOM image file includes a plurality of DICOM images.

9. 2. The method of claim 1, wherein one of the one or more header attributes is a study ID attribute.

10. requesting access to a workspace in an environment for use of the DICOM image file prior to incorporating the comment into the DICOM image file, receiving, by the processor of the image viewer system, from the user device, a study ID related to a medical imaging study and a user identity, the user identity including one or more of the group consisting of an organization ID, a name ID, an app ID, and an email address; generating a hash of the session including the study ID and a workspace identifier associated with the user identity; storing a hash of the session in memory for the user and for further generating at least one workspace lock for resolving concurrent access to the workspace by one or more users, the workspace including the collection of DICOM image files associated with the medical imaging study and one or more user interface views; The method of claim 1 further comprising:

11. determining one or more other workspace identifiers associated with the same study ID; generating, for each workspace identifier determined to be associated with the study ID, one or more workspace locks, each of the workspace locks including a key-value pair including a workspace key and a workspace value; The workspace key includes an organization ID, a name ID, and the study ID; The workspace values ​​include the app ID, the email address, the organization ID, and the name ID. Steps and storing said workspace lock in memory; The method of claim 10 further comprising:

12. 12. The method of claim 11, wherein the one or more workspace locks are configured to expire after a preconfigured period during which a "keep on continuing" request is not received by the image viewer system from the user device.

13. A user logout event from the workspace; and A workspace exit event from said workspace; detecting at least one of removing the one or more workspace locks associated with the one or more other workspace identifiers; The method of claim 11 further comprising:

14. receiving a first detection request from the user device to detect changes to be made to the workspace key; receiving a second detection request from another user device; receiving a first claim request from the user device to apply the user identity of the user to the workspace key; receiving a second billing request from the other user device; writing the user identity of the user into the workspace key and sending a confirmation in response to the first claim request; sending a null response to the second request if the second request detects a change to the workspace key; The method of claim 11 further comprising:

15. 12. The method of claim 11, wherein 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 app ID, the other workspace identifier being associated with a previously running workspace instance.

16. 16. The method of claim 15, further comprising terminating the previously running instance.

Citation Information

Patent Citations

  • Report generation support apparatus, report generation support system, and medical image referring apparatus

    JP2010057902A

  • Matching findings between imaging datasets

    JP2016525426A

  • Medical image display device, medical information management server

    WO2012049741A1