On this weeks FHIR Workflow call, we discussed the similarities between the task and message header structures in FHIR. The notions we associate with messaging, services and tasks have a lot of overlap, and Lloyd asked us to consider these for next week.
Taking a crack at this:
Task as a resource is a record of things to do or what has been done.
Messages are a record of things that have been communicated.
Operations are a record of services to perform. We don't really have a resource that records the invocation, what we have is a resource (OperationDefinition) that describes HOW and invocation can be performed.
Communications are part of "things that can be done", and communications can initiate other activity.
The focus of the MessageHeader resource is to ensure that a message gets where it needs to go in a timely, consistent and predictable fashion. To do that, it needs to know the source and destination of the message, the content of the message, and other critical details needed to ensure appropriate routing with respect to timeliness, consistency and predictability.
The focus of the Task resource is to capture the status of activity in providing a service. This enables the steps required to to perform a service to be monitored, managed and adjusted as necessary to optimize service delivery. To do this, the task resource needs to know how a task is composed, what actors may be engaged in or affected by the task, and the parameters that may affect the performance of the task.
An operation initiates a service, and the OperationDefinition resource describes how that service is called. To do this, it describes what the service does, and the parameters that might affect its behavior.
In system automation, we should realize that ANY detectable event can be used as a trigger to invoke activity. Thus, FHIR based systems might use any of three ways above to automate the delivery services. Receipt of a message could trigger activity. Creation (or update) of a task could trigger activity. Invoking an operation could trigger activity. And even creating or updating a resource could be a way to invoke activity.
So, we should be looking at design patterns for the invocation of services. Messaging, services, and workflow are all design patterns that can support this. Invocation of a service is performed by "binding" that service to an event, where event could be described as the "discovery" of a resource meeting certain criteria.
All three can be used together. A message can be sent from one system to another saying "Please perform this service". Upon receipt of the message, the receiving system can create a set of tasks which must be performed to manage the activity. Upon creation of one of these tasks, another component monitoring its task queue can invoke activity directly using one or more operations.
One of those invocations could then involve communication with another system, requiring messaging to communicate a request to perform additional services (e.g., a lab, on obtaining a positive identification of Type A Influenza might request subtype evaluation from a reference lab).
On boundaries, messaging is used when what needs to be monitored or ensured is the communication activity. Tasks are used when what needs to monitored or managed is the workflow activity. Operations are used to invoke behaviors directly.
With RESTful approaches, the essentials of messaging are already addressed within the HTTP or HTTPS layer in terms of routing and communications. However, more complex messaging scenarios can use FHIR Messaging to support more complex communication management.
There also may be cases where where a system needs to both ensure communications, and manage workflows. In these cases, messaging can be to communicate tasks which reference the activity to be performed.
Keith
Taking a crack at this:
Task as a resource is a record of things to do or what has been done.
Messages are a record of things that have been communicated.
Operations are a record of services to perform. We don't really have a resource that records the invocation, what we have is a resource (OperationDefinition) that describes HOW and invocation can be performed.
Communications are part of "things that can be done", and communications can initiate other activity.
The focus of the MessageHeader resource is to ensure that a message gets where it needs to go in a timely, consistent and predictable fashion. To do that, it needs to know the source and destination of the message, the content of the message, and other critical details needed to ensure appropriate routing with respect to timeliness, consistency and predictability.
The focus of the Task resource is to capture the status of activity in providing a service. This enables the steps required to to perform a service to be monitored, managed and adjusted as necessary to optimize service delivery. To do this, the task resource needs to know how a task is composed, what actors may be engaged in or affected by the task, and the parameters that may affect the performance of the task.
An operation initiates a service, and the OperationDefinition resource describes how that service is called. To do this, it describes what the service does, and the parameters that might affect its behavior.
In system automation, we should realize that ANY detectable event can be used as a trigger to invoke activity. Thus, FHIR based systems might use any of three ways above to automate the delivery services. Receipt of a message could trigger activity. Creation (or update) of a task could trigger activity. Invoking an operation could trigger activity. And even creating or updating a resource could be a way to invoke activity.
So, we should be looking at design patterns for the invocation of services. Messaging, services, and workflow are all design patterns that can support this. Invocation of a service is performed by "binding" that service to an event, where event could be described as the "discovery" of a resource meeting certain criteria.
- In Message oriented system, the arrival of a message is (or leads directly to) the invocation of a service.
- In a Task oriented system, the update of a task can lead to the invocation of a service.
- In an operation, the invocation of an operation leads to (or simply is) the invocation of a service.
All three can be used together. A message can be sent from one system to another saying "Please perform this service". Upon receipt of the message, the receiving system can create a set of tasks which must be performed to manage the activity. Upon creation of one of these tasks, another component monitoring its task queue can invoke activity directly using one or more operations.
One of those invocations could then involve communication with another system, requiring messaging to communicate a request to perform additional services (e.g., a lab, on obtaining a positive identification of Type A Influenza might request subtype evaluation from a reference lab).
On boundaries, messaging is used when what needs to be monitored or ensured is the communication activity. Tasks are used when what needs to monitored or managed is the workflow activity. Operations are used to invoke behaviors directly.
With RESTful approaches, the essentials of messaging are already addressed within the HTTP or HTTPS layer in terms of routing and communications. However, more complex messaging scenarios can use FHIR Messaging to support more complex communication management.
There also may be cases where where a system needs to both ensure communications, and manage workflows. In these cases, messaging can be to communicate tasks which reference the activity to be performed.
Keith
AuditEvent records what happened, in addition to any other resources created like DiagnosticReport... AuditEvent is there to record the event regardless of why, where, who, etc... it simply records facts. This is why it is so flexible. Yet it isn't the normal output, that would be defined by the happy-path of the workflow.
ReplyDelete