Mission-critical Ajax: Making Test Ordering Easier and Faster at Quest Diagnostics

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

1 comments

Comments 1 - 1 of 1 previous next Post a comment

Post a comment
Embed Video
Edit your comment Cancel

Favorites, Groups & Events

Mission-critical Ajax: Making Test Ordering Easier and Faster at Quest Diagnostics - Presentation Transcript

  1. Mission-critical Ajax: Making Test Ordering Easier and Faster at Quest Diagnostics David Rapperport
    • Diagnostics Testing:
      • In the U.S., it is estimated that the cost of laboratory testing is only 3% of the total annual cost of health care. Yet, up to 80% of objective information used in diagnostic decision making is estimated to come from laboratory tests*
          • * American Society for Clinical Laboratory Science Mar/Apr 1998
  2. Background
    • About Quest Diagnostics:
      • The leading provider of diagnostic medical testing in the US
      • Offer access to its services through its national network of laboratories and patient service centers
      • Quest's Care360 web-based lab ordering system is relied upon by more that 100,000+ physicians throughout the US
      • Typical application users are; Physicians, Phlebotomists, Hospital Techs, Nurses, and other Healthcare workers
  3. Background
    • Quest Diagnostics’ scale
    • 150,000,000 Patients tested each year
    • 550,000 Patients tested each night
    • 41,500 Employees
    • 2,000 Patient Service centers
    • 185 Laboratories
    • Data from the Quest Diagnostics 2006 Annual Report
  4. Background
    • Ordering a test is a complex task
      • Rule based ordering (77m rules currently dynamically applied)
      • Accurately specifying correct required data
      • Different regulatory requirements State, National, and International
      • Payment via Government and private payors
  5. Background (application)
    • Care360 has been internet-based since May 2000
      • Cache and WebLink based
      • Proven to be very stable, secure, and scalable
      • Standard page/form mode web application
      • Frames, complete page refreshes as user progressed through steps
      • Some field level “Ajax” like validations db retrieval using hidden frame submissions and hand crafted JavaScript
      • Current scale 750,000,000 HTM
      • Six-Sigma availability over the last 5 years
      • Code base includes 600+ Cache classes and 500+ dynamic WLD active server pages
  6. Ordering the old way
  7. Ordering the old way
  8. Ordering the old way
  9. Issues
    • Ordering process is cumbersome when implemented as “traditional” web application
      • Huge, complex web pages
      • Complex tree of possible transitions between pages
  10. Issues
    • Care360 should aid customers
      • Constantly inputting many orders a day
      • Speed and efficiency highly important
      • This is not buying a book….
    • The act of placing a medically and financially correct order can never be too fast.
      • BUT, designs must constantly balance “easy of use” versus “speed of entry”
  11. Issues
    • Difficult for team to collaborate effectively:
      • Modifying different parts of the same pages
    • Big, complex pages cause maintenance headaches
      • Original author may not be maintaining it
      • What the page does takes valuable time to discover
    • Multiple concurrent version development
      • Many versions under development at the same time
  12. A case for Ajax?
    • So, did Ajax warrant the hype and deliver the goods at Quest Diagnostics?
  13. Our plan
    • Leave the main core of Care360 alone
      • Evolution versus Disruptive Innovation
      • Just add/integrate not “Rip and Replace”
    • Add a new “EZ-Order” option that applied new Ajax techniques
      • Re-design of UI
      • Broken down into small, atomic units
      • “ Container page” containing designated target <div> placeholders
      • Also modal “lightbox” pop-up <div> panels
  14. EWD vs. ZEN Decision
    • CMMI – Substantial Decision Analysis and Resolution Process (DAR) Completed
      • Product Requirements:
        • Bidirectional Session Integration with WLD
        • Continue to use DMZ hardened and proven MGW Infrastructure
        • Reuse of existing backend array based method returns
        • Cache 5.0.x compatibility
        • Fast Learning Curve for current WLD Developers
        • Extremely aggressive business timeline requirement
  15. Our Decision
    • EWD was selected due to it’s ability to meet the defined requirements
    • ZEN has many positive attributes but for this project it was not able to meet our required needs within the timeline
    • Additional EWD Benefits
      • Concise browser payload ~(25%) difference
      • Contextual Multi-lingual support
      • Adaptation Layer for 3 rd Party JavaScript Libraries Implementation; extjs, ejscharts, yui, dojo, etc.
      • Deployable as WebLink, CSP, PHP, or JSP application
  16. Technical Solution
    • Using Enterprise Web Developer (EWD)
      • Ajax framework
        • Concept of page fragments
        • Replace the innerHTML of specified target tags
      • Compatible with Quest’s existing technical infrastructure
  17. Container Page: <div> breakdown Page1 OrderDetail PatientInfo StandingOrder Patient SearchList / InfoDetail Billing InsuranceInfo GuarantorInfo Comments
  18. Ajax Application Flow Container Page Fetch data Pre-page Script EWD State & Session Management Back-end Server Front-end technology (WebLink, PHP, CSP etc) Generate Page
  19. Ajax Application Flow Container Page Fetch Page Fragment Page Fragment Fetch data Event Replaces DOM content Pre-page Script Pre-page Script EWD State & Session Management Back-end Server XMLHttpRequest Generate Fragment
  20. Ajax Application Flow Container Page Fetch Page Fragment Page Fragment Fetch data Event Replaces DOM content Pre-page Script EWD State & Session Management Back-end Server
  21. Ajax Application Flow Container Page EWD State & Session Management Back-end Server
  22. Timescales and resources
    • 4 developers
    • 45 days each
    • Tasks:
        • Learn the technology and methodology:
          • Advanced JavaScript, Ajax, JSON, YUI, etc
          • EWD Toolset
        • Deliverables:
          • Phase 1 production ready
  23. End Product
  24. End Product
  25. End Product
  26. End Product
  27. User satisfaction
    • User trials were fully successful
    • Full production rollout successful
    • Some initial performance issues that have been ironed out
      • Due to many more, but smaller, back-end transactions
  28. User Interface improvements
    • Flow through the complexity of ordering is now much more intuitive
    • The impression is that of a much slicker, more responsive interface
      • Each event just changes a small area of screen
  29. User Interface improvements
    • Not yet fully utilizing pre-emptive, asynchronous data-fetching
      • Currently using pre-fetching in application where long option lists are expected via Dynamic Select List
      • More potential opportunities for this in the future
  30. System/performance: pros
    • Performance good during ordering process
    • Good scaling with load balanced app and web servers
    • JavaScript performance adequate
  31. System/performance: cons
    • Application Servers work harder managing more, smaller, Ajax transactions
    • Potential client issues with any JavaScript error that can stop client processing
    • Not so good for users with latent internet connections
  32. Security
    • No adverse problems experienced to date
    • Independent penetration test completed with no EZ-Order issues uncovered
    • EWD’s Ajax framework secure in our deployment
  33. Development & Maintenance
    • Simplified the design and construction of the UI and the user’s work-flow
    • Allowed much better work breakdown
      • Allowed individual functions to be assigned to individuals
      • Each concentrated on his/her fragments
      • Clean, well defined interfacing of fragment modules
  34. Development & Maintenance
    • Already experiencing lower maintenance overhead compared with the “classic” web approach
      • Smaller team required to support new module
      • More reuse possible
      • Faster for bug-fix and enhancements
      • No one module is overly complex
  35. Business improvements
    • Marketing very pleased with the product and aggressively selling
    • Very well received at HIMMS Conference
    • Recognized by AjaxWorld at their 2008 Conference
  36. Conclusions
    • Ajax is not just hype
    • Ajax really does bring business benefits

+ george.jamesgeorge.james, 2 years ago

custom

1967 views, 0 favs, 4 embeds more stats

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 1967
    • 1492 on SlideShare
    • 475 from embeds
  • Comments 1
  • Favorites 0
  • Downloads 28
Most viewed embeds
  • 295 views on http://gradvs1.mgateway.com
  • 172 views on http://www.outoftheslipstream.com
  • 7 views on http://www.outoftheslipstream.org
  • 1 views on http://outoftheslipstream.com

more

All embeds
  • 295 views on http://gradvs1.mgateway.com
  • 172 views on http://www.outoftheslipstream.com
  • 7 views on http://www.outoftheslipstream.org
  • 1 views on http://outoftheslipstream.com

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories