Difference between revisions of "Pharm Tech Minutes 2016.02.16"
Jump to navigation
Jump to 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/] | ||
| − | + | The most important and addressable term is "administration" since we do not have "statement" in our scope yet. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
= 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? | ||
| − | |||
= 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 12: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