DICOM INTERNATIONAL CONFERENCE & SEMINAR Oct 9-11, 2010 Rio de Janeiro, Brazil PACS MULTIPURPOSE (clinical and scientific) Jacques Fauquex & Nicolas Martino Opendicom, Uruguay

2 Table of Contents De-identification/Personal data Personal information and purpose of use Laws of protection of Personal data ISO requirements (similar to HIPAA) Habeas Data & liberal de-identification DICOM sup 142 with most liberal options Optimize sup 142 de-identification table in function of the DICOM conformance statements of connected modalities Attributes to remove or nullify Attributes to clean PACS MULTIPURPOSE

3 PACS registry and repositories Made of two information systems Registry minimal structure The registry indexes patient identifiers Repositories without patient identifiers Repository grouping through URLs Workflows Consent registration Private DICOM attributes to simplify consent administration within the PACS Private attribute list At patient arrival 3

4 PACS MULTI-PURPOSES Store SCP Consent Linker triggered at file reception Store SCP attribute repartition On image instance storage Clinical access Re-identification through registry Scientific access to authorized repository only Conclusions 4

De-identification/Personal data

6 Personal information and purpose of use Gathering information about a patient is basic to the medical practice. Binding it to a permanent identifier is perfectly justified for this purpose. The binding is not justified for other purposes, for instance when the doctor wants to communicate the medical information at the university. For an academic purpose, the doctor has the obligation to bring de-identified information only. Moreover, in some countries, the doctor should obtain an explicit authorization from the patient. For instance, in countries with laws for the protection of “personal data” 6

7 De-identification/Personal data Europe and Latin American countries protect Personal data 1981 UE, Alemania, Francia, España 2006 México Uruguay & Argentina refer explicitly to ISO ARGENTINA ISO (27799)

8 De-identification/Personal data ISO requirements (similar to HIPAA) Patient explicit consent required prior to the use of the medical data for any purpose different from medical assistance to the patient. Accession rights justified in function of the purpose for which the patient gave his/her consent. Patient consent always revocable (this concept implies a versioned documentation of consents). 8

9 De-identification/Personal data Habeas Data & liberal de-identification In the Uruguay, consent and de-identification rules are transitive, as precised in law art 17. The doctor should de-identify and use only for a purpose authorized by the patient. When s/he communicates the data to a colleague, the colleague in turn is made as responsible as the doctor. That is, attempts of the colleague to re-identify or use the data for another purpose are illegal too. A strong law of Habeas Data may be sufficient to justify an application of DICOM Sup 142 with liberal options. 9

10 De-identification/Personal data DICOM sup 142 with most liberal options 10 CodeCode Meaning ccccc1Basic Application Confidentiality Profile ccccc2Clean Pixel Data Option ccccc6Clean Descriptors Option ccccc7aRetain Longitudinal With Full Dates Option ccccc8Retain Patient Characteristics Option ccccc9Retain Device Characteristics Option cccc10Retain Device Identity Option cccc11Retain UIDs ccccc12Retain Safe Private Option

11 De-identification/Personal data Optimize sup 142 de-identification table in function of the DICOM conformance statements of connected modalities CUDIM, our test institution, was built around two PET GE and is strictly dedicated to PET. So we can filter sup 142 list of attributes, and discard attributes not used at all by PET GE. GE DICOM conformance statement also informs us of private attributes to wipe out Attribute NameTagTypeVRVM PET patient_id(0009,1002)3LO1 PET patient_id(0009,105f)3LO1

12 De-identification/Personal data Attributes to remove or nullify 12 INTO REGISTRYSUP 142IOD GE PETAttributetag Patient levelYESZRPatient’s Name(0010,0010) YESZRPatient ID(0010,0020) YESZOPatient’s Birth Date(0010,0030) YESX/COther Patient IDs Sequence(0010,1002) NOXOPatient Address(0010,1040) NOXOPatient’s Telephone Number(0010,2154) Study levelYESZOAccession Number(0008,0050) YESZOReferring Physician’s Name(0008,0090) YESZ2Study ID(0020,0010) NOXOAdmission ID(0038,0010) Series levelYESX/Z/DO/value configInstitution Name(0008,0080) YESXORequesting Physician(0032,1032) YESXORequesting Service(0032,1033) YESXRequest Attributes Sequence(0040,0275) YESXORequested Procedure ID(0040,1001) YESX/Z/D3Operators’ Name(0008,1070) NOX3Performed Procedure Step ID(0040,0253) NOX3Performed Procedure Step Description(0040,0254) NOXRScheduled Station AE Title(0040,0001) NOXRScheduled Performing Physician Name(0040,0006) NOXOScheduled Station Name(0040,0010) NOXOScheduled Procedure Step Location(0040,0011) NOXOPatient Transport Arrangements(0040,1004) NOXORequested Procedure Location(0040,1005) NOXOConfidentiality Constraint on Patient Data Description(0040,3001)

13 Accesses, de/re-identification Attributes to clean SUP 142IOD GE PETAttributetag Study levelC3Study Description(0008,1030) CORequested Procedure Description(0032,1060) COPatient State(0038,0500) Series levelC3Series Description(0008,103E) C2Contrast Bolus Agent(0018,0010) C3Protocol Name(0018,1030) COScheduled Procedure Step Description(0040,0007) COPre-Medication(0040,0012) These attribute may remain into the files.

PACS registry and repositories

15 PACS registry and repositories Made of two information systems One or more FILE SYSTEM repository where each DICOM object is stored as an independant file A DATABASE registry receives metadata extracted at DICOM file reception into a relational schema adapted from the DICOM object model : INSTANCE table SERIES table STUDY table (PATIENT table) 15

16 PACS registry and repositories Registry minimal structure The INSTANCE table includes: an URL to the corresponding file in the repository metadata specific to the instance (that is with some variability between instances of a same series). a pointer to one and only one entity of the SERIES table The SERIES table includes metadata specific to the series a pointer to one and only one entity of the STUDY table The STUDY table includes metadata specfic to the study metadata specific to the patient 16

17 PACS registry and repositories The registry indexes patient identifiers contains all the identifiers is where IHE Patient Identity Reconciliation” (PIR) integration profile may modifiy erroneous identifiers. provides a filtered access to the repository(ies) in function of the identifiers and thanks to the URLs of the INSTANCE table 17

18 PACS registry and repositories Repositories without patient identifiers The URL is the main key between both information systems Patient identifiers are useless in the repository. Let’s get rid of them there ! 18

19 PACS registry and repositories Repository grouping through URLs The root segment of the path is important because it allows to perform grouping. We suggest a fundamental subdivision between: HEALTHCARE_ONLY SCIENCE_CONSENT a named private specific scientific trial consent followed by year followed by month followed by a study grouping segment with aleatory name followed by file aleatory name file:///REPOSITORY/SCIENCE_CONSENT/2010/10/3ea243/45772e 19

Workflows

21 Consent registration REGISTRY REPOSITORY HEALTHCARE ONLY REPOSITORY SCIENCE CONSENT

22 Consent registration Private DICOM attributes to simplify consent administration within the PACS Some of our new attributes are kept into the table PATIENT of the registry and available as keys in DICOM queries. They indicate the most up-to-date consent of the patient in relation to the scientific use of the data. Some of our new attributes are also kept into the the table STUDY of the registry. They indicate the consent applied to a specific study. 22

23 Consent registration Private attribute list 23 Attribute NameTagTypeVRVMVM Value Private Creator Data Element(0011,0011)3LO1OPENDICOM COMMUNICATION CONSENT Patient Access Consent Policy(0011,1100)3AE1Contains the most op-to-date consent status: HEALTHCARE_ONLY SCIENCE_CONSENT or a named specific private consent up to 7 chars followed by _CONSENT. For instance DRUGX_CONSENT Patient Access Consent Reference Sequence(0011,1101)3cSQ1Sequence binding to referenced consent document >Referenced SOP Class UID(0008,1150)1UI1Uniquely identifies the referenced SOP Class. >Referenced SOP Instance UID(0008,1155)1UI1Uniquely identifies the referenced SOP Instance. Study Access Consent Policy(0011,1110)3AE1Contains the consent status applicable to the study. Same contents list as in (0011,1100) Study Access Consent Reference Sequence(0011,1111)3cSQ1Sequence binding to referenced consent document >Referenced SOP Class UID(0008,1150)1UI1Uniquely identifies the referenced SOP Class. >Referenced SOP Instance UID(0008,1155)1UI1Uniquely identifies the referenced SOP Instance.

24 Consent registration At patient arrival The recepcionist creates a task in the modality worklist An entry for the patient is automatically created in the table PATIENT if it didn’t exist before The recepcionist checks the presence of consents for scientific use with a query to the PACS and, if adequate, gives the patient a form to be filled and signed The recepcionist scans and sends it as DICOM PDF On receiving the consent, the REGISTRY updates the values of (0011,1100) and (0011,1101) of its table PATIENT 24

25 REPOSITORY HEALTHCARE ONLY Store SCP Consent Linker REGISTRY REPOSITORY SCIENCE CONSENT DICOM query (0010,0030)=PatientID (0011,1100)=57017 RETURN value (0011,1101)=? (0011,1101)=SCIENCE_CONSENT (0011,1101)=HEALTHCARE_ONLY

26 Store SCP Consent Linker triggered at file reception checks out by DICOM query which consent policy is applicable to the study writes the consent reference into the file (0011,1110) Study Access Consent Policy (0011,1111) Study Access Consent Reference Sequence (0008,1150) Referenced SOP Class UID (0008,1155) Referenced SOP Instance UID uses Study Access Consent Policy as called AET forwards the result to the PACS 26

27 INTO REGISTRYSUP 142IOD GE PETAttributetag Patient levelYESZRPatient’s Name(0010,0010) YESZRPatient ID(0010,0020) YESZOPatient’s Birth Date(0010,0030) YESX/COther Patient IDs Sequence(0010,1002) NOXOPatient Address(0010,1040) NOXOPatient’s Telephone Number(0010,2154) Study levelYESZOAccession Number(0008,0050) YESZOReferring Physician’s Name(0008,0090) YESZ2Study ID(0020,0010) NOXOAdmission ID(0038,0010) Series levelYESX/Z/DO/value configInstitution Name(0008,0080) YESXORequesting Physician(0032,1032) YESXORequesting Service(0032,1033) YESXRequest Attributes Sequence(0040,0275) YESXORequested Procedure ID(0040,1001) YESX/Z/D3Operators’ Name(0008,1070) NOX3Performed Procedure Step ID(0040,0253) NOX3Performed Procedure Step Description(0040,0254) NOXRScheduled Station AE Title(0040,0001) NOXRScheduled Performing Physician Name(0040,0006) NOXOScheduled Station Name(0040,0010) NOXOScheduled Procedure Step Location(0040,0011) NOXOPatient Transport Arrangements(0040,1004) NOXORequested Procedure Location(0040,1005) NOXOConfidentiality Constraint on Patient Data Description(0040,3001) Store SCP attribute repartition REGISTRY REPOSITORY SCIENCE CONSENT attribute belongs to Sup 142 list attribute DO NOT belong to Sup 142 list WIPED OUT or NULLIFIED COPIED INTO REGISTRY CORRESPONDING TABLE de-identification

28 Store SCP attribute repartition On image instance storage The DICOM file is read. The corresponding patient, study and series entries are found in the registry, or created with the values of the corresponding attributes extracted from the file. Patient identifiers are wiped out or nullified in the file. A new entry is created in the instance table with a unique URL binding to the futur file location in the repository. The file is moved to the URL location. 28

29 Clinical access REPOSITORY HEALTHCARE ONLY REPOSITORY SCIENCE CONSENT patient study re-identification through registry DICOM retrieve DICOM query

30 Clinical access Re-identification through registry Upon image instance retrieval: The doctor selects a set of instances by DICOM queries filtering the registry. The doctor initiates the retrieval of the set. DICOM corresponding files are read. Patient nullified and inexistant attributes are overwritten with values found in the registry. The result is sent to the requestor. 30

31 Scientific access REPOSITORY SCIENCE CONSENT File System

32 Scientific access to authorized repository only The repository is subdivided into two or more sub repositories: SCIENCE_CONSENT HEALTHCARE_ONLY Scientific access is allowed to the sub repository “ SCIENCE_CONSENT” only, in read mode. Automated batch treatment becomes possible The URL to a specific file allows the scientist to get an already de-identified copy of the file. The URL contains a segment stating “SCIENCE_CONSENT”

Conclusions

34 Conclusions The duality REGISTRY - REPOSITORY of the PACS makes it an ideal place for de- re- identification The REPOSITORY file system allows grouping and control of user access (for example read access to users of group SCIENCE_CONSENT) The URLs binding REGISTRY with REPOSITORIES are very practical objects. CONSENT management is possible from within the PACS 34