Difference between revisions of "Pharm Tech Minutes 2016.02.16"

From IHE Wiki
Jump to: navigation, search
Line 28: Line 28:
 
In terms of IHE transactions, options 2a, 3 require that the "checking" and the "final receiving" are done in the same actor because there is only one transaction which requires only one receiving actor.
 
In terms of IHE transactions, options 2a, 3 require that the "checking" and the "final receiving" are done in the same actor because there is only one transaction which requires only one receiving actor.
 
* How to deal with repudiation? (i.e. nurse can say "i didn't receive any notice")
 
* How to deal with repudiation? (i.e. nurse can say "i didn't receive any notice")
 
 
We will revisit this in the FHIR since FHIR has a mechanism being prepared for this.
 
We will revisit this in the FHIR since FHIR has a mechanism being prepared for this.
  
Line 35: Line 34:
 
* [ftp://ftp.ihe.net/Pharmacy/yr7_2015-2016/Technical_Committee/Other/ISO%20Medication%20Management,%20TR%2020831/]
 
* [ftp://ftp.ihe.net/Pharmacy/yr7_2015-2016/Technical_Committee/Other/ISO%20Medication%20Management,%20TR%2020831/]
  
* [http://wiki.ihe.net/index.php?title=File:MedicationManagementConcepts.docx http://wiki.ihe.net/index.php?title=File:MedicationManagementConcepts.docx]
+
The most important and addressable term is "administration" since we do not have "statement" in our scope yet.
* Review of comments
+
[ftp://ftp.ihe.net/Pharmacy/yr6_2014-2015/Technical_Committee/Whitepapers/MedicationManagement/MedicationManagementRelatedConceptsandDefinitions_2014.10.02_LTz_JCT.docx ftp://ftp.ihe.net/Pharmacy/yr6_2014-2015/Technical_Committee/Whitepapers/MedicationManagement/MedicationManagementRelatedConceptsandDefinitions_2014.10.02_LTz_JCT.docx]
+
* Glossary
+
  
* ISO DTR 20831 and ISO TC215 WG6 follow-up (Michael)
 
* Medication data collection - proposal review (José)
 
* Discussion
 
* Defining next steps
 
  
  
 
= 12:30 - 13:30 - Lunch =
 
= 12:30 - 13:30 - Lunch =
 +
 +
Proposed definition from IHE to SKMT:
 +
'''The application of a pharmaceutical product to the subject of care.'''
 +
Motion Stéphane / Juergen
 +
Approved unanimously
 +
 +
 +
Definition of statement:
 +
Discussion on scope: Example: How do we report "I never take this because i feel bad when I do".
 +
 +
* Patient statement can declare an Administration or Prescriptions or Dispense act.
 +
* Patient statement may include observations and conclusions regarding the admin, presc and disp.
 +
* Patient statement may refer to an administration recorded by a HCP (does not include own medication information but just conclusions)
 +
* Statement can be by patient or by others
 +
 +
Proposed definition:
 +
Medication Statement
 +
'''A declaration given by the subject of care or a third party, about the usage or non-usage of a pharmaceutical product by the subject of care. The primary information is about the medication, but it may include supporting information about observations and conclusions, for example reasons for diverging from the intended dosage. '''
 +
Motion to approve for SKMT and eventually IHE glossary:
 +
Stephane / Juergen
 +
Approved unanimously (0-0-6).
  
 
= 13:30 - 15:30 - Strategy for IHE profiles with FHIR =
 
= 13:30 - 15:30 - Strategy for IHE profiles with FHIR =
 
* Discussion where FHIR resources and REST concept can be useful for IHE Pharmacy.
 
* Discussion where FHIR resources and REST concept can be useful for IHE Pharmacy.
 +
** Transport paradigm - RESTFUL , servers, etc.
 +
** Current status of relevant resources
 +
** IHE strategy: Documentation management: DSTU vs final...
 +
 +
 +
FHIR:
 +
* Issues with FHIR: moving specification
 +
* Even ITI has not yet provided a full transport architecture. Do we need this?
 +
** '''The work done on FHIR must be aligned (reusing if possible) with the work on ITI'''
 +
** '''Using the FHIR standards must be discussed with ITI'''
 +
 +
Topics for tomorrow' joint discussion with ITI, PCC, QRPH:
 +
Part 1: * Is there a FHIR profile template?
 +
 +
Part 2: We will discuss with you a simple tentative profile, e.g. Administration:
 +
(The core Resource already exists in HL7 FHIR)
 +
* Client retrieves Administration Instructions from server
 +
* Client puts the Administration report on the server
 +
 +
Questions:
 +
* Do we make / do we need to make an generic access mechanism for FHIR data?
 +
** e.g. a new generic "ITI-FHIR100 - Submit resource to FHIR server" As equivalent to ITI-41 Provide and register document set to ebXML.
 +
 +
* How do we handle "server pushes data to client"?
 +
** Should that be profiled by ITI? Or leave to everyone? Or is it already covered?
  
= 15:30 - 16:00 - Break =
 
  
 
= 16:00 - 16:30 Board report and preparation of tomorrows's Joint Meeting =
 
= 16:00 - 16:30 Board report and preparation of tomorrows's Joint Meeting =

Revision as of 11:10, 16 February 2016

Meeting Minutes

10:00 - 10:30 Welcome

Participants

  • Juergen Brandstaetter
  • Leonidas Tzimis
  • Michael Tan
  • José Costa Teixeira
  • Stéphane Spahni
  • Jacqueline Surugue
  • Marc Robberecht (Webex)
  • Esther Peelen (Webex)

Approval of Geneva F2F Minutes

Motion to approve minutes as they are: Juergen / Stéphane 0-0-7

10:30 - 11:30 Supply topics, Part 1

  • Pending Issues of White Paper Supply
  • Barcoding profile

Matter of "tentative" administration Open options:

  Option 1: Submit a question "can this be done?", waiting and providing real action
  Option 2a: Submit first a provisional admin, and then decide whether to send final (same transaction with flag)
  Option 2b: Same as 2a, but two different transactions without flag 
  Option 3: Submit the final administration, and if a problem exists, there is an exception workflow

In terms of IHE transactions, options 2a, 3 require that the "checking" and the "final receiving" are done in the same actor because there is only one transaction which requires only one receiving actor.

  • How to deal with repudiation? (i.e. nurse can say "i didn't receive any notice")

We will revisit this in the FHIR since FHIR has a mechanism being prepared for this.

11:30 - 12:30 Medication Documentation

  • Document "Medication Management Related Concepts and Definitions" (Michael)
  • [1]

The most important and addressable term is "administration" since we do not have "statement" in our scope yet.


12:30 - 13:30 - Lunch

Proposed definition from IHE to SKMT: The application of a pharmaceutical product to the subject of care. Motion Stéphane / Juergen Approved unanimously


Definition of statement: Discussion on scope: Example: How do we report "I never take this because i feel bad when I do".

  • Patient statement can declare an Administration or Prescriptions or Dispense act.
  • Patient statement may include observations and conclusions regarding the admin, presc and disp.
  • Patient statement may refer to an administration recorded by a HCP (does not include own medication information but just conclusions)
  • Statement can be by patient or by others

Proposed definition: Medication Statement A declaration given by the subject of care or a third party, about the usage or non-usage of a pharmaceutical product by the subject of care. The primary information is about the medication, but it may include supporting information about observations and conclusions, for example reasons for diverging from the intended dosage. Motion to approve for SKMT and eventually IHE glossary: Stephane / Juergen Approved unanimously (0-0-6).

13:30 - 15:30 - Strategy for IHE profiles with FHIR

  • Discussion where FHIR resources and REST concept can be useful for IHE Pharmacy.
    • Transport paradigm - RESTFUL , servers, etc.
    • Current status of relevant resources
    • IHE strategy: Documentation management: DSTU vs final...


FHIR:

  • Issues with FHIR: moving specification
  • Even ITI has not yet provided a full transport architecture. Do we need this?
    • The work done on FHIR must be aligned (reusing if possible) with the work on ITI
    • Using the FHIR standards must be discussed with ITI

Topics for tomorrow' joint discussion with ITI, PCC, QRPH: Part 1: * Is there a FHIR profile template?

Part 2: We will discuss with you a simple tentative profile, e.g. Administration: (The core Resource already exists in HL7 FHIR)

  • Client retrieves Administration Instructions from server
  • Client puts the Administration report on the server

Questions:

  • Do we make / do we need to make an generic access mechanism for FHIR data?
    • e.g. a new generic "ITI-FHIR100 - Submit resource to FHIR server" As equivalent to ITI-41 Provide and register document set to ebXML.
  • How do we handle "server pushes data to client"?
    • Should that be profiled by ITI? Or leave to everyone? Or is it already covered?


16:00 - 16:30 Board report and preparation of tomorrows's Joint Meeting

16:30 - 17:30 Educational track

  • Review of educational material
  • Identify action items on educational material

17:30 - Adjourn

Pharmacy Planning Committee