Idea Transcript
SlideShare Explore Search You
Upload Login Signup
Search
Submit Search
Home Explore Presentation Courses PowerPoint Courses by LinkedIn Learning Search Successfully reported this slideshow.
Table of Contents High Level Solution Design................................................................................. 5.1 Overview................................................................................................................. Introduction 1.1 Document Purpose The purpose of this document is to describe the high level solution design (HLSD) for th... 1.3 Audience The intended audience of this document includes: • Project sponsor & Steering Committee • Pharmaceutical deci... Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported Reach Business BREQ-005 The solution should u... Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported Evaluation Reporting RREQ-002 The system shou... Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported Low Risk Non- Functional NREQ-003 The system ... Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported Flexible platform Vendor VREQ-004 RADAR infor... 2. Business Context 2.1 Business Driver The current delivery method involves distributing a file set, which is provided to... services • Maintain responsiveness: Ensure RADAR in prescribing software maintains acceptable responsiveness for the user.... 3. Functional specification 3.1 User experience NPS RADAR information is delivered primarily using an alert mechanism. To ... 3.2 Functional Specification 3.2.1 Overview This section specifies the requirements for integrating NPS documentation into... Figure 1. RADAR document browser window The display of the set of RADAR documents will be within a web browser. An initiat... This RADAR window should be approximately 750 × 550 pixels (see Figure 2). It may be a modal dialog window, but any automa... Figure 3. PIls document browser window Clicking on document in the navigation menu will open the file in acrobat reader as... Figure 4. Patient information leaflet document displayed in Adobe Acrobat Reader 3.7 Usage data submission At the end of e... 3.7.1.2 Providing a configuration option for submitting usage data The user should have the option to configure submission... 4. Solution Design 4.1 Solution overview The solution design is divided into two parts. The first part describes three sol... loss of connectivity • No vendor effort or intervention required to keep NPS information up to date. keep NPS information ... This solution architecture uses a web service model to provide a regular batch update of NPS information in prescribing so... 4.5 Solution Architecture 2: On demand access This solution architecture delivers RADAR information on demand via a web se... The GP software at the health care practice, polls the NPS web service regularly (e.g. daily) to check if the cached syste... 4.6 Solution Architecture 3: Information updates via vendor software update process This solution architecture relies on t... be provided as a single ‘package’ for use in the GP software. Customers without internet access are also able to access NP... Ref Architectural Decision AD1 Description: During the initial design discussions HL7 messaging standards to be used for R... 5. Fixed aspects of the design 5.1 Overview This section of the document describes those aspects of the design which are s... 6. Technical Design 6.1 Locally cached information through web services 6.1.1 Use Cases 6.1.2 Activity diagrams Two key ac... This activity can be implemented using a HTTP GET transaction with a predefined URI and “If-modified-since” cache logic. T... This activity can be implemented using a HTTP PUT or POST transaction with a predefined URI or with SOAP (details to be sp... 6.2 On demand access 6.2.1 Use Cases 6.2.2 Activity diagrams Refer to • section 6.1.2, Activity diagram 01 vendor check fo... Upcoming SlideShare Loading in …5 × 1 of 31
High Level Solution Design v1 0 6,033 views Share Like Download ...
Jehangir Rizvi Follow Published on May 28, 2015
0 Comments 3 Likes Statistics Notes
Full Name Comment goes here. 12 hours ago Delete Reply Spam Block Are you sure you want to Yes No Your message goes here
Share your thoughts… Post Be the first to comment
JamesPolisMBAStanfor 2 weeks ago
belisario dongiovanni , Software developer and System administrator of web/mobile solutions at Geotel s.c. at Software developer and System administrator of web/mobile solution 1 month ago
Pimpar K. , Software Engineer at e-Synergy (Thailand) Co., Ltd. at e-Synergy (Thailand) Co., Ltd. 3 months ago No Downloads Views Total views 6,033 On SlideShare 0 From Embeds 0 Number of Embeds 15 Actions Shares 0 Downloads 228 Comments 0 Likes 3 Embeds 0 No embeds No notes for slide
High Level Solution Design v1 0 1. 1. 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 software Confidential High Level Solution Design (HLSD) Page 1 of 31 2. 2. Table of Contents High Level Solution Design....................................................................................................................................1 MI0002: RADAR Information Delivery to Clinical Software Options Analysis...................................................1 .................................................................................................................................................................................... 1 Jay Rizvi.................................................................................................................................................................. 1 Document Date: v1.0 28/07/2010............................................................................................................................1 Table of Contents.................................................................................................................................................... 2 Introduction............................................................................................................................................................. 4 Introduction............................................................................................................................................................. 4 1.1 Document Purpose..................................................................................................................................4 1.2 Project Overview.....................................................................................................................................4 1.3 Audience.................................................................................................................................................. 5 1.4 Project Scope..........................................................................................................................................5 1.4.1 In Scope............................................................................................................................................... 5 2. Business Context............................................................................................................................................... 10 2.1 Business Driver.....................................................................................................................................10 2.1.1 Current state.......................................................................................................................................10 2.2 Business Intent......................................................................................................................................10 2.2.1 Purpose..............................................................................................................................................10 2.2.2 Method............................................................................................................................................... 11 2.2.3 End State............................................................................................................................................ 11 3. Functional specification....................................................................................................................................12 3.1 User experience....................................................................................................................................12 3.2 Functional Specification.........................................................................................................................13 3.2.1 Overview............................................................................................................................................ 13 3.2.2 RADAR Documents............................................................................................................................13 3.3 Basic Integration - Linking to NPS RADAR documents.........................................................................13 3.3.1 Functional Requirements....................................................................................................................13 3.4 Advanced Integration - also Linking NPS RADAR documents to the drug database ...........................14 3.4.1 Functional Requirements....................................................................................................................14 3.5 Patient Information Leaflets...................................................................................................................15 3.6 Basic Integration - Linking to NPS PILs documents...............................................................................15 3.6.1 Functional Requirements....................................................................................................................15 3.7 Usage data submission.........................................................................................................................17 3.7.1 Functional Requirements....................................................................................................................17 4. Solution Design ................................................................................................................................................. 19 4.1 Solution overview...................................................................................................................................19 4.2 Solution elements with multiple design options.....................................................................................19 4.3 Fixed aspects........................................................................................................................................19 4.4 Solution Architecture 1: Locally cached information through web services............................................20 4.4.1 Option summary ................................................................................................................................21 4.4.2 NPS Information Flow.........................................................................................................................21 4.5 Solution Architecture 2: On demand access..........................................................................................22 4.5.1 Option summary.................................................................................................................................23 4.5.2 NPS Information Flow.........................................................................................................................23 4.6 Solution Architecture 3: Information updates via vendor software update process ...............................24 4.6.1 Option summary ................................................................................................................................25 4.6.2 NPS Information Flow.........................................................................................................................25 4.7 Common Architecture decisions............................................................................................................25 5. Fixed aspects of the design..............................................................................................................................27 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 2 of 31 3. 3. 5.1 Overview................................................................................................................................................ 27 5.2 System Index File .................................................................................................................................27 5.3 Drug Coding.......................................................................................................................................... 27 5.4 Reporting Data Format..........................................................................................................................27 5.5 NPS information format.........................................................................................................................27 5.6 Security.................................................................................................................................................. 27 6. Technical Design .............................................................................................................................................. 28 6.1 Locally cached information through web services .................................................................................28 6.1.1 Use Cases..........................................................................................................................................28 6.1.2 Activity diagrams................................................................................................................................28 6.2 On demand access ...............................................................................................................................31 6.2.1 Use Cases..........................................................................................................................................31 6.2.2 Activity diagrams................................................................................................................................31 6.3 Information updates via vendor software update process .....................................................................31 6.3.1 Use Cases..........................................................................................................................................31 6.3.2 Activity diagrams................................................................................................................................31 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 3 of 31 4. 4. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 4 of 31 5. 5. 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 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 5 of 31 6. 6. Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported 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 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 6 of 31 7. 7. Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported 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 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 NonFunctional 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 7 of 31 8. 8. Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported 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 Flexible platform Vendor VREQ-002 An automatic, internet-based mechanism should exist to allow the vendors application to receive the latest PILs update easily. Desirable / High Specified by vendor Flexible platform Vendor VREQ-003 RADAR information will be provided in standards-compliant HTML and PDF Desirable / High Specified by vendor © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 8 of 31 9. 9. Goal Type Number Requirement Mandatory/ Desirable/ Priority Vendor Supported 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 6 3. Internet Explorer 7 4. Internet Explorer 8 5. Apple Safari (latest) Desirable / High Specified by vendor 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. Desirable / High Specified by vendor © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 9 of 31 10. 10. 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 10 of 31 11. 11. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 11 of 31 12. 12. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 12 of 31 13. 13. 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). © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 13 of 31 14. 14. 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 Functional Requirements 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 14 of 31 15. 15. 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 .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 Functional Requirements 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). © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 15 of 31 16. 16. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 16 of 31 17. 17. 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 Functional Requirements 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 17 of 31 18. 18. 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 18 of 31 19. 19. 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 • No vendor effort or intervention required to • Avoids delay or interruption of prescribing process due to Internet latency or © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 19 of 31 20. 20. loss of connectivity • 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 loss of connectivity. • Update mechanism uses existing functionality, minimising implementation costs. 4.4 Solution Architecture 1: Locally cached information through web services © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 20 of 31 21. 21. 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 21 of 31 22. 22. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 22 of 31 23. 23. 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. 4.5.1 Option summary Design aspect Option 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. 4.5.2 NPS Information Flow © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 23 of 31 24. 24. 4.6 Solution Architecture 3: Information updates via vendor software update process This solution architecture relies on the vendor’s existing application updates by “slipstreaming” 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 24 of 31 25. 25. 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. 4.6.1 Option summary Design aspect Option 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.6.2 NPS Information Flow 4.7 Common Architecture decisions These decisions are independent of which solution architecture is chosen and thus apply to all. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 25 of 31 26. 26. 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 internet Rationale: HL7 adding extra complexity without much benefit Decision: Web Services AD2 Description: For delivery of content both push and pull method have been considered Selected Option: Pull method Rationale: 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 © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 26 of 31 27. 27. 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 file URL : This will be the full URL for downloading the file from NPS web server, example http://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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 27 of 31 28. 28. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 28 of 31 29. 29. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 29 of 31 30. 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. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 30 of 31 31. 31. 6.2 On demand access 6.2.1 Use Cases 6.2.2 Activity diagrams 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 6.3.2 Activity diagrams Refer to section 6.1.2 Activity diagram 02 vendor submits reporting data. © NPS RADAR information delivery to clinical software Confidential High Level Solution Design (HLSD) Page 31 of 31 Recommended
Test Prep: GRE Online Course - LinkedIn Learning
Visual Thinking Strategies Online Course - LinkedIn Learning
Learning Management Systems (LMS) Quick Start Online Course - LinkedIn Learning
Solution design & procurement approach v1 Doug Walters
Workshop de Value Proposition Design v1 DTStartups
Structured Approach to Solution Architecture Alan McSweeney
Java Source Code for simulating Student login to Class Allocation system Jehangir Rizvi
JMeter Installation Instructions Jehangir Rizvi
BusinessRequirements_RADAR v1 1 Jehangir Rizvi
AI and Machine Learning Demystified by Carol Smith at Midwest UX 2017 Carol Smith English Español Português Français Deutsch About Dev & API Blog Terms Privacy Copyright Support
LinkedIn Corporation © 2017 × Share Clipboard × Email
Enter email addresses Add a message From
Send Email sent successfully.. Facebook Twitter LinkedIn Link Public clipboards featuring this slide
×
No public clipboards found for this slide ×
Save the most important slides with Clipping Clipping is a handy way to collect and organize the most important slides from a presentation. You can keep your great finds in clipboards organized around topics. Start clipping No thanks. Continue to download. Select another clipboard ×
Looks like you’ve clipped this slide to already. Search for a clipboard Create a clipboard
You just clipped your first slide! Clipping is a handy way to collect important slides you want to go back to later. Now customize the name of a clipboard to store your clips. Name* Best of Slides
Description Add a brief description so others know what your Clipboard is about. Visibility Others can see my Clipboard Cancel Save Save this documentTap To Close