high level solution design v1 0

High Level Solution Design

MI0002: RADAR Information Delivery to Clinical Software Options Analysis

Jay Rizvi

Document Date: v1.0 28/07/2010

© NPS RADAR information delivery to clinical softwareConfidential High Level Solution Design (HLSD)

of 30

Table of Contents

Introduction............................................................................................................................................................... 4

1.1 Document Purpose........................................................................................................................... 41.2 Project Overview............................................................................................................................... 41.3 Audience........................................................................................................................................... 41.4 Project Scope.................................................................................................................................... 41.4.1 In Scope............................................................................................................................................ 4

2. Business Context......................................................................................................................................... 9

2.1 Business Driver................................................................................................................................. 92.1.1 Current state..................................................................................................................................... 92.2 Business Intent................................................................................................................................. 92.2.1 Purpose............................................................................................................................................. 92.2.2 Method............................................................................................................................................ 102.2.3 End State........................................................................................................................................ 10

3. Functional specification............................................................................................................................. 11

3.1 User experience.............................................................................................................................. 113.2 Functional Specification.................................................................................................................. 123.2.1 Overview......................................................................................................................................... 123.2.2 RADAR Documents........................................................................................................................ 123.3 Basic Integration - Linking to NPS RADAR documents...................................................................123.3.1 Functional Requirements................................................................................................................123.4 Advanced Integration - also Linking NPS RADAR documents to the drug database......................133.4.1 Functional Requirements................................................................................................................133.5 Patient Information Leaflets............................................................................................................143.6 Basic Integration - Linking to NPS PILs documents........................................................................143.6.1 Functional Requirements................................................................................................................143.7 Usage data submission................................................................................................................... 163.7.1 Functional Requirements................................................................................................................16

4. Solution Design.......................................................................................................................................... 18

4.1 Solution overview............................................................................................................................ 184.2 Solution elements with multiple design options...............................................................................184.3 Fixed aspects.................................................................................................................................. 184.4 Solution Architecture 1: Locally cached information through web services.....................................204.4.1 Option summary.............................................................................................................................. 214.4.2 NPS Information Flow.....................................................................................................................214.5 Solution Architecture 2: On demand access...................................................................................224.5.1 Option summary.............................................................................................................................. 234.5.2 NPS Information Flow.....................................................................................................................234.6 Solution Architecture 3: Information updates via vendor software update process.........................244.6.1 Option summary.............................................................................................................................. 254.6.2 NPS Information Flow.....................................................................................................................254.7 Common Architecture decisions.....................................................................................................25

5. Fixed aspects of the design....................................................................................................................... 26

5.1 Overview......................................................................................................................................... 265.2 System Index File........................................................................................................................... 265.3 Drug Coding.................................................................................................................................... 265.4 Reporting Data Format.................................................................................................................... 265.5 NPS information format................................................................................................................... 265.6 Security........................................................................................................................................... 26

6. Technical Design........................................................................................................................................ 27

6.1 Locally cached information through web services...........................................................................276.1.1 Use Cases...................................................................................................................................... 276.1.2 Activity diagrams............................................................................................................................. 27


of 30

6.2 On demand access......................................................................................................................... 306.2.1 Use Cases...................................................................................................................................... 306.2.2 Activity diagrams............................................................................................................................. 306.3 Information updates via vendor software update process...............................................................306.3.1 Use Cases...................................................................................................................................... 306.3.2 Activity diagrams............................................................................................................................. 30


of 30

Introduction

1.1 Document Purpose

The purpose of this document is to describe the high level solution design (HLSD) for three possible architectures for the RADAR project.

The major objectives of this document are to: Detail the major architectural design aspects of the solution in greater detail comprising:

o The business (functional) architecture/design – detail regarding the major functional aspects of the solution and how they relate to each other, other systems and the solution’s environment;

o The information architecture/design – detail regarding what the major ‘subject areas’ of information are, how they relate to the NPS data reference model and how the solution will be designed to access the information it needs;

o The application and integration architectures/designs – detail regarding how the major ‘components’ of the solution will be packaged into business applications and how the components will be integrated to provide the overall solution and integrate with the solution’s environment;

o The security and technical architectures/designs – detail regarding how the overall solution will be supported by the technical environment, including the network, and the integration of security mechanisms into the overall solution architecture/design.

This document supersedes any previous design documents.

1.2 Project Overview

The document is structured to initially describe the solution at a high level and progressively provide more detail to the point where all the solution requirements of each system have been detailed.

The first sections provide the context of the solution, briefly describing the business reason and then how the solution fits with clinical software vendor’s application.

The following sections then detail how the solution will work and be structured, how the functional requirements will be met, and what the requirements are on each individual component of the solution.

1.3 Audience

The intended audience of this document includes: Project sponsor & Steering Committee Pharmaceutical decision support team Medicines information Solution Architecture Clinic software vendors Infrastructure Support teams

1.4 Project Scope

Below are the business requirements for the project.

1.4.1 In Scope


of 30

Goal Type Number Requirement Mandatory/ Desirable/ Priority

Vendor Supported

Reach Business BREQ-001 The system should be easy to implement for additional vendors (e.g. Best Practice, Fred IT, Medtech Global, Zed Med) of General Practice and community pharmacy software, while providing a similar or improved set of functions to existing implementations in Medical Director and Genie.

Mandatory Yes

Reach Business BREQ-002 Production and delivery mechanisms should not require significant additional effort at NPS as a result of changes.

Mandatory Yes

Reach Business BREQ-003 The solution should support a move from MIMS drug coding to a non-proprietary drug coding standard.

Desirable/ High n/a

Reach Business BREQ-004 This solution should take into account which coding system vendors use The solution should use a code set that is common to most vendor to maximise reach and reduce overall cost.

Mandatory Yes

Reach Business BREQ-005 The solution should use the optimum output format for displaying and viewing RADAR information in the vendor’s application.

Mandatory Yes

Low Risk Business BREQ-006 NPS must be able to test that RADAR has been incorporated correctly before updates are distributed to end users.

Mandatory n/a

Cost/Effort Business BREQ-007 The solution should use the same mechanism for delivery of RADAR content to MIMS Online and e-MIMS as would be used for delivery to prescribing software vendors.

Desirable/ Medium

n/a

Effort Business BREQ-008 The vendor’s application should display a RADAR popup message for any ‘current’ topic (as defined by mapping NPS supplies).

Mandatory/ High Yes

Flexible platform

Business BREQ-009 After the pop has been displayed a predefined number (3 or 5) of times, it should not appear any more.

Mandatory/ High Yes

Flexible platform

Business BREQ-010 Healthcare professionals should have the option to stop displaying the specific drug popup after it has been displayed at least once.

Mandatory/ High Yes


of 30


Vendor Supported

Effort Business BREQ-011 The options analysis should provide a recommendation for streamlining PILs production business process addressing the following issues:

1. PILs publication currency issues, different versions of PILs documents in different software packages.

2. Different titles given to templates used during production of PILs documents

3. Variations in presentation of the documents such as version numbering

Desirable / Medium

n/a

Evaluation Reporting RREQ-001 The system should provide data that contains information on the number of active registered users for each vendor.

Desirable / Low Yes

Evaluation Reporting RREQ-002 The system should provide data that contains information which can be aggregated and report on the usage of RADAR month-by-month.

Desirable / Medium

Yes

Evaluation Reporting RREQ-003 The system should provide data that contains information on the number of pop ups for both Patient information leaflet and RADAR content.

Desirable / Medium

Yes

Evaluation Reporting RREQ-004 The system should provide data that contains information on the number of user-initiated article reads. (Aka Medical Director “RADAR button”).

Desirable / Low Yes

Evaluation Reporting RREQ-005 The system should provide data on the number of times RADAR is invoked in a vendor’s application. (aka MD “Resources menu”)

Desirable / Low Yes

Evaluation Reporting RREQ-006 The system should provide data allowing a breakdown on an article-by-article basis.

Desirable / Low Yes

Evaluation Reporting RREQ-007 The system should provide data allowing a breakdown on a vendor-by-vendor basis giving the same statistics but identifiable by vendor.

Desirable / Low Yes

Evaluation Reporting RREQ-008 The system should provide data that contains information on the length of time a RADAR alert was on screen.

Desirable / Low Yes


of 30


Vendor Supported

Evaluation Reporting RREQ-009 The system should provide data that contains information if a prescription was written and for which drug after the document was accessed (YES/NO).

Desirable / Low Yes

Quick Non-Functional

NREQ-001 The new solution should be able to retrieve and display a RADAR article in the range of 50-500 ms.

Mandatory Yes

Flexible platform

Non-Functional

NREQ-002 The system should adhere to HL7 messaging.

Desirable / Medium

n/a

Low Risk Non-Functional

NREQ-003 The system should be available to clinical software users 24 hours, all year around. Less availability will only be acceptable if the system is able to degrade gracefully without affecting any of the other non RADAR features in the vendor’s application or impacting the user experience in any way.

Mandatory Yes

Reach Non-Functional

NREQ-004 The system should be usable for a user that is capable of performing basic tasks with the prescribing software; RADAR should not impose an added burden of difficulty.

Mandatory Yes

Impactful Non-Functional

NREQ-005 The system should consider the implications of an increase in the number of participating vendors and/or active users on NPS production and delivery processes and infrastructure.

The system does not need to consider scalability requirements regarding an increased number of RADAR documents (only 10-15 new RADAR documents shall be produced each year).

Mandatory n/a

Minimise cost

Non-Functional

NREQ-006 The solution should reduce cost over the next three to five year period.

Desirable / High n/a

Flexible platform

Vendor VREQ-001 An automatic, internet-based mechanism should exist to allow the vendors application to receive the latest RADAR update easily.

Desirable / High Specified by vendor


of 30


Vendor Supported

Flexible platform

Vendor VREQ-002 An automatic, internet-based mechanism should exist to allow the vendors application to receive the latest PILs update easily.


Flexible platform

Vendor VREQ-003 RADAR information will be provided in standards-compliant HTML and PDF


Flexible platform

Vendor VREQ-004 RADAR information in HTML should comply with W3C standards and will display correctly in the following browsers at a minimum.

1. Mozilla Firefox (latest)2. Internet Explorer 63. Internet Explorer 74. Internet Explorer 85. Apple Safari (latest)


Flexible platform

Vendor VREQ-005 A web services based model using SOAP protocol should be used for communication between RADAR system residing on NPS infrastructure and vendors application residing at a health professionals practice.



of 30

2. Business Context

2.1 Business Driver

The current delivery method involves distributing a file set, which is provided to clinical software vendors via a URL to download (3 times a year). The file set includes mapping files that map between MIMS drug codes and RADAR files. A solution is required that will reduce cost in the long term while improving usage reporting and update frequency, allowing for greater reach and integration with more vendors.

2.1.1 Current state

2.2 Business Intent

2.2.1 Purpose

The goals of the project are to:

Increase reach: Increase the number of health professionals that have ready access to RADAR information

Minimise cost: Minimise total cost of changes to the delivery mechanism (i.e. NPS effort and external cost over a five year period)

Reduce effort: Reduce the overall effort by NPS and its vendors Flexible platform: Provide a platform which can be expanded upon to deliver additional NPS information


of 30

services Maintain responsiveness: Ensure RADAR in prescribing software maintains acceptable responsiveness

for the user. Low Risk: For implementation Positive impact: The functionality of the system should have a positive impact to change the behaviour of

prescribers. Improve monitoring: Provide a way to ascertain the benefit of RADAR

2.2.2 Method

Based on these goals, the objectives of the project are to provide an improved delivery mechanism which:

Improves information delivery by providing a platform that can support, increased functionality, automatic updates of RADAR information.

Captures usage information for measuring effectiveness. Improve operational performance by reducing the ongoing operational risk and cost Mitigate technology risk by providing a supported platform to align technology, process and business

strategy.

2.2.3 End State

The solution will deliver the following benefits: Improved delivery model A standard coding system to reduce manual mapping effort Internet enabled distribution of RADAR information (new drug information and patient information leaflets) Low cost, flexibility and scalability.


of 30

3. Functional specification

3.1 User experience

NPS RADAR information is delivered primarily using an alert mechanism. To reduce the level of intrusion and alert fatigue, each drug alert is invoked up to 5 times only, and the user is able to cancel further pop up alerts. As the flow chart below describes, the RADAR alert is inserted into the existing prescribing workflow.


of 30

3.2 Functional Specification

3.2.1 Overview

This section specifies the requirements for integrating NPS documentation into clinical software. Currently, two types of documentation are available:

1. NPS RADAR documents

RADAR documents contain information about new medicines, new and revised listings on the Schedule of Pharmaceutical Benefits and relevant new research. NPS RADAR is published in line with major updates to the Schedule of Pharmaceutical Benefits with updates to files for clinical software currently made available 3 times per year.

2. NPS Patient Information documents

Patient Information Leaflets and Action Plans are produced by NPS as practical help for health professionals in communicating essential treatment messages to patients and are best used in conjunction with verbal communication during patient consultation. These cover a number of topics such as Chronic Obstructive Pulmonary Disease, Type 2 Diabetes, Upper Respiratory Tract Infections, and Antibiotics. They have been designed to be complementary to the Consumer Medicines Information (CMI) leaflets which contain specific information regarding a particular medication.

3.2.2 RADAR Documents

There are two components to integrating RADAR with clinical software:

1. Basic integration - linking to NPS RADAR documents:

via the NPS website (via a menu item or resources list)

within the clinical software

2. Advanced integration –linking RADAR documents to the drug database - providing direct access to each article via an alert mechanism, and possibly via a button or other contextual access for a particular drug

3.3 Basic Integration - Linking to NPS RADAR documents

3.3.1 Functional Requirements

3.3.1.1 1A. Providing a shortcut to RADAR on the NPS website via a menu item or resource listing

The user can access all RADAR documents via a menu or button. The user can browse all documents whenever they wish, and this can occur independently of the act of prescribing.

When user selects one of the NPS RADAR options from the Resources menu, the action opens a new web browser window (e.g. Microsoft Internet Explorer or Mozilla Firefox) with the target URL set to http://www.npsradar.org.au/

OR

3.3.1.2 1B. Providing continuous access to local RADAR documents via browser

The user can access all RADAR documents via a menu or button. The user can browse all documents whenever they wish, and this can occur independently of the act of prescribing.

As the user selects one of the NPS RADAR option from the Resources menu, they are provided with a window from which they can search for their document of choice (see Figure 1).


of 30

Figure 1. RADAR document browser window

The display of the set of RADAR documents will be within a web browser. An initiating page (frindex.htm) will be provided as part of the RADAR document set, which will allow navigation amongst the individual RADAR documents. The HTML documents will be the same files used in individual drug information provision.

frindex.htm is the initial hyperlink target for the RADAR document set.

3.4 Advanced Integration - also Linking NPS RADAR documents to the drug database


3.4.1.1 1. Linking of drugs to RADAR documents

A RADAR document may be linked to one or more generic drugs. For each drug, there may be separate RADAR documents for different dosage forms.

In addition, the links for each RADAR document are specified using drug codes, specified in an XML system index file.

3.4.1.2 2. Recognising a RADAR event

Proceeding with prescribing a generic or brand name for which a RADAR document exists may trigger a RADAR event (i.e. displaying a RADAR pop-up window or otherwise alerting the user to the fact that a RADAR review is available for this drug). Alternatively, it may enable a RADAR button.

If the RADAR event triggers an automatic modal window, then the software may record the number of times that a given user prescribes the drug, and limit the number of times that the RADAR window will automatically be displayed.

If implemented as a modal window, the RADAR window will contain a checkbox allowing the user to suppress further pop-ups for that particular medication. The pop-up feature will be able to be turned on and off globally via Preferences (see below) — the default will be to display the RADAR window as per the NPS specification.

3.4.1.3 3. Displaying a RADAR window via the RADAR button or after a RADAR event

When the RADAR button is enabled, clicking it will display a RADAR window.


of 30

This RADAR window should be approximately 750 × 550 pixels (see Figure 2). It may be a modal dialog window, but any automatically triggered display should be integrated in such a way as to minimally disrupt the workflow.

Figure 2 RADAR window

The contents of the summary window will be the <NDR doc>.htm file, displayed in a web browser (e.g. Internet Explorer) control.

The initial presentation will be controlled by the HTML format of the document, so the prescribing system only has to load the document and not be concerned with its presentation.

The summary window will contain a hyperlink to the corresponding full RADAR article, which may be opened in the same window or a separate browser window, as appropriate to the user interface and workflow.

3.4.1.4 4. Preferences

An additional Preference option should be added for RADAR, allowing the user to turn any pop-up feature on or off globally.

3.5 Patient Information Leaflets

Patient information leaflets (PILs) and action plans are developed by NPS or its member organisations. They help health professionals communicate essential treatment messages to their patients. These leaflets and action plans are complementary to Consumer Medicine Information leaflets, which contain specific information regarding a particular medication.

The user should be able to access any PIL file from the main navigation menu of the system. Patient information leaflet files will be provided as PDF documents for integration with GP system.

3.6 Basic Integration - Linking to NPS PILs documents


3.6.1.1 Providing continuous access to local PILs documents via browser

The user can access all PILs documents via a menu or button in the prescribing software. The user can browse all documents whenever they wish, and this can occur independently of the act of prescribing.

As the user selects the NPS Patient education option from the Resources menu, they are provided with a window from which they can search for their document of choice (see Figure 3).


of 30

http://www.nps.org.au/search_by_medicine_name

Figure 3. PIls document browser window

Clicking on document in the navigation menu will open the file in acrobat reader as a separate window.

Note: The above Figure 3 is only conceptual and would need to be built by the software vendor.


of 30

Figure 4. Patient information leaflet document displayed in Adobe Acrobat Reader

3.7 Usage data submission

At the end of each month NPS requires usage data to be submitted from each of user of the software for reporting purposes. Submission of such information should be approved by the user who can at any time opt out from submitting any further data or vice versa.


3.7.1.1 Providing a modal dialog when submitting usage data for the first time

The first time reporting data is being submitted to NPS from the GP software a modal window should appear to confirm authorization from the logged in user. Below is a conceptual user interface.

Figure 5. First time submission of usage data


of 30

3.7.1.2 Providing a configuration option for submitting usage data

The user should have the option to configure submission of usage data by turning it on or off. Below is a conceptual user interface.

Figure 6. Configuring submission of usage data


of 30

4. Solution Design

4.1 Solution overview

The solution design is divided into two parts. The first part describes three solution architectures in section 4.2 and the second part discusses the fixed elements of the solution design in section 5. Depending on vendor feedback, NPS may elect to develop (and support) one or more of the solution options below.

4.2 Solution elements with multiple design options

Information Delivery: NPS RADAR and patient information leaflet information may be delivered directly to the GP software from an NPS web server or via vendor software updates.

RADAR and PILS data storage: NPS information can be stored locally on the clinical software system to ensure optimum read and display speeds or, alternatively, downloaded on demand.

Reporting data submission: This option applies to solution architectures 1 & 3 only, in which the GP software submits usage reporting data via a web service. For solution architecture 2 NPS derives reporting data from on-demand access to RADAR information via the web service. See section 4. The user will be requested to confirm submission of reporting data to NPS.

4.3 Fixed aspects

Functional Design The application logic describing the user interaction with RADAR information is integrated into the vendor software. See section 3.

System Index File: NPS provides a file that allows mapping from the GP software drug codes to RADAR document URIs. See section 5.2.

The table below summarises the various options for each of the key aspects of the design, which are described in the three solution architectures below.

Locally cached information through web services

On demand access

Information updates via vendor software update process

Information delivery method

Web service

Vendor update RADAR and PILS data storage

Locally cached

Remote access (NPS infrastructure)

Reporting data submission Web service Captured via On Demand access

Application logic

Built In / Part of GP software

Advantages Avoids delay or

interruption of prescribing process due to Internet latency or loss of connectivity

No vendor effort or intervention required to

Avoids delay or interruption of prescribing process due to Internet latency or loss of connectivity.


of 30

No vendor effort or intervention required to keep NPS information up to date.

keep NPS information up to date.

Usage data does not need to be collected or reported by the GP software

Update mechanism uses existing functionality, minimising implementation costs.

4.4 Solution Architecture 1: Locally cached information through web services


of 30

This solution architecture uses a web service model to provide a regular batch update of NPS information in prescribing software.

NPS information is stored in a local file system cache on the GP software. This ensures that the prescribing process is not delayed due a slow or interrupted internet connection.

The GP software at the health care practice, polls the NPS web service regularly (e.g. daily) to check if the cached data is up to date. If an update is required it can be requested via an NPS web service.

4.4.1 Option summary

This solution architecture is based on the options in the table below.

Design aspect Option

Information Delivery Method Web Service

RADAR Information Storage Locally Cached

PILS Information Storage Locally Cached

Reporting Data Submitted directly from GP desktop or practice (mandatory)

4.4.2 NPS Information Flow


of 30

4.5 Solution Architecture 2: On demand access

This solution architecture delivers RADAR information on demand via a web service. RADAR and PILS data files are stored on NPS web server. The GP system uses the system index file to look up the unique identifier for any relevant RADAR or PIL information is available, and then requests it from the web service. Only the system index file is stored locally.


of 30

The GP software at the health care practice, polls the NPS web service regularly (e.g. daily) to check if the cached system index file is up to date.

In this architecture, NPS derives reporting data from use of the web service, and the vendor does not collect or deliver further usage data.



Information Delivery Method Web service

RADAR Information Storage Remote access (NPS infrastructure)

PILS Information Storage Remote access (NPS infrastructure)

Reporting Data NPS to gather information. No submission required by vendor.



of 30

4.6 Solution Architecture 3: Information updates via vendor software update process

This solution architecture relies on the vendor’s existing application updates by “slip-streaming” NPS information with scheduled vendor updates.

In this model NPS information is provided to the vendor (who would be acting as an intermediary) and then integrated into the vendor’s existing application update mechanism. RADAR, PILS and system index file would all


of 30

be provided as a single ‘package’ for use in the GP software.

Customers without internet access are also able to access NPS information by receiving them from vendor CD based updates.

This solution stores NPS RADAR and patient information leaflets in a local file set, similar to solution architecture 1.



Information Delivery Method Vendor Update

RADAR Information Storage Locally Cached

PILS Information Storage Locally Cached

Reporting Data Submitted directly from GP desktop or provided by vendor (optional)


4.7 Common Architecture decisions

These decisions are independent of which solution architecture is chosen and thus apply to all.


of 30

Ref Architectural Decision

AD1 Description: During the initial design discussions HL7 messaging standards to be used for RADAR were considered

Preferred Option: Use web services with an XML payload over the internetRationale: HL7 adding extra complexity without much benefitDecision: Web Services

AD2 Description: For delivery of content both push and pull method have been consideredSelected Option: Pull methodRationale: Pushing content to consumers requires an intermediary directory service

to locate end points between NPS and practices. Currently the infrastructure does not exist to support this method.

Decision: Pull method


of 30

5. Fixed aspects of the design

5.1 Overview

This section of the document describes those aspects of the design which are same irrespective of which solution architecture is selected.

5.2 System Index File

The system index file will contain information about RADAR and PILs documents.

RADAR The system index file is a table that maps from drug codes to NPS document URI. In the case of RADAR documents, there will be separate URIs for the RADAR summary and the RADAR detail files. The system index file will be provided in XML.

PILS The system index file would contain the following 3 pieces of information about each PILs document.

1. Document Title.2. File Name.3. URL

Document Title: this information is used by GP softwares for display on screen purpose.File Name: This will be unique for each PIL document and will be the identifier for a fileURL : This will be the full URL for downloading the file from NPS web server, examplehttp://www.nps.org.au/PILS/current_assets/Opioids_PIL.pdf

5.3 Drug Coding

The system index file includes drug codes for multiple drug coding schemes in an extensible way. NPS will support MIMS and AMT initially.

5.4 Reporting Data Format

Reporting data can be provided in flat file format such as a comma separated file.

The content of the data should contain information specified in section 1.4.1 (RREQ-001 to RREQ-009). The format will be specified in the low-level solution design.

5.5 NPS information format

The table below lists the various formats for NPS information. NPS will also supply graphics files, CSS, and JavaScript to provide a standard presentation of RADAR documents. Some RADAR documents will also incorporate graphics files.

Information Type Formats

RADAR summary article file HTML

RADAR full article file HTML, PDF

Patient Information Leaflets PDF

System index file XML

5.6 Security

RADAR, PILs and system index file will be transferred over a secure connection using Secured Socket Layer technology and appropriate certificates.


of 30

http://www.nps.org.au/PILS/crrentassets/Opioids_PIL.pdf

6. Technical Design

6.1 Locally cached information through web services

6.1.1 Use Cases

6.1.2 Activity diagrams

Two key activity diagrams have been detailed to assist in the communication of the solution.

The flow and interactions need to be reviewed during the detailed design process. This is the suggested approach and is used as a starting point.


of 30

This activity can be implemented using a HTTP GET transaction with a predefined URI and “If-modified-since” cache logic. The vendor identifier would be included in the HTTP user-agent string.


of 30

This activity can be implemented using a HTTP PUT or POST transaction with a predefined URI or with SOAP (details to be specified). The vendor identifier would be included in the HTTP user-agent string. The format for reporting data is to be specified.


of 30

6.2 On demand access

6.2.1 Use Cases


Refer to section 6.1.2, Activity diagram 01 vendor check for updates

6.3 Information updates via vendor software update process

6.3.1 Use Cases


Refer to section 6.1.2 Activity diagram 02 vendor submits reporting data.


of 30

high level solution design v1 0

Documents

nps radar information

document purpose

business context

business driver

business intent

project scope

project overview

current state