XDW & folders: a topic for June 6 XDW discussion

[lynn felhofer (gmail)]

The following note is background information for Wednesday's discussion on XDW lessons learned from Bern.  Webex details are included in a separate email.

Begin forwarded message:

From: Mark Sinke <mark....@forcare.nl>

Date: May 30, 2012 4:35:51 AM CDT

To: "Mauro Zanardini (mzana...@consorzioarsenal.it)" <mzana...@consorzioarsenal.it>, Arianna Cocchiglia <acocc...@consorzioarsenal.it>, "Lynn Felhofer (felh...@charter.net)" <felh...@charter.net>

Cc: Andries Hamster <andries...@forcare.nl>, Walco van Loon <Walco....@forcare.nl>, EU Connecthaton 2012 <eu2...@forcare.nl>

Subject: Observations and discussion around the folder in the XDW profile

Hi Mauro, Arianna, Lynn,

 

At the tail end of the Bern connectathon we discussed the use of the folder in XDW. Since we failed to discuss all together, I spoke with Mauro/Arianna and Lynn in two separate conversations. I’d like to take the opportunity to write down our discussion and my position  around the usage of the XDW profile, and in particular the use of the folder in the profile.

 

As discussed with Lynn, it would be good to schedule a “what we learned from XDW in Bern” t-con somewhere next week to dump and discuss our ideas while the memories are still fresh.

 

Note that I also forwarded a mail from Andries to Mauro that we unfortunately did not get around to discussing. I will send the same mail separately to Lynn and Arianna, to get on the same page. We may want to tackle that topic too, in the same call.

 

Now, on to the matter at hand.

 

The XDW profile mandates the use of a folder to group the documents in a particular workflow together. During the discussion with Mauro and Arianna, the folder surfaced as a primary way to identify a workflow, and as a practical measure to help out with the use case where two different want to update the same workflow state at the same time. The consumer that tries to update a workflow that is updated gets an error message (“cannot replace a deprecated document”), queries the workflow folder content, and retries with the then fresh workflow document content, as the folder contains a new, Approved, workflow document to work with.

 

Let us take a step back first. XDW is built on XDS, and it relies on the XDS replace (RPLC) semantics for advancing steps in the workflow. What it means is that when a workflow is updated, the source that wants to update the workflow sends a new version, with a RPLC relation to the previous document. That relation is (a) an indication to the registry to deprecate the previous workflow document and (b) a permanent record of that action. Item (b) is of particular interest, because it means that a sequence of workflow updates is represented in the registry as a sequence of RPLC associations and documents, like this

 

Doc rev1 (Deprecated) <- RPLC assoc (source: rev2, target: rev1) <- Doc rev2 (Deprecated) <- RPLC assoc (source: rev3, target: rev2) <- Doc rev3 (Approved)

 

This means that if an XDW content updater has a workflow document (i.e., the current state of the workflow), it can update it by adding a new association (source: rev4, target: rev3) and document (Doc rev4) to the tail end of the chain depicted above. If that fails, because someone has intervened and updated the document (say, by Doc rev3a), the state in the registry is as follows:

 

Doc rev1 (Deprecated) <- RPLC assoc (source: rev2, target: rev1) <- Doc rev2 (Deprecated) <- RPLC assoc (source: rev3, target: rev2) <- Doc rev3 (Deprecated)* <-  RPLC assoc (source: rev3a, target: rev3)  <- Doc rev3a (Approved)

 

The update fails because it is illegal to  RPLC a Deprecated document (in this case, rev3, marked with *). In this case, a GetRelatedDocumentsQuery with the UUID of Doc rev3 is sufficient to get the rev3a document. The client may then perform the necessary update logic and resubmit the update, this time with a RPLC association (source: rev4, target: rev3a), which will succeed, as Doc rev3a is still Approved. The final state will be

 

Doc rev1 (Deprecated) <- RPLC assoc (source: rev2, target: rev1) <- Doc rev2 (Deprecated) <- RPLC assoc (source: rev3, target: rev2) <- Doc rev3 (Deprecated) <-  RPLC assoc (source: rev3a, target: rev3)  <- Doc rev3a (Deprecated) <- RPLC assoc (source: rev4, target: rev3a)  <- Doc rev4 (Approved)

 

Note that this way of solving an update problem is something that happens outside XDW as well. For example, in XDS-I, when imaging study content is changed, the Imaging Document Source will create a new study manifest (also known as a KOS object) and submit it to replace a previous one. Consumers relying on the previous version have to traverse the RPLC association through queries like GetRelatedDocuments to arrive at the new instance of the study manifest (KOS).

 

Futher note that the resolution is just one way of doing it. Another way, which might be more logical for a UI that directly faces the user, is to requery the open workflows for a patient (based on patientId, workflow document class code and event code), select the right one manually, and retry the operation manually. In that case a straightforward FindDocumentsQuery is sufficient.

 

The 3^rd alternative, now possible in the XDW profile, is to query the folder contents and  look for the single Approved workflow document, as that must be the latest one. This latter option is the one that apparently surfaced during some XDW t-cons/face-to-face that I unfortunately had to skip.

 

What I tried to show is, that it is possible in various ways to connect old and new versions of the workflow document, some relying on generic XDS capabilities and one specifically on the folder. I would argue that for this particular problem the folder is not necessary. It should not be a requirement on any of consumer actors to use it as the only means to get to a new version of a workflow document – in fact, I would argue that, from a software design perspective, the more generic XDS mechanism is probably “better” as it is suited to more than just XDW.

 

However, where I do see value in the folder, is that it represents the full context of a workflow on the XDS metadata level. If, beyond the versions of the workflow document,  all documents related to the workflow (i.e., those documents referenced as inputs or outputs of tasks in the workflow), as mandatorily put in the folder, that makes it possible to present a view of a particular workflow, based on just XDS metadata – no need to directly dive into the document content for a simple display of all open workflows and their related referrals or resulting reports.

 

It also makes it possible to identify any and all documents in the workflow for automated processing, without pulling the workflow document first. I’m not sure if the benefit to software design is large is such cases, as it is trivial to find out if the workflow has been replaced by a new version and whether it might need attention; in such cases, I’d expect the automated agent to download the workflow document anyway for deeper investigation. As this is an automated process, the time spent downloading these documents is probably acceptable.

 

It should be observed that even for the purpose of a work list display, the folder is superfluous. However, if the folder requirement is removed, a consumer needs to open one workflow document per workflow displayed to arrive at the same functional display of input and output documents. Further note that with the folder, the work list display only goes as far as the XDS metadata related to both the workflow document and the associated documents carries any semantically relevant information. It would be a very coarse-grained display, but it avoids a round-trip per open workflow displayed. As a user is waiting for the response, this may be significant.

 

So my conclusion would be that the folder in XDW is valuable, but for related document display, not for status update conflict resolution.

 

To make folders effectively usable, we need to make sure that (a) folders are consistently filled with the workflow document versions and *all* related documents referenced in the workflow document and (b) there is no mandatory usage of the folder for XDW actors that consume a workflow document. This gives flexibility on the consumer to operate efficiently based on the client’s software design, and forces the sources to support some designs that are not possible without a folder. As a special case, the XDW updater is both a source and consumer; its consumer side has no mandatory requirements, but the source needs to update the folder when necessary.

Regards, and thanks for a wonderful connectathon,

 

Mark Sinke

 

PS I performed another scan of the XDW profile as it stands today (i.e., the TI version dated 2011-10-03), and I came to the understanding that putting all related information for a workflow in a folder may not be possible in an XCA context (it is not possible to refer to a document in another community from within a folder). However, the same holds for the RPLC relation between successive versions of a document. We may need to discuss that fact whether that effectively renders the XCA extension of XDW unusable. If so, we need to fix it ;-).

 

Mark Sinke – CTO – Forcare BV

http://www.forcare.nl

mailto:mark....@forcare.nl

Tel: +31 30 699 1930

Mob: +31 646 255 635

 

[Mark Sinke]

Hi all,

 

Find below some comments from my colleague Andries Hamster on the use of the folder in XDW and what I said about it in the previous mail that Lynn forwarded.

 

Regards,

 

Mark.

 

From: Andries Hamster
Sent: Wednesday, May 30, 2012 20:59
To: Mark Sinke
Subject: Re: Observations and discussion around the folder in the XDW profile

 

Mark,

 

My notes in english as you may want to share them.

 

I do not agree with your closing remark that it is important to put all workkflow and related documents in the same same folder. Say that a XDW document references an older, previously registered, document as input. Why in that case would it be important to add this document to the same XDSFolder as the XDW documents? This would require the XDW doc creator to associate a document published by potentially another source to an XDSFolder it created to associate the XDW document with. This may be technically possible and potentially an advantage. I fail to see the clinical relevance though.

 

Also your statements about XDSFolder making it easier to create a work list It unclear to me. Since both the XDsFolder metadate as well as the XDW document meta date does not containt enough relevant information from a clinical user perspective it probabaly always will be required to analyse the XDS document content to create a work list entry that makes sense to a user.

 

I only see a technical benefit in using the folder concept in that it makes it easier for a consumer to find all XDW document associated to the same clinical process.

Andries Hamster