For creating an anonymization/de-identification tool I would like to delete/overwrite all tags/attributes from the DICOM file that are not necessary. I've searched around the internet, but have not found a clear list of which tags are mandatory for a DICOM file.
I found out that there are multiple types, type 1 is mandatory, type 2 must at least be an empty string and type 3 can just be deleted. But so far I have not found an easy list online with all tags and their types. Does anyone have list of tags and types or a list of mandatory tags for DICOM file?
The mandatory attributes (given by their tags) depend on the SOP Class of the DICOM file.
read the Media Storage SOP Class UID (0002,0002) from the File Meta Information (meta header)
in the DICOM standard, locate the IOD correspondent to the SOP Class UID (e.g. "1.2.840.10008.5.1.4.1.1.1" = Computed Radiography Image Storage)
the IOD specification lists the mandatory and optional modules (e.g. Patient Module, General Image Module, etc). The modules marked with M are mandatory, C=conditional, U=optional (user option)
each module lists the mandatory and optional attributes (e.g. the Patient module includes the patient name, the patient ID, sex, etc). Attributes marked with 1 are mandatory, 2=mandatory but can be empty, 3=optional, 1C=mandatory if some conditions are satisfied, 2C=mandatory but can be empty if some conditions are satisfied
There is a nice Presentation about "De-Identification" by David Clunie here: https://www.dclunie.com/papers/D2_1045_Clunie_Deidentification.pdf
The concepts presented went into the DICOM Standard Part 15, Annex E - De-Identification
The current list of attributes to handle for a valid de-identifier is clearly described in the DICOM standard PS 3.15:
Attribute Confidentiality Profiles
In particular see the table:
Table E.1-1. Application Level Confidentiality Profile Attributes
As a side pay special attention to the private tags, as described in the following profile:
Retain Safe Private Option
For historical reference, you should also pay attention that the DICOM standard has greatly changed since the 2008 edition:
ftp://medical.nema.org/medical/dicom/2008/08_15pu.pdf
Some tool (eg. gdcmanon) implements the old section PS 3.15 / E.1 / Basic Application Level Confidentiality Profile (Implementation of E.1.1 De-identify & E.1.2 Re-identify).
Finally, DicomCleaner should give you an idea of what a quality implementation looks like:
How to use DicomCleaner
The original wording of the question: "I would like to delete/overwrite all tags/attributes from the DICOM file that are not necessary" seems to be in conflict with the definition of "de-identification". So either the question is poorly formulated, or you are missing the fact that Type 1 attribute may contain Protected Health Information.
Related
I want to know the meaning of the exten, which is one member of the structure ngx_http_request_t, also, ngx_http_set_exten hopes to be excavated.
I believe that it means file extension, being the part of the final path element that follows a period. It is used to lookup the MIME type in the types data structure, to be used in the response.
Relevant code is here. Line 1701.
How could I understand this record:
Accept: application/vnd.my.api+json
I mean, is this "+" symbol is standartized (anyway, I have not find it in spec), or it is just a convention?
Thanks.
The Accept header specifies a list of acceptable media types.
The "+xxx" part of the media type is called suffix. It is an augmentation to the media type definition and helps to specify the underlying structure of that media type.
RFC 6838, "4.2.8. Structured Syntax Name Suffixes" defines:
XML in MIME [RFC3023] defined the first such augmentation to the
media type definition to additionally specify the underlying
structure of that media type. To quote:
This document also standardizes a convention (using the suffix
'+xml') for naming media types ... when those media types
represent XML MIME (Multipurpose Internet Mail Extensions)
entities.
That is, it specified a suffix (in that case, "+xml") to be
appended to the base subtype name.
Since this was published, the de facto practice has arisen for
using this suffix convention for other well-known structuring
syntaxes. In particular, media types have been registered with
suffixes such as "+der", "+fastinfoset", and "+json". This
specification formalizes this practice and sets up a registry for
structured type name suffixes.
The primary guideline for whether a structured type name suffix is
registrable is that it be described by a readily available
description, preferably within a document published by an established
standards-related organization, and for which there's a reference
that can be used in a Normative References section of an RFC.
Media types that make use of a named structured syntax SHOULD use
the appropriate registered "+suffix" for that structured syntax
when they are registered. By the same token, media types MUST NOT
be given names incorporating suffixes for structured syntaxes they
do not actually employ. "+suffix" constructs for as-yet
unregistered structured syntaxes SHOULD NOT be used, given the
possibility of conflicts with future suffix definitions.
I have two questions when I am reading the
DICOM standard:
In a DICOM file, (0002 0003)"Media Storage SOP Instance UID" and
(0008 0018) "SOP Instance UID", are they the same? What about (0002
0002) and (0008 0016)? and Why ??
Chris is correct, they are the same. From the dicom standard section C.12.1.1.1:
The SOP Class UID and SOP Instance UID Attributes are defined for all
DICOM IODs. However, they are only encoded in Composite IODs with the
Type equal to 1. See Section C.1.2.3. When encoded they shall be equal
to their respective Attributes in the DIMSE Services and the File Meta
Information header (see PS3.10 Media Storage).
As to the reason why these items are duplicated, I can only speculate, but the File Meta Information Header only exists in dicom files (it is not transmitted by an SCP/SCU). When an SCP writes a file from the DICOM data it receives, it has to get the SOP class and instance UIDs from the dataset, so that is the mechanical reason they are the same. As to why these tags and not some others, I am sure there are many reasons, but note that the File Meta Information Header is always readable by any dicom entity as it is always "Little Endian Explicit" even if the following dataset is some weird transfer syntax. So these two fields are always guaranteed to be readable and usable in any valid dicom file (even if the group 8 versions are in an unreadable transfer syntax).
I also tried to look up the condition:
However, they are only encoded in Composite IODs
Almost every IOD is a Composite IOD when I look at the standard:
Normalized IODs
Composite IODs
Yes they are the same. Tags with group 0002 are part of the DICOM P10 header, I assume they are duplicated so they can be quickly read without having to parse the entire file.
In an RDF file that describes a resource I would like to include a link to a HTML document that provides background information. The document is HTML, not RDF. I have the feeling that this should be made clear, probably with some kind of format specification (like dcterms:format).
My questions are:
What is the best way to link to non-RDF resources (URIs) in Linked
Data / RDF?
Which is the best vocabulary term to use for a
document/resource that provides background information on the
subject?
The general property for providing additional information is rdfs:seeAlso. As the spec says, you can create a sub-property of seeAlso to convey more specific semantics. As for encoding the metadata, personally I'd stick to Dublin Core and I would add a bNode so that the various properties of the external source can be recorded in the triple store.
So, if some_resource is the thing that you have more information about:
example:some_resource
rdfs:seeAlso [
dcTerms:source "http://your.si.te/docs/foo.html"^^xsd:anyURI ;
dcTerms:format "text/html" ;
dcTerms:title "Foo user manual"#en ;
dcTerms:language "en"
].
I need to create and read a user preferences XML file with Adobe Air. It will contain around 30 nodes.
<id>18981</id>
<firstrun>false</firstrun>
<background>green</background>
<username>stacker</username>
...
What's a good method to do this?
Write up an "XML parser" that reads the values and is aware of the data types to convert to based on the "save preferences model." So basically you write a method/class for writing the data from the "save preferences model" to XML then write a method/class for reading from the XML into the "save preferences model", you can use describeType for both. Describe type will return an XML description of the model classes properties and the types of those properties and accessibility (read/write, readonly, write only). For all properties that are read/write you would store them into the XML output, when reading them back in you would do the same thing except you could use the type property from the describeType output to determine if you need to do a string to boolean conversion (if(boolValue == "true")) and string to number conversions, parseInt or parseFloat. You could ultimately store the XML in a local SQL database if you want to keep history, or else just store the current preferences in flat file (using FileReference, or in AIR you can use FileStream to write directly to a location).
Edit:
Agree with Joshua's comment below local shared objects was the first thing I thought of when seeing this, you can eliminate the need to write the XML parser/reader since it will handle serializing/de-serializing the objects for you (but manually looking at the LSO is probably ugly)... anyhow I had done something similar for another project of mine, I tried stripping out the relevant code, to note in my example here I didn't use describe type but the general concept is the same:
http://shaunhusain.com/OnePageSaverLoader/index.php