Skip Navigation
Department of Health and Human Services www.hhs.gov
  • Home
  • Search for Research Summaries, Reviews, and Reports
 
 

Research Report - Final – Apr. 3, 2012

Enhanced Functionality for the Distributed Research Network Pilot

Formats

Table of Contents

Author Affiliations

Jeff Brown, Ph.D.1
David Hertz, B.S.2
Richard Platt, M.D., M.Sc.1
Robert Rosen, M.B.A.2
Adam Sigelman, B.A.3
Beth Syat, M.P.H.3
Kiran Shah, B.S.2

1Harvard Medical School and Harvard Pilgrim Health Care Institute
2Lincoln Peak Partners
3Harvard Pilgrim Health Care Institute

Abstract

The Agency for Healthcare Research and Quality (AHRQ) has identified the need for clinical, administrative, and other kinds of health care information from very large populations to address topics central to its mission, and to the missions of other Federal agencies. A distributed health data network advances AHRQ’s Effective Health Care and Health Information Technology research goals by focusing on standardized and reusable information technology approaches for speeding the initiation and conduct of large-scale comparative effectiveness studies, including studies of treatments covered by Medicaid, Medicare, CHIP, and other Federal payers.

As part of a prior task order contract (HHSA 290-2005-0033-I-TO5), the current team developed design specifications for a scalable, distributed, health data network, created a prototype for the network, performed a study using distributed principles assessing the comparative effectiveness of second line anti-hypertensive therapy, and created a blueprint for implementing a distributed health data network.

The current activity ("Enhanced Functionality for the Distributed Research Network Pilot") involved continued development of the previously created prototype. Work involved building more robust infrastructure components for a distributed network for comparative effectiveness research and illustrating its use using health plan data. Specifically, network software and portal development included more advanced access control, permissions, usage controls, and query type mechanisms, a redesigned research user interface, additional user notifications, and workflow, auditing and monitoring features. A functioning pilot network that supports distributing menu-driven queries was created, whereby queries are executed against local data resources, and results are aggregated for review.

Introduction

Overall Goal of the Distributed Research Network (DRN)

The overall goal of the project is to create a secure Web-based network that can integrate health data from a wide array of sources and make it available to AHRQ and its partners without requiring the large amount of time and effort that currently delays effective decision making. The network also will help avoid the redundancy that has begun to occur as different Federal programs begin to use the same data resources for similar purposes.

Rationale

AHRQ has identified the need for clinical, administrative, and other kinds of health care information from very large populations to address many topics central to its mission, and to the missions of other Federal agencies, including CMS, and other partners.

A distributed network advances AHRQ’s Effective Health Care and Health Information Technology research goals by focusing on standardized and re-usable information technology approaches for speeding the initiation and conduct of large-scale comparative effectiveness studies, including studies of treatments covered by Medicaid, Medicare, SCHIP, and other Federal payers. Other research topics that could be addressed include coverage with evidence development and assessment of long-term outcomes. The network also will allow rapid generating of evidence related to the diffusion of new medical technologies. The system will make actionable information available in a more timely way than traditionally occurs in standard research environments.

A fully functioning network will expedite comparative research studies by facilitating access to large and diverse populations and through reuse of existing or newly created data resources, and standardization of study procedures and analytic approaches. Such a network also will allow rapid response to simple queries that are often needed to assess the size and scope of emerging public health priorities.

Background

Our prior work (contract 290-2005-0033I-TO5)* developed a comprehensive framework and design for a scalable and secure distributed research network.1,2 Detailed stakeholder discussions and technical assessments identified the following as paramount concerns for a network: complete control of, and access to, uses of their data; strong security and privacy features; limited impact on internal systems; minimal data transfer; auditable processes; standardization of administrative and regulatory agreements; transparent governance; and ease of participation and use.2

The proposed network design therefore features a secure Web-based portal that performs network functions, such as operations (e.g., workflow, policy rules, auditing, query formation and distribution) and security (e.g., authentication, authorization) and distributed data marts that remain under the control of the data partners.

The intent of this activity is to make progress in developing the capabilities and functionality necessary for a fully functioning network. The enhancements described below will be incorporated into Phase 2 of our Distributed Research Network (DRN) activities (290-2005-0033I-TO12), reducing the demand on the new task order’s resources and accelerating the availability of functional network components. In addition, continuing development serves to improve the usefulness of the stakeholder feedback, as it can be elicited through demonstrations of the prototype and its current and future capabilities. We designated this activity as Phase 1.5, to distinguish it from the task order that ended in August 2009 (DRN 1.0) and the new task order that began in December 2009 (DRN 2.0).

Figure 1 illustrates the high-level network architecture. Our approach was based on lessons learned from Phase 1 of DRN and specifically on our findings that a network should be built in phases to improve the efficiency of software development, elicit strong support and trust from early adopters, and provide a functional platform to solicit expansion of the network.

Figure 1. Distributed research network system architecture

Figure 1 is an illustration depicting the high-level system architecture. Within the Portal are the following functionalities: Portal Database, Access Control Manager, Query Manager, Results Manager, Workflow Manager, User Manager, Audit Manager, Researcher User Interface, Data Mart Admin User Interface, System Administrator User Interface, and DRN Hub API. The Portal is connected to the Data Mart via the Message Protocol. Within the Data Mart are the following functionalities: Data Mart Database, Data Mart Security Manager, Query Execution Manager, Data Mart API, Data Mart Audit Manager, and Data Source Manager.

Specific Aims and Methods

The project includes three specific aims.

Aim 1: Develop and test software that allows authorized users to execute queries across distributed, de-identified health plan databases and rapidly return summary data.

This aim focused on building additional areas of the architecture to improve usability and speed and drive acceptance of the system by participating and prospective members. The new functionality and capabilities developed as part of this aim are listed below.

DRN Portal Functions
  • Access Control Manager/Data Entitlements—An access control architecture was designed, and an access control framework was constructed that includes data entitlement functions enabling system and data mart administrators to restrict access to data marts, query types, and query parameters based on individual users’ roles or affiliations with organization or groups.
  • Workflow Manager/Notification Functions—The workflow manager functionality was extended to include a notification framework that centralizes notification management and provides end-user control over delivery of notifications, including an alert to query submitters when results become available.
  • Data Mart Administrator User Interface—A data mart provisioning feature was added, enabling non-technical administrators to set up and maintain data mart information in the Portal, including the ability to add new data marts and edit a data mart’s configuration.
Data Mart Client Functions
  • Workflow Manager—In this phase, the Data Mart Client was extended so that it can receive and execute queries in an unattended mode that periodically polls the Portal to find queries, and, based on local query rules, downloads and executes queries and uploads results automatically without any user interaction required.
  • Audit Manager—Auditing and reporting capabilities were added for transaction and event logging, logging of query receipt and execution, as well as errors and exceptions.

Aim 2: Deploy the software developed in Aim 1 in multiple data owner partners and test the functionality of the system in a real world setting.

We deployed and tested the infrastructure developed in Aim 1. Testing involved querying data resources maintained and secured by the data partners to establish the functionality of the system in a real-world setting. We installed and tested at five sites: Harvard Pilgrim Health Care, Group Health Cooperative, Geisinger Health System, HealthPartners Research Foundation, and Kaiser Permanente Colorado.

Aim 3: Document the technical infrastructure and provide specific recommendations for continued deployment and development.

Implementation of the software included a Webinar describing the new features, instructions for use, and a discussion of suggested revisions.

Results

This section describes the final design of the DRN 1.5 system. The first section details the system architecture, the second section describes the design of the new portal functions, and the last section describes the enhancements to the DRN Data Mart Client.

System Architecture and Components

The components of the DRN System Architecture are illustrated in Figure 1.

The major architectural components for the Network are the Portal, the Data Marts, and the Data Mart Client.

The web-based Portal is hosted on a centrally accessible server and provides all of the centralized services. Investigators log in to the Portal using a web-based user interface, and submit menu-driven queries via the Portal. After queries are executed by the Data Marts, results are returned to the Portal, where they are aggregated and made available to the submitter.

The data mart components run locally at the data partner location. Two different types of data marts allow for flexibility in the deployment model. The Server Based Data Mart is hosted on a server, and it exposes a web services interface utilized by the Portal to automatically send and execute queries and retrieve results. The Client Based Data Mart is a lightweight desktop application, intended to run on the Data Mart administrator’s desktop computer. The Client Based Data Mart uses a web services interface exposed by the Portal to manually download and execute queries and upload results.

The components of the DRN System Architecture are described in the table in Appendix A1. The code for the components of the System Architecture is organized into "projects." The table in Appendix A2 summarizes the languages and tools used in the network architecture implementation.

Portal Functions

Access Control Manager/Data Entitlements

System enhancements now allow system and data mart administrators to restrict access to data marts and query types (e.g., ICD-9 diagnosis codes or generic names) based on individual users, organizations, or groups. This new functionality greatly improves data partner acceptance by permitting fine-grained control over who can submit queries to their data marts and which data marts are available for querying. Several access control concepts were created to allow this level of access control.

Access Control Concepts

Entity—refers to the recipient of a permission, such as a user or an organization. Entities are organized into a hierarchy, whereby permissions granted to "parent" entities (e.g., an organization) are "inherited" by "child" entities (e.g., a user). For example, an entity could be a user (e.g., Jeff Smith), an organization (e.g., Harvard Pilgrim Health Care), or a group (e.g., the HMO Research Network).

Permission—refers to an allowance granted or restricted by access control. Permissions are associated with a target and granted to an entity.

Target—refers to the object of a permission. Targets can be a right (e.g., "submit query", "view results"), a resource (e.g., a data mart), or a data resource (e.g., query type).

Role—refers to the classification assigned to each user. The assignment of a role confers certain rights. Roles currently include investigator, data mart administrator, and system administrator.

Access Control Entities

Figure 2 illustrates the entity hierarchy for access control.

Figure 2. Access control entity hierarchy

Figure 2 shows the access control hierarchy. All users gain system permissions depending on the organizations to which they pertain or the groups to which their organizations pertain.

Permissions are inherited by entities through parent/child relationships. An Organization inherits all permissions granted to all Groups to which it belongs, and a User inherits all permissions granted to its parent Organization. Thus, a User has the union of all permissions granted to the User, the parent Organization, and all parent Groups.

Access Control Targets

Appendix Table A3 summarizes the access control targets. Targets are the objects of permissions. Each permission grants access to a target. In addition to the rights inherited through parent entities, all users also retain system rights assigned to their system role. Together, these access control concepts, entities, and targets give system and data mart administrators fine-grained control over who can query their data marts and what investigators can query of that data mart (e.g., query types)

Workflow Manager/Notification Functions

The notification functionality was extended to include centralized notification management and end-user control over delivery of notifications. Most significantly, a query status notification feature was added to alert query submitters when results become available. Details of the notification controls are below.

Notification Concepts

Event—refers to an occurrence of a particular transaction within the system, for example, the submission of a new query. Appendix Table A4 describes the events to be included in DRN 1.5.

Notification—refers to a message describing the occurrence of an event, for example, an email message regarding submission of a new query. Multiple notifications may be generated for a single event.

Event Generation

Events are generated by various components and subsystems, typically at the time the event occurs—e.g., when a new query is entered, a New Query event is generated by the Query Manager.

When an event is generated, the system records the event and notifications in the database. The notification entries are recorded for processing only when the user has opted for such events on the currently established portal.

Notification Options

Users can control generation of notifications by configuring their Notification Options. Notification options can be configured in the Portal through the Investigator User Interface.

Figure 3 depicts a screenshot of how the notification option appears.

Figure 3. Notification option screenshot

This screen shot shows the portal screen where users can select their notification options. Investigators can opt in or out to notifications that occur when the status of one of their queries changes, when there are new results, or when a certain pre-selected amount of time passes without a change in query status. Data mart administrators can receive emails when new queries are submitted to their Data Marts or a week goes by without any change in status in a query submitted to their Data Marts.

Taken together, this new functionality provides an enhanced user experience by creating various notification options and by giving users flexibility over use of those options.

Data Mart Admin User Interface

This enhancement allows nontechnical administrators to set up and maintain data marts in the portal. The provisioning feature includes the ability to add new data marts, edit a data mart’s configuration, and enter a data mart administrator’s contact information. The specific new features are listed below.

Data Mart Administration Menu Item

Users can access the Data Mart Administration feature through the User Interface of the Portal through a new "Data Mart Administration" menu item added to the "Administration" menu of the main navigation bar.

Data Mart List Screen

The Data Mart List screen features a grid containing a list of data marts, as illustrated in Figure 4.

Figure 4. Data mart administration screenshot

This screen shot displays the portal screen where users can click to view information on each of the Data Marts in the system.

Data Mart names are hyperlinks; clicking on the Data Mart’s name will bring up the Data Mart Detail screen for the selected data mart.

Data Mart Detail Screen

The Data Mart Detail screen is used to edit existing data mart information or create a new data mart. The screen contains a form for displaying and editing the data mart attributes as illustrated in Figure 5.

Figure 5. Data mart detail screenshot

This screen shot shows the Data Mart information screen. This screen contains detail on each Data Mart, including name, type, corresponding organization, organization description, administrators, contact information, available periods, restrictions, requirements, and supported queries.

Clicking the Permissions button brings up the Data Mart Permissions form as shown in Figure 6.

Figure 6. Data mart permission screenshot

This screen shot shows the Data Mart permissions screen. On this screen, data mart administrators can choose which entities (groups, organizations, and users) may access their Data Marts.

This permissions screen allows data mart administrators and system administrators to control which entities can send queries to the data mart. These enhancements allow system and data mart administrators to update and maintain the list of available data marts in the network.

Query Manager/Results Manager/Investigator User Interface

Three new query types have been added: outpatient procedure codes, inpatient procedure codes, and enrollment. In addition to these query types, query parameter selection has been expanded to include age and sex filters.

New Query Type: ICD-9 Procedure Codes

A new query type was added to the system to support ICD-9 Procedure Code queries as shown in Figure 7.

Figure 7. ICD-9 Procedure code screenshot

This screen shot shows the new investigator user interface that allows investigators to submit queries based on ICD-9 procedure codes.

New Query Type: HCPCS Procedure Codes

The Healthcare Common Procedure Coding System (HCPCS) is a set of health care procedures codes based on the Current Procedural Terminology (CPT). HCPCS are typically associated with outpatient care. The HCPCS User Interface is as shown in Figure 8.

Figure 8. Health care common procedure coding system screenshot

This screen shot shows the new investigator user interface that allows investigators to submit queries based on HCPCS procedure codes.

New Query Type: Enrollment

Enrollment describes information, such as the age and sex distribution of health plan members included in each data mart. The Enrollment User Interface is as shown in Figure 9.

Figure 9. Enrollment screenshot

This screen shot shows the new investigator user interface that allows investigators to submit queries based on eligibility and enrollment data.

New Query Parameter: Age Group

A new query parameter has been added to the Query Entry screen to support filtering results by age group. The user interface should present the age group parameter using a list of check boxes, as in Figure 10.

Figure 10. Age parameter screenshot

This screen shot shows how users may select different age ranges by which to stratify their result sets.

New Query Parameter: Sex

A new query parameter has been added to the Query Entry screen to support filtering results by sex. The user interface should present the sex parameter using a list of check boxes, as in Figure 11.

Figure 11. Sex parameter screenshot

This screen shot shows how users may stratify their result sets by sex.

These three new query types and two new parameters allow investigators more flexibility in the health data queries they submit.

Data Mart Metadata

Metadata was added to the portal to document the available data at each site and provide site-specific information for users. Metadata include years of data available, types of data available by year, key contacts, and special requirements or restrictions on use.

New Database Attributes

Appendix Table A5 lists the new database attributes to be added to the portal database to support metadata attributes for each Data Mart.

User Interface—Display Changes

The Data Mart Metadata is available through a drop-down menu on the Query Entry Form. The Data Mart selection control will be modified to provide hyperlinks to a popup display containing the metadata. The hyperlinks will appear as in Figure 12.

Figure 12. Data mart hyperlinks screenshot

This screen shot shows how users may select which Data Marts to include in their queries. Clicking on the hyperlink for a particular Data Mart will display that Data Mart's meta data.

Clicking on a hyperlink causes a popup window to appear containing a listing of the metadata for the selected Data Mart.

Administration

Administration of data mart metadata, including entry and modifications of metadata values, will be done through the Data Mart Admin User Interface as described above.

This data mart metadata enhances investigator experience by giving investigators instant access to detailed information on each of the Data Marts in the network.

Data Mart Client Functions

Workflow Manager

The Data Mart Client was extended so that data mart administrators can setup the system to receive and execute queries automatically in an "unattended mode." A feature was added allowing the Data Mart Client to run "in the background" on the data mart administrator’s desktop system. In this mode, the application periodically polls the Portal to find, download, and execute queries and upload results automatically, without any user interaction required. A set of preferences governs the operation of the service and includes settings, such as the polling duration.

Background Processing operates in one of two modes:

  • In Notify Only mode, the application will poll for new queries and alert the user when new queries are found, but it will not process any queries automatically.
  • In Process mode, the application will poll for new queries, execute them, and upload results automatically.

A Polling Interval configuration setting specifies the number of minutes between polling attempts.

When new queries are found while in Process mode, the system automatically runs the query and uploads the results to the portal. If the application is operating in Notify mode, the application will notify the user by causing the new query indicator to appear in the system tray icon and a description of the query to be briefly displayed as a tool tip above the system tray icon.

System Tray Icon

The Data Mart Client now contains an icon in the System Tray for the purposes of: (1) indicating that the background process is running; and (2) providing basic status information through a "tool tip."

The "tool tip" is shown when the cursor is hovered over the system tray icon, and provides a status message as illustrated in Figure 13.

Figure 13. System tray icon tool tip screenshot

This screen shot shows the Data Mart Client tray icon. Messages appear when the Client receives and processes queries while set in unattended mode.

When the Background Process is in Notify mode, the system tray icon is used to deliver notifications and signal status to the user as illustrated in Figure 14.

Figure 14. System tray icon notification screenshot

This screen shot shows the Data Mart Client tray icon. Messages appear when new queries arrive when the Client is set in notify mode.

When new queries are found, a tool tip is displayed containing a description of the new query as shown. In addition, as long as new queries are present, the new query indicator appears in the system tray icon.

Settings Dialog

The Data Mart Client settings dialog will be modified as shown in Figure 15.

Figure 15. DRN client settings dialog screenshot

This screen shot shows the settings popup for the Data Mart Client. Users can set the Client to unattended or notify mode in this interface.

These enhancements allow data mart administrators the option to process and upload queries much more efficiently with little need for user interaction.

Audit Manager

To coincide with the unattended processing feature added in the Workflow Manager, a set of auditing and reporting capabilities were added to the Data Mart Client. The auditing features include transaction and event logging, including logging of query receipt and execution as well as errors and exceptions. Reporting features include the ability to run reports filtered by date range, query type, and entity.

Logging

The logging feature provides functions for writing log messages to the Windows Event Log. Appendix Table A6 notes the types of information that are logged. All log messages are written to a separate Windows Event Log File named DRN, which is visible using the Windows Event Viewer.

Figure 16. Windows event view screenshot

This screen shot shows the Windows event viewer, where a data mart administrator can view all activity that has occurred in their Data Mart.

Options for log size, rollover, etc. are configurable using the standard Windows Event Viewer properties dialog (Figure 17).

Figure 17. Windows event view properties dialog screenshot

This screen shot shows the properties dialogue of the Windows event viewer. Here the user can set preferences related to the log size, rollover, etc.

Reporting of events logged through the Audit Manager is possible using the Windows Event Viewer (Figure 17).

This audit manager allows system and data mart administrators to ensure that only authorized users are using the system and that they do so in an appropriate manner.

Discussion

This section describes the lessons learned from the project and the anticipated next steps in the upcoming DRN version.

Lessons Learned in Development and Implementation

The activities involved in the technical development of the DRN 1.5 system reinforced the need for detailed governance policies. Many governance questions arose during the project, including:

  • What pre-defined user roles should the system contain, and what rights should those roles confer on users?
  • How should system administrators set up new users in the system? What should the "default settings" be for new users? Should data mart administrators be allowed to add new users at their organizations or is that a system administrator function?
  • How should the system set up external investigators? Should they fall under an umbrella group or get individual logins?

The governance panel formed in the next phase of the project will address these issues and many others.

Additionally, the Data Mart Administrators from the implementation sites were primarily concerned with issues relating to data protection and privacy. Concerns center on the proposed future inclusion of low cell counts or other Personal Health Information (PHI). Data Mart Administrators also wish to minimize the risk of unauthorized or fraudulent uses the DRN system to access their proprietary information for nefarious purposes. While the DRN partners are comfortable with the development of the tool thus far, many had suggestions on how to improve the security of the system in future versions. These suggestions are outlined in the following section.

Identification of New Functionality

Data Protection and Privacy

All partners and stakeholders stressed the importance of protecting proprietary information. During the course of the project, the project team identified the following additional functionalities that would serve this goal:

  • Data deletion: Currently, the system retains query results indefinitely. Future versions should include functionality that deletes results after a specified period.
  • Low cell counts: Currently, the system does not mask low cell counts; although data partners could do so on their own. Future versions should give data mart administrators the option of masking low cell counts. Preferably the system would allow data mart administrators to manually set the threshold at which to mask low counts.
  • Unattended Mode Permissions: Currently, if the Data Mart Client is set to unattended mode, all queries submitted to the Data Mart will run automatically. Data Mart Administrators have expressed the interest in creating permissions for use of this mode. In other words, they want the ability to restrict the use of unattended mode to only their most trusted partners. Other system users would still be able to submit queries, but the data mart administrators would have to manually run and upload those queries.
  • Period Ranges: Currently, the system allows investigators to submit queries to data marts regardless of the available data in that data mart. A more sophisticated system would only display data marts as options if those data marts contained the data in the requested periods. For instance, if a data mart did not have data from 2008, an investigator would not see it in the Query Interface after selecting 2008 as the requested period.

Validation of Local Data Marts

DRN 1.5 assumes that the underlying data is in the correct format. However, as new partners begin to create their own tables, it will be important to verify the structure of the data in the data marts. Validation will result in fewer DRN errors and higher overall data quality. The requested enhancement would entail a series of functions that would scan the underlying database to validate that:

(a) All necessary tables exist;
(b) Each table has the appropriate column setup; and
(c) Data in each of the table rows match the expected format and accepted values.

Both data mart administrators and system administrators should have the option of validating the underlying data. This activity would be performed when adding new data marts or updating the data in existing data marts.

Next Steps

The primary suggestions for additional development of the system include:

  • Continued development to improve access control, security, and usability
  • Create the ability to exchange files, thereby allowing investigators to submit analytic code to data marts and receive result sets in return
  • Investigate the technical requirements needed to perform distributed multivariate analysis using network resources
  • Additional query types should be investigated, including more granular diagnosis and procedure information and incident exposure/diagnosis counts in addition to the prevalent counts now included
  • Incorporate data validation and visualization components in the portal to help investigators validate query results, view them graphically, and actively manipulate the results within the portal

Translation of Findings

The experience with this project corroborates the team’s hypothesis surrounding the viability and value of a distributed research network. While partners still have concerns about data protection, they are unanimous in their support of the underlying architecture and access control features. The distributed model of data querying allows a high degree of automation and efficiency while still including the necessary protections that satisfy data partners, data partners’ IT security requirements, and IRB representatives.

Future versions of the DRN tool should build on the model of this version while considering more robust querying options for investigators. As sites become more comfortable with the system and its protections, the DRN can expand to include more detailed and varied data sets, including patient-level data sets. There is tremendous value in providing analysis tools for patient-level data sets that would not require data to leave its parent organization. Various public and private organizations may have interest in using these kinds of tools for multi-site studies. Building upon and expanding the network will entail a number of activities, including speaking engagements at conferences, developing a secure and professional DRN website with project information, and engaging known research consortia in discussions on how they might benefit from the system.

References

1. Maro JC, Platt R, Holmes JH, et al. Design of a national distributed health data network. Ann Intern Med 2009;151(5):341-4.

2. Brown JS, Holmes JH, Shah K, et al. Distributed Health Data Networks. A Practical Preferred Approach to Multi-Institutional Evaluations of Comparative Effectiveness, Safety, and Quality of Care. Med Care 2010;48(6):S45-S51.

*Developing a Distributed Research Network and Cooperative to Conduct Population-based Studies and Safety Surveillance 290-2005-0033I)

Appendix A.

Table A-1. System components

Component Description
Access Control Manager Manages all aspects of security for Portal including authentication, session management, policies, group permissions, user permissions, and access rights.
Query Manager Manages query entry, routing and distribution.
Results Manager Manages receipt, organization, assembly, merging and aggregation of result sets.
Workflow Manager Manages workflow (e.g., for query approval) including request routing, alerting and notification, approval management and tracking.
User Manager Manages user accounts.
Audit Manager Provides auditing functions including activity and error logging.
Investigator User Interface User interface for Investigators, including menu driven and ad hoc query entry, query management, result status, and result set management.
Data Mart Administrator User Interface User interface for data mart administrators including data mart setup and configuration, access control management, and workflow management.
System Administrator User Interface User interface for system administrators including portal setup and configuration, access control management, and user management.
DRN Portal API Application Programming Interface (e.g., web service API) for the Portal; exposes Portal functions for remote applications including query retrieval and results submission.
Portal Database Database for the Portal.
Message Protocol Protocol for messaging between the Portal and external applications including the Data Marts.
Data Mart Security Manager Manages all aspects of security for Data Mart including authentication, session management, policies, group permissions, user permissions, and access rights.
Query Execution Manager Manages execution of queries including queue management, query translation, query engine interface, and results handling.
Data Mart API Application Programming Interface (e.g., web service API) for the Data Mart. Exposes DRN functions for remote applications including query submission and results retrieval.
Data Mart Audit Manager Provides auditing functions including activity and error logging.
Data Source Manager Manages exchange of data between the Data Mart database and source systems.
Data Mart Database Database for the Data Mart.

Table A-2. Languages and tools

Component(s) Tools/Languages
Portal Microsoft Visual Studio .Net 2005
Data Mart Client Microsoft.Net Framework 2.0 C#
Portal Database Microsoft SQL Server 2005
Data Mart databases Microsoft Access (can be any ODBC-accessible data source)

Table A-3. Targets

Target Description
Data Mart Instance of a remote database, typically hosted by a data partner. Granting permission to a data mart allows an entity to submit queries to that data mart. Permissions to administer a data mart and respond to queries submitted to a data mart are covered under Rights.
Rights Rights represent capabilities or functions available to users of the system – such as, "log in", or "submit query". Granting a right allows the entity to utilize a particular function (e.g., "administer user profile") or utilize a particular function in a particular way (e.g., "administer user profile for another user in the same organization").
Query Type Granting permission to a Query Type allows the entity to submit queries of that type.

Table A-4. Event types

Event Type Event Source Description
New Query Query Manager Occurs when a new query is created, typically through the Query Entry screen of the Investigator User Interface in the Portal.
Query Status Change Query Manager Occurs when a query’s status changes. Query status changes can happen automatically, as when the Portal background service changes the query status. Query status changes can happen as a result of a user action, such as when query status is set to Awaiting Approval when a user clicks "Hold" in the Data Mart Client or as a result of the Data Mart administrator clicking "Reject" in the Data Mart client.
Query Reminder Query Manager (via Portal Background Service) Occurs when no response is received from a data mart within n days of query submission (where n is a configurable system wide parameter). In addition, this notification also occurs when a data mart has not responded within n days of the last reminder sent to this data mart.
New Results Results Manager Occurs when query results are returned. Query results can be returned automatically, as with server-based data marts, or as a result of a user action, such as when a user clicks Upload Results from the Data Mart Client.
Submitter Reminder Query Manager (via Portal Background Service) Occurs when no response is received from one or more data marts within n days of a query submission (where n is a configurable user selected frequency parameter). The submitter will receive one notification per query submitted, which occurs n days after the last submitter reminder was sent for a query when one or more data marts have not responded.

Table A-5. Database attributes

Attribute Description
Available Periods Text string containing a description of the available periods, e.g., "Annual and quarterly data from 2001 to present."
Contact First Name First name of key contact, e.g., "Jeff"
Contact Last Name Last name of key contact, e.g., "Smith"
Contact Phone Phone number of key contact, e.g., "(617) 555-1212"
Contact Email Email address of key contact
Special Requirements Text box containing a description of any special requirements, e.g., "All procedure queries will be subject to IRB review, typically requiring 3-5 business days for approval."
Usage Restrictions Text box containing a description of any usage restrictions, e.g., "Data not available for export outside of the United States."
Health Plan Description Text box describing the health plan, such as population size, geographic region, etc.
Organization ID Organization with which Data Mart is associated.

Table A-6. Audit information types

Type Description
Transaction and Event Logging Startup and shutdown of Data Mart Client
State changes (Start/Stop) of Data Mart Client Background Service
Login and Logout through Data Mart Client
Query Receipt and Execution New query found by Data Mart Client Background Service
Query executions
Query rejections
Queries placed on hold
Upload of results
Errors and Exceptions Unexpected errors and unhandled exceptions.

Appendix B. Technical Documentation: Requirements and Design Specification

Enhanced Functionality for the Distributed Research Network Pilot

TECHNICAL DOCUMENTATION
Requirements and Design Specification

DRN 1.5
Requirements and Design Specification

Revision 1.5
April 26, 2010

Document History

Revision Author Date Description
0.1 Kiran Shah 11/19/2009 Internal draft
0.2 Kiran Shah 11/20/2009 Internal draft
0.3 Kiran Shah 11/29/2009 Developed sections 3.2, 4.1, and 4.2.
Incorporated preliminary feedback from Jeff Brown.
1.0 Kiran Shah 12/4/2009 Requirements/Design Milestone submission.

Incorporated feedback from LP/HP working session on 12/2.

Developed section 3.1.

Added multiple Notification Email

Added HealthPlanDescription attribute

1.1 Kiran Shah 12/17/2009 Incorporated feedback from Harvard Pilgrim:
  • Added sections
  • Added verbiage regarding access to administration functions
  • Added validation rules
  • Added requirements describing the changes to the User List page.
  • Added Administer Data Mart rights

Changed "Owner" to "Organization" and updated "Notification" details

Added "OrganizationId" to DataMarts

Added clarifying language

1.2 Kiran Shah 12/28/2009 Minor edits to make several rights in-scope for DRN 1.5.

Added schema diagram and additional tables.

Added "Supported Queries" and "Permissions".

Added Required field designations in Table 35.

Updated logo image on cover page.

Added explanatory verbiage in various sections.

1.3 Kiran Shah 12/30/2009 Made "Administer user profile for any user" right in scope for DRN 1.5.

Changed "Outpatient Procedure Codes" to "ICD-9 Procedure Codes" throughout.

Updated intro verbiage to reflect use of the existing query type in several sections.

Added "Setting" parameter to Table 39.

Added Setting parameter.

Revised "Procedure Code" parameter and added "Setting" parameter to Table 40.

Modified SQL code and added Setting parameter.

Updated intro verbiage to reflect use of the existing query type.

Added ification Email Templates section.

1.4 Kiran Shah   Changed verbiage throughout section 4.
1.5 Srinivasan Karunanidhi 22/02/2010 Removed excessive Rights (Administer Users, Administer Organization, Administer Data Marts and Administer Groups) from section 3.1.5

Added New Right (Administer Roles) to section 3.1.5

Added New Method signatures (AddRightToRole and RemoveRightToRole) to support Role based access at the user level in section 3.1.7.

Added new validation rules to section 3.1.9.1

Updated tables 11,13,14,15,36,37

Added tables 24,25,29,30,39

Added note to section 3.1.10.3

Added new requirement to filter Data Marts based on query types to section 3.1.11

Added verbiage for new reminder events/table Event Detail Query Reminder and Event Detail Submitter Reminder.

Updated all the email template in section 3.2.14

Added new section 3.2.14.5 (email template for Submitter email reminders).

Updated verbiage and added note to section 3.3.2

Updated SQL queries in section 3.4.2.2, 3.4.3.2, 3.4.4.2

Added and Appendix to the document with three separate sections to describe changes &enhancements made as follow: Appendix A Role-Based Rights; Appendix B – Notification Enhancements/Query Submitter Reminder; and Appendix C – View Data Marts’ meta data.

Updated all figures to reflect the changes added to this version.

Appendixes 1 - 3

1. Introduction

1.1. Background

Harvard Pilgrim Health Care (HPHC) previously engaged Lincoln Peak to develop a prototype of a distributed health information network—a distributed research network (DRN)—to conduct population-based studies of the risks and benefits of therapeutics.

In Phase 1, the prototype demonstrated how participating members can issue queries through a network portal (hub) that are then distributed across network nodes and executed locally. Query results are returned in aggregate form, and collated into unified result sets. The prototype also demonstrates how authentication and access control could be provided by the network. The prototype demonstrates the following functions:

  • Assembly of a simple query using a menu driven user interface
  • Issuance of the query
  • Distribution of the query to multiple network servers
  • Local execution of the query against a test dataset
  • Return of the results to the portal
  • Aggregation of the results and presentation as a single results set

As an extension to Phase 1, Lincoln Peak extended the prototype to beyond test datasets to include information representing actual patient care. Portal functionality was extended to support a "publish and subscribe" query fulfillment model. Query selection, parameter specification, data mart selection, query status, query detail, and result viewing remained unchanged. However, instead of having queries dispatched to "live" servers for automated execution against test datasets, queries are queued for later semi-automated processing by network partners using their desktop or laptop computers. An email-based notification mechanism was added to the portal to alert data partners when new queries have been submitted. A lightweight desktop application was developed for use by partners to fulfill queries. To participate in the prototype network, data partners do a one-time download and installation of this lightweight desktop application. No servers, no firewalls, and special network setups are required. Once the desktop application is installed, the partners can fulfill queries wherever they are, with only their desktop/laptop computer and an internet connection. Partners are in complete control of which queries get answered, and what results get uploaded to the portal.

This next phase (DRN 1.5) will focus on building out additional areas of the architecture to improve usability and drive acceptance of the system by participating and prospective partners.

1.2. Document Scope

This document describes the functional requirements and design for DRN phase 1.5. The document is arranged into the following sections:

Section 2 describes the high level system architecture originally envisioned for DRN, the organization of the code, and the languages and tools used.

Section 3 describes the DRN Portal functions being developed in this phase, including Access Control, the Notification functions of the Workflow Manager, the Data Mart Admin User Interface, additions and changes to the Investigator User Interface, and addition of Data Mart Metadata.

Section 4 describes the DRN Data Mart Client functions being developed in this phase, including the Workflow Manager for providing unattended operation, and the Audit Manager.

2. System Architecture

2.1. Existing System Architecture

Requirements and design specifications described in this document refer to components contained within the DRN System Architecture as illustrated below.

Figure 1. System architecture

This figure shows the high-level system architecture of the DRN Client and Portal.

The major architectural components for the DRN Network are the Portal, and the Data Marts.

The Portal is hosted on a centrally accessible server, and provides all of the centralized services. Investigators log in to the Portal using a web-based user interface, and submit menu-driven queries which are stored in the Portal Database. After queries are executed (by the data marts), results are returned to the Portal, where they are aggregated and made available to the query submitter.

The Data Mart components run locally, in close proximity to each data source. Queries submitted to the Portal are sent to each data mart, which executes the queries against the local data source. Results are then returned to the Portal. Two different types of data marts allow for flexibility in the deployment model. The Server Based Data Mart is hosted on a server, and exposes a web services interface utilized by the Portal (i.e., in a "push" type model) to send and execute queries and retrieve results. The Client Based Data Mart is a lightweight desktop application, intended to run on the Data Mart administrator’s desktop computer. The Client Based Data Mart uses a web services interface exposed by the Portal (i.e. in a "pull" type model) to download and execute queries and upload results.

The components of the DRN System Architecture are described in the table below.

Table 1. DRN System architecture components

Component Description
Access Control Manager Manages all aspects of security for DRN Portal including authentication, session management, policies, group permissions, user permissions, and access rights.
Query Manager Manages query entry, routing and distribution.
Results Manager Manages receipt, organization, assembly, merging and aggregation of result sets.
Workflow Manager Manages workflow (e.g., for query approval) including request routing, alerting and notification, approval management and tracking.
User Manager Manages user accounts.
Audit Manager Provides auditing functions including activity and error logging.
Investigator User Interface User interface for Research users, including menu driven and ad hoc query entry, query management, result status, and result set management.
Data Mart Admin User Interface User interface for data mart administrators including data mart setup and configuration, access control management, and workflow management.
System Admin User Interface User interface for system administrators including portal setup and configuration, access control management, and user management.
DRN Portal API Application Programming Interface (e.g., web service API) for the DRN Portal. Exposes Portal functions for remote applications including query retrieval and results submission.
Portal Database Database for the DRN Portal.
Message Protocol Protocol for messaging between the DRN Portal and external applications including the data marts.
Data Mart Security Manager Manages all aspects of security for data mart including authentication, session management, policies, group permissions, user permissions, and access rights.
Query Execution Manager Manages execution of queries including queue management, query translation, query engine interface, and results handling.
Data Mart API Application Programming Interface (e.g., web service API) for the data mart. Exposes DRN functions for remote applications including query submission and results retrieval.
Data Mart Audit Manager Provides auditing functions including activity and error logging.
Data Source Manager Manages exchange of data between the data mart database and source systems.
Data Mart Database Database for the data mart.

2.2. Code Organization

The code for the components of the System Architecture is organized into "projects" as follows:

Table 2. DRN system components project organization

Component(s) Project Name Description
Portal Database PortalDatabase SQL database project for the Portal database.
Investigator User Interface
Data Mart Admin User Interface
System Administrator User Interface
PortalWeb ASP.NET web application for the Portal application.
Access Control Manager
Query Manager
Results Manager
Workflow Manager
User Manager
Audit Manager
DRNLib Shared library for Portal components.
Data Mart Client Security Manager
Data Mart Client Query Execution Manager
Data Mart Client Workflow Manager
Data Mart Client User Interface
Data Mart Client Audit Manager
Data Mart Client Data Source Manager
DRN Portal API
DataMartClient Windows forms application for Client Based Data Mart.
Data Mart Security Manager
Query Execution Manager
Data Mart API
Data Mart Audit Manager
Data Source Manager
DataMartWeb ASP.NET web service for Server Based Data Mart.

2.3. Languages and Tools

The table below summarizes the languages and tools used in DRN:

Table 3. Languages and tools

Component(s) Tools/Languages
DRN Portal
DRN Data Mart Client
Microsoft Visual Studio .Net 2005
Microsoft .Net Framework 2.0
C#
DRN Portal Database Microsoft SQL Server 2005
Data Mart databases Microsoft Access (can be any ODBC-accessible data source)

3. DRN Portal Functions

This section specifies requirements and design for changes to the DRN Portal.

3.1. Access Control Manager/Data Entitlements

Overview of Requirement

The existing system contains "demo" functionality which is suggestive of potential access control features. The "demo" functionality will be replaced by a true access control function. An access control architecture will be designed and a base access control framework will be constructed. The initial implementation will include data entitlement functions enabling system administrators and data mart administrators to restrict access to data marts and query types (e.g., ICD-9 diagnosis codes or generic names), based on individual users or entire organizations.

Access Control Concepts

Entity—refers to the recipient of a permission, such as a user or an organization. Entities are organized into a hierarchy, with permissions granted to "parent" entities (e.g., an organization) are "inherited" by "child" entities (e.g., a user).

Permission—refers to an allowance granted or restricted by access control. Permissions are associated with a target and granted to an entity.

Target—refers to the object of a permission. Can be a right (e.g., "submit query"), a resource (e.g., a data mart), or data (e.g., query type).

Access Control Entities

The diagram below illustrates the entity hierarchy for access control:

Figure 2. Access control entity hierarchy

This figure shows the hierarchy of access control. All system users belong to a single organization. Organizations can belong to multiple (or no) groups

Table 4. Access control entities

Entity Description
Group A group of related organizations (e.g., Kaiser Permanente, HMO Research Network)
Organization A company or institution (e.g., Kaiser Permanente Colorado, or AHRQ). Organizations belong may belong to any number of groups (or no groups).
User An individual person. Users belong to one organization.

Note that the User entity already exists in the DRN Portal database. Group and Organization are new entities.

Permissions are inherited by entities through parent/child relationships. An Organization inherits all permissions granted to all Groups to which it belongs, and a User inherits all permissions granted to its parent Organization. Thus a User has the union of all permissions granted to the User, the parent Organization, and all parent Groups.

Access Control Targets

The table below summarizes the access control targets to be included in DRN 1.5.

Table 5. Access control targets

Target Description
DataMart Instance of a remote database, typically hosted by a partner. Granting permission to a data mart allows the target (user, organization, or group) to submit queries to that data mart. Permissions to administer a data mart and respond to queries submitted to a data mart are covered under Rights.
Rights Rights represent capabilities or functions available to users of the system – such as "log in", or "submit query". Granting a right allows the target (user, organization, or group) to utilize a particular function (e.g., "administer user profile") or utilize a particular function in a particular way (e.g., "administer user profile for another user in the same organization").
QueryType Granting permission to a Query Type allows the target (user, organization, or group) to submit queries of that type.

Rights

The list below specifies the rights which can be granted in DRN 1.5.
Items listed in italics will not be included in DRN 1.5 but are contemplated for future phases.

  • Portal Functions
    • Access
      • Log in to portal (Login)
    • Queries
      • Submit query
      • View list of queries submitted by self
      • View list of queries submitted by any user in same organization
      • View list of queries submitted by any user in same group
      • View list of queries submitted by any user
    • Results
      • View results summary for queries submitted by self
      • View results summary for queries submitted by any user in same organization
      • View results summary for queries submitted by any user in same group
      • View results summary for queries submitted by any user
      • View results detail for queries submitted by self
      • View results detail for queries submitted by any user in same organization
      • View results detail for queries submitted by any user in same group
      • View results detail for queries submitted by any user
    • Administration
      • Administer user profile for any user in same organization
      • Administer user profile for any user in same group
      • Administer user profile for any user
      • Create user in same organization
      • Create user in same group
      • Create any user
      • Grant organization-level permissions
      • Grant group-level permissions
      • Grant system wide permissions
      • Administer Data Mart for same organization
      • Administer any Data Mart
      • Administer Roles
  • Data Mart Client Functions
    • Access
      • Log in to portal through Data Mart Client
    • Queries
      • View list of queries submitted to data mart
      • View query detail
      • Hold query
      • Reject query
      • Run query
    • Results
      • Upload results

Access Control Data Model

The diagrams below illustrate the data model for Access Control—for DataMarts, QueryTypes, and Rights. In each case, the permissions are stored in a many-to-many "join table" which joins the access control target (DataMart, QueryType, or Right) to the entity being granted permission (user, organization, or group). The presence of a record in the join table represents a granted permission, while absence of a record indicates that the permission has not been granted.

Access Control Data Model for Users, Groups and Organizations

The diagram below illustrates the data model for access control entities—users, groups, and organizations. Note that the Users entity already exists in the DRN Portal database, however Groups and Organizations are new in DRN 1.5:

Figure 3. Access control data model for organizations and groups

This figure shows the table structure that governs the access control hierarchy depicted in Figure 2.

Access Control Data Model for DataMarts

The diagram below illustrates the data model for defining permissions between entities and DataMarts.

Figure 4. Access control data model for DataMarts

This figure shows the table structure that governs access control at the DataMart level.

Access Control Data Model for QueryTypes

The diagram below illustrates the data model for defining permissions between entities and QueryTypes.

Figure 5. Access control data model for QueryTypes

This figure shows the table structure that governs access by query type.

Access Control Data Model for Rights

The diagram below illustrates the data model for defining permissions between entities and Rights.

Figure 6. Access control data model for rights

This figure shows the table structure that governs access control by user right.

Access Control Manager Design

The Access Control Manager implements methods for granting and checking permissions, and includes the methods described below.

Methods for Granting Permissions and Rights

void GrantUserDataMartPermission(int UserId, int DataMartId)
Grants specified User permission to use specified DataMart.

void GrantOrganizationDataMartPermission(int OrganizationId, int DataMartId)
Grants specified Organization permission to use specified DataMart.

void GrantGroupDataMartPermission(int GroupId, int DataMartId)
Grants specified Group permission to use specified DataMart.

void GrantUserQueryTypePermission(int UserId, int QueryTypeId)
Grants specified User permission to use specified QueryType.

void GrantOrganizationQueryTypePermission(int OrganizationId, int QueryTypeId)
Grants specified Organization permission to use specified QueryType.

void GrantGroupQueryTypePermission(int GroupId, int QueryTypeId)
Grants specified Group permission to use specified QueryType.

void AddRightToRole (int RoleTypeId, int RightId)
Grants specified Right to specified User.

void GrantOrganizationRight (int OrganizationId, int RightId)
Grants specified Right to specified Organization.

void GrantGroupRight (int GroupId, int RightId)
Grants specified Right to specified Group.

Methods for Revoking Permissions and Rights

void RevokeUserDataMartPermission(int UserId, int DataMartId)
Revokes specified User permission to use specified DataMart.

void RevokeOrganizationDataMartPermission(int OrganizationId, int DataMartId)
Revokes specified Organization permission to use specified DataMart.

void RevokeGroupDataMartPermission(int GroupId, int DataMartId)
Revokes specified Group permission to use specified DataMart.

void RevokeUserQueryTypePermission(int UserId, int QueryTypeId)
Revokes specified User permission to use specified QueryType.

void RevokeOrganizationQueryTypePermission(int OrganizationId, int QueryTypeId)
Revokes specified Organization permission to use specified QueryType.

void RevokeGroupQueryTypePermission(int GroupId, int QueryTypeId)
Revokes specified Group permission to use specified QueryType.

void RemoveRightFromRole (int RoleTypeId, int RightId)
Revokes specified Right from a role (Each user shall be assigned with a role).

void RevokeOrganizationRight (int OrganizationId, int RightId)
Revokes specified Right from specified Organization.

void RevokeGroupRight (int GroupId, int RightId)
Revokes specified Right from specified Group.

Methods for Checking and Listing Permissions

bool CheckUserRight(int UserId, int RightId)
Returns true if specified user has specified Right by virtue of user having user-level assignment of the Right, or inheriting organization-level or group-level assignment of the Right.

int[] GetUserDataMartPermissions(int UserId, bool IncludeInherited)
Obtains the list of DataMarts to which specified user has access by virtue of user having user-level permission or (if IncludeInherited is true) inheriting organization-level or group-level permission to the DataMart.

int[] GetUserRights(int UserId, bool IncludeInherited)
Obtains the list of Rights granted to specified user by virtue of user having user-level assignment of the Right or (if IncludeInherited is true) inheriting organization-level or group-level assignment of the Right.

int[] GetUserQueryTypePermissions(int UserId, bool IncludeInherited)
Obtains the list of QueryTypes to which specified user has access by virtue of user having user-level permission or (if IncludeInherited is true) inheriting organization-level or group-level permission to the QueryType.

int[] GetOrganizationDataMartPermissions(int OrganizationId)
Obtains the list of DataMarts to which specified organization has permission.

int[] GetOrganizationRights(int OrganizationId)
Obtains the list of Rights assigned to specified organization.

int[] GetOrganizationQueryTypePermissions(int OrganizationId)
Obtains the list of QueryTypes to which specified organization has permission.

int[] GetGroupDataMartPermissions(int GroupId)
Obtains the list of DataMarts to which specified group has permission.

int[] GetGroupRights(int GroupId)
Obtains the list of Rights assigned to specified group.

int[] GetGroupQueryTypePermissions(int GroupId)
Obtains the list of QueryTypes to which specified group has permission.

Data Mart Client Security Manager Design

The Data Mart Client Security Manager will implement access control functions for the Data Mart Client.

For DRN 1.5, the Data Mart Client does not require direct access to the access control functions. Access control will be implemented in the portal, and within the DRN Hub API.

Administration for Users, Organizations, and Groups

User administration functions were added to DRN in a previous phase. In DRN 1.5, the user administration is expanded to include the user/organization relationship, and adds administrative functions for organizations and groups.

New administrative functions will be added to the "Administration" menu of the main navigation bar, as follows:

Figure 7. Administration menu

This screen shot depicts the menu options available to administers under the 'Administration' link.

Access to the Administration functions for Groups, Organizations, Users, and Rights is governed by Rights. Only users with sufficient permissions are allowed access to these functions.

User Administration

The existing User Administration form will be changed to include a control for selecting Organization as follows:

Figure 8. User administration form

This screen shot depicts the user interface used to administer a single use profiles.

The new controls on the User Admin form are as follows:

Table 6. User administration form controls

Control Description
Organization select Presents a list of Organizations from the Organization table.
Rights button Presents the Rights Selection form as described in section 0 on page 24.
Role select Presents a list of Roles from the RoleTypes table.
Email entry Presents a textbox to Add/Edit email address.
Delete button Presents the admin user with an option to delete the selected user.

The following validation rules will be implemented:

  • Valid organization must be selected. All users must be associated with an organization.
  • Valid email must be entered.
  • Valid role must be selected. All users must be associated with a role.

To facilitate identification of Users associated with an Organization, the following changes will be made to the User List page:

Figure 9. User list form

This screen shot depicts the user interface that allows an administrator to view all users in the system. Clicking on a user name takes the administrator to the screen in figure 8.

  • An Organization column will be added to the User list, displaying the name of the Organization with which the user is associated.
  • An Organizations filter will be added. This will be a drop-down list of Organizations. Selecting an Organization will filter the list of users to those associated with the selected Organization. A special list item labeled "All" will be available as the first item in the pick list, and will cause users from all organizations to be displayed.

Organization Administration

The Organization Administration will include functions to create, edit, and delete organizations, and will consist of two forms—the Organization List form, and the Organization Detail form.

The Organization List form will present a list of organizations, as follows:

Figure 10. Organization list form

This screen shot depicts the user interface used to administer organizations.

Organization names will be presented as hyperlinks. Clicking on the organization name will bring up the Organization Detail screen for the selected organization.

The New Organization button will bring up the Organization Detail screen for creating a new organization.

The Organization Detail form presents the attributes of the organization, as follows:

Figure 11. Organization detail form

This screen shot depicts the user interface used to create a new organization.

The fields on the Organization Detail form are as follows:

Table 7. Organization detail form fields

Field Database Table/Column
Organization name Organization.OrganizationName

The controls on the Organization Detail form are as follows:

Table 8. Organization detail form controls

Control Function
Delete button Presents a confirmation dialog, as in:

Javascript: Really delete this organization? OK or cancel.

If the user clicks OK, the system flags the organization as deleted by setting the Organization.isDeleted flag = 1.

Save button Performs validation checks and saves entries made on the form.

Validation checks are as follows:

  • Organization name – must not be blank

For new Organizations, inserts a new record in the Organizations table.

For existing Organization records, updates the existing record in the Organizations table.

Cancel button Returns to the Organization List screen.
Rights button Presents the Rights Selection form.

Group Administration

The Group Administration will include functions to create, edit, and delete groups, and will consist of two forms—the Group List form, and the Group Detail form.

The Group List form will present a list of groups, as follows:

Figure 12. Group list form

This screen shot depicts the user interface used to administer groups.

This screen shot depicts the user interface used to administer groups.

Group names will be presented as hyperlinks. Clicking on the group name will bring up the Group Detail screen for the selected group.
The New Group button will bring up the Group Detail screen for creating a new group.
The Group Detail form presents the details of the group, as follows:

Figure 13. Group detail form

This screen shot depicts the user interface used to add organizations to a group.

This screen shot depicts the user interface used to add organizations to a group.

The fields on the Group Detail form are as follows:

Table 9. Group detail form fields

Field Database Table/Column

Group name

Group.GroupName

Not In Group

Initially displays Organizations. OrganizationName for all records found in the Organizations table (where isDeleted=0) but not found in the OrganizationsGroups table for the group being modified.

This list contains all Organizations (where isDeleted=0) when a new group is being added.

In Group

Initially displays Organizations. OrganizationName for all records found in the OrganizationsGroups table for the group being modified, where Organizations.isDeleted=0.

This list is initially empty when a new group is being added.

The controls on the Group Detail form are as follows:

Table 10. Group detail form controls

Control Function

Add button

Moves the record selected in the “Not In Group” list into the “In Group” Members list. In other words, adds an organization to this group.

Remove button

Moves the record selected in the “In Group” Members list into the “Not In Group” list. In other words, removes an organization from this group.

Delete button

Presents a confirmation dialog, as in:

Javascript: Really delete this group? OK or cancel.

If the user clicks OK, the system flags the group as deleted by setting the Group.isDeleted flag = 1.

Save button

Performs validation checks and saves entries made on the form.

Validation checks are as follows:

  • Group name—must not be blank

For new Groups, inserts a new record in the Groups table.

For existing Group records, updates the existing record in the Groups table.

Also updates the OrganizationsGroups table by adding any new associations and removing any that should no longer exist.

Cancel button

Returns to the Group List screen.

Rights button

Presents the Rights Selection form.

Access Control Administration

All Access Control (including Access Control settings for the Data Mart Client) is administered through the Portal. Access Control administration functions are exposed in various places, including administrative functions for both access control entities (users, organizations, and groups) and targets (data marts, rights, and query types).

Administering Data Mart Permissions

Data Mart permissions relate to which entities (users, organizations, and groups) are granted access to a data mart (for submitting queries). Data Mart permissions are administered through the Data Mart Admin User Interface.

Administering Rights—Rights Admin

Administration of Rights occurs through a new Rights Admin function, reachable through the Administration > Rights menu item in the main navigation bar.

Clicking on the Rights menu item presents the Rights List Form as follows:

Figure 14. Rights list form

This screen shot depicts the complete list of system rights.

This screen shot depicts the complete list of system rights.

Each Right Code is presented on a hyperlink. Clicking on the hyperlink leads to the Rights Detail form, as follows:

Figure 15. Rights detail form

This screen shot depicts the user interface used to give individual entities a particular right (the right to log into the system).

This screen shot depicts the user interface used to give individual entities a particular right (the right to log into the system).

The fields on the Rights Detail form are as follows:

Table 11. Rights detail form fields

Field Database Table/Column

Right Code

Rights.RightCode

Description

Rights.Description

Groups

Initially displays list of Groups.GroupName for groups found in GroupsRights for the current Right, where Groups.isDeleted=0.

Organizations

Initially displays the list of Organizations.OrganizationName for organizations found in OrganizationsRights for the current Right, where Organizations.isDeleted=0.

Users

Displays the list of Users.UserName for those users whose role has been granted the current right, where Users.isDeleted=0.

The controls on the Rights Detail form are as follows:

Table 12. Rights detail form controls

Control Function

Groups – Add button

Opens the Group Selection popup window and adds the user’s selections to the Groups list.

Groups – Remove button

Removes the row selected in the Groups list.

Organizations – Add button

Opens the Organization Selection popup window and adds the user’s selections to the Organizations list.

Organizations – Remove button

Removes the row selected in the Organizations list.

Save

Saves all changes made on the Rights Detail form and returns to the Rights List.

Updates the GroupsRights and OrganizationsRights table adding records to and removing records from each as needed, according to any changes made.

Cancel

Returns to the Rights List form without saving changes.

Administering Rights—Rights Selection

In addition to providing a “Rights-centric” mode of Rights administration, the system also allows Rights to be administered within the context of administering individual entities—i.e. groups, organizations, and users. In other words, while administering a group, organization, or user, clicking on the Rights button from the detail form brings up the Rights Selection dialog as shown below:

Note: The “Rights” section was overhauled to provide a role-based rights and access at the user level as requested by the client. Please refer to Appendix “A” for the approved Rights proposal that details the changes implemented.

Figure 16. Rights selection form (approved changes)

This screen shot depicts the user interface used to give rights to an individual user.

This screen shot depicts the user interface used to give rights to an individual user.

The controls on the Rights Selection form are as follows:

Table 13. Rights selection form controls

Control Function

Cancel button

Close the form opened as popup.

Administering Query Type Permissions

Query Type permissions relate to which entities (users, organizations, and groups) are granted access to each Query Type.

Administration of Query Type permissions occurs through a new Query Type Permissions Admin function, reachable through the Administration > Query Permissions menu item in the main navigation bar.

Clicking on the Query Type Permissions menu item presents the Query Type Permissions List Form as follows:

Figure 17. Query type permissions list form

This screen shot depicts the user interface used to set access controls by query type.

This screen shot depicts the user interface used to set access controls by query type.

Each Query Type is presented as a hyperlink. Clicking on the hyperlink leads to the Query Type Permissions Detail form, as follows:

Figure 18. Query type permissions detail form

This screen shot depicts the user interface used to allow access to individual entities for a particular query type (pharmacy dispensings by drug class).

This screen shot depicts the user interface used to allow access to individual entities for a particular query type (pharmacy dispensings by drug class).

The fields on the Query Type Permissions Detail form are as follows:

Table 14. Query types permissions detail form fields

Field Database Table/Column

Query Type

QueryTypes.QueryType

Description

QueryTypes.Description

Groups

Initially displays list of Groups.GroupName for groups found in GroupsQueryTypes for the current QueryType, where Groups.isDeleted=0.

Organizations

Initially displays the list of Organizations.OrganizationName for organizations found in OrganizationsQueryTypes for the current QueryType, where Organizations.isDeleted=0.

Users

Initially displays the list of Users.UserName for users found in UsersQueryTypes table for the current QueryType, where Users.isDeleted=0.

The controls on the Query Types Permissions Detail form are as follows:

Table 15. Query types permissions form controls

Control Function

Groups – Add button

Opens the Group Selection popup window and adds the user’s selections to the Groups list.

Groups – Remove button

Removes the row selected in the Groups list.

Organizations – Add button

Opens the Organization Selection popup window and adds the user’s selections to the Organizations list.

Organizations – Remove button

Removes the row selected in the Organizations list.

Users – Add button

Opens the User Selection popup window and adds the user’s selections to the Users list.

Users – Remove button

Removes the row selected in the Users list.

Save

Saves all changes made on the Query Types Permissions Detail form and returns to the Query Types Permissions List.

Updates the GroupsQueryTypes, OrganizationsQueryTypes, and UsersQueryTypes tables, adding records to and removing records from each as needed, according to any changes made.

Cancel

Returns to the Query Types Permissions List form without saving changes.

Access Control Changes in Query Entry

The Query Entry form in the DRN Portal application will be modified to include Access Control. The following changes will be implemented:

  • Query Type Filtering—the Query Type pick list will be filtered to display only the query types for which the current user has permission. If the user does not have permissions to at least one query type, the following message will be displayed:
    You have not been granted permission to submit any of the available query types. Please contact the System Administrator for assistance.
  • Data Mart Filtering—the Data Mart pick list will be filtered to display on the data marts to which the current user has permission. If the user does not have permissions to at least one data mart, the following message will be displayed:
    You have not been granted permission to submit queries to any of the available data marts. Please contact the System Administrator for assistance.
  • Data Mart Filtering based on supported Query types—the Data Mart pick list will be filtered to display only the data marts that support the selected Query type from the Query type pick list.

3.2 Workflow Manager/Notification Functions

Overview of Requirement

A basic notification function was added in the previous phase, to alert data mart administrators when queries are entered against a data mart. This functionality will be extended to include a notification framework which will centralize notification management and provide end-user control over delivery of notifications. A query status notification feature will be added, to alert query submitters when results become available.

Notification Concepts

Event—refers to an occurrence of a particular transaction within the system, for example the submission of a new query.

Notification—refers to a message describing the occurrence of an event, for example an email message regarding submission of a new query. Multiple notifications may be generated for a single event.

Workflow Manager Design

The Workflow Manager implements functions to manage workflow including request routing, alerting and notification, approval management, and tracking. Alerting and notification functions are exposed through an Event Interface and a Notification Interface.

Figure 19. Workflow manager design

This diagram shows how certain functions cause the system to generate email notifications.

The Event Interface exposes functions for event generation, and used by other system components such as the Query Manager and Results Manager to generate events when they occur.

The Notification Interface exposes functions for event notification, including functions to set notification options and retrieve notifications, used by other system components such as the DRN Hub API and the Investigator User Interface.

Event Generation

Events are generated by various components and subsystems in DRN, typically at the time the event occurs—e.g., when a new query is entered, a New Query event is generated by the Query Manager.

When an event is generated, the system records the event and notifications in the database. The notification entries are recorded for processing only when the user has opted for such events on DRN portal (“Settings > Notification Options” page). Generation and delivery of notifications happens subsequently, as part of background processing

Event Data Model

The diagram below illustrates the data model for Event data.

Figure 20. Event data model

This figure shows the underlying table structure for DRN events.

The Events table is the master/parent table for recording event data and contains the following attributes:

Table 16. Events attributes

Attribute Data Type Description

EventId

Int

Identity

EventSourceId

Int

Event Source, referring to the module which generated the event.

EventTypeId

Int

Event Type, specifying the type of event which occurred.

EventDateTime

Datetime

Date and time the event occurred

The EventSources and EventTypes tables are lookup tables for Event Source and Event Type, respectively. Attributes are as follows:

Table 17. EventSources attributes

Attribute Data Type Description

EventSourceId

Int

Identity

EventSource

Varchar(50)

Event source description

Table 18. EventTypes attributes

Attribute Data Type Description

EventTypeId

Int

Identity

EventType

Varchar(50)

Event type description

The EventDetailNewQuery, EventDetailQueryStatusChange, EventDetailNewResult, EventDetailQueryReminder and EventDetailSubmitterReminder tables are detail/ child tables, used to store event details specific to each Event Type. For example, for a New Query event, there is one record in the Events table and a corresponding record in the EventDetailNewQuery table.

Table 19. EventDetailNewQuery attributes

Attribute Data Type Description

EventId

Int

Event to which this detail pertains

QueryId

Int

Query id of new query

Table 20. EventDetailStatusChange attributes

Attribute Data Type Description

EventId

Int

Event to which this detail pertains

QueryId

Varchar(50)

Query id of query with status change

NewQueryStatusTypeId

Int

New query status type

Table 21. EventDetailNewResult attributes

Attribute Data Type Description

EventId

Int

Event to which this detail pertains

ResultId

Int

Result id of new result

Table 22. EventDetailQueryReminder attributes

Attribute Data Type Description

EventId

Int

Event to which this detail pertains

QueryId

Int

QueryId associated with the notification

DataMartId

Int

Unique Id for the data mart that has not responded

Table 23. EventDetailSubmitterReminder attributes

Attribute Data Type Description

EventId

Int

Event to which this detail pertains

QueryId

Int

QueryId associated with the submitter reminder notification

Events
The table below describes the events to be included in DRN 1.5:

Table 24. Workflow manager events

Event Source Event Type Description

Query Manager

New Query

Occurs when a new query is created, typically through the Query Entry screen of the Investigator User Interface in the Portal.

Query Manager

Query Status Change

Occurs when a query’s status changes.

Query status changes can happen automatically, as when the Portal background service changes the query status.

Query status changes can happen as a result of a user action, such as when query status is set to AwaitingApproval when a user clicks “Hold” in the Data Mart Client or as a result of the data mart administrator clicking “Reject” in the Data Mart client.

Query Manager (via Portal Background Service)

Query Reminder

Occurs when no response is received from a data mart within n days of query submission (where n is a configurable systemwide parameter). In addition, this also occurs when a data mart has not responded within n days of the last reminder sent to this data mart.

Results Manager

New Results

Occurs when query results are returned.

Query results can be returned automatically, as with server-based data marts, or as a result of a user action, such as when a user clicks Upload Results from the Data Mart Client.

Query Manager (via Portal Background Service)

Submitter Reminder

Occurs when no response is received from one or more data marts within n days of a query submission (where n is a configurable user selected frequency parameter). The submitter will receive one notification per query submitted, which occurs n days after the last submitter reminder was sent for a query when one or more data marts have not responded.

Note: The user level setting shall be selected on the “Notification options” page available under “SETTINGS” menu option in the DRN portal.

Event Interface

The Event Interface exposes methods for event generation, including the following:

int RaiseEvent(strin Return to Top of Page