aethelwulffe wrote on Friday, August 24, 2012:
I am providing some input from a *somewhat* non-technical standpoint.
Introduction:
A requirement for a workflow system, a multi-level provider scheme, and other functions to be implemented in OpenEMR came up with the following observations:
1. The existing CDR engine can be expanded and refined to provide access control and perform administrative task automation for both patient care and user access. This would be more than a “Clinical Decision Rules” system, but I’ll keep that term for this discussion.
2. The ACL system, while we barely tap the power of it, is not really designed to be the basis of a CDR engine, but the CDR engine may be able to take over it’s role.
The basic ideas follow:
Access control
A user logs in. The users access checks, as well as global practice/clinic-level variables are checked via admin configured rules (much as the existing ACL system does), yet is equipped with much more comprehensive access elements than the current system comes equipped with. The administrator configures the access rules for the user are configured via a GUI that does not require hard-coded access checks in every file in the code, allowing much better control and user configuration. Access to reports etc… is controlled as you might expect. Then it gets weird. Access to patients is controlled by a CDR cross-check. This could make it so that a provider only has access to patients assigned to them, probably via the patient demographics. Access could be restricted by provider, squad, or level of the provider using a configured patient data target.
Patient Workflow requirements
Patients can have rules assigned to them by program, insurance variables, individual configuration, diagnosis code in the “issues” system, or from a treatment plan form (or all of the above). If the CDR engine has this data, it can be used to send dated reminders, create appointments for the patient or their provider, send messages (including using the Alerts system) and other administrative functions that require admin assistants many hours. It can also set prerequisites, such as not permitting billing to be entered or visits to be scheduled when some prerequisite has not been fulfilled. These elements are the basis of both basic business workflow, as well as a plan based treatment system. Many of the intents and defined Meaningful Use standards seem to be pointing to exactly this sort of capability.
One of the remaining questions is how the rules are configured at the individual patient level. The best suggestion seems to be to configure via forms, such as a Treatment Plan form, either as an encounter form or otherwise.
I have identified a few development goals that I think can help achieve this. The B.O.D. of OEMR and attending members of the community have discussed a few of the following:
The following upgrades to the CDR engine may help provide workflow, specialty and treatment plan functionality in OpenEMR:
1. Full GUI configuration of rules. Currently, full configuration and expansion of the existing capabilities can only be achieved via code.
2. CDR/ACL interface. Throughout the EMR code, instances of acl checks can be replaced to simply check access as per the CDR system. This allows:
a. Per Patient, per patient group or program, and per user checks for access control at every level, configured via the CDR GUI.
b. Checks against workflow requisites to be made by the same call against the CDR to ensure that the user has not bypassed a workflow element.
c. A simplification of the ACL checks in the code.
d. Multi-level providers/users to be configured via a practice-wide CDR rule.
e. Possibly supercede the ACL system, as the CDR would need to perform many of the same functions anyway.
f. Allow the Rules to essentially control the user session variables, compressing the expansiveness of the code and streamlining the approach.
3. CDR functionality added for Calender appointment checks/creation/interface.
4. CDR interface with an upgraded “issues” system to allow configured issue categories to allow that legacy system to be used to determine elements in a patients treatment plan or treatment protocol. “Issues” may need an expansion or supplement in the form of a Treatment Plan form. (final configuration of this needs more discussion, my arguments based on Mental Health and Behavioral Health having already been presented).
5. CDR interface (depending on issues discussed in the introduction) with accounts receivable/billing activity to allow reminders, messages and calender provider/patient appointments to auto-populate based on configured requirements. _EXAMPLE: As per a Medicaid prepaid counseling program, a patient must have a Treatment Plan completed 45 days after the first billable service. When the first billable service is completed, the rule must then create a dated reminder for the patient’s assigned counseling provider (demographics field). The dated reminder system MIGHT expanded to check for an encounter that completes the plan, but even without it, the CDR could restrict access and not permit another billable service to be entered without the treatment plan being in the system. When the plan is complete, another rule takes over to identify the date at which the plan review is due…and so on.
_
Performance of the system while running the CDR engine in this manner has been discussed. Despite the issues with running reporting for meaningful use, the actual CDR portion does not seem to have the issues that other bits of the meaningful use “package” does.
Thanks for listening
-Art
). Regarding the first one, my proposal seems to be a good way to set up the back-end for per-patient custom rules (I am sure a couple things will come up in the engine when doing this, but should be able to get up and working with minimal resources; note gui elements will need to be built around it, though, which will likely be where the majority of the resources will go towards).