| Planning considerations - A key component is the governance structure. There are many models, such as a newco, a partnership, a purchased service, or a hybrid. Establishing this model lays the foundation and the terms of engagement for the participating hospitals. In the case of SWODIN, there was already a history of collaboration among a group of hospitals that was leveraged and expanded upon in 2004 to form a partnership. As the project expanded and the extent to which the new participants were sharing services changed, the model adapted, and the agreement was modified to include some participants under a purchase service model.
A project of this magnitude requires strong Executive sponsorship. SWODIN formed a project Steering Committee with CEO or executive designate participation from each organization. Regular communication with the Steering Committee is essential to ensure active engagement and support. A strong PMO is required, along with strong regional/hospital and vendor teams where roles and responsibilities are clearly defined. The SWODIN PMO is comprised of hospital employees and consultants, and the Project Director reports directly to the Steering Committee Chair. The regional teams are 100% hospital employees. This fosters local ownership.
Implementation considerations - How will patient records from multiple hospitals with multiple identifiers be collated (longitudinality)? Is there an existing client registry, a government identifier, or is a regional solution required?
At the time of implementation, there was no client registry and the government identifier was not assigned to all members of our population. The SWODIN project opted to implement a patient matching solution within the DI-r. It is a deterministic model using hospital identifiers as the primary match criterion, relying on patient demographics only when necessary.
Workflow and use case considerations are key. Radiologists often demand that the images be available in the local PACS application so that they are able to manipulate and compare local and images from other facilities side by side. This is a challenge, as most PACS systems have not integrated the functionality required either to query the repository directly or to manage non-local (“foreign images”). The timing of the receipt of the images in the repository must be considered if emergency consults are required. The timing of the acquisition and publication to the repository is a challenge. Many PACS systems track changes through the local PACS database. Once images have been sent to the repository, it is a challenge to ensure that any updates that occur to the image set, such as rejections or additions, can be propagated in the repository without a great deal of manual intervention. Until standards are established through IHE or DICOM, this requires manual intervention, threatening the data integrity of the repository.
Many PACS systems use a combination of body part and procedure code/description to drive hanging protocols. These vary system to system. If images are being imported into the local PACS, this may lead to challenges with hanging protocols. It is essential to drive toward consistent nomanclatures or be able to integrate to a nomanclature registry.
If non local/foreign images are imported into local systems, there are many data integrity issues to be considered. Does the PACS system require an order? If so, how will the order be created? What patient identifier should be used? What procedure code should be used? How long will the order and image be retained? What purge mechanisms and rules exist? Can or should image set changes be allowed? If so, are the changes to be populated to the Image Repository? How is the originating PACS notified of an update? How is use or access to the image audited locally or regionally? How is the report accessed? How do we manage patients consent? How do we ensure that data transmission will be secure and there are proper credentialing policies? Access to image and report data should be recorded in an easy to access central location. In the event that there is a breech, it is important to be able to provide timely and accurate audit information.
In the SWODIN case, we have chosen to have the DI-r act as a proxy to mitigate some of these interoperability challenges. All patient demographic, order information, results, and images are sent to the DI-r where the patient matching rules are applied and the images are profiled to the associated orders and results. Wherever possible, the images are sent to the DI-r, as soon as it is confirmed that all images have been acquired, to facilitate emergency consult scenarios. Collaboration with all vendors was required to review how image set updates will be managed and, in some instances, manual processes are required. Access to the comprehensive radiology history is provided through the DI-r application and images are displayed on a web based viewer attached to the DI-r. Although there is exception management required at the DI-r it is proving to be manageable than expected. Access management is controlled through User profiles and, although this requires setup and ongoing administration, it facilitates our ability to provide audit information, as all user activity and access to images is recorded in the application layer and can be reported on using standard reporting tools.
If the images are not readily available in the local PACS, it can be a difficult sell to get clinicians to adopt yet another application. SWODIN has worked with various vendors to provide the ability to launch the DI-r application from within the local PACS. This allows the clinician to maintain their current workflow, but have access to the longitudinal record and to select and display foreign images. While this does not solve the issues with being able to apply hanging protocols or link and do a comparison scroll, in a multi monitor configuration it is often possible to display the image from the current exam on one monitor and the image from the DI-r on another.
Operational sustainability must also be considered, including issues such as who maintains and manages the solution, and uptime and infrastructure requirements (these may be different depending on the level of service being provided). Is this a mission critical system? What are the disaster level and uptime requirements?
SWODIN has a fairly mature support model in place. As participants are connected to the DI-r, there is a 30-day stabilization period, after which there is a “Transition to Operations” handoff.
|