Main Page

openEPCR is a project that aims to provide the EMS community with a fully-functional electronic Patient Care Report solution that is licensed as Free/Open Source software under the GNU GPL and distributed free of cost for the benefit of the community.

For background on the project, please see the About page.

openEPCR is currently in the planning stage. I haven't even chosen a language to code in yet (though I'm heavily leaning towards Java, as it has been proven to work well for similar projects). I am really looking for the following assistance:

• I need people to suggest required features and, more importantly, explain how your PCR system should work, what data is required, etc.
• Development assistance.

If you'd like to provide some assistance either in terms of coding or suggestions, please e-mail me.

Please stay tuned to this site for further updates.

If you'd like more information, you can look through the Plans page which details what specific things need to be worked on, or the Features page which gives a general overview of what the project will (hopefully) be capable of.

Please be advised that most of the information on this site will change, and most of the technical aspects will be changed drastically.

Update on OpenEPCR Status - August 7th, 2011

I've had a few emails recently inquiring about the status of OpenEPCR. Here is the reply that I sent to one of the interested parties. Please read below for more information.

I currently have the software running at my organization, but there's no real release. I started the openEPCR project (finally gave it a name, setup the domain, etc.) when I was in the process of rewriting our ePCR app from a visual basic program to something PHP based (mainly for ease of maintenance, and to integrate with our other administrative tools, schedule, etc. which are all web-based). Unfortunately, after not too long I realized just how complicated it would be to rewrite it in a generic way that would be applicable to any organization.

So... I have the code that we use internally, though I'd need to go through it and make sure it doesn't have any sensitive information here and there. It's a starting point... it's based on a large number of PHP classes that handle generating a HTML form that's identical to our printed (single-side letter size PDF) call report, form validation, database work, and then generating a filled-in printable PDF. There's very very little separation between logic, storage and presentation (definitely not MVC) and changing the actual PCR code would probably be only slightly less time consuming than starting over from scratch. On the positive side, though, it is quite well documented and commented.

Lastly, the suite of tools that currently compose our in-house solution - ePCR, schedule, roster, financial management (geared towards a 501(c)(3) non-profit), equipment sign-out, rig checks, and a VoIP phone-based response call-in system - is pretty disjointed. It started as a schedule/roster, and has had other components bolted on or thrown together since then, as they were needed.

My no-BS assessment is that what I have would be a good starting point in terms of ideas and functionality, for someone with a lot of time and ambition. But, if it's going to be usable by anyone other than our organization, especially any larger organization (we have 2 rigs and a maximum of one duty crew at a time, and that's used as the basis for a lot of assumptions), and especially anyone who can't handle changing the MySQL schema, PHP code, etc. to fit their needs, it's going to need a total rewrite as one cohesive, planned out application.

-Jason

If you're still interested, please drop me an email at jason@jasonantman.com. When I get some free time, and if I have people who express interest, my current plan is this:

1. Get the code we currently have in production organized in some manner, strip out any sensitive information, fill a database with representative/sample information, and get it available in SVN or Git somewhere.
2. Get a working demo online, for people to look at/play around with.
3. Setup a mailing list and/or forum here, to act as a central communication point for people interested in working on an open source ePCR solution, or other open source software solutions for EMS/Fire/SAR.

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.