Difference between revisions of "Query for Existing Data"

From IHE Wiki
Jump to navigation Jump to search
m (Redirecting to PCC TF-1/QED)
 
(113 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Introduction=
+
#redirect [[PCC TF-1/QED]]
''This is a draft of the Query for Dynamic Clinical Data Profile (QCD) supplement to the Patient Care Coordination Technical Framework.  This draft is a work in progress, not the official supplement or profile.''
 
 
 
__TOC__
 
 
 
==Profile Abstract==
 
The Query for Dynamic Clinical Data Profile (QCD) supports dynamic queries for Clinical Data. 
 
A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository.  This profile makes the information widely available to other systems in the enterprise to support provision of better clinical care.  The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.
 
 
 
==Glossary==
 
; Clinical Data Repository : A Clinical Data Repository (CDR) is a database of clinical information on patients, often optimized for access by individual patients.
 
 
 
==Issue Log==
 
===Open Issues===
 
# One WSDL or two? <br/>HL7 and IHE specifications for Web Services would indicate that the formal contract defining the behavior of the service be described in a single Web Services Definition.  However, a WSDL that conforms to HL7 specifications is overly complex for engineering use.  I would recommend supplying one WSDL that is the formal contract, and a second WSDL for engineering use, to simplify the creation of client proxies.
 
# Should Accept and Application Acknowledgements be supported? <br/>The web service responds to queries with results.  This is a very simple request/response message exchange pattern (MEP), which obviates the need to support application or accept acknowledgements.  If the request succeeds, then the response serves as an application level acknowledgement.  So, I have decided to not use either of these.
 
# Following the HL7 Shoulds in naming? <br/>The HL7 Web Services profile provides guidance about how to name various components of the service description.  No rationale for this guidance is provided, and the names are not easily understood by application developers.  Therefore, I have followed the spirit but not the letter for this guidance, using the human readable names derived from the HL7 Ballot materials, instead of the interation identifiers.  Note however, that the names of the Elements carried in the soap:Body conform to the "Shall" requirements, in that they do use the HL7 interaction identifiers for the name of the message element.
 
 
 
===Closed Issues===
 
=Volume I=
 
<pre>Add the following bullet to the list of profiles</pre>
 
* Query for Dynamic Clinical Data - This profile (QCD) supports dynamic queries for Clinical Data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems in the enterprise to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.
 
===Dependencies===
 
<pre>Add the following row(s) to the list of dependencies</pre>
 
{|style='background-color:#7f7f7f;' align='center' border='1' cellspacing='0'
 
!Integration Profile
 
!Dependency
 
!Dependency Type
 
!Purpose
 
|- style='background-color:#ffffff;' align='center'
 
|Query for Dynamic Clinical Data
 
|[[Audit Trail and Node Authentication]]
 
|Each [[Clinical Data Source]] and [[Clinical Data Consumer]] actor shall be grouped with the ATNA [[Secure Node]] or [[Secure Application]] actor.
 
|Required to manage audit trail of exported PHI, node authentication, and transport encryption.
 
|- style='background-color:#ffffff;' align='center'
 
|Query for Dynamic Clinical Data
 
|[[Concistent Time]]
 
|Each [[Clinical Data Source]] and [[Clinical Data Consumer]] actor shall be grouped with the [[Time Client]] Actor
 
|Required to manage and resolve conflicts in multiple updates.
 
|-
 
|}
 
 
 
==Profile Name==
 
The Query for Dynamic Clinical Data Profile (QCD) supports dynamic queries for clinical data. A wide variety of systems often need access to dynamic clinical information stored and maintained in an EMR system or other clinical data repository. This profile makes the information widely available to other systems in the enterprise to support provision of better clinical care. The information made available by this profile can be used to support clinical care, quality reporting, financial transactions, public health reporting, clinical trials, drug interaction checking, and patient qualification for various protocols.
 
 
 
''And then some more introductory text.''
 
 
 
===Use Cases===
 
====Clinical Trials====
 
A patient participating in a clinical trial arrives for a trial-related visit to a physician office.  The physician completes a report in his/her EMR gathering information relevant to the trial.  Upon completion of the trial, a research assistant needs to gather the data relevant to the trial and submit it to the clinical trial information system.
 
====Claims====
 
A practice management / billing system begins a claim.  The practice management system extracts certain clinical information (known as situational data elements) from the EMR to complete the claim.
 
====Drug Safety====
 
Medication is about to be administered at a modality.  Prior to administration, the modality queries the EMR for current problems, medications and allergies, to enable display of this information to the operator, or to send to a decision support system to determine if this medication is OK to administer.
 
A CPOE system needs to generate a medication order for a patient.  Prior to generating the order, the system will query the EMR for specific measurements (e.g., height, body weight, age) of the patient for measurement specific dosing regimens.  The system might also request the patient's current problems, medications and allergies to perform drug interaction checking before completing the order.
 
====Quality Reporting====
 
Upon completion of a visit, certain quality measures need to be gathered in order to produce an aggregate measure.  A quality system can query the EMR to determine for each patient the values that need to be measured.
 
====Public Health, Biosurveillance, and Disease Registries====
 
Upon completion of a visit, certain data may need to be gathered and reported to public health authorities.  A reporting system can query the EMR for this information to put together the appropriate public health data.
 
====Identifying Qualifying Patients====
 
Decision support systems can query the EMR to obtain specific data elements for a patient, and use that information to determine if the patient qualifies for a clinical trial, or if the visit is one that requires additional reporting.
 
 
 
===Actors/Transaction===
 
There are two actors in this profile, the Clinical Data Repository and the Clinical Data Consumer. [[image:qcd.png|frame|center|Query for Dynamic Clinical Data Actor Diagram]]
 
 
 
Table 5.1-1 lists the transactions for each actor directly involved in the Patient Identifier Cross-referencing Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled 'R'). Transactions labeled 'O' are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed below under [[#Options | Options]].
 
 
 
{|style='background-color:#cfcfcf;' align='center' border='1' cellspacing='0'
 
!Actor
 
!Transaction
 
!Optionality
 
!Section
 
|+Query for Dynamic Clinical Data Actors and Transactions
 
|- style='background-color:#ffffff;' align='center'
 
| rowspan='4'|Clinical Data Source
 
| [[#Query Vital Signs | Query Vital Signs]]
 
| R
 
| PCC-1
 
|- style='background-color:#ffffff;' align='center'
 
| [[#Query Problems and Allergies | Query Problems and Allergies]]
 
| R
 
| PCC-2
 
|- style='background-color:#ffffff;' align='center'
 
| [[#Query Lab Results | Query Lab Results]]
 
| R
 
| PCC-3
 
|- style='background-color:#ffffff;' align='center'
 
| [[#Query Medications and Immunizations | Query Medications and Immunizations]]
 
| O
 
| PCC-4
 
|- style='background-color:#ffffff;' align='center'
 
| rowspan='4'|Clinical Data Consumer
 
| [[#Query Vital Signs | Query Vital Signs]]
 
| O<sup>1</sup>
 
| PCC-1
 
|- style='background-color:#ffffff;' align='center'
 
| [[#Query Problems and Allergies | Query Problems and Allergies]]
 
| O<sup>1</sup>
 
| PCC-2
 
|- style='background-color:#ffffff;' align='center'
 
| [[#Query Lab Results | Query Lab Results]]
 
| O<sup>1</sup>
 
| PCC-3
 
|- style='background-color:#ffffff;' align='center'
 
| [[#Query Medications and Immunizations | Query Medications and Immunizations]]
 
| O<sup>1</sup>
 
| PCC-4
 
|}
 
 
 
Note <sup ID=note1>1</sup>: The Actor shall support at least one of these transactions.
 
 
 
=== Options ===
 
 
 
{|style='background-color:#cfcfcf;' align='center' border='1' cellspacing='0'
 
!Actor
 
!Option
 
!Section
 
|+Query for Dynamic Clinical Data Options
 
|- style='background-color:#ffffff;' align='left'
 
|Clinical Data Source
 
|
 
|option 1
 
|link to definition...
 
|- style='background-color:#ffffff;' align='left'
 
|Clinical Data Consumer
 
|
 
|option 2
 
|link to definition...
 
|}
 
 
 
=== Grouping ===
 
 
 
=== Process Flow ===
 
[[Image:seq.jpg|frame|center|Query for Dynamic Clinical Data Process Flow]]
 
 
 
More text about process flow
 
 
 
== Actor Definitions ==
 
; Clinical Data Source : A clinical data source maintains a collection of clinical data for patients.  It responds to queries for that data from a Clinical Data Consumer.
 
; Clinical Data Consumer : A clinical data consumer performs queries of a clinical data repository to obtain clinical information.
 
 
 
== Transaction Definitions ==
 
; Transaction : Definition
 
 
 
=Volume II=
 
===Query for Dynamic Clinical Data Content===
 
==== Standards ====
 
; [http://www.hl7.org/v3ballot/html/infrastructure/cda.htm CDAR2] : Clinical Document Architecture, Release 2, 2005 HL7
 
; [http://www.hl7.org/documentcenter/public/standards/informative/crs.zip CRS] : Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm), 2006, HL7.
 
; [http://www.hl7.org/Library/Committees/structure/CCD%2E01Dec2006%2EDRAFT%2Ezip CCD] : ASTM/HL7 Continuity of Care Document (Draft)
 
 
 
; [http://www.snomed.org SNOMED] : Systemized Nomenclature for Medicine
 
 
 
[[Category:Patient Care Coordination]]
 
[[Category:Draft Profile Supplement]]
 

Latest revision as of 22:17, 14 June 2007

Redirect to: