Request For Proposal:
Clinical Decision Rules Enhancements and Mental Health Implementation.
OEMR.org
Objective:
OEMR.org 501(c)3 is inviting developers familiar with OpenEMR 4.1x to bid on expanding and optimizing the Clinical Rules Engine (CDR) and Access Control List (ACL). The intent is to provide administrative workflow and disease management tools to the users. This will commonly take form of workflow prerequisite checks for the whole clinic, treatment plan management at the patient group or program level, and patient-specific rules. It should also re-envision the implementation of the ACL to that effect, and allow for much better per-patient or per-treatment program data access control.
Summary of Requirements:
a. Improving the user configuration interface: using visual mapping, a configuration wizard or some other method to give the user a user-friendly plain-language tool to create re-usable rules, rule sets, and ACL objects and users.
b. Create functions to enable the CDR to operate as a patient-specific Treatment Plan engine, and provide export/import functions for the same, including appointment creation and other functions indicated in the analysis at the end of this document.
c. Provide prerequisite checking down to the encounter level to control work flow utilizing the ACL, with options to restrict encounter creation, show warning messages, and send reminders.
d. Enable tracking and reporting of plans and rules in effect for patients at the individual, treatment program, and patient level. Include the plan rule descriptions, appointment dates, and other relevant data into the CCR export or Patient Report.
e. Provide API and user documentation with multiple practical examples for use.
f. Improve the usability and interface of the ACL, complete with interactive documentation to support the CDR engine.
g. Provide a mechanism that makes unitary calls to the ACL for displayable data and sql update calls, replacing individual acl_check() calls with a function in the CDR, replacing current instances of ACL checks in the code.
h. Improve overall performance of the CDR.
The purpose of the above is to provide the user with tools to enable disease management.
Example Scenario:
1. Patient is created in the EMR.
The CLINIC level rule set “Appointments_required” automatically comes into effect, meaning that all encounters of the type “Visit” (vs. “Phone Call”) must have a scheduled appointment.
2. The Patient is assigned to a TREATMENT PROGRAM level rule set “Mental_Health_Counseling”. This sends a dated reminder or message to the program supervisor telling them that the patient needs a counselor assigned in the demographics values. Only admin level personnel and the assigned counselor can access data that makes sql calls to that patient_data.pid.
3. An encounter is created for the patient that includes a visit type or billing code that triggers a rule that creates a dated reminder to the assigned clinician and clinician supervisor indicating that the treatment plan must be approved within 45 days of the date of that encounter.
4. 45 days pass. The patient data value treatment_plan_date has no assigned value. This prevents new encounters for this patient from being created.
5. A treatment plan date is entered. The “Mental_Health_Counseling” rule now requires sets and schedules a treatment plan review date for 180 days, and sends dated reminders.
Scope of Bids
Developers may choose to bid on definable segments of the project, or as overall project design and management. Development plans, including plans of action and milestone dates must be included in bid proposals.
Bid consideration priority will be determined by the following bid content:
1. Project Management/Design proposals.
2. Addresses the CDR engine function development directly.
3. ACL engine function-specific bids.
4. GUI packages.
Post development application packages such as specialty provider configurations or documentation writing will be considered later, but all the above content levels must provide example configurations, user documentation input, and API code documentation for their contributions as applicable.
Suitability and Compensation Overview
Vendors must develop proposal specifications on speculation, but should include include compensation for project planning. Bids should reference developer and administrative work hours/days for defined bid proposal sub-items, and relative compensation rates. Bids will be evaluated in terms of return on investment to the project vs. listed compensation rates. Vendors should provide references, evaluable code with end user and API documentation and/or other portfolio items.
Project Organization
Project financial oversight will be provided by the Board of Directors of OEMR.org. Bid package review will be by the ad hoc OpenEMR community members. The OpenEMR project and OEMR.org will be providing communication matrix and project development environment. This is to include a centralized communication website (project specific bulletin board), documentation wiki, bug tracking, development demo and most importantly the OEMR501c3 code-base repository on GitHUB for integration into the development code-base. All relevant communication must be public to the OpenEMR community at large. All non-derivative code must be attributed to the author, and licensed to OEMR.org (to wit, the funding organization will own the code, and release it under the appropriate open-source license to be determined by the larger OpenEMR community).
Collaboration and Licensing
Vendors may, and are encouraged to engage with programmers, users, and evaluators in the OpenEMR community. Assistance rendered (gratis or paid) to the Vendor by outside collaborators will not affect Vendor compensation upon completing the job specifications and QAI checks. All contributing parties MUST be included in code and source attribution. Vendors utilizing other open-source code in their projects must comply with licensing. All licensing must be compatible and evaluated as acceptable to OEMR.org. Use of existing code should not require a re-structuring of the project or additional packages to operate it. White-page code on the other hand, should feel free to implement project-level improvements to the code base or database structure.
Bid Submission Guidelines
Bids should be submitted by January 31, 2013. Please submit bids to the OEMR Executive Directive:
Samuel T. Bowen, MD
[email protected]
2365 Springs Road NE
Hickory, NC 28601
828-612-4932