GB2539561A

GB2539561A - Mobile health units

Info

Publication number: GB2539561A
Application number: GB1608014.5A
Authority: GB
Inventors: Scott Brendan; Story Alistair; Lawrence Stan; Haggar Lewis; Porter Michael
Original assignee: University College London Hospitals NHS Foundation Trust (UCLH)
Current assignee: University College London Hospitals NHS Foundation Trust (UCLH)
Priority date: 2015-05-07
Filing date: 2016-05-09
Publication date: 2016-12-21
Also published as: GB201507824D0; WO2016177989A1; GB201608014D0

Abstract

A mobile, vehicular health unit (MHU) has an electronic or computerised healthcare modality system such as an X-ray, MRI, ultrasound or CT system. Also provided is a processing system connected to the modality system, and a data transmission system connected to the computer system. The processing system is configured to generate patient records by means of providing a workflow management system, which assigns an identifier to a patient and processes the user through data capture stages, one of which is a patient information stage and another of which is a modality capture stage. A single folder or record is generated containing information from both stages, which is stored locally and also uploaded to a remote location such as clinic 11 or the MHU office 9. Radiation shielding may be provided in the MHU and the data may be erased from the local storage system according to a predetermined condition.

Description

Mobile Health Units

Field of the Invention

The present invention relates to Mobile Health Units (MHUs), 5 particularly MHUs having a computerised method and system therein.

Background of the Invention

In recent years, health service providers have invested much time and money in computer systems to make the provision of information, including up-to-date patient information and test results, more readily available, and in a secure manner to meet the appropriate regulatory requirements.

In the field of radiology, procedures using photographic many countries been replaced patient records.

for example, traditional X-ray film and paper with digital records have in X-ray images and It has been proposed, in the UK at least, to provide MHUs for performing off-site radiology screening in a convenient manner. For example, tuberculosis (TB) is a condition that tends to exist amongst certain groups, including homeless people, who are more susceptible to such conditions and less likely to make regular visits to a doctor or hospital. MHUs offer a way of enabling these groups to receive in a convenient way screening, treatment and/or advice or referrals to specialist facilities. It will however be appreciated that other forms of screening and assessment may be performed at MHUs.

A particular problem exists in MHUs in terms of capturing the required data, including screening results, and accurately providing the resulting data to the existing healthcare infrastructure for up-to-date record keeping, and handling onward care.

Summary of the Invention

A first aspect of the invention provides a mobile health system, comprising a vehicle which comprises: an electronic or computerised healthcare modality system; a processing system connected to the modality system; and a data transmission system connected to the computer system, wherein the processing system is configured to generate patient records by means of (a) providing a workflow management system configured in use to: (1) assign an identifier to a patient; (ii) process the identified user through a predetermined plurality of data capture stages in a predetermined order, at least one of which is a patient information stage, and another of which is a modality capture stage; (iii) at the or each patient information stage, receiving user-input data and creating a patient information file storing the received data in association with the patient identifier; (iii) at the modality capture stage, transferring the patient identifier to the external modality system and receiving 25 therefrom one or more modality data files containing the patient identifier and modality results; (iv) generating a single folder or record containing the patient information file and the modality data file(s) for the same patient identifier; (v) storing each said folder on a local storage system; and (b) automatically uploading using the transmission system the or each said folder held on the local storage system to a remote storage system.

The modality system may be one of an X-ray, MRT, ultrasound or CT system.

The modality data files may be DICOM files corresponding to one or more images generated by the modality system. The DICOM files may be generated in a vendor-neutral format.

The vehicle may be arranged into a plurality of separate compartments, one of which is a modality compartment housing the 10 modality system, one or more walls of said compartment being provided with radiation shielding.

The processing system may be further configured to erase data from the local storage system responsive to a predetermined condition. The processing system may be configured to erase data from the local storage system responsive to a logging-out or power-down instruction.

A second aspect of the invention provides a system, comprising: an electronic or computerised healthcare modality system; a processing system connected to the modality system; and a data transmission system connected to the computer system, wherein the processing system is configured to generate patient 25 records by means of: (a) identifying a user; (b) capturing user information in a first data file; (c) receiving from the modality system one or more modality files generated thereat for the identified user; (d) providing a single patient record for the identified user, storing both the first data file and the one or more modality files; (e) storing the patient record on a local storage system; and (f) transmitting by means of the data transmission system a copy of the patient record to a remote storage system.

The system may be provided as part of a vehicular mobile health clinic, wherein the processing system is configured to transmit the patient record over a wireless data link.

A further aspect provides a method of generating patient records at a mobile health unit (MHU) which comprises an electronic or computerised modality system, the method comprising:(a) providing a workflow management system configured in use to: (i) assign an identifier to a patient; (ii) process the identified user through a predetermined plurality of data capture stages in a predetermined order, at least one of which is a patient information stage, and another of which is a modality capture stage; (iii) at the or each patient information stage, receiving user-input data and creating a patient information file storing the received data in association with the patient identifier; (iii) at the modality capture stage, transferring the patient identifier to an external modality system and receiving therefrom one or more modality data files containing the patient identifier and modality results; (iv) generating a single folder or record containing the patient information file and the modality data file(s) for the same patient identifier;(v) storing each said folder on a local storage system; and (b) automatically uploading each said folder held on the local storage system to a remote storage facility.

The modality system may be one of an X-ray, MRT, ultrasound or CT system.

The modality data files may be DICOM files corresponding to one or more images generated by the modality system.

The DICOM files may be received in a vendor-neutral format.

The method may be performed on a computer system housed within a vehicle, arranged into a plurality of separate compartments, one of which is a modality compartment housing the modality system, one or more walls of said compartment being provided with radiation shielding.

The method may further comprise the step of erasing data from the local storage system responsive to a predetermined condition.

The step of erasing data from the local storage system may be made responsive to a logging-our or power-down instruction.

A further aspect of the invention provides a method of producing 20 patient records in a vehicular healthcare facility which comprises a computerised modality system, the method comprising: (a) identifying a user; (b) capturing user information in a first data file; (c) receiving from the modality system one or more modality files generated thereat for the identified user; (d) providing a single patient record for the identified user, storing both the first data file and the one or more modality files; (e) storing the patient record on a local storage system; and (f) transmitting by means of the data transmission system a copy of the patient record to a remote storage system.

A further aspect of the invention provides a non-transitory computer-readable storage medium having stored thereon computer-readable code, which, when executed by at least one processor, causes the at least one processor to perform a method, comprising: (a) providing a workflow management system configured in use to: (i) assign an identifier to a patient; (ii) process the identified user through a predetermined plurality of data capture stages in a predetermined order, at least one of which is a patient information stage, and another of which is a modality capture stage; (iii) at the or each patient information stage, receiving user-input data and creating a patient information file storing the received data in association with the patient identifier; (iii) at the modality capture stage, transferring the patient identifier to an external modality system and receiving therefrom one or more modality data tiles containing the patient identifier and modality results; (iv) generating a single folder or record containing the patient information file and the modality data file(s) for the same patient identifier;(v) storing each said folder on a local storage system; and (b) automatically uploading each said folder held on the local storage system to a remote storage facility.

The term 'modality' refers to a method or system for application of, or employment of, any therapeutic agent. In this context, a modality can extend to any medical imaging or Point of Care Testing machine, including not only X-rays but also Magnetic Resonance Imaging (MRI), ultrasound and Computerised Tomography (CT) even if these do not have any direct therapeutic effect.

Brief Description of the Drawings

The invention will now be described, by way of non-limiting example, with reference to the drawings, in which: Figure 1 is a schematic block diagram of a system including mobile health units (MHUs) according to the invention, and associated systems including cloud storage; Figure 2 is a schematic block diagram of a MHU data system according to the invention, located with the or each MHU 10 indicated in Figure 1; Figure 3 is a flow diagram indicating stages in a MHU workflow, as implemented on the MHU data system of Figure 2; Figure 4 is a schematic diagram showing functional software blocks of a workflow management system according to the 15 invention provided on the MHU data system; Figure 5 is a flow diagram showing the high-level process for creating patient records; Figure 6 is a screen capture of a questionnaire group page, provided as part of the workflow management system of an embodiment of the invention, which is also useful for understanding operation; and Figure 7 is a partial perspective view of an example MHU comprising a vehicular clinic arranged into compartments and including a modality rooms.

Detailed Description of Preferred Embodiment(s)

Embodiments herein provide computer systems forming part of a mobile health unit (MHU), and other computer systems associated with integration of the MHU with a health service organisation 30 and affiliated systems and services, for example a MHU control office. It will, however, be appreciated that such computer systems can be employed in, or for use with, other mobile units outside the healthcare field.

In the context of this specification, a MHU is a mobile, vehicular-based assessment facility comprising all of the hardware and software required in the registration and testing of individuals, or patients. It is an example of a Point-of-Care Testing system (POCTs). Diagnosis of particular conditions can be made on-site, or made available securely to specific others, e.g. specialist clinicians, for follow-up consultations and treatment, if necessary.

In the specific example to be described, the MHU is a mobile radiology unit comprising of an X-ray machine for the screening of individuals for conditions such as tuberculosis (TB). An X-ray machine is an example of a modality, which generally refers to a method of application of, or employment of, any Therapeutic agent. In this context, a modality can extend to any medical imaging or POCT machine, including not only X-rays but also Magnetic Resonance Imaging (MRT), ultrasound and Computerised Tomography (CT) even if these do not have any direct Therapeutic effect.

The MHU has particular uses in the context of homeless people who are particularly susceptible to TB due to their living conditions. Homeless people are also unlikely to be formally registered with a health service provider for screening and diagnosis, and their location over time may change which will make tracing of their medical history difficult, for example if the individual presents themselves subsequently to hospital. MHUs may travel to many different locations, e.g. near to where homeless people congregate or sleep, so that screening can be performed in a manner that is convenient to them. The MHU can create a record of their visit, including taking of at least some personal details to enable identification, performing an initial clinical interview, performing the on-site scan, making an initial diagnosis or recommendation, providing treatment (if appropriate) and saving the data securely to a centralised system so that follow-up diagnosis and treatment by hospital based specialists can be performed on the patient.

Referring to Figure 1, an overall system 1 employing one or more MHUs 3 is shown. An MHU 3 is typically a van, having a series of partitioned areas or closed rooms, including areas for housing computer systems to be described, patient consultation areas and an appropriately furnished modality (X-ray) room with radiation protection. The MHU 3 is connected to a cloud-based storage facility 5 (hereafter 'cloud storage") through a secure wireless data link 7. The MHU 3 comprises a 3G/4G/WiFi interface and antenna for this purpose, making the transfer of data over the secure data link 7 possible regardless of location, provided the link can be established. Where no link is currently possible, each MHU 3 system is arranged to upload data when a link does become available, e.g. when the MHU travels into a location where there is connectivity. This is arranged automatically.

The cloud storage 5 is located in a secure data centre, and stores an identical or near-identical image of a local database created on the MHU 3 during a site visit, so that patient data and X-ray images are made available at a centralised, secure location, and also so that the data stored at the MHU can be erased subsequently at the end of a visit or day. This is important not only to make storage space available on the MHU's computer systems, but also to avoid sensitive data being acquired, e.g. if the MHU was stolen or security systems circumvented. Synchronisation between the MHU 3 and cloud storage 5 can be done in real-time or near-real time (e.g. following a 'save' or 'update' type operation for data entry at the MHU) provided the secure data link 7 is operational.

Also connected to the cloud storage 5 is a MHU office 9, which is a non-mobile computer system operated by a dedicated team. At the MHU office 9, a dedicated team of specialist clinicians may analyse the data being uploaded to the cloud storage 5, e.g. to answer specific questions raised by staff at the MHU, and even make diagnoses or recommendations based on X-ray images uploaded, preferably in a relatively rapid manner. The MHU office 9 can also forward referrals or specific questions to outside specialists, simply by sending the patient data by email, or through a plaintext link to the cloud storage 5. The MHU office 9 is also responsible for monitoring via wireless connectivity the status of MHUs 3, and particularly their computer systems, to identify issues such as technical faults and software issues. The MHU office 9 is also configured through its computer systems to provide regular updates of the software running at MHU systems over a wireless link. Such monitoring and updating of software can be performed via the cloud storage 5, or directly, not involving interaction with the cloud storage 5.

One or more clinics or hospitals 11 may also connect to the cloud storage 5 to view patient records and X-ray images. In this way, a patient attending a clinic local to them can inform their doctor of prior attendance at a MHU 3, and the doctor through information such as the patient name, date of birth and/or MHU location/date can identify the required record and call up the relevant information.

All data communication is preferably secured to the appropriate 30 level required for health care data, and typically will involve some form of SSL encryption, password protection and/or access being limited to particular domains.

Functional components of a MHU 3 are shown schematically in Figure 2. A server 21, which is typically a PC running a SQL server application, sits at the heart of the system and has its own terminal 23 comprising monitor and keyboard. Also connected to the server 21 are: (i) a modality terminal 25 associated with the modality system 27, in this case a proprietary X-ray machine; (ii) one or more other computer terminals 29; (iii) one or more portable computer terminals 31, e.g. tablets or laptops; (iv) a printer 33; (v) network accessible storage (NAS) 35; (vi) WEAN access point 37; and (vii) 3G/4G/WiFi access point 39.

Each of the server, modality terminal 25 and other computer terminals 29, 31 will comprise a processor/controller associated with RAM memory and non-transient memory, e.g. a hard-drive, storing and running an operating system (e.g. MS Windows Server) and other executable application(s). The RAM memory is for the temporary storage of data during program execution.

For example, the server 21 stores on non-transitory memory an executable workflow management tool (WMT) 41 computer program.

Advantageously, the WMT 41 is arranged to generate for each patient a single folder combining patient information, including information gathered from questionnaires as part of a healthcare workflow or pathway, and one or more X-ray image(s) obtained from the modality as part of a the workflow, so that both sets of information are available on the cloud storage 5 in the folder.

Traditionally, patient information is held in a so-called RIS system, and X-ray image data in a so-called PACS system, with there being no automated tie-up between the two systems. Here, the WMT 41 generates both sets of data as part of a defined workflow and automatically ties them together in the single folder for subsequent viewing.

RIS refers to a Radiology Information System, which generally comprises a computerised database for storing and distributing patient radiological data and imagery. PACS refers to a Picture Archiving and Communication System (PACS) which is a medical digital imaging technology which provides for efficient storage and access to images from modalities such as X-ray and CT machines, dispensing with the older practises of using photographic film housed in jackets.

PACS typically uses the Digital Imaging and Communications in Medicine (DICOM) standard. DICOM is a standard for handling, storing, printing and transmitting information in medical imaging. It includes a file format definition and a network communications protocol, which is an application protocol that uses TCP/IP to communicate between systems.

As mentioned RIS and PACS are typically implanted as separate 25 systems, requiring manual correlation between the RES and PACS information for given patients. A DICOM is typically written appropriate for a particular modality manufacturer.

The WMT 41 stored the server 21 herein is configured, when executed, to follow a predefined workflow, comprising a finite series of information-gathering steps (which may include sub-steps, and some of which may be conditional or dependent on the information gathered from other steps) which result in the creation of a medical record, or updated medical record, for the or each patient. In overview, the WMT 41 permits identification of the patient, and also generates to a single folder (record) information previously handled separately by RIS and PACS systems.

The workflow is implemented in a webpage, browser-based interface, presenting to an operator a series of information-gathering pages in a specific order, with in-built rules determining which subsequent windows/data input fields are presented. Where the rules determine that use of the modality is required or advised, e.g. an X-ray, then the WMT 41 works in conjunction with a modality terminal 25 (running its own modality interface), automatically passing some of the already-input patient data to the modality interface and thereby adding the patient to the modality schedule, commencing a PACs workflow.

In the present embodiment, the patient data transferred to the modality terminal 25 is a so-called DICOM ID, comprising one or both of a Patient ID and a Visit ID. Both are unique to the patient, and enable the output from the modality terminal 25, i.e. the X-rays, to be associated with the patient information gathered as part of the workflow and located in a single folder for the patient.

Following X-raying, the resulting image(s) are created and stored using a vendor-neutral DICOM standard (i.e. so as to be accessible and viewable by any application able to open.DCM files, and not limited to a specific modality manufacturer's viewer). The images are stored on the NAS 35. Subsequent workflow stages, if any, are completed, and the resulting file of patient information, e.g. medical questions, are stored as a text file, e.g. a RTF file, on the NAS 35.

The WMT 41 is also configured to automatically store the two related files, i.e. the.DCM file and the.RTF file, and possibly a.csv file, in this particular case, to a single folder having the DICOM ID. This can be done in real-time, or at the end of a clinic, i.e. when the WMT 41 is shut-down. This can be done locally, or at the cloud storage 5.

In this way, a single patient folder is created quickly and efficiently employing predefined, easy-to-follow stages, effectively combining RIS and PACs so that patient information is automatically made available to the modality and that that patient's image(s) from the modality are sent back within the workflow and added, or combined with, the patient record. This avoids errors or complications involved with, for example, accidentally omitting patients from a key part of the workflow, assigning images with the incorrect patient, and so on.

The operation of the WMT 41 will be explained in more detail later on.

Returning to the hardware overview, the internal network of the MHU 3 comprises both wired and wireless technology, e.g. using a 1GB Ethernet switch which connects the server 21 to the modality terminal 25, and also to the other terminal(s) 29, and to the NAS 35 which provides a local archive of patient records, as a backup. The WLAN access point 37 is configured to allow wireless access to the server 21 from tablets/laptops 31 being used in or around the MHU 3, e.g. during initial patient registration outside the MHU. Access to the WLAN is secure and limited only to the tablets/laptops 31 through known means. The server 21, as mentioned, runs a web server, and also a SQL database, and is configured only to serve web pages to the local network only, i.e. the terminal(s) 29 and the tablets 31. No general Internet access is permitted. Users access the server 21 via web browsers with application-level security requiring a log-in at first entry to the system. In this example, the server terminal 23 is used as an X-ray review workstation, and to the user, the interface will appear much the same as that presented to users of the terminal(s) 29 and tablets/laptops 31.

The terminal(s) 29 can be employed by staff conducting different stages, e.g. one for initial clinical interviews and one for private consultations.

Preferably, one of the terminal(s) 29 will be configured to act as a back-up to the server 21; that is, in the event of failure of the server 21 in the field, the back-up terminal 29 can be switched to act as the server 21, providing the same functionality and ensuring that patient records held on the NAS 35 are up-to-date. For this purpose, this back-up terminal 29 preferably comprises the same, or a similar, hardware and software set-up as the server 21. The server 21 and back-up terminal 29 are configured to back-up frequently across the system to the NAS 35, and to the cloud storage 5, to provide the most up-to-date picture of patient data in the event of failure. This 'fail over' is a manual, but could be an automated, process. In the event of failure of the server 21, a script is run which: (i) changes the IP address (but not the name) of the back-up terminal 29 to the IP address of the server 21; (ii) takes the database out of read-only recovery mode to operational status; (iii) starts the web services for the website to work.

This will then allow users to access the WMT 41 website and the website to access the database. After fail over, the system can be reset once the problem is resolved, involving migrating the database back to the server 21, resetting the IP address and disabling the web services on the back-up terminal 29, and enabling the web services on the server 21.

The 3G/4G/WiFi access point 39 is configured only to transmit and receive data to the cloud storage 5 using the available secure link 7. In some embodiments, access to the MHU 3 database may be permitted directly, i.e. without the need to access the cloud storage 5. This may be a secure connection to a health service network.

The printer 33 is provided for the output of information for MHU staff or visiting patients, e.g. to issue appointments/recommendation/referral letters or even prescriptions.

Referring now to Figure 3, the high-level operation of the WMT 41 will now be described. As mentioned, this is provided through a browser based interface of web pages and takes the example of the MHU 3 being a mobile X-ray clinic, although other forms of modality can be used.

In a first step 3.0, the operator will log-in to the WMT 41 to initiate the MHU 3 for that 'clinic'.

In step 3.1, the clinic is set up, involving the operator being prompted by the WMT 41 to input the details of the clinic, including date, time and location. In some embodiments this information can be detected and entered automatically, e.g. using GPO.

In step 3.2, a work list is set up. This may involve manually entering to the WMT 41 a list of patients to be seen, or importing a prepared work list file. This may be entered at one of the tablet computers 31. In certain situations, this can be combined with step 3.3.

In step 3.3, the WMT 41 prompts the operator to check-in a patient, i.e. a 'reception' stage, either based on the entered work list, or as part of creating a work list. This typically will involve prompting for, and receiving, name, date of birth, address, medical history, and marking them as 'in autendance'. At this point, a patient record or file is created, or an existing file updated. At this point, the DICOM IDs can be generated automatically.

In step 3.4, the WMT 41 prompts the operator to perform a patient clinical interview. This may be performed in a particular part of the MHU 3, e.g. a private area. The WMT 41 runs through a predefined, ordered set of questions relating to the patient's clinical details, e.g. history of chest pain, coughing, phlegm, and additional notes as required. The questions may be ordered in a hierarchy, with sub-questions prompted dependent on the entered responses. Radio buttons or drop-down menus are typically provided to constrain answers to questions, and provide filtering. A template can also be provided depending on answers given. The answers to the questions are added to the patient record.

In step 3.5, the WMT 41 transfers at least part of the patient record, e.g. the DICOM ID, to the modality terminal 25 for the taking of an X-ray. Thus, the patient's DICOM ID will appear in the X-ray schedule and any X-ray images created during step 3.5. are created using DICOM standards and sent back to the server and stored locally in the NAS 35. The modality interface running on the modality terminal 25, which may be proprietary, controls the creation of the images and how they are sent back to the server. The WMT 41 makes no modification to the images, other than to ensure they are of the.DCM file type.

In step 3.6, the WMT 41 presents the X-ray image(s) for review. 5 This review stage may be limited to a selected terminal, e.g. server terminal 23. Here, the operator, who may be a radiologist specially trained in this area, reviews the output on screen and makes an initial diagnosis, entered through the WMT. If the patient exhibits no signs of illness (negative) this may be entered to the WMT 41 which prompts a discharge condition whereby the patient record is completed and jumps to step 3.12, i.e. patient exit.

If a positive, or possible positive determination is made, the 15 WMT 41 moves to step 3.7 whereby a POCT test is performed for additional diagnostic view. In this case, a sputum sample is prompted to provide rapid diagnosis of possible TB. In step 3.8, the WMT 41 prompts for input of either a positive or negative outcome of the additional diagnostic test, or using a predefined super-set of result criteria that can be filtered according to POCT type in a drop-down box.

If negative, the WMT 41 jumps to step 3.12, i.e. patient exit. If positive, the WMT 41 moves to step 3.10 whereby a referral is made for treatment at a specialist clinic. This may add the patient to a list for follow-up at the MHU office 9, whereby the patient's record is added to a special list, members of which will be assigned an appointment time and will receive a letter confirming same shortly thereafter. The printer 33 may be used at this time to generate the letter or an advisory note to attend or follow-up. Step 3.11 may prompt the follow-up, e.g. at a later time or if the patient has been seen before. The WMT 41 them moves the step 3.12, i.e. patient exit.

If the outcome from step 3.8 is indeterminate, a remote consultation can be requested in step 3.9 if such a facility is available. This involves the WMT 41 either advising or prompting a while-you-wait diagnosis from a remote specialist, whereby the patient's DICOM image(s) are made available to the specialist via the cloud storage 5. A positive determination causes the WMT 41 to jump to the referral step 3.10; a negative determination causes the WMT 41 to jump to step 3.12.

After a patient exit, i.e. step 3.12 the process signs the patient out, possibly with a follow-up appointment and proceeds to the next patient, if there is one, until all patients in the list have been dealt with, at which time the clinic ends in step 3.13.

It will be appreciated that some steps can be re-ordered or omitted or replaced. Multiple patients can be handled in parallel, i.e. with multiple patients currently having a common status within the workflow. The end-result, however, is that the local NAS 35 stores a database of patient records, combining the RIS and PACS processes to generate for each patient a text file containing patient information, medical history and other data, and one or more image file(s) of the X-rays. The WMT 41 automatically ties these files together in a single folder, or patient record, with a common DICOM ID.

Referring to Figure 4, functional components provided on the server 21, including the WMT 41, are shown in more detail, and their interactions will now be described.

The WMT 41 is an application that interacts with a SQL database 43 to present the webpages in the required order. The SQL database 43 stores, for example, rules and questionnaires which dictate the workflow, what questions or information is/are prompted, and the general presentation of the webpages. This SQL database 43 can be updated periodically to change any feature of the webpages or indeed the application. For thts purpose, when the MHU 3 first starts-up at the beginning of a clinic, any update(s) placed on the cloud storage 5 by the MHU office 9 may be pushed to the server 21 for updating, prior to commencing the workflow. Alternatively, or additionally, updates can be performed in other ways, for example manually by remote login, and/or on-site updating using a memory card or USB drive that is connected to the server for uploading updates. Note, however, that answers or information gathered in response to old questions, will remain and are not overwritten.

The WMT 41, as mentioned, moves the patient through various stages to step 3.5 whereby an X-ray is required, following clinical interviews. The patient's up-to-date record for the current clinic is stored locally in the NAS 35. A data access layer (DAL) 45 acts as the interface between the WMT 41 and the database 43, updating the patient record as in the 'X-ray' state.

A modality interface 47 is configured to handle data requests and transfers between the server 21 and the modality terminal 25. For example, the modality terminal 25 will require a so-called C-FIND function to access a worklist for the modality. The operator of the modality terminal 25 will therefore issue a C-FIND command periodically.

The modality interface 47 receives this C-FIND request and uses the DAL 45 to find all patients in the X-ray' state in the current clinic, and returns them as a DICOM worklist. The radiographer takes the images at the modality and makes a C-STORE request using the modality workstation 25. The modality interface 47 is configured to accept such C-STORE requests and stores the images on a local file system 49, each having their associated DICOM IDs. The modality interface 47 also writes an application event which triggers a file copy to the NAS 35. On successful file write, the modality interface 47 uses the DAL 45 to update the patient's visit record to 'X-ray results' state (step 3.6). The patient will now appear in the next 1X-ray results' worklist. The radiographer, or other person, can now open and view the images, and record their diagnosis and complete the pathway, all from the WMT 41 website.

The patient files stored comprise only three file formats, which are DICOM (.dcm) for the X-ray images, comma-separated values (.csv) and rich text format (.rtf). This ensures that data is viewable in most freely-available text, database and image viewers, regardless of, for example, the manufacturer of the modality.

Referring to Figure 5, the high-level process for creating the individual patient records on the cloud storage 5 is shown, and can be applied to any form of modality. The process starts in step 5.1. In step 5.2, a patient ID is assigned, e.g. a DICOM ID. In step 5.3, the workflow is commenced. In step 5.4, if as part of the workflow it is determined that treatment or a scan is required using a modality, the patient ID is sent to the modality interface in step 5.6. In step 5.7 the patient ID is added to the modality schedule. In step 5.8 the modality is performed, e.g. an X-ray taken. In step 5.9 the results are generated. In step 5.10, the modality results, e.g. a DICOM file containing the DICOM ID, are sent back. In step 5.10 the modality file is saved to the NAS 35.

In parallel with the modality operating steps, in step 5.5 the workflow may continue, if further steps apply, and a patient information file is saved to the NAS 35, with the patient ID, in step 5.12. In step 5.13 the patient information file and modality file are combined into a single created folder, usually named with the patient ID. This is performed automatically. In step 5.14, the folder is mirrored to the cloud storage 5.

It will be appreciated that the patient information file may be 5 updated on the NAS periodically, and does not necessarily wait until the modality results are returned before updating.

Synchronisation to the cloud storage 5 is made whenever there is availability over the data link 7. Whatever is saved in the NAS 35, which can occur whenever new data is added at each stage of the process, are mirrored in the cloud storage 5, and similarly any files added to the cloud storage 5 for a patient record are copied down to the NAS 35 so that follow-ups reflect accurate and up-to-date information. The mirroring is therefore two-way. Alternatively, or additionally, the options for this push-to-cloud' can be: (i) automatic save to cloud upon manually saving to the NAS 35, if connected; (ii) automatic synchronisation once connectivity is restored; (iii) ability to manually trigger automatic synchronisation.

Ideally, excessive writes can be managed to ensure that only changed files are uploaded or downloaded.

Remote access to the cloud storage 5 is made possible from any Internet connected device with an internet browser, provided access rights are provided. This can be performed by providing an email to a user with a plain text folder path to a patient's record, i.e. the cloud folder. The user must, however, have a user account enabling access to the cloud storage 5 before they can access the folder path.

It will be appreciated that the WMT 41 works in association with a questionnaire, which at a high level is stored as data within the database 43 as a structure of questionnaires, questions linked to questionnaires and possible answers linked to questions. Questionnaire data is split into three sections to allow the system to be used in different multiple areas of the WMT 41 system, and for version control of questionnaires.

Object Parent Object Description

Questionnaire Group N/A -Top Level This determines which the questionnaire appears in, e.g. clinical interviews, POCT, etc. Questionnaire Type Questionnaire Group This determines the specific questionnaire in a group, e.g. basic clinical interview, advanced clinical interview, flu vaccination, etc. Questionnaire Version/Iteration Questionnaire Type This determines the specific version of a specific questionnaire.

This object is what questions belong to and is what is created every time a change or update to a questionnaire is made. The WMT will only show the most recent "marked as active" questionnaire version for each questionnaire type, e.g. "basic clinical interview v.1", "basic clinical interview v.2", etc. Rendering Questionnaire Groups Upon loading a "Questionnaire Pick Screen" the WMT looks up the Questionnaire Group for the current page. With this Questionnaire Group it can select all the Questionnaire Types to show, and for each Questionnaire Type, the most recent and "marked as active" Questionnaire Version is selected and shown on screen, for example, as shown in Figure 6.

Rendering Questionnaires Upon loading a specific Questionnaire Version, all questions and their possible answers are loaded. Each question is ordered by its sequence number and different HTML is outputted depending on the question's answer type. For example, if the question has a free text answer type then a free text field would be rendered; if the question has a radio button answer type then the questions possible answers are rendered as radio button options.

Figure 7 shows an example of a MHU 3 in the form of a vehicle 20 60 housing the components shown in Figure 2 and performing the functionality described in relation to subsequent Figures.

The vehicle 60 has a driver's cab 61 and a clinic section in the rear. The clinic section is accessed using one or more doors, and is divided into a plurality of compartments 62, 63, 64. One such compartment 62 is a modality room, namely a room in which the modality equipment such as an X-ray, MRI, Ultrasound or CT scanning machine is located. The walls, and preferably the floor and roof of the modality room 62 may be shielded, e.g. with lead screens or the like, to protect persons outside of the room from radiation when the modality is in use. The modality computer 25 may also be located within the modality room 62, but could also be outside.

The other rooms 63, 64 may be used for one or more of a waiting area, consultation area or the like. One of said rooms 63, 64 may contain the computer components shown in Figure 2, other 10 than the modality equipment.

It will be appreciated that the above described embodiments are purely illustrative and are not limiting on the scope of the invention. Other variations and modifications will be apparent to persons skilled in the art upon reading the present application.

Moreover, the disclosure of the present application should be understood to include any novel features or any novel combination of features either explicitly or implicitly disclosed herein or any generalization thereof and during the prosecution of the present application or of any application derived therefrom, new claims may be formulated to cover any such features and/or combination of such features.

Claims

Claims 1. A mobile health system, comprising a vehicle which comprises: an electronic or computerised healthcare modality system; a processing system connected to the modality system; and a data transmission system connected to the processing system, wherein the processing system is configured to generate patient 10 records by means of (a) providing a workflow management system configured in use to: (i) assign an identifier to a patient; (ii) process the identified user through a predetermined 15 plurality of data capture stages in a predetermined order, at least one of which is a patient information stage, and another of which is a modality capture stage; (iii) at the or each patient information stage, receiving user-input data and creating a patient information file storing 20 the received data in association with the patient identifier; (iii) at the modality capture stage, transferring the patient identifier to the external modality system and receiving therefrom one or more modality data files containing the patient identifier and modality results; (iv) generating a single folder or record containing the patient information file and the modality data file(s) for the same patient identifier; (v) storing each said folder on a local storage system; and (b) automatically uploading using the transmission system 30 the or each said folder held on the local storage system to a remote storage system.
2. A system according to claim 1, wherein the modality system is one of an X-ray, MRI, ultrasound or CT system.
3. A system according to claim 2, wherein the modality data files are DICOM files corresponding to one or more images generated by the modality system.
4. A system according to claim 3, wherein the DICOM files are generated in a vendor-neutral format.
5. A system according to any of claims 2 to 4, wherein the vehicle is arranged into a plurality of separate compartments, one of which is a modality compartment housing the modality system, one or more walls of said compartment being provided with radiation shielding.
6. A system according to any preceding claim, wherein the processing system is further configured to erase data from the local storage system responsive to a predetermined condition.
7. A system according to claim 6, wherein the processing 20 system is configured to erase data from the local storage system responsive to a logging-out or power-down instruction.
8. A system, comprising: an electronic or computerised healthcare modality system; a processing system connected to the modality system; and a data transmission system connected to the processing system, wherein the processing system is configured to generate patient records by means of: (g) identifying a user; (h) capturing user information in a first data file; (i) receiving from the modality system one or more modality files generated thereat for the identified user; (j) providing a single patient record for the identified user, storing both the first data file and the one or more modality files; (k) storing the patient record on a local storage system; and (1) transmitting by means of the data transmission system a copy of the patient record to a remote storage system.
9. A system according to claim 8, provided as part of a vehicular mobile health clinic, wherein the processing system is configured to transmit the patient record over a wireless data link.
10. A method of generating patient records at a mobile health unit (MHU) which comprises an electronic or computerised modality system, the method comprising:(a) providing a workflow management system configured in use to: (i) assign an identifier to a patient; (ii) process the identified user through a predetermined plurality of data capture stages in a predetermined order, at least one of which is a patient information stage, and another of which is a modality capture stage; (iii) at the or each patient information stage, receiving user-input data and creating a patient information file storing the received data in association with the patient identifier; (iii) at the modality capture stage, transferring the patient identifier to an external modality system and receiving therefrom one or more modality data files containing the patient identifier and modality results; (iv) generating a single folder or record containing the patient information file and the modality data file(s) for the same patient identifier;(v) storing each said folder on a local storage system; and (b) automatically uploading each said folder held on the local storage system to a remote storage facility.
11. A method according to claim 10, wherein the modality system is one of an X-ray, MRI, ultrasound or CT system.
12. A method according to claim 11, wherein the modality data files are DICOM files corresponding to one or more images generated by the modality system.
13. A method according to claim 12, wherein the DICOM files are 10 received in a vendor-neutral format.
14. A method according to any of claims 11 to 13, wherein the method is performed on a computer system housed within a vehicle, arranged into a plurality of separate compartments, one of which is a modality compartment housing the modality system, one or more walls of said compartment being provided with radiation shielding.
15. A method according to any of claims 10 to 14, further 20 comprising the step of erasing data from the local storage system responsive to a predetermined condition.
16. A method according to claim 15, wherein the step of erasing data from the local storage system is made responsive to a 25 logging-out or power-down instruction.
17. A method of producing patient records in a vehicular healthcare facility which comprises a computerised modality system, the method comprising: (g) identifying a user; (h) capturing user information in a first data file; (i) receiving from the modality system one or more modality files generated thereat for the identified user; (j) providing a single patient record for the identified user, storing both the first data file and the one or more modality files; (k) storing the patient record on a local storage system; and (1) transmitting by means of the data transmission system a copy of the patient record to a remote storage system.
18. A computer program comprising instructions that when executed by a computer apparatus control it to perform the method of any of claims 10 to 17.
19. A non-transitory computer-readable storage medium having 15 stored thereon computer-readable code, which, when executed by at least one processor, causes the at least one processor to perform a method, comprising: (a) providing a workflow management system configured in use to: (i) assign an identifier to a patient; (ii) process the identified user through a predetermined plurality of data capture stages in a predetermined order, at least one of which is a patient information stage, and another of which is a modality capture stage; (iii) at the or each patient information stage, receiving user-input data and creating a patient information file storing the received data in association with the patient identifier; (iii) at the modality capture stage, transferring the patient identifier to an external modality system and receiving therefrom one or more modality data files containing the patient identifier and modality results; (iv) generating a single folder or record containing the patient information file and the modality data file(s) for the same patient identifier;(v) storing each said folder on a local storage system; and (b) automatically uploading each said folder held on the local storage system to a remote storage facility.