business requirements volume v1piim.newschool.edu/clients/tatrc/csify10/reports/fy10_q3/w81xw… ·...
TRANSCRIPT
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Multi-Inclusion, Universal Client Electronic Health Record: Business Requirements Volume Chris Goranson, Jihoon Kang, Marine Koshkakaryan, PIIM, The New School Last Updated: June 14th, 2012
Quarterly Report: March 02, 2012 – June 01, 2012 Page 2 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Notes
Revision History
Date Notes Author 6/13/12 Document creation and formatting C. Goranson 6/13/12 Report on initial development status C. Goranson 6/14/12 Additional Notes and Summaries
Added C. Goranson
6/15/12 Additional content and format edit J. Kang
Business Requirements v1 Page 3 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
INTRODUCTION
This is the Business Requirements Volume for the Multi-Inclusion, Universal Client
Electronic Health Record. The purpose of this volume is to organize and document findings
of the project; document the mission and objectives of the project with stakeholders; provide
a foundation for the initial usability metrics and design heuristics.
PROJECT STRATEGY We propose the following project strategy, occurring in three initial phases. This project
strategy is based off of feedback received from CDR Park and the larger Essentris team and has
been structured to provide the highest level of support while accommodating the current sprint
format for review, design and development of the Essentris system. We are presently completing
Phase I as noted below, and have begun initial steps of Phase II
PHASE I: BUSINESS REQUIREMENTS AND PREPARATION
Phase I consists of the following:
1) Define the EMR features (components/user activities) to research and redesign. E.g., patient
list, creating/receiving notes, orders, etc.
2) Establish the usability methods and metrics to evaluate the current EMR system
3) Establish the usability testing methods to evaluate the EMR features which PIIM later
delivers
4) Establish design and production methods
5) Complete the business plan consisting of:
a) WBS
b) Gantt Chart
c) Reporting methods (scheduling of iterative review meetings
d) Milestones and delivery dates
II. DEVELOPMENT CYCLE
1) Choose an EMR feature (component/user activity)
Peter has a specific list of features to be redesigned and we choose one at a time.
Business Requirements v1 Page 4 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
2) Study the feature
PIIM team will learn about the user’s goal(s), workflow, interface elements (e.g., objects,
actions) and so forth associated with the selected feature.
Dependency: CliniComp/Peter’s ER team should give PIIM access to Essentris ER Module.
3) Usability research
PIIM team will identify the UI elements which hinder or potentially hinder users’ workflow
and productivity. The team will also apply the severity level (e.g., moderate, critical, very
critical) to each element (usability violation), then make recommendations how it should be
improved.
Dependency: PIIM will have to report the findings to stakeholders and get their feedback.
4) Dividing items to redesign
PIIM team will carefully go through all items identified during “3. Usability research,” then
divide into two groups: Low-hanging Fruit (LHF), High-hanging Fruit (HHF)
Low-hanging Fruit (LHF): items that require relatively less development efforts and do not
drastically change the workflow and structure of the current Essentris ER Module
High-hanging Fruit (HHF): items that require more development efforts and may change the
user experience and system structure drastically. Such changes are not necessarily expected to
be implemented by the development (engineering) team for the time being; they can be
implemented in the future.
5) Design Set A — LHF
PIIM team will design the elements from LHF using the usability research and
recommendations. Each element will be documented with detailed design specs. The specs
will be sent to the development (engineering) team.
6) Design Set B — HHF
PIIM team will document these, but these won’t be implemented by the development
(engineering) team during this project period.
Business Requirements v1 Page 5 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
7) Implementation (LHF only)
CliniComp/Peter’s team will take the design specs into development.
Dependencies: CliniComp/Peter’s team must handle this process. They can, however, meet with the design
team (PIIM) regularly for additional support.
8) Usability test
Once the implementation (Step 6 above) is complete, PIIM and Peter’s team will take both
models (current feature from the ER Module and new model) for scientific usability testing
(e.g., GOMS, uFurT, etc.)
Dependency: CliniComp/Peter’s team should make the new model available for testing. We also need to
make sure they will do this. When we met Peter in Bethesda last November, he said he could. I remember!
9) Revision of design
Based upon the feedback and new findings from the usability testing (Step 7 above), PIIM
team will refine and revise the design. Updated design specs will be delivered to
CliniComp/Peter’s team.
10) Documentation
With the research, design, testing, refinement/revision above, PIIM will update the
following documents:
i) Detailed GUI Design Volume
ii) Usability Volume
Business Requirements v1 Page 6 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Stakeholder Review
Gathering Requests/ Requirements
User Interface/ User Experience Analysis
Selecting Component
Implementation
Usability Test / Validation
Revision
Design Set A Low-hanging Fruits
Revision
Design Set B High-hanging Fruits
Documentation/ Delivery
Dividing Research Outcomes
Business Requirements v1 Page 7 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
III. POTENTIAL EMR FEATURES TO REDESIGN
1. ED Tracking Boards (ED Tracking, Triage Tracking, Tracking Compact, Tracking VS, etc.)
2. Notes (DOD ED Medical Record, Edit and Review modes, usability, template selection)
3. Order Entry (New Order, Standard Order Set, Order States, workflow, data considerations)
4. Flow Sheets (Charted order results and imports, one time orders, continuous orders)
5. Summary Screens
6. Dashboards/Reports
7. Web Links (ED Reports, access to resources, CPOE Transcriptions Dashboard, CHCS
transcriptions)
8. Nuance (Dragon) Integration
9. Patient Banner Redesign
10. Bed Transfer Task Execution Steps
11. Other Items (policies and procedures, training materials, patient aftercare content
capabilities, imaging capabilities, choice lists, Database Items or DBIs)
12. Calculation Based Dosing
Business Requirements v1 Page 8 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
APPENDIX A: MEETING NOTES MARCH 30TH, 2012: KICK-OFF MEETING RECAP Following a Skype call with CDR Park, PIIM and the Essentris team, we identified the
following high-level items that should be reviewed. Below is a summary of notes from CDR Park
and PIIM staff:
1. PIIM needs to secure access to Essentris, address training needs
2. Schedule site visit to the ED (NMCSD) and get a sense for how coverage within the
ED works:
a) Spread of coverage
(1) Parameter 1
(a) Weekdays
(b) Weekends
(2) Parameter 2
(a) Days
(b) Nights
(3) Parameter 3
(a) Shift Change
(b) End of Day Reporting
(4) Parameter 4
(a) ED
(b) FT
(c) Coding Environment
(5) Parameter 5: Setting
(a) Community Non Teaching (29 Palms)
(b) Family Practice Teaching MTFs (Travis)
(c) Tertiary Medical Centers (NMCSD, WRNMMC)
3. Review workflows with Sandy, Jeanine and Kathy
a) Review workflows already captured
b) Review methodology used
4. Visit template: based on spread coverage
Business Requirements v1 Page 9 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
a) Uses: Anthony, PIIM, NRL, Others
b) Peter to draft
MAY 2-4, 2012: ESSENTRIS ED CLINICAL CONTENT DESIGN On May 2-4, 2012 CliniComp hosted an Esssentris ED Clinical Content Design meeting. A
number of items were covered, including:
1. CPOE Preparations
a. Freq Orders in the ED Environment
b. Freq Groups of Orders
c. Most Common 200 CC’s Orders
d. Most Common 200 Dispositions Orders
2. EssED Road Map
3. Reports / Dashboard
4. CPOE – Orders
a. Review of OrderSets
b. Defining Missing Orders
c. Refining Orders
5. Guest Presentations
a. Dragon Integration
b. PIIM
6. Larger Discussion
In attendance: Michael Crowder (Travis); Sandy Mar (Clinical ED workflow); Jim Neil (CliniComp
since 2007); John Hughes (RN / IT); Chris Strotum; Paul Schirelli; Andrea Swinesuale; Annette
Moore (Ret AF); JF Lancelot; Peter Park
Dr. Park:
Early detection system of sepsis – led to the reduction of mortality – 30% higher.
Business Requirements v1 Page 10 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Presenting high-value information first.
Refining the order sets. Creating and implementing a library mechanism for this. Early detection
algorithm – 5 common data elements pulled within 90 minutes. Septic protocol pathway and alert.
Detected in the ED (antibiotics started) and connect to inpatient to carryout.
Put in place a standard protocol across services and locations. Need system to support it.
Roadmap (Sprint 26 CPOE) – supporting Madigan and Wright-Patterson to the same level as
Balboa – some challenges remain. Still in beta.
CPOE, issuing change orders a big deal. Opportunity to optimize their processes. How can we
refresh in an enterprise setting?
Take MedSearch module and integrate. Rolling out updates to four different groups of regional
hospitals – a graduated release complete with training (methodology).
Region 1: Asia Yokosuka Okinawa Guam Bremerton Oak Harbor.
Region 2: Europe Naples Sigonella Rota Guantamano Bay Jacksonville
Region 3: CONUS West Lemoore 29 Palms Camp Pendleton San Diego
Region 4: CONUS East Bethesda Portsmouth Camp Lejeune Pensacola Beaufort
Every site is refreshed within 6 months of the initial release of the ‘band’, or cycle.
Regions grouped according to anticipated kick-back. Training sites are in CONUS. One release per
year is just as difficult as doing the roll-out across the region. Roll-out cost could be around $6M
per year. Making the argument to stand up a full implementations team. 14 mobile trainers
Lea / Lisa on the innovation side.
* Branding of the various releases of Essentris ED modules (instead of build numbers, use catchy
names, phrases, etc.)
Workflow: Basecamp on-line questions submitted; reviewed during weekly calls; questions moved
into sprints, and sprints are defined into ‘themes’.
Business Requirements v1 Page 11 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
* Why isn’t it used at the patient’s bed side? Don’t want to turn back on patients; difficult to extract
information; computer isn’t always on. Workflow at the bedside (CAG card enabled increases
system start-up wait time) – what should the implementation look like? How do we chart against
the orders? Peter wants this integrated into our write-up.
What should the standard kiosk look like? In a room, where should they be configured in the bed?
Not at the feet of the patient, for example. Docking station for tablets? Jaco inspectors want to
clean / inspect the tablets.
Question: Tablet and wireless? CITRIX on android. Dell Streaks 5, 7 (10 inch), some locations no
Steak 5. Essentris usability not tested on tablets.
Could we make the computers a kiosk? Only three programs on the kiosks? What programs should
be on the kiosk (AHLTA, CHCS, Essentris)? We need a configuration guide.
What are DISA guidelines? More TMIA staff
EUD configuration – how do you log in. 20 – 30 minutes to login. Want to look at the kiosk. Card
readers are problematic.
CHCS meant to be a report machine. Does not include write-back functionality. Workflow
involves signing into multiple programs using card readers. Wireless functionality does exist on
devices that include the card reader built in, but will log you out after 10 minutes. Users cannot
place orders from within Essentris; have to log into CHCS to place orders, due to no writeback
functionality. CHCS is from the 70’s continues to devolve. 110K outpatient visits a month.
Essentris can pull information out of CHCS but cannot write it back.
Lab flowsheet to the patient.
* Do we want a concentrated working group on design-related content?
Call-back mechanism. Critical value follow-up mechanism should use notes, reports, or flowsheets?
Follow-up logs with value for urgency level.
Business Requirements v1 Page 12 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Reviewing the charts via Essentris – read only? Example shown is for radiology. Until user clicks
on ‘completed’ – the information is not updated in the system. Staff checks the call log – patient call
back follow-up. Perfect spot for a personal mailbox? Messaging capabilities? Needs some kind of
messaging support – prompts you to come back. STICKY NOTES on the screen – how about on
the application? Clinicians need some way to flag comments. A JACO requirement makes you
document what you receive. Essentris does have a critical values note.
HOW DO WE VISUALIZE THE TRAIL OF THE WORKFLOW?
DHIMS is 10 minutes logoff on Essentris. Some groups set it so the computer won’t time out.
Wright-Patterson has a script that runs in the background that shakes the mouse to keep the screen
active and user logged in.
RFID technology?
Visual representations appear to be more of a table with colored in squares that are representing the
things that need to be addressed.
Travis AFB – built their own bucket and workflow. Do user-generated improvements flow up?
IN the PIT at the ED (just one example): Two monitors set to CORE, two set to TRIAGE in the
ED department. Shows how users are using the interfaces.
Transcoding allergies into Allergy Markers.
MINIMUM ALLERGY: TYPE, NAME AND SYMPTOM FIELDS. This is a medispan
requirement. Melder support of the allergies – so the fields update themselves?
SPEED is essential in the ED – initial first glance can be a first run at allergies, later fleshed out by
the other care providers later (the ones that have the time to review in detail).
Could CHCS autopop the allergies fields? Right now, the CHCS
Business Requirements v1 Page 13 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
TMA has slapped Peter’s hands on ICE. Political – something was getting done. Want more
money (rice bowls and money). CIO’s have been difficult as well.
Can assist JF with discussing the changes necessary for EssED (the ergonomic changes).
LOGIC OF THE LIGHT SWITCHES – further discussion with JF and Peter. Can open additional
options based off of selections made à computational logic
PETER: I only care about how long they’ve been in the ED.
Way to launch the PACS from within Essentris, call up the patient via SSN to address “HL7
resulting from PACS to Essentris”. Challenge is to get credit for the radiology diagnosis. Wet read
can go into Essentris, but wouldn’t be fed back into PACS.
Challenge: Different workflows, different systems. Only the final interpretation of the radiology
comes from CHCS (not the wet read). Dr’s still taking notes based on the call on the wet read (note
taking is still a key concern – where do the notes go, and how are they recorded?)
Logic:
99281 – can bill for someone visiting who left before being seen but have been triaged. Avg cost is
$130. But someone could be seen by a nurse, but leaving before triage may not be billable?
Reference document for RADIOLOGY WORKFLOW: see the
Rads%20Over%20Reads,%20Started%20Feb%206%202013.pdf document.
Visual C / C++ on a UNIX DB Backend accessed from Oracle
UNIX / Proprietary DB à Oracle à Visual C / C++
Nurses cannot write a prescription.
Business Requirements v1 Page 14 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
PETER: Wiki for sharing and organizing information. One for order sets, etc. SHOULD WE
START A WIKI FOR AN IEHR? What would it look like? How do we manage this knowledge?
Should wikispaces be used? Sounds like it already is being used, but needs to be revisited. Creating
a “best-practices” – could you involve NIST? Simple descriptions of what the modules do, etc.
Could be something that we do as part of our the outreach to the MHS functional community for
expert and end-user feedback.
PIIM has an opportunity to help CliniComp think through what the next generation of these reports
should look like.
Team has to (a) identify the use cases; and (b) the users can generate the reports. On-demand report
generation using Crystal Reports is not feasible. What about a HTML-generated live report? Have
to work within the boundaries of what we have.
SAIC was given 10M to redevelop some CHCS functionality – has not performed well.
CCI reports are HTML web pages that periodically get updated. But the reports are not really
editable or dynamic – these are static pages. Cannot click on the report and go into Essentris. Why
not using something like Fusion Tables, etc? Other sites have developed some innovation. Are
non-transmittable between sites. San Diego is one example. Could that be another place where the
reports wiki would be helpful?
Standardized notes and standard data architecture with standard tags can lead to the standardization
of reports.
Cyclic schedule will be only two times per year – should find out when these cycles will occur.
Perhaps we could coordinate our implementation of usability testing around the same times.
Reports are very simple web links, opens an HTML-generated page. Automation is key to these
reports working correctly.
Clinical tools and Productivity tools – lists of patients who checked in by hour, then day of the
month. Data in the reports is
Business Requirements v1 Page 15 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
HOW TO DEAL WITH UNSIGNED ED ORDERS – this can be a big deal as it can lead to a
recoupment of funds. One button signing all orders at the same time.
DATA ANALYTICS ON THE REPORTS IS IMPORTANT. What does the flowsheet look like?
MD field becomes the unique ID?
Orders and order sets.
Global change –
HIGHLIGHT DOCTOR PROVIDER PAGE
REPORT NEEDS:
Animal Bites – reporting form (requirements vary depending on state)
Total Throughput time by provider
Occupational Health Injuries
Triage Times
Times to Rooms
Average wait time per day, per shift
Patients per provider (really looking for a data exploration tool)
Deaths in the ED
Query Names?
Line of Duty Determinations
MVA
Injury Report (& related documentation, command information)
Needle stick
POCT
Recent discharges and arrival report
Nurses annotation
MedRep completed
Asthma surveillance
Sedation Cases – come off notes
Business Requirements v1 Page 16 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Restraint Cases – come off notes
New universal protocol notes
Unplanned Bounce-back report (returns within 72 hours)
Provider-centric reports
Syndromic Surveillance is already captured.
Public Health Depts grab STD reports straight from CHCS. LWAB charts – left without being
seen.
TEMPLATES: Could be something for the wikispaces wiki. They are also sold by TSy and AAEM.
Sounds like a GREAT OS project. Worth looking to see if there are any good OS templates that are
out there. Redesign template creation/selection. Jihoon suggested T1- template (based on chief
complaint), T2 – observation sections,…. Maybe T3 – default state of each field within section.
Personalize and save templates. Offered mock-up.
Within Essentris system, tag seems to be the identifier of the report.
Probably need to figure out how difficult it would be for Essentris engineers to deploy a new skin
on top of existing code. We have to be careful with our assumptions.
Most popular templates:
TRAVIS AFB
Narrative (no template) 96% / Adult URI / (less than 2%)
Balboa – 86% / AV URI / ADULT URI (these are less than 2%)
There’s no way to collapse the text boxes around the narrative. As static fields are selected, and the
changing conditional is highlighted, the narrative is pre-populated by what was selected. From a DB
perspective, the text is just being loaded in based on what’s checked on the screen. STATE
CHANGE OF THE DEPENDENT FIELDS BASED ON WHAT’S SELECTED.
User Interface / quickly as possible, maximum legal trail.
Flag Flag Flag
Business Requirements v1 Page 17 of 20
Multi-Inclusion, Universal Client Electronic Health Record (W81XWH1120183): Business Requirements June 16, 2012
Need a hierarchical list of findings (kind of like SnoMed, but different). All three specialty leaders
want a quicker way to get stuff inserted.
[Page 18]
Multi-Inclusion, Universal Client Electronic Health Record: Business Requirements Volume PIIM, The New School Last Update: June 13th, 2012
©2012 PIIM, THE NEW SCHOOL
Dragon / Nuance demonstration. Might make good interaction with mental health issues (nlp). Are partnered with IBM / Watson stuff. Could this technology behave I WANT THE GUY WHO HATES COMPUTERS How can we integrate the How can we reimagine the EDTR-HLD training – transfer from patients to the destination (within Patient Control). Multiple choices required before anything can be done. Need to refine tabbing structures, etc. Following presentat ion to CliniComp, Int l . Key Modules: Status Board – make more delicious. Optimize easy changes on the settings Order Entry Beds Transfer – too many steps Labs Look at the date on the banner – is it used well? The entire banner needs help. Flowsheets Summary Screen – standard column placement Do we need plotting / graphing / administration tools? Per Dr. Chris Strode approximately 90% of provider workflow is: Select Pt -> E (Note) -> Orders (D) ->Discharge (F)
Internal design suggestion (Marine): 1) A provider centric view to flip through all the notes for a list of my patients.
Skip the steps: selecting and exiting each pt chart and entering into the note section. Notes have access (link) to orders.
2) A view to flip through a list of orders for my current patients same as above but for orders. Provider may enter and/or review results from here.
3) A view where I can go through and discharge patients from my list. JF:
1) Putting lipstick on the pig 2) Making full recommendations on the EssED 3) Identifying and putting out usability fires (like the beds transfer) Status board
[Page 19]
Multi-Inclusion, Universal Client Electronic Health Record: Business Requirements Volume PIIM, The New School Last Update: June 13th, 2012
©2012 PIIM, THE NEW SCHOOL
Summary screen – the summary screen requests are made by the users and given to their site admins. Site admins make the request to CliniComp Need a good summary screen on the ED environment. Can it be embedded in a workflow? Screen names in the clinical summary need to be revised. There is a sample starting point provided by Peter on basecamp at SumScreen: DOD ED Clinical Summary. Order sets: Many buttons across the top of the interface. Choice lists should be the same across all CPOE – Computer based order entry. Abdominal pain – sets or bundles of orders. Order sets created based on Travis AFB. Goal is to come up with universal sets that can be used across the DoD. Order sets may change across – summary screens are shown that lets the doctor choose the order sets and the course of action. Choice list in Essentris was probably imported from CHCS. Getting a list of diagnostic procedures out of CHCS – get input into ALHTA, CHCS, etc. Users are No mouse-overs on the buttons on top of the order set.
Orders placed in Essentris have to be re-entered into CHCS by the nurse, etc. Discrete, quick-order sets might be popular? Saves chance of entry being wrong? CPOE Checklist:
1. What is being ordered? 2. What is in our order sets? How can we make the sets better (what is missing)? 3. What sets do we need? If you can press the keys on the keyboard, you can automate it with Dragon. DoD flags things that are available at all sites, other ones can be created and stored on a case-by-case basis. Allergy note at the top is only populated if entered in certain fields throughout Essentris / DBI / CHCS. This information will populate the header bar, but if the allergy marker is filled in from one of these fields.
[Page 20]
Multi-Inclusion, Universal Client Electronic Health Record: Business Requirements Volume PIIM, The New School Last Update: June 13th, 2012
©2012 PIIM, THE NEW SCHOOL
IS THERE SOMETHING THAT DOCUMENTS WHERE THE FIELDS POPULATE FROM? WHICH SYSTEM? Essentris? CHCS? ICE? Can the allergy fields auto populate into other fields? Nurses use buttons E (Note – ‘DoD ED Medical Record’) and B (DoD ED Flowsheet) a lot.
Following is a list of items from the general discussion on Friday that we may want to contribute to (especially 1-4):
1. JF mentioned that they have a 'smart patient list', something similar to provider portal notification functionality (at 90% completion per JF).
2. Signing and routing notes to other users, a mailbox type of functionality/work flow needs to be planned out.
3. A personalized order entry sheet with check-boxes, max 50 orders. Orders from anywhere, the ability to place orders from anywhere in the system, such as notes.
4. Number of steps to save single order vs. order sets is inconsistent; it is causing loss of orders.
5. The system does not have a good role awareness capability. User type based entry points to system.
6. Ability to view previous notes, a preview with DOS and ICD9 to aid in selection. This item may already be in progress.
7. Currently a nurse annotates an order when it has been transcribed into CHCS from Essentris. This annotation indicates the ‘transcribed’ state. An action item was taken to make this state change part of the other order entry status/state.
8. Action item to build a coder summary screen. 9. Action item to build in real time reporting of missing data.
Some low hanging fruit might be found in:
1. Better label and instruction wording in Notes and all over the system. 2. Status Board(s) color scheme.
Chat with Leah at CliniComp after the conference on Friday. She showed me some work that a previous design team did. They no longer have access to these designers. She is working on some new windows/forms that may be added to the system; she was wondering if we can help with that. I said I believe it is within the scope of the project, but I would have to check with you guys. I told her I would get in touch with her to set-up a call to discuss. Go to next SA training.