Past Research

Mobile Support

Objectives

The goal of this research was to create a mobile CDSS - the MET system - for supporting triage of children presenting to the ED with various types of acute pain. The MET system had to:

  • Provide structured evaluation of the patient's condition, electronic data capture, and triage recommendations directly at the point of care;
  • Seamlessly "follow" the EP moving from patient to patient and from one clinical presentation to another;
  • Integrate with hospital information systems to store and retrieve basic demographic and clinical data.

The EP using the MET system enters information about patient's clinical attributes (patient's history, physical examination and the results of tests), and she/he can call the support function to receive a triage recommendations together with their relative strengths. The system recommends whether the patient needs a specialist consult, requires further investigations/observation, or is dischargeable to the care of the family physician. The triage support function can be invoked at any time, irrespective of the amount of information about the patient's condition that is currently available to the system.

The logical structure of the MET system follows the ontology-driven design with separated knowledge and generic problem solving methods (solvers). The first generation of the MET system -- MET1 -- included modules for abdominal pain and scrotal pain. MET1 with the abdominal pain module (MET1-AP) was prospectively evaluated during a clinical trial in the ED of Children's Hospital of Eastern Ontario in Ottawa, Ontario, Canada. This was one of the very first extensive clinical trials to evaluate the use of decision support technology in a real clinical setting. The second generation of the system -- MET2 -- was extended to take full advantage of the ontology-oriented design and included ontological models of a complete system. This research resulted in a multi-platform and multi-problem (abdominal pain, scrotal pain and hip pain) environment, able to seamlessly run on the web, a desktop computer or a mobile device (handheld or tablet computer).

Clinical Problems

Abdominal Pain

Abdominal pain in childhood is a common but challenging problem for ED personnel. While some patients have serious conditions requiring admission or surgery, most have benign causes. Symptoms frequently resolve without complication before a cause is found so that a definitive diagnosis is not possible during the ED visit. In these cases, choosing the correct triage plan in an efficient manner is an important proxy to determining a future definitive diagnosis. For the majority of such patients where the diagnosis of appendicitis is in doubt, investigations and repeated assessments conducted by different physicians are time consuming and may be painful. There is empirical evidence that highlights an obvious advantage of the rapid triage of patients with abdominal pain. However, the central difficulty of such triage is accurate initial assessment based on a limited number of clinical symptoms and signs (attributes) that in combination contribute the most to the definitive management.

Hip Pain

Pediatric hip pain is associated with musculoskeletal disease and maybe caused by numerous underlying mechanisms that are benign or potentially very serious. The clinical conditions associated with hip pain are: acute transient synovitis (ATS), Legg-Calve-Perthes disorder (LCPD), septic arthritis (SA), and slipped capital femoral epiphysis (SCFE). ATS is a self-limited inflammatory condition that for most children resolves within a few weeks of the onset of symptoms. LCPD is a disorder of the femoral head with the surgical or non-surgical treatment focused on femoral head containment. SA, also known as infectious arthritis, is a serious infection of the joints, and it is considered a medical emergency because of the damage it causes to bone and cartilage and a potential to create septic shock. SCFE is a disorder of the growth and development of upper femur and immediate treatment of SCFE is mandatory, with surgery being often the preferred method of treatment. The ED triage of the pediatric hip pain involves rapid identification of SA or SCFE first, followed by the LCPD.

Scrotal Pain

The acute scrotum (scrotal swelling and/or pain) in boys and adolescent males is typically first assessed by EPs. The usual causes of acute scrotum are torsion of a testicular appendage, testicular torsion, or infection of the testis/epididymis. True testicular torsion is a surgical emergency, with a limited window of opportunity of 4-12 hours from the onset of pain to make the diagnosis and untwist the spermatic cord in order to salvage the testicle. Triage of testicular torsion can be difficult clinically, and given the limited window of opportunity, surgical consultation occurs frequently. Historically, management of acute scrotum involved emergent surgical exploration, especially if there was any diagnostic uncertainty. With the advent of such tools as the nuclear medicine testicular flow scan and color Doppler Ultrasound, a more discriminating approach has become the norm. Experience has proven that these modalities are imperfect and cannot replace clinical acumen.

Architecture

The MET system was based on the paradigm of extended client-server architecture, suited for weak connectivity (infrequent wired or wireless connections between clients and a server). MET1 was designed for a homogeneous mobile platform (handhelds) and MET2 extended this functionality to a set of heterogeneous platforms (desktops and different types of mobile devices).

MET1 - the 1st Generation of MET

According to the MET1 architecture the server hosted the temporary database with data of patients currently processed by the system and the clinical modules for each specific pain presentation. Each module contained an ontology with the domain model (detailed specification of clinical attributes used for a presentation and instructions how to create the customized user interface) and the decision model (knowledge necessary to make triage decisions for this presentation). The server was also responsible for providing appropriate modules (required to provide support for evaluating the patients currently in the system) to the clients.

Architecture of MET1
Architecture of MET1

The modules were executed on the client by the executor. First, the executor created and customized the user interface using the information from the domain model and components from the interface repository. Then, it managed the interactions with the EP, stored data in the local database and used the solver to process the clinical decision model in order to generate triage recommendations.

MET1 was sufficient for uniform computing platforms and uniform clinical problems, however, the requirement of ubiquitous support on diversified computing platforms (like handhelds and desktops) led to MET2.

MET2 - the 2nd Generation of MET

In MET2 the system's functionality was distributed between the server and the clients, but the server takes a more active role. It creates customized modules for specific clinical problems and specific client platforms, links them with appropriate interface components and a solver, and transmits such customized package to the clients.

Architecture of MET2
Architecture of MET2

Clinical modules are replaced by clinical models comprised of ontological models describing the domain of a problem, the knowledge necessary to solve it, the user interface, and the solver. The last two models are platform independent, i.e., they do not have implementation details specific for each platform. The server also hosts the platform models with detailed descriptions of all supported client platforms.

When a specific clinical support is required (for a specific clinical presentation to be processed on a specific platform), the renderer retrieves the appropriate clinical and platform models and creates a platform-specific clinical module. It customizes the user interface according to the interaction capabilities of the target platform. Depending on the processing power of the platform, it also "tweaks" the decision model and the solver, so more powerful platforms would use more sophisticated and better solvers. Then, the module is passed to the integrator that combines it with necessary platform-specific components from the interface and solvers repository. Finally, the whole "package" is sent to the client.

Compared to MET1, the client in MET2 is simplified -- it only contains the executor and the local database. Other necessary elements are included in the "package" received from the server and they are purged when not used. The "receive-run-purge" cycle allows MET2 to provide complex and sophisticated support on lean client platforms.

Screenshots

The MET system was designed to be used in the ED and it has to integrate with the clinical workflow. Thus, it involves man-machine interactions that are quick and easy to follow, allowing the EP to continue his/her management routine without unnecessary external interference. The users of the MET system are familiar with filling out paper charts, evaluating patients, and interpreting the results of the tests rather than with operating a computer. In order to tailor the interactions to the EPs' needs, we used domain-specific metaphors to represent the interface objects and actions.

Pictures below present MET1 and MET2 screenshots from different computing platforms. In order to get a larger image, click on the picture.

MET1 – the 1st Generation of MET
MET1: Accessing main functions on Palm
Accessing main functions (Palm)
MET1: Entering pain location on Palm
Entering pain location (Palm)
MET1: Entering pain duration on Pocket PC
Entering duration of pain (Pocket PC)
MET1: Providing triage recommendation on Pocket PC
Providing triage recommendation (Pocket PC)
MET2 – the 2nd Generation of MET
MET2: Entering values of attributes on Pocket PC
Entering values of attributes (Pocket PC)
MET2: Entering values of attributes on Tablet PC
Entering values of attributes (Tablet PC)
MET2: Entering values of attributes on OS X
Entering values of attributes (OS X)