From Teaching Open Source
Project Name: Open Source Health Information Platform (OSHIP)
Project Home Page URL: http://launchpad.net/oship
Project Statistics Page: http://www.ohloh.net/projects/oship
Tags for Your Project: healthcare EMR EHR PHR Python interoperability Zope3 ZCA Grok informatics health medical
Project Description: A Python implementation of the openEHR http://www.openehr.org healthcare information model. Our motto is; "to reuse everything useful to us". In order to discover why this project exists one must first discover what is wrong with the way we currently develop healthcare applications. Recommended reading: Where the Context Lies and the openEHR Primer
Project Issue Tracker URL: https://bugs.launchpad.net/oship
Language Translations Page: https://translations.launchpad.net/oship/trunk/+pots/oship
FAQs & Answers Page: https://answers.launchpad.net/oship
Project Ideas List URL: https://blueprints.launchpad.net/oship
Project IRC Channel Information: N/A
Project Mailing Lists Information: Follow the instructions on the homepage to join the oship-dev team and you will be subscribed to the mailing list.
Individual Mentor Contact Information & Their Areas of Expertise: We have several mentors available with a variety of health care information systems and computer science experience. Information about the lead developer and primary mentor is available at http://www.linkedin.com/in/timothywaynecook
Mentor Capacity: The lead developer is 100% on this project. Other mentors are available as needed.
Information about the OSHIP Community:
Background information regarding the specifications can be found on the openEHR origins page.
The OSHIP development community uses one primary mailing list. When a new developer joins they can select a Blueprint that they want to work on or create one themselves if they have an idea to present. In either case a new developer can create a branch for their work and merge the code from the existing TRUNK code. When the developer has contributed what they consider to be demonstrative improvements they then issue a Merge Proposal into the TRUNK. Their code is peer-reviewed by a minimum of two other developers/managers and if it is found to be of good quality it will be merged by the management team. If the reviewers find issues then the developer will receive feedback or be asked questions about those issues until they are resolved.
We believe that this creates an environment where new developers can feel free to work on whatever they choose without being concerned about how to get their work acknowledged and used. Everyone, including the management team goes through the same process.