Successfully reported this slideshow.

Open Development

912 views

Published on

The January call will focus on introducing the concepts of open development, software lifecycle and upcoming open projects. We have a number of projects on the roadmap and would like to give the community an opportunity to help prioritize the list.

We'll discuss the upcoming GT.M Integration project to more tightly couple OpenVista and GT.M. You can read the proposals and discuss this project at Medsphere.org, see the project homepage here: http://medsphere.org/community/roadmap/gtm

Please feel free to invite any colleagues that might find this topic relevant or interesting.

When: January 15, 12:30 - 2pm Pacific
Where: Dial-in: (888) 346-3950 // Participant Code: 1302465
Web conference: http://www.medsphere.com/infinite/

What: Open Development

- Ecosystems at work
- Open Development Introduction
- Community Project Overview
- GT.M Project Introduction
- Project Review
- Medsphere.org: Tip of the Month

===

The community calls are listed on the Medsphere.org event calendar (http://medsphere.org/community-events/) and we will update each month's call as the agenda is solidified.

Details and Recording available here: http://medsphere.org/blogs/events/2009/01/15/community-call-january-2009

Published in: Health & Medicine, Technology
  • Be the first to comment

  • Be the first to like this

Open Development

  1. 1. Webinar: http://www.medsphere.com/infinite/ Voice: (888) 346-3950 Participant code: 1302465
  2. 2. Open Development January 2009 Community Call
  3. 3. Presenters • Rick Jung • Jon Tai • Ben Mehling
  4. 4. Agenda • Ecosystems at Work • Introduction to Open Development • GT.M Integration Project • Medsphere.org: Tip of the Month
  5. 5. Ecosystems at Work Rick Jung
  6. 6. Introduction Medsphere has fostered the creation of what is rapidly becoming the largest collaborative, open source ecosystem in healthcare IT. With the seeds of disruptive innovation now planted around the world, what will happen to vendor lock, proprietary systems, upgrade and maintenance fees, and users groups as we know them?
  7. 7. What is an Ecosystem? Collaboration on a community governed roadmap that drives innovation, advancement and knowledge of clinical best practices into IT solutions for all 7
  8. 8. Medsphere Vision How is Medsphere cultivating the largest collaborative ecosystem in healthcare?
  9. 9. Why an Ecosystem? • Activities Freedom from vendor lock Focus on knowledge and services Competitive advantage for the community Encourages contributions from Ecosystem members Fosters governance of the collaborative contribution process Promotes a mechanism to review & reuse contributions Assures quality control of mainline - trusted for use in live healthcare environment Provides Multifaceted value proposition to ecosystem members Open access for subscribers & community to create and contribute
  10. 10. What is Medsphere.org for? • A virtual town square – a location where members can stand on boxes and shout, swap ideas, debate approaches, and evaluate contributions. • A place to get answers from us, customers, and others for support, programming, training, and implementation questions • Share best practices…….eliminate silos of information and frustration • And soon………monitor clinical quality outcomes against published data from clients like Midland and others!
  11. 11. How does it work? • Participants collaborate, discuss and contribute to the whole leading to transformation in Healthcare • Contributions - A bug with one of our open releases was reported by George - Blog post on the value of BCMA http://medsphere.org/thread/1044?tstart=0 http://medsphere.org/people/RADAMS/blog - A question was asked about searching for orders (it was answered - 25 templates contributed by WVDHHR by Cesar and Hartsel) http://medsphere.org/search.jspa?q=%22Template%3A%22&resultT http://medsphere.org/thread/1150?tstart=0 ypes=DOCUMENT&dateRange=all&communityID=&username=Hartse l - Carolyn ferried in a question on client deployment techniques. David Kerrins provided CCDH's solution. Fernando, a member - A community member suggested a group focused on Behavioral from Brazil, provided another example of a solution. Albert Health added info on the open source package we recommend. http://medsphere.org/groups/behavioral-health http://medsphere.org/thread/1051?tstart=0 - We have started a new quot;DIY with Opensourcequot; Blog, and Brotman - This document was created by me, however it was contributed this article edited/enhanced by a community member -- additionally, via http://medsphere.org/blogs/diy/2008/12/15/real-time-proactive- feedback from Hardhats, I added several entries to the table I infection-control-alerts hadn't been aware of. http://medsphere.org/docs/DOC-1198 - How to determine the function of an option in Putty? FAQ added by Hartsel (and enhanced by Carolyn Kron and Alli Lees) - Finally, Chris U of TIPG blogs with some amusing, but useless http://medsphere.org/docs/DOC-1358 factoids (Just like traditional organizations, ecosystems require distractions too!) http://medsphere.org/people/chris.uyehara/blog/2008/12/11/first- post---alrighty-then
  12. 12. How does a bill become a law? Community Code Flow
  13. 13. MSC Product Roadmap Timeline 13
  14. 14. Development Proposals 14
  15. 15. www.medsphere.org
  16. 16. Introduction to Open Development Ben Mehling
  17. 17. SDLC Overview Stages of the lifecycle: • Product Definition – what will be built/fixed • Development – how it will implemented, write the code • Quality Assurance – does it work as specified • Release Management – package everything together
  18. 18. Product Definition New Development (project or feature) • Proposals • Design • Documentation • Assign Priority Defect Correction • “Artifact” or Ticket created • Verify the reported defect (QA & Product) • Assign Priority
  19. 19. Product Management Who manages the influx of change requests and defect corrections? • Ultimately Product Management, with input from: – Customer Care – Client Services / Field Personnel – Quality Assurance – Development • Requests are channeled through a process that uses expertise specific Change Control Teams, and if necessary a higher level, Change Control Board.
  20. 20. Development • Agile-like Development Process • Create a Backlog • Plan a Sprint • Work on individual tasks • Commit Code to SCM • Peer Review
  21. 21. Quality Assurance • Test Plans • Manual vs. Automated Testing • Agile means QA and Development work closely and in parallel (i.e., no throwing things quot;over the wallquot;) • Execute Test Plan and Approve Code
  22. 22. Release Management • Mainline Management • Packaging • Documentation
  23. 23. Open Development @ the VistA Community Meeting Ben Mehling
  24. 24. Software Life Cycle & Testing in the FOSS Environment by Cameron Schlehuber, former national DBA • Patch sequencing • Patch installation & retrofitting • Packaging a patch
  25. 25. VistA Software Development Lifecycle Working Group Brainstorming session I • Discussion of the “Five tier” support model – 1) End-user – 2) CAC/ADPAC/Superuser – 3) Local Developer – 4) National Helpdesk & Field Support – 5) National Developer
  26. 26. VistA Software Development Lifecycle Working Group Brainstorming session II • Discussion of AS-IS VA process – Local and Field support reporting into “forum” – “Forum” acts as the central clearing house
  27. 27. Related Sessions TRAC Server: How to use subversion and TRAC by Ray Anthracite Panel Discussion - HIPAA, Network Security and VistA Security By K.S. Bhaskar, George Lilly, Jon Tai, and Ray Anthracite Open Source Licensing by Ray Anthracite Software Development the VistA Way: Open-source Lessons by Rick Marshall
  28. 28. GT.M Integration Project Jon Tai
  29. 29. Background • OpenVista runs on GT.M today, but... – Difficult to install – Difficult to configure – Difficult to manage
  30. 30. Project Goals • Make it easier to install and manage OpenVista on GT.M – Create Linux packages • Push packages upstream in the future – Build a web-based management console • Standardize – Codify best practices into tools • Make it easy to do the right thing and difficult to do the wrong thing • Verify that all OpenVista components run properly on GT.M
  31. 31. Proposals • Several proposals are available now on Medsphere.org – Communities > sRoadmap > GT.M Integration
  32. 32. Standardize Filesystem Layout • Standardizing on common locations for files will allow us to build tools • Where should GT.M be installed? • How should the files in an OpenVista instance be organized? – Where do routines, objects, globals, journals, and images go? • What partitions should be created to hold the various file types?
  33. 33. Globals and Journals • How should globals be distributed amongst different database files? • What journaling parameters should be used? • What journaling actions should be taken on boot, shutdown, recovery?
  34. 34. Linux/OpenVista Security • How do user accounts at the Linux and OpenVista levels coexist? • How can we secure programmer mode access? • How can we take advantage of additional security features at the Linux level? – iptables – SELinux
  35. 35. Web-based Management Utility • “Namespace” management • System status and monitoring • User management • Backups and journaling • Log viewer
  36. 36. Changes to OpenVista • Fix compile errors when running on GT.M • RPC broker / HL7 listener / VistaLink management • Concept of namespaces
  37. 37. Linux Packages • RPMs and debs containing utilities – Web-based configuration utility – Backup scripts – ... not OpenVista itself
  38. 38. Next Steps • We need the community to provide feedback • What are we missing? – Rick Marshall, VISTA Expertise Network • How can the proposals be improved?
  39. 39. Next Steps • Issue tracking / source code tracking – launchpad.net • Assign tasks • Medsphere will host calls every other week – We will post a poll for a day/time – Present status to community – Technical discussion
  40. 40. Medsphere.org Tip of the Month Jon Tai
  41. 41. • Questions? • Reminders: – Survey: GT.M Project Call – Survey: How are we doing?

×