BusinessRequirements_RADAR v1 1

BUSINESSREQUIREMENTS DOCUMENT

RADAR information delivery to clinical software options

VERSION: 1.1 DATE: 22/07/2010

Authorised by:

Name Title Signature Date

By approving this deliverable, each individual agrees that the requirements as captured in this document accurately reflect the current understanding of business requirements and system design can be undertaken in line with these requirements.

Once authorised, any changes to these requirements will be governed by the project’s change management process, which will include impact analysis, appropriate reviews and approvals mandated via the Project Governance structure (and according to the NPS Project Management Framework guidelines).

Key ContactsIdentify and provide contact information for the key contacts for the project.

Project Sponsor Title/Team Extn/Phone Email

Alice Bhasale Deputy Manager, Medicines Information (02) 8217 [email protected]

Stakeholder Title/Team Extn/Phone Email

Malcolm Gillies Medical Writer, Medicines Information (02) 8217 8723 [email protected]

Business Analyst Title/Team Extn/Phone Email

Jehangir Rizvi Senior Business Analyst, PDS, NPS (03) 9412 5519 [email protected]

Revision History

Version Date Author Description

0.1 13/04/2010 J.Rizvi Initial draft

0.2 05/05/2010 J.Rizvi Added reporting requirements

0.3 06/05/2010 J.RizviAdded new sections (requirements scope , non functional requirements,) to the template. Added content to all sections.

0.4 10/05/2010 J.Rizvi Added requirements for patient information leaflet.

0.5 13/05/2010 J.Rizvi Added functional requirements.

0.6 14/05/2010 J.Rizvi Incorporated changes requested by sponsor.



0.9 22/06/2010 J.RizviAdded vendor requirements to section 7 and RADAR production timeline to section 5.2

1.0 05/07/2010 J.Rizvi Created release version for review and feedback.

1.1 22/07/2010 J.Rizvi Add sections

RADAR INFORMATION DELIVERY TO CLINICAL SOFTWARE BUSINESS REQUIREMENTS DOCUMENT

TABLE OF CONTENTS

1 Document Purpose..............................................................................................................3

2 Document Resources........................................................................................................3

2.1 Related Documents................................................................................................................................. 3

3 Project Overview................................................................................................................4

3.1 Stakeholders........................................................................................................................................... 4

4 Key Assumptions and Constraints..................................................................................4

4.1 Key Assumptions and Constraints...........................................................................................................4

5 CURRENT SITUATION.............................................................................................................5

5.1 Radar Production Process....................................................................................................................... 5

5.2 Radar Production Timeline and effort......................................................................................................8

5.3 Patient information leaflet Production Process........................................................................................9

6 REQUIREMENTS SCOPE........................................................................................................10

6.1 In Scope................................................................................................................................................ 10

6.2 Out of Scope......................................................................................................................................... 10

7 Business Requirements..................................................................................................11

7.1 Project Goals......................................................................................................................................... 11

7.2 Requirements........................................................................................................................................ 11

8 Business Glossary..........................................................................................................15

© 2010 NPS Business Requirements Document Page 2


1 Document Purpose

This document defines the requirements for delivering RADAR information to clinical software systems. It will be used as the basis for the following project activities:

Record internal business requirements. Record external vendor requirements. Guide the analysis of options to improve the impact of RADAR information.

2 Document Resources

Name Team Project Role

Alice Bhasale Medicines Information StakeholderMalcolm Gilles Medicines Information StakeholderJames Reeves Pharmaceutical Decision Support Stakeholder

2.1 Related Documents

The following documents are also to be considered alongside this document:Document Description

PMP Project Management Plan



3 Project Overview

3.1 StakeholdersThe following comprises the internal and external stakeholders whose requirements are represented by this document:

# Stakeholders

1 Medicines Information Team

2 Pharmaceutical Decision Support

3 Hatrix / iSoft

4 Medtech Global

5 Genie Solutions

6 Health Communication Network

7 Best Practice

8 Fred IT Group

9 MIMS

10 Australian Medicine Handbook (AMH)

4 Key Assumptions and Constraints

4.1 Key Assumptions and Constraints

# Assumptions1 There is no decision support functionality.

# Constraints

1 The publishing business processes cannot be altered and will remain as is.



5 CURRENT SITUATION

5.1 Radar Production Process





Step No.

Process Step Role/Team Process Step Description

Start

1. Topic allocation NDWG Topic allocation by NDWG.

2. Assign task to author

MI team Identify and contact external expert reviewers and sponsor, requesting review and advising of timelines.

3. Develop content using SISMO template

MI team Develop content using SISMO template. Generate version for SISMO which involves completing release information (metadata). Format references. Check that hyperlinks work. Check adverse reporting statement. Remove any headers, footers or watermarks and review document against SISMO checklist.

3a. Internal review of document

MI Manager and team

Send to MI team/manager for internal review.

3b. Amend document MI team Amend document based on feedback from MI team and Manager and send to NDWG 1 week before face-to-face meeting.

3c. Face to face meeting to review document

NDWG NDWG meets to review document, approximately 10 wees after PBAC meeting.

Face to face meeting with NDWG to review document.

3d. Amend document based on comments from NDWG

MI team Amend document based on feedback from NDWG and send to expert reviewer and sponsor for 5-day review.

3e. Review document Expert reviewer

Review document.

3f. Review document Sponsor Review document.

3g. Amend document MI team Amend document based on feedback from project sponsor & expert reviewer.

3h. Send document for final review

MI team Send to NDWG, project sponsor, DoHA and publishing for final review.

3i. Review document NDWG Review document.

3j. Review document DoHA Review document.

3k. Review document Publishing Review document.

3l. Review document Sponsor Review document.

3m. Amend document with publication subedits

MI team Amend document based on feedback from final review with publication subedits.

4. Send file to Julian MI team Send to Julian to SISMO with Endnote library.

5. Using SISMO generate HTML

Publishing Julian using SISMO makes metadata changes directly to his copy of the final source doc and then sends a link to the HTML version, to the author for proofing.

6. Author proof reads HTML

MI team The author can accept/reject the changes, add any of their own and send to Julian confirmation by email.

7. Any changes Publishing Determine for proofing – changes need or no changes needed



Step No.

Process Step Role/Team Process Step Description

needed? Changes needed – go to step 8

No changes needed – go to step 9

8. Amend source document

Publishing Julian ensures that all final changes are reflected in the source word document and saves file and sends to PDS.

9. Using SISMO produce documents

PDS Bryn produces documents from source using SISMO.

10. Front page (web format)

MI team Send front page (web format) to PDS.

11. Zip document PDS Bryn zips following documents – front page, TOC, final PDFs, XML drug links (drug %20 descriptions.htm), XML summary, XML full, HTML summary, HTML full.

12. Upload to NPS dev website

PDS Bryn creates a new URL on dev.nps website and copies zipped documents to this and Bryn informs MI of the URL.

13. Email website link to vendors

MI MI emails website link to HCN and Genie. (No security)

HCN – 3 days before beta CD is to be released i.e. 3/3, 3/7, 3/11

Genie – 2 weeks prior to final version release date.

14. Download files & END

Genie Downloads front page, TOC, XML drug links (drug %20 descriptions.htm), XML summary, XML full from dev.nps website.

15. Download files HCN Downloads front page, TOC, HTML summary, HTML full, final PDF’s from dev.nps website and create beta CD.

16. Send beta CD HCN Send out beta CD to MI for testing.

17. Organise IT to install

MI team Organise IT to install beta CD.

18. Test CD MI team Test for new radar listings, if ‘NPS Radar’ button appears when you prescribe and pop-up summary is displayed with the option to display full details.

19. Pass? MI team Yes – go to step 21

No – loops steps 20, 16, 17 & 18 until passed.

20. Fix up issue HCN Resolve issue and send out beta CD again for testing.

21. Release CD & END

HCN CD ready to be released.

End



5.2 Radar Production Timeline and effort

Radar release dates are 3 times a year:

1. April2. August3. December

Pharmaceutical Benefits Scheme release dates are monthly.

Unit/Team Period Full time effortNew drugs working group 2-3 weeks 4 daysPublishing 2 months 2-4 weeksMedicines information Up to 8 weeks full-time effort per article (1-2 articles

per MI author) for first draft.

Medicines information Up to 3 weeks full-time effort per article for reviewing (spread over 5 weeks).

Pharmaceutical Decision Support

1 week 1-2 days



5.3 Patient information leaflet Production Process



6 REQUIREMENTS SCOPEThis section shows what business functionality is in scope and out of scope for Implementation.

6.1 In Scope Requirements gathering and documentation Conceptual solution design Options analysis recommendation

6.2 Out of Scope Changes to production business process for Patient information leaflets. Implementation of the recommended solution options



7 Business RequirementsThe following section documents the various business requirements of this project.

7.1 Project GoalsIncrease reach: Increase the number of health professionals that have ready access to RADAR informationMinimise 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 vendorsFlexible platform: Provide a platform which can be expanded upon to deliver additional NPS information servicesMaintain responsiveness: Ensure RADAR in prescribing software maintains acceptable responsiveness for the user.Low Risk: For implementationPositive impact: The functionality of the system should have a positive impact to change the behavior of prescribers.Improve monitoring: Provide a way to ascertain the benefit of RADAR

7.2 Requirements

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




Vendor Supported

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

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




Vendor Supported

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 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

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




Vendor Supported

Flexible platform

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

Specified by vendor

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)

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


8 Business Glossary

Term/Acronym Definition

RADAR rational assessment of drugs and researchPIL patient information leafletSNOMED CT systematized nomenclature of medicine -- clinical termsAMT Australian medicines terminology

16

BusinessRequirements_RADAR v1 1

Documents

functional requirements

vendor requirements

reporting requirements

rizvi incorporated changes

rizvi initial draft

medicines information

business glossary

contact information