Basics Of Doing Document Sharing Inquiry Right

IHE is currently working on a "Handbook" intended to learn an XDS Affinity Domain, or Community (XCA), or MHD community on how t...

IHE is currently working on a "Handbook" intended to learn an XDS Affinity Domain, or Community (XCA), or MHD community on how to construction their Document Sharing (XDS, XCA, MHD) Query

As purpose of the metadata handbook discussion, Charles has clarified inward a really elegant way a "Best Practice" for leveraging the XDS/XCA/MHD Query, vs local processing of the resulting document entry/reference Metadata, to arrive at the best results. This "Best Practice" should survive used, but I know it is non used. The principal argue it is non used is because it was never explained to the IHE readership.

XDS Query

The XDS Query transaction has a huge issue of stored queries. Realistically at that spot is exclusively ONE stored inquiry that is needed: FindDocuments

The other stored queries are non useless, but are far to a greater extent than special purpose.  They are to a greater extent than focused on SubmissionSets, Folders, as well as Associations. These are useful, exactly non really primary for a full general purpose Document Consumer.  These are genuinely essential when i gets into use-cases that require these other capabilities.

Degenerate Query

The fact that FindDocuments is as well as thence dominant is exposed to a greater extent than strongly inward that some servers exclusively implement FindDocuments, as well as don't don't back upward whatever of the other queries.  This is particularly truthful of XCA (cross-community) which agency they don't fifty-fifty back upward SubmissionSet, Folders, or Associations. This is also truthful of the Argonaut specification, where SubmissionSets, Folders, as well as Associations are non supported.

XDS FindDocuments Query Parameters

The FindDocuments query has eighteen inquiry parameters. You exclusively ask v of them. The other thirteen parameters are possible to use, but to a greater extent than probable to consequence inward wretched results. They are at that spot to assure that FindDocuments is complete, but the work of these additional parameters is really fragile. Fragile inward that the consuming arrangement must survive inward genuinely skilful synchronization amongst the publication system, as well as that is exactly unlikely longitudinally over decades. Later I explicate how to bargain amongst this fragility.

1. PatientId -- this is required inward XDS, but I volition call it exactly for completeness. You must accept a Patient ID you lot are interested in. Use of PIX, PDQ, XCPD, or another Patient Identity Management arrangement is a required prerequisite. 
2. ClassCode -- this is the most poorly understood metadata element, nonetheless it was intended to survive the most powerful. The sentiment is a major focus of the novel IHE "Handbook", where nosotros explicate that a pocket-size issue of vocabulary damage should survive allowed, that grouping documents into logical 'classifications'. Where these classifications are useful to a Document Consumer. That is they should survive designed (vocabulary pattern -- value set) such that for whatever use-case where person is looking for documents they tin flame alternative i or 2 damage from this valueset that are most probable to provide results.
3. ServiceStartTimeFrom -- ServiceStopTimeTo -- these function together to give a menstruum of fourth dimension inside which the documents were about. This is different than the creation time, which is when was the document created. The service times are to a greater extent than specific to the fourth dimension arrive at of the treatment. So for an episode summary, it would accept the fourth dimension arrive at of the episode. Important to banking concern complaint that these 2 parameters function together to give a menstruum of time, as well as that menstruum of fourth dimension tin flame non accept a start (beginning of time), or non accept an terminate (end of time). Thus i tin flame inquire for documents roofing handling prior to 1998. Another illustration is exclusively documents roofing the concluding half-dozen months past times specifying a StartTimeFrom as well as leaving opened upward the halt time.
4. PracticeSettingCode -- this is the clinical speciality where the human activeness that resulted inward the document was performed. Like the classCode, this should accept been filled amongst a controlled valueSet of pre-negotiated vocabulary that represents wide classifications of exercise settings. 

Classification ValueSets are critical

What the to a higher house shows is that 2 of the critical FindDocuments inquiry parameters should come upward from good controlled value sets. Value sets that accept a few (10-20) vocabulary values that stand upward for wide classifications. 

These codes ask to survive useful, but useful to person doing a Query. Too ofttimes these codes are considered when a Document Entry is existence published. Yes they ask to survive filled out when the Document Entry is published, but they ask to survive useful for Query. 

So, how does a community create upward one's heed what these valuesets should contain? THAT is the whole purpose of the novel IHE metadata "handbook"... I too, await this educate of principles, process, as well as mechanism.

Query is non enough

The whole purpose of the XDS Metadata is to enable processing of the documents as well as thence that the correct information tin flame survive found. The 4 inquiry parameters are necessary, but non sufficient.

Critical inward the "Best Practice" that Charles explained is that a Document Consumer must survive create to some cast of local processing. This local processing would leverage ALL of the metadata. This local processing powerfulness farther eliminate unnecessary entries, powerfulness form the results, powerfulness lay emphasis on some entries because of specific metadata entries. This local processing powerfulness survive automated algorithm, or powerfulness 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 amongst Patient ==> Notifications When Patient Has Encounter Elsewhere
• HIE from Providers & Payers Working Separately ==> Shared Responsibility for Managing Care
• HIE from Enterprise cast 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 inward XDS
• IHE #FHIR profiles - MHD, PDQm, as well as PIXm
• MHD - Why work of FHIR Contained?
• IHE FormatCodes are mandatory 
• In Wisconsin nosotros accept Interoperability 
• What is MHD beyond XDS-on-FHIR? 
• Health Information Exchange: Centralized, Federated, or Distributed
• Define Atom -- Too many definitions inward work today 
• Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
• Distinction betwixt Documents as well as Messages
• Understanding XDS metadata - IHE re-documentation effort
• XDS Notifications
• HIE Patient Identity problem
• Healthcare Metadata 
• Minimal Metadata
• What is the create goodness of an HIE
• Karen's Cross or exactly Minimal Metadata
• HIE using IHE
• Texas HIE Consent Management System Design
• The French Health Information Systems Interoperability Framework -- Now available inward English
• One Metadata Model - Many Deployment Architectures
• Critical aspects of Documents vs Messages or Elements
• Using both Document Encryption as well as Document Signature
• Document Encryption
• XDS/XCA testing of Vocabulary Enforcement
• Where inward the World is CDA as well as XDS?
• Universal Health ID -- Enable Privacy
• HIE/HIO Governance, Policies, as well as Consents
• IHE - Privacy as well as Security Profiles - Document Encryption