About

From OpenEPCR
Jump to: navigation, search

Contents

Background

More and more Emergency Medical Services organizations are moving to electronic Patient Care Reports, or ePCRs. Many states are specifying state-wide formats, as well. While many commercial vendors have introduced solutions, many of them have problems - mainly, they are cost-prohibitive for small volunteer agencies and agencies with limited budgets, and many of them rely on commercial offsite hosting - therefore they completely fail in a situation where traditional landline-based internet connections are down - the specific time when they are most needed.

Project Mission

OpenEPCR aims to provide the Emergency Medical Services sector with a Free (as in Freedom, a.k.a. Open-Source) Electronic Patient Care Report (EPCR) software solution. Licensed under the GNU GPL, it will be easily extendable by users' organizations. Such a solution does not currently exist. Furthermore, many states and regions are moving to electronic data aggregation for EMS. OpenEPCR aims to provide an easy way for organizations to adopt a standardized data set and submit their data - and only the data that they choose - to a trusted third party. The software will attempt to do all of this while paying heed to applicable standards on privacy and security, as well as being fully platform-independent.

Project Goals

  1. Provide *all* code licensed under the GNU GPL, and make code as easy as possible to modify and extend.
  2. Be fully platform-independent and database-independent, running in a platform-independent language.
  3. Have NO reliance whatsoever on outside services i.e. be able to run in a disaster situation with a full communications breakdown.
  4. Be designed with internationalization (i18n) and localization in mind, specifically with easy support for translations.
  5. Have all data set, user information, rights/access management, authentication, and authorization abstracted, allowing organization-specified rules as well as various authentication means (central server, local file, passwords, hardware tokens, OTP, etc.)
  6. Attempt to conform to HIPPA and other applicable standards governing security and privacy.
  7. Allow all organizational data such as PCR forms, data sets, printable versions, etc. to operate as pluggable modules; changing the entire PCR structure should be as easy as adding a few new files and running a script.
  8. Be designed with both the small, volunteer, virtually budget-less squad and the large paid organization in mind.
  9. Run on a variety of devices including desktops, laptops, and mobile devices of all flavors.
  10. Operate in environments including standalone, central server, ad-hoc network, and a network of distributed master servers.
  11. Have the utmost regard to integrity of data - data loss or corruption is NOT an option.
  12. Support virtually unlimited customization for an end-user organization.
  13. Be designed with ease of extension in mind - it should be easy for end-user organizations to design custom add-ons that integrate fully, while conforming to the Access Control model.
  14. Eventually, include support for administrative functions such as equipment/vehicle checks, scheduling, roster functionality, etc.
  15. Eventually, consider creation of an integrated incident management system for patient, resource, and personnel tracking.
  16. Be designed with as much space for custom software hooks as possible.
  17. Attempt to pull together developers from various disciplines and gather suggestions from a vast sampling of the EMS field.

Long-Term Goals

  • As time progresses, I would also like to look into integrating an MCI triage package, perhaps a CAD feature, and integration with PHP EMS Tools.
Personal tools