- Forum
- Communities
- Integrating the Healthcare Enterprise (IHE)
- Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards
Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards
- David Kwan
- Topic Author
- Offline
- Posts: 54
2 weeks 5 days ago #9865
by David Kwan
Replied by David Kwan on topic Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards
• Charles Parisot, (IHE MCWG Facilitator), “As you may have heard, IHE Europe has a Multi-Country Working Group (MCWG) on imaging, where we bring together implementation experience on national level image information sharing together to deliver recommendations going forward. Among the 3 sets of recommendations that MCWG and its 10 member countries have produced, one of them is on the Metadata and its use in the three steps query model used by XDS, XDS-I and MHD.
• ==> www.ihe-europe.net/multi-country-working-group-Imaging-Information-Sharinghttps://www.ihe-europe.net/multi-country-working-group-Imaging-Information-Sharing
• MCWG Approved Recommendations on Imaging Information Sharing on April 2024
1. Profile and Standards Positioning (May 2024), Positions the role of HL7 FHIR in the sharing of imaging information architectures, choice of profiles and standards such as MHD(FHIR), XDS-I. Coexistence with XCA and FHIR/MHD, integration of Web Access to DICOM Objects (WADO-RS) in XDS-I.
2. Imaging Metadata and linkages (December 2023), Strategies or metadata definitions for filtering access in queries (key filtering elements) and linkages between orders, reports and imaging studies.
3. Extensions to Imaging Study Manifest (February 2024), Develop context of use of manifests, explain the choice of DICOM KOS, refine the content of imaging study manifest in areas such as patient IDs, accession numbers, additional content in study/series descriptions.
The set of recommendations on Imaging Metadata and Linkage is where the answer to your question is found, more specifically slides 14 and 15.
In short, document type code, is impractical for filtering, but critical for selection in step 2 of the search process. Friendly naming of document types is important for such a selection.
Therefore, imaging procedure codes are not appropriate as TypeCodes and shall be a specific event code added to eventcodelist (that departs from XDS-I). They are also related to laterality….
ClassCode is a much higher classification. See that we have recommended a list of class codes, where imaging has only one value.
But all of this cannot be divorced from the coding of body parts/system, as it is one of the most critical elements.
So much analysis and positive and negative experience went into these recommendations. We invited the NHS into MCWG, last year.
• Neil Robinson responded, “I'll take a look at the MCWG content and get back ASAP Charles.”
• ==> www.ihe-europe.net/multi-country-working-group-Imaging-Information-Sharinghttps://www.ihe-europe.net/multi-country-working-group-Imaging-Information-Sharing
• MCWG Approved Recommendations on Imaging Information Sharing on April 2024
1. Profile and Standards Positioning (May 2024), Positions the role of HL7 FHIR in the sharing of imaging information architectures, choice of profiles and standards such as MHD(FHIR), XDS-I. Coexistence with XCA and FHIR/MHD, integration of Web Access to DICOM Objects (WADO-RS) in XDS-I.
2. Imaging Metadata and linkages (December 2023), Strategies or metadata definitions for filtering access in queries (key filtering elements) and linkages between orders, reports and imaging studies.
3. Extensions to Imaging Study Manifest (February 2024), Develop context of use of manifests, explain the choice of DICOM KOS, refine the content of imaging study manifest in areas such as patient IDs, accession numbers, additional content in study/series descriptions.
The set of recommendations on Imaging Metadata and Linkage is where the answer to your question is found, more specifically slides 14 and 15.
In short, document type code, is impractical for filtering, but critical for selection in step 2 of the search process. Friendly naming of document types is important for such a selection.
Therefore, imaging procedure codes are not appropriate as TypeCodes and shall be a specific event code added to eventcodelist (that departs from XDS-I). They are also related to laterality….
ClassCode is a much higher classification. See that we have recommended a list of class codes, where imaging has only one value.
But all of this cannot be divorced from the coding of body parts/system, as it is one of the most critical elements.
So much analysis and positive and negative experience went into these recommendations. We invited the NHS into MCWG, last year.
• Neil Robinson responded, “I'll take a look at the MCWG content and get back ASAP Charles.”
Please Log in or Create an account to join the conversation.
- David Kwan
- Topic Author
- Offline
- Posts: 54
2 weeks 5 days ago #9864
by David Kwan
Replied by David Kwan on topic Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards
• Kinson Ho, (Imaging Standards SME, Tempus Labs, Inc.), posed question: “Just curious. I assume the hospitals in BC use this provincial XDS-I infrastructure to search for external relevant priors. In this case, does the query constraint on typeCode? If so, is your terminology translation engine being used in query as well besides store and retrieve?”
• Cezary Klimczak (CTO, Leafsprout Technologies Inc), responded: “Depending on what each hospital (chief radiologist) defines as "relevant external priors" for their local site/PACS, the query to the XDS-I infrastructure may indeed be performed based on Procedure Code (stored as typeCode in XDS-I), or Modality and Body Part (both stored as eventCodes in XDS-I), or Practice Setting (e.g., to constrain results to radiology vs. cardiology vs. breast imaging), or Facility Type (to differentiate between hospitals and outpatient facilities), or based on other parameters (study date, etc). Those queries are supported out of the box by XDS-I: both for a specific patient in the context of a particular episode of care; and across patients (MPQ) for reporting/statistical purposes, e.g., give me all PET Brain exams performed at any hospital in the province in the last week/month.”
• Cezary Klimczak (CTO, Leafsprout Technologies Inc), responded: “Depending on what each hospital (chief radiologist) defines as "relevant external priors" for their local site/PACS, the query to the XDS-I infrastructure may indeed be performed based on Procedure Code (stored as typeCode in XDS-I), or Modality and Body Part (both stored as eventCodes in XDS-I), or Practice Setting (e.g., to constrain results to radiology vs. cardiology vs. breast imaging), or Facility Type (to differentiate between hospitals and outpatient facilities), or based on other parameters (study date, etc). Those queries are supported out of the box by XDS-I: both for a specific patient in the context of a particular episode of care; and across patients (MPQ) for reporting/statistical purposes, e.g., give me all PET Brain exams performed at any hospital in the province in the last week/month.”
Please Log in or Create an account to join the conversation.
- David Kwan
- Topic Author
- Offline
- Posts: 54
2 weeks 5 days ago #9863
by David Kwan
Replied by David Kwan on topic Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards
Question posed: “We are developing a National Imaging Registry (IHE -XDS-I) and are looking at the appropriate relationship between classCode and typeCode. The issue is around supporting a 1:1 relationship of typeCode to classCode whilst appropriately declaring the actual imaging that was undertaken. Would like to ask what value sets you have used."
• Cezary Klimczak (CTO, Leafsprout Technologies Inc), “as the author of the XDS-I Metadata section in the Canadian Health Infoway Standards, I can explain how we handled the topic of classCode and typeCode in Canada.”
XDS-I classCode:
• It is used to convey the high level type of each document (not the low-level format for which there is a formatCode) published to the XDS-I Infrastructure. There are two main types of real-world entities that are expressed as documents in the XDS-I deployments, each associated with a single class code:
• imaging study - represented as a manifest (DICOM KOS object) containing pointers to the study's instances. In Canada we use the LOINC code 18726-0, code system: 2.16.840.1.113883.6.1
• imaging report - represented as a CDA document (in most deployments, PDF or text also possible -- again the format code governs that) containing the imaging report. In Canada we use the LOINC code 18748-4, code system: 2..16.840.1.113883.6.1
• The above class codes are affinity-domain specific so whatever we use in Canada might be different from what the UK ends up using (if there is a preference for coding systems other than LOINC).
XDS-I typeCode:
• It is used to identify the type of the procedure associated with the published manifest and report (e.g., Chest 2 View). Different jurisdictions within Canada (i.e., provinces) use different value sets here. A set typically contains around 3500-4000 codes as there are many types of imaging procedures out there. SNOMED-CT (used by Ontatrio) and private coding systems are the most popular vernaculars.
• In terms of approaches to implementation on a large scale, Leafsprout, the company I work for, deployed the XDS-I infrastructure and the Foreign Exam Management infrastructure for the province of British Columbia. BC chose to use their own private set of procedure codes -- neither based on SNOMED-CT nor RadLex nor LOINC but rather on a set that their provincial eHealth body maintains. The set comprises around 3500 codes/procedures, a.k.a. exam codes. Those are the provincial level codes that are different from the local procedure codes used at different hospitals throughout the province. It was not feasible (cost-wise) to convert hundreds of hospitals to the provincial set as radiologists in different parts of the province were quite passionate about their own local terminologies that had been in place for 30 years or so, e.g., CT HEAD at one place is CT SKULL at another vs. CT BRAIN at yet another, vs. CT-156 somewhere else. Yet, there was a desire to perform meaningful cross-site comparisons, statistical analyses, or to be able to import external exams to any local PACS within the province. As a result we rolled out a terminology translation engine that normalizes all local exam codes to the global set upon registration in the provincial XDS-I system. The same engine localizes global exam code to the local one when bringing a remote external prior study and report to the local PACS. This way an external exam acquired for a patient in a hospital 1000km away (with a different exam code, MRN and accession) shows up in a local PACS with the appropriate local exam code (and local MRN and localized accession) to avoid conflicts/hazards and so the appropriate local hanging protocols can be applied, as if that exam was performed locally.
• Cezary Klimczak (CTO, Leafsprout Technologies Inc), “as the author of the XDS-I Metadata section in the Canadian Health Infoway Standards, I can explain how we handled the topic of classCode and typeCode in Canada.”
XDS-I classCode:
• It is used to convey the high level type of each document (not the low-level format for which there is a formatCode) published to the XDS-I Infrastructure. There are two main types of real-world entities that are expressed as documents in the XDS-I deployments, each associated with a single class code:
• imaging study - represented as a manifest (DICOM KOS object) containing pointers to the study's instances. In Canada we use the LOINC code 18726-0, code system: 2.16.840.1.113883.6.1
• imaging report - represented as a CDA document (in most deployments, PDF or text also possible -- again the format code governs that) containing the imaging report. In Canada we use the LOINC code 18748-4, code system: 2..16.840.1.113883.6.1
• The above class codes are affinity-domain specific so whatever we use in Canada might be different from what the UK ends up using (if there is a preference for coding systems other than LOINC).
XDS-I typeCode:
• It is used to identify the type of the procedure associated with the published manifest and report (e.g., Chest 2 View). Different jurisdictions within Canada (i.e., provinces) use different value sets here. A set typically contains around 3500-4000 codes as there are many types of imaging procedures out there. SNOMED-CT (used by Ontatrio) and private coding systems are the most popular vernaculars.
• In terms of approaches to implementation on a large scale, Leafsprout, the company I work for, deployed the XDS-I infrastructure and the Foreign Exam Management infrastructure for the province of British Columbia. BC chose to use their own private set of procedure codes -- neither based on SNOMED-CT nor RadLex nor LOINC but rather on a set that their provincial eHealth body maintains. The set comprises around 3500 codes/procedures, a.k.a. exam codes. Those are the provincial level codes that are different from the local procedure codes used at different hospitals throughout the province. It was not feasible (cost-wise) to convert hundreds of hospitals to the provincial set as radiologists in different parts of the province were quite passionate about their own local terminologies that had been in place for 30 years or so, e.g., CT HEAD at one place is CT SKULL at another vs. CT BRAIN at yet another, vs. CT-156 somewhere else. Yet, there was a desire to perform meaningful cross-site comparisons, statistical analyses, or to be able to import external exams to any local PACS within the province. As a result we rolled out a terminology translation engine that normalizes all local exam codes to the global set upon registration in the provincial XDS-I system. The same engine localizes global exam code to the local one when bringing a remote external prior study and report to the local PACS. This way an external exam acquired for a patient in a hospital 1000km away (with a different exam code, MRN and accession) shows up in a local PACS with the appropriate local exam code (and local MRN and localized accession) to avoid conflicts/hazards and so the appropriate local hanging protocols can be applied, as if that exam was performed locally.
Please Log in or Create an account to join the conversation.
- David Kwan
- Topic Author
- Offline
- Posts: 54
2 weeks 5 days ago - 2 weeks 5 days ago #9862
by David Kwan
Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards was created by David Kwan
To IHE Canada Community Members,
This Forum topic and responses will be of interest to many of you.
We recently received an inquiry in the Infoway standards inbox from Neil Robinson at IHE UK regarding their National Imaging Registry (IHE -XDS-I) project.
Neil asked, “We are developing a National Imaging Registry (IHE -XDS-I) and are looking at the appropriate relationship between classCode and typeCode. The issue is around supporting a 1:1 relationship of typeCode to classCode whilst appropriately declaring the actual imaging that was undertaken. Would like to ask what value sets you have used."
We reached out to a group of experts and what follows is the resulting conversation that was very informative for Neil and the UK project. We thank Cezary Klimczak, Kinson Ho, and Charles Parisot for participating in this conversation.
This will nicely prepare anyone attending the Enterprise Imaging Community Nov 15th webinar, “Chartering Interoperability for Large-Scale, Second-Generation Imaging Information Sharing: IHE MCWG Contribution” with Charles Parisot. This webinar is on Friday Nov 15th at noon EST, you may find webinar and registration info with this link: infocentral.infoway-inforoute.ca/en/news-events/event-calendar/icalrepeat.detail/2024/11/15/36211/130/chartering-interoperability-for-large-scale-second-generation-imaging-information-sharing-ihe-mcwg-contributionhere .
David.
This Forum topic and responses will be of interest to many of you.
We recently received an inquiry in the Infoway standards inbox from Neil Robinson at IHE UK regarding their National Imaging Registry (IHE -XDS-I) project.
Neil asked, “We are developing a National Imaging Registry (IHE -XDS-I) and are looking at the appropriate relationship between classCode and typeCode. The issue is around supporting a 1:1 relationship of typeCode to classCode whilst appropriately declaring the actual imaging that was undertaken. Would like to ask what value sets you have used."
We reached out to a group of experts and what follows is the resulting conversation that was very informative for Neil and the UK project. We thank Cezary Klimczak, Kinson Ho, and Charles Parisot for participating in this conversation.
This will nicely prepare anyone attending the Enterprise Imaging Community Nov 15th webinar, “Chartering Interoperability for Large-Scale, Second-Generation Imaging Information Sharing: IHE MCWG Contribution” with Charles Parisot. This webinar is on Friday Nov 15th at noon EST, you may find webinar and registration info with this link: infocentral.infoway-inforoute.ca/en/news-events/event-calendar/icalrepeat.detail/2024/11/15/36211/130/chartering-interoperability-for-large-scale-second-generation-imaging-information-sharing-ihe-mcwg-contributionhere .
David.
Last edit: 2 weeks 5 days ago by David Kwan.
Please Log in or Create an account to join the conversation.