Iteration 1 Architecture

This wiki page describes the architecture for Iteration1 of the SCOOP project.

Context

The architecture context is basically the same as the previous iteration although the way that this is realized has changed.

/iteration1/images/architecture/IT1-Context.png

This iteration is being deployed to a laboratory environment (non production) at UVic.

There is only one practice being simulated in this iteration (i.e. one endpoint).

Logical View

/iteration1/images/architecture/IT1-Systems.png

There are a number of architectural changes planned for this iteration of SCOOP.

1. We are enhancing OSCAR to export the patient summary document, either for a single individual or by batch for all individuals with a record in the EMR

2. The data transfer format will be an emerging Canadian standard, the E2E developed by the BC PITO program. It is an HL7 CDA-based XML document. Because we are enhancing an open source Canadian EMR – it only makes sense to support a Canadian standard.

3. The middleware (Mirth) will play a much smaller role in this design. It will simply transfer individual summary documents between the EMR and the hQuery Gateway. It will not perform any aggregation or transformation.

4. hQuery Gateway will be enhanced to support the import of E2E patient summary documents. This is not a complex change because it is CDA-based and extremely similar to the already supported C32 document.

Constraints

Privacy Individual information never leaves the practice. Early feedback from discussions with the faculty physicians UBC highlighted their stewardship of patient information as a serious matter. There’s a genuine concern that anonymous data collected may be used for unintended research purposes in the future. Several are concerned by the risks of data aggregation, even when the data is de-identified.

Open Source As SCOOP development is sponsored with public funds it will be released as open source for any one to use. In addition, SCOOP will only rely on free, open source components so that its use is accessible to any individual/group.

OSCAR In addition to being open source, OSCAR is the EMR used by many faculty physicians at UBC. A few of these faculty members will the initial SCOOP users. For this reason, OSCAR will be the first supported EMR.

Design View

Software design of the new export feature in OSCAR

/iteration1/images/architecture/IT1-Template-UML.png

We will attempt to stay true to the MVC design. Velocity based templating requires both a template and a data model. We have opted to make the Patient object draw on all the pre-existing DAOs and models and have Patient group up the relevant fields for easy velocity access. Most of the heavy code work will be found in E2EVelocityExport.java and DemographicExportAction4.java acts as the Event Handler and file management for the export function.

Software design for new hQuery enhancements

In order for hQuery to handle incoming E2E documents, its import library Health Data Standards had to be updated. We created a new E2E section of the import code and modeled it as closely as possible to the existing C32 importer code as that both E2E and C32 are both CDA documents and share similar document design. Updating this library alone would be sufficient enough to populate its database with the required information.

Query Design

Since hQuery follows the map-reduce paradigm for gathering and returning results, we will also be mapping and reducing with design.

Map

The goal here is to emit every result in which there is a patient that is over a specified age limit, drug limit during a specified date in time. This is done by checking if the specified time is between the start and end date for each drug. If it is, and there are more of these drugs for one patient than the specified drug limit, and the patient is older than the age limit, we expect to have this patient be mapped in the results.

To deal with the potential overcounting of drugs, for each patient we store an array of all drug codes (in this case DIN numbers) that are encountered. Should we encounter the same exact drug again within our search, it will skip over that when adding together the total amount of current active drugs a patient has. Below is the Javascript query for the map phase used in hQuery.

function map(patient) {
  var ageLimit = 65;
  var drugLimit = 5;
  var time = new Date();

  var drugList = patient.medications();
  var currentDrugs = findCurrentDrugs(drugList, time);

  emit('total_population', 1);
  if (patient.age(time) > ageLimit) {
    emit('sampled_number', 1);

    // Adds patient to count if over ageLimit & over drugLimit
    if (currentDrugs > drugLimit) {
      emit('polypharmacy_number', 1);
    }
  }
}

// Returns count of "active" drugs that are between start & end date
// Also checks for the same "active" drug and doesn't overcount
function findCurrentDrugs(drugs, time) {
  var now = time.getTime();
  var count = 0;
  var seenDrugs = [];

  for(var i = 0; i < drugs.length; i++) {
    var repeat = false;
    var drugStart = drugs[i].indicateMedicationStart().getTime();
    var drugEnd = drugs[i].indicateMedicationStop().getTime();

    // Check if drug is within the right time
    if(drugEnd >= now && drugStart <= now) {
      // Check if this entry is a repeat of same drug (codesystem agnostic)
      var codes = drugs[i].medicationInformation().codedProduct();

      for (var j = 0; j < codes.length; j++) {
        var code = codes[j].code();

        if(seenDrugs.indexOf(code) == -1) {
          seenDrugs.push(code);
        }
        else {
          repeat = true;
        }
      }

      // Increment count if not a repeat
      if(!repeat) {
        count++;
      }
    }
  }
  
  return count;
}

Reduce

The goal here is to gather all the emitted data from the map phase and sum them together in each respective category to yield a useful answer to the researcher. This is done with a straight-forward summation function. Below is the Javascript query for the reduce phase used in hQuery.

function reduce(key, values) {
  var result = 0;

  while (values.hasNext()) {
    result += values.next();
  }

  return result;
}

Data View

Introduction to E2E E2E, or EMR to EMR, is a CDA specification being developed by BC's PITO organization. Its main purpose is to create a standard in which EMR data can be transmitted to other Canadian EMRs in a standardized way.

Overview of E2E sections (including image)

Scope of content for Iteration 1 In order to sufficiently answer our polypharmacy question, we would require demographic information such as name and age of birth, as well as all current medication data. The medication data required would be when it was prescribed, how long its duration is, and what drug it is. Information such as the name and what type of drug would only be used for differentiating between records and to prevent overcounting and would not be a factor in the results of the query.

Technology Selection

OSCAR An Open Source EMR system used by many private physicians. This is way that individual information is captured - and the user interface for the physician practitioner end user.

Mirth Mirth is an open source interfacing system. It acts as generic middleware between many healthcare software systems and connects them via HL7 messages (although several formats / protocols are supported).

Mirth Rest Adaptor This is an open source piece of middleware developeed by the SCOOP project. Mirth does not fully support restful web services. Specifically it does not allow naming of attachments to web service calls. For this reason, hQuery gateway cannot find the patient summary document when Mirth calls it directly. This component can be thought of as a restful web service relay that renames a single attachment (patient summary document) before forwarding the call.

hQuery Gateway The query gateway is a web based application that provides the back end for executing queries. The query gateway which exposes a query API, accepts queries, runs those queries against the patient data, and returns the results of the query back to the query composer.

hQuery Composer The query composer is a web based application that provides the front end for creating, managing, and executing queries. Those queries are executed against the query gateway which exposes a query API, accepts queries, runs those queries against the patient data, and returns the results of the query back to the query composer.

Scoop Endpoint refers to all the non-emr SCOOP software components that will reside at a practice in the future. This indludes hquery gateway, Mirth, and Mirth Rest adapter.

SCOOP Hub This is the application that the researcher uses to ask a "question" of the Research Network. This includes features for query management, policy enforcement, privacy management, and security. Currently, hQuery composer is the only software system in the hub - but more design and enhancements are needed.

• Libraries: template