sai.ramani@gmail.com wrote:


> I understand that if i receive a date range and a time range, then i
> combine the start date and start time into the start datetime and the
> end date and end time into a end date time. Things get a little
> confusing when only one of them is a date range.
> Sai

Hi Sai,

The special processing for date and time range on the MWL was put into
place after it was recognized that handling each of them independently
would result in a query for data which might lie in many different
discontinuous time ranges: difficult to compute and not a particularly
useful use case.

Handling them independently, the time range defines a distinct range
within a 24 hour period. When combined with an independently processed
date range, it implies a search for worklist entries within a limited
range over multiple successive days. This was judged to be
non-intuitive and an unlikely use case, whereas searching for a
starting time on a starting date through to a finishing time on a
finishing date was considered to be a truly useful query.

For the case where you have a scalar/single value for the date and a
time range, you should search for all entries whose scheduled time lies
between:

Date@Starting Time through the time Date@Ending Time -- i.e find
entries where scheduled datetime is greater than the specified Date+
specified Start time and less than the specific Date+ Specified End
time.

Thanks for your reply, Eric. That does clear it up for me except for
the "unlikely" (but still possible ?) usage scenario where a user
supplies a single time (scalar) and a date range? Should I then simply
ignore the time provided and treat the date range as my matching
criteria?

e.g
Date Range = "Sep 14 - Sep 16"
Time = "4:00 AM"

Should I match for

"Sep 14 4:00 AM - Sep 16 4:00 AM"

or

"Sep 14 12:00 AM - Sep 16 11:59:59 PM"

Thanks for the help.

Sai

hi

I am a newbie too so i am not answering your issue,but i want you to
help me out with some of the issues.

I want to create a MWL which connects to RIS system and
MODALITY(CT,CR),

I need some light on issues like,

1)how will Modality queries the MWL and what it usually queries.

2)When MWL will get the Hl7 message from RIS i,e weather on patient
admission?

because i am currently sending SIU S12 type of message that is
created upon patient registration and this message does'nt have
segments like ORM ,OCR,ORB (this kind of message i saw in an example
message) .

In other words i want you to tell me the setup b/w RIS and MWL and
example message.

3)Modality and MWl ::now i suppose MWL is an scp i want to know what
it actually sends to the Modality for what kind of request.

In otherwords simple setup b/w Modality and MWL with some example
message.

I hope you will find time to answer my issues.

Thanks in adwance.

swamy.















sai.ramani@gmail.com wrote:
> Thanks for your reply, Eric. That does clear it up for me except for
> the "unlikely" (but still possible ?) usage scenario where a user
> supplies a single time (scalar) and a date range? Should I then simply
> ignore the time provided and treat the date range as my matching
> criteria?
>
> e.g
> Date Range = "Sep 14 - Sep 16"
> Time = "4:00 AM"
>
> Should I match for
>
> "Sep 14 4:00 AM - Sep 16 4:00 AM"
>
> or
>
> "Sep 14 12:00 AM - Sep 16 11:59:59 PM"
>
> Thanks for the help.
>
> Sai

hi

I am a newbie too so i am not answering your issue,but i want you to
help me out with some of the issues.

I want to create a MWL which connects to RIS system and
MODALITY(CT,CR),

I need some light on issues like,

1)how will Modality queries the MWL and what it usually queries.

2)When MWL will get the Hl7 message from RIS i,e weather on patient
admission?

because i am currently sending SIU S12 type of message that is
created upon patient registration and this message does'nt have
segments like ORM ,OCR,ORB (this kind of message i saw in an example
message) .

In other words i want you to tell me the setup b/w RIS and MWL and
example message.

3)Modality and MWl ::now i suppose MWL is an scp i want to know what
it actually sends to the Modality for what kind of request.

In otherwords simple setup b/w Modality and MWL with some example
message.

I hope you will find time to answer my issues.

Thanks in adwance.

swamy.















sai.ramani@gmail.com wrote:
> Thanks for your reply, Eric. That does clear it up for me except for
> the "unlikely" (but still possible ?) usage scenario where a user
> supplies a single time (scalar) and a date range? Should I then simply
> ignore the time provided and treat the date range as my matching
> criteria?
>
> e.g
> Date Range = "Sep 14 - Sep 16"
> Time = "4:00 AM"
>
> Should I match for
>
> "Sep 14 4:00 AM - Sep 16 4:00 AM"
>
> or
>
> "Sep 14 12:00 AM - Sep 16 11:59:59 PM"
>
> Thanks for the help.
>
> Sai

sai.ramani@gmail.com wrote:
> Thanks for your reply, Eric. That does clear it up for me except for
> the "unlikely" (but still possible ?) usage scenario where a user
> supplies a single time (scalar) and a date range? Should I then simply
> ignore the time provided and treat the date range as my matching
> criteria?
>
> e.g
> Date Range = "Sep 14 - Sep 16"
> Time = "4:00 AM"
>
> Should I match for
>
> "Sep 14 4:00 AM - Sep 16 4:00 AM"
>
> or
>
> "Sep 14 12:00 AM - Sep 16 11:59:59 PM"
>

Ah, missed that Q in your first posting. The "special logic" for
handling the date and time is specified in DICOM part 4, Table K.6-1
in the cell under Scheduled Procedure Step Time. It indicates the
special logic is invoked when range matching is specified for BOTH date
and time. In essence, the special logic requires the SCP to use
starting values and end values of the two attributes as DateTime VRs
and do range matching for Scheduled Steps date and times as if they
were also single DateTime values.

Your question is a good one since it is range matching on the Scheduled
Date which is in fact causing the SCP to have to search for multiple
discontiguous date/time ranges. On the other hand, if the time
attribute is single value, it is basically defining a list of discrete
DateTime values to be checked for an exact match on successive days.

According to the way the standard is written now you should treat date
range, single time as a list of discrete values (Specific time on range
of days)

It is a good question as to whether that is a realistic use case. What
you seem to be suggesting is that specification of range matching in
only the Scheduled Date attribute should be sufficient to cause the SCP
to do DateTime range matching rather than discrete single value
matching -ie automatically promote the single value Scheduled Time to a
Time Range.

Personally, I believe that is a more realistic use case than doing
exact value matching on a list of discrete time values. But I could be
off base on that opinion. One could easily argue there is a use case
for a user trying to find an appointment known to be around a certain
time, but but uncertain about the date. Most SCPs are going to have
some level of fuzzy logic for time matching anyway (because of the
imprecision of the match key value). Retaining the separate handling of
date and time for date range but single time supports both the discrete
query model and the contiguous model, depending on whether range is
specified in the time.

I suggest this is probably a good subject for a correction proposal. It
would be worthwhile to see the modality vendors' feedback on the
behavior they would expect/anticipate in their application user
interface for a date range, but single value time.

Thanks, Eric.

eric.goodall@gmail.com wrote:
> sai.ramani@gmail.com wrote:
> > Thanks for your reply, Eric. That does clear it up for me except for
> > the "unlikely" (but still possible ?) usage scenario where a user
> > supplies a single time (scalar) and a date range? Should I then simply
> > ignore the time provided and treat the date range as my matching
> > criteria?
> >
> > e.g
> > Date Range = "Sep 14 - Sep 16"
> > Time = "4:00 AM"
> >
> > Should I match for
> >
> > "Sep 14 4:00 AM - Sep 16 4:00 AM"
> >
> > or
> >
> > "Sep 14 12:00 AM - Sep 16 11:59:59 PM"
> >
>
> Ah, missed that Q in your first posting. The "special logic" for
> handling the date and time is specified in DICOM part 4, Table K.6-1
> in the cell under Scheduled Procedure Step Time. It indicates the
> special logic is invoked when range matching is specified for BOTH date
> and time. In essence, the special logic requires the SCP to use
> starting values and end values of the two attributes as DateTime VRs
> and do range matching for Scheduled Steps date and times as if they
> were also single DateTime values.
>
> Your question is a good one since it is range matching on the Scheduled
> Date which is in fact causing the SCP to have to search for multiple
> discontiguous date/time ranges. On the other hand, if the time
> attribute is single value, it is basically defining a list of discrete
> DateTime values to be checked for an exact match on successive days.
>
> According to the way the standard is written now you should treat date
> range, single time as a list of discrete values (Specific time on range
> of days)
>
> It is a good question as to whether that is a realistic use case. What
> you seem to be suggesting is that specification of range matching in
> only the Scheduled Date attribute should be sufficient to cause the SCP
> to do DateTime range matching rather than discrete single value
> matching -ie automatically promote the single value Scheduled Time to a
> Time Range.
>
> Personally, I believe that is a more realistic use case than doing
> exact value matching on a list of discrete time values. But I could be
> off base on that opinion. One could easily argue there is a use case
> for a user trying to find an appointment known to be around a certain
> time, but but uncertain about the date. Most SCPs are going to have
> some level of fuzzy logic for time matching anyway (because of the
> imprecision of the match key value). Retaining the separate handling of
> date and time for date range but single time supports both the discrete
> query model and the contiguous model, depending on whether range is
> specified in the time.
>
> I suggest this is probably a good subject for a correction proposal. It
> would be worthwhile to see the modality vendors' feedback on the
> behavior they would expect/anticipate in their application user
> interface for a date range, but single value time.

hi

please answer my queries.

sai.ramani@gmail.com wrote:
> Thanks, Eric.
>
> eric.goodall@gmail.com wrote:
> > sai.ramani@gmail.com wrote:
> > > Thanks for your reply, Eric. That does clear it up for me except for
> > > the "unlikely" (but still possible ?) usage scenario where a user
> > > supplies a single time (scalar) and a date range? Should I then simply
> > > ignore the time provided and treat the date range as my matching
> > > criteria?
> > >
> > > e.g
> > > Date Range = "Sep 14 - Sep 16"
> > > Time = "4:00 AM"
> > >
> > > Should I match for
> > >
> > > "Sep 14 4:00 AM - Sep 16 4:00 AM"
> > >
> > > or
> > >
> > > "Sep 14 12:00 AM - Sep 16 11:59:59 PM"
> > >
> >
> > Ah, missed that Q in your first posting. The "special logic" for
> > handling the date and time is specified in DICOM part 4, Table K.6-1
> > in the cell under Scheduled Procedure Step Time. It indicates the
> > special logic is invoked when range matching is specified for BOTH date
> > and time. In essence, the special logic requires the SCP to use
> > starting values and end values of the two attributes as DateTime VRs
> > and do range matching for Scheduled Steps date and times as if they
> > were also single DateTime values.
> >
> > Your question is a good one since it is range matching on the Scheduled
> > Date which is in fact causing the SCP to have to search for multiple
> > discontiguous date/time ranges. On the other hand, if the time
> > attribute is single value, it is basically defining a list of discrete
> > DateTime values to be checked for an exact match on successive days.
> >
> > According to the way the standard is written now you should treat date
> > range, single time as a list of discrete values (Specific time on range
> > of days)
> >
> > It is a good question as to whether that is a realistic use case. What
> > you seem to be suggesting is that specification of range matching in
> > only the Scheduled Date attribute should be sufficient to cause the SCP
> > to do DateTime range matching rather than discrete single value
> > matching -ie automatically promote the single value Scheduled Time to a
> > Time Range.
> >
> > Personally, I believe that is a more realistic use case than doing
> > exact value matching on a list of discrete time values. But I could be
> > off base on that opinion. One could easily argue there is a use case
> > for a user trying to find an appointment known to be around a certain
> > time, but but uncertain about the date. Most SCPs are going to have
> > some level of fuzzy logic for time matching anyway (because of the
> > imprecision of the match key value). Retaining the separate handling of
> > date and time for date range but single time supports both the discrete
> > query model and the contiguous model, depending on whether range is
> > specified in the time.
> >
> > I suggest this is probably a good subject for a correction proposal. It
> > would be worthwhile to see the modality vendors' feedback on the
> > behavior they would expect/anticipate in their application user
> > interface for a date range, but single value time.

Swamy,

It might be a good idea to start a separate thread to get questions
answered. Jumping onto a thread and asking your own questions makes the
thread less valuable to others who search the forums.

One good way to understand how a Modality Worklist works would be to
read the dicom specs. You can download it from David Clunie's website.
http://www.dclunie.com/dicom-status/...seStandard2006

Look in PS 3.4 Annex K (called "Basic Worklist Management Service").
This has a lot of useful information.

My answers (which may be incomplete at best)

1. Modalities use C-Find to issue queries to the Modality Worklist
Broker. There are keys that are required to be used in matching logic,
some conditional matching logic and some optional keys. This list is
defined in detail in the DICOM Standard (Annex K of PS 3.4)

2.The worklist broker (SCP) will have to setup its own way of fetching
information from the RIS. This entirely depends on your business
scenario. Your broker can query the RIS or the RIS can notify the
broker. Really depends on how your customers' environment is. In my
case, there is a separate program that monitors a RIS system. The RIS
system dumps out a notification file whenever an admission or other
such event occurs. I then read this information into our database. When
the modality queries the broker, the broker obtains scheduling/RIS
information from my database.

3. The MWL broker (SCP) will return a dataset with the results of the
C-Find when a modality queries the MWL.

Hope this helps.

Sai

thippeswamy.kn@gmail.com wrote:
> hi
>
> I am a newbie too so i am not answering your issue,but i want you to
> help me out with some of the issues.
>
> I want to create a MWL which connects to RIS system and
> MODALITY(CT,CR),
>
> I need some light on issues like,
>
> 1)how will Modality queries the MWL and what it usually queries.
>
> 2)When MWL will get the Hl7 message from RIS i,e weather on patient
> admission?
>
> because i am currently sending SIU S12 type of message that is
> created upon patient registration and this message does'nt have
> segments like ORM ,OCR,ORB (this kind of message i saw in an example
> message) .
>
> In other words i want you to tell me the setup b/w RIS and MWL and
> example message.
>
> 3)Modality and MWl ::now i suppose MWL is an scp i want to know what
> it actually sends to the Modality for what kind of request.
>
> In otherwords simple setup b/w Modality and MWL with some example
> message.
>
> I hope you will find time to answer my issues.
>
> Thanks in adwance.
>
> swamy.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> sai.ramani@gmail.com wrote:
> > Thanks for your reply, Eric. That does clear it up for me except for
> > the "unlikely" (but still possible ?) usage scenario where a user
> > supplies a single time (scalar) and a date range? Should I then simply
> > ignore the time provided and treat the date range as my matching
> > criteria?
> >
> > e.g
> > Date Range = "Sep 14 - Sep 16"
> > Time = "4:00 AM"
> >
> > Should I match for
> >
> > "Sep 14 4:00 AM - Sep 16 4:00 AM"
> >
> > or
> >
> > "Sep 14 12:00 AM - Sep 16 11:59:59 PM"
> >
> > Thanks for the help.
> >
> > Sai