WO2008052283A1

WO2008052283A1 - Image reporting system and apparatus

Info

Publication number: WO2008052283A1
Application number: PCT/AU2007/001681
Authority: WO
Inventors: Martin Fine
Original assignee: Medinexus Pty Ltd
Priority date: 2006-11-02
Filing date: 2007-11-02
Publication date: 2008-05-08

Abstract

Apparatus (1000) for management of medical images and for preparing and circulating reports on analysis of those images has a medical reporting client (8), a central server system (9), a download client (12), and a web application (14). The apparatus (1000) is interfaced with imaging apparatus (1) and may be interfaced with PACS/IS system (2) or a RIS/LIS/CIS/HIS system (3). The medical reporting client (8) is the application that is used to create, aggregate, generate, and combine, medical reports with their associated images or media. The central server module (9) is used to map formats of medical reports and images, manage medical reports and images centrally for distribution to referring health providers, manage profiles and facilities centrally, manage various users' profiles of doctors, operators, and patients. The download client (12) is used to integrate medical report data into healthcare practitioners in-house systems. The web application (14) handles secure communications with healthcare practitioners, logins, accessing of images, image manipulation and forwarding messages to practitioners. Healthcare practitioners are notified by SMS (18) or by email (13) that reports with images (8f) are available for viewing. The healthcare practitioner may then view the reports with images (8f) using a web browser (15) over a secure connection.

Description

Image reporting system and apparatus.

Field of the invention

The present invention relates to the generation of medical-related or other images and other data, to the analysis of such images or data., and to securely reporting on the results of that analysis to a healthcare practitioner or the like.

Background of the invention

It will be evident to the reader that, although the emphasis of the description of the invention is on the healthcare fields, embodiments of the invention may be used in other fields where images and data are analysed and the results of the analysis reported. Accordingly, throughout this specification (including the claims) we use the terms:

"image generating facility" to mean any type of facility that can generate images or other data, including a radiology clinic, pathology laboratory, or other type of healthcare facility that generates medical reports with images or other media for distribution to referring healthcare providers; and "analysis facility" to mean any type of facility which can receive such images or data to generate a report, including a medical practice, dental practice or the like.

Practice in the fields of medical imaging is generally segregated into the fields of specialist practitioners. Radiographers are a category of healthcare practitioners who produce images for medical diagnostic purposes. Radiologists are a category of healthcare practitioners who specialize in the analysis of such captured images and in subsequently reporting that analysis to the referring healthcare practitioner. The general .procedure is that a healthcare practitioner such as a medical general practitioner (GP) refers a patient to a radiographer for imaging, such as by magnetic resonance imaging (MRJ), X-ray imaging and ultrasound imaging. The images are sent to a specialist practitioner (such as a radiologist) for analysis. It is common for radiologists to produce upwards of 60 to 80 reports per day. It is usually the case that the images (such as X-ray prints) and the report are then given to the patient and a copy .of the report is sent to the referring practitioner. It is thus generally the responsibility of the patient to ensure that the images are taken to the referring practitioner.

Il takes a radiologist a very long time to examine all images, prepare reports, collate images and reports and sign the assembled report and images. There is also substantial cost in producing film, and the associated paper work and distribution.

At the moment the onus is on the GP to ensure that the patient does attend for the imaging (or other procedures) and to ensure that the specialist reports on the imaging or testing is sent back to the GP. There is little standardization in the formats by which images are sent from image capture sites to specialists for analysis or in the formats by which images and reports are then sent by the specialist to the referring practitioner.

It is accordingly an aim of the present invention to facilitate to some degree the automation of the process of associating reports with images or the like.

It is also an aim that at least some embodiments of the invention have the capacity to notify a referring practitioner that a report has been prepared and is ready for perusal by that practitioner.

It is also an aim of the present invention to facilitate the secure supply of reports from radiologists and the like to referring healthcare practitioners and the like.

It is also an aim of the present invention to allow a referring healthcare practitioner to view images and the associated reports remotely over a computer network.

It is also an aim that at least some embodiments of the invention have the capacity to allow a referring healthcare practitioner to check that reports have been received on all patients who have been referred for imaging.

It is also an aim that at least some embodiments of the invention allow the reporting radiologist to track and check which reports and images have been read by the referrers and to take appropriate action if any reports have not been read.

It is also an aim of at least some embodiments of the invention to notify the referrer of the availability of reports.

Summary of the invention In one aspect, the present invention provides a process of reporting the analysis of an image or the like, the process comprising: receiving at least one image that has been generated in an electronic form by an image generating facility; assembling the analysis of the at least one image together with the at least one image into a report; storing the report and image as a single document on a computer network; and sending a notification to a user that the report is available for accessing.

It is preferred that the process further comprises the step of notifying an image analyst that the at least one image is available for analysis.

The process further comprises the step of the analyst applying an electronic signature to the report before the user is notified that the report is available for accessing.

It is preferred that the notification is sent by at least one of an email message and an SMS message.

It is preferred that the report is available for accessing over a computer network.

It is preferred that the step of assembling the report automatically incorporates into the report additional data which is additional to the image data.

It is preferred that the additional data is data about the subject of the image.

It is preferred that the subject of the image is a patient of a first healthcare practitioner; and the user of the report is a second healthcare practitioner.

It. is preferred that the first healthcare practitioner and the second healthcare practitioner are the same. It is preferred that the additional data has been gathered from an information system of the first healthcare practitioner.

It is preferred that any alteration to the report after it has been, signed invalidates the electronic signature to the report.

It is preferred that the step of applying an electronic signature to the report uses a PKI identity certificate.

It is preferred that the report is available for accessing by using a cryptographically secured mechanism,

It is preferred that the report is available for accessing by using a Web browser.

It is preferred that the process further includes the step of monitoring whether a report has been accessed by a user to whom a notification was sent.

It is preferred that the process further includes the step of a user authorizing another user to access the report.

It is preferred that the process further includes the step of a user printing a report.

It is preferred that different steps of the process are performed by two or more different software programs.

Further preferred features of the invention are set out in the claims which are appended to this description.

Brief description of the drawings

Preferred embodiments of the invention are described with reference to the drawings, in which:

Figures 1 and 2 are block schematic diagrams illustrating apparatus according to one embodiment of the invention;

Figures 3 to 21 are flow-charts illustrating the operation of the apparatus of the embodiment of figure 1; and

Figures 22 to 60 are screen-capture prints illustrating some inputs to, and some outputs from, apparatus of the embodiment of figure 1.

Description of preferred embodiments of the invention

Figure 1 is a block diagram showing a system 1000 according to a preferred embodiment of the present invention. This figure illustrates the relationship and connections with each system as well as the connections and relationships with other third-party systems, the global computer network and medical apparatus.

The apparatus 1000 includes a medical reporting client 8, a central server system 9, a download client 12, and a web application 14. The apparatus 1000 is also interfaced with a number of other systems, some of which are illustrated in figure 1.

It is preferred that the system 1000 is implemented using IBM-PC compatible hardware running Windows 2000 Server Edition operating systems. The system 1000 uses a web server, application server, integration server and a database server that runs Microsoft SQL 2000.

As is described in more detail below:

The medical reporting client 8 is the application that is used to create, aggregate, generate, and combine, medical reports with their associated images or media.

This process can be set to run automatically (without human intervention) at predefined time intervals or manually (with human intervention) when required. The central server module 9 is the back-end infrastructure of the overall system and is located on a hosting facility. The central server module 9 is a series of hosted applications, services and methods used to map formats of medical reports and images, manage medical reports and images centrally for distribution to referring health providers, manage profiles and facilities centrally, manage various users' profiles of doctors, operators, and patients. The download client 12 is used to integrate medical report data into GP (general practitioners) PMS (practice management software) / CIS (clinical information system) 10. The download client 12 downloads medical reports 11 in various formats from the central server module 9 and then populates a file based directory for integration into GP PMS / CIS 10. The web application 14 handles secure communications with healthcare practitioners, logins, accessing of images, image manipulation and forwarding messages to practitioners.

The apparatus 1000 is also interfaced with a number of third party applications or systems used in medical practices, some of which are illustrated in figure 1, such as: digital medical apparatus 1; a PACS (picture archiving and communications system) or IS (imaging system) 2;

RIS (radiology information system); a LIS (laboratory information system), a CIS (clinical information system); a HIS (hospital information system), a PMS (practice management system) 3; a GP (general practice) PMS (practice management system) / CIS (clinical information system) 10; a third-party SMS (short message service) messaging device 16; a cellular / mobile telecommunications network such as GSM (global system for mobile communication) network; a CDMA (code division multiple access) network 17; and the global computer network 19.

The apparatus 1000 is used to gather information in the form of completed reports and images from any of these sources. These can be in a number of different formats which include:

HL7 (health level seven);

XML (extensible markup language);

PIT (pathology information transfer); DOC (Microsoft Word document foπnat) 4; images in DICOM (digital imaging commutation) foπnat 5; images in JPEG (Joint Photographic Experts Group) format, GIF (graphics interchange format),BMP (bitmap), PNG (portable network graphic) format or

TIFF (taged image file foπnat) format 6; other data in XLS ( Excel Spreadsheet), CSV (comma separated values) and

ODBC (object database connection) format 7; and medical reports for integration into GP PMS in HL7 and PIT formats 11, email 13, and SMS 18.

In addition, all the components of the system 1000 communicate with each other securely via the global computer network 19, through HTTPS (hypertext transport/transfer protocol secure) using SSL 128bit (secure socket layer protocol with 128 bit encryption).

The following digital medical apparatus 1 can be installed within an image generating facility for acquiring and producing images and other media or data within that facility: X-ray imaging apparatus; MRI (magnetic resonance imaging) apparatus; CT (computed tomography) apparatus; US ( ultrasound) apparatus;

DEXA or DXA (dual energy X-ray absorptometry) apparatus; PET (positron emission tomography) apparatus; cardiology apparatus such as a ECG (electrocardiograph) device; camera apparatus such as a normal digital camera or a medical specialty camera (such as a thermographic camera or a medical endoscope); or any other device or apparatus such as a flow cytometer.

Such apparatus acquires and produces images and media in various formats such as DICOM, JPEG, GIF, BMP, PNG, TIFF 6, and other data such as XLS, CSV and ODBC 7.

An image generating facility may have a PACS (picture archiving and communication system) / IS (imaging system) 2, in place to facilitate the integration, archiving, and management of medical image or media within that facility. PACS / IS system performs the following standard functions:

The PACS / IS 2, provides a patient worklist function that enables users within the facility to work from a list of patients who need procedures performed or images acquisition. The patient worklist integrates patient information to and from the digital medical apparatus 1, and the RIS / LIS/ CIS/ HIS 3. The PACS / IS 2, provides an image / media management function that enables users within the facility to manage, interpret, and manipulate the selected images / media.

The PACS / IS 2, provides an image query and retrieve function that enables other systems to query for images, media and data and retrieve that information via a set of commands. The medical reporting client 8 integrates into this image query & retrieve function to access images in DlCOM format 5 and accesses other information such as patient information.

A healthcare facility may have some type of RIS (radiology information system) or a LIS (laboratory information system), or a CIS (clinical information system), or a HIS (hospital information system) or a PMS (practice management system) 3, in place to manage patient information, appointments and scheduling, clinical /diagnosis management, billing and accounting and report generation. The RIS / LIS / CIS/ HIS 3 system perform the following functions:

The RIS / LIS / CIS/ HIS 3, provide a patient worklist function that enables users within the facility to work from a list of patient that need procedures performed or images acquired for. The patient worklist integrates patient information to and from the PACS / IS 2.

The RIS / LIS / CIS/ HIS 3, provide a patient worklist function that enables users within the facility to manage patient information such as patient records, patient cases, patient billing and accounting, patient scheduling and appointments and other functions related to patient management.

The RIS / LIS / CIS/ HIS 3, provide a reporting function that enables users within the facility to create patient medical reports. This function then generates these medical reports 4, in various formats such as HL7 (health level seven), XML

(extensible markup Language), DOC (Microsoft Word document format), PIT (pathology information transfer) and places them in a file directory that enables other systems to pick up and interpret those medical reports 4. The medical reporting client 8, integrates into the RIS / LIS / CIS/ HIS 3, via the medical report files and the file directory. The medical reporting client 8, acquires the medical report files from the specified file directory.

The medical reporting client 8 is the application that is used to create, aggregate, generate, and combine, medical reports with their associated images or media. This process can be performed automatically (without human intervention) or manual (with human intervention). The medical reporting client 8 implements the following functions: the image conversion and management function 8a; the server communication component 8b; the digital signing function 8c; the communication messaging function 8d; and the communication HTTPS layer 8e.

The image conversion and management function 8a interfaces with the PACS /IS 2 and with the digital medical apparatus 1 to source image and media data, Once images or medical data have been acquired, the image conversion and management function 8a converts them into other formats such as JP2 and J2K (JPEG 2000 image standard formats) using a wavelet-based image compression standard. This enables the lossless compression of these images and media so that they can be delivered via a secure pipe over the global computer network 19.

The server communication component 8b provides a number of functions within the medical reporting client 8. They include: data conversion and management; creation of files creation of files into predefined structured XML format; preparation of files for upload; the management of the settings and parameters of the application and its methods and the management of a predetermined schema to be used for XML documents.

The server communication component 8b, interfaces and integrates into the RIS / LIS / CIS/ HIS 3, via the medical report files and the file directory. The server communication component 8b, acquires the medical report files from the specified file directory. The server communication component 8b then converts those files into XML and saves the original file for storage both locally and on the central server module 9. The server communication component 8b, then links the associated images in JP2/J2K format to the XML based on the criteria of patient details. The server communication component 8b, creates a XML report with images 8f. The server communication component 8b, then prepares the files for the XML report with, images for upload to the central server module 9. The XML report with images 8f, is segmented into different data fields for easy population into the data repository 9a.

The digital signing function 8c, interfaces to the user's (reporting health provider) digital PKI certificate either provided by HESA (Health eSignature Authority) or a third party certificate authority as displayed in a screenshot in figure 38. The Health eSignature Authority (HeSA - see www.hesa. com.au) has been established by Medicare Australia to undertake the role of registration authority within the Australian healthcare sector. The Health eSignature Authority receives applications from organisations and professionals within the Australian healthcare sector, authenticates the identity of the prospective healthcare location or healthcare individual user and submits requests to its certification authority - Cybertrust Asia Pacific - for certificate issue. The Health eSignature Authority then distributes the digital key pairs and digital certificates to approved healthcare locations and individual users by registered post. The digital signing function 8c, sources the digital certificate information and from this information creates a digital signature that is unique to the user and links to the XML report with images 8g. Once the XML report with images 8g is digitally signed it is transported via the communication HTTPS Layer 8e to the central server module 9 where the XML report with images 8g is available for access by the referring health provider. If the digitally signed report is altered in any way it is deleted. The digital signature process ensures non-repudiation and trust within the system. Once the report is digitally signed the system is prompted to proceed with the communication messaging function 8c and the communication HTTPS layer 8e.

The communication messaging function 8d, manages the local component of the communication of SMS 8h and email 8g reminders to referring health providers.

The communication HTTPS Layer 8e enables connectivity between the medical reporting client 8 and the central server module 9 via the global computer network 19. This happens via the secure protocol of HTTPS (hypertext transfer/transport protocol) using 128 bit SSL that all messages, correspondence and files transported via medical reporting client 8 is encrypted. The central server module 9 is the back-end infrastructure of the overall system and is located on a hosting facility. The central server module 9 is a series of hosted applications, services and methods used to map formats of medical reports and images, manage medical reports and images centrally for distribution to referring health providers, manage profiles and facilities centrally, manage various users' profiles of doctors, operators, and patients.

The central server module 9 has: The data repository 9a; the web application 9b; the orchestration hub 9c; and the secure communication HTTPS Layer 9d.

The data repository 9a, consists of a database that encompasses the configuration data the raw data from reports, patients, doctors, users, etc and graphics / images such as facility logos, PDF files, HL7 files, etc. The data repository 9a also has a file directory that stores the images associated with each report. The data repository 9a internally interfaces with the web application 9b, and the communication HTTPS layer 9d and orchestration hub 9c. The configuration data is the various settings and system parameters that recorded within with the medical reporting client 8, the web application 14, or the download client 12 and is stored within the configuration segment of the database in the data repository 9a.

The web application 9b, is an application that enables referring health providers to access medical reports and images from any computer with a connection to the global computer network. The web application is hosted on the central server module 9. The web application 9b internally interfaces with the data repository 9a and the communication HTTPS layer 9d.

Orchestration hub 9c has a web services layer and a business object classes layer. The web services layer is a system designed to support interoperable interaction over the global computer network utilizing XML files, The business object classes layer is a series of small applications that have different uses that control various actions such as adding data into the data repository or translating a HL7 file into XML format, orchestration hub 9c internally interfaces with the data repositoiy 9a and the communication HTTPS layer 9d.

The communication HTTPS layer 8e enables to connectivity between the central server module 9, the medical reporting client 8, the download client 12 and the web application 14 via the global computer network 19. This happens via the secure protocol of HTTPS (hypertext transfer/transport protocol) using 128 bit SSL that all messages, correspondence and files are transported with encryption.

The download client 12 is used to integrate medical report data into GP (general practitioners) PMS (practice management software) / CIS (clinical information system) 10, The download client 12 downloads medical reports 11 in various formats from the central server module 9 and then populates a file based directory for integration into GP PMS / CIS 10 as is explained in detail below.

The download client 12 has the following components: The communication HTTPS layer 12a; server communication component 12b; and the report delivery function 12c.

The communication HTTPS layer 12a enables connectivity between the central server module 9, and the download client 12 via the global computer network 19. This happens via the Secure protocol of HTTPS (hypertext transfer/transport protocol) using 128 bit SSL thereby ensuring all messages, correspondence and files are securely encrypted prior to being transported.

The server communication component 8b, enables the download client 12 to authenticate user information with the central server module 9 and to centrally manage the settings and parameters of the application and its methods such as the file directories and file formats used for integration.

The report delivery 12c function enables the download client 12 to integrate medical reports 1 1 into GP PMS / CIS 10 by placing the reports into the specified directory ready for the GP PMS / CIS 10 to pick up the files and attach them to the patient record. The web application 14 is accessed by the referring health providers via a web browser 15 (such as Internet Explorer or Netscape, etc) to access the medical reports and images. The use of a web application avoids the need to install and maintain any proprietory application software on potentially thousands of client computers.

The web application 14 has the following functions: The communication HTTPS layer 14a; the login function 14b; the report and image access function 14c; the image manipulation function 14d; and the forwarding function 14e. The communication HTTPS layer 14a enables to connectivity between the data repository 9a, and the web application 14 via the global computer network 19, This happens via the secure protocol of HTTPS (hypertext transfer/transport protocol) using 128 bit SSL). The login function 14b enables the user to log into the web application as displayed in figure 43 while the login function 14b authenticates the users name and password with the data repository 9a, to verify access to the system.

The report and image access function 14c enables the user to view the medical report and image via a web browser 15. This function is displayed in a series of screenshots in figure 44, figure 45 and figure 46.

The image manipulation function 14d enables the user to zoom in and out of the images via the web browser 15 to view aspects of the content with clarity. This function is displayed in a screenshot in figure 47.

The forwarding function 14c enables the user to select another recipient (colleague) for the report and forward the information onto another user on the system. This function is displayed in a series of screenshots in figure 48, figure 49 and figure 50.

Figures 3 to 11 are flow charts illustrating the functions of the medical reporting client 8 of the Medinexus system.

Figure 3 is a flow chart illustrating the settings function of the medical reporting client 8 and the connections, processes and tasks performed when configuring the medical reporting client for report creation. This flowchart also illustrates the interaction between medical reporting client, orchestration hub and the central database. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c.

Step m1, the user logs into the medical reporting client 8, using a username and password allocated and set up by Medinexus for that particular user. Step m2, the medical reporting client 8, sends a request to authenticate the user's username and password with orchestration hub 9c. Step h1 orchestration hub receives the request and validates the user's username and password against the data repository 9a. Step h2 if the user details are correct, orchestration hub 9c checks if that computer is registered to use the Medinexus system. If the user details are not correct the medical reporting client 8, returns the user to step m1. Step h3 if the computer is registered to use the Medinexus system, step h4 orchestration hub 9c sends the configuration settings to the medical reporting client 8. If the computer is not registered to use the Medinexus system, the user is redirected back to step m1. Step m3, once the medical reporting client 8, receives the configuration file the medical reporting client 8, examines the file for the settings parameters. The medical reporting client 8, displays these settings to the user. This function is displayed in a screenshot in figure 22.

The user can then change the settings based on their facilities setup configuration. The settings that can be changes are set out in steps m4 through to m8. Step m9 the medical reporting client 8, then saves the settings in the configuration file and uploads the file to orchestration hub to be processed. Step h6, orchestration hub received the configuration file and saves changes under the facility record. Step m10, the medical reporting client 8 validates if the current user is a doctor. If not a doctor step m11 the medical reporting client 8 prompts the user to select the doctor mat will be reporting. If the user is a doctor step m12 the doctor is require to select the digital certificate that will be used to sign the reports. Step m13 the administration setting process is complete.

Figure 4 is a flow chart diagram illustrating the automated report generation of the medical reporting client 8 and the connections, processes and tasks performed when reports with images are automatically generated - this means that the reports and the images that come from the RIS system and the PACS or similar systems can occur as a 'background' task, to be checked and digitally signed by the practitioner at convenient times throughout a day. This eliminates the laborious manual task of creating reports. This flowchart also illustrates the interaction between medical reporting client, orchestration hub and the central database. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c.

Step m14, the medical reporting client 8, checks if the system is in automated report creation mode or manual report creation mode. If the system is in manual report creation mode processing continues with figure 5. If the system is in automated report creation mode the system step m15 checks for report folder locations and report formats in the configuration file. Step m16 the system checks the specified folder for the specified report files, i.e. HL7 or PIT reports. Step m18 the system checks if new files (reports) exist in the specified directory. If there are no new specified files within the specified directory the system returns to step m17 to await the polling time. At the designated polling time the system starts step m16 again to check for new files. If there are new files within the specified directory the system will start step m19. The system converts the files into XML files based on the Medinexus schema. Step m20, the system stores the original source files i.e. HL7 or PIT, locally in an archive folder and the system also uploads those files to orchestration hub 9c to be stored in the media segment of the data repository 9a. This function is displayed in a screenshot in figure 23.

Step m22, the system also temporarily stores the XML version of the report locally. Step m23, the system reads the data from the XML report. The system picks up the patient data and the referring health provider data. Such data includes patient name, patient date of birth, patient Medicare number, and patient address. For the referring health provider, such data includes: doctor's name, doctor's address, and doctor's provider number. The system sends this data to orchestration hub 9c to check whether the patient and referring health provider pertaining to this report exist in the data repository 9a. If they do not exist, the records will be added to the data repository 9a. Step h7 orchestration hub 9c, searches for referring health provider and patient within the database h8 of the data repository 9a, Step h9, the system validates if the referring health provider and patient exist. If the referring health provider and/or patient do not exist, the system starts step hi 0 and creates a patient record and/or a referring health provider record within the database h8. Step m24 the medical reporting client 8, queries the PACS/IS 2 using relevant data from the XML report. The relevant data includes: patient name, patient date of birth, and exam ID. Step m25 the PACS/IS 2 query and retrieve interface checks for DICOM images or other media that have been marked as required by the reporting doctor. If there are no marked images or other media, the medical reporting client 8, in step m26 requests from orchestration hub 9c, the report xsl (extensible style language) style sheet based on the report format setup in the medical reporting client 8, Step h11, orchestration hub 9c, retrieves the XSL file from the media segment of the data repository 9a. The XSL stylesheet is the formatting file that provides a consistent look and feel for each report from that facility. If there are marked DICOM images or other media the medical reporting client 8, step m30 locally stores the relevant DICOM data such as patient details, notes, DICOM exposure, contract and brightness, etc. Step m31 the medical reporting client 8, converts DICOM images into JP2/J2K image format. The JP2/J2K images are a lossless compressed version ready for easy and efficient uploading over the global computer network 19. Step m32 the medical reporting client 8, locally stores the JP2/J2K images. Step m33 the associated JP2/J2K images are then linked within the XML report. Step m34 the medical reporting client 8, requests from orchestration hub 9c, the report xsl (extensible style language) style sheet based on the report format setup in the medical reporting client 8. Step h11 , orchestration hub 9c, retrieves the XSL file from the media segment of the data repository 9a. If the report has associated JP2/J2K images the medical reporting client 8 in step m36 start server communication component 8b to merge the XML report, the XSL stylesheet m35 and the JP2/J2K images to create a HTML report. Step m37, the report with images is then displayed. If the report has no associated JP2/J2K images the medical reporting client 8 in step m37 start server communication component 8 b to merge the XML report and the XSL stylesheet m35 to create a HTML report. Step m28, the report without images is then displayed. Step m29, the reports are now- in preliminary mode. Preliminary mode is the stage of a report that can be edited by the creator, before the report is uploaded into the central server module 9 via the global computer network 19.

Figure 5 is a flow chart illustrating the manual report creation function of the medical reporting client 8, illustrating process for the entering of patient details, referrer details, report urgency and report title for a manually created report. This flowchart also illustrates the interaction between medical reporting client, orchestration hub and the central database. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c. Step m38, the medical reporting client 8, prompts the user to enter the patient name and date of birth. This function is displayed in a screenshot in figure 24. Step m39, the medical reporting client 8, sends patient details to orchestration hub 9c, to search and verify details. Step hi 2, orchestration hub 9c receives request with patient details. Step hi 3, orchestration hub 9c, checks the database in the data repository 9a to see if the patient already exists based on search criteria. Step hl4, if so, orchestration hub 9c, sends the patient record to the medical reporting client 8, and populates the patient demographic details on the screen. Demographics include telephone number, address, Medicare number, etc. The users it taken to step m42 to confirm the patient details. If the patient does not exist on the database, the user is prompted in step m40 to continue with entering patient demographic details. Step m41 the medical reporting client 8, sends patient demographics for insertion into the database. Step h16, orchestration hub 9c, receives request to save patient record. Step h17, the patient record is created and saved in the database within the data repository 9a. Step m42, the user is required to confirm patient details. Step m43, the user is required to add the details of the intended report recipient - usually a referring health provider. This function is displayed in a screenshot in figure 27 and figure 28. Step m44, the user is required to enter the recipient's name. Step m45, the medical reporting client 8, sends recipient/referrer details to orchestration hub 9c, to see whether that referrer is on our data. Step h18, orchestration hub 9c receives request with recipient/referrer details. Step h19, orchestration hub 9c, checks the database in the data repository 9a to see if the recipient/referrer exists based on search criteria. Step h20, if the recipient/referrers does not exist the user is taken back to step m44 to try again. If the recipient/referrer exists orchestration hub 9c, sends the recipient/referrers record to the medical reporting client 8, and populates the recipient/referrers demographic details on the screen. The user it taken to step m46 to confirm the recipient/referrer details. Step rn47, the user is now required to select the urgency of the report, viz a vie urgent report, important report, or for your information. Step m48, the user is required to enter the title of the report (i.e. chest X-ray report - Possible fractured rib). Step m49, the user is advised to select if they would like the patient address included on the report (statutory requirement). The medical reporting client 8 now takes the user to FIG 6 to complete the report creation process.

Figure 6 is a flow chart illustrating the report typing or load report content function within the manual report creation function of the medical reporting client 8 illustrating the connections, processes and tasks performed when manually creating a report where the report content is typed or a report from another system like the RIS system is manually imported. This flowchart also illustrates the interaction between medical reporting client, orchestration hub and the central database. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the "orchestration hub 9c. These functions are displayed in screenshots in figure 28, figure 29, figure 30, figure 31, figure 32, and figure 33.

Step m50, the medical reporting client 8, displays a screen that enables the user to type the report content or load an existing report document. If the user wants to load a report, step m52, the user browses the local machine or internal network for the desired report document either in .txt (flat text file) or .doc (Microsoft Word document) format. Once selected the user is taken to step m.53. Step m51, if the user wants to type of the report contents they do so as if they were to type a document in another program such as

Microsoft Word. Step m.53, the user customizes the text formatting by the controls on the application. The user can change attributes such as font, colour, size, alignment, etc. Step rn54, the user browses and selects desired images for import into the report. The user can select images of the following formats: JPG, BMP, GIF and TIFF. Step m55, the medical reporting client 8, converts the images into JP2/J2K images. Step ra56, the user is prompted to add captions for each of the images. Step m57, the user selects the size of the images to be displayed on the report and if they would like the images to have magnifying functionality (zoom - figure 14) via the Medinexus web application 14. Step m.58, the medical reporting client 8, creates a XML report from the data that was entered and stores both the XML report m60 and the JP2/J2k images m61 locally ready for upload to the central server module 9. Step m59 the medical reporting client 8, requests from orchestration hub 9c, the report xsl (extensible style language) style sheet based on the report format setup in the medical reporting client 8. Step h21, orchestration hub 9c, retrieves the XSL file from the media segment of the data repository 9a. Step m63 starts server communication component 8b to merge the XML report, the XSL stylesheet m62 and the JP2/J2K images to create a HTML report. Step m64, the report with images is then displayed. Step m65, the user is required to decide if they would like to upload the report now or later. If the user wants to upload the report later the medical reporting client 8 will take them to figure 7. If they would like to upload the report now medical reporting client 8, will take them to m76 within figure 7.

Figure 7 is a flow chart illustrating the preliminary report mode of the medical reporting client 8 and the connections processes and tasks performed when uploading the reports and images to orchestration hub and the central database. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c. These functions are displayed in screenshots in. figure 34, figure 35, and figure 36,

Step m68, the medical reporting client 8, displays a list of the preliminary reports (reports created but not uploaded) available. Step m.69, the user selects the desired report for uploading to the central server module 9. Step m70, the selected report with images is displayed, The user can either delete the report m72, which also deletes the XML report and images from the local machine or the user can upload m74 the report. If the user deletes the report it is returned to list of available preliminary reports m69. If the user wants to upload the reports,, the medical reporting client 8, step m75, prepares the XML report and JP2/J2K images for upload to the central server module 9. Step m77, server communication component 8b, sends the XML reports and associated JP2/J2K images to orchestration hub 9c. Step h25, orchestration hub 9c, receives request for storing the XML report and images. Step h26, the XML report with image links is stored within the data repository 9a, and linked to the patient and referrer/recipients record. Images are stored within a file directory within the data repository 9a.

Step m78, reports and images are uploaded successfully. Step m79, the user can either sign the report at this stage or elect to do so later. If the user chooses to sign later, they are taken back to the list of preliminary reports, m69. If the user elects to the sign the report now, step m80, the user checks if they are authorised to sign that report (is the user a reporting doctor with a secure signature key). If the user is a reporting doctor the medical reporting client 8, proceeds to FIG 8.6.

Figure 8 is a flow chart illustrating the draft report mode of the medical reporting client 8 and the connections, processes and tasks performed when viewing the reports that have been uploaded to Medinexus Central. This flowchart also illustrates the interaction between medical reporting client, orchestration hub and the central database.. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c. These functions are displayed in a screenshot in figure 37.

Step m82. the medical reporting client 8, displays a list of draft (reports uploaded to the central server module 9, with no digital signature) reports available. Step m83, user selects desired reports for signing or deleting. If the user wants to sign, the medical reporting client 8, step m.90 checks if the user is authorised to sign. If they are authorised the medical reporting client 8, lakes the user to FIG 8.6, If the user wants to delete the report, step m88, a request is sent to orchestration hub 9c to delete the report from the central server module 9. Step h31 , orchestration hub 9c, receives request to delete the report. Step h32, the XML report is deleted from the data repository 9a, and the images are deleted from the file directory. Step m89, the report and images are successfully deleted and the user is returned to step m83. . .

Figure 9 is a flow chart illustrating the digital signing of reports and images through the medical reporting client 8 and the connections, processes to digitally sign reports with images. This flowchart also illustrates the interaction between medical reporting client, orchestration hub and the central database. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c. These functions are displayed in screenshots in figure 38, figure 39, and figure 40.

Step ro.92, the medical reporting client 8, takes the authorised user (reporting doctor) through the process of digitally signing the report prior to sending it to recipients/referring health providers. The user is required to confirm the report recipient / referrer. Step m93 the medical reporting client 8, searches the certificate registry on the local machine for digital certificates installed. Step m94, the authorised user selects the required digital certificate. The digital certificate can be in the format of a software certificate, a smart card certificate, a USB certificate or other type. It is preferred that the certificate be a HeSA certificate. Step m95 the authorised user is required to enter the unique password for that certificate. Step m96, the medical reporting client 8, creates a unique digital signature for the reporting doctor from the doctor's digital certificate. Step m97 the digital signature is uploaded to orchestration hub 9c. Step h35, orchestration hub 9c, receives request to sign and complete the report with images. Step h36, orchestration hub 9c, generates request to send email or SMS based on recipient and report status. This process is shown in figure 11. Step h37, the XML report and links to images are digitally signed. The digital signature is stored in the data repository 9a. Step h40, access to the report is now provided to the recipient / referring health provider. Step m98, the digital signing process is now complete. Step m99., the user is taken back to draft reports figure 8. Figure 10 is a flow chart illustrating the completed reports mode of the medical reporting client 8 and the connections, processes and tasks performed when viewing and searching for reports with images that have already been sent. This flowchart also illustrates the interaction between medical reporting client, orchestration hub, and the central database.. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c.

Step m100, a list of completed (signed and sent) reports are displayed. These functions are displayed in a screenshot in figure 41. Step m10l, the user can select desired report for viewing and the status of the report/ audit trail (the date/time that the report was viewed by the recipient). Step m102, the medical reporting client 8, sends request to orchestration hub 9c, for the time that the report was viewed. Step h42, orchestration hub 9c, receives request. Step h43, orchestration hub 9c, checks the data repository for the date and time that the report was viewed. Step m103, the date and time of when the report was viewed by the recipient is displayed within the medical reporting client 8. Step m104, the user has the option to forward the report to additional recipients / referrers. Step m105, the Recipient search screen is displayed. Step m106, the user is required to add the details of the intended report recipient - i.e. medical colleague. Step m107, the user is required to enter the recipient's name. Step m108, the medical reporting client 8, sends recipient details to orchestration hub 9c, to see whether that doctor / medical colleague is on the database Step h45, orchestration hub 9c receives request with recipient. Step h46, orchestration hub 9c, checks the database in the data repository 9a. Step m109, orchestration hub 9c, sends a list of recipients based on the search criteria to the medical reporting client 8. Step m110, the user is required to select desired recipient. Step m111, the user is now required to select the urgency of the report, viz a vie urgent report, important report, or for information. Step m132, the user is required to confirm, the forwarding details, Step m113, medical reporting client 8 generates a request to orchestration hub 9c, to action the report forwarding. Step h47, orchestration hub 9c, receives request to forward the report to the desired recipient. Step h48, access to the report is given to the new recipient and additional information is saved in the data repository 9a.

Figure 11 is a flow chart illustrating the communication component for sending SMS and / or email notifications in the medical reporting client 8 and tasks performed when the system automatically generates email and/ or SMS reminders for sent reports. This flowchart also illustrates the interaction between medical reporting client, orchestration hub, the central database and the third party SMS messaging components. The flow on the right is the medical reporting client process and the flow on the left is the interaction with the orchestration hub 9c.

Step h49, orchestration hub 9c, accesses the data repository 9a, and checks the recipient / referrer record profile to ascertain whether that referrer would like to receive SMS (Short Messaging Service) messages for urgent reports and/ or email reminders of reports that he has not viewed, orchestration hub 9c, also checks the report data for the urgency of the report. Step h51 , if the referrer / recipient has email reminders activated; check if the referrer / recipient has an email address listed. If the referrer / recipient does not have email reminders activated orchestration hub 9c, goes straight to step h56. Step h53, if the referrer / recipient does not have an email address listed orchestration hub 9c, goes straight to h56. If the referrer / recipient has an email address listed, proceed with the emailing process. Step h54, orchestration hub 9c, creates an email with the report title links to the login of the web Application 14. This email is generated from a pre-existing template. Step h55, the email is then sent via SMTP (Simple Mail Transfer Protbcol) to the email address listed within the profile section of the recipient / referrers record. Step h56, if this is an urgent report as per the status information of the report data, orchestration hub 9c, proceeds with the SMS process, if it is not an urgent report the process is ended, Step h58, If the recipient / referrer has a mobile phone number in their profile part of their record, orchestration hub 9c, proceeds with the SMS process, if it is not an urgent report the process is ended. According to alternative embodiments of the invention, the SMS process is proceeded with even if the report is not urgent. Step h59, orchestration hub 9c, creates a XML file from a pre-existing SMS template. Step h60, XML file is sent to the Third Party SMS Messaging Service 16 to distribute via SMS to the recipient / referrers mobile phone number, Step t1, Third Party SMS Messaging Services 16 sends the SMS to the recipient/ referrer's phone via a mobile / cellular network such as GSM or CDMA. Step t3, the recipient / referrer receives an SMS on their mobile phone advising them that an urgent report is available for them to view via the web application 14.

For purposes of confidentiality, neither the e-mail message nor the SMS contain patient identifiers - they simply state the type of report that has been reported on.

Figures 13 to 21are flow chart diagrams describing the functions of the web application 14, of the Medinexus system and are described in this third embodiment.

Figure 13 is a flow chart illustrating the login, and report viewing of the web application 14 and the connections, processes and tasks preformed when logging in to the system and accessing reports with image. This flowchart also illustrates the interaction between web application and the central database.. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. These functions are displayed in screenshots in figure 42, Figure 43, figure 44, figure 45, figure 46, figure 47, figure 48, figure 49 and figure 50.

Step w1 , the user opens the web browser 15. Step w2 the user navigates to the Medinexus web application 14, either via the Medinexus website (www.medinexus.com.au) or by entering the login address into the web browser's 15 address bar.. Step w3, the user clicks the login button. Step w4, the web application's 14 secure HTTPS login screen is launched.. Step w5, the user enters their username and password. This function is displayed in a screenshot in figure 43.

A temporary usemame and password is allocated to the user by the facility. The first time the user logs into the web application 14, the user is prompted to change the password.

Step dl, the user's credentials (username and password) are validated with the login details stored in the database. Step d2, if the user's credentials are valid the user is logged into the system w6. If the user's credentials are not valid, the user is returned to the secure login screen w4. Step w7, a list of current reports (reports that have not been accessed or have been accessed within the last day) is displayed. Step w8, the user selects the desired report with "one click" the report is requested from the database. This function is displayed in a screenshot in figure 42. Step d4, the desired report and images are accessed from the data repository 9a, (the report is accessed from the database, and the images are accessed from the file directory on the central server module 9). This function is displayed in screenshots in figure 44, figure 45, and figure 46. Step w9, the desired digitally signed report and images are displayed to the user on one web page w10 within the web application 14. Step d6, the date and time of when the report was accessed is recorded in the database. Step w11, the user has a number of report options that they can now choose from. All these functions are accessed by "one click". The user may choose to: go back to the current report screen w12; print the report w16; view reporting doctor's digital certificate information w13; zoom into images w21. This function is displayed in a screenshot in figure 47; or forward the report to another recipient w20. This function is displayed in screenshots in figure 48, figure 49, figure 50, figure 51, figure 52, and figure 53.

Step w12, to go back to the current report screen the user clicks once on the back icon. This takes the user back to w7.

Step w17, to print the report, the user clicks once on the print icon. Step w18, the use is prompted with their operating system's print selection window, The user selects printer, and other related information, (i.e. printer tray, paper size, etc) and clicks the print button. The report is printed.

Step w14, the user clicks once on the reporting doctor's digital certificate link. Step d8, the digital certificate information is accessed from the database. Step w15, the digital certificate information is displayed such as doctor's name, provider number, certificate number, etc.

Step w21 , the user clicks the magnifying icon next the desired image to zoom into the images. This function is displayed in a screenshot in figure 47. The user is taken to figure 14.1. Step w20, the user clicks the forwarding icon to forward the report onto another recipient. The user is taken to figure 14.2. This function is displayed in screenshots in figure 48, figure 49, figure 50, figure 51, figure 52, and figure 53. Figure 14 is a flow chart illustrating the zoom function of the web application 14 and the connections, processes and tasks performed when enhancing the viewing of images. This flowchart also illustrates the interaction between web application and the central database.. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. This function is displayed in a screenshot in figure 47.

Step w22, the user selects the desired image to be viewed and clicks once on the magnifying icon next to the image. Step w23 the image request is sent to The central server module 9. Step d9, the desired image is accessed from the file directory within the data repository 9a. Step w24, the image is displayed in a large size within a popup window. Step w25, the user may zoom in or out. The user either clicks once or moves the cursor over the zoom in or zoom out link to proceed with zooming into or out of the image.

Figure 15 is a flow chart illustrating the forwarding function of the web application 14 and the connections, processes and tasks performed when forwarding a reports with images to another recipient. This flowchart also illustrates the interaction between web application and the centra! database. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. This function is displayed in screenshots in figure 48, figure 49, figure 50, figure 51, figure 52, and figure 53.

Step w28, the user clicks once on the forward report icon. Step w29, a forwarding history list is display. This displays all recipients that the particular report has been forwarded to, Step w30, if the user does not want to continue with forwarding the report they click the back button once, w31. Step w32 the user selects the forward to button, Step w33; a recipient search screen is displayed. Step w34, the user enters in the search criteria to find a recipient. The user may enter first name, last name and specialty. Step w36, the user clicks the search button and a request is sent. Step dl 1, the request is received and 'closest match' recipients based on the search criteria are retrieved from the database. Step w37, a list these is displayed. The user selects the intended recipient at Step w39; the user enters the forwarding comments (like using a "post-it") and the urgency of the report. Step w40, the user proceeds with the forwarding by clicking the save icon. Step w41, the report is forwarded to the desired recipient, and dl5, the report forwarded and additional information is saved to the database.

Figure 16 is a flow chart illustrating the search functions of the web application 14 and the connections, processes and tasks performed when making a selection of patient, report, or doctors search. This flowchart also illustrates the interaction between web application and the central database. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. This function is displayed in screenshots in figure 54, figure 55, figure 56, and figure 57.

Step w42, the user selects the search icon. Step w43, the search screen is displayed. Step w44, the user has three search options. The user can search for reports w45, patients w55 or doctors w50. This function is displayed in screenshots in figure 54 and figure 55.

Step w45, the user selects the doctors search option. Step w46, the user enters in search criteria to find doctors. The user can enter the following criteria; first name, last name or parts thereof. The user clicks the search icon. The web application 14, takes the user to figure 19.

Step w50, the user selects the report search option. Step w45l, the user enters in search criteria to find reports. The user can enter any of the following criteria; report title, date/date range, patient's first name and last name, patient's date of birth, if the report was a received, sent or forwarded report. The more detail the user provides, the tighter the search and the fewer returns. The user clicks the search icon. The web application 14, takes the user to figure 18.

Step w55. the user selects the patient search option. Step w46, the user enters in search criteria to find patients. The user can enter any or all the following criteria; first name, last name, date of birth. The user clicks the search icon. The web application 14, takes the user to figure 17.

Figure 17 is a flow chart illustrating the patient search functions of the web application 14 and the connections, processes and tasks performed when searching for patients and their reports. This flowchart also illustrates the interaction between web application and the central database. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a.

Step w60, the web application 14 sends the criteria-based search request for patients. Step dl 6, the database receives search request and accesses patients based on search criteria.\ Step w61, a list of patients that match the search criteria is displayed Step w62, the user selects the desired patient and clicks once. Step w63, sends record request for patient details. Step d19, the database receives request and. accesses patient record. Step w64, the patient record is displayed on the screen in editable fields. The information that is displayed is name, gender, date or birth, address, Medicare number, telephone number and email. Step w65, the user can update the patient information within the editable fields. Step w66, the user clicks the save icon, and the information is sent to the database to be saved to the patient Record. Step w68, the user has the option to either edit the current patient or create a new patient. If the user chooses to edit the existing patient the web application 14 returns them to w64. If the user selects that they would like to create a new patient, w69 an empty patient demographic form is displayed. The user is required to enter the data of name, gender, date or birth, address, Medicare, phone and email. The information is sent to the database and saved as a new patient record. Figure \ 8 is a flow chart illustrating the report search functions of the web application 14 and the connections, processes and tasks performed when searching for reports by criteria. This flowchart also illustrates the interaction between web application and the central database.. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a.

Step w71 , the web application 14, sends the criteria-based search request for reports. Step d25, the database receives search request and accesses the reports based on search criteria. Step w72, a list of reports is displayed based on search criteria. Step w73, the user selects the desired report and clicks once. Step w74, sends record request for report information. Step d28, the database receives request and accesses the reports and images record. Step d30, the user ID, and time and date on which the report was accessed is recorded within the database (for audit trail purposes, so that the system can notify the authors (radiologists etc) of any unread reports at any given time) Step w74, the digitally signed report with images is displayed on the screen. Step w77, the user may select a number of different functions for that report. This is described in figure 14, Figure 19 is a flow chart illustrating the doctor search functions of the web application 14 and the connections, processes and tasks performed when searching for doctors on the system. This flowchart also illustrates the interaction between web application and the central database. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. This function is displayed in screenshots in figure 56 and figure 57.

Step w78, the web application 14, sends the criteria-based search request for doctors. Step d31 , the database receives search request and accesses the doctors based on search criteria. Step w79, a list of the selection criteria is displayed. Step w80, the user selects the desired doctor and clicks once. Step w81, sends record request for doctor information. Step d34, the database receives request and accesses the doctor's record. Step w82, the doctor's record is displayed on the screen.

Figure 20 is a flow chart diagram detailing the profile functions of the web application 14 the connections, processes and tasks performed when viewing and editing the profile for that user within the system. This flowchart also illustrates the interaction between web application and the centra] database. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. This function is displayed in a screenshot in figure 58, figure 59 and figure 60.

Step w83, the user clicks on the rny profile icon. Step w84, the web application 14 requests profile information. Step d36, receives request and accesses my profile settings from the database. Step w85, my profile settings are displayed on screen. Step w86, my profile settings include: title, first name, last name, usemame, password, qualifications, email address, health care facility, specialty, areas of interest, address, telephone number, receive SMS alerts, text size, list length, etc. Step w87, the user can edit the following information. Step w88, the user edits the information within the profile settings. Step w90, for the user to cancel, the user clicks the cancel icon w89, for the user to save the changes made, the user clicks the save icon w91. Step d39, the database receive request to save profile information. Step d40, the user's profile settings are updated on the database. Figure 21 is a flow chart diagram detailing the healthcare facility functions of the web application 14 and the connections, processes and tasks performed when viewing and editing the association of the user to a healthcare facility and the details of that healthcare facility. This flowchart also illustrates the interaction between web application and the central database. The flow on the right is the web application 14 process and the flow on the left is the interaction with the database / data repository 9a. This function is displayed in a screenshot in figure 58.

Step w93, the user clicks on the my facility icon. Step w94, the web application 14 requests the user's facility information. Step d41, receives request and accesses associated facilities from the database. Step w95, a list of facilities with association to user are displayed on screen. Step w96, the user clicks on desired facility. Step w97, a request is sent for desired facility information. Step d44, receives request and accesses facility information from database. Step w98, web application 14 validates if the user is an administrator of the select facility. If the user is not an administrator, w99 non-editable facility information is display, such as facility name, address, logo, email, and phone. If the user is an administrator, w10l editable facility information is displayed on screen in fields that cover facility name, address, logo, email, phone, type of facility and services provided. Step w102, if the user wants to edit this information they proceed to step w103 and they enter and change the information within the fields and options. Step w106, the user clicks the save icon and the changes facility information is sent to the database. Step d46; request received to save facility information and it is updated on the facility record. This function is displayed in a screenshot in figure 59 and figure 60.

Figure12 is a flowchart 12 is a flow chart illustrating the functions of the download client 12 and the connections, processes and tasks performed when downloading report files and integrating into third party software. This flowchart also illustrates the interaction between orchestration hub and the central database.

The flow on the right is the download client 12 process and the flow on the left is the interaction with orchestration hub 9c.

Step del, the user logs into the download client 12 with username and password. Step h61, orchestration hub 9c receives request to authenticate username and password. Step h62 orchestration hub 9c checks database to validate username and password. Step h63, if the username and password is not valid the user is taken back to the login screen del . Step dc3, if this is the first time the user has logged into the download client 12 they will have to set up the parameters/settings. Step dc5, the user selects the format they would like to receive for use in their PMS / CIS 10 (practice management system, clinical information system), i.e. HL7 or PIT. Step dc6, the user enters in the path or directory to where the files are to be downloaded.. Step dc7, the user enters in polling time (the intervals when the download client 12 checks for new reports). Step dc8, the settings is stored in a XML settings file and sent to orchestration hub 9c for upload. Step h64, orchestration hub 9c, receives file and stores it in the database. This completes the set up for the download client 12. If the user has logged in and set up their parameters previously, the application will download the XML setting file and check the follow parameters; format, directory path, polling time.

Step del 3, based on polling time, the download client 12 sends regular request for all new reports to be downloaded in the required format, i.e. HL7. Step h67, orchestration hub 9c, receives request and checks database for any new reports for the specified user. If there are reports available for download, orchestration hub 9c will generate the reports in the specified file format as detailed in the XML setting file. I.e. into HL7 files. Step h71, orchestration hub 9c, sends the reports in the required format to the download client 12. Step dcl4 the new files are downloaded into the specified file directory. The download client 12, then generates an acknowledgment that the file/s have been delivered. This acknowledgment is then sent to orchestration hub 9c, for insertion into the database, and so form part of our audit trail whereby we monitor which reports have not been downloaded. The specified files are picked up by the PMS / CIS 10 for local integration into the patient record.

Figure 2 is a block diagram illustrating the functions and components of the central server module 9 and the connections, processes and tasks performed between orchestration hub, web Services, business object classes, the database and third party components within the architecture.

The central server module 9 has three major components: data repository 9a, which is located on the database server, orchestration hub 9c, which is located on the central server and the web application 9b, which is located on the web server. The mc1 database server houses the Medinexus data repository 9c / mc2. The data repository 9c / mc2 has a database for managing and storing configuration settings called CONFIG mc3, a database for managing and store data called DATA mc4, and a database for managing and storing media such as files, and logos, called MEDIA mc5. The data repository 9c, also stores the medical images in the File Directory mc5. The database does not connect to the global computer network 19 at all. This is to facilitate improved security.

The web server mc6 houses the web application mc7. The web application mc7 connects to the global computer network 19, via HTTPS with 128 bit encryption and also connects to the database server mc1 and the data repository mc2 to access data.

The orchestration hub server mc9 consists of three major components: HTTPS mc12, web Services mc11 and business object classes mc10. orchestration hub 9c manages the connections via a secure connection (HTTPS) between the medical reporting client 8, and the download client 12, via the global computer network 19 to the central server module 9. orchestration hub 9c enables these applications seamless connection the data repository 9a. orchestration hub 9c connects to the global computer network 19, via a secure HTTPS (hypertext transfer/transport protocol secure) with 128 bit encryption and also connects to the database server mc1 and the data repository mc2 to access data.

The web Services Layer mc11 is the component that is designed to support interoperability between HealthTalk Business Objects me 10 and the other applications such as the medical reporting client 8, and the download client 12.

The business object classes mc10, are many small components or objects (within object- oriented software) that abstract the business entities. The object classes functions and serves purpose to running specific processes for the medical reporting client 8, and the download client 12 from The central server module 9. to provide a distributed architecture model that enables a robust and interoperable solution. There are many business object classes that are used within the orchestration hub. They include: clsAssemblylnfo - - this class manages the components that are assembled at the client side, (i.e radiology practice) cIsAddress - this class manages the creation, collection and access to address data and the connection to the data repository 9a for this entity. clsAdminReport - this class creates administration data such as error logs. clsAgreement - this class manages the access and registration to patient and doctor agreements and the connection to the data repository 9a for this entity. cϊsBusinessAttribute - this class manages the attributes within each of the business entity (i.e Radiology practice or Cardiology clinic), Attributes include formats, system interfaces, etc. clsBusinessObject - this class manages the orchestration of the different business objects within orchestration hub 9c. clsBusLogic - this class manages the business logic of each business entity. (That is, the processes of a radiology practice or Cardiology clinic). clsCertificate - this class manages the profiles of digital certificates and digital signatures. It manages such information as certificate authority, and class of the certificate, and this class also manages the digital signing of data. clsCountry - this class manages data relating to the country of the entities, such as patients, doctors, facilities, etc and the relationship to other demographic data, such as the format of address or phone numbers. clsDefaultFacility - this class manages doctors preference and selection of a default facility and the rules associated with default facilities. clsDoctor - this class manages the creation, collection and access to doptors data and the connection to the data repository 9a for this entity. clsDoctorDirectory - this class manages the doctors data to provide a directory service of the doctors on the system, This is like a "yellow pages" service. clsEmail - this class manages the creation, collection and access to email data and the connection to the data repository 9a. This class also manages the communication component that enables emails via SMTP. clsExam - this class manages the collection and access to examination ids and data and the connection to the data repository 9a for this entity. Examination IDs can be used as another way to assign images and media to reporting information other then patient demographics. clsFacility - this class manages the creation, collection and access to facility information and the connection to the data repository 9a for this entity. clsFieldCollection - this class manages the collection of other field information that are do not have specific classes and the connection to the data repository 9a for this entity. clsGuardian - this class manages the creation, management and access to security roles within the system. (That is, operators can only perform certain tasks, and doctors can perform all tasks). clsHL7Adapter - this class manages the transfer, import, conversion and translation of HL7 files into XML and the Medinexus Schema. clsMedia - this class manages the transfer, import, and access, to Media such as

HL7 files, logos, .DOCs, and other files. clsOperator - this class manages the creation, collection and access to operators (practice Staff) data and the connection to the data repository 9a for this entity. clsOwner - this class manages the creation, collection and access to owners

(practice administrator, clinical partner) data and the connection to the data repository 9a for this entity. clsPassword - this class manages the creation, collection and access to passwords and usernames. clsPatient - this class manages the creation, collection and access to patient data and the connection to the data repository 9a for this entity. clsPerson - this class manages the creation, collection and access to person data. A person is the common data that is the same for a doctor, patient, operator/user. clsPhone - this class manages the creation, collection and access to the phone information such as work, home and mobile phone numbers, and manages the formats that these numbers are recorded and displayed. clsProfileTemplate - this class manages the templates associated with the profile of doctors and facilities. Each facility and their doctors have templates for displaying their reporting information. clsReport - this class manages the creation, collection and access to report data and the connection to the data repository 9a for this entity. cIsRequest - this class manages the process of electronic referrals and requests. clsSpeciality - this class manages the association of specialties to doctors and facilities. clsUserProfile - this class manages the profiles of the doctors. It manages functions such as the SMS and email alerts, display preferences, demographics, etc. clsViewReport - this class manages the function of viewing reporting information and images. clsWordAdapter - this class manages the transfer, import, conversion and translation of Microsoft Word (.DOC) files into XML and the Medinexus Schema. Licenses.licx - this component manages the licenses of the medical reporting client and the computers that are register to have this installed.

GlobalVariables - this component manages the global variables (the variables that affect all components of the system) of the Medinexus system ChiliKatDotNet Component - the Chilikat.Dot.Net component is a third party component that manages the creation of digital signatures and the process of digital signing.

Atalsoftdotlmage component - the Atalsoftdotlmage component is a third party component that manages the compression of images with the used of JPEG2000 technology.

Medinexus Objects Library - the Medinexus Objects Library is the library of all the Medinexus business objects.

An example of the logic process of this system is as follows:

A patient visits their GP (general practitioner) because the patient is complaining of having a sore wrist after falling over. The GP decides to refer the patient to a radiology practice/imaging facility with an imaging apparatus 1 to have an X-ray examination preformed to see if the patient has a fractured wrist.

The GP writes a referral for the patient to take to the radiology practice/imaging facility. The patient calls the radiology practice/imaging facility to make an appointment and/or they present at the radiology practice/imaging facility to have X-ray examination performed.

The patient particulars / personal information is captured onto the RIS system, from which a workflow is generated, and which may or may not pass information across to the PACS system.

The Patient is taken by the radiographer to the room where the X-ray apparatus 1 is located. The radiographer aligns the patient's wrists in front of the x-ray cassette and the X-ray apparatus then takes an X-ray image of the patient's wrist. The digital image is then stored as a DICOM file 5 in a specified, directory and within the PACS/IS system. The Radiologist then views the X-ray images and then dictates the patient report based on the diagnosis. The report is then typed into the radiology information system 3 by the typist. The radiology information system 3 then generates the report information into a HL7 4 file and saves it to a specified directory. The Medical Reporting Client 8 then checks the specified directory from the RJS system 3 for new HL7 reports 4. The Medical Reporting Client 8 then reads the file for data such as patient name, examination ID, doctor's name and converts the file to XML. The Medical Reporting Client 8 then queries the PACS/IS system 2's Image Query and Retrieve component for DICOM images 5 for the patient and examination ID found within the HL7 file 4. Once the DICOM images 5 are retrieved, they are then converted to JPG format.

One of the practice staff logs into the Medical Reporting Client 8, and then views the preliminary reports for the day. The report just created will be displayed within the preliminary report screen as detailed in screenshot 34. The practice staff then views the report and uploads it to the central server 9. The Radiologist then logs into the medical reporting client 8, and then views the report from the draft section of the application and checks the referring doctor's details, patient details, and ensures that the report is medically correct, and that the imbedded images are correct. The radiologist then digitally signs the report and images with their digital certificate i.e. HeSA smart card, which indicates that he has checked the content Then report with images is then completed. The medical reporting client 8 prompts the central server 9 to generate an email and/or SMS detailing that there is a report and images ready to be accessed on the web address where it can be accessed. These are sent to the referring GP. If requested, the GP/referrer receives either email or sms with a link to that report on the web. The GP/referrer can either select the link or type the link into a web browser 15. The GP/referrer is then prompted with the login screen of the web application 14. The GP/referrer then types in their username and password that was provided to them by the Radiology/Imaging facility. The GP/referrer is then taken to the current report screen that details all the current reports. (Current reports are reports that have not been viewed or reports that have been accessed on that day.) The GP selects the report that has just been sent to them by the Radiology/Imaging facility. The report and images is then displayed to the GP. The GP can then elect to zoom into the images for a better view, The process is now complete.

According to another preferred embodiment of the invention, which is not illustrated in the drawings, the process steps performed by the medical reporting client are split up and performed by a medical reporting client agent and a medical reporting client manager.

It is preferred that the medical reporting client agent is a service ("Windows Service") or daemon (Unix, Linux) installed on a server. It is preferred that the server is a dedicated server. It is also preferred that the medical reporting client agent operates automatically. It is also preferred that the medical reporting client agent performs image processing and data upload.

It is preferred that the medical reporting client manager performs the remaining process steps of the medical reporting client, such as: management of patients; management of doctors and other health care provider demographics: management of staff; report management and digital signatures pertaining to these reports.

It is further preferred that the medical reporting client agent and the medical reporting client manager both communicate with the central server system and not directly with each other.

According to yet another preferred embodiment of the invention, which is not illustrated in the drawings, there is a process of validating any data stored, transferred and accessed on a computer network comprising: a first step of creating hashes (digests) of the data; a second step of encrypting the hashes with a private key; a third step of storing the encrypted hashes of the data on a computer network along with the original data; a fourth step of accessing the original data and the encrypted hashes of the data; a fifth step of creating hashes (digests) of the accessed original data; a sixth step of decrypting the accessed encrypted hashes of the data with a public key; a seventh step of comparing the hashes of the accessed original data with the decrypted hashes of the data, and; an eighth step of accepting the accessed original data when the hashes (digests) match, or, rejecting the accessed original data when the hashes (digests) do not match.

It is preferred that the fourth, fifth, sixth, seventh and eighth steps are performed by a web browser with a plug-in to perform the fifth, sixth, seventh and eighth steps.

It is preferred that the data consists of a report and images. It is also preferred that the report and images are a single document.

While the present invention has been described with reference to a few specific embodiments, the description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications may occur to those skilled in the art without departing from the true spirit and scope of the invention as defined by the appended claims.

"Comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Claims

Claims:

1. A process of reporting the analysis of an image or the like, the process comprising: receiving at least one image that has been generated in an electronic form by an image generating facility; assembling the analysis of the at least one image together with the at least one image into a report; storing the report and the at least one image on a computer network; and sending a notification to a user that the report is available for accessing.

2. A process as claimed in claim 1 , further comprising the step of notifying an image analyst that the at least one image is available for analysis.

3. A process as claimed in claim 1 or claim 2, in which at least one of the steps of: receiving at least one image that has been generated in an electronic form by an image generating facility; notifying an image analyst that the at least one image is available for analysis; assembling the analysis of the at least one image together with the at least one image into a report; storing the report on a computer network; and sending a notification to a user that the report is available for accessing is performed automatically.

4. A process as claimed in any one of the preceding claims, further comprising the step of the analyst applying an electronic signature to the report before the user is notified that the report is available for accessing.

5. A process as claimed in any one of the preceding claims, in which the notification is sent by at least one of an email message and an SMS message.

6. A process as claimed in any one of the preceding claims, in which the report is available for accessing over a computer network.

7. A process as claimed in any one of the preceding claims in which the step of assembling the report automatically incorporates into the report additional data which is additional to the image data.

8. A process as claimed in claim 7, in which the additional data is data about the subject of the image,

9. A process as claimed in any one of the preceding claims in which: the subject of the image is a patient of a first healthcare practitioner; and the user of the report is a second healthcare practitioner,

10. A process as claimed in claim 8, in which the first healthcare practitioner and the second healthcare practitioner are the same.

11. A process as claimed in any one of claims 8 to 10, in which the additional data has been gathered from an information system of the first healthcare practitioner.

12. A process as claimed in any one of the preceding claims, in which any alteration to the report after it has been signed invalidates the electronic signature to the report.

13. A process as claimed in any one of claims 4 to 12, in which the step of applying an electronic signature to the report uses a PKI identity certificate.

14. A process as claimed in any one of the preceding claims, in which the report is available for accessing by using a cryptographically secured mechanism.

15. A process as claimed in any one of the preceding claims, in which the report is available for accessing by using a Web browser.

16. A process as claimed in any one of the preceding claims, further including the step of monitoring whether a report has been accessed by a user to whom a notification was sent.

17. A process as claimed in any one of the preceding claims, in which a user authorizes another user to access the report.

18. A process as claimed in any one of the preceding claims, further including the step of a user printing a report.

19. A process as claimed in any one of the preceding claims, in which at least two steps of the process are performed by different software programs.

20. Apparatus for reporting the analysis of an image or the like, the apparatus comprising: means for receiving at least one image that has been generated in an electronic form by an image generating facility; means for assembling the analysis of the at least one image together with the at least one image into a report; means for storing the report and the at least one image on a computer network; and means for sending a notification to a user that the report is available for accessing.

21. Apparatus as claimed in claim 20, further comprising means for notifying an image analyst that the at least one image is available for analysis.

22. Apparatus as claimed in claim 20 or claim 21 , in which at least one of the: the means for receiving at least one image that has been generated in an electronic form by an image generating facility; the means for notifying an image analyst that the at least one image is available for analysis; the means for assembling the analysis of the at least one image together with the at least one image into a report; the means for storing the report on a computer network; and the means for sending a notification to a user that the report is available for accessing performs automatically.

23. Apparatus as claimed in any one of claims 20 to 22, further comprising means for the analyst to apply an electronic signature to the report before the user is notified that the report is available for accessing.

24. Apparatus as claimed in any one of claims 20 to 23, in which the notification is sent by at least one of an email message and an SMS message.

25. . Apparatus as claimed in any one of claims 20 to 24, in which the report is available for accessing over a computer network.

26. Apparatus as claimed in any one of the claims 20 to 25, in which the means for assembling the report automatically furthercomprises means for incorporating into the report additional data which is additional to the image data.

27. Apparatus as claimed in claim 20 to 26, in which the additional data is data about the subject of the image.

28. Apparatus as claimed in any one of claims 20 to 27, in which: the subject of the image is a patient of a first healthcare practitioner; and the user of the report is a second healthcare practitioner.

29. Apparatus as claimed in claim 27, in which the first healthcare practitioner and the second healthcare practitioner are the same.

30. Apparatus as claimed in any one of claims 27 to 29, in which the additional data has been gathered from an information system of the first healthcare practitioner.

31. Apparatus as claimed in any one of the claims 20 to 30, in which any alteration to the report after it has been signed invalidates the electronic signature to the report.

32. Apparatus as claimed in any one of claims 23 to 31, in which the means for applying an electronic signature to the report uses a PKI identity certificate.

33. Apparatus as claimed in any one of claims 20 to 32, in which the report is available for accessing by using a cryptographically secured mechanism.

34. Apparatus as claimed in any one of claims 20 to 33, in which the report is available for accessing by using a Web browser.

35. Apparatus as claimed in any one of claims 20 to 34, further including means for monitoring whether a report has been accessed by a user to whom a notification was sent.

36. Apparatus as claimed in any one of claims 20 to 35, further comprising means for a user Io authorize another user to access the report.

37. Apparatus as claimed in any one of claims 20 to 36, further comprising means for a user to print a report.

38. Apparatus as claimed in any one of claims 20 to 37, comprising at least two computers.

39. A process as claimed in claim 19, in which each software program is running on a different computer.