Wednesday, April 4, 2018

Basics of doing Document Sharing Query right

IHE is currently working on a "Handbook" intended to instruct an XDS Affinity Domain, or Community (XCA), or MHD community on how to structure their requirements on metadata. This effort is long overdue, as IHE has relied on the communities to figure this out themselves. More communities have failed than have succeeded. I am just very grateful that they keep trying. Mostly they keep trying because the most basic query is just asking for all documents available for a given Patient. This is necessary, but not sufficient. Let me explain the next level of Document Sharing (XDS, XCA, MHD) Query

As part of the metadata handbook discussion, Charles has clarified in a very elegant way a "Best Practice" for leveraging the XDS/XCA/MHD Query, vs local processing of the resulting document entry/reference Metadata, to achieve the best results. This "Best Practice" should be used, but I know it is not used. The main reason it is not used is because it was never explained to the IHE readership.

XDS Query

The XDS Query transaction has a huge number of stored queries. Realistically there is only ONE stored query that is needed: FindDocuments

The other stored queries are not useless, but are far more special purpose.  They are more focused on SubmissionSets, Folders, and Associations. These are useful, just not very primary for a general purpose Document Consumer.  These are actually essential when one gets into use-cases that require these other capabilities.

Degenerate Query

The fact that FindDocuments is so dominant is exposed more strongly in that some servers only implement FindDocuments, and don't don't support any of the other queries.  This is especially true of XCA (cross-community) which means they don't even support SubmissionSet, Folders, or Associations. This is also true of the Argonaut specification, where SubmissionSets, Folders, and Associations are not supported.

XDS FindDocuments Query Parameters

The FindDocuments query has 18 query parameters. You only need 5 of them. The other 13 parameters are possible to use, but more likely to result in poor results. They are there to assure that FindDocuments is complete, but the use of these additional parameters is very fragile. Fragile in that the consuming system must be in really good synchronization with the publication system, and that is simply unlikely longitudinally over decades. Later I explain how to deal with this fragility.

  1. PatientId -- this is required in XDS, but I will mention it just for completeness. You must have a Patient ID you are interested in. Use of PIX, PDQ, XCPD, or some other Patient Identity Management system is a required prerequisite. 
  2. ClassCode -- this is the most poorly understood metadata element, yet it was intended to be the most powerful. The idea is a major focus of the new IHE "Handbook", where we explain that a small number of vocabulary terms should be allowed, that group documents into logical 'classifications'. Where these classifications are useful to a Document Consumer. That is they should be designed (vocabulary design -- value set) such that for any use-case where someone is looking for documents they can pick one or two terms from this valueset that are most likely to return results.
  3. ServiceStartTimeFrom -- ServiceStopTimeTo -- these work together to give a period of time within which the documents were about. This is different than the creation time, which is when was the document created. The service times are more specific to the time range of the treatment. So for an episode summary, it would have the time range of the episode. Important to note that these two parameters work together to give a period of time, and that period of time can not have a start (beginning of time), or not have an end (end of time). Thus one can ask for documents covering treatment prior to 1998. Another example is only documents covering the last 6 months by specifying a StartTimeFrom and leaving open the stop time.
  4. PracticeSettingCode -- this is the clinical speciality where the act that resulted in the document was performed. Like the classCode, this should have been filled with a controlled valueSet of pre-negotiated vocabulary that represents broad classifications of practice settings. 

Classification ValueSets are critical

What the above shows is that two of the critical FindDocuments query parameters should come from well controlled value sets. Value sets that have a few (10-20) vocabulary values that represent broad classifications. 

These codes need to be useful, but useful to someone doing a Query. Too often these codes are considered when a Document Entry is being published. Yes they need to be filled out when the Document Entry is published, but they need to be useful for Query. 

So, how does a community determine what these valuesets should contain? THAT is the whole purpose of the new IHE metadata "handbook"... I too, await this set of principles, process, and mechanism.

Query is not enough

The whole purpose of the XDS Metadata is to enable processing of the documents so that the right information can be found. The four query parameters are necessary, but not sufficient.

Critical in the "Best Practice" that Charles explained is that a Document Consumer must be ready to some form of local processing. This local processing would leverage ALL of the metadata. This local processing might further eliminate unnecessary entries, might sort the results, might put emphasis on some entries because of specific metadata entries. This local processing might be automated algorithm, or might involve a human. Likely both.

More on Document Sharing Management (Health Information Exchange - HIE)

1 comment:

Subscribe to: Post Comments (Atom)