Re: [IHE-Rad-Tech1614] Template for the DBT profile

[David Clunie]

Hi all

Personally I think this decision to create a new profile is not a
great idea.

It creates a vast amount of documentation re-work that is completely
unnecessary to address the problem.

Also, since all DBT systems are going to support the "base" MAMMO
profile anyway, it seems simpler to me to simply have DBT as an
option to that.

I don't know what the reasons for choosing the new profile approach
are. The reasons listed in Antje's notes from the meeting:

"Due to the complexity of this supplement and possible options for it
(e.g flagging key images) and in order to keep it aligned with MAMMO
and SMI it was decided to create a new profile rather than an option"

are not in my opinion sufficient justification.

There is very little "complexity" triggered by DBT.

The additional consideration of "key images" introduced in the F2F
discussion is interesting, but not in itself sufficient to be
considered "complex", since we already have a KIN profile that
can be used to satisfy the "optional support for Key Image Notes
and Presentation States" that is described in Antje's notes.

So I would propose that you reverse this decision and go back to
using the text that I provided that takes the "option" approach
in preparing for the next meeting.

If anyone strongly objects to that perhaps they can volunteer to
be the editor instead of expecting Antje to do a whole lot of
(unnecessary) documentation work that serves no useful purpose.

David

On 11/26/13 10:20 AM, Schroeder, Antje wrote:
> Hi everybody.
>"
> During our face to face meeting, we decided to make the DBT supplement a new profile rather than an option to Mammo. Based on this decision the discussion came up, how to document this profile:
>
> a) We could follow the approach taken in Mammo and SMI to define a profile which re-uses a lot of the existing transactions and defines the DBT content specific stuff within the transactions used (Rad 4 and Rad 16). This would be based on the supplement template from Oct.2013
>
> b) Some people think we should start to write 'real' content profiles and just define the content (eg what DICOM SOP classes need to be supported, what information needs to be stored in the DICOM header of these objects, how do we display these object). The workflow then would be defined by binding to the relevant transactions in a workflow profile (e.g SWF or MAMMO or MAWF)
>
> In theory I like the second approach, however as we unfortunately do not have a template for DICOM content yet, I do not really feel confident on defining it on the fly and using it for a new profile. Furthermore I would like to keep the three profiles (Mammo, SMI and DBT) aligned and would like to come up with an approach that keeps the three profiles in line, since they share a lot of functionality.
>
> Based on a discussion with Mary Jungers, I think the best approach is to use the existing template (the one published in Oct.2013). I would support any activities of the Documentation workgroup to define DICOM content (which actually needs coordination with other domains as well and there are some open questions that I had, when I started thinking about it). Assuming that gets done prior to this profile going into Final text, I would then re-write the DBT profile (and potentially Mammo and SMI) based on that template prior to final text.
>
> Best regards
> Antje Schroeder
>

[Jeanne Couder]

Hi David,

 

I participated to the discussion and  was supporter of new profile rather than option, but purpose was to not to have people do unnecessary work.

And if we think the decision was not good, as far as I am concern, we might re-discuss it as well.

Here are some arguments I brought or others brought to the table during the meeting, about the new profile versus mammo option.

(To all participants please complete and correct if necessary)

 

1/ It is true that most of the needs are similar for 2D MG and DBT and that  today all systems will support 2D MG as well as DBT. But this might not be true in future.

Why a modality or evidence creator would not generate only DBT or DBT element? why would a modality be force to generate 2D exams, as specified in Mammo Image Profile, when generating DBT data? As we do not know what will come, we thought better to separate both.

2/ The other argument that was mentioned, was that vendors seem more motivated to implement new IHE profiles rather than IHE options (this was also the reason for SMI to be a new profile if I well remember).

3/  Being able to add options as we still learn on the usage of DBT.

 

Once again, the aim was to have unnecessary paper work done, and we might discuss how to simplify/share work.

 

Best Regards

 

Jeanne

[David Clunie]

I doubt there will ever be a DBT display that does not support FFDM, and though it might be possible that there would be such a modality, I think we can finesse that with the option approach.

The SMI profile did not require nearly as many of the existing MAMMO FFDM features, or the need to hang/compare with FFDM, hence made more sense as a separate profile, so is not really a useful precedent.

From an adoption perspective, I don't really think it makes a difference ... profiles and options are adopted if they solve a significant problem (and are ignored if they don't).

We can always add more options that add to the DBT option too, e.g., projection support or 3D CAD.

David

[David Clunie]

Not great at all ... I don't think we need a separate profile and that we should minimize effort for maximum return.

Do you have any arguments in favor of a profile rather than an option?

David

-------- Original message --------
From: "Lindop, Christopher (GE Healthcare)" <Christoph...@ge.com>
Date: 11/26/2013 1:26 PM (GMT-05:00)
To: David Clunie <dcl...@dclunie.com>,"Couder, Jeanne (GE Healthcare)" <Jeanne...@med.ge.com>,ihe-mam...@googlegroups.com
Cc: IHE Radiology Technical Committee <IHE-Ra...@googlegroups.com>

Subject: RE: [IHE-Rad-Tech1617] Template for the DBT profile

Great – If you do not think it makes a difference, then we can continue a development path for a separate profile.

--
You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com.
To post to this group, send email to IHE-Ra...@googlegroups.com.
Visit this group at http://groups.google.com/group/IHE-Rad-Tech.
For more options, visit https://groups.google.com/groups/opt_out.

[David Clunie]

I don't think I saw your email with your arguments, and have rebutted
those made by others so far.

I think Antje should proceed with drafting it as an option to capture
the technical content in the easiest way possible, and we can consider
re-drafting as a profile at the next F2F.

David

-------- Original message --------
From: "Lindop, Christopher (GE Healthcare)" <Christoph...@ge.com>
Date: 11/26/2013 1:55 PM (GMT-05:00)
To: David Clunie <dcl...@dclunie.com>,"Couder, Jeanne (GE Healthcare)"
<Jeanne...@med.ge.com>
Cc: IHE Radiology Technical Committee <IHE-Ra...@googlegroups.com>

Subject: RE: [IHE-Rad-Tech1621] Template for the DBT profile

I gave the technical rationale in a previous e-mail.

I would also add that from a vendor adoption perspective it does matter
if is an option or a profile.

From: IHE-Ra...@googlegroups.com
[mailto:IHE-Ra...@googlegroups.com] On Behalf Of David Clunie
Sent: Tuesday, November 26, 2013 12:43 PM
To: Lindop, Christopher (GE Healthcare); Couder, Jeanne (GE Healthcare);
ihe-mam...@googlegroups.com
Cc: IHE Radiology Technical Committee
Subject: RE: [IHE-Rad-Tech1621] Template for the DBT profile

Not great at all ... I don't think we need a separate profile and that
we should minimize effort for maximum return.

Do you have any arguments in favor of a profile rather than an option?

David




-------- Original message --------
From: "Lindop, Christopher (GE Healthcare)" <Christoph...@ge.com>
Date: 11/26/2013 1:26 PM (GMT-05:00)
To: David Clunie <dcl...@dclunie.com>,"Couder, Jeanne (GE Healthcare)"
<Jeanne...@med.ge.com>,ihe-mam...@googlegroups.com
Cc: IHE Radiology Technical Committee <IHE-Ra...@googlegroups.com>
Subject: RE: [IHE-Rad-Tech1617] Template for the DBT profile

Great � If you do not think it makes a difference, then we can continue

Le mardi 26 novembre 2013 16:32:12 UTC+1, David Clunie a �crit :

[David Clunie]

I think there may be some confusion between the MAMMO profile and
the need to create an MG object.

If an Acquisition Modality supported the MAMMO profile + DBT option,.
and did not do FFDM, only tomo (e.g., a cone-beam CT perhaps), then
it would not be required to create any MG objects.

Only if an Acquisition Modality does FFDM is it required to create
MG objects.

I assume that nobody is suggesting that a modality should be allowed
to create FFDM images (that are not synthetic MIPs from DBT) and encode
those as Breast Tomo objects ... that would be an interoperability
disaster (none of the installed base of MG object displays could
display them).

So, in short, the profile alternative to an option is not necessary
to permit Tomo-only object generation, should such a device exist.

Chris, was that the only reason you were pushing for a profile?

David

PS. For reference, I quote IHE RAD Vol 2:

"4.8.4.1.2.3 Storage of Full Field Digital Mammography Images

When participating in the Modality Images Stored transaction and
the Mammography Image Integration Profile, the Acquisition Modality
actor that creates in vivo clinical full field digital mammography
images, whether using a digital detector, by computed radiography,
or by digitizing film, shall use the DICOM Digital Mammography
X-Ray Image IOD, and shall supply the attributes with the additional
requirements presented in Table 4.8.4.1.2.3-1."

PPS. I still think that synthetic FFDM (MIPs from tomo like Hologic's
C-View) should be encoded as MG rather than Breast Tomo objects,
to maximize their display-ability with the installed base, but that
is a separate question and not really relevant to the current
DBT profile versus option debate.


On 11/26/13 2:20 PM, Lindop, Christopher (GE Healthcare) wrote:
> There is no technical reason for a DBT system to create an MG. This would be unnecessary work for a vendor to implement. That is the technical reason.
>
>>From a document profile perspective, options are messy to manage. We should not promote options. Unless you have a valid technical reason why they should be the same, I would be willing to consider it. I have not heard a valid technical reason yet.
>
> Separate profile.

>
> From: Lindop, Christopher (GE Healthcare)
> Sent: Tuesday, November 26, 2013 12:12 PM
> To: Couder, Jeanne (GE Healthcare); ihe-mam...@googlegroups.com
> Cc: IHE Radiology Technical Committee; dcl...@dclunie.com

> Subject: RE: [IHE-Rad-Tech1616] Template for the DBT profile
>
> I would add/emphasize that there was no consensus that MG would be implemented by an acquisition modality claiming DBT. To that extent, a DBT system creating a "synthetic 2D" or even a single slice DBT should use the DBT format, making the creation of a 2D MG unnecessary.
>
> This, of course opens up to the discussion of this being a content and display profile. As the template work for DICOM has not been completed, developing a profile in this manner may be additional and unnecessary work.
>
> Chris Lindop

>
> From: IHE-Ra...@googlegroups.com<mailto:IHE-Ra...@googlegroups.com> [mailto:IHE-Ra...@googlegroups.com] On Behalf Of Couder, Jeanne (GE Healthcare)
> Sent: Tuesday, November 26, 2013 11:36 AM
> To: ihe-mam...@googlegroups.com<mailto:ihe-mam...@googlegroups.com>
> Cc: IHE Radiology Technical Committee; dcl...@dclunie.com<mailto:dcl...@dclunie.com>
> Subject: Re: [IHE-Rad-Tech1616] Template for the DBT profile
>
>
> Hi David,
>
>
>
> I participated to the discussion and was supporter of new profile rather than option, but purpose was to not to have people do unnecessary work.
>
> And if we think the decision was not good, as far as I am concern, we might re-discuss it as well.
>
> Here are some arguments I brought or others brought to the table during the meeting, about the new profile versus mammo option.
>
> (To all participants please complete and correct if necessary)
>
>
>
> 1/ It is true that most of the needs are similar for 2D MG and DBT and that today all systems will support 2D MG as well as DBT. But this might not be true in future.
>
> Why a modality or evidence creator would not generate only DBT or DBT element? why would a modality be force to generate 2D exams, as specified in Mammo Image Profile, when generating DBT data? As we do not know what will come, we thought better to separate both.
>
> 2/ The other argument that was mentioned, was that vendors seem more motivated to implement new IHE profiles rather than IHE options (this was also the reason for SMI to be a new profile if I well remember).
>
> 3/ Being able to add options as we still learn on the usage of DBT.
>
>
>
> Once again, the aim was to have unnecessary paper work done, and we might discuss how to simplify/share work.
>
>
>
> Best Regards
>
>
>
> Jeanne
>
>

> Le mardi 26 novembre 2013 16:32:12 UTC+1, David Clunie a �crit :

> --
> You received this message because you are subscribed to the Google Groups "IHE Radiology Technical Committee" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com<mailto:IHE-Rad-Tech...@googlegroups.com>.
> To post to this group, send email to IHE-Ra...@googlegroups.com<mailto:IHE-Ra...@googlegroups.com>.

[David Clunie]

Hi Chris

I am just quoting what is written in the existing technical framework,
whether you like it or not, and whether it makes sense or not.

It is not a question "my logic", but rather interpreting the text
as written.

Sure, it appears to be a loophole, and sure it makes no sense for a
non-FFDM system to claim the MAMMO profile as the text stands today,
and no practical reason why a vendor would (e.g., a cardiac NM
modality could claim support for MAMMO and do nothing, but why
would it?).

But it does open the door to solving the issue with the option that
Jeanne raised of a hypothetical DBT modality that does not want/need
to do FFDM but could claim MAMMO+DBT.

I disagree that "options are the best way to kill profiles", and
your assertion is unfounded. A case in point is the "Radiology
Audit Trail Option" to ATNA; is it less widely implemented because it
is an option? No, it is implemented by radiology systems because
that is what they require. One could say the same for XDS-I.b
about "Set of DICOM Instances" or "PDF Report" options.

Users buy what they need, and if they need DBT and are educated to ask
for MAMMO+DBT then that is what they will do. The documentation mechanism
in the Integration Statements is clear.

Largely the benefit of the MAMMO profile has been on the Image Display
side anyway, and the same will be true of DBT. The modality vendor may
have a little work to clean up the IODs they create to comply, but in
general they will do that regardless, and I think we are going to have
much less of an issue with modalities than displays.

For the Image Display, MG object support is indeed an absolute
pre-requisite to DBT support, since it would be ludicrous to have
a "tomo-only" display in a world that is still predominantly non-
FFDM even for current images, much less priors. So I assume your
statement "a purchaser buys a product supporting Mammo Image would
expect as base to support MG objects ... this is an unnecessary
requirement to the DBT profile" is intended only from the Modality,
not Image Display, perspective. I.e., if we were to write a DBT
profile rather than an option, we would have to include a requirement
to support full display of MG objects (replicate all the MAMMO profile
requirements for the Image Display), given that a very common use
case is DBT comparison with MG priors.

So in my opinion, the option is still on the table, so as to speak.

The day may come in the far distant future when users consider DBT
as a "modality" in its own right, but for now it is an add on ("option")
to FFDM systems, which is optionally used, and for which PACS and work
stations may "optionally" choose to display it, and for which patients
"optionally" choose to pay for it, since it seems to be "optional" for
payers to reimburse for it.

So adding DBT as an "option" to the existing MAMMO profile fits right in
with the reality of the development and deployment of these systems,
and the user's perception of them.

David

On 11/26/13 4:55 PM, Lindop, Christopher (GE Healthcare) wrote:
> Are we looking at the same profile? The Mammo Image Profile absolutely requires the Acquisition Modality to create an MG image Object. There is no statement in Mammo that the MG Image object is an undeclared option. Undeclared options as you describe are actually harder to document and claim than documented ones. I think you are justifying exactly why it should be a separate profile. IHE should have no ambiguities. Based on your logic, an acquisition system can claim support of Mammo Image even if it does not support MG or DBT. I suppose I can create my IOD. Alternatively, the Mammo profile could be re-written to indicate that MG is an option. I would not favor that.
>
> Few purchasers and vendors look at options. An option would increase the complexity with the end-users. Options are always the best way to kill profiles. A purchaser buys a product supporting Mammo Image would expect as base to support MG objects. This is an unnecessary requirement to the DBT profile.
>
> So in short the profile option alternative to a profile is confusing. IHE needs to be clear and simple for users and implementers. An option should be off the table.

> To unsubscribe from this group and stop receiving emails from it, send an email to IHE-Rad-Tech...@googlegroups.com.
> To post to this group, send email to IHE-Ra...@googlegroups.com.

[Schroeder, Antje]

Hello altogether,

I had the feeling that at our meeting there was a consensus among all members present at the first day, that we should define this as a profile. At this point in time I see a discussion between two members. What is the opinion of other participants? Answering as a Siemens Representative (not necessarily as the editor of this profile), I could see advantages to either way of documenting this profile.

 

In this eMail conversation I saw the following reasoning for an option:

• DBT is always dependent on the Mammo Image profile and therefore should be documented as such.
• It means less documentation effort

 

Reasons for a separate profile I read so far

• Better marketing value, if it could be claimed as a separate profile
• Support for Acquisition Modalities that only create DBT objects and no DICOM MG objects
• Cleaner way of documenting things, especially when it comes to adding options to an option, especially if this profile needs to be extended later.
• General trend to use less options

 

As an editor, I would like to document, what makes most sense, independent of how much effort it means. David suggested that it would be possible to support the second bullet of DBT only modalities even in the option approach (however I need to admit, I do not really understand your reasoning, David, which may be due to the fact that I do not understand all nuances of the English language). I'm not clear, how we would document options on options, which seems a little messy so to me.

 

I would like to come to a decision on this topic asap, the latest by the end of the week, so that I could start documenting in detail. Therefore I would like to get input from a broader number of committee members.

 

Thanks

antje

[Wolfman, Judith]

Although I understand from the discussion that a separate profile for DBT may be more work, which, and I truly appreciate the amount of work required, from an end user, a separate profile would certainly make it easier to document modality capability when purchasing.  As a practicing radiologist in a large institution, I have some input on equipment purchases, and certainly review the RFP.  However, once it goes to the purchasing department (and the lawyers to review the purchase contract), I’m not sure that “options” might get lost without a defined checklist which a separate profile may provide.

 

Again, thank you so much for all of your time and expertise,

Judy

--
You received this message because you are subscribed to the Google Groups "IHE Mammography" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-mammograp...@googlegroups.com.
To post to this group, send email to ihe-mam...@googlegroups.com.
Visit this group at http://groups.google.com/group/ihe-mammography.

[Schroeder, Antje]

Good Morning.

 

Based on the feedback on my last eMail and the discussions that we had during our f2f meeting in Oak Brook, I decided to write the DBT supplement as a separate profile and not an option to Mammo Image.  However I will not draft this as a content profile but rather use the existing Supplement Template Document.

 

Antje

 

From: ihe-mam...@googlegroups.com [mailto:ihe-mam...@googlegroups.com] On Behalf Of Schroeder, Antje

Sent: Mittwoch, 27. November 2013 15:45
To: dcl...@dclunie.com; 'ihe-mam...@googlegroups.com'; IHE-Ra...@googlegroups.com

--
You received this message because you are subscribed to the Google Groups "IHE Mammography" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ihe-mammograp...@googlegroups.com.
To post to this group, send email to ihe-mam...@googlegroups.com.
Visit this group at http://groups.google.com/group/ihe-mammography.