Use Cases
Please list any use cases, including personal involved and the data they need on this page. Do not worry if you have trouble editing for style, formatting etc. - that can be corrected/edited by others!
I'm not sure where these comments belong, but here seems as good a place as any. 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.).
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?
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.
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""
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.
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.
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)
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?
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.
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).
Mime Type - no issues
Reference ID List - not sure how his would be used in the context of correspondence. ?
Limited MetaData - i think we need to define the "minimum metadata" before we can decide whether a document has Limited Metadata?
ENDS------------------------------------
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?
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.
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.
