Requirements
Background
openEHR - pronounced ‘open air’ - is an open specification for storing patient data used by clinicans and developers working in clinical contexts.
However clinical data are often messy and mixed up, and each clinical application had its own models, so moving data was very hard.
Everyone was building their models over and over again which kept causing problems. A new standard api to send models to but abstract data away from the database layer was needed.
Furthermore, this meant that only one CDR could be queried at once, which slowed down the work of the developers in the field.
Gathering Requirements
We were able to gather the requirements from the users through direct semi-structured interviews with both our users and our client by using Zoom.
Personas
The system will be used by developers who are working within the clinical field. We therefore created two personas -
an experienced developer who has been working in the clinical field for a long time, and a developer who has recently
transferred to the clinical field. They can be found in more detail in HCI.
Essential Features - Must Haves
Requirements |
Type |
Register CDR environment variables* |
Functional |
Support different CDR authentication requirements* |
Functional |
Execute AQL on multiple CDRs and display the result |
Functional |
Federate the result of AQL statement from multiple CDRs |
Functional |
Check consistency of result of AQL statement from multiple CDRs |
Functional |
Commit composition to multiple CDRs |
Functional |
Easy-to-use GUI for new users |
Non-Functional |
System must run smoothly without any noticeable lag |
Non-Functional |
- Register CDR environment variables
- Possibly import postman environment files
- Support different CDR authentication requirements
- Ethercis requires session tokens
- Marand ThinkEHR supports Basic authentication
Possible Features in the Future - Could Haves
Requirements |
Type |
Upload a template to multiple CDRs |
Functional |
List templates from multiple CDRs |
Functional |
Visualise tempaltes and archetypes - show data constraints |
Functional |
Generate AQL from interacting with template visualisation |
Functional |
Authentication to support multipler users |
Non-Functional |
Generation of AQL from interaction with templates |
Functional |
Use Cases
Use Case |
Logging In (UC1) |
Description |
User enters login details and clicks login button |
Primary Actor |
User |
Secondary Actor |
System |
Pre-condition |
None |
Main flow |
- User opens the app
- User enters his username
- Clicks button to go to main page and display CDRs
|
Post-condition |
None |
Alternative Flow |
None |
Use Case |
Add CDR (UC2) |
Description |
User adds a new CDR from addition page |
Primary Actor |
User |
Secondary Actor |
System |
Pre-condition |
User has logged on |
Main flow |
- User enters add CDR page
- User enters CDR details
- Clicks button to add the CDR
- CDR saved to the config file and a confirmation window pops up
- Change is reflected in the main page
|
Post-condition |
None |
Alternative Flow |
None |
Use Case |
Remove CDR (UC3) |
Description |
User removes a CDR from list by clicking the bin button |
Primary Actor |
User |
Secondary Actor |
System |
Pre-condition |
User has logged on and one or more CDRs exist in the list |
Main flow |
- User clicks on bin button next to CDR in list
- The CDR is removed from the configuration file
- Change is reflected in the main page
|
Post-condition |
None |
Alternative Flow |
None |
Use Case |
Query AQL (UC4) |
Description |
User inputs an AQL query and clicks on the query button |
Primary Actor |
User |
Secondary Actor |
System |
Pre-condition |
User has selected CDRs they wish to query from the list |
Main flow |
- User inputs AQL query into text box
- User clicks on the query button
- System processes and interprets the query
- Query result from the selected CDR(s) is returned as a JSON tree
|
Post-condition |
None |
Alternative Flow |
Error: 400 Bad Request (i.e. Incorrect AQL query) (UC4.1) |
Description |
AQL query was incorrect and system has failed to process the query |
Primary Actor |
User |
Secondary Actor |
System |
Pre-condition |
User has selected CDRs they wish the query from the list |
Main flow |
- User inputs AQL query into text box
- User clicks on the query button
- System processes and interprets the query
- System is unable to interpret the query as it is incorrect
- Error: 400 Bad Request is shown in the results box
|
Use Case |
Create JSON Table (UC5) |
Description |
User creates a table of results from the given JSON tree |
Primary Actor |
User |
Secondary Actor |
System |
Pre-condition |
User and system has successfully completed a query |
Main flow |
- User clicks on Create Table from JSON button
- System creates a table from the JSON tree
- The tree is displayed on a pop-up window
|
Post-condition |
None |
Alternative Flow |
None |