Roadmap

Label: Help Wanted

As of this moment, we're using a label, appropriately titled "Help Wanted", to track roadmap items. So what, you may ask, qualifies something as a roadmap issue.

1. It's a submitted, vetted issue that core contributors have determined is something the project should pursue when resources are available.
2. It is NOT being actively or eminently worked on, and thus is a great way to get a sense of how one might contribute to the project.
3. Some level of requirements validation has occurred (otherwise, it would have a "Needs Requirements" label).
4. Should you choose to work on the feature / issue / etc, you should expect responsiveness from http://github.com/tangollama or other people serving in a product management role on the project regarding requirements questions / issues, he/they are up-to-date on the request and can help both clarify requirements and are happy to bounce ideas.

That being said, here's the Roadmap https://github.com/HospitalRun/hospitalrun-frontend/labels/Help%20Wanted

Note: among the many things for which we're indebted to the Ember https://twitter.com/emberjs is the clever notion of the Help Wanted label (https://github.com/emberjs/guides/labels/help%20wanted).

Label: Needs Requirements

Prior to an issue getting the Roadmap label, a presumably good idea that needs to be flushed out further will often receive the "Needs Requirements" label. This same label can be used while an issue is being worked to indicate the need for outside product management support. These issues should be reviewed by project contributors focused on product management and with access to the sort customer interaction that would allow him or her to make an informed and useful decision.

Version 1.0

We define "version 1.0" as the version of the solution ready for public beta, where the system would be available for download but (more importantly) ready for offering the hosted solution in beta program that is vetted by application.

Among the features for 1.0 are the following:

• Inventory module in it's current state, meant to catalog and track the consumable inventory for a given facility
• Imaging module, including a queue for making imaging requests, the ability to configure and integrate a PACS solution via HL7, the ability to see the status of requests in HospitalRun, the ability to review JPEG's of the resulting images, and the ability to launch the DICOM viewer
• Labs module, tracking the queue of lab requests and unstructured data for lab results. Integration with an external LIS is NOT part of the deliverable.
• Medication module, including submitting and fulfilling pharmacy requests, tied back to inventory for tracking dispensing.
• Appointments module
• Visits module - tracking the Labs, Medication, Imaging, Procedures, and other Charges (tied back to inventory) of a patient visit.
• Billing that ties back to Patients and Visits that includes building and publishing invoices, registering payments, price lists for services, and a concept in HospitalRun known as Payment Profiles which can be used to modify the price list for given Patients or specific Invoices.
• Patient module - including Visits
• a component for modifying the header / footer of all printed documents for a given installation
• a component for creating customizable forms for interactions like the Social Work form
• a demo mode for the system that allows the user to operate in a completely offline mode. This same demo mode would be available for users in production instances to support self-directed training.

Version 1.0 will provide