This wiki has undergone a migration to Confluence found Here
Difference between revisions of "OO Behavior BF"
Jump to navigation
Jump to search
Line 6: | Line 6: | ||
* Participation Context – Participation Context is the context in which the template for the payload was instantiated. Participation context includes, but is not limited to author, subject, record target, verifier and transcriber. | * Participation Context – Participation Context is the context in which the template for the payload was instantiated. Participation context includes, but is not limited to author, subject, record target, verifier and transcriber. | ||
− | * Accountability – Accountability is separated into Request and Fulfillment Management, and involves concepts like custody, provenance, and jurisdiction. The custodian for an order may change over time, so there needs to be clear mechanisms in place in the behavioral order model for transferring custodianship of an order. | + | * Accountability Management – Accountability is separated into Request and Fulfillment Management, and involves concepts like custody, provenance, and jurisdiction. The custodian for an order may change over time, so there needs to be clear mechanisms in place in the behavioral order model for transferring custodianship of an order. |
− | * Request Management – The state of the request for an order is managed by the entity (organization or device) that | + | ** Request Management – The state of the request for an order is managed by the entity (organization or device) that is given custody of the order. |
− | * Fulfillment Management - An order is intended to be fulfilled (satisfied) by the actions taken by the performer(s). The custodian of the order request is responsible for determining if the actions taken by the performer fulfill the order. | + | ** Fulfillment Management - An order is intended to be fulfilled (satisfied) by the actions taken by the performer(s). The custodian of the order request is responsible for determining if the actions taken by the performer fulfill the order. |
* Request Completeness – An order clearly communicates the action to be taken by the performer(s). | * Request Completeness – An order clearly communicates the action to be taken by the performer(s). | ||
* Payload Completeness - A payload is an assemblage of information that may be verified. An order payload includes relevant details necessary to perform the requested action(s). | * Payload Completeness - A payload is an assemblage of information that may be verified. An order payload includes relevant details necessary to perform the requested action(s). |
Revision as of 21:43, 24 November 2010
Back to Orders & Observations WG main page
Back to Essential_Concepts_OO_Behavior main page
Behavioral Principles for Orders
- Participation Context – Participation Context is the context in which the template for the payload was instantiated. Participation context includes, but is not limited to author, subject, record target, verifier and transcriber.
- Accountability Management – Accountability is separated into Request and Fulfillment Management, and involves concepts like custody, provenance, and jurisdiction. The custodian for an order may change over time, so there needs to be clear mechanisms in place in the behavioral order model for transferring custodianship of an order.
- Request Management – The state of the request for an order is managed by the entity (organization or device) that is given custody of the order.
- Fulfillment Management - An order is intended to be fulfilled (satisfied) by the actions taken by the performer(s). The custodian of the order request is responsible for determining if the actions taken by the performer fulfill the order.
- Request Completeness – An order clearly communicates the action to be taken by the performer(s).
- Payload Completeness - A payload is an assemblage of information that may be verified. An order payload includes relevant details necessary to perform the requested action(s).
Design Principles
These principles can be realized in these design principles.
- Orders may be made up of many actions (or actions)
- Accountability is transferable
- The Community obligations may be bound to the technology through context or contract bindings.
Characteristics of Behavioral Model Components
The HL7 Interoperability Paradigms use common model components that embody these principles. The following table is from the original, and is included here for traceability.
Principle | Contract | Control Wrapper | Context Wrapper | Payload |
Context | X | X | ||
Management | X | X | ||
Fulfillment | X | X | ||
Actionable | X | |||
Complete | X |
Within these definitions:
- Services comprise:
- Contract
- Control Wrapper
- Context Wrapper
- Payload
- V3 Messaging comprise:
- Control Wrapper
- Context Wrapper
- Payload
- Documents comprise:
- Context Wrapper
- Payload
Using the BF Principles and Components, this table becomes:
Payload Binding | Information | |||
Characteristic | Interaction Wrapper | Control Wrapper | Context Wrapper | Payload |
Participation Context | X | X | ||
Accountability Management | X | X | ||
Request Completeness | X | |||
Payload Completeness | X |