d6 pilot registry of registries (ror) phase 1 development ......wireframe of the registry comparison...

D6 Pilot Registry of Registries (RoR) Phase 1 Development Report

WORK PACKAGE

WP4

DOCUMENT NAME

Pilot RoR Phase 1

Development Report

DOCUMENT VERSION

1.0

DATE 01/10/2013

PARENT RoR Functional Requirements Document

Version: 2.0

WP 4 Date:25/10/2013

2

Project Title Cross-border Patient

Registries Initiative

Project Acronym PARENT

PARENT Coordinator Matic Meglič, IVZ

Work Package Leader

Authors

Ivan Pristaš

Vanja Pajić

Tomaž Čebular

Mladen Kostešić

Work Package 4

Deliverable 6

Title Pilot RoR; Phase 1

Development Report

Version 1.0

Dissemination Level Public


Version: 2.0

WP 4 Date:25/10/2013

3

Change History

Version Date Status Changes Author Details

1.0 15/7/13 First version of document VP, TČ, MK

2.0 25/10/13 Formal review finished ExCo No significant

changes


Version: 2.0

WP 4 Date:25/10/2013

4

PARENT Pilot Registry of Registries (RoR), Phase 1 Development

Currently finishing Phase 1 of development, the PARENT RoR tool is envisioned as a Web portal to provide added value to patient registries across the EU in order to assist interested individuals to obtain reliable and up-to-date information about European patient registries’ metadata. The PARENT RoR will promote the more efficient use of resources in setting-up and managing patient registries. In Phase 1 of RoR development, we have decided to focus on three core functionalities that support registry browsing (or listing), registry advanced search (both by keyword and predetermined filters) and registry comparison by which multiple registries' components can be compared side by side.

(The details concerning PARENT RoR development are found in the Functional Specifications documentation available to project partners and EC)

PARENT RoR Background

The PARENT RoR is envisioned as a registry overview and search tool to provide a pilot listing of available registries on the EU level, to create a metadata repository for storing and cataloguing patient registry metadata of patient registries, enable sharing of comprehensive information on which data are collected/available in a given registry, and as a web application allow advanced searches for specific metadata on a given registry inside the PARENT RoR environment.

In short, the PARENT RoR is designed to provide its users with the tool to obtain on EU-level patient registries’ metadata. The development process of the RoR itself is envisioned in two phases. The first phase will cover the searchable web catalogue of existing EU-level patient registries’ data obtained for the PARENT Questionnaire. The second phase will expand upon PARENT RoR to integrate better with the rest of the PARENT Framework1 including methodologies, data models, guidelines and tools for patient registry establishment and governance that are based upon PARENT RoR information. It will also include the functionality of direct import of metadata elements by registry holders and provide for advanced metadata queries.

PARENT RoR Purpose and Scope

The purpose and scope of PARENT RoR is to:

assist users (researchers, registry holders and decision-makers) in identifying search criteria for metadata items included in patient registries

expose metadata standards used in existing EU-level patient registries

1 The definition of scope and specifications of the PARENT Framework are currently in progress. Phase

2 RoR documentation will provide more detail on this.


Version: 2.0

WP 4 Date:25/10/2013

5

expose existing metadata definitions in order to set up a standardized vocabulary of registry terms and shared data model

provide a user friendly interface for the registry related information provide a web based search and browse facility enabling the searching and browsing

through data obtained from registries provide links to existing EU-level patient registries and other relevant information

sources

PARENT RoR Phase 1 Functionalities

Functionality #1: Registry Listing

The registry listing functionality allows the user to overview information about the registries and the information gathered through the PARENT questionnaire in a structured list and narrow down a shortlist through manual selection, aided by filtering functionality. The registry information provided by the listing functionality is taken from the PARENT Questionnaire. The user has the ability to look up, select and display HTML-based metadata for key data set. The registry listing functionality integrates data that already have been collected about the properties listed via the PARENT Questionnaire in an easily browsable manner. It also provides direct links to other sources of information (such as links to primary data sources i.e. existing registries) via a navigational section of a displayed page.

Figure 1. Wireframe of the Registry Listing Function of RoR (development version), Main RoR Functionalities Tab and General RoR Tools


Version: 2.0

WP 4 Date:25/10/2013

6

Figure 2. Wireframe of the Registry Listing Function options

Main functions and information

Registry listing in selected view

View toolbox General RoR tools

Single registry overview

List shows basic information about registries in RoR and enables quick browsing. Soon it will be

enhanced by column sorting

Compare allows selection of RoR fields to be displayed and easily compared on screen

Advanced search allows selection of desired RoR parameters and viewing the resulting registry list

All views allow view of a complete list of registries that satisfy selection parameters for each view,

while selection displays only those registries selected by the user that satisfy the criteria

Each view has its own filtering mechanism


Version: 2.0

WP 4 Date:25/10/2013

7

Functionality #2: Registry Advanced Search The registry advanced search functionality allows the user to search the PARENT RoR registries using the multiple search criteria based on the PARENT Questionnaire. The user has the ability to select multiple selection criteria based on information fields provided in the listing functionality to search for registries and/or registry components.

Figure 3. Wireframe of the Registry Advanced Search Function of RoR (concept version)

Functionality #3: Registry Comparison To compare multiple registries side by side, the Registry Comparison functionality is used. The user has the ability to select various comparison fields and see the detailed information of two or more registries in a side by side, tabular view.


Version: 2.0

WP 4 Date:25/10/2013

8

Figure 4. Wireframe of the Registry Comparison of RoR (development version)

Note: RoR data is currently gathered through the PARENT Questionnaire and the two are connected via an external link. A .csv file is created with all the Questionnaire fields and the file is read by the Phase 1 RoR web platform and displayed to the user in a predefined table. In Phase 2 of RoR development, the PARENT Questionnaire is going to be obsolete due to a web form that the users will use to input their registry data.

PARENT RoR Design

The PARENT RoR Website is currently viewable in any standard Web browser (Internet Explorer version 8, 9 and 10, and latest versions of Google Chrome, Mozilla Firefox, Opera and Apple Safari).

The “look and feel” of the PARENT RoR is inherited from the existing PARENT Website (http://www.patientregistries.eu). All the visual identity elements such as PARENT logo, Web fonts and colours as well as European Commission logo used on the official PARENT Website and other distribution materials are used in the PARENT RoR as well. The PARENT RoR will be included as a subpage of the official PARENT Website and linked throughout the existing Website where appropriate.

http://www.patientregistries.eu/


Version: 2.0

WP 4 Date:25/10/2013

9

Figure 5. A screenshot taken from the official PARENT Website containing all the graphical elements that are being reused by the PARENT RoR, Homepage

Figure 6. A screenshot taken from the official PARENT Website containing all the graphical elements that are being reused by the PARENT RoR, About page


Version: 2.0

WP 4 Date:25/10/2013

10

APPENDIX A: RoR Functional Specifications

PARENT RoR Phase 1 Core Functionalities

1.1. Core Functionality #1: Registry Browsing

The registry browsing functionality should allow the user easy access to information about the registries and their properties in a structured list. Registry browsing should incorporate Registry information fields describing registry formal background and purpose, included in the PARENT Questionnaire for registry holders, developed and implemented by WP4. The user will have the ability to look up, select and display HTML-based metadata (currently available in a structured PARENT Questionnaire format) for any data set. The registry browsing functionality should integrate data that already have been collected about the properties listed via the PARENT Questionnaire. It should also provide direct links to other sources of information (such as links to primary data sources i.e. existing registries) via a navigational section of a displayed page. The availability of Browse criteria depends on the user role (see Chapter 4. on PARENT RoR Users Types and User Privileges) and is limited to either: Limited Browse (Only a minimal set of metadata elements is shown in a Summary list) or Full Browse (A minimal set of metadata elements is shown and by clicking on See more details all the additional metadata elements i.e. Registry Information Fields (see Chapter 4. on PARENT RoR Registry Information Fields). All the browse options are presented to the user via a Registry Browse page. The Registry Browse page of PARENT RoR will include all the items listed in Registry Information Fields. Functionality 1.1: Registry Browsing by Registry Information Field

Use-case 1: User clicks on Registry Information Field (replace with actual listed registry information field item) selected from a predefined list of Registry Information Fields in a navigational pane. A new view opens with a structured list of that particular Registry Information Field's details (see Registry Information Fields) in a dropdown menu. User then clicks on a specific dropdown menu item (specific Registry Information Field's detail) and the registry data displayed is structured in a table format with Registry Information Fields as the table rows and Registry Information Fields' values as the table cells. Considerations: Whenever the mouse goes over an item (Registry Information Field) listed in the table, the item’s description (see Registry Information Fields, Description) is displayed in a floating window (tooltip).


Version: 2.0

WP 4 Date:25/10/2013

11

Figure 1a. Registry Browsing Functionality UML Use-case Diagram


Version: 2.0

WP 4 Date:25/10/2013

12

Figure 1b. Registry Browsing Functionality Data Flow Diagram

Figure 1.1.c. Registry Browsing Functionality Page Wireframe, Browse Page and Summary View


Version: 2.0

WP 4 Date:25/10/2013

13

Figure 1.2.c. Registry Browsing Functionality Page Wireframe, Browse Page and Detailed View

1.2. Core Functionality #2: Registry Search The registry advanced search functionality should allow the user to search the PARENT RoR registries using the search criteria listed in the Registry Information Fields Table. The availability of search criteria depends on the user role and is limited to either: Limited Search (Only a minimum set of metadata elements is shown in a Summary list) or Full Search (A minimum set of metadata elements is shown and by clicking on See more details all the additional metadata elements are shown in a new view). The entire search options are presented to the user via a Registry Search page. The Registry Search page of PARENT RoR will include the search items listed in Registry Information Fields, Minimum registry information depending on the user role (see above). All the searchable items are listed in checkboxes which the users can either check or uncheck to refine the search criteria. Also, a search box is available for free text search.


Version: 2.0

WP 4 Date:25/10/2013

14

Functionality 2.1: Registry Advanced Search

Use-case 1 (Full Search): User selects one or multiple search items presented via checkboxes under the label Search registries by. When done, user clicks on the Search button. A new view opens with the search results list containing the Registry Information Fields requested. The search results contain a Summary list of metadata elements (see Registry Information Fields, Minimum registry information) displayed in a table. The user is provided with the See more details button. - If the user clicks on See more details button, a new view opens with a full display

of search results presented in a table (see Registry Information Fields, Additional registry information).

Use-case 2 (Full Search): User enters a search keyword (free text) into the search box and clicks on the Search button. A new view opens and search results are displayed in a table. The search results contain a Summary list of metadata elements (see Registry Information Fields, Minimum registry information). The user is provided with the “See more details” button. - If the user clicks on See more details button, a new view opens with a full display

of search results presented in a table (see Registry Information Fields, Additional registry information).

Use-case 1 (Limited Search): User selects one or multiple search items presented via checkboxes. When done, user then clicks on Search button. A new view opens and search results are displayed in a table. The search results contain only a Summary list of metadata elements (see Registry Information Fields, Minimum registry information). Use-case 2 (Limited Search): User enters a search keyword (free text) into the search box and clicks on the Search button. A new view opens and search results are displayed in a table. The search results contain only a Summary list of metadata elements (see Registry Information Fields, Minimum registry information). Considerations for Registry Advanced Search: The searchable data displayed is structured in a table format with the Registry information fields as the table rows and the Registry Information fields' values as the table cells. The default sort order of the tabular list is ascending, by registry name and then by other registry attributes as listed in Registry Information Fields. The field(s) and value(s) of the searched term is always highlighted (bolded). The user can click on any table row heading to sort the list by that row (the row then moves up to the first place in the table).


Version: 2.0

WP 4 Date:25/10/2013

15

Depending on the user role, the user can view detailed information about any of the registry properties shown in the Summary list by clicking on See more details button. When the user clicks on a field in the Summary list, a description of the field (see Registry Information Fields) appears in a new view. Whenever the mouse goes over an item (Registry Information Field) listed in the table, the item’s description (see Registry Information Fields, Description) is displayed in a floating window (tooltip). Additional considerations: To reduce loading time for each page, the list is displayed in increments of 20 records per page. The search function should default to a logic, such as Boolean, requiring that search results match all the selected criteria (i.e. criterion 1 AND criterion 2 AND criterion 3). When the user selects more than one item as search criteria, the search function should find all data that meet one or more of the items selected (i.e. item 1 OR item 2 OR item 3). When the user types in free text into the search box, the application should automatically suggest the keyword being written (Keywords are items from the Registry Information Fields list) Figure 2a. Registry Search Functionality UML Use-case Diagram


Version: 2.0

WP 4 Date:25/10/2013

16

Figure 2b. Registry Search Functionality Data Flow Diagram

Figure 2.1.b. Registry Search Functionality Page Wireframe, Registry Information Page and Summary View


Version: 2.0

WP 4 Date:25/10/2013

17

Figure 2.2.b. Registry Search Functionality Page Wireframe, Registry Information Detailed View

1.3. Core Functionality #3: Registry Information Comparison To compare multiple registries side by side, the Registry Information Comparison functionality is used. Use-case 1: User selects multiple Registry Information Fields from a predefined (Browse or Search) list and clicks on the option (button) to Add to list. The selections are temporarily saved and displayed on the page's sidebar with the option (button) to Compare the Fields previously selected. User then continues Browsing or Searching or the user clicks on Compare button located in the sidebar display. A new view opens with a parallel list of Registry Information Fields thus selected. The Registry Information Fields are listed in a table format with Registry Information Fields as table columns and Registry Information Field’s values as Rows. User can remove a previously selected (and added to the list) Registry Information Field by clicking on the Remove button shown in the sidebar under the displayed list of Registry Information Fields. After comparing, the Registry Information Fields stay unchanged until the user removes them manually or exits the application.


Version: 2.0

WP 4 Date:25/10/2013

18

Optional: User can generate the Registry Information Fields' Comparison table previously described in a chart (a graphical description of the data compared) where applicable (i.e. where numbers are listed as values). Considerations: The Compare functionality is available both in Browse and Search functionalities. Whenever the mouse goes over an item listed in the table, the item’s description (see Registry Information Fields, Description) is displayed in a floating window (tooltip). User can only compare 2 registries at a time. If the user selects a third registry, the system alerts the user with a pop-up message that two registries are already selected and prompts for either removal of one of the two, replacing the previously selected registry, or abandoning the action altogether.


Version: 2.0

WP 4 Date:25/10/2013

19

Figure 3a. Registry Information Comparison Functionality UML Diagram


Version: 2.0

WP 4 Date:25/10/2013

20

Figure 3b. Registry Information Comparison Functionality Data Flow Diagram


Version: 2.0

WP 4 Date:25/10/2013

21

Figure 3.1.c. Registry Information Comparison Functionality Page Wireframe, Page and Comparison Summary Comparison View

Figure 3.2.c. Registry Information Comparison Functionality Page Wireframe, Detailed Comparison View


Version: 2.0

WP 4 Date:25/10/2013

22

2. PARENT RoR Registry Information Fields

The PARENT RoR registry entries will contain the information about all registry metadata terms included in the PARENT Questionnaire for registry holders. Some items are mandatory for every registry holder to enter (Minimum registry information) and some are optional (Additional registry information).

Phase 1 of the PARENT RoR design will include the following minimum metadata elements (see Table 5. below) which are to be entered by registered registry holders in a predefined web form.

The table below lists all Registry information fields that must be present on the PARENT RoR view of the Registry Components window. Fields must be listed in this order, with the appropriate data entry control. Fields mandatory status and cardinality is also listed. Fields’ description must be displayed in a tooltip when mouse hovers over the label.

Figure 5.Registry Information Fields List Field name Detail Type Cardinality Status Description

Name* short text free text required The name of the registry in English and local language

Short name* short text free text required unique human-readable code for the indicator

Registry geographic scope*

item list single-choice required Type of registry (national, regional, EU etc)

Registry activity* item list single-choice required Registry active/not active

Registry holder* item list multi-choice required Type of registry holder (public health institution, health care provider etc.)

Registry type* item list single-choice required Type of registry – condition, product or services based

Registry Primary observational unit*

item list single-choice required Type of primary unit observed in the registry (person, event, hospital discharge, medical product)

Contact person for access to data*

free text free text required contact details (name and email address of contact person or institution)

Data quality indicator short text free text Existence and description of data quality indicator

Reference Documents document attachment optional One or more documents defining indicator methodology, official guidelines, etc..


Version: 2.0

WP 4 Date:25/10/2013

23

Links URL link link optional One or more links associated with the indicator

Existence of standardized data exchange format

item list single-choice optional yes/no

Data linkage available with unique identifier2

item list single-choice required yes/no

Data linkage routinely to other sources

item list single-choice optional yes/no

Sources of data item list multi-choice optional Type of source from which data is obtained

Major data provider item list multi-choice optional Major data provider for the registry

Interest in sharing data item list single-choice optional yes/no

Additional approval needed from

item list/free text

multi-choice optional List of sources of data linked with registry

Fees needed to access data

item list single-choice required yes/no

Average timeframe in weeks for application decision

free text free text optional Number of weeks for a decision to be made on an application for access to data.

Other possible data sources

free text free text optional All other data sources from which information for the indicator could be collected.

Comments and limitations

long text free text optional Description of any existing limitation of the data or issues that may have implication for data interpretation, including issues that might affect comparability between countries and across time.

Date of last updated indicator

date single-choice - Last modified date, automatically displayed based on last edit date done by user

Key words short text Free text optional List of key words describing the registry

*Mandatory registry information fields (Minimum of information that a registry holder must provide), also Searchable fields

Note: In Phase 1 of the PARENT RoR development, all the above information is given explicitly by registered registry holders via the PARENT Questionnaire and entered in the PARENT RoR by PARENT administrators. In Phase 1 there will be no direct data input from registry holders.

2 This can be either patient or device unique ID


Version: 2.0

WP 4 Date:25/10/2013

24

3. PARENT RoR Graphical User Interface Requirements

The PARENT RoR Website must be viewable in a standard Web browser (Internet Explorer version 8, 9 and 10, and latest versions of Google Chrome, Mozilla Firefox, Opera and Apple Safari).

The “look and feel” of the PARENT RoR will be inherited from the existing PARENT Website (http://www.patientregistries.eu). All the visual identity elements such as PARENT logo, Web fonts and colours as well as European Commission logo used on the official PARENT Website and other distribution materials should be used in the PARENT RoR as well, if only as a guidance.

The PARENT RoR will be included as a subpage of the official PARENT Website and linked throughout the existing Website where appropriate.

Summary

The PARENT RoR Patient Registry Inventory is envisioned as a browsable and searchable listed display of patient registries contained in the PARENT RoR. The registry metadata are imported from the PARENT Questionnaire generated .csv file (Phase 1 of the PARENT RoR development) for easy user access. Phase 2 of PARENT RoR is currently in planning and development phase.

http://www.patientregistries.eu/