Comments

This is the place to leave comments on the XDS specifications. Please follow any comments by ~~~~ which will add your signature and a timestamp. Dave Harvey (talk) 07:56, 2 June 2014 (MDT)

Dave Barnet

Top level comments in this section were added by Dave Barnet (elsewhere, and moved here by Dave Harvey)

I'm not sure where these comments belong, but here seems as good a place as any (moved to comments by DH). I'd categorise these comments as "Using XDS for a national metadata". This is predominatley aroung using XDS with ITK. At present ITK's interest in metadata (generally) is around correspondence (discharge summaries, ED reports etc.).

Valid point - though looked at through the eyes of XDS, the ITK and FHIR metadata sets are remarkably similar (in both case being at least partially based on XDS) so I think that we can look at this generically, without getting too hung up on the technology.Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

I've been through the document produced by Dave Harvey "XDS Meta-Data UK2" - which I think is an attempt to define a core set of metadata for a national context?

correct Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

This does beg the fundamental question in all this for me - is cross enterprise data sharing only across a Trust (or group of Trusts), or across a national healthcare service? The answer I think has profound implications on what we recommend as a national metadata solution.

I see it as both - it is both guidance for those implementing locally, but with a "secondary benefit" that it would improve the prospects for clinically useful and safe national integration at some stage in the future! Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

The below imagines a CDA document being stored onto a document repository - for example a discharge summary being added to the repository (which is the only current use case in the ITK).

Running down the data items, here's my thoughts.

PatientID - I think nationally this has to be the NHS Number. I can't see any other option for inter-trust data sharing (as local trust patient numbers will be meaningless to Trusts outside their locality). Plus as only 1 identifier is allowed, it surely must be the national identifier. I'd also add that if no traced NHS number is available, the document would not be reliably retrievable (this in my view is a mandatory NHS Number)

SourcePatientID - The ITK CDA specs do allow for local identifiers. XDS allows 1 local identifier. SourcePatientID MUST have the assigning authority documented. It would be useful to agree the format of the assigning authority - all the examples I've seen have an OID (who assigns these OIDS?) - ITK uses the assigning authorty attribute with an ODS code and name - for example "assigningAuthorityName="V39XF:North Lane Clinic, Chatham""

Agreed - the question is whether the ODS code is specific enough - what about "merged" hospitals with separate historical overlapping numbering ranges (are there any?) Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

SourcePatientInfo - is the name, gender, address, telecom, DoB of the patient as held on the system from which the document is generated - no issues with this.

TypeCode - ITK and IHE say that this should be populated with one of the CorrespondenceDocumentType codes. These form part of the document code (ClinicalDocument\code@code). However, this format of document code isn't mandated in ITK specs. The DMSs currently have a definite choice of a single (post-cordinated) SNOMED code, a compositional SNOMED expression using CorrespondenceDocumentType & CorrespondenceCareSetting, and in the nonCoded spec, document code is loosened to CWE, so you can use any code. The issue here is that somewhere along the way the use of the compositional document code need to be firmly stated.

Nice to hear the ITK rules. That said, I would strongly recommend a single, simple code, not only for standards compliance, but also a care setting is also available elsewhere (and of course searchable). Keeping them separate makes searching much more flexible - you can search for one or the other, rather than trying to use hundreds of possible combinations.Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

classCode - IHE document suggests that this is difficult to define a usfule set of codes for this item. I agree. IHE document suggest that the current range of ITK specs would attract a value of "Clinical Document". The issue for me is that this value cannot be harvested from the document being processed (for storage), and the value comes from an external affinity domain. The issue with affinity domains a the broad concensus of agreement on the value list from all interested parties.

This is complicated by the XDS-I policy, which says that classCode would hold the equivalent of the "TypeCode" above, and that typeCode should hope the procedure code - this needs discussion! Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

Author - Only contentious bit as far as I can see is the Specialty. In the last meeting this was highlighted as important. The ITK document specs lean towards putting in a job role, or the SDS profile. The IHE document suggests using the NHS Data Dictionary set of specialty codes. This is reasonable in that there's already reporting according to these code (Commissioing data sets for example). However the clinical documents don't currently carry the specialty of the author (we'd need a change to the ITK specifications, creation of an OID, and a mandation to populate it)

In many cases, I would hope/expect that a document/metadata source would be able to populate this (given the identity of the author) from a local lookup - but perhaps I'm being optimistic! Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

Legal Authenticator - we rarely see this populated. The IHE document says this should be populated in the same way as author/person. However (& I may be wrong) - I think Legal Authenticator is defined as a slot, whereas author/person are classifications?

In XDS you are right, but this is merely a formatting question - the classification is used so that the individual items within the author (name, role, specialty and institution) can be individually exposed (as themselves, slots within the classification)Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

EventCodelist - IHE document says this is extremely flexible, and used to hold clinical acts. The definition of what populates this field need tightening up to be consistent scross care settings (I think its OK for specialties to use this in different ways, but within a specialty there should be consistent use). Currently the ITK metadata recommendation does not include this field. I think we need more discussion on this.

Agreed! Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

Healthcare Facility Type Code - IHE document says thiscould use the NHS Data Dictionary org type list. In ITK CDA specs, I think this comes from the CDACareSettingType SNOMED subset from the encompassing encounter. Where populated, this is defined as CNE, so should be a consistent set of values.

Practice Setting Code - The IHE document points to CorrespondenceCareSetting as a list of values (used as part of the compositional grammar statement for document code) - see TypeCode above for the issues.

Title - no issues

Comments - no issues

Confidentiality Code - I agree we need a simple set of codes for cross repository document searching.

Format Code - Currently in ITK, we say use the CDA messageType to populate this item. So this gives you "Ambulance Report", "Discharge Summary" etc. (quite a high level document type, not typically involving the detailed care setting). This idea falls down when using the nonCoded specification, as the messageType here says "NonCodedCDA" document (so some guidance / discusssion is needed).

Agreed that this is an area for discussion - there is lots of guidance/precedent here from the US/International IHE profiles, where easy "sub-profile" has paired CDA types with format codes. Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

Mime Type - no issues

Reference ID List - not sure how his would be used in the context of correspondence. ?

probably not used - it I a very "new" and optional addition, mainly for radiology to add study and/or accession numbers, but it COULD usefully be considered for things like encounter IDs to link documents within an encounter.Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

Limited MetaData - i think we need to define the "minimum metadata" before we can decide whether a document has Limited Metadata?

This is defined in the IHE profile.

---

Having written this, I have the feeling that a lot of what I've said & commented on is an "administrative" view of document retrieval. For example a clinician might want to find all the documents relating to Mrs. Miggins' Cardiac care since the year 2000. To do this we could search for documents from 2000 that have an author from a cardiac specialty (but we'd miss any emergency department reports that may be relevant). Maybe someone could explain to me how this sort of query would work?

Most of that would be an absolutely standard XDS FindDocuments query - using patient ID and ServiceStartTime as parameters. You are right that the speciality is a "grey" area - which has been much discussed. Your "author speciality" approach is the "standard" one, but as you say, as more general one providing a means to identify specialities to which documents are addressed or when there is a known other link to a speciality such as your A&E case (and a big thanks for that - this is not a use of speciality that I'd considered)Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

I also think we could do something around anatomy within the registry. For example, for reports that are body-part centric. When Great Ormand Street (GOSH) were implmenting XDS for radiology, they identified 12 regions of the body to classify reports (I think it was 12 - it may have been more or less). However, these 12 boidy parts are not going to me of much use to a specialist hospital such as moorfields eye hospital. (Whereas GOSH may have gone as far as classifying eyes as head structures, Moorfields would want to classify their documents according to the detailed structure of the eye). This make cross-repository querying seemingly difficult, as different organisations classify documents according to their local requirements.

Interesting idea! ONLY radiology (via XDS-I) defines body part usage at all at the moment - the question of whether and how to use for other specialities (and sub-specialities) is open! Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

However, i think that there are unifying ways forward on this. One answer could be to use a classification hierarchy (such as SNOMED), so a query of "left Cornea" would produce documents relating to left cornea, and a query of "left eye structure" would produce a document list of all left eye structure reports. The idea being that you could query for documents up a known (and common) hierarchy until you get the reports you're looking for. If all instantiations of the document registry implement the same hierarchy, you would get cross-repository querying.

This is an intriguing idea, but I'm not sure where you would propose that this happens. If at the consumer, then it makes perfect sense, and could easily (?) be implemented by a supplier as part of their "product differentiation" to give an enhanced user experience. I doubt that expecting such intelligence to go into the registry would be practically or politically possible. Dave Harvey (talk) 13:17, 13 June 2014 (UTC)

By Neelam Dugar

XDS Consumer Requirements

There are 2 aspects of the XDS Consumer--Metadata Display and Image/Document Display:

Metadata Display and Sorting when in patient context

When in a PATIENT context XDS consumers must be able to display the following metadata as columns which can SORTED or FILTERED.

1. Doc class
2. Doc type-For radiology--Image, Request, Report
3. NHS Specialty producing the document-(Practice Setting Code in XDS)
4. Author (name, job-role, specialty, institution)
5. Named Responsible Consultant/GP in NHS (Legal Authenticator in XDS)
6. Associated Specialties (will include the sending and receiving specialty, or other specialties for e.g MDTM Outcome) - part of Event Codes in XDS
7. Investigation Code Description--NICIP Code for radiology. OBR4--Universal Service ID--also part of Event Code in XDS
8. Modality (and Body parts) are part of XDS-I event codes
9. Date/Time of Doc creation

Image and Document(PDF/a) Display

1. Images and Documents must be displayed in 1 click from metadata
2. Images and doc displayed inherently within the XDS consumer--no extra software launching exercise
3. Documents displayed within 3-5sec. Images displayed within 5-10 secs (tested on workstations with adequate bandwidth)
4. Linked documents displayed "together"

Any comments on XDS Consumer Requirements:

I think that these "consumer" requirements are useful to show what metadata is needed, but aspects such as speed are really part of local procurements rather than metadata specification. Dave Harvey (talk) 21:25, 18 June 2014 (BST)