@@ Line 1: / Line 1: @@
-=Introduction=
+#redirect [[PCC TF-1/QED]]
-''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.''
-__TOC__
-==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=
-<pre>Add the following bullet to the list of profiles</pre>
-* 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===
-<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 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.
-|- style='background-color:#ffffff;' align='center'
-|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.
-===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.
-[[image:Qcd.png|frame|center|Query for Existing Data Actor Diagram]]
-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 | Options]].
-{|style='background-color:#D9D9D9;' align='center' border='1' cellspacing='0'
-!Actor
-!Name
-!Optionality
-!Transaction
-|+Query for Existing Data Actors and Transactions
-|- style='background-color:#ffffff;' align='center'
-| rowspan='5'|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 Diagnostic Data| Query Diagnostic Data]]
-| O<sup>1</sup>
-| PCC-3
-|- style='background-color:#ffffff;' align='center'
-| [[#Query Medications | Query Medications]]
-| O<sup>1</sup>
-| PCC-4
-|- style='background-color:#ffffff;' align='center'
-| [[#Query Immunizations | Query Immunizations]]
-| O<sup>1</sup>
-| PCC-5
-|- style='background-color:#ffffff;' align='center'
-| Vital Signs Data Repository
-| [[#Query Vital Signs | Query Vital Signs]]
-| R
-| PCC-1
-|- style='background-color:#ffffff;' align='center'
-| Problems and Allergies Repository
-| [[#Query Problems and Allergies | Query Problems and Allergies]]
-| R
-| PCC-2
-|- style='background-color:#ffffff;' align='center'
-| Diagnostic Data Repository
-| [[#Query Diagnosic Data | Query Diagnosic Data]]
-| R
-| PCC-3
-|- style='background-color:#ffffff;' align='center'
-| Medications Repository
-| [[#Query Medications | Query Medications]]
-| R
-| PCC-4
-|- style='background-color:#ffffff;' align='center'
-| Immunizations Repository
-| [[#Query Immunizations | Query Immunizations]]
-| R
-| PCC-5
-|}
-Note <sup ID=note1>1</sup>: The Actor shall support at least one of these transactions.
-=== Options ===
-{|style='background-color:#ffffff;' border='1' cellspacing='0'
-!align='center' style='background-color:#cfcfcf;' |Actor
-!align='center' style='background-color:#cfcfcf;' |Option
-|+Query for Existing Data Options
-|-
-|Clinical Data Source
-|''None Defined''
-|-
-|rowspan='5'|Clinical Data Consumer
-|[[#Vital Signs Option|Vital Signs Option]]
-|-
-|[[#Problems and Allergies Option|Problems and Allergies Option]]
-|-
-|[[#Lab Results Option|Lab Results Option]]
-|-
-|[[#Medications Option|Medications Option]]
-|-
-|[[#Immunizations 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 | 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 ===
-[[Image:Qcdseq.png|frame|center|Query for Existing 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 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 Diagnostic Data : Request information about diagnostic results known for a patient.  The query may request information about all diagnostic results, or may request information on a specific diagnostic result entry, or one entered for a specific encounter or date range.
-; Query Medications : Request information about medications given to, or being taken by a patient.  The query may request information about all medications or may request information on a specific kind of medication or immunization, or one entered for a specific encounter or date range.
-; Query Immunizations  : Request information about immunizations given to a patient.  The query may request information about all immunizations, 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 ===
-{{Use Case Roles
-|Clinical Data Consumer|Requests a list of vital signs matching a minimal set of selection criteria from the Vitals Signs Repository.
-|Vitals Signs Data Repository|Returns vital signs measurements matching the selection criteria supplied by the Clinical Data Consumer.
-|Tx=Query Vital Signs}}
-=== Referenced Standards ===
-{|
-{{Std|CareRecord}}
-{{Std|CareQuery}}
-{{Std|HL7WS|HL7 Version 3 Standard: Transport Specification - Web Services Profile, Release|http://www.hl7.org/v3ballot/html/infrastructure/transport/transport-wsprofiles.htm}}
-{{Std|WSDL|Web Services Descrition Language (WSDL 1.1)|http://www.w3.org/TR/wsdl}}
-{{Std|SOAP|Simple Object Access Protocol (SOAP 1.1)|http://www.w3.org/TR/2000/NOTE-SOAP-20000508/}}
-|}
-=== Interaction Diagrams ===
-[[Image:Qcdpmo.png]]
-==== Trigger Events ====
-The Clinical Data Consumer's need to obtain information about a patient will trigger the query, based on the following HL7 trigger event: [http://www.hl7.org/v3ballot/html/domains/uvpc/uvpc_CareRecordQuery.htm#QUPC_TE043100UV-te QUPC_TE043100UV] -- Query Care Record Event Profile Query
-==== Message Semantics ====
-The Query Care Record Event Profile Query cooresponds to the HL7 Interaction
-[http://www.hl7.org/v3ballot/html/domains/uvpc/vpc_CareRecordQuery.htm#QUPC_IN043100UV-int QUPC_IN043100UV].
-===== Expected Actions -- Clinical Data Consumer =====
-# The clinical data consumer shall send a query as specified in the [http://www.hl7.org/v3ballot/html/domains/uvpc_CareRecordQuery.htm#QUPC_MT040300UV-msg QUPC_MT040300UV] message type.
-# The clinical data consumer processes the query response data.  If the response indicates that more data is available, the clinical data consumer can request additional data using the General Query Activate Query Continue message, indicating which data is being requested.
-# Upon completion of all result processing, the clinical data consumer should send a General Query Query Cancel message to indicate to the server that futher query results are not needed.
-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.
-{| border='1' cellspacing='0'
-|-align='center' bgcolor='#D9D9D9'
-! Parameter Name!!Cardinality!!Data Type!!Vocabulary Domain!!Consumer!!Repository
-|+Query Parameters
-|-
-|[[#careProvisionCode|careProvisionCode]]||0..1||CD||&nbsp;||O||R
-|-
-|[[#careProvisionReason|careProvisionReason]]||0..*||CD||&nbsp;||O||O
-|-
-|[[#careRecordTimePeriod|careRecordTimePeriod]]||0..1||IVL<TS>||&nbsp;||O||R
-|-
-|[[#clinicalStatementTimePeriod|clinicalStatementTimePeriod]]||0..1||IVL<TS>||&nbsp;||O||R
-|-
-|[[#includeCarePlanAttachment|includeCarePlanAttachment]]||0..1||BL||&nbsp;||R||R
-|-
-|[[#maximumHistoryStatements|maximumHistoryStatements]]||0..1||INT||&nbsp;||O||R
-|-
-|[[#patientAdministrativeGender|patientAdministrativeGender]]||0..1||CE||AdministrativeGender||O||R
-|-
-|[[#patientBirthTime|patientBirthTime]]||0..1||TS||&nbsp;||O||R
-|-
-|[[#patientId|patientId]]||1..1||II||&nbsp;||R||R
-|-
-|[[#patientName|patientName]]||0..1||PN||&nbsp;||O||R
-|}
-Each of the parameters is described in more detail below.
-======careProvisionCode======
-This element describes the information that is being looked for.  When this value is not present, it indicates that all relevant results are to be reported up to the maximum number specified in [[#maximumHistoryStatements|maximumHistoryStatements]] for each result.  Specific results may be requested using the LOINC codes found in {{ILink|Vital_Signs_Observation_code|Vital Signs Observation}}.  These codes must be supported by a conforming repository.
-======careProvisionReason======
-This element identifies the reason why the result was recorded.  If specified, only those results which are recorded for the specified reason will be returned.
-======careRecordTimePeriod======
-This element describes the time period over which the results 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 results 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 results 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 Data Repository may choose not to honor this request when the value is set to true, but must then raise a BUS detected issue alert to indicate that this capability is not supported.  Note that many data repositories will not associate a care plan attachment with a specific result.
-======maximumHistoryStatements======
-This value indicates the maximum number of each type of result 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 results are requested, and maximumHistoryStatements/value/@value = 1, you will receive the most current value for each kind of result 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 Data Repository will raise a detected issue alert.
-===== Domain Content =====
-A Vital Signs Data Repository shall support the following codes:
-COBSCAT
-LOINC Codes defined in
-===== Expected Actions -- Vitals Signs Data Repository =====
-The Data Repository, shall:
-# Recieve and validate the query
-# Create the response message.
-# Add a NAT detected issue alert to the response message if the requesting party is not authorized to perform the query, and immediately return a response indicating the error, and that the query was aborted.
-# Add a VALIDAT detected issue alert to the response message if the patientName, patientGenderCode or patientBirthTime do not match the values known by the Vital Signs Data Repository Actor.
-# Add a BUS detected issue alert to the response message if includeCarePlanAttachment is true, but care plans are not associated with observation values.
-# Add a BUS detected issue alert to the response message if a careProvisionReason value is specified, but the Data Repository cannot query by this field.
-# Add a BUS detected issue alert to the response message if any of the vocabulary domains are not recognized by the Data Repository.
-# Add a FORMAT detected issue alert to the response message if any date ranges are incorrectly formed (low > high).
-# Add a ILLEGAL detected issue alert to the response message if the the data repository does not recognize the identity domain used to identify the patient.
-# Add a KEY204 detected issue alert to the response message if the the 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.
-# If any issues were detected, Set queryAck/statusCode/@code to aborted, and queryAct/queryResponse/@code to QE, and return the response.
-# Query for the data requested by the query.
-# If results are found, set queryAct/queryResponse/@code to OK, otherwise set it to NF.
-# Set queryAck/statusCode/@code to deliveredResponse.
-# Add any results to the response up to the maximum number of history statements requested.
-# If all results have been returned, release the query results.
-# Respond to any requests for additional data when a General Query Activate Query Continue message is sent for any query that was not aborted or otherwise terminated.
-# Release query results when a General Query Query Cancel message is recieved, and respond with a Get Care Record Profile Response that indicates the query has been aborted.  While the query may have already been terminated, this should not raise any error, as there are several reasons why the query may have been terminated that the sender would not be aware of, such as the expiration of a timeout.
-# Raise a KEY204 detected issue alert upon reciept of a General Query Activate Query Continue, or General Query Query Cancel message which does not have a correct query id.
-# Raise a VALIDAT detected issue alert upon reciept of a General Query Activate Query Continue request for a query which was previously aborted.
-# Release query results if no additional messages on the query are recieved within an application configurable timeout value.
-A conforming Data Repository shall support those parameters that have an R in the Repository column from the table above, and need not support those query parameters that have an O in this column.
-====== 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.
-{{Note|Ideally, there should be a way for the Clinical Data Consumer to determine what vocabularies are supported by a Data Repository, to allow for vocabulary negotiation.  The detectedIssue element could return the list of vocabularies supported in some way.|For Public Comment}}
-==Query Problems and Allergies  ==
-=== Use Case Roles ===
-[[Image: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 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 Diagnostic Data ==
-=== Use Case Roles ===
-[[Image:Qcdqlr.png]]
-; Actor: Clinical Data Consumer
-; Role: Requests a list of diagnostic results for a given patient matching a minimal set of selection criteria from the Diagnostic Data Repository.
-; Actor: Diagnostic Data Repository
-; Role: Returns diagnostic results for a given patient matching the selection criteria supplied by the Clinical Data Consumer.
-==Query Medications ==
-=== Use Case Roles ===
-[[Image:Qcdqmd.png]]
-; 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.
-[[Category:Patient Care Coordination]]
-[[Category:Draft Profile Supplement]]
-==Query Immunizations  ==
-=== Use Case Roles ===
-[[Image:Qcdqim.png]]
-; 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.
-[[Category:Patient Care Coordination]]
-[[Category:Draft Profile Supplement]]

Difference between revisions of "Query for Existing Data"

Latest revision as of 22:17, 14 June 2007

Navigation menu

Search