Guidance for use of XDS Document Metadata

=Guidance for use of XDS Document Metadata

in the UK=

Dave Harvey 11/5/14

Change History

Version	Date	Details
0.1	8/5/14	First draft – limited distribution
0.2	11/5/14	Placed in dropbox for review, with examples added
0.3	21/5/14	Placed onto IHE-UK web site for comments
0.4	22/05/14	NOT yet published – adding open questions.

This is a very early version, based on discussions over the last month, and is intended as much to stimulate debate as to provide guidance. Please send comments to dave@ihe-uk.org, or by commenting at http://www.ihe-uk.org/MetaDataProposal

Open Questions and Options

1. Should the correspondence document list be classCode or typeCode? XDS-I usage would favour classCode, but size would favour typeCode!
2. Do we need specific codes for different specialities? e.g. in place of “Report”, do we need “Radiology report”, “Haematology report”, “Biochemistry report” etc.? Doing so would go against XDS guidance for classCode (which should be generic).
3. How should “associated specialities” be represented? The suggestion below is to use eventCodes, but there are 3 other possibilities:
   1. For requests (not reports), use the finer grained classCodes/typeCodes to indicate receiving speciality.
   2. For reports, use an “indirect author” (role = recipient) to indicate the destination.
   3. The “Indirect author” could also be used for requests
4. What confidentiality codes should be used?
5. Do staff need unique identifiers (GMC number etc.) or is name+institution adequate?
6. Should specialities be simplified to be “patient-centric” rather than “author-centric”?
7. What document formats (mine types / formats) should be permitted?
8. What (if any) structural differences would need to be made to provide equivalent support for medical and social care?

Rationale

The timing of the work now has been stimulated by both the (near) publication of the SNOMED list (work done by Leo Fogarty), and by the need to provide guidance to a few projects currently needing something to get started with.

Principles

The logic behind these suggestions is that documents should be classified as flexibly as possible, in a way which permits optimum searching for documents based on multi-dimensional codes, rather than simplistic classification into single-valued metadata items. None of the suggestions here prevent any classification within the document, nor any other data being used for routing/recipients (push) – it is purely based around the principle of making the documents as easily and flexibly discoverable as possible for “pull” retrieval. This document concentrates purely on document metadata - equivalents for submission sets and folders can easily be generated later on the same principles, with only Content Type Code (for the submission set) needing any specific consideration. Whilst the actual example codes in Appendices A and B are based primarily on health care, as that is the context in which they have been generated, the intention of this guidance is that it should be sufficiently generic to embrace social care as/when suitable document types, settings and “speciality” codes have been defined.

Summary

For those already acquainted with the XDS metadata model, the UK-specific recommendations in this note can be summarised as follows:

Patient ID	NHS Number
Class Code	Generic "Clinical Document"
Type Code	Current SNOMED "correspondence document type" subset
Practice Setting Code	Current SNOMED Practice Setting Code list
Event Code List	Multiple values, including: Receiving and sending specialities, possibly using simplified speciality codes. Discipline-specific additions, e.g. for radiology: Body Part(s) Modality(s) NICIP code (and/or as SNOMED equivalent)

Example

A simple sample, based on this draft is presented in Appendix C, both in full XML version and in a simplified human-readable form.

Specific Fields:

Patient ID:

Type: XCN Coded Value Multiplicity: Single

Whilst the obvious contender for this filed would be the NHS number, combined with the appropriate OID root (2.16.840.1.113883.2.1.4.1), concerns are regularly raised about the suitability of the NHS number for this role due to perceived deficiencies, including duplicates and the issue of temporary numbers. Whilst primary "guidance" could simply be to use the NHS number, secondary guidance about how to cope with its deficiencies might also be needed.

Source Patient ID:

Type: XCN Coded Value Multiplicity: Single

This should be the primary number used locally to identify the patient, and would normally be a PAS number (with associated root OID), but could be NHS number where that is used as the primary local identifier.

Source Patient Info

Type: Complex Type Multiplicity: Single

This field is not used for searching, and it exists only for possible corroboration of the main Patient ID if problems are detected. It can therefore be completed using information from PAS/RIS/PACS etc. on a "best efforts" basis, and no specific UK guidance is needed.

Type Code:

Type: Coded Value Multiplicity: Single

This should be populated using one of the “Correspondence Document Type” SNOMED codes, as listed in Appendix A. These are deliberately practice setting and speciality agnostic, and therefore the full meaning is derived by combing the Type Code with the Practice Setting Code.

Class Code:

Type: Coded Value Multiplicity: Single

Given suitable values of Type Code and Event codes (as below), it is difficult to define a useful role for this field, and it could be used in an extremely broad manner to enable clinical documents to be filtered from others that might also be stored in the same system, so perhaps the following:

• Clinical Documents
• Privacy Documents
• Financial Documents
• Etc.

Ideally, these should be located or added as SNOMED codes, with a suitable OID to represent them. In the sample in Appendix C, the SNOMED code 419891008 (Record artifact) has been used.

Author

Type: Complex Type Multiplicity: Multiple

May be person or “system” - we need to ensure that values from a "system" without a person readily identifiable are supported, provided that the system from which they originate is identifiable.

Institution

This is XON coded, meaning that an OID for the coding scheme could be included, but free test is also allowed. Values from NHS OCS Organisation Codes could possibly be used.

Person

This is XCN coded, meaning that name and/or unique ID can be included

Open questions:

1. Do we have a national list we can use? NHS staff number? GMC/Nursing/radiographer registration code?
2. How do we represent "systems"? (e.g. PACS submitting XDS-I manifests)?

It is worth noting in this regard that the GMC guidance is that a doctor should include the GMC number in all "correspondence" - see http://www.gmc-uk.org/doctors/information_for_doctors/doctors_registration_number.asp

Role

This can be either free txt or CX coded, meaning that a unqiue ID and an OID for the coding scheme could be included

Values and meaning as per list at: http://www.datadictionary.nhs.uk/data_dictionary/attributes/j/job_role_code_de.asp

Speciality

This can be either free txt or CX coded, meaning that a unique ID and an OID for the coding scheme could be included

Values and meaning as per list at: http://www.datadictionary.nhs.uk/data_dictionary/attributes/m/main_specialty_code_de.asp

Telecommunication

If supported, is well defined in the IHE framework as an XTN value - giving a means to add phone, e-mail etc.

Legal Authenticator

Type: XCN Coded Value Multiplicity: Single

This should be coded in the same way as the Author/Person part of the Author type, and has the same open question regarding unique staff identification.

EventCodeList

Type: Coded Values Multiplicity: Multiple

This set of fields is extremely flexible, and is in many ways the ideal place to hold searchable values. Whilst technically described as being to represent "clinical acts", it has been recognised that it actually has slightly wider applicability, for instance in the XDS-I profile, where it is mandated that it be used not only for the modality used for imaging, but also for the body part examined. Combined with the flexibility to structure complex and/or queries based on this field (which are mandatory for registries to support in their entirety), this list be used as the main place to hold data important for searching for clinical data in an extensible manner where that data does not have a suitable, multi-valued existing more specific location. There is no limit on the number or type of codes which may be added, and 3 broad groups are proposed:

1) General UK-specific requirements

Given that the Document Type Codes are speciality-neutral, but that speciality is important for searching (e.g. a Haematology report is very different from a radiology report), a code should be included for all specialities involved in the document. For instance:

1. An internal note such as an in-patient progress note, would include only a single code.
2. A document passing between departments (or generated by one at the request of another) would have codes for both the specialities. So for instance, a request from ENT to radiology would generate (at least) a referral, images (referenced via XDS-I) and a report, and all 3 would contain codes for both ENT and radiology.
3. In other situations such as multi-disciplinary team meetings, there could be 3 or more speciality codes.

The form of the speciality code is open to debate. At one extreme, there is the list of "practice setting codes" (Appendix B), but this is held elsewhere, and is very specific, making it difficult to use reliably for searching. The list of specialities recognised for consultants would make a much simpler and perhaps therefore more manageable and useful list - see : http://www.datadictionary.nhs.uk/data_dictionary/attributes/m/main_specialty_code_de.asp.

As a further simplification, it would be possible to remove all "age-specific" terms from the list, collapsing say "PAEDIATRIC CARDIOLOGY" and "CARDIOLOGY" into just "CARDIOLOGY", to avoid arbitrary discontinuities across age boundaries (e.g. when looking to see what heart investigations may have been done on a 17 year old patient, there is a risk of excluding those that happen to have occurred before her 16th birthday)

2) Speciality-Specific requirements

Radiology is used as an example in this document, but similar principles apply to others.

The XDS-I profile requires that documents submitted conforming to that profile (both image manifests, and others such as reports), contain the following 2 requirements:

1. Modality(s) used in the imaging. This is well-defined in terms of the DICOM modality codes, including a OID to clarify the vocabulary, and there is no reason to modify this for UK usage.
2. Body Part(s) imaged. This too should be included, but the current definition in the XDS-I profile is in terms of SNOMED-RT codes, rather than SNOMED CT codes. Open question: should we specify that SNOMED-CT codes should be used in place of the SNOMED-RT? Even if that is changed, then keeping the relative small defined list of body parts (CID-4 in DICOM Part 16) would seem sensible to assist completeness in searches.

In addition to the above, it is clearly useful to document the actual imaging procedure itself, and the NICIP code(s) used should also be included (together with their defining OID: 2.16.840.1.113883.2.1.3.2.4.21), or perhaps the (already mapped) SNOMED equivalents.

Clearly other specialities would need their own equivalent guidelines and rules - e.g. surgical procedure codes.

3) Other codes

There are no constraints in the XDS specification on other codes which could be added, and there is no obvious reason to add such constraints for UK usage, provided that the information provided in them is not something which could and should be included elsewhere in the metadata.

Healthcare Facility Type Code

Type: Coded Value Multiplicity: Single

There is a list in the NHS dictionary which could be used for this purpose - see http://www.datadictionary.nhs.uk/data_dictionary/attributes/o/org/organisation_type_de.asp and whilst it would seem to be suitable for initial use, it seems to be heavily weighted toward fine detail for NHS organisations, with little detail for non-NHS data sources such as "Local Authority" or even "Non-NHS organisation".

Practice Setting Code

Type: Coded Value Multiplicity: Single

A suitable list has recently been provided alongside the list of document types (Annex B), which would appear to be suitable for this item. There is an important distinction between this field, which indicates relatively fine detail of the environment/staff involved, and the speciality code in the event list which provides the much broader view of the speciality to which the clinical document relates.

Title

Type: Free text Multiplicity: Single

Being free text, and not searchable, this field is not important in the query, but it is important in the returned data, as many consumers will display to the user, allowing them to decide whether to retrieve and display the document. The title should therefore contain a meaningful human readable indicator of the document title, and this need not necessarily be any particular combination of other fields.

Comments

Type: Free text Multiplicity: Single

Being free text, and not searchable, this field has little use, but can usefully be used to hold comments about the document, perhaps related to system generating it etc.

Confidentiality Code

Type: Coded Value Multiplicity: Single

A simple code set will need to be developed if it does not already exist - for the sample an existing US code has been used, along with its OID.

Format Code

Type: Coded Value Multiplicity: Single

The standard types available are well defined in the IHE technical frameworks, and the main tasks for UK guidance are to decide which ones should be used/supported by systems in the UK, and whether any more specific codes are required for UK-specific documents such as those being developed by the PSRB. In the meantime, the “standard” codes for XDS & XDS-I should fulfil immediate needs.

Mime Type

Type: Coded Value Multiplicity: Single

Only a small subset of the possible MIME types (e.g. text/xml, application/dicom or application/pdf) are specifically referenced in the IHE technical frameworks, and whilst other (including even application/msword etc.) would be permissible within the standard, confining to the above 3 + standard browser-supported images (e.g. image/jpeg or image/png) would seem a sensible constraint.

Reference ID List

Type: Coded Value Multiplicity: Multiple

This is a “new” addition to the XDS Metadata set, and includes places to some additional data items. Of these, the only one likely to have immediate usage in the UK is the “accession number” which should be used in radiology, and potentially in other disciplines such as pathology to link together requests, images and reports. This raises 2 important issues:

1. Being new implementations, systems going into UK hospitals are not constrained by history and the fact that this is a recent addition to the standard in the form of an “option” for registries. UK registry purchases should therefore mandate support for the “ReferenceId” option in sources, registries and consumers.
2. The accession numbers, if not globally unique should be associated with an issuer OID to provide such uniqueness, so a method to allocate OID for this purpose will be necessary, including the ability to allocate >1 per organisation, as radiology and pathology and numerous other systems may have otherwise overlapping ranges.

Limited MetaData

Type: Flag Multiplicity: Single

This is simply an indicator of whether the document has restricted metadata, for instance if the document were generated by automated scanning of paper notes. The field itself needs no UK-specific profiling, but it might be useful to consider the circumstances (if any) under which documents of this type should be used in the UK.

Generic Fields

The following attributes are well documented in the IHE framework, are automatically generated in standard ways, and so need no significant UK-specific discussion:

• Availability Status
• Creation Time
• Entry UUID
• Hash
• Size
• Home Community ID
• Repository Unique ID
• UniqueID
• URI
• Language Code
• Service Start Time
• Service Stop Time