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 QueryThe 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 QueryThe 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 ParametersThe 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.
- 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.
- 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.
- 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.
- 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
Query is not enoughThe 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)
- HIE Future is Bright - stepping into 2018
- HIE from Manual ==> Automated
- HIE from Provider-Centered ==> Patient-Centered
- HIE from Multiple Point-to-Point Connections ==> Single Connection to Hub
- HIE from Updated @ Next Encounter with Patient ==> Notifications When Patient Has Encounter Elsewhere
- HIE from Providers & Payers Working Separately ==> Shared Responsibility for Managing Care
- HIE from Enterprise class API ==> FHIR API to Document Sharing
- Future of HIE is bright
- FormatCode granularity
- Granularity of FormatCode
- Multiple formats of the same Document content
- FHIR documents in XDS
- IHE #FHIR profiles - MHD, PDQm, and PIXm
- MHD - Why use of FHIR Contained?
- IHE FormatCodes are mandatory
- In Wisconsin we have Interoperability
- What is MHD beyond XDS-on-FHIR?
- Health Information Exchange: Centralized, Federated, or Distributed
- Define Atom -- Too many definitions in use today
- Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
- Distinction between Documents and Messages
- Understanding XDS metadata - IHE re-documentation effort
- XDS Notifications
- HIE Patient Identity problem
- Healthcare Metadata
- Minimal Metadata
- What is the benefit of an HIE
- Karen's Cross or just Minimal Metadata
- HIE using IHE
- Texas HIE Consent Management System Design
- The French Health Information Systems Interoperability Framework -- Now available in English
- One Metadata Model - Many Deployment Architectures
- Critical aspects of Documents vs Messages or Elements
- Using both Document Encryption and Document Signature
- Document Encryption
- XDS/XCA testing of Vocabulary Enforcement
- Where in the World is CDA and XDS?
- Universal Health ID -- Enable Privacy
- HIE/HIO Governance, Policies, and Consents
- IHE - Privacy and Security Profiles - Document Encryption