I don't think I"m going to get the answer I want but I figured I would ask before giving up with GDCM.
I've built a tool using the GDCM library to do some Query/Retrieve on our local PACS. During testing, everything worked fine, but now that I've deployed it, we have one major issue.
When C-Move is transferring a study (with multiple series) and comes upon a series with a document or a report (IE patient protocol, dose report), it stops transferring any more images, even for the other series in the study. Using Wireshark, I can see that the C-Move requests are being sent, but no C-Store transfers are being sent back in return.
This will continue until the next Study, which will transfer normally until it gets to another series that has a document/report. We didn't catch this during early testing because we were testing on select studies that did not contain reports.
Is there a reason why GDCM doesn't play ball with non-images using C-Move? If I can't overcome this limitation of the library easily, is there a way to ignore series with reports, or series with only 1 image (which is how scout images and reports are stored and neither are necessary for me). Do I need to change the DCMTK library instead for my Q/R tool?
Cheers,
Shensmobile
Well to begin with:
Your question needs some more information. I will still try to answer with obvious reasons.
I never used GDCM. I will answer in context of DICOM.
GDCM is: QR SCU and CStore SCP.
PACS is: QR SCP and CStore SCU.
If above is reverse, it does not change the answer much, just reverse the roles.
I do not think problem is with your PACS or GDCM. I think the problem is while Association part of MOVE request.
Your CStore SCP does not support those SOP class because:
Simply, it does not support those at all.
May be you need to configure it to add the support. I do not know what to do here. I neither know GDCM nor your PACS. You need to figure this out yourself.
Those are not proposed by SCU at all.
Configure your SCU to propose those classes.
Those are proposed by SCU but not accepted by SCP.
Check why SCP is rejecting those classes in Associate Response. I strongly suspect this is the problem. Most probably, your CStore SCP is not configured to accept instances with those SOP classes.
Those are accepted by SCP but on CStore Request, instances are being rejected for some reason.
Why, I do not know. You may need to check your logs and configurations.
Please understand that most of the problems in DICOM network communication lies in Association part. Focus your debugging there.
What I can say for sure is that, this problem is not related to C-Find or C-Move Requests/Responses. This problem is related to C-Store operation and its Association part.
Please read following excellent articles from Roni:
http://dicomiseasy.blogspot.com/2012/01/dicom-queryretrieve-part-i.html
http://dicomiseasy.blogspot.com/2012/02/c-move.html
Using Wireshark, I can see that the C-Move requests are being sent, but no C-Store transfers are being sent back in return.
Assuming your are moving a Study, MOVE request is sent once to initiate MOVE operation. Then, MOVE SCP will become CStore SCU and will initiate another Association with CStore SCP. CStore SCP can be different from original MOVE SCU; but I do not think this is the case in your scenario. Then for each (optionally; do not rely on this. Read Roni's articles mentioned below) CStore operation, MOVE response is communicated. You did not mention about MOVE responses in your question.
Is there a reason why GDCM doesn't play ball with non-images using C-Move?
I do not think this is about "non-image" as mentioned above; but cannot bypass this possibility all together. May be that CStore SCP is accepting those SOP classes (incorrectly, even though it does not support those) but reject the instances for some reason (may be non-image instance) while C-Store. You need to check logs and configurations of your CStore SCP here.
If I can't overcome this limitation of the library easily, is there a way to ignore series with reports, or series with only 1 image
You may choose to bypass the Study level retrieve/MOVE and try Series level retrieve. To do this, you first need to fetch list (C-Find) of SeriesInstanceUIDs for that Study. Then MOVE each series independently. In C-Find response, you also get other attributes like image count where you can put your filters for further MOVE operation.
Do I need to change the DCMTK library instead for my Q/R tool?
As I said above, I do not think this problem is with library.
Related
In DICOM, following are the classes defined for C-Find and C-Move at Study Root.
Study Root Query/Retrieve Information Model - FIND: 1.2.840.10008.5.1.4.1.2.2.1
Study Root Query/Retrieve Information Model - MOVE: 1.2.840.10008.5.1.4.1.2.2.2
I have implemented Query Retrieve SCP and SCU in multiple applications. In all those cases, I always implemented both the classes. I do C-Find first to get the list of matching data. Then based on result, I do (automatically or manually) C-Move to get the instances. All those implementations are working fine.
Recently, I am working on one application that combines DICOM with other private protocol to fulfill some specific requirements. It just stuck to my mind if it is possible to directly do C-Move without doing C-Find as SCU?
I already know the identifier (StudyInstanceUID) to retrieve and I also know that it does present on SCP.
I looked into specifications but could not found anything conclusive. I am aware that C-Find and C-Move could be issued by SCU to SCP on different connections/associations. So in first glance, what I am thinking looks possible and legal.
I worked with many third party DICOM applications; none of them implements SCU the way I am thinking. All SCUs implement C-Find AND C-Move both.
Question:
Is it DICOM legal and practical to implement Query Retrieve SCU C-Move command without C-Find command? Please point me to the reference in specifications if possible.
Short answer: Yes this is perfectly legal per DICOM specification.
Long answer: Let's consider the DCMTK reference DICOM Q/R implementation. It provides a set of basic SCU command line tools, namely findscu and movescu. The idea is to pipe the output of findscu to movescu to construct a valid C-MOVE (SCU) request.
In your requirement you are simply replacing the findscu step with a private implementation that does not rely on the publicly defined C-FIND (SCU) protocol but by another mechanism (extension to DICOM).
So yes your C-MOVE (SCU) implementation is perfectly valid, since there is no requirement to provide C-FIND (SCU) during this query.
I understand you are not trying to backup an entire database using C-MOVE (SCU), that was just a possible scenario where someone would be trying to use C-MOVE (SCU) without first querying with a valid C-FIND (SCU) result.
I planned to implement a Storage Commitment Service to verify if files previously sent to the storage were safely stored.
My architecture is very simple and straightforward my SCU sends some secondary capture images to the storage and I want to be sure they are safely stored before delete them.
I am going to adopt push model and I wonder what steps/features I need to implement to accomplish the service
What I understood is
I need to issue a N-ACTION request with SOP Class UID
1.2.840.10008.1.20.1 and add to the request a transaction identifier together with a list of Referenced SOP Class UID – Referenced SOP
Instance UID where Referenced SOP Instance UID are the UIDs of the
secondary capture images I previously sent to the storage and
Referenced SOP Class UID in my case is the soap class identifier
representing the Secondary Capture Image
Wait for my N-ACTION response to see if the N-ACTION request succeed
or not
Get the response from the storage in form of N-EVENT-REPORT
But when? How the storage give me back the
N-EVENT-REPORT along with the results? Does my SCP AE implements some
SCP features? Or I need to issue a N-EVENT request to get a
N-EVENT-REPORT?
Have a look at the image below copied from here:
Now, about your question, following is the explanation assuming same association will be used for entire communication. For communication over multiple associations, refer above article from Roni.
But when?
Immediately. On same connection/association. On receiving NAction response, you should wait for timeout configured in your application. Before timeout expires, you should get the NEventReport.
How the storage give me back the N-EVENT-REPORT along with the results?
When you receive NAction response from SCP, that means SCP saying "Ok; I understood what you want. Now wait while I fetch your data...". So, you wait. When SCP is ready with all the data (check list) necessary, it just sends it back on same association through NEventReport. You parse the Report and do your stuff and send response to SCP saying "Fine; I am done with you." and close the association.
Does my SCP AE implements some SCP features?
No (in most of the cases); you do not need to implement any SCP features in both (single association/multiple associations) cases. You should get NEventReport on same association as mentioned above. DICOM works on TCPIP. Client/Server concept in TCP is only limited to who establishes the connection and who listens for connections. Once the connection is established, any one can read/write data on socket.
In rare cases, SCP sends NEventReport by initiating new association on its own. In that case, SCU need to implement SCP features. This model is not in use as far as I am aware. It is difficult to implement this model for both SCP and SCU. It also needs multiple configurations which everyone tends to avoid. So, this could be neglected. I am calling this rare because I never (at least so far) come across such implementation. But yes; this is valid case for valid reason.
Or I need to issue a N-EVENT request to get a N-EVENT-REPORT?
No; as said above. Refer this.
J.3.3 Notifications
The DICOM AEs that claim conformance to this SOP Class as an SCP shall invoke the N-EVENT-REPORT request. The DICOM AEs that claim conformance to this SOP Class as an SCU shall be capable of receiving the N-EVENT-REPORT request.
That said, SCU should be able to process NEventReport. It will NOT issue it.
There are three different sequences of events possible. I could describe them here, but this article is really excellent: Roni's DICOM blog
I have nothing to add to what is written there.
I’m a complete newbie at BizTalk and I need to create a BizTalk 2006 application which broadcasts messages in a specific way. I’m not asking for a complete solution, but for advise and guidelines, which capabilities of BizTalk I should use.
There’s a message source, for simplicity, say, a directory where the user adds files to publish them. There are several subscribers, each having a directory to receive published files. The number of subscribers can vary in the course of exploitation of the program. There are also some rules which determine if a particular subscriber needs to receive a particular file, based on the filename. For example, each subscriber has a pattern or mask of filename which files they receives must match. Those rules (for example, patterns) can change in time as well.
I don’t know how to do this. Create a set of send ports at runtime, each for each destination? Is it possible? Use one port changing its binding? Would it work correctly with concurrent sendings? Are there other ways?
EDIT
I realized my question may be to obscure and general to prefer one answer over another to accept. So I just upvoted them.
You could look at using dynamic send ports to achieve this - if your subscribers are truly dynamic. This introduces a bit of complexity since you'll need to use an orchestration to configure the send port's properties based on your rules.
If you can, try and remove the complexity. If you know that you don't need to be truly dynamic when adding subscribers (i.e. a subscriber and it's rules can be configured one time only) and you have a manageable number of subscribers then I would suggest configuring each subscriber using it's own send port and use a filter to create subscriptions based on message context properties. The beauty of this approach is that you don't need to create and deploy an orchestration and this becomes a highly performant and scalable solution.
If the changes to the destination are going to be frequent, you are right in seeking a more dynamic solution. One nice solution is using dynamic send ports and the Business Rules Engine. You create rule set for the messages you are receving. This could be based on a destination property or customer ID in the message. Using these facts, the rules engine can return a bunch of information like file mask, server name, ip address of deleiver server, etc. You can thenuse this information to configure the dynamic send in the orchestration. The real nice thing here is that you can update the rule set in the rules engine without redeploying the whole solution. As a newb, these are some advanced concepts, but not as diificult as you may think.
For a simpler solution, you might want to look at setting the FILE Send adapters properties via it's Propery Schema (ie. File name, Directory, etc.). You could pull these values from a database with a helper class inside an expresison shape. On each message ogig out, use the property shcema to set where the message will be sent and named. This way, you just update the database as things change.
Good Luck!
In Blackberry application I want to check what type of network connection is being used on particular phone, whether it is BES/MDS,BIS-B or Direct Tcp.
Is there any way to find out this?
Many applications like Jive,Opera and many more are doing this kind of check.
Please help.
The question is quite logical and I do agree with Richard as well. Though a better answer lies in the fact that there can be a logic developed which would involve Service Book parsing and making use of system listeners to check the current coverage status.
I had attempted to make one such logic once in my project which worked for me. I had shared my findings and understanding about the concept in more detail at my blog post. May be you would like to check once.
You can find my blog post here.
Your question springs from an incorrect assumption. A Blackberry could be communicating over any or all of those channels simultaneously. In fact any application may as well. At any particular time you can determine if coverage is sufficient for one of those channels, or register a listener for notification of changing status using net.rim.device.api.system.CoverageInfo.
Recently, I've been reading up on the IRC protocol (RFCs 1459, 2810-2813), and I was thinking of implementing my own server.
I'm not necessarily looking into adhering religiously to the IRC protocol (I'm doing this for fun, after all), but one of the things I do like about it is that a network can consist of multiple servers transparently.
There are a number of things I don't like about the protocol or the IRC specification. The first is that nicknames aren't owned. While services like NickServ exist, they're not part of the official protocol. On the other hand, implementing something like NickServ properly kind of defeats the purpose of distribution (i.e. there'd be one place where NickServ is running, and one data store for it).
I was hoping there'd be a way to manage nicknames on a per-server basis. The problem with this is that if you have two servers that have some registered nicknames, and they then link up, you can have collisions.
Is there a way to avoid this, without using one central data store? That is: is it possible to keep the servers loosely connected (such that they each exist as an independent entity, but can also connect to one another) and maintain uniqueness amongst nicknames?
I realize this question is vague, but I can't think of a better way of wording it. I'm looking more for suggestions than I am for actual yes/no answers. So if anyone has any ideas as to how to accomplish nickname uniqueness in a network while still maintaining server independence, I'd be interested in hearing it. Note that adhering strictly to the IRC protocol isn't at all necessary; I've got no problem changing things to suit my purposes. :)
There's a simple solution if you don't care about strictly implementing an IRC server, but rather implementing a distributed message system that's like IRC, but not exactly IRC.
The simple solution is to use nicknames in the form "nick#host", much like email. So instead of merely being "mipadi", my nickname could be "mipadi#free-memorys-server.net". So I register with just your server, but when your server links up with others to form another a big ole' chat network, you can easily union all the usernames together. There might be a "mipadi" on otherserver.net, but then our nicknames become "mipadi#free-memorys-server.net" and "mipadi#otherserver.net", and everything is cool.
Of course, this deviates a good deal from IRC. :)
They have to be aware of each other. If not, you cannot prevent the sharing of nicknames. If they are, you simply need to transfer updates on the back-end. To prevent simultaneous registrations, you need a transaction system that blocks, requests permission from all other servers, and responds.
To prevent simultaneous registrations during outages, you have no choice but to timestamp the registration, and remove all but the last (or a random for truly simultaneous) registered copy of the nick.
It's not very pretty considering these servers aren't initially merged in the first place.
You could still implement nick ownership without a central instance, if your server instances trust each other.
When a user registers a nick, it is registered with the current server he's connected with
When a server receives a registration that it didn't know of, it forwards that information to all other servers that don't know it yet (might need a smart algorithm to avoid spamming the network)
When a server re-connects to another server then it tries to synchronize the list of registered nicks and which server handles which nick
If there is a collision during that sync, then the older registration is used, and the newer one marked as invalid
If you can't trust your servers, then it'll get a lot harder, as a servers could easily claim every username and even claim the oldest registration for each one.
Since you are trying to come up with something new, the idea that springs to mind, is simply including something unique about the server as part of the nick name when communicating outside of the server. So if you want to message a user on a different server you might have something like user#server
If you don't need them to be completely separate you might want to consider creating some kind of multiple-master replicated database of accounts. Where each server stores a complete copy of the account database, and each server can create new accounts which will be replicated to other servers as possible. You'll probably still have to deal with collisions on occasion though.
While services like NickServ exist, they're not part of the official protocol.
Services are not part of the official protocol because they've nothing to do with the protocol. They're bots with permissions. There's no reason why you couldn't have one running on each server but it does make them harder to maintain.
If you were to go down that path, I would probably suggest the commonly used "multiple master" database replication technique. If one receives a write (in your case, a new user is created or updated, etc) it sends the data to all the other nodes. You'll have to be careful though. If one node is offline when the others get an update, it will need to know to resync on reconnection.
Another technique would be as above but in reverse. Data is only exchanged between nodes when it's needed. Eg if a user tries to log in on a node where there's no data for it, it'll query the others and issue a move order to get all the data to that one node. This is potentially less painful than the replication version but there could be severe problems in netsplits if somebody signs up on a node disconnected from the pack for a duplicate nick.
One technique to nullify the problems of netsplits would be to make chat nodes and their bots netsplit-aware. When they're split, they probably shouldn't allow any write actions... But this could impact on your network if you're splitting lots.
You've also got to ask how secure this might or might not be. IRC network nodes are distributed for performance but they're not "secure". Because of this, service bots are usually run centrally to keep ultimate control over their running. If you distributed the bots and remote node got hacked, they'd potentially have access to the whole user database (depending on the model).