Presenter(s): Greg Hill Topic Experience Actionable Data with Mirth Level 200
Safe Harbor Provisions/Legal Disclaimer This presentation may contain forward-looking statements within the meaning of the federal securities laws, including statements concerning future prospects, events, developments, the Company s future performance, management s expectations, intentions, estimates, beliefs, projections and plans, business outlook and product availability. These forward-looking statements do not represent a commitment, promise or legal obligation to deliver any material, code or functionality. The development, release and timing of any features or functionality described for our products remains at our sole discretion. Future products developed beyond what is contemplated by existing maintenance agreements, will be priced separately. This roadmap does not constitute an offer to sell any product or technology. We believe that these forward-looking statements are reasonable and are based on reasonable assumptions and forecasts, however, undue reliance should not be placed on such statements that speak only as of the date hereof. Moreover, these forward-looking statements are subject to a number of risks and uncertainties, some of which are outlined below. As a result, actual results may vary materially from those anticipated by the forward-looking statements. Among the important factors that could cause actual results to differ materially from those indicated by such forward-looking statements are: the volume and timing of systems sales and installations; the possibility that products will not achieve or sustain market acceptance; the impact of incentive payments under The American Recovery and Reinvestment Act on sales and the ability of the Company to meet continued certification requirements; the development by competitors of new or superior technologies; the timing, cost and success or failure of new product and service introductions, development and product upgrade releases; undetected errors or bugs in software; changing economic, political or regulatory influences in the health-care industry or applicable to our business; changes in product-pricing policies; availability of third-party products and components; competitive pressures including product offerings, pricing and promotional activities; the Company's ability or inability to attract and retain qualified personnel; uncertainties concerning threatened, pending and new litigation against the Company; general economic conditions; and the risk factors detailed from time to time in the Company s periodic reports and registration statements filed with the Securities and Exchange Commission.
Background Why notifications? Implementation Notification Destinations Notification Subscriptions Monitoring Notifications Use Cases Agenda
Why Notifications? Problem Messages coming in from various sources to Mirth Results Some, but not all messages, need to be forwarded to downstream destinations Rules for forwarding downstream vary from destination to destination Messages may need to be transformed before they can be delivered to a destination The type of delivery may vary from destination to destination Need a mechanism to alert providers of patient events Need an easy way to manage all of the above
Solution Why Notifications? Leverage existing Mirth Results constructs such as Facilities, Patient Groups, Provider Groups to control delivery at a high level Build a simpler interface for defining where messages should be sent (Notification Destinations) Build customizable rules for when a message should be delivered (Notification Subscriptions) Build tool to monitor notification activity (Notification History)
How does it all work The Notification functionality allows you to set up automatic forwarding to specified destinations for incoming clinical data messages that match specified criteria. When messages are consumed by Mirth Results, if any message matches all the criteria in a subscription definition, the message is forwarded to the list of destinations included in that subscription. Both results delivery and event alerting are supported by this module.
Notification Destinations Destinations define where a message should be sent. Fields to define include: Name Type Format Description Notification Destinations can also be used for Ad-Hoc delivery Note: Some of the Notification Types require additional parameters
Notification Types The system supports the following Notification Types: HTTP send the message to an HTTP listener (Mirth Connect channel) Fax send the message via fax Mirth Mail send the message via a Direct email message Network Printer send the message to a network printer Additional types can be added via the creation of a Results Plugin
Notification Subscriptions Notification Subscriptions are automated rules for delivering results. Fields to define include: Name Description Initial Trigger Optional Rules One or more Destinations
Notification Subscriptions The rules can be basic or complex, but all begin with one of the following Trigger Types: Patient the message is for the specific patient Patient Group the message is for one of the patients in the patient group Provider the specific provider is listed in the message as either the Attending, Referring, Consulting, Admitting, Ordering1.5, or Copy To Provider Provider Group one of the providers in the provider group is listed in the message Data Source the message is from a specific source
Notification Subscriptions In addition to the Initial Trigger, rules can be created to further define which messages that are delivered. For advanced rules you can narrow by: Clinical Item Type (lab, radiology, transcription, ADT) Attending Provider s Full Name Attending Provider s NPI Data Source Global ID Diagnostic Service Section ID Event Type Insurance Company Name Insurance Plan Effective Date Insurance Plan Expiration Date Insurance Plan Type Observation Group Label Order Status Ordering Provider s NPI Ordering Provider s Full Name Patient Class Patient Community ID Result Status
Advanced Rules You can also create custom advanced rules by switching to Advanced Mode and writing your own rules in JavaScript using the Results Clinical Data Model. Example usages include: Date Range Filtering (don t trigger an alert on the weekend) Checking for value thresholds (A1C out of range) More complex rules not expressed with simple field equals or field not equals
Use Subscriptions to: Putting it all Together Drive Clinical Workflow Improve Transitions of Care Alert provider when a patient is admitted to the Emergency Room Alert Provider that Diabetic patient lab result is out of range
Driving Clinical Workflow Problem: I m a provider and I want to receive anything that I m named on into my practice s EMR, because I hate logging into external systems and when things come to one place, I don t have to go anywhere else for a patient s external records. Solution: When MR receives an HL7 message that has any provider in a practice named on the message, MR delivers the message to an HTTP hub that will send to the practice s EMR, regardless which EMR it is.
Driving Clinical Workflow DEMO
Improve Transitions of Care Problem: I m a care manager at an ACO, monitoring transitions of care from the hospital to a local long term care (LTC) facility. I want to set up an alert that triggers whenever a discharge happens from the local LTC facility. Solution: When MR receives a CCD from the LTC data source, send a Direct message to the Care Manager.
Improve Transitions of Care DEMO
Alert provider on ED Admit Problem: I want to know when any of my patients are admitted to the ED or admitted to an inpatient facility to my direct messaging application. Solution: Using a Patient Group trigger, when MR receives message for a patient in that group and a rule of patient class of E or I, convert the message to a PDF and using Direct to send it to the physician.
Alert provider on ED Admit DEMO
Advanced Scripting Problem: Provider wants to be alerted whenever one of his Diabetics has an A1C that is out of range Solution: Use Advanced Scripting to analyze the contents of the HL7 message to find an A1C value and, if out of range, alert the Provider.
Advanced Scripting DEMO
Monitoring Subscription Activity As rules fire, entries are added to the Notification History page.
Managing Message History Messages may need to be reprocessed for many reasons such as connectivity issues, busy signals, etc. To replay a message: Select the message Click on Resend Message You can also choose to reevaluate a message and delete a message. The amount of message history kept on this page is managed via the Setup->General Settings->Notifications tab.
Conclusion The Notification system in Mirth Results is a powerful tool that allows you to setup rules for delivering messages or alerts to members of your community. Simple rules can be developed quickly and easily. Complex rules can be developed using JavaScript. The triggering and successful delivery of messages can be monitored using the Notification History page.
Session Survey Please take a moment to complete a brief survey regarding this session. 1. Open your ONE UGM Mobile App (please note: you must have already logged in and accepted the Terms of Use to access this feature) 2. Click the Navigation Button at the top left of the screen 3. Select Sessions 4. Search for and select this session 5. From the sessions details screen, select Survey at the bottom right of the screen 6. Remember to hit Save at the bottom of the survey once you have answered the questions
Any Questions?