1 / 19

What is proper format for the XDW document

What is proper format for the XDW document. In its first year, XDW has been exposed to feedback, and this public comment phase to allow clarifications of the requirements and future expectations for workflow management. To elicit comments now, rather than later

gore
Télécharger la présentation

What is proper format for the XDW document

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. What is proper format for the XDW document

  2. In its first year, XDW has been exposed to feedback, and this public comment phase • to allow clarifications of the requirements and future expectations for workflow management. • To elicit comments now, rather than later • This proposal is based on attempts to detail how an XDW workflow would be encoded into a CDA document. • While XDW is in trial implementaton, there will be further tuning of XDW, its requirements and expectations.

  3. Alternatives • Public Comment version of XDW • A CDA document, but PC supplement is very short on details regarding templates, constraints, etc. • Proposed Alternative • An IHE defined Document, based on IT workflow standards. • Use the IT standards for the XDW document task description. • Use XDS, etc. for the communications, document management, etc. • In other words, the current XDS proposal, but with a different XDW document format.

  4. Existing workflow standards • Relevant standards • BPEL • http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf • BPMN • http://www.bpmn.org/ • OASIS Human Task • http://docs.oasis-open.org/bpel4people/ws-humantask-1.1.pdf

  5. BPEL • BPEL is in use and is a published standard. It is integrated into Java, .NET, and other languages and frameworks. • BPEL assumes that a complete workflow can be defined: • That covers all reasonable possible work paths • Can be fully specified in advance • The only variability supported is that parties to the workflow can be identified as tasks are created, task details can vary, and tasks may take different paths. • BPEL assumes that there is a master controlling system or process for the entire workflow. It does not have federated independent workflows, although it does allow for subcontracting. • BPEL explicitly recognizes that manual human tasks don’t fit this model, and defines a stub for these tasks.

  6. BPEL for XDW • BPEL is not a good fit for medicine and XDW. • Most of the medical tasks involve people and unpredictability. BPEL just provides stubs this kind of task. • XDW is specifically for the coordination of dispersed and different organizations. The BPEL assumption of a single master coordinating system is not valid. • XDW does not assume that the workflow is defined in advance. Most medical workflows are dynamically defined and modified as part of the diagnosis and treatment process. BPEL requires that the workflow be known in advance. • XDW steps are a mix of automated and manual tasks. BPEL only supports stubs for the manual tasks.

  7. BPMN • Extends BPEL • Primarily a documentation oriented standard, rather than a communications or transaction standard. • Manual tasks remain stubs, but BPMN points to the OASIS Human Task as a way to document a manual task. • BPMN is not appropriate for XDW for the same reasons BPEL is not: • Its scope is the fully pre-defined workflow, operating under the control of a single management system. • It still stubs out manual tasks, although it points to the Human Task standard as a way to describe tasks.

  8. Human Task From the introduction of the Human Task specification • Purpose “human task is used to specify work which has to be accomplished by people.” • To solve the problem that “ the workflow management system managed the entirety of a task’s lifecycle, an approach that did not allow the means to directly affect a task’s lifecycle outside of the workflow management environment … Particularly significant was an inability to allow applications to create a human task in such tightly coupled environments.”

  9. The Human Task Standard • There are several major components • XML-encodings for the description of a human task, relationships, and operations on human tasks. • Definitions for Web Service interfaces to systems that manage human tasks. It provides a variety of read, write, and modify operations about human tasks. • The portion that is of direct interest is the definition of the individual task.

  10. Why only the task description • The XDW assumes that there are multiple organizational control systems. • The XDW environment lacks the predictability needed to set up appropriate communications between each of these organizational control systems. There are often administrative, legal, security, and other barriers to such communications. • XDW is a loosely coupled system, and the Human Task standard for Web Services assumes that a tightly coupled system can be established.

  11. What is gained from using task description? XD* Document Sharing Internal System • Individuals and organizations each have their own task management system. Some of these will use the BPEL/BPMN standards internally. • By using the same task description data element, an organization that uses BPEL internally can extract the task description from the XDW document and put it directly into their task management system when they start work. • Finished work can be extracted from the BPEL based system and put into the XDW document when complete. XDW v1 Internal Task Management System Task

  12. Description of a Human Task • tTaskInstanceData is the data element defined to describe a task • This is a subset of the whole Human Task standard. • This is just the description of the task • This does not define the inter-task relationships. • This does not define the web services messaging about tasks • The proposal is to use this as the description for a task.

  13. Task Description Task List and Major Elements of a Task Description

  14. tTaskInstanceData • A Task instance must include • An id • A task type and description • A name (for the task) as a text string • A current status (based on the Human Task state machine rules) • Creation time, last Modified time • Input list (which may be explicitly empty) of document references or inclusions. All forms of reference are allowed. • Output list (which may be explicitly empty) of document references or inclusions.

  15. tTaskInstanceData • A task may also include • A variety of task metadata, such as current performer, notification participants, escalation flag. • Fault description (for completed tasks). • Renderings (These can be created, added during performance, or upon completion. They can be included or by reference. They should be resolvable into something that can be displayed.) • Comments (these are added during the performance of the task, and are limited to unstructured text). • Adhoc Attachments (these are things added during the performance of the task, and the encoding permits any kind of external reference to documents, etc.) • A subordinate task tree, potentially infinite. • And it is infinitely extensible.

  16. Proposed Constraint • BPMN introduces the concept of a “lean task” to reduce implementation difficulties. The “lean task” has two limits: • No renderings. The Human Task definition of a rendering is extremely vague and flexible. This makes interoperability and testing very difficult. • No subordinate tasks. The potentially infinite recursion of subordinate tasks makes implementation very difficult. The “lean task” environment expects each task to have its own separate description. • These limits are appropriate for XDW for the same reasons.

  17. XDW extensions • XDW will specifically constrain that when an input document or output document is in the XDS registry there must be a document ID reference in the “input” or “ouput” section of the task. • This is fully consistent with the Human Task intention and schema for input and output. • The Human Task schema allows any kind of reference or by value inclusion for inputs, attachments, and outputs. • Prohibit by value inclusion of documents or comments in Inputs or Outputs. • The use case and architectural assumption is that any clinical data will be managed by reference. • XDW must extend the task ID requirement to be a globally unique ID. • Human task standard only requires it to be unique within the system. In the case of XDW, there is no single controlling system so it must be globally unique, i.e., an OID.

  18. Structure of XDW Document • This is incomplete at the moment. Needs editing. • Some is copied from CDA, e.g., • recordTarget for patient • ConfidentialityCode • Some is new • TaskList • Workflow Description (to be added)

More Related