I wonder if it is possible to have two different images with the same header. If so, can we display this two images in the PACS or otherwise which tags should be changed to display them?
No you can't. The issue is that Dicom requires every image to have it's own Unique UID stored in the header.
PACS systems commonly ignore newly received images if their UID is identical to one they already have in the database, so if you don't follow this part of the standard you probably don't get very far.
If you want to generate DICOM images, and you are unfamiliar with the standard, my advice is to use OFFIS img2dcm or a similar tool to convert them from normal images.
Jan de Vaan is correct, you SHOULDNT have duplicate headers with different image bitmaps and that is 'guaranteed' by the unique SOP instance UID. I've never seen a duplicate UID come from any modality. Saying that, there are sloppy applications with terrible UID implementations to generate the unique UID. There are teleradiology apps, secondary capture devices and other open source DICOM packages (for instance) that, typically on reset, could and do create a repeatable UID sequence. Many research labs get along fine with these. I expect you have one of these applications up the pipeline back to the source modality. If its messing up something as fundamental to DICOM as the UID, I would wonder what other wonderful things are happening.
If you must get these into the PACS, you would have to change the SOP Instance UID, which is not a recommended practice.
Related
I am writing an app where there is not a lot of interaction with other users. Set and retrieve your own data only.
In Firebase Firestore how could I model this so that everything fits under a users UID?
Something that would look like this?
users/{uid}/user/
users/{uid}/settings/
users/{uid}/weather/
If I want to achieve something like this, then I need to create another UID:
users/{uid}/user/{uid}/{userInfo}
This feels a bit off to me.
Is this wrong? Would it be better if I moved every subcollection into its own collection?
Is this faster / more efficient?
Any help is appreciated!
The most common approaches for me:
Store the profile information, settings and weather in the user document (your {uid}) itself. This most common for the profile information, but it's always worth considering for other types too: do they really need to be in their own documents?
Have a default name for a single subcollection for each user, and then have each information type as a document with a known name in there. So /users/$uid/documents/profile, /users/$uid/documents/settings, and /users/$uid/documents/weather. So now each information type is in a separate document, meaning you can for example secure access to them individually.
If the information for a certain type is repeated, I'd put that in documents in a known/named subcollection. So if there are many weathers, you'd get /users/$uid/weather/$weatherdocs. So with this you can now have an endless set of the specific type of information.
Neither of these is pertinently better/worse, as it all depends on the use-cases of your app.
There will be performance differences between these approaches, as they require a different number of network requests. If this is a concern for your app, I'd recommend testing all approaches above to measure their relative performance against your requirements.
The title is probably poorly worded, but I'm trying my hand at creating a REST api with symfony. I've studied a few public api's to get a feel for it, and a common principle seems to be dealing with a single resource path at a time. However, the data I'm working with has a lot of levels (7-8), and each level is only guaranteed to be unique under its parent (the whole path makes a composite key).
In this structure, I'd like to get all children resources from all or several parents. I know about filtering data using the queryParam at the end of a URI, but it seems like specifying the parent id(s) as an array is better.
As an example, let's say I have companies in my database, which own routers, which delegate traffic for some number of devices. The REST URI to get all devices for a router might look like this:
/devices/company/:c_id/routers/:r_id/getdevices
but then the user has to crawl through all :r_id's to get all the devices for a company. Some suggestions I've seen all involve moving the :r_id out of the path and using it in the the query string:
/devices/company/:c_id/getdevices?router_id[]=1&router_id[]=2
I get it, but I wouldn't want to use it at that point.
Instead, what seems functionally better, yet philosophically questionable, is doing this:
/devices/company/:c_id/routers/:[r_ids]/getdevices
Where [r_ids] is a stringified array of ids that can be decoded into an array of integers/strings server-side. This also frees up the query-parameter string to focus on filtering devices by attributes (age, price, total traffic, status).
However, I am new to all of this and having trouble finding what is "standard". Is this a reasonable solution?
I'll add I've tested the array string out in Symfony and it works great. But I can't tell if it can become a vehicle for malicious queries since I intend on using Doctrine's DBAL - I'll take tips on that too (although it seems like a problem regardless for string id's)
However, I am new to all of this and having trouble finding what is "standard". Is this a reasonable solution?
TL;DR: yes, it's fine.
You would probably see an identifier like that described using a level 4 URI Template, with your list of identifiers encoded via a path segment expansion.
Your example template might look something like:
/devices/company{/c_id}/routers{/r_ids}/devices
And you would need to communicate to the template consumer that c_id is a company id, and r_ids is a list of router identifiers, or whatever.
You've seen simplified versions of this on the web: URI templates are generalizations of web forms that read information from input controls and encode the inputs into the query string.
I need to create a Secondary Capture Image representing a report related to radiopharmaceutical and dose injected to the patient during the medical examination.
I know Secondary Capture Image is not the right choice to accomplish the task but that is what the customer requires.
Following are the steps I thought to implement for developing the feature and I would like to read some opinions or suggestion from the community.
Assumption: MWL is implemented and the Study Instance UID is generated in the RIS
query the MWL (C-FIND) to get the requested procedure object
parse the result to get the StudyInstanceUID and patient related
informations (name, sex, birthdate etc.)
query (C –FIND) the modality looking for the specific Study
Instance UID
parse the result to get the Series Instance UID
create the image setting the three mandatory attribute Study
Instance UID, Series Instance UID, Modality (together with some type
2 attributes I got querying MWL and modality in the previous
steps)
C-STORE to persist the image to the storage archive
Commit of the image (do I really need?)
I really appreciate comments opinions or someone that can address me to a more solid architecture.
correct
correct. Do not forget about attributes that are not so obvious like Admission ID, Accession Number, Referring Physicians Name and others.
The majority of modalities does not support Query/Retrieve as an SCP. If you would really need to query for the images, send the C-FIND to the PACS rather than the modality. The Study Instance UID comes with the worklist. Even if the UID you find by Query differs from that, I would strongly recommend to use the one from the worklist. However, I do not see any sense in using attributes from other sources than the MWL and your own "acquisition".
Why would you want to add the image to an existing series? It would probably be more appropriate to create a new one. There are a lot of reasons for that, e.g. Modality and vendor/equipment information are series level information and probably different.
There are more mandatory attributes for SC (e.g. in the general image module). Not all come from the MWL.
yes.
You do not have to. However, suppose that your images are lost:
a) you have received a storage commitment from the PACS -> blame on the PACS
b) you have not received a storage commitment from the PACS -> blame on ...? ;-)
How good/stupid would it be to use Firebase tree structure to directly represent a user-facing tree structure, like a "document outline" in "word processors"?
As opposed to e.g. doing an SQL-join parent-child type of relationship and then building the tree via a projection (which would probably be slow).
I know that there is a limit of 32 levels of nesting ( https://www.firebase.com/docs/web/guide/understanding-data.html ), which should be enough, as I cannot imagine a sane user wanting to do as many levels of nesting for a textual tree-outline...
Although maybe I need to divide 32 by two, because of each node needing to have sub nodes for its children and metadata, right?
I know that once a tree node is accessed via Firebase API, then all sub-nodes need to be fetched, which could be a performance problem if the user has a lot of data, but in the end I think this would not be a problem, since the data would mostly be a user-entered plaintext (short).
A performance problem could arise if the user pastes some very long chunks of text copied from somewhere (e.g. tens of kilobytes). But then I could separate those "TLOB-s" via a kind of "symlink" in firebase and fetch them on-demand from a different node, right? Same should apply for separating images and other heavy objects, right?
Although in a prototype and early stages, this should probably be ignored, for the sake of simplicity...
I could probably put in place a generic approach to "symlinking", to overcome the 32 levels limitation and the need to fetch all sub-nodes at once, right? Is there some best-practices approach for that (e.g. syntax for a firebase node which would symbolise a link to another node) ?
I have extracted the "symlinking" idea to a separate question: Firebase "symlink" to another node .
I could probably partition the topmost nodes into some kinds of projects/categories to prevent having to fetch absolutely everything the user has ever had...
Is my reasoning/approach correct?
Is there any consideration that I did not think of, e.g. innate limits on data size or performance or e.g. security rules?
Would I be better served by other technologies like Couchbase/Pouchbase ?
Further details: this is for a hybrid mobile app with some emphasis also on web access and offline access. I hope to do most of the logic in Javascript. The UI part of the question is here: HTML tree for hybrid mobile app .
I've built an ASP.NET page whose output stream is a dynamically-generated PNG image containing only text on a transparent background.
The text is based upon database IDs contained in the querystring. There will be a limited number of variations.
Which one of the following would be the most efficient means of returning the image to the client?
Store each variation upon the first generation, and thenceforth retrieve this from the drive.
Simply generate the image each time.
Cache the output response based upon the querystring.
Totally depends on how often this image is going to have to be generated.
If it's a small project I would elect to generate it each time as this would be the simplest solution.
If you are expecting a lot of generations then storing the image each time it's generated and checking for pre generated images would be next, it gets a bit complicated though, all depends on how many unique variations of images you expect to be generated, if it is small, go for it, otherwise you may have to have expiry dates on the images that are not so frequently accessed.
In short, it depends on what the application of this is, and not enough information was given to give a comprehensive answer to your specific solution.