Iteration 3 Requirements

Overall system functional requirements are documented on the Feature List wiki page.

System Non-Functional Requirements

• Processes 10,000 individual records in a timely manner (e.g. less than one hour running after practice hours)

OSCAR Component Requirements

OSCAR is the test EMR supported for this iteration.

Functional Requirements

1. From within an individual's chart, user can export an individual patient summary record
2. Outside of an individual chart, user can export individual patient summary documents for all patients as a batch

Non-functional Requirements

1. Export format is HL7 CDA standard-based, specifically the "E2E" format created by the BC Physician Information Technology Office program.
2. For this iteration, E2E content sections must include all sections that are considered required for a minimally functional E2E document.
3. Export must perform in a timely manner - while a user waits (30 min / 10000 patients)
4. Export feature saves summary document(s) in a folder on the same workstation that the user initiated the request from.
5. Export format is customizable for users that adopt a different document standard.

Mirth Component Requirements

Mirth is the middleware component that loads the patient summary documents into the hQuery gateway. See IT3 Architecture for more details.

Assumption that this project will not implement new features (but may contribute minor bug fixes as needed). But because Mirth is a multipurpose tool, functional requirements are included to ensure that it supports SCOOP needs.

Functional Requirements

End users will not interact with Mirth on a frequent basis. It will be set up by a SCOOP project engineer and run on a schedule.

1. Mirth polls a folder location, grabs individual patient summary documents, and loads it into hQuery gateway via restful web service (via Mirth Rest Adapter), removes the patient summary document from the folder location after successful loading
2. End user can configure the location where OSCAR patient summary documents will be located after exporting.
3. End user can set the time of day that documents are processed
4. User can set the frequency of processing (in days)
5. Users can set the url of the Mirth-Rest-Adapter

Non-functional Requirements

1. Should process 10,000 patient records in less than 1 hour (presuming it operates during the night)
2. support polling of a directly location
3. support sending documents as an attachment to a rest web service API

Mirth Rest Adapter Component Requirements

The component is only necessary because Mirth randomly names an attachment to a rest web service call. hQuery expects the patient summary record as an attachment with a specific name.

Functional requirements

1. User sets the destination web service url
2. System accepts rest web service call, renames the attachment, and calls the specified destination web service url sending the newly named attachment

Non-functional Requirements

1. Component can accept calls as fast as Mirth can send them without any degradation in reliability.

hQuery Gateway Component Requirements

Assumption that this wiki page only outlines new features for hQuery Gateway.

Non-functional Requirements

1. Imports records in the E2E patient summary document format.
2. Component accept records as fast as Mirth processes them without degrading reliability.