Faites-nous part de vos impressions sur le Serveur terminologique, et aidez-nous à améliorer nos services! Vous avez jusqu’au 3 décembre 2024 pour répondre au sondage. Votre avis nous intéresse! En savoir plus >

Partager :

file Guidance Request on IHE UK Inquiry Regarding National Imaging Registry Standards

  • Messages : 54
il y a 2 semaines 6 jours #9865 par David Kwan
• 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.”

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 54
il y a 2 semaines 6 jours #9864 par David Kwan
• 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.”

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 54
il y a 2 semaines 6 jours #9863 par David Kwan
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.

Connexion ou Créer un compte pour participer à la conversation.

  • Messages : 54
il y a 2 semaines 6 jours - il y a 2 semaines 6 jours #9862 par 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.
Dernière édition: il y a 2 semaines 6 jours par David Kwan.

Connexion ou Créer un compte pour participer à la conversation.

Logo d'InfoCentral

La santé numérique à votre service

 

Transformer les soins de santé au Canada grâce aux technologies de l'information sur la santé.