VNA Study Management - Proposal

1. Proposed Workitem: Shared Study Management (SSM)

• Proposal Editor: Kinson Ho
• Editor: Kinson Ho
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: Radiology

Summary

With the increasing interest and adoption of a centralized archive / distribution / integration archicture, it is not unusual that the Centralized Archive receives the same study multiple times. Each copy of the study may have different key attributes due to coercion to local values (e.g. patient ID, accession number, etc.). It is difficult for the Centralized Archive to identify if the differences are legitimate or a mistake. Also it is unclear what is the expected behavior how to handle the differences in the Centralized Archive (e.g. query, retrieve, update, etc.)

DICOM defines the Original Attribute Sequence to capture the original value if the Image Manager performs any coercion. IHE IRWF has adopted this mechanism. Further expected behaviour is required to specify how this information should be used. Moreover, expected behaviour for other study related transactions such as query, retrieve, etc. also need to be enhanced to handle these use cases.

Regional health information exchange networks based on XDS or DICOM/HL7 (e.g. Diagnostic Imaging Repositories in Canada) are interested in a standard based mechanism to address the problem. Individuals from Centralized Archive vendors are encouraged to participate in the profile development. Agfa is willing to lead the development effort.

Regional health information exchange networks often consists of systems from multiple vendors with different behaviour. IHE Radiology is a good venue to standardize the behaviour based on underlying standards to address this increasingly common problem.

2. The Problem

With the increasing interest and adoption of a centralized archive / distribution / integration archicture, it is not unusual that the Centralized Archive receives the same study multiple times. These studies can be sent from different sites, each receive a copy of the same study (via CD Import, network transfer, retrieve from Centralized Archive, etc.). Each copy of the study may have different key attributes due to coercion to local values (e.g. patient ID, accession number, etc.).

Conceptually, it is possible to have multiple views of a study. Technically it is common for the different views to have the same SOP Instance UID, same Series Instance UID but different Study Instance UID, accession number, patient ID, procedure codes, etc.

This imposes several problems to a successful deployment of a Centralized Archive:

• How can the Centralized Archive recognize that these different key attributes are equivalent, not data corruption or old/stale values from an old copy?
• Should the Centralized Archive be able to maintain these different key attributes such that when it returns the study back to the same originating site, it can return the right value (e.g. the local coerced value known)?
• What if a 3rd site request the study? What values should the Centralized Archive return?
• If there is a change request sent from Site A to the Centralized Archive (e.g. following IOCM), should the Centralized Archive reflect the same change to the study sent from Site B? Or should the change request only applies to the copy sent from Site A
• If there is a viewer attached to the Centralized Archive, which key attribute should be displayed? How can it present the other equivalent values?
• More generally speaking, should the Centralized Archive consider the multiple copies of the same study as independent?
• If XDS-I.b is involved, should each copy of the study be a separate manifest, or should they be all considered a single manifest?

The value of this profile is to strengthen the operational interoperability of a Centralized Archive.

3. Key Use Case

The common scenario is as follow:

• Site A acquires a study (Study A)
• Site A shares the study with Site B
• When Site B receives the study, it reconciles the study to local patient and order information but retain the same UIDs, including the Study Instance UID. This is according to IRWF profile. Site B now has a slightly different version of Study A, let's called it Study A'.
• Site A and B eventually both archive the study to the shared centralized Centralized Archive
• When the Centralized Archive receives the studies, when it received the second copy, it detects that the same object has already been received but the new copy has different key identifiers (e.g. Patient ID, accession number, etc.)

A variation of the scenario above is that Site B does not follow IRWF. Instead the Importer also updates the Study Instance UID corresponding to the local order that the study is coerced to.

4. Standards and Systems

Existing systems: Image Manager/Image Archive, Change Requester, Image Display, Evidence Creator, Imaging Document Source/Consumer, Importer

Existing standards: SWF, IOCM, IRWF, XDS-I, DICOM

5. Technical Approach

Existing actors

Importer: To inject the Original Attribute Sequence

Image Manager: To examine the Original Attribute Sequence as well as manage the multiple views of the study. Return the linked information in query/retrieve

New actors

No new actors required

Existing transactions

1. Storage and Conflict Detection

When an Importer imports an external study, if it coerces the study to a local order and patient record, then it shall keep track of the original values of any coerced attributes, including UIDs such as Study Instance UID, in the Original Attribute Sequence with the reason value set to COERCE (or something else defined by IHE / DICOM)

When an Image Manager receives an object, if the SOP Instance UID is known but associated to a different Study Instance UID, then the Image Manager examines the Original Attribute Sequence. If the reason is COERCE and the modified attributes have values that match the known values associated to the SOP Instance UID, then the Image Manager knows that this is an equivalent object with local coerced value. Therefore the Image Manager shall accept the object. Otherwise, the Image Manager is free to decide how to handle the conflict (e.g. reject the object, accept but flag it as conflict, etc.)

The Image Manager shall also keep track of the source of the study (e.g. based on Calling AE, Institution, Department, etc.)

The Image Manager shall link the patient records.

1. Query / Retrieve

If the Image Manager is capable of managing multiple views of the study, then the Image Manager shall return the best view of the study:

• If the Image Manager knows about a view that matches the requester, then the Image Manager shall return the matching view.
• If the Image Manager does not find any view that matches the requester, then the Image Manager shall return the best view (e.g. first known view)

1. Handling of IOCM Rejection Notes

If the Image Manager receives a rejection note, it shall reject only the copy that matches the full study hierarchy (i.e. SOP / Series / Study Instance UID), not only the SOP Instance UID.

1. Handling of HL7 Update

Since the patient records are linked, if the Image Manager receives ADT messages, it shall update the corresponding patient record and maintain the linkage information.

New transactions (standards used)

No new transaction required

Impact on existing integration profiles

Depends on SWF / SWF.b.

Update IRWF / IRWF.b with regards to the use of Original Attribute Sequence

• • An alternative solution is to add a new Local Coercion use case in IOCM. In this case, the Change Requester is required to create replacement objects for the imported study, in particular all the UIDs will be updated. No Rejection Note is required.

New integration profiles needed

Create a new Share Study Management (SSM) profile

Breakdown of tasks that need to be accomplished

1. Create a new profile
2. Evaludate and determine how to enhance the following transactions:
   1. Storage
   2. Query
   3. Retrieve
   4. Rejection Note Store
   5. Procedure Update
   6. Patient Update

6. Support & Resources

Multiple DI-r groups in Canada Health Infoway expresses interest in the design of this.

7. Risks

Some customers may prefer the second copy to be an independent copy while some may prefer the second copy to be a linked copy. This affects whether changes to one copy should automatically be applied to another copy.

8. Open Issues

Not all systems will be upgraded at the same time. Ideally the benefit of the profile can be materialized with the minimal amount of systems involved.

Which design alternative is more practical? IOCM Local Coercion use case or Management of multiple study views.

Storage Commitment only specifies the list of SOP Instance UIDs in the N-Action request. So the Image Manager may return a success even if it does not have a particular view of the study.

If the Importer only imports a partial copy of the original study and only this partial copy is sent to the shared Centralized Archive, should the full study be visible to Site B?

9. Tech Cmte Evaluation

Effort Evaluation (as a % of Tech Cmte Bandwidth):

• 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

TBA