Difference between revisions of "Pharm Tech Minutes 2017.02.07"

From IHE Wiki
Jump to: navigation, search
Line 51: Line 51:
There are 3 prescriptions, one for each of 3 patients.
There are 3 prescriptions, one for each of 3 patients.
Each prescription contains medication that is for Shift 1, Shift 2 and Shift 3
Each prescription contains medication that is for Shift 1, Shift 2 and Shift 3
{| | Patient 1 | Patient 2 | Patient 3
|-Period 1 | Team 1| Team 1 | Team 2
|-Period 2 | Team 3| Team 2 | Team 2
|-Period 3 | Team 3| Team 4 | Team 4
Patient 1 Patient 2 Patient 3
Patient 1 Patient 2 Patient 3

Revision as of 02:17, 8 February 2017

Meeting Minutes

10:00 - 10:30 Welcome


  • Leonidas Tzimis
  • Michael Tan
  • José Costa Teixeira
  • Marc Robberecht

Joining later:

  • Juergen Brandstaetter
  • Jacqueline Surugue
  • Tom de Jong

Approval of Dublin F2F Minutes

Pending action items:

  • Action item: Start organizing (Jacqueline)
  • Action item: Finalize the profiles and make sure that profiles are published (Stephane)
  • Action item: Check possibilities within AGFA Madrid for support in finding meeting space (Marc)
  • Action item: Approach HL7 and ISO to check, if they are willing to meet to such a meeting (Michael)
  • Action item: Deliver text to team until end of October (Jacqueline)
  • Action item: Take care of publishing (Jose)

Motion to approve as is and review pending action items during this F2F: Michael/ Leonidas. Approved by everyone.

Approval of the agenda: Approved

10:00 - Supply - Falsified Medicines Directive paper

  • Document is accepted by the group for publishing
    • Action Item: Jose to initiate publishing
  • Next work item: Short paper on
    • The role of interoperability in optimal stock reordering: a paper that explains how, thanks to standard interoperability, there can be a system that colllets all necessary information about stock status, consumptions, etc, and can from there derive the optimal point of reordering items.
    • Multi-faceted Medication Lists: A paper to explain that instead of defining medication lists upfront, we advise stakeholders to store the "raw data" and then derive any flavour from that data.

11:20 - Supply - Transactions and naming

Intro on scope

  • Jacqueline mentions the existence of Groupements Hospitaliers Territoires in France, a cooperative initiative joining several hospitals
  • Leonidas mentions the concept of the interconnected hospitals in Crete

13:40 Common Profile / FHIR

Requirement: We need to get all the medication requests (planned administration instances for a nurse, or for a robot) Idea: We should ask PCC how they plan to do it for a Care Plan.

Scenario: There are 3 prescriptions, one for each of 3 patients. Each prescription contains medication that is for Shift 1, Shift 2 and Shift 3

} Patient 1 Patient 2 Patient 3 Period 1 Team1 Team1 Team2 Period 2 Team3 Team2 Team2 Period 3 Team3 Team4 Team4 Prescription 1 Spasfon, Phloroglucinol, to be taken at breakfast, lunch and dinner during 7 days = 21 medRequests Prescription 2 Profenid, Ketoprofen, to be taken after breakfast, after lunch and after dinner, for 10 days (Omeprazol, 40 mg, to be taken before the meals) = 30 medRequests Prescription 3 Amoxicillin, to be taken at 7 am, 3 pm, 11 pm, with some food, for 7 days = 21 medRequests We make the following resources: Presc 1 Presc 2 Presc 3 AdmRequest 1.1 (day 1, breakfast) AdmRequest 1.2 (day 1, lunch) AdmRequest 1.3 (day 1, dinner) AdmRequest 1.4 (day 2, breakfast) AdmRequest 1.5 (day 2, lunch) AdmRequest 1.6 (day 2, dinner) AdmRequest 2.1 (day 1, after breakfast) AdmRequest 2.2 (day 1, after lunch) AdmRequest 2.3 (day 1, after dinner) AdmRequest 2.4 (day 2, after breakfast) AdmRequest 2.5 (day 2, after lunch) AdmRequest 2.6 (day 2, after dinner) AdmRequest 3.1 (day 1, 7:00) AdmRequest 3.2 (day 1, 15:00 AdmRequest 3.3 (day 1, 23:00) AdmRequest 3.4 (day 2, 7:00) AdmRequest 3.5 (day 2, 15:00) AdmRequest 3.6 (day 2, 23:00) Prescr= medRequest with intent="order" AdmRequest= medRequest with intent="instance-order" Query: the _query parameter allows to query on any resource element (and eventually, TBC, on related elements). Action item: Jose to push the resources to a server and try and query a medicationRequest on dosageInstruction.when.

Discussion on common functionality:

Definition of Administration event:

The administration of a medicine into a patient’s body, either at a specific point of time or within a period of time. For community, the documentation of this activity is done in the ADM profile. The documentation SHOULD be done immediately after the event has been completed.

Administration event should be able to be APPENDED to each other, to document more complex situations, such as changes in flow rate of perfusions, the need of more than one bag, etc.

Administration periods can be recorded in two different ways: A) We record each single event that the period consists of: start, end, changes... B) At the end of the period, we record what has happened during that period.

In both approaches, you may use the append concept for documenting more complex scenarios.

In the use case of several medications on one single perfusion, we need a grouping mechanism to show the medications are all belonging to the same procedure.

Not Given

The data elements shall forsee a "not given" flag, to indicate that an administration was not performed. If possible, a place for a reason (e.g in some kind "Administration information").

Definition of Administration statement:

"A declaration given by the subject of care or a third party about the usage or non-usage of medication.". Basic difference to administration event is, that a statement does refer to a secific event, but is a more general statement.

Pharmacy Planning Committee