Difference between revisions of "Pharm Tech Minutes 2017.02.07"
| Line 60: | Line 60: | ||
! Patient 2 | ! Patient 2 | ||
! Patient 3 | ! Patient 3 | ||
| − | |||
|- | |- | ||
| Period 1 | | Period 1 | ||
| Line 66: | Line 65: | ||
| Team 1 | | Team 1 | ||
| Team 2 | | Team 2 | ||
| − | |||
|- | |- | ||
| Period 2 | | Period 2 | ||
| Line 72: | Line 70: | ||
| Team 2 | | Team 2 | ||
| Team 2 | | Team 2 | ||
| − | |||
|- | |- | ||
| Period 3 | | Period 3 | ||
| Line 78: | Line 75: | ||
| Team 4 | | Team 4 | ||
| Team 4 | | Team 4 | ||
| − | |||
|} | |} | ||
Revision as of 05:46, 8 February 2017
Meeting Minutes
10:00 - 10:30 Welcome
Participants
- 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 | Team 1 | Team 1 | Team 2 |
| Period 2 | Team 3 | Team 2 | Team 2 |
| Period 3 | Team 3 | Team 4 | Team 4 |
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.