Difference between revisions of "Cross-enterprise Document Query - XDQ"
m (Adding on-demand queries to XDS moved to Cross-enterprise Document Query - XDQ: Rename profile proposal from previous years) |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| − | ==1. Proposed Workitem: | + | ==1. Proposed Workitem: Cross Enterprise Document Query - XDQ == |
| − | * Proposal Editor: | + | * Proposal Editor: Vassil Peytchev |
| − | * Editor: | + | * Editor: Vassil Peytchev |
* Date: N/A (Wiki keeps history) | * Date: N/A (Wiki keeps history) | ||
* Version: N/A (Wiki keeps history) | * Version: N/A (Wiki keeps history) | ||
| − | * Domain: | + | * Domain: IT Infrastructure |
==2. The Problem== | ==2. The Problem== | ||
| − | The existing | + | The existing XD* framework addresses several common healthcare workflows, while providing a relatively simple set of interactions between actors. The current XD* framework, however, doesn't provide a mechanism for on-demand query for a patient summary. The reliance on creating documents at fixed points of the care delivery process is not sufficient to cover all use cases when a patient summary is needed at the point of care. While modern EMR and EHR systems store most of the patient's clinical and administrative data in discrete database fields, and are capable of generating patient summary documents upon request (on the fly), the XD* framework does not provide the capability for directly querying a document source. |
==3. Key Use Case== | ==3. Key Use Case== | ||
| − | ===How it works with | + | ===How it works with XDS=== |
| − | Person A moves to a new area due to accepting a job with company B. Person A visits their PCP for the first time, and provides initial information, including a drug allergy. That night, Person A is in an accident, and unconscious is admitted in the ER. Even though the ER staff knows the patient's PCP from records contained on his person, their query to the regional registry returns no existing documents, as the initial visit summary is not ready to be published. The drug allergy remains unknown ,and the patient | + | Person A moves to a new area due to accepting a job with company B. Person A visits their PCP for the first time, and provides initial information, including a drug allergy. That night, Person A is in an accident, and unconscious is admitted in the ER. Even though the ER staff knows the patient's PCP from records contained on his person, their query to the regional registry returns no existing documents, as the initial visit summary is not ready to be published. The drug allergy remains unknown, and the patient faces the possibility of a harmful drug being administered. |
===How it should work=== | ===How it should work=== | ||
| − | Person A moves to a new area due to accepting a job with company B. Person A visits their PCP for the first time, and provides initial information, including a drug allergy. That night, Person A is in an accident, and unconscious is admitted in the ER. The ER staff finds the patient's PCP from records contained on his person, and issues a direct query to the PCP's EMR system. The response of the query is a CCD document, which contains the current clinical summary of the patient, including the drug | + | Person A moves to a new area due to accepting a job with company B. Person A visits their PCP for the first time, and provides initial information, including a drug allergy. That night, Person A is in an accident, and unconscious is admitted in the ER. The ER staff finds the patient's PCP from records contained on his person, and issues a direct query to the PCP's EMR system. The response of the query is a CCD document, which contains the current clinical summary of the patient, including the drug allergy. Using this information, the ER staff avoids a dangerous situation. |
==4. Standards & Systems== | ==4. Standards & Systems== | ||
| + | Document Source, Document Consumer | ||
| − | + | ebXML Registry, XDS Stored Query, XDS.b Retrieve Document Set | |
| − | '' | + | ==5. Discussion== |
| + | ''Why would IHE be a good venue to solve the problem and what you think should IHE do to solve it.'' | ||
| + | This is a natural extension to the set of XD* profiles. | ||
| − | + | ''What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?'' | |
| − | |||
| − | '' | ||
| − | |||
| − | |||
| − | |||
| + | A new profile, using existing transactions and existing actors. | ||
| − | '' | + | ''What are some of the risks or open issues to be addressed?'' |
| + | There are additional use cases where on-demand queries can be very useful. There is likely a need for PCC to define a CCD-based patient "snapshot" content profile. | ||
| − | + | [[Category:Profile Proposals]] | |
Latest revision as of 21:38, 15 September 2008
1. Proposed Workitem: Cross Enterprise Document Query - XDQ
- Proposal Editor: Vassil Peytchev
- Editor: Vassil Peytchev
- Date: N/A (Wiki keeps history)
- Version: N/A (Wiki keeps history)
- Domain: IT Infrastructure
2. The Problem
The existing XD* framework addresses several common healthcare workflows, while providing a relatively simple set of interactions between actors. The current XD* framework, however, doesn't provide a mechanism for on-demand query for a patient summary. The reliance on creating documents at fixed points of the care delivery process is not sufficient to cover all use cases when a patient summary is needed at the point of care. While modern EMR and EHR systems store most of the patient's clinical and administrative data in discrete database fields, and are capable of generating patient summary documents upon request (on the fly), the XD* framework does not provide the capability for directly querying a document source.
3. Key Use Case
How it works with XDS
Person A moves to a new area due to accepting a job with company B. Person A visits their PCP for the first time, and provides initial information, including a drug allergy. That night, Person A is in an accident, and unconscious is admitted in the ER. Even though the ER staff knows the patient's PCP from records contained on his person, their query to the regional registry returns no existing documents, as the initial visit summary is not ready to be published. The drug allergy remains unknown, and the patient faces the possibility of a harmful drug being administered.
How it should work
Person A moves to a new area due to accepting a job with company B. Person A visits their PCP for the first time, and provides initial information, including a drug allergy. That night, Person A is in an accident, and unconscious is admitted in the ER. The ER staff finds the patient's PCP from records contained on his person, and issues a direct query to the PCP's EMR system. The response of the query is a CCD document, which contains the current clinical summary of the patient, including the drug allergy. Using this information, the ER staff avoids a dangerous situation.
4. Standards & Systems
Document Source, Document Consumer
ebXML Registry, XDS Stored Query, XDS.b Retrieve Document Set
5. Discussion
Why would IHE be a good venue to solve the problem and what you think should IHE do to solve it.
This is a natural extension to the set of XD* profiles.
What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?
A new profile, using existing transactions and existing actors.
What are some of the risks or open issues to be addressed?
There are additional use cases where on-demand queries can be very useful. There is likely a need for PCC to define a CCD-based patient "snapshot" content profile.