-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DICOM Private Data Elements in DICOM RDF #145
Comments
The basic idea is that the encoding has to be agnostic to the actual attribute numbers. One unique encoding is the Private Creator identifier. So the attribute number of an entry can be described like this: The actual identification of the attribute would then be the Private Creator, the two digits XX and the UID of the entity that the attribute is assigned to. If there is no knowledge about the actual entity, then the attribute can be assigned to the SOP Instance (e.g. CT Image etc.). A possible encoding might look like this:
Alternatively the {gggg} part could be replaced with a {generated UUID}. And the blank node for the element could be replaced with an actual IRI, for example:
Furthermore one could define a type for the resource of the private creator and its elements:
Which could be further defined in an ontology:
And then one could include additional descriptions of the data elements linked to the private entry. Sample Data 1
|
option: bnode labeldesign goal: Discourage people from inserting the attribute tag directly into SPARQL queries. Sample Data_:0029.0010 dicom:hasPrivateCreatorId extReg:private%20creator%201 .
<X> dicom:extensionElement [
dicom:extensionLabel _:0029.0010 ;
dicom:value 7
] Query UseSELECT ?val WHERE {
?tag dicom:hasPrivateCreatorId extReg:private%20creator%201 .
?x dicom:extensionElement [ dicom:extensionLabel ?tag ; dicom:value ?value ]
} cost:
|
Private Data Elements in DICOM are defined in https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_7.8.html
These elements cannot be simply described by their attribute number, it is necessary to decode the Private Creator first. Private Data Elements with the same attribute number could actually belong to different Private Creators and reference completely different data.
Typically there is no specification available for Private Data Elements, so the VR must be determined from the data. Either the VR is explicitly mentioned or it falls back to UN (Unknown).
For example data could be encoded like this:
in an other DICOM object it would be legal to encode it like this with the same meaning:
The question is how to encode this in RDF so that the data is searchable?
The text was updated successfully, but these errors were encountered: