Query for Existing Data
Introduction
This is a draft of the Query for Existing Data Profile (QED) 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 Existing Data Profile (QED) 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.
Volume I
Add the following bullet to the list of profiles
- Query for Existing Data - This profile (QED) 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 Existing Data | Audit Trail and Node Authentication | Each actor in this profile 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 Existing Data | Consistent Time | Each actor in this profile shall be grouped with the Time Client Actor | Required to manage and resolve conflicts in multiple updates. |
Profile Name
The Query for Existing Data Profile (QED) 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.
Disease Management
A physician wants to monitor a patient's blood sugar levels. She requests the patient's blood sugar lab results (lab) and BMI (vital signs) for the past 9 months, and uses a desktop application to graph them.
Actors/Transaction
There are six actors in this profile, the Clinical Data Consumer, and five different repositories of clinical data, including vitals, problems and allergies, diagnostic results, medications, and immunizations.
The table below 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 | Name | Optionality | Transaction |
|---|---|---|---|
| Clinical Data Consumer | Query Vital Signs | O1 | PCC-1 |
| Query Problems and Allergies | O1 | PCC-2 | |
| Query Lab Results | O1 | PCC-3 | |
| Query Medications | O1 | PCC-4 | |
| Query Immunizations | O1 | PCC-5 | |
| Vital Signs Data Repository | Query Vital Signs | R | PCC-1 |
| Problems and Allergies Repository | Query Problems and Allergies | R | PCC-2 |
| Diagnostic Data Repository | Query Diagnosic Data | R | PCC-3 |
| Medications Repository | Query Medications | R | PCC-4 |
| Immunizations Repository | Query Immunizations | R | PCC-5 |
Note 1: The Actor shall support at least one of these transactions.
Options
| Actor | Option |
|---|---|
| Clinical Data Source | None Defined |
| Clinical Data Consumer | Vital Signs Option |
| Problems and Allergies Option | |
| Lab Results Option | |
| Medications Option | |
| Immunizations Option |
Vital Signs Option
A Clinical Data Consumer that implements the Vital Signs Option implements the Vital Signs Query transaction.
Problems and Allergies Option
A Clinical Data Consumer that implements the Problems and Allergies Option implements the Problems and Allergies Query transaction.
Lab Results Option
A Clinical Data Consumer that implements the Lab Results Option implements the Lab Results Query transaction.
Medications Option
A Clinical Data Consumer that implements the Medications Option implements the Medications Query transaction.
Immunizations Option
A Clinical Data Consumer that implements the Immunizations Option implements the Immunizations transaction.
Grouping
Clinical Data Repositories
Any of the repository actors of this profile can be grouped with other repository actors. For example, an EMR might implement all of the repository actors of this profile, while a pharmacy system might implement only the Immunizations and Medications Repository actors.
When actors are grouped in this fashion, it is expected that they will provide appropriate join fields to show relationships between different records.
Audit Trail and Node Authentication and Consistent Time
All actors of this profile shall be grouped with either the Secure Node or the Secure Application actor, to ensure the security of the information being exchanged. These actors shall also implement Time Client to ensure that consistent time is maintained across systems.
TBD -- what specifically are the logging requirements under this profile
- Login/Logout
- Actor Start/Stop
- Query
- Import (if the reciever imports the queried data)
- Export
Retrieve 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 all documents used in generating the results.
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.
Patient Identity Cross Referencing and Patient Demographics Query
A clinical data consumer may be grouped with a Patient Identifier Cross-reference Consumer or a Patient Demographics Consumer actor to resolve patient identifiers prior to submitting queries to a Clinical Data Source.
Within an enterprise, the need to cross-reference patient identifiers may not be necessary. However, once enterprise boundaries are crossed, these identifiers will need to be resolved. In that case either, PIX or PDQ shall be used.
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 using [PCC-4] where the patient 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 using [PCC-1], 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 using [PCC-1]. The system also request information about the patient's current problems and allergies using [PCC-3], and medications using [PCC-4] 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 using [PCC-5]. If an immunization was given during the visit, the reporting application collects the appropriate data and submits it to an immunization registry.
Quality Reports and Disease Management
A diabetic patient completes a routing visit. During the visit the EMR queries a Lab Result Repository to determine if a recent HgA1C result is available from the last six months using [PCC-2]. Upon failing to find one the EMR notifies the physician that an updated test is required.
Actor Definitions
- Clinical Data Consumer
- A clinical data consumer makes use of clinical patient data.
- Vital Signs Data Repository
- A Vital Signs Data Repository maintains patient vital signs data.
- Problems and Allergies Repository
- A Problems and Allergies Repository maintains patient problem and allergy data.
- Diagnostic Data Repository
- A Diagnostic Data Repository Repository maintains results from diagnostic tests (e.g., Lab, Imaging, or other test results).
- Medications Data Repository
- A Medications Data Repository maintains patient medication data.
- Immunizations Data Repository
- An Immunizations Data Repository maintains patient immunization data.
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
- Actor
- Clinical Data Consumer
- Role
- Requests a list of vital signs matching a minimal set of selection criteria from the Vitals Signs Repository.
- Actor
- Vitals Signs Repository
- Role
- Returns vital signs measurements matching the selection criteria supplied by the Clinical Data Consumer.
| style='border: 1px solid black;' | Actor 1 | style='border: 1px solid black;' | Actor 2 | |
| colspan=3 | File:Usecase.wmf |
Referenced Standards
Interaction Diagrams
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: QUPC_TE043100UV -- Query Care Record Event Profile Query
Message Semantics
The Query Care Record Event Profile Query cooresponds to the HL7 Interaction QUPC_IN043100UV.
Expected Actions -- Clinical Data Consumer
The clinical data consumer shall send a query as specified in the QUPC_MT040300UV message type.
The message supports specification of the data items listed in the table below as query parameters. The first column of this table provides the name of the parameter. The next column indicates the number of times it may occur in the query. The next column indicates the type of data expected for the query parameter. The next column indicates the vocabulary domain used for coded values. The final column indicates whether the Service must support this parameter. A Clinical Data Consumer may supply parameters other than those required by this profile, but must appropriately handle any detected issue alert raised by the Vital Signs Data Repository in its response.
| Parameter Name | Cardinality | Data Type | Vocabulary Domain | Opt |
|---|---|---|---|---|
| careProvisionCode | 0..1 | CD | R | |
| careProvisionReason | 0..* | CD | O | |
| careRecordTimePeriod | 0..1 | IVL<TS> | R | |
| clinicalStatementTimePeriod | 0..1 | IVL<TS> | R | |
| includeCarePlanAttachment | 0..1 | BL | R | |
| maximumHistoryStatements | 0..1 | INT | R | |
| patientAdministrativeGender | 0..1 | CE | AdministrativeGender | R |
| patientBirthTime | 0..1 | TS | R | |
| patientId | 1..1 | II | R | |
| patientName | 0..1 | PN | R |
Each of the parameters is described in more detail below.
careProvisionCode
This element describes the information that is being looked for. All Vital Signs Data Repository actors are required to support the value COBSCAT from the HL7 ActCode domain. When this value is used, it indicates that all vital signs are to be reported up to the maximum number specified in maximumHistoryStatements for each vital sign.
Specific vital signs may also be requested using the LOINC codes found in Vital Signs Observation.
careProvisionReason
This element identifies the reason why the observation was recorded. If specified, only those observation values which are recorded for the specified reason will be returned.
careRecordTimePeriod
This element describes the time period over which the vital signs observations were recorded. A query could for example, request new entries that have been processed for this patient since the last query request. If specified, only those observations that were recorded within the specified time period will be returned.
clinicalStatementTimePeriod
This element describes the effective time for the clinical statement. If specified, only those observations that were effective within the clinical statement effective time will be returned.
includeCarePlanAttachment
This element is set to either true or false depending upon whether care plans should be returned or not. A Vital Signs Data Repository may choose not to honor this request when the value is set to true, but must then raise a detected issue alert. Note that most vital signs data repositories will not associate a care plan attachment with a specific observation measure.
maximumHistoryStatements
This value indicates the maximum number of history statements that will be returned by the query. No more than the maximum number will be returned. This value is NOT the maximum number of clinical statements returned, rather it is the maximum number of clinical statements returned for individual type of clinical statement specified in the careProvisionCode. Thus, if all vital signs are requested (careProvisionCode/code/@code = "COBSCAT"), and maximumHistoryStatements/value/@value = 1, you will receive the most current value for each vital sign requested.
patientAdministrativeGender
The patient gender may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient gender of the patient specified in patientId. If the two values do not match, the Vital Signs Data Repository will raise a detected issue alert.
patientBirthTime
The patient birth time may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient birth time of the patient specified in patientId. If the two values do not match, the Vital Signs Data Repository will raise a detected issue alert.
patientId
The patient identifier shall be specified in this element.
patientName
The patient name may be provided in the query. If provided, it serves as a verification of the patient identity. The value must match the patient name of the patient specified in patientId. If the two values do not match, the Vital Signs Data Repository will raise a detected issue alert.
Expected Actions -- Vitals Signs Data Repository
The Vital Signs Data Repository, shall:
- Recieve and validate the query
- Raise a NAT detected issue alert if the requesting party is not authorized to perform the query.
- Raise a VALIDAT detected issue alert if the patientName, patientGenderCode or patientBirthTime do not match the values known by the Vital Signs Data Repository Actor.
- Raise a BUS detected issue alert if includeCarePlanAttachment is true, but care plans are not associated with observation values.
- Raise a BUS detected issue alert if a careProvisionReason value is specified, but the Vital Signs Data Repository cannot query by this field.
- Raise a BUS detected issue alert if any of the vocabulary domains are not recognized by the Vital Signs Data Repository.
- Raise a FORMAT detected issue alert if any date ranges are incorrectly formed (low > high).
- Raise a ILLEGAL detected issue alert if the the vital signs data repository does not recognize the identity domain used to
identify the patient.
- Raise a KEY204 detected issue alert if the the vital signs data repository does not know about the patient. This is distict from having nothing to report. If the patient is recognized but there is no data to report, the result returned should simply have no data. However, if information is requested for a patient that isn't known, then the KEY204 alert shall be raised.
- Query for the data requested by the query.
- Return the query results up to the maximum number of history statements requested.
A conforming Vitals Signs Data Repository shall support those parameters that have an R in the table above, and need not support those query parameters that have an O in this column. Clinical Data Consumers may use the parameters with an R without expectation of any failure.
Raising Alerts
If the requesting party is not authorized to perform the query, the minimum response shall be sent indicating only that the requested is not authorized to perform the query. In other cases, all possible alerts shall be accumulated before returning a response to the caller.
This enables Clinical Data Consumer actors to send a test query that will enable them to verify the vocabulary and other request parameters that are desired.
An alert is raised by sending an response where:
queryAck/queryResponseCode/@code = "QE"
One or more ControlActProcess/detectedIssue elements are returned.
Each detectedIssue element identifies the error in detectedIssue/code
The erroneous parameter shall be identified in detectedIssue/text using the element name, and nothing else should be present in detectedIssue/text.
| For Public Comment | Ideally, there should be a way for the Clinical Data Consumer to determine what vocabularies are supported by a repository. The detectedIssue element could return the list of vocabularies supported in some way. |
Query Problems and Allergies
Use Case Roles
- 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 Problem and Allergy Repository.
- Actor
- Problem and Allergy Repository
- 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
- Actor
- Clinical Data Consumer
- Role
- Requests a list of lab results for a given patient matching a minimal set of selection criteria from the Lab Result Repository.
- Actor
- Lab Result Repository
- Role
- Returns lab results for a given patient matching the selection criteria supplied by the Clinical Data Consumer.
Query Medications
Use Case Roles
- Actor
- Clinical Data Consumer
- Role
- Requests a list of medications for a given patient matching a minimal set of selection criteria from the Medications Repository.
- Actor
- Medications Repository
- Role
- Returns medications for a given patient matching the selection criteria supplied by the Clinical Data Consumer.
Query Immunizations
Use Case Roles
- Actor
- Clinical Data Consumer
- Role
- Requests a list of immunizations for a given patient matching a minimal set of selection criteria from the Immunizations Repository.
- Actor
- Immunizations Repository
- Role
- Returns immunizations for a given patient matching the selection criteria supplied by the Clinical Data Consumer.