Ophthalmology Specialist Support Business Requirements Document Version 1 Status: Final Draft Author: Daniel Sin, OSCAR EMR Date: 30/07/2014

Transcription

1 Ophthalmology Specialist Support Business Requirements Document Version 1 Status: Final Draft Author: Daniel Sin, OSCAR EMR Date: 30/07/2014

2 Document Revision History Version Date Changed By Change /12/2014 Daniel Sin Add requirements retroactively beginning by understanding functionality in 12.1 version. This will be follow by discussing changes by different pilots from OSPs /23/2014 Daniel Sin Adding another Eyeform implementation information taken from their website /08/2014 Daniel Sin Updating physician interview information including preferences and recommendations /24/2014 Daniel Sin Updating another clinic interview feedbacks and provide recommendation 1 07/30/2014 Daniel Sin Touch ups on final draft of Business Requirement Document Document Review History Version Date Changed By Change

3 1 Introduction There were numerous of Ophthalmology enhancements since it was first started developed in A few OSPs have been enhancing the functionality further by working with leading Ophthalmologists in terms of pilots. The multiple pilots have created diversions in the OSCAR EMR functionality and code that must integrate back to the main trunk of OSCAR EMR (OSCAR 14 Master). This document is an attempt to document the functionality and identify integration recommendations of the Ophthalmology versions into the OSCAR 14. Moving forward, with the help of the OSPs, OSCAR EMR will help define a set of functionality that is available to all Ophthalmologists in a general release of OSCAR. OSCAR EMR believes this initiative will eliminate duplicate efforts from the OSCAR community and encourage the collaboration of the OSPs and user groups. 1.2 Project Overview This initiative is to gather the requirements for Ophthalmology function that was developed by a number of OSPs as pilot projects and coordinate the consolidation effort of the functionality back to OSCAR 14. Each of the OSPs has worked with one or more Ophthalmology clinics to customize OSCAR functionality to their work flow, user interface and data requirements. It is necessary to understand the functions in each of the different versions to sort out the common set. This project will also try to gather the feedback from the physicians that are key stakeholders in driving the enhancements before finalizing the Ophthalmology functionality to OSCAR 14. The OSCAR pilot process specifies that it is the responsibilities of the OSPs to contribute resources to merge the code into OSCAR 14. Once the requirements are finalized, OSCAR EMR will facilitate the collaboration of OSPs to merge the source code back to the main trunk of OSCAR. 1.3 Assumptions The OSPs has based/updated their Ophthalmology enhancements on 12.1 of OSCAR EMR code The OSPs will corporate and contribute the code back to OSCAR EMR Ability to contact the Physicians and discuss some of the workflow and requirements. OSPs and piloting clinics are aware of the commitments that they are required to contribute and integrate the code back to OSCAR EMR main trunk per the affiliation agreement. OSCAR EMR will facilitate the code integration to minimize integrate efforts among the OSPs It is critical to integrate the functionality of Ophthalmology to future versions of OSCAR EMR 1.4 References/Inputs There are a number of different Ophthalmology implementations by a number of OSPs. This project has reviewed the following implementations

4 Original Ophthalmology version call eyeform that is available on A version and a few of its variations from OSCAR Services A version implemented by Prylyn which was an enhanced version developed by Indivica Did not get access to an version of Ophthalmology implementation by Indivica but able to review partial functionality from their website 2 Process Flows Pending documentation with clinics. 3 Requirements Definition 3.1 Approach OSCAR EMR has taken the initiatives to interview each of the contributing OSPs to review their version of the Ophthalmology implementation. The requirement gathering process had to start from the ground up as there were no documentations at all for what has been done. A number of interviews, demonstration and communications have been done with the help of the OSPs. The requirement tables below captured the current functionality. The requirements have also been reviewed by the lead Ophthalmologists that help drive the enhancements. Some of the requirements will be dropped from eisting pilots for the purpose of integrating back to OSCAR 14. They will be specified at the notes section of the requirements. The approach to integrate the functionality is to preserve the business logics that are critical to the eisting pilot clinics while in the meantime minimize further changes to limit integration efforts. The requirements will be the foundation of the Ophthalmology functionality that will be incorporate into OSCAR 14.

5 3.2 Business Requirements The business requirements of different Ophthalmology versions are captured in the following tables. The requirements captured are intended to be in a high level that described business needs of the Ophthalmology functionality. These requirement tables captured the difference of the Ophthalmology functionalities from eisting OSCAR releases functionality. It is not intended to show all OSCAR requirements. To understand general OSCAR functionality, please refer to other business requirement and training documents. The requirements have additional identifiers to show if each the requirement eists in different OSP versions of the Ophthalmology code. The title Origin means the original Ophthalmology version developed by McMaster, OS denotes OSCAR Service, P denotes Prylyn s, Id denotes Indivica version. BR ID Requirements Statement details Notes Origin. OS P Id* BR001 Allow Ophthalmology specialties data to be entered in Patient summary screen easily. Patient summary screen with should be ready for data input when open. BR002 Ability to enter Ophthalmology measurements (Vision Pretest - P) or (Vision assessment and Vision measurements - OS) on patient summary page implemented as eyeform. OS has separated the measurement in two sections with additional measurements totalling 62 fields. Additional fields including OU sections, Int values in Vision assessment Cyclo values and M values for near and dist. Current Patient summary requires the opening of sections and not efficient for data entry. 22 fields - P see figure 2 screen shot or 62 fields see fig. 3 -OS BR003 Implement copy and paste functions in vision measurement to copy AR values to M and Cyclo measurement fields. Also implement clear function to reset all field values. BR004 Ability to enter Ophthalmology measurements (Vision Manifest P) or 18 fields P, figure 1 or (Glass History-OS) on patient summary page implemented as figure 3 OS 24 fields eyeform. Glass history should support different type pf glasses (reading, Bi-focal etc.) and a date on the prescription.

6 BR005 Allow multiple Glass histories to be entered and the ability to copy functions to copy from values AR. Partially covered under Vision manifest of the original eyeform. This is used by technicians most of the time. BR006 Ability to enter Ophthalmology measurements - IOP on patient summary page implemented as eyeform. The date and time of measurement should be capture for the measurement. 6 fields BR007 Ability to enter Ophthalmology measurements Special eam in P or Other eam in OS on patient summary page implemented as eyeform. OS section included OU data entry (transport Canada requirements). 10 fields for P or 14 fields for OS. BR008 Ability to enter Ophthalmology measurements EOM/Stereo on patient summary page implemented as eyeform BR009 Ability to enter Ophthalmology measurements Anterior Segment on patient summary page implemented as eyeform. System includes normal and clear function to set section values. BR010 Ability to enter Ophthalmology measurements Posterior Segment on patient summary page implemented as eyeform. System includes normal and clear function to set section values. Single free tet field 18 fields 10 fields BR011 Ability to enter Ophthalmology measurements Eternal P or Eternal/Orbit on patient summary page implemented as eyeform. OS has separate eyelid data to the Eyelid/NLD measurement section. 10 fields for P or 6 fields for OS BR012 Ability to enter Ophthalmology measurements NLD on patient summary page implemented as eyeform. OS has included eyelid 6 fields for P. 14 fields for OS

7 information and added Lac lake and Irrig fields for both OD and OS in the section. OS system includes normal and clear function to set section values. BR013 Ability to enter Ophthalmology measurements Eyelid Measurements on patient summary page implemented as eyeform. OS has two entries for Lid mergins which include MRD and ISS values. It also has a substitute section of Schimer with Inferior Scleral show. 14 fields for P and 16 fields for OS BR014 Ability to enter Ophthalmology measurements Orbit on patient 4 fields for P and 6 files summary page implemented as eyeform. OS has added face values to for OS. the section called Eternal/Orbit. Faces values comes from eternal section of the original form. BR015 Ability to enter Ophthalmology measurements Reflective on patient summary page implemented as eyeform. OS system includes normal and clear function to set section values. BR016 Ability to enter Ophthalmology measurements Duction/Diplopia on patient summary page implemented as eyeform including OU measurements. OS system includes normal and clear function to set section values. 8 fields related to laser vision correction. It should be a configurable section if possible. 18 fields. This information is covered under EOM Stereo in the original eyeform. BR017 Ability to enter Ophthalmology measurements Deviation Measurement on patient summary page implemented as eyeform. OS system includes normal and clear function to set section values. BR018 Support care plan on patient summary page, allow the plan to be arranged, generate note for discharge, STAT/PRN, optom routine 10 fields. This information is covered under EOM Stereo in the original eyeform

8 options. BR019 The system should allow the information on the patient summary page to be Saved, Saved and Eit, Sign, Save & Eit or Sign, Save & Bill. BR020 The various sections on eyeform can be epanded with one click or each section can be epanded or shrink individually. A link to click to save the eform values. BR021 Current History, Past Ocular History (Past Eye History), Diagnostic Notes (Research/Notes) and Medical History sections should be considered as frequently used sections of patient summary. They should be open and available for data entry on the landing screen. This should be configurable in OSCAR 14. Clinics capture current history for every visit. BR022 In addition to the four frequently used sections on BR013, Family History, Eye medications, Other medications, Other communications and Patient logs should also be considered as frequently used sections of patient summary. They should be open and available for data entry on the landing screen. BR023 For open data fields, highlight data that has been entered recently. User should be able to adjust the time for the highlight. BR024 All epandable sections should be arranged on the one side of the patient summary screen. Preferable on the left side of the screen. E.g. Highlight data that has been entered for the past X hours BR025 The epandable sections or modules should be ordered from top down Sections should follow as follows: Allergies, Prescriptions, Specs History, Procedures, Lab the epandable rule of Results, Diagrams/ EForms, Documents, Billing, measurements, Tickler, eisting OSCAR.

9 Messages, Consultations, Consultation Reports, and Macros. BR026 Impression History should be shown in a separate section as shown in Fig. 1. It should be scrollable when there are much data with the window displaying the latest history. BR027 Impression entry should have its own data entry section. It should also have the ability to copy the last impression, indicate no change and indicate the patient is stable. Instead as a button to open the section. BR028 The epandable sections or modules should be ordered on both sides of This may not carry back the patient summary screen. On the left side from the top are Patient to OSCAR 14 based on log, View tickler, Oscar Msg, Documents, Diagrams, Photos, Lab Result, UI designed Measurements, Appointment History, Eamination History, Billing requirements. History, Macro. On the right side of the screen from the top down they Other meds are used are Family history, Allergies, Pregnancies, ZEISS forum viewer, Ocular only for reference. It is Meds, Other Meds, Medications, Ocular Procedures, Consultations, not entered as Consultation report, EForms, Forms. medication but a one line tet that shows medication history. BR029 The number of open sections for data entry on Patient Summary screen should be configurable. BR030 Automation of canned functions should be supported by users specifying the action via Macros. The Marco definition section should include Impressions and Follow up, Billing etc. BR031 ZEISS forum viewer epandable section should allow data entry captured in Zeiss observation results.

10 BR032 Additional save button on top of the display to save user from scrolling BR033 Map EF form data entry to Encounter form to avoid duplication and improve user interface Id version of eyeform has enabled both EF and E on scheduling page. This could confuse user. This change will not carry forward to OSCAR 14. BR034 On consultation Pertinent clinical information, add ability to add information to the consultation. They are Past Ocular History, Specs History, Diagnostic notes, Ocular Procedures, Impression/Plan while dropped ongoing concerns, medications, additional notes etc. BR035 Support Signature, additional Fa recipient information to the Consultation request. BR036 Support the addition of any of the measurement data to be added to the Pertinent clinical information of a consultation. User may specify which of the information is being added. BR037 Provide intelligent UI features, hovering impression to show physician that entered the information. BR038 Related to Ophthalmology operations - Private billing support multiple payment against 1 invoices, each payment support discount, refund, credit, payment, payment method customizable etc. financial models. Related requirement not sure if it is mandatory. BR039 Related to Ophthalmology operations Multisite functionality should be the default setting for Ophthalmology operations. Related requirement as the leading clinics all

11 BR040 Related to Ophthalmology operations Support the R prescription of bottles and tubes in medications. Dosage container that is larger than per dose. BR041 Display patient last name, first name, Gender, DOB, age, referred by on patient summary. have multiple locations based on their business model. Necessary for Ophthalmology. BR042 Create button on patient summary page to have quick access to other OSCAR modules BR043 The default epanded/collapsed status of each section upon first opening a new Encounter should be based on the epanded/collapsed status of the corresponding section in the most recent previous Encounter. The default (if there is no previous Encounter) is collapsed. BR044 Add a consultation report section to allow the Ophthalmologist to create his/her consultation report. This is different from the consultation and is the results of the specialist care. BR045 When a care plan is added to the patient, generate Tickler or messages to admin users to enable their follow up. BR046 Allow the additional information to be entered into a consultation report before generating it. Information on the consultation report should be system admin definable including the insertion of diagrams and measurements. Fields with no value should be dropped from the report. BR047 Ability to archive data (remove from display) on frequently use data

12 entries sections. Ability to view the archives on demand from patient summary screen. BR048 Allow the capturing of graphical information of the patient. Allow technicians or Physicians to draw and save the diagram on patient issues. BR049 Ability to generate a consultation report with information specified by the Physician. Consultation Report should be arranged in a letter format where information should be arranged in an efficient and professional way. Physician clinic information should be set as letter header. Templates should be built to allow clinic to pick and choose the information to include. BR050 Include the ability to add Diagrams in the Consult Report Letter Generator BR051 Print button in vision measurements to allow the printing of the prescriptions for a presentable patient copy. BR052 Allow the printing of the eyeform entries to show a similar layout and organization as shown on the screen. BR053 Add part of the eyelid data entry to Anterior segment as it is an important entry at that segment. BR054 The angle entries in Anterior segment (five boes) are cumbersome to enter, Suggestion to provide a one line free tet for data entry. Is structure data required? BR055 Ability to create/configure default for cornea (e.g. selecting one of the options to default on OS, OD or both eyes)

13 BR056 Billing History: What's displayed in the Left column under this heading should filter the entire billing history for this patient to ONLY show all A233A, A235A, and A253A billings under currently logged in provider in the past 365 days; After clicking on "Billing History", the resulting window should include additional column "Provider" to list the initials of the Billing Physician ("Team" value in Provider record) for each row. BR057 The ability to maintain some color coding or the compressed + fields. This is a good to have to allow clinics to highlight specific sections. BR058 The whole eyeform should epand and collapse based on user preference. The form should remember the last setting from user and remains at the pre-set state. BR059 The eyeform data capture should be arranged in an anatomical order.

14 Note: OSCAR EMR did not have a chance to discuss the Ophthalmology functionality with Indivicia but we are able to gather information from their website; their information specifically may not be the most accurate or detail. 3.3 Functional Requirements FR ID Requirements Statement Details Notes Origin. OS P Id* FR001 Provide data type validation at each of the eyeform data entry fields FR002 Provide additional information on the patient summary form when cursor hoover over certain data input fields e.g. who, when data was added, mouse-over the "+" symbol brings up the contet menu etc. Helpful information for large clinic operations FR003 Allow the creation of use roles that has limited operation on patient summary screen view only with ability to enter patient logs and office communications. FR004 Allow the sharing of macros among OSCAR users FR005 Support audit requirements on all data entries FR006 Single Patient summary page (encounter) to avoid data duplication and confusion of which screen to use. FR007 Each frequently used section should allow data entry to be done by clicking on the area similar to the action of clicking on the +. It should also be able to support word-wrapped, click on tet to edit, FR008 Provide buttons to enable information or defaults to be copied from a

15 section to another. E.g. measurement data copying and appointment reasons to current histories etc. FR009 Implement EForm to support graphical descriptions of patient s eye issues. 3.4 Data Requirements DR ID Requirements Statement Details Notes Origin. OS P Id* DR001 DR002 DR003 OSCAR database should support all fields created in the different versions of Ophthalmology ecept there are conflicts in the data. Provide database scripts on upgrade from to create all new data tables and entries, default value should be set when required by the system. Data migration path should be provided from each of the deployed version to OSCAR 14 Ophthalmology Including new table zeiss_oru_result DR004 DR005 Minimum of the latest three historical entries should be displayed on the four or nine open boes. Ability to support more than 10 years of patient data without performance degradations. (over 100 labs, documents, consultation reports and/or encounters) 3.5 Technical Requirements

16 TR ID Requirements Statement Details Notes Origin. OS P Id* TR001 Data loading to the patient summary page must be optimized to reduce page load time. Significant work has been done to load what is need for the encounter than loading years of data. TR002 Enable configuration capability to control the number of data sections to be displayed on the eyeform. Not all data segments required by each Ophthalmologist. TR003 Ability to support the latest version of Ubuntu, Tomcat and Firefo TR004 Ability to support call center operations supporting patients using OSCAR TR005 Ability to limit data load on eyeform/patient summary to minimize loading and refresh time. TR006 Support database size of 1TB (with proper hardware setup) without significant software related performance degradations. Performance requirements Performance requirements

17 Figure 1 Ophthalmology Patient Summary screen by Prylyn

18 Figure 2 EForm detials for original and Prylyn design.

19 Figure 3 Ophthalmology Patient Summary screen by OSCAR Service

20 Figure 4 Indivica Eyeform implementation (obtain from website dated Jan. 2013) Figure 5. Graphical representation of Patient information

21 4. User Feedbacks All of the pilot projects suffered from a lack of documentation and this is the responsibility of the OSPs to document the requirements of the enhancement to the Ophthalmology code. This document will serve as the foundation for Ophthalmology functionality. OSCAR Services has been working on the Eyeform since 2006, working with their client physicians; his approach on development was to enhance his workflow and data on the Ophthalmology specialty by adhering to the layout of OSCAR. They have a continuous relationship to work together to add functionality as required. It is the main reason that the patient summary layout, color scheme have not been modified. The eyeform is implemented in the patient summary screen to allow tight data integration to the structure data of OSCAR. Changes in the eyeform were driven by the need to support more measurement types. The change is very much contained in the eyeform data measurement part with additional data fields (for eample duction, deviation and OU measurements). Clinic has reviewed changes from other clinic and agreed in principle that it is possible to adopt to the user interface functionality of the other Ophthalmology implementations. Prylyn customized their version of the eyeform based on a version they obtained from Indivica. The Indivica version was implemented in a separate eform where user must click a link separate from the patient summary screen. Prylyn has subsequently synchronized the eform input to the patient summary input to eliminate the appearance of separate data entry. The design of user interface included the nine open sections of the original Ophthalmology code. The customization was based on clinic workflow to manage different points of contacts. The nine open sections are used most often and arranged vertically based on relevance. The major changes include removing the color coding of the tabs and arranging all of the epandable sections on the left side. This design enabled the automation of set patient encounters with Firefo macros which minimizing the users administrative tasks per patient. There is no change to the measurements part of the eyeform (Fig. 1); additional measurement data is captured in the EOM/Stereo section. Clinic has agreed in principle to review the measurements as part of the eyeform from other OSPs with the understanding to adopt them as much as possible. 5. Recommendations Due to the open source nature of OSCAR EMR and OSP pilot process, integrating Ophthalmology pilot changes are the responsibility of the OSPs. Since none of the latest pilot code has been integrated back to OSCAR codebase (OSCAR 14 Master), there are significant work that need to be done before the net major release of OSCAR. OSCAR EMR will facilitate and coordinate the code merge back to Master among the OSPs. This approach will be used moving forward on pilots to ensure there are no duplication of effort and inconsistency of the functionality. To avoid major change to workflow of the Ophthalmology pilot clinics, the code going back to OSCAR Master codebase must maimize the adoption of eisting functionality and minimize change to pilot codes. It is clear from this requirement gathering that each Ophthalmology pilot has a main focus of change. This means the sections of change within a pilot may be adapt back to OSCAR Master code base to avoid partial adoption that may force significant changes to code. In addition, user training requirements will be minimized as the workflow within a functional area is maintained. We proposed here to adopt the user interface of the Prylyn change on Eform and the measurement part of the eyeform from OSCAR

22 Service. Technical discussions will follow to identify the best way to implement the eyeform. The backend system will contain the superset of data elements (within good design integrity) from all pilots to minimize database changes. Other minor components like consultation report and minor enhancements can be decided in detail design. The multisite implementation was a required component in different OSPs deployment of Ophthalmology pilot which is an outstanding issue. There was significant functionality built around the management of the geographic site (clinics and sites) from location administration to revenue reporting. This functionality should be reviewed as part of the Ophthalmology integration and determine the best way to integrate the feature back to OSCAR Master code.

23 6 Signoff By signing below, the parties hereby confirm that they have read and agreed to the scope and details of all the requirements as set out in this requirements document. [Enhancement/Feature Request party] OSCAR EMR Name: Date: Name: Date:

24 7 Acknowledgements OSCAR EMR would like to thank OSCAR Service, Prylyn to walk us through and provide screen shots of their version of the Ophthalmology implementation. We would like to thank Hazim Hassan and Dr. Thomas Klein of GoEyeCare, Dr. Dale Gray and Dr Eric Tam of eyemd Institute for their time and epertise in helping to complete and review this document. 8 Glossary