Authoring
Authoring / Editing of Knowledge Modules
Scenario Details: Over the next several days, David modifies the AMIA module for the particular best practices that Healthcare Plan A has adopted for their local population. He uses a graphical tool to review and validate that the definition for “asthma” is acceptable for his institution, ensures that the rules have triggers that are supported locally, and creates new notification parameters for how evaluation results will be communicated. He decides that the ordering physician should receive an email notification when results are available, that a peak flow should be ordered, not just recommended, in the system if the patient has not had a screen within the past 12 months, and that the institution’s asthma registry system should be updated with any new demographic information. He then assigns a clinical priority, thereby ensuring the system appropriately processes triggering messages according to patient safety and risk considerations. He tests both the logic and clinical intent of the new rules in a test environment in which he steps through the rule flow by triggering the module with different lab values. Satisfied that his rules are satisfactory for the population at large, David deploys the rule into the staging area where Engineer Ed validates the performance implications before applying it to the production system where it affects all diabetics and all providers.
David likes this new rule so much that he decides to use the just deployed institutional rule as a template. In his general user role, he finds the new rule in the list of institutional templates, makes a personal copy, and then modifies it for some select asthmatics for when they are admitted to the hospital. He modifies the criteria for defining the patients that the rule applies to, adjusts some of the threshold values used within the rules themselves, and then changes the notification mechanisms. For these particular patients, he wants to be emailed immediately with inpatient lab results when they are ready and he requires that he be paged if he fails to review critical lab results in the system within 30 mins of being emailed. He reviews his hospital contact information, makes a quick update to his office phone number, and then selects his pager number for the notification alert. As this rule is a personal rule that by definition can only affect him, he deploys the rule directly into the production system and activates it immediately. Finally, thinking other pulmonologists might like to see the rule, he optionally allows its metadata to be searchable in the template repository as a public, non-institutional rule template.
Actors: Institutional Clinical Domain Expert (Provider)
Requirements:
Requirement # | Description |
2.3.1 | The System shall be capable of identifying a patient or group of patients that a knowledge module applies to using static attributes. |
2.3.2 | The System shall be capable of identifying a patient or group of patients that a knowledge module applies to using dynamic attributes. |
2.3.3 | The System shall be capable of defining patient collections as inpatient, outpatient or both if defining attributes are ambiguous. |
2.3.4 | The System shall be capable of scoping rule execution to inpatient or outpatient data if the patient collection is so defined. |
2.3.5 | The System shall define knowledge modules as institutional or personal according to the role of the author. |
2.3.6 | The System shall ensure knowledge modules are private to the author by default, and optionally exposed as public when appropriate or when deployed as institutional. |
2.3.7 | The System shall ensure institutional knowledge modules are visible to all for use as templates for personal rules. |
2.3.8 | The System shall be capable of chaining and branching logical operations with a rule. |
2.3.9 | The System shall enable a configurable prioritization of institutional and personal rules |
2.3.10 | The System shall be capable of defining by what methods the results are to be delivered and to whom. |
2.3.11 | The System shall be capable of defining that rule results are to be delivered to another System defined by an IP address/port or service identifier. |
2.3.12 | The System shall electively define a period of time before an unacknowledged notification message is forwarded to an alternative recipient. |
2.3.13 | The System shall expose patient demographic data elements for use in creating knowledge modules. |
2.3.14 | The System shall expose notification mechanisms (voicemail, pager, email, etc) for use in creating knowledge modules. |
2.3.15 | The System shall be capable of testing and validating knowledge modules workflow. |
2.3.16 | The System shall expose staff demographic data elements for use in creating knowledge modules. |