1 / 5

ACM Across Domains and the Enterprise

ACM Across Domains and the Enterprise. Brief Profile Proposal for 2009/10 presented to the IT Infrastructure Planning Committee Monroe Pattillo 20091007. The Problem.

Télécharger la présentation

ACM Across Domains and the Enterprise

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ACM Across Domains and the Enterprise Brief Profile Proposal for 2009/10 presented to the IT Infrastructure Planning Committee Monroe Pattillo 20091007

  2. The Problem • Each IHE domain defines its own means of event notification to communication devices, where events can range from equipment or infrastructure issues to staff clinical workflow to PCD alarms. • This leads to multiple systems being purchased for nearly every clinical, workflow, or administrative notification requirement, all going to the same or worse yet duplicated communication systems and devices. • One individual required to respond to multiple events or alarms carries multiple communication devices. • Need to create a single event notification capability, based upon the PCD ACM profile, usable across IHE domains and the Enterprise. • The market is ready to accept a single shared solution for all notifications regardless of their source. • Without this proposal the market will continue to deploy multiple, potentially overlapping, but more likely duplicated notification solutions. • ITI can take advantage of the ACM ground work laid last year by PCD

  3. Use Case • A transportation request for a patient being discharged based upon an ADT Discharge request is ITI focused with an ITI defined notification mechanism. • DICOM MPPS notification for patient transportation back to their room following study review complete is RAD focused with a RAD defined notification mechanism. • A PCD alarm to notify a clinician is PCD focused with a PCD defined notification mechanism (ACM). • LAB result availability notification is LAB focused with a LAB defined notification mechanism. • PHARM is similar. • Each has its need for notification. The reasons for notification may be unique. The notification mechanisms should be shared.

  4. Proposed Standards & Systems • ACM has already laid the ground work • It’s an IHE reviewed PCD profile with a Trial Implementation validated at the 2009 NA Connectathon • It’s HL7 v2.5 based, but easily movable to v2.6 • It already includes use cases for more than PCD alarms

  5. Discussion • ITI can take advantage of work already done by PCD in the areas of actor definition, transaction definition, protocol selection, and data item definition. • ACM already includes use cases for more than just PCD alarm events. • ACM already has Connectation and Showcase experience • Remaining work for ACM • Identify/validate open protocol between AM - AC actors • Currently SMTP, with multiple already possible in PCD New Directions • Identify ACM specific event trigger to support broader adoption • Drive vendors to develop capabilities documented but not yet validated • Alarm Archiver (AA) actor • PCD-05 transaction – End to end status response AC > AM > AR • We’ll need a profile editor.

More Related