Summary
Description of the profile
Event Processing and Notifications enables monitoring of services in the ecosystem and provides for asynchronous updates by services, effectively allowing a loose coordination of services that both provide and respond to conditions (possibly defined in business rules).
The semantic infrastructure will provide a placeholder to specify events and triggering conditions for data and services. The platform monitors these events at runtime and acts on these events.
Capabilities
Requirements traceability
Requirement |
Source |
Capability |
|---|---|---|
Support notification of what is new then need to find the computational and collaboration specifications. |
Gap Analysis::Manage::087 - Notifications |
|
Artifact lifecycle management and metadata requirements include the ability to: * Manage lifecycle, governance and versioning of the models, content and forms * Establish relationships and dependencies between models, content and forms * Determine provenance, jurisdiction, authority and intellectual property * Create represention and views of the information, realized through the appropriate transforms * Provide access control and other security constraints * Create annotations for better discovery and searching of artifacts * Develop usage scenarios and context for the information * Provide terminology and value set binding The artifacts are bound to the services via the service metadata. The service metadata combined with the artifacts and supporting metadata provide a comprehensive service specification. The artifact management requirements listed above are derived from the following use cases: * caEHR: The caEHR project has adopted ECCF for specifications and CDA documents for interoperability. The caEHR project requirements include the need for an infrastructure for managing all the artifacts generated during specification process, including HL7 models and documents. The caEHR project also intends to publish these artifacts for the community and vendors. The infrastructure needs to support better discovery, making all the relevant information available in the right context. * ONC and other external EHR adopters: ONC has adopted CCD and CCR for meaningful use. All national EHR implementations are expected to support forms and the semantics of these forms play a critical role in interoperability. The semantic infrastructure must provide a mechanism to create, store and manage these forms. * Clinical Trials: Clinical trials use forms to capture clinical information, and the semantics captured by these forms are critical for interoperability and reporting. The semantic infrastructure must provide a mechanism to manage the lifecycle of these forms. |
Semantic Infrastructure Requirements::Artifact Management::Artifact Lifecycle Management |
|
Event Processing and Notifications enables monitoring of services in the ecosystem and provides for asynchronous updates by services, effectively allowing a loose coordination of services that both provide and respond to conditions (possibly defined in business rules). The semantic infrastructure will provide a placeholder to specify events and triggering conditions for data and services. The platform monitors these events at runtime and acts on these events. Link to use case satisfied from caGRID 2.0 Roadmap: As patient care proceeds, the system notifies the designated clinicians that data (for example, images) are ready for review. Similarly, when notifications are received, event processing logic allows the appropriate parties to assign clinicians for care. In order to facilitate better treatment (a learning healthcare system), as new de-identified glioblastoma data is made available, notifications are sent that could indicate a recommended change in the treatment plan. |
Semantic Infrastructure Requirements::caGRID 2.0 Platform and Terminology Integration::Event Processing and Notifications |
eventNotificationMessageExchangeModel
Description
Event Notification Message Exchange Model create, destroy, edit, maintains.
Support notification of what is new then need to find the computational and collaboration specifications.
Message exchange is the means by which service participants (or their agents) interact with each other.
There are two primary modes of interaction: joint actions that cause real world effects, and notification of events that report real world effects.
An event is a report of an occurrence that is of interest to some participant; in our case when some real world effect has occurred. Just as action messages will have formatting requirements, so will event notification messages. In this way, the Information Model of a service must specify the syntax (structure), and semantics (meaning) of the action messages and event notification messages as part of a service interface. It must also specify the syntax and semantics of any data that is carried as part of a payload of the action or event notification message.
In addition to the Information Model that describes the syntax and semantics of the messages and data payloads, exception conditions and error handling in the event of faults (e.g., network outages, improper message formats, etc.) must be specified or referenced as part of the Service Description.
The correct consequence of realizing a real world effect may be to initiate the reporting of that real world effect via an event notification.
The Process Model characterizes “the temporal relationships between and temporal properties of actions and events associated with interacting with the service.” Thus, MEPs are a key element of the Process Model. The meta-level aspects of the Process Model are provided as part of the Service Description Model.
An event is realized by means of an event notification message exchange that reports a real world effect; specifically, a change in shared state between service participants. The basic event notification MEP takes the form of a one-way message sent by a notifier agent and received by agents with an interest in the event.
Often the sending agent may not be fully aware of all the agents that will receive the notification; particularly in so-called publish/subscribe (“pub/sub”) situations. In event notification message exchanges, it is rare to have a tightly-coupled link between the sending and the receiving agent(s) for a number of practical reasons. One of the most common is the potential for network outages or communication interrupts that can result in loss of notification of events. Therefore, a third-party agent or service is often used to decouple the sending and receiving agents .
Requirements addressed
Overview of possible operations
To be provided.
