Legitimate Data Sharing: What it means. It means that if your GP records are sent to a Central data store for archiving, still only the GP surgery you are registered with will have access to your data. Other GP surgeries will not have access to your data. If you decide to change your GP and get yourself registered with another surgery, your data will now be available to your new GP. This will improve your clinical management as a patient.
The same applies to PACS and data sharing. If you are registered with a Trust on their PAS, your images that may lie in the central data store will be accessable to clinicians within that Trust. However, your data will not be accessible to other Trusts as you are not registered on their PAS. However, if in an emergency you get admitted to another hospital, as you will get registered on their PAS, your imaging data will npw be available to the clinicians of the hospital and this will help with clinical management. Legitimate data sharing is good of our NHS patient and we should support CFH in delivering this.
IHE has come up with standards for enabling Legitimate Data sharing with the following XDS and XDS-I profiles
"The XDS profile provides a standards-based specification for managing the interchange of documents that care delivery organizations have decided to explicitly share. The XDS profile has acquired a leading position in specifying the architecture and guidelines for sharing clinical and healthcare information across organizational boundaries.
XDS assumes that participating organizations belong to one or more clinical affinity domains. A clinical affinity domain (CAD) is a group of care delivery organizations (CDO) that have agreed to work together using a common set of policies and infrastructure. Each CDO may have its own legacy IT system and/or existing IT infrastructure. The CAD enables the sharing and exchange of medical information across CDOs by using the established policies and infrastructure.
DOCUMENT REGISTRY - maintains metadata about each registered document, including a link to the document repository from which it can be retrieved. The document registry receives requests from document repositories to register documents and responds to queries from document consumers about documents that meet specific criteria. There can be only one document registry in a clinical affinity domain.
DOCUMENT REPOSITORY - ensures that a document is persistently stored and can be retrieved from its persistent storage. The repository retrieves documents from a document source or through a non-XDS interface, stores them persistently, and registers them with the document registry of the clinical affinity domain. The document repository also responds to requests for documents it has previously registered. There can be many document repositories within a clinical affinity domain.
DOCUMENT SOURCE- produces and publishes documents. The document source sends documents to the document repository. It also supplies metadata to the document repository for the subsequent registration of the documents with the document registry. This component provides an interface that enables other components in the system to add documents into the clinical affinity domain. There may be many document sources within a clinical affinity domain.
DOCUMENT CONSUMER - queries the document registry for documents that meet certain criteria and retrieves selected documents from one or more document repositories. There may be many document consumers within a clinical affinity domain.
PATIENT IDENTITY SERVICE - cross-references patients among multiple domains. In particular, it provides the mechanism to translate CDO level patient IDs to CAD level patient IDs."
Let us look at this in the NHS context 1. "A clinical affinity domain (CAD) is a group of care delivery organizations (CDO) that have agreed to work together using a common set of policies and infrastructure.": This is the NHS. 2. "DOCUMENT REGISTRY-There can be only one document registry in a clinical affinity domain." THIS ACTOR HAS TO BE THE SPINE. 3. PATIENT IDENTITY SERVICE: Also called PDS service within the SPINE.CAD level identity is the NHS no. The PDS service in the spine needs to support this XDS actor. 4. DOCUMENT REPOSITORY : a. for images the LSP central data store will need to have this actor for XDS-I b. for reports the local RISes will need to support this actor 5. DOCUMENT SOURCE: a. For Images the local PACS needs to support this actor b. For reports the RISes need to support this actor. 6. DOCUMENT CONSUMER : a. For Images the Local PACS will support this actor b. For reports the local RIS will need to support this actor.
If our country is looking at enabling legitimate data sharing using the IHE way, this is what we need 1. SPINE to support Document Registry and Patient Identity service actors of XDS and XDS-I 2. LSP Image archives/Local PACS(outside the LSP) to support Document repository actor for XDS-I 3. Local PACS (whether LSP or Non-LSP) to support Document Source and Document Consumer actors for XDS-I 4. Local/Central RISes to support Document repository, Document Source and Document Consumer actors for XDS.
We do need policy, targets and real penalties on suppliers who do not deliver, to support this method of legitimate data sharing. Let us look at the future 1.GP systems: make themselves document consumer actor and then would have access to radiology report using this means (rather than a push to the GP system) 2. Lab systems use the same actors as RIS to enable data sharing accross organisations 3. PAS systems enable same actors as RIS to enable clinic letter/discharge summary sharing throughout the NHS.
This also provides to us choice as consumers of these health care systems. We also know choice, enables competition and competition enables innovation.
Please could I invite comments (good or bad) from knowledgeable people particularly technical people.
Dave Harvey is due to talk to us about XDS and XDS-I on 7th March. Dave has a lot of knowledge on IHE and has been involved in connectathons.
scenario reporting cxr - from gp - registered radiology but not pas lesion ? significance GP mentions prevoius cxr St Elsewhere
How do I access this with above ?Written letter with signed pt consent ?telephone and 10 day wait for snailmail ?as should be, a single database open to those with a legitimate interest(assuming implied consent unless opted out or using given consent which as we have been told works in (as far as I can remember from presentation at group meeting) the Agfa Finnish project
1. In IHE world your patient who is registered on RIS/radiology will have a PAS entry (PAS acts as the ADT actor on SWF profile of IHE). 2. If the Patient is registered on your PAS, you have a legitimate relationship to that patient. Hence, if your PACS/central store/other PACS in your CAD (Clinical Affinity Domain --like NHS) support XDS-I you will have access to all the patients imaging history within the CAD (whole of the NHS---this will not be limited by LSP cluster boundaries). Similarly if your RIS supports XDS then you will have access to all the radiology reports wherever they may have been performed in the NHS. The PACS within your CAD can be from multiple suppliers provided they support XDS-I. Similarly the RISes in your CAD can be from multiple suppliers but need to support XDS.
This was what NPFIT vision was when it came out (which all of us supported). Let us all try to help to make the NPFIT vision a reality. XDS and XDS-I are a means of realising the NPFIT vision.
You do not have to have a central database/single data store to enable data sharing, provided the PACS/RIS systems from hospitals you wish to share data with comply to XDS and XDS-I. The beauty is that you do not have to have the same PACS suppliers in the CAD
All you need is a 1. a single unique identifier--like NHS no for us 2. Document Registry--like the Spine for us.
Analogy is that you do not have buy all your modalities from the same vendor in order for you to store all radiology images into the same PACS (not very long ago modality vendors were selling miniPACS systems for individual modalities). Now PACS vendors are selling central databases to allow image sharing amonst their PACS systems. Whilst the same goal can be achieved by insisting on standards.
2 points to make 1. NHS Spine As I understand it, the spine will provide access to a summary record and there will always be locally available documents that are not available via the spine.
It would be useful if an application could be developed that could search for local documents within the affinity domain using XDS and also search the spine using its existing search facilities.
2. No need for single patient ID using XDS Provided there is a Patient Identifier Cross Reference Manager supported by the affinity domain then the consumers in each institution can use their own Patient ID when initiating a search and the registry will perform a search using any other known patient IDs as well as that specified by the Consumer
All this will be discussed at the meeting to be held in Oxford on Wednesday 9th April see www.ihe-UK.org
posted on Tuesday, February 26, 2008 - 03:40 pm
To enable data sharing the IHE way we need : SPINE to support 1. Document Registry and 2. Patient Identity service actors of XDS and XDS-I
Within the English PACS solution we do need NHS no. as unique identifier due to Cluster Data stores and the National Breast Screening service and our need to share data with GPs etc.