Docstoc

XDW_public-comment-Charles-V3

Document Sample
XDW_public-comment-Charles-V3 Powered By Docstoc
					ITI: XDW
            Note: comment form column formatting MAY be off by one column, the public comment form we used initially w

Submitter   Profile   Vol       Section #   Line #

Charles     XDW             1 Introduction 118-130
                              Section 2.2.X 250_256
                              Section X     260-272




Charles     XDW             1 Introduction 131-144
                                           and 164




Charles     XDW             1                        143
Charles   XDW   1             161




Charles   XDW   1 5.Y.2.1.3   1027




Charles   XDW   1             1055
                1




Charles   XDW   1 XX.1   605




Charles   XDW   1 XX.1   605
Charles   XDW   1 5.Y.3.3   1110




                1 5.Y.5.2   1165




Charles   XDW   1 5.Y.5.3   1170




Charles   XDW   1 5.Y.5.4   1181




Charles   XDW   1
Charles   XDW   1X   316




Charles         1X   316




Charles   XDW   1    221
Charles   XDW   1             230




Charles   XDW   1             235




Charles   XDW   1             277

Charles   XDW   1       294-295


Charles   XDW   1             311




Charles   XDW   1 X.1         322

          XDW   1 X.2         345
          XDW   1 X.3   352




          XDW   1 X.3   368




Charles   XDW   1 X.3   377
Charles   XDW   1 X.3   377




Charles   XDW   1 X.3   394
Charles         1 X.4.1.3   433




Charles         1 XX.1      499




Charles   XDW   1 XX.2      608
Charles   XDW   1 XX.2   608




Charles   XDW   1 XX.2   608




                1 XX.2   608
1 XX.3   710




1 XX.4   810
formatting MAY be off by one column, the public comment form we used initially was apparently changed format

          Issue

          Small improvements in the Supplement Intro:
          "The Cross-Enterprise Document Workflow (XDW) profile enables participants in a multi-
          organizational environment to track the steps related to patient-centric workflows as they coordinate
          their activities. It builds upon the sharing of health documents provided by other IHE profiles such as
          XDS, adding the means to associate documents to a patient-specific workflow. XDW provides a
          common interoperability infrastructure upon which a wide range a specific workflow “content” may be
          defined. It is designed to support the complexity of health services delivery with much flexibility to
          adapt as workflows evolve.
          This profile defines a shared workflow tracking data structure, called a “workflow document” that
          records past steps of a workflow and maintains the references to health information input and output
          associated with each step. Such shared workflow state information allows the various participating
          systems to be aware of the history (past steps) of any of the workflows known for a patient, access the
          workflow current state and remain coordinated by updating this shared document with the new steps
          they have performed."




          Following the list of bullets relative to the properties of the "a common, workflow-
          independent interoperability infrastructure", a graphics would help the reader better visualize
          the points made. This graphic is part of an XDW overview slide deck that was tested with
          some audiences during public comment and was proved effective.




          The bullet: "Facilitates the integration of multi-organizational workflows with the variety of
          existing organization workflow management systems."
          is correct but needs to be extended to explain that XDW enables peer-to-peer ( or
          federated) workflow synchronization beetwen the participating workflow
          managment systems in the point of care systems.
The bullet: "Leave the driving of the workflow to the health professional. Future steps are
not managed in XDW, but left to the business layer above XDW where requests or
expectations are considered integral to the outcome of previous steps (care plans, requests,
etc.)."
is incorrect in stating that XDW does not manage future steps. In fact XDW
reference the defintion of the workflow step to which all particpants are bound by,
thus providing the framework for participants to behave accordingly.

In the section 5.Y.2.1.3 CDA Header Relationships, replace, append, and transform
are described. It seems clear that append and transfrom are not applicable to XDW.
They should be removed. Replace:RPLC may be relevant, but is not discussed in
any details. Is XDW requiring that RPLC be tracked witjin the XDW document or
only through the XDS metadata.



An XDW workflow needs to be uniquely identified. In the PC version there is some
confusion about what mechanism to use. This is required for a variety of use cases.
The creator of new workflow instance wants to periodically check the status of the
workflow it initiated (need to be queryable metadata). A referenced document
needs, in its clinical content, to refer to one or more workflows that may be
completed or on-going, but not to any specific point in the workflow (so pointing to
a specific XDW document would not be appropriate). In the Public Comments
proposal the sepcification of the proposed mechanisms needs to be very explicit to
specify clerly a single identifier and associated mechanism to create it, query by it,
etc.
The current XDW Profile proposal is supported by XDS, but no clear statement is
made about use of XCA in a federated environment with multiple XDS domains.
The support of XDW with XCA cannot be ignored. If certain gaps are identified,
their resolution should be discussed in the introduction to this supplement




In the process flow for the Use Case e-Prescription Workflow, as shown by Figure
XX.1.4-1. Basic Process Flow in XDW Profile, there seems to be an inconsitency.
After the "Content Creator provides the Pharmaceutical Advice Document and
replaces the old Workflow Document with the updated one (9,10)", it is not clear
why the Content Creator would then need to re-query for the same documents in the
following step (11,12). This query appears unnecessary if the patient stays at the
pharmacy for both validation and dispensation.




There is no definite specification of the approach in XDW to lock/unlock a
workflow while an activity is in progress or how "race condition" are resolved when
paralell activities are performed (two concurrent updates of the same XDW
instance). There is a definite need for a single well defined mechanism for assuming
ownership of a workflow, the issues about "unlocking" this assumption of
ownership, the rules about expiration of such blocking. A common model is needed
beyond an example in volume 1 where an "in progress" step is used.
Folder codeList Value is not fully specified in the metadata specification table
5.Y.3.3 for CodeList:
"Contains the set of codes specifying the type of clinical activity that resulted in
placing XDS Document in this XDSFolder.
The value shall be “XDW Workflow Context Folder”."
The CodeList and DisplayName are two ditinct entries that booth need to be
defined. In the proposed text the display name is specified as a code. This is
incorrect.

It should be only possible to add, but not to update specific past steps.




The tilte of this section:
"5.Y.5.3 Add clinical document to workflow"
Is not correct. It should speak of performing a new step in a workflow which results
in creating a new document.
The title and section text should reflect this better semantic.



The following section is quite confusing:
"5.Y.5.4 Get a clinical document referenced by workflow
The Workflow Document contains details of each step as well as the
DocumentEntry.uniqueId of all the referenced clinical documents, so a single stored
query is adequate to get all the clinical document metadata. The query is needed
because the workflow document contains only references to the clinical documents."

The explanation about the need for a single query appears incorrect, as not all XDS
document entry metadata for the referenced documents is included within the
workflow document.




There should be a common thread of examples across the entire profile. This would
facilitate the readers comprehension from the use cases, to the WF document
structure and sample XML.
The use of XDW requires the specification of a workflow definition by the different
workflow environments where XDW will be used. The current XDW profile should
better present the overall architecture within which XDW is intended to be used.




Need to clarify the boundaries of XDS vs XDW vs Workflow Definition.




In the closed issue introduction, the terms:
step status codes, status step description, are used.
In Volume 3 the term step code and step description are used. This is better as the
code speaks to the overall step. No status fro the step should be defined. A step
when recorded in an XDW document exists. No other status are relevant to XDW.
In the closed issue section, an editorial improvement could reference the workflow
decription:
"This reflect the reality that in a multi-organizational environment future steps are an
“expectation” shared by one professional with others that will rely upon their
medical judgment and the latest information to perform or not such expected
activities”.


In the closed issue section point 4 is not correctly stated,: 4. This profile specifies
no rules for controlling changes of status.


The official term for IHE specified workflow definitions is propsoed to be: "These
will be called XDW-Based Content Profiles.".
This statement should be more specific: "Such workflow definitions are simply
referenced by a unique identifier."

The concept of workflow definition driving teh future states of an XDW managed
workflow need to be better highlighted. It is also proposed to add to XDW a sample
template for a workflow definition that would be used as a foundation for workflow
profile specifications.




It is not clear what the need is to reference: "in PCC TF-2: 4.1." A number of
statement do not apply, some do, several are missing.
The section referenced for the profile options (X.2) in the Table X.2-1 XDW -
Actors and Options and the options defined in the section: X.2.2 XDW Content
Profile Options are inconsitent. The earlier ones reference ITI TF-1: X.2.2.1 and
the later reference:
X.2.2.1 View Option
  See PCC TF-1:3.4.1.1
  See PCC TF-2:3.1.1
X.2.2.2 Document Import Option
  See PCC TF-1:3.4.1.2
  See PCC TF-2:3.1.2
The explanation of the role of the XDW document should be broaden in the
following section:
"This document is used to track the steps of the workflow which is followed, to
manage the documents related to a clinical workflow and its changes as it evolves
step after step. The Content Creator shall be able to create XDW Workflow
Document as 355 specified in ITI TF-3:5.3." Note there does not seem to be a
section 5.3 in Volume 3 of ITI TF.



The definition of input and output documents should be clarified and extended to
include parent and chilmd workflow documents.
"• The Inputs contains information needed to access documents used in performing
this step. For example, this could contain a reference to a referral request.
• The Outputs contains information needed to access documents output as a result of
370 performing this step. For example, this could contain a reference to a report
written by a specialist."




Note there does not seem to be a section 5.3 in Volume 3 of ITI TF.
Need to better explain the deprecation process of prior Workflow documents.




Need to put document as plural.
The example figure in the referral use case should be extended (or a new figure
added) to explain in the example the parts which are related to the the workflow
definition and those that are supported by XDW;




In the use cse described by section: XX.1 Use Case e-Prescription Workflow,there a
a number of minor incorrect statments:
Line 512- The use case analyzed is not focused on the workflow of a single
document, the e-Prescription document. It contains other documents.
Line 541- The type of references listed are not all inputs "a section of “inputs”
where the author puts a set of information useful to understand the reason for the e-
Precription (the references of the report of the visit, the references of reports of
exams, etc.)," The report of the visit seems to be rather an output document, rather
than not an input document.
Line 557: In the step: "He checks in which step the e-Prescription is (using the
Workflow Document) and he may checks the potential interactions of the active
substances prescribed." one need to discuss avoiding the double dispensation, as the
issue is mentionned in the introduction.
Line 566: Why would the pharmacist requery for the workflow and the advice
document he just produced: "When the pharmacist dispenses the items, he queries
and retrieves the Workflow Document, the e-Prescription Document and the
Pharmaceutical Advice Document of interest and if all the information are correct he
In the section XX.2 Use Case e-Referral Workflow several error have ben
identified:
Line 610-- The definition is not clear as it is not the workflow for the way a
specialist works but of the way a physician refers a patient to a specialist. "The use
case is focused on the workflow of a specialist exam (e-Referral)."
Line 611: I suggest removing the following text with little value: "This use case, in
the 610 same modality of the previous, approaches the problem of tracking the
different steps which characterize the availability and usability of the electronic
prescription. The problems are the same described in the previous use-case (how
manage the tracking of the steps of the workflow). The different from the previous is
that the e-Referral follow all workflow of the exam prescribed in object and in the
workflow are involved more actors and more systems."
Line 628-- The specialist practices in a hospital, but this not the case in many
environment. the text should be generalized: "After a few days the patient is
admitted at the hospital, the HCP consults the e-Referral and the process for the visit
starts."
Line 649-- Avoid using the term prescription in : "GP’s prescription placer software
produce two objects:"
In the section XX.2 Use Case e-Referral Workflow several error have ben
identified:
Line 650: It is not coorect to use the folder mechanism to reference documents from
an XDW object: "this two objects are referenced using the XDS Folder mechanism".
Replace by:
this two objects are referenced by their document Id and it has been decided by this
affinity domain to place both in the same XDS folder."
Line 654: Again wording misleading. Replace: "The Content Creator provides a
document folder to group all document produced and related at the same workflow
document" by: "The Content Creator creates a document folder to place the
workflow document and choose the option to place in the same folder all document
produced and related to the same workflow document
Line 660: The use of the healthcared need to be mentionned as an example of
patient identification. Replcae: "The HCP asks for patient health card in order to
retrieve both the documents containing the ordered exams and the associated
workflow document." by: "The HCP asks for the patient identity (e.g. using his
health card) in order to access the workflow document. and the referenced
documents dexcribing the specific ordered exams."
Line 665: The concept of the workflow passing from a state to another may be
confusing as many healthcare workflow do not have specific status (or the status is
defined by the verious step that have been performed). Replace:"Once he has
booked the visit, he replaces the workflow document with an updated one including
all the information of the previous Workflow Document and a new workflow step
In the section XX.2 Use Case e-Referral Workflow several error have ben
identified:
Line 669: Write in term of steps for the workflow, not in term of statuses. replace:
"When the patient is admitted at the hospital, the HCP consults the e-Referral
document and the Workflow Document associated and checks if the e-Referral is
still in the step 670 placed and it has been booked by the same health care provider."
by "When the patient is admitted at the hospital (assuming the specialist practices
within a hospital), the HCP consults the e-Referral document and the Workflow
Document associated and checks if the prior steps in the e-Referral contains the
"placing order" step and the "booking visit" steps. placed and it has been booked by
the same health care provider.
Line 674: Write in term of steps for the workflow, not in term of statuses. replace:
"If the e-Referral’s step is correct and the exam can take place, the HCP replaces the
Workflow Document with the updated one which contains all the information of the
previous one and a new task to describe the current step. At this step the e-Referral
passes from the step scheduled to the step in-progress and the exam can take place."
by: "If the necessary prior e-Referral’s step have taken place, the exam can take
place. The HCP replaces the Workflow Document with the updated one which
In the section XX.2 Use Case e-Referral Workflow several error have ben
identified:
Line 691: replace throw by trhough in: "It is also possible to manage a system of
subscription and notification to communicate the progress between the different
steps through the use of the Document Metadata Subscription (DSUB) profile or the
Notification of Document Availability (NAV) profile."
In the section XX.3 Use Case Tele-counseling Service for Neurosurgery Workflow
several error have ben identified:
- Need editing to avoid using the concept of status and instead speak of steps.
- The follow-up seems to be identical to the frist tele-consulting session. It make the
example too complex and does not add any value. It seems to be simply a repeat.
- This example does not highlight significant distinct features than the referral one
just before.


In the Section: XX.4 Healthcare professional Monitoring Workflow several errors
have been identified:
- Line 848; same comment as comment made on Line 654 (use of Folder)
- The overall english flow needs editing
nitially was apparently changed format

            Proposal                                                                                              Priority

            Replace with updated text:                                                                            M
            "The Cross-Enterprise Document Workflow (XDW) profile enables participants in a multi-
            organizational environment to track the steps related to patient-centric workflows as they
            systems hosting workflow management applications coordinate their activities of the health
            professional they support. ItXDW builds upon the sharing of health documents provided by other
            IHE profiles such as XDS, adding the means to associate documents for conveying clinical facts to a
            patient-specific workflow. XDW provides a common interoperability infrastructure upon which a
            wide range a specific workflow “content” may be defined. It is designed to support the complexity
            of health services delivery with much flexibility to adapt as workflows evolve.

            This profile defines a shared workflow tracking data structure, called a “workflow document” that
            records past steps of a workflow and maintains the references to health information input and
            output associated with each step. Such shared workflow state information allows the various
            participating systems to be aware of the history (past steps) of any of the workflows known for a
            patient, access the workflow current state and remain coordinated by updating this shared
            document with the new steps they have performed according to a referenced workflow
            definition."




            It is proposed to add after line 144 the following picture:                                           H




            Replace bullet by:                                                                                    M
            "Facilitates the integration of multi-organizational workflows with the variety of
            existing organization workflow management systems. It does so, not by adding a
            centralized workflow management system, but by offering peer-to-peer ( or federated)
            workflow synchronization beetwen the participating workflow management systems in
            the point of care systems."
Replace bullet by:                                                              M
"Leave the driving of the workflow to the health professional, and its system
as a worklfow participant within the definition of the workflow refenced at the
time of workflow initiation. Future steps are not managed in constrained by
XDW, but left to the business layer above XDW where requests or
expectations are considered integral to the outcome of previous steps (care
plans, requests, etc.)."
Remove any reference to Transform and append in CDA Header of XDW              H
document.
Decide if Replace (RPLC) need to be used or not (do not leave optional). There
does not seem to be solid arguments to manage RPLC, as XDW documents are
unlikely to be stored in local applications data stores.



There are two partially documented mechanisms that are mentionned in the H
Public Document:
1 - Use the intra document CDA Replace (RPLC) versioning. The document
SetId could be workflow instance unique Id. However, it is not queryable as
absent from the XDS Document Entry. The specification is not clear if the
Document set Id should be the same as the folder Id.
2 - A Folder shall be used and the folder Unique Id used for globally identifying
the overall workflow instance. All XDW WF documents, from the first one
throughout all the replacement XDW WF documents would be placed in the
same folder. The use of folder has the weakness that creating of XDW
documents across multiple federated XDS affinity Domains with XCA is not
curently supported.
One should note that introducing a new "Workflow Instance Id" and track it as
the Document Set Id, so that it is availble in every replaced instance as the
workflow steps unfold and adding it to an existing XDS Metadata attribute,
such as the event code list would not offer the support of a "race condition
resolution" between concurent attempts to repalce the same XDW document.
It is therefore proposed to:
1 - Support the use of folders to identify the group of previous and current
workflow documents related to a single workflow instance.
2 - Require the use of the DocumentSet ID within the CDA document header,
so that any document consumer having only performed a simple query and
retrieve of an active workflow document (without performing folder related
queries) has access to the folder ID or workflow instance Id. It is important to
not that this is not required to replace the WF document as by XDS, an XDS
registry shall place a replaced document in the same folder (this needs to be
explained in the public comment version).
The design choices of XDW should anticipate XCA support as much as possible. H
It is clear that, based on these comments, and the open issue on solution to
support the back link from any document to any referencing XDW objects,
there is only one extension needed. It is to ensure that the affinity domain in
which an XDW Document has been created (and its containing folder) shall
exist within a single affinity domain (race condition and identification of the
overall workflow through folder Id). Therefore the Home Community Id where
a workflow document resides shall be tracked as an attribute of the workflow
document, so that a federated use of "XDR" may ensure that any replacing
document is placed within the initially created folder without requiring a
complex discovery process.




As this example is not intended to specify the most generic ePrecription       M
workflow, it is recommended to simplify the example, and have the
pharmacist perform the validation at the same time as the medication is
dispensed. The step 11 query should be removed and the advice and
dispensation steps should be combined.




It is proposed to specify in XDW Volume 1 and Volume 3 a "predefined"           H
workflow step with a code "workflow locked", the expiration date and time
being placed in the end service time of the XDW object. This expiration
date/time for the lock is informative", as care emergencies may require
overriding this expiration time. If a specific workflow definition needs to add
any supplemental information a document may be referenced in the
workflow step output. This will allow workflow mgt application to include the
locking support across any workflow.
In addition, there should be a new section added in volume 3 to describe the
handling of a race condition between two document content creators/sources
that perfrom a replace operation on a WF document, and the provider and
register transation replace operation fails as the replaced document is
deprecated. In this case the XDW document creator shall be required to
repeat the WF document replacement, by first identifying the current
workflow document, and performing a new replace operation.
An XDW profile defined code and display name are required. "XDW Workflow M
Context Folder" is fine as "codeListDisplayName". A code value need to be
assigned by IHE ITI for "CodeList".




Replace:                                                                  M
"The process for updating the document is:
 • Open the existing workflow document
   o Add or update workflow steps
   o Re-register (update) the workflow document by performing a document
replace"
By:
The process for updating the document is:
 • Open the existing workflow document
   o Copy all previous workflow steps without any changes
 • Create a new workflow document
   o Insert all previous workflow steps without any changes
   o Add one or more new workflow steps
 • Re-register the new workflow document by performing a document replace

Replace by: 5.Y.5.3 Add a workflow step with an associated clinical document M
Whenever a worflow advances, a new Workflow Document with an additional
step is created and added to the same Workflow Context Folder. If there are
clinical documents related to this new step, the Content Creator records the
references to these documents inside the input and/or output sections of the
new step.


Replace 5.Y.5.4 by:                                                               M
5.Y.5.4 Get a clinical document associated to a workflow
Any Workflow Document contains details of each step that have been
performed for the specific workflow definition to which the workflow
document is related. The step includes the references to zero or more input
or output documents as the DocumentEntry.uniqueId of all the referenced
clinical documents. As a result, a single stored query is sufficient to get all
references to the clinical documents. With these references the documents
may be directly retrieved.

 The metadata for each of the referenced documents should be added to the
input or output reference section in the XDW document specification to avoid
the need to perform as many queries as there are referenced documents. We
suggest thes e be added.
It is strongly suggested to rely on the "referal use case" to introduce in volume H
3 a sample WF document including the content of the WF document at the
end fo the referal (two steps).
The XDW profile should contain a sufficiently detailed example of workflow
definition to enable multi-party Connectathon testing.
It is proposed in the introduction to XDW to add the following, just before          H
section X.1:




XDW coordinates execution of various workflow definitions

A Worflow definition is required in order to manage a specific set of tasks. It is
specified by IHE in what is called a Workflow Definition Profile.
A Worflow Definition includes the set of possible steps that may occure within
the workflow and for each possible step it specifies the relationships between
possible previous steps and possible subsequent steps, the required or
optional types of document content that may be reference as input or output
to the step. A generic template for a workflow definition is provided in
appendix XX.


The XDW Document illustration shows how an XDW Document containing a                 M
Workflow Definition is exchanged between "edge" applications using
Document Sharing infrastructure.




Replace the words "step status code" and "step status description" by "step          M
code" and "step description".
Replace by: "This reflect the reality that in a multi-organizational environment M
future steps are an “expectation” shared by one professional with others that
will rely upon their medical judgment and the latest information to perform or
not such expected activities within the constraints of the workflow
description”.



Replace point 4 by:                                                                  M
"4. This profile specifies no rules for controlling the succession of steps except
through the reference to a workflow definition as specified by the workflow
document typecode and description."
It is proposed to make it more simply : "These profiles built upon XDW will be       M
called Workflow Profiles."
It is proposed to make this statement more specific: "Such workflow                  H
definitions are simply referenced by a unique identifier, which is used as the
Workflow Document Type Code and Meaning."
Suggest replacing:                                                                   H
"This profile defines the content of a workflow document that records past
steps of a workflow and maintains the references to health information input
and output associated with each step. Such shared workflow state information
allows the various participating systems to be aware of the history (past steps)
of any of the workflows known for a patient, access the workflow current
state and remain coordinated by updating this shared document with the new
steps they have performed."
By:
"This profile defines the content of a workflow document that records past
steps of a workflow and maintains the references to health information input
and output associated with each step. Such shared workflow state information
allows the various participating systems to be aware of the history (past steps)
of any of the workflows known for a patient, access the workflow current
state and remain coordinated by updating this shared document with the new
steps they have performed according to the futures steps as constrained by
the workflow definition (see Appendix YYY for a template definition)."



IHE ITI should consult with PCC on this matter.                                      M

These need to be reconciled                                                          M
Replace by:                                                                      M
"This document is used to manage all context information about a workflow.
It references the specific workflow definition that constraints the participants
of the workflow. It also tracks the steps of the workflow which is followed,
manage the documents related to each step of the clinical workflow and its
changes as it evolves step after step. The Content Creator shall be able to
create XDW Workflow Document as specified in ITI TF-3:5.3 (?)"



Replace by:                                                                    H
"• The Inputs contains step-specific information to be recorded and shared for
future workflow participants that need to know what information was
relevant for performing the step. In particular it will contain references to
documents used in performing this step. For example, this could contain a
reference to a referral request. It may also contain references to "parent"
workflows to which this workflow is a "child".
• The Outputs contains step-specific information to be recorded and shared
for future workflow participants that need to know what information was
produced as a result of performing this step. In particular it will contain
references to resulting documents. For example, this could contain a reference
to a report written by a specialist. It may also contain references to "child"
workflows initiated by this workflow as a parent. "



                                                                               M
Replace by:                                                                     M
At any time, if a participant chooses to advance the workflow for a specific
patient, it shall create one (or more) new step by adding this step to the most
recent instance of the workflow document. This new version of the workflow
document is then published as a replacement. The prior version being
replaced is then placed in a deprecated status so that only the most
cuurenty workflow document is active. The technical description of the
updating of the workflow document is specified in ITI TF-3:5.y.

Add an s to the last word of this section.                                      L
"If all participants in a workflow are part of the same XDS Affinity Domain, by
requiring that all documents referenced within a specific Workflow Document
be placed within the folder that contains the Workflow Documents."
                                                H




Correct text starting at the following lines:   M
Line 512; Line 541; Line 557; Line 566;




                                                M
M




M




M
M




M

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:4
posted:10/18/2011
language:English
pages:30