Vous pouvez maintenant accéder à la version de decembre 2024 du Répertoire canadien des médicaments à partir de Terminology Gateway et du serveur terminologique, à des fins de consultation ou d’implantation. En savoir plus >

Partager :

file REMINDER: Remote Reading For Imaging - Profile/Guide - Comments Due Wednesday July 8, 2015

  • Messages : 8
il y a 9 ans 5 mois #599 par Chris Lindop
I have updated the document and posted it at ic.infoway-inforoute.ca/en/resources/docs/imagingdocs/337-di-rri-2015-07-013

As per our discussion, the next step will be to publish this as a new profile proposal for next year.

Chris

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

  • Messages : 5
il y a 9 ans 5 mois #590 par Cezary Klimczak
Hi Chris,

My high-level comment on the document has to do with the Content Modules section. It looks to me like the currently proposed Metadata associated with a workflow document may be insufficient to locate relevant workflows based a reasonable search criteria.

We can argue/discuss what a reasonable search criteria is, but for now I think it may make sense to consider at least the few key attributes that are used in other imaging-related cross-enterprise profiles (namely XDS-I). These attributes are:

- Exam/procedure code
- Body part
- Modality
- Reference ID (with the fully qualified accession number). This would facilitate queries like ".
- Document Author (which is really a set of authors) that could encompass - similar to the XDS-I metadata - the set of human stakeholders relevant to a given workflow, e.g., the requestor of the remote read (if requested by a human), the referring physician associated with the exam to be read, etc.

The addition of these attributes would facilitate queries like:
- what are the outstanding "Chest CTs with Contrast" that are awaiting remote reads
- what are outstanding SPECT-CT exams to be read
- what is the status of a particular remote read for an exam whose accession number (fully-qualified) is known
- what are the open remote read requests associated with a particular human stakeholder (like a referring physician)

Cezary

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

  • Messages : 8
il y a 9 ans 5 mois #579 par Kinson Ho
Hi Ben, Chris and others,

I uploaded a copy of the implementation guide with my comments here

ic.infoway-inforoute.ca/en/resources/docs/imagingdocs/305-remote-reading-iguide-kh

I have a general comment after reviewing the remote reading implementation guide. For the XDS/XDS-I implementation guide that we developed in the last few years, over the years, many of us, both from the vendors and from the different provincial project teams, have gained a good understanding of the details and how to apply the knowledge to the specific project. As a result, during the comment period, we received a great list of feedback from both vendor side as well as project teams. This also shows that there are a number of active projects going on using XDS/XDS-I as a base and therefore this implementation guide is highly valuable as a base for each project team to customize. For this remote reading using XDW/XDS-I implementation guide, so far the comments are on the lighter side. I have not seen any comments from any project teams yet. Not sure if this means the need for implementing remote read is still quite some time in the future and therefore there is no time to review this implementation guide yet, or the practical and technical knowledge of using XDW is not there. I have added quite a lot of comments, some related to the solution / business architecture, some related to the technical details. For example, how to handle addendum? How to handle procedure updates after the read request is sent? Does it require change in the 15 minutes XDS manifest submission guideline? How to handle terminology differences in the Read Request OMI message and the facility that the Read Performer is located? How should the Dispatcher be aware of the different Performers and their credentials/capability? etc. I don't think these questions should be answered by vendors because the software will likely be configurable to adopt to different situations. I would really like to see participation and comments from project teams to answer some of the questions rather than just discussions from the vendors. This is particularly important given this is an implementation guide, not a technical profile. In my opinion, an implementation guide should have further guidance on how to address practical problems, ideally use cases that Canada needs the most. I think the state of the document now is high on technical details but low on specific practical guidance, especially if we compare to what we develop for the XDS/XDS-I implementation guide.

Thanks,

Kinson

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

  • Messages : 47
il y a 9 ans 5 mois #571 par Ben Macerola

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é.