Query for Existing Data

From IHE Wiki
Jump to navigation Jump to search

Introduction

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.

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

  1. One WSDL or two?
    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.
  2. Should Accept and Application Acknowledgements be supported?
    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.
  3. Following the HL7 Shoulds in naming?
    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

Add the following bullet to the list of profiles
  • 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

Add the following row(s) to the list of dependencies
Integration Profile Dependency Dependency Type Purpose
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.
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.

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.

Actor Transaction Optionality Section
Query for Dynamic Clinical Data Actors and Transactions
Clinical Data Source Query Vital Signs R PCC-1
Query Problems and Allergies R PCC-2
Query Lab Results R PCC-3
Query Medications and Immunizations O PCC-4
Clinical Data Consumer Query Vital Signs O1 PCC-1
Query Problems and Allergies O1 PCC-2
Query Lab Results O1 PCC-3
Query Medications and Immunizations O1 PCC-4

Note 1: The Actor shall support at least one of these transactions.

Options

Actor Option Section
Query for Dynamic Clinical Data Options
Clinical Data Source option 1 link to definition...
Clinical Data Consumer option 2 link to definition...

Grouping

Request Form for Data Capture

A Clinical Data Consumer actor may be grouped with an ??? or ???? actor to appropriately populate forms with recently gathered clinical data.

Cross Enterprise Document Sharing

A Clinical Data Source actor may be grouped with a Cross Enterprise Document Repository actor. Data gathered from clinical documents submitted to the Document Repository can be a source of information returned by the Clinical Data Source actor. Information returned by the Clinical Data Source shall include references to the documents that were submitted to the Document Repository.

Content Integration Profiles

A Content Creator may be grouped with a Clinical Data Consumer to obtain some or all of the information necessary to create a Medical Summary based on information found in a Clinical Data Source.

Process Flow

Query for Dynamic Clinical Data Process Flow

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 visit, a research assistant needs to gather the data relevant to the trial and submit it to the clinical trial information system. Among the data needed to gather are the patient's current medications.

The research assistant logs into the clinical trial information system, and enters data about the patient visit pertinent to the trial. The clinical trial information system performs a query of the EMR where the patient visit data is stored, and obtains the list of the patient's current medications.

Claims

A claims administrator begins a claim for treatment of a patient who is pregnant. They log into their practive management system to begin processing the claim. Since this claim is for services provided during pregnancy, a patient measurement is needed to complete the claim. The practice management / billing system queries the EMR for the date of last menstruation for the patient, and completes the claim.

Drug Safety

A CPOE system needs to generate a medication order for a patient for a medication whose dosage is based on weight. Prior to generating the order, the system will query the EMR for the most recent weight measurements of the patient to determine the correct dose. The system also request information about the patient's current problems, medications and allergies to perform drug interaction checking before completing the order.

Public Health, Biosurveillance, and Disease Registries

During a routing pediatric visit, a pediatric patient is immunized. Upon completion of the visit, a reporting application is notified. The reporting application queries the EMR visit data to see if any immunizations were given during the just completed visit. If an immunization was given during the visit, the reporting application collects the appropriate data and submits it to an immunization registry.

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

Query Vital Signs
Request information about recent patient measurements, usually used to obtain vital signs measurements. The query may request all measurements, or those taken for a specific encounter, or date range, or may be for a specific set of measurements.
Query Problems and Allergies
Request information about problems or allergies known for a patient, usually to determine the patients current problems and allergies. The query may request information about all problems, all allergies, or may request information on a specific problem or allergy entry, entered during a specific encounter or date range.
Query Lab Results
Request information about lab results known for a patient. The query may request information about all lab results, or may request information on a specific kind of lab result entry, or one entered for a specific encounter or date range.
Query Medications and Immunizations
Request information about medications and immunizations given to, or being taken by a patient. The query may request information about all medications, all immunizations, or may request information on a specific kind of medication or immunization, or one entered for a specific encounter or date range.

Volume II

Query Vital Signs

Use Case Roles

Qcdqvs.png

Actor
Clinical Data Consumer
Role
Requests a list of vital signs matching a minimal set of selection criteria from the Clinical Data Source.
Actor
Clinical Data Source
Role
Returns vital signs measurements matching the selection criteria supplied by the Clinical Data Consumer.

Referenced Standards

Interaction Diagrams

Qcdpmo.png

Trigger Events

The Clinical Data Consumer's need to obtain vital sign information about a patient will trigger the query, based on the following HL7 trigger event: POOO_TE000009UV -- Patient Measured Information Requested

Message Semantics

Expected Actions Role 1
Expected Actions Role 2

Query Problems and Allergies

Use Case Roles

Qcdqpa.png

Actor
Clinical Data Consumer
Role
Requests a list of problems or allergies for a given patient matching a minimal set of selection criteria from the Clinical Data Source.
Actor
Clinical Data Source
Role
Returns problems or allergy entries for a given patient matching the selection criteria supplied by the Clinical Data Consumer.

Query Lab Results

Use Case Roles

Qcdqlr.png

Actor
Clinical Data Consumer
Role
Requests a list of lab results for a given patient matching a minimal set of selection criteria from the Clinical Data Source.
Actor
Clinical Data Source
Role
Returns lab results for a given patient matching the selection criteria supplied by the Clinical Data Consumer.

Query Medications and Immunizations

Use Case Roles

Qcdqmi.png

Actor
Clinical Data Consumer
Role
Requests a list of medications or immunizations for a given patient matching a minimal set of selection criteria from the Clinical Data Source.
Actor
Clinical Data Source
Role
Returns medications or immunizations for a given patient matching the selection criteria supplied by the Clinical Data Consumer.