1 / 14

Multi-Patient Query for Aggregated Data Analysis

Proposal for expanding the XDS Stored Query transaction to allow for repurposing, secondary use, and population health surveillance through aggregated queries. The use case focuses on public health agencies identifying potential outbreaks and making informed decisions. The proposed approach includes adding a new query catalogue and defining new actors for aggregated data analysis.

edwardgarcia
Download Presentation

Multi-Patient Query for Aggregated Data Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XDS Stored Query – Multi-patient Queries Detailed Profile Proposal for 2008/09 presented to the IT Infrastructure Planning Committee for November 18 to November 19 at the face to face meeting Ana Estelrich November 18, 2008

  2. Summary Existing Problem • XDS Stored Query transaction defines a single catalogue of queries • Each catalogue of queries present in the Stored Query transaction contains : • single patient ID • folder ID • submission set ID • Data aggregation is needed for repurposing, secondary use, and population health surveillance • Public Health needs to have the means to make aggregated queries on certain fields such as eventCodeList in order to identify potential outbreaks and take appropriate decisions. • Quality accreditation organisations need to be able to aggregate data so that they can perform measurements of how institutions perform (author or healthcareFacilityTypeCode). • Clinical Research needs to be able to combine the results of different patients in a clinical trial (typeCode).

  3. Summary Relevant standards • XDS.b Document Consumer • XDS.b Document Registry • ebRIM OASIS/ebXML Registry Information Model v3.0 • ebRS OASIS/ebXML Registry Services Specifications v3.0 • IHE ITI Technical Framework, Volume 2-3.18 Registry Stored Query Summarize how the problem could be solved • Option to transaction ITI-18, providing the that the necessary privacy and security policies and precautions are in place. Why IHE? • IHE already has the ITI-18 – single query for a single patient’s documents • IHE QRPH needs to perform aggregated queries for • Patient Safety • Potential Outbreaks • Epidemiological Studies • Clinical Trial Evaluations • Quality Accreditation Organizations

  4. Use Case - Public Health - Current • Patient B gets treated by Hospital A for certain symptoms, corresponding to a potential reportable condition. • This will be captured in the document/submission set/folder metadata eventCodeList. • Hospital A sends a required report to the appropriate Public Health agency P, and also sends an ED Encounter Summary (EDES) to the local XDS repository (using Publish and Subscribe). • There are pre-determined set for event codes, corresponding to the patient’s symptoms and that are included as part of the XDS metadata. • Public Health determines that a review of recent ED encounters for patients with similar symptoms is necessary. • XDS Document Registry only accepts patient specific queries. • A list of patients with the appropriate symptoms must be obtained and individual queries are performed to the XDS Registry – verytime consuming and not always accurate. • If Multiple Patient Queries existed, then the task would be much easier to automate.

  5. Use Case - Public Health - Desired • The same situation but: • After reviewing the report, the public health agency determines that a review of recent ED encounters for patients with similar symptoms is necessary. • Using queries from the new catalog of Stored Queries, the Public Health officials retrieves the metadata from the XDS registry for all recent EDES and hospital discharge summaries which contain the event codes corresponding to the symptoms in question. • Informed decision can be made as to how to contain the epidemic (if there is one) and if further actions should be taken (contacting the persons that the patient has come into contact with etc).

  6. Just one system of many which will need to aggregate data

  7. Public Health Information Affinity Domain (PHIAD) Public Health Information Affinity Domain

  8. Proposed Standards & Systems • XDS.b Document Consumer • XDS.b Document Registry • ebRIM OASIS/ebXML Registry Information Model v3.0 • ebRS OASIS/ebXML Registry Services Specifications v3.0 • IHE ITI Technical Framework, Volume 2-3.18 Registry Stored Query

  9. Technical Approach One Expanding the existing Stored Query with an additional catalogue of queries. • Benefit – Creating a new actor will allow to define separate security requirements from the existing XDS.b Registry actor • Drawback – adding a new actor to XDS.b which is ok since it is still in trial implementation. Two • Add the new query catalogue as an option for the XDS.b Document Registry - in this case no new actors are needed. Three • Define and add the new pair of actors, Aggregated Registry and Aggregated Consumer, as a new profile

  10. Impact on existing actors XDS.b Document Consumer • Currently, there are no requirements to support specific queries, even from the current catalog. • This can be left as is, since it would be other profiles that will specify the use of multi-patient queries XDS.b Document Registry • If the decision is to create a new actor, the current Document Registry actor will not change, except for noting that it only supports the current query catalogue, and acknowledging the possibility of it being grouped with the new Aggregated Registry actor. • If the decision is to add the new query catalogue to the Document Registry actor, then it will be added as an option to the existing actor – Document Registry.

  11. New transactions (standards used) and on existing profiles No new transactions needed • The stored query transaction can be used for the multi-patient query • Current transaction will be enhanced by extending section 3.18.4.1.2.3.7 (Parameters for Required Queries) in volume 2 of the technical framework to accommodate a second catalog of queries. Impact on existing integration profiles • XDS.b will have to accommodate the use of aggregated queries. New integration profiles needed • It is unlikely that this enhancement would lead to a new integration profile.

  12. Breakdown of tasks needed to be accomplished • Decide with QRPH what metadata are needed • Create initial enhancement for the Stored Query transaction in Volume 2, using XDSDocumentEntry.eventCodeList, XDSDocumentEntry.author, XDSDocumentEntry.healthcareFacilityTypeCode, and XDSDocumentEntry.classCode as the required parameters for 4 new queries. • Evaluate the need for additional queries • Evaluate the need to allow/require asynchronous queries. • Prepare initial proposals for changes to volume 1 for XDS.b (same actor(s) with options vs. new actors) • Get the committee's feedback at the January F2F meeting • Based on committee feedback, finalize changes to volume 2, the Registry Stored Query transaction • Based on committee feedback, create enhancement to volume 1 • With help from the security experts in ITI, create initial risk assessment for aggregated queries • Get the committee's feedback at May F2F meeting • Apply committee feedback and create final draft • Prepare the supplement for publication at the July F2F meeting

  13. Open Issues Open Issues • Defining the additional queries • The changes need to be brought to volume 1 • Security considerations.

  14. Technical and Political Risks Technical risks implementation burden of existing registry implementations, and the security risk assessment of the new queries. This will affect the implementability of the specification. Political risks perception among users that XDS is yet again being changed, as well as the possible negative impact on registry implementers. These have to be weighed when determining the changes to be made to Volume 1, and an educational campaign needs to clearly explain that this supplement does not change any part of the existing XDS.b specifications.

More Related