This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Proposal 926: Encounter Query

From HL7Wiki
Jump to navigation Jump to search

This proposal requests for a new topic to be added to the PA domain: the Encounter Query Topic. The basic use-case for this proposal is a query for all active encounters for a given patient identifier. There may be circumstances where one would like to query a subset of the active encounters, or encounters with a status other than active.

The topic is based on a use-case similar to the one underlying the HL7 v2 QRY^Q01. This is a query for two categories of data: patient demographics (covered in v3 by a Patient Registry) and data related to encounter(s). The proposed encounter queries would be valid for any encounter type, which is why we suggest to create a new “Encounter Query” topic.

The use-case for the encounter query has been discussed before (See Proposal 926 on HL7.org). 2005-01-11 PA WGM: Motion #926.3: The committee recognizes this as a valid requirement and will entertain a detailed proposal. (Rene/Louise , 12-0-1)

This proposal is being brought forward by NICTIZ. There is a use-case for its inclusion in AORTA, the Dutch national healthcare infrastructure.

Note that artefact IDs have been assigned for the sake of consistency. Upon acceptance of the proposal PA may wish to assign identifiers according to its own scheme.

Encounter Query Topic

This topic supports the process of querying systems for patient encounters. It;s scope is limited to encounters in event mood. The basic use-case for this proposal is a query for all active encounters for a given patient identifier. There may be circumstances where one would like to query a subset of the active encounters, or encounters with a status other than active.

Future versions of the topic may include:

  • A query for encounter details based on the encounter.id, e.g. a "Get Encounter Details Query".
  • A query for encounters in a mood other than EVN.

Storyboard #1

Purpose

This storyboard demonstrates querying an encounter manager for a list of patient encounters matching a Patient ID and the timeframe the encounters took place.

Diagram

Find Encounters Interaction Diagram

Narrative: Find Encounters Query

Adam Everyman (with Patient ID 8237363) makes an appointment with his new General Practicioner (GP), Dr Particia Primary. Prior to the appointment she queries the regional registry, which contains copies of relevant data from all regional hospitals, to get hold of the patient's history. She also initiates a Find Encounters Query for Mr. Everyman using his patient identifier (8237363), and a timeframe consiting of the last 5 years (date range: 20020301-20070301).

She receives back a Find Encounters Query Response containing 3 matching encounters. An outpatient encounter took place on 20040721 with Dr.Smith in the Good Health Hospital; there was an inpatient encounter which took place from 20050115 up to 20050203 with Dr.Adrian in the Good Health Hospital; and an e-mail consult on 20060823 with dentist Dr.Tootache. The returned information (although not clinical in nature, but administrative) provides her with contextual information for the clinical history. Dr Primary plans to ask Adam about the details of the second encounter.

Storyboard #2

Purpose

This storyboard demonstrates querying an encounter manager for a list of patient encounters based on a query that contains a Patient ID and the ID of a responsible organization.

Diagram

Find Encounters Interaction Diagram

Narrative: Find Encounters Query

Adam Everyman (with Patient ID 8237363) makes an appointment with his new General Practicioner (GP), Dr Particia Primary. Dr Primary asks him about any hospital stays during the last 5 years. Adam Everyman recalls he had an inpatient stay at the Good Health Hospital. He doesn't recall the exact dates of the encounter. She queries the regional registry, which contains copies of relevant data from all regional hospitals, to get hold of the patient's history. She also initiates a Find Encounters Query for Mr. Everyman using his patient identifier (8237363), an indication that she's looking for "inpatient encounters", and the identifier of the Good Health Hospital.

She receives back a Find Encounters Query Response containing 1 matching encounter. An inpatient encounter took place from 20050115 up to 20050203 in the Good Health Hospital with Dr.Adrian as the attending physician. The returned information (although not clinical in nature, but administrative) provides her with contextual information for the clinical history. Dr Primary asks Adam about the details of the encounter and requests his permission to get hold of a copy of the medical records of that encounter.

R-MIMs

Find Encounters Query R-MIM (PRPA_RM900300)

Diagram

Find Encounters Query R-MIM

Description

This RMIM defines content to query an encounter manager for all encounters related to 1 specific patient that match the set of encounter related query parameters. The default values of the parameters are such that all active encounters are returned. The response may potentially return many records so the responseModalityCode, initalQuantity and initialQuantityCode attributes of QueryByParameter and the SortControl class are included in the information model.

QueryByParameter - The entry point to the R-MIM. This class allows the query requester to specify how the query should be processed by the query fulfiller. See the QUQI domain for a description.

SortControl - This class allows the query requester to specify the order in which the server should return multiple results. See the QUQI domain for a description.

ParameterList - This collection of parameter items for the query, similar to the WHERE clause in a SQL query. A query message can include any combination of the parameters. Multiple instances of parameter item are combined with AND logic. Multiple values in the value attribute of a single parameter item instance are combined with OR logic.

  • PatientId (mandatory): Identifies the patient that is the subject of the encounter(s)
  • EncounterStatus (optional, default value "active"): Constrains the response to encounters that have one of the specified statuses, e.g. active, within thye TimeFrame (if any) as specified by the EncounterTimeFrame parameter.
  • TypeOfEncounter (optional): Constrains the response to encounters of one of the specified types, e.g. IMP (inpatient)
  • EncounterTimeframe (optional): Constrains the responses to those encounters that had a status as contained in the EncounterStatus parameter within the timeframe as specified by this parameter. It affects encounters whose effectivetime overlaps with any part of the timeframe specified in this parameter.
    • Note that this parameter does NOT constrain the participations in any way, i.e. if an encounter overlaps with the timeframe specified by this parameter, ALL partcipations -regardless of their effectivetime- shall be returned.
  • CareEventId (optional): Constrains the responses to those encounters associated with the CareEvent specified by the parameter.
  • ResponsibleOrganizationID (optional) Constrains the responses to those encounters where one of the organizations responsible for the encounter is equal to one of the specified IDs in this parameter.

Note: AttendingPhysician has been dropped as a parameter, there is no Dutch use-case for it. It has been replaced by ResponsibleOrganizationID.

Find Encounters Query Response R-MIM (PRPA_RM900350)

Diagram

Message type: new, to be derived from the D-MIM as a generic encounter R-MIM without a fixed encounter type (Act.code). The new R-MIM need not be as detailed as the current Inpatient Encounter D-MIM. The encounter and its partcipations is key to the response structure.

As per PA's request during the WGM, the list of data elements that are NICTIZ use-case requirements:

  • Encounter status, effectiveTime, code
  • Attending physicians (all of them, with status and effectiveTime on the participation)
  • ResponsibleParty (all organizations, with status and effectiveTime on the participation)
  • Admitter
  • Subject / Patient CMET

Description

The Find Encounters Query Response R-MIM defines the message used to report the existence of an encounter in event mood.

Details of the walkthrough can be taken from the current Inpatient topic.

Interactions

Find Encounters Query Interaction (PRPA_IN900300)

Description:

A user initiates a query to an encounter manager requesting all patient encounters that match a particular set of parameters.

  • Transmission Wrapper: Send Message Payload, MCCI_MT000100UV01
  • ControlAct Wrapper: Query Control Act Request : Query By Parameter, QUQI_MT021001UV01
  • Message Type: Find Encounters Query R-MIM, PRPA_MT900300
  • Receiver Responsability: Find Encounters Query Response Interaction, PRPA_IN900350

Find Encounters Query Response Interaction (PRPA_IN900350)

Description:

Upon receipt of the Find Encounters Query Interaction, the encounter manager returns all patient encounters that match the given set of parameters.

  • Transmission Wrapper: Application Level Acknowledgement, MCCI_MT000300UV01
  • ControlAct Wrapper: Query Control Act Response / Acknowledgement, QUQI_MT120001UV01
  • Query Response Type: Find Encounters Query Response R-MIM, PRPA_MT900350
  • Query Definition: Find Encounters Query R-MIM, PRPA_MT900300

Discussion

20070110, WGM, PA committee:

  • Add CareEvent (CMET).id (=Akin to Clinical Path) as a query parameter to add option to serach for Encounters associated with that CareEvent. (done - 20070126)
  • Need to define a new response R-MIM, encounter with history of managed partcipation (attending physician). Constrained to NICTIZ use-case requirements. Rene to send list of data items to PA - PA will create model. (done - 20070126)
  • Timeframe of partcipation would probably have to be within the timeframe of the EncounterTimeframe parameter. Talk to NICTIZ to check use-case. (done, clarified above, 20070126)
  • Possible name change "query for encounters with historic participations". - to distinguish from other use-cases.
    • (20070126) Left up to PA to decide if they wish to rename the interaction. The query contained in this proposal, when querying for active encounters, will return the full history for active encounters. A separate query may have to be defined which just returns the "latest/active" particpations.
  • Add storyboard for q with timeframe, and 1 with att physician (done - 20070125)

Motion: PA agree in ballot cycle, assuming all issues are resolved, and pubs material provided in time (see PA minutes for official wording) (8-0-2)

  • Latest end of February to PA