Difference between revisions of "Pharm Tech Minutes 2016.06.28"
Jump to navigation
Jump to search
m |
|||
(40 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
= Meeting Minutes = | = Meeting Minutes = | ||
− | |||
== Participants == | == Participants == | ||
* Juergen Brandstaetter | * Juergen Brandstaetter | ||
Line 9: | Line 8: | ||
* José Costa Teixeira | * José Costa Teixeira | ||
* Stéphane Spahni | * Stéphane Spahni | ||
− | |||
* Marc Robberecht (Webex) | * Marc Robberecht (Webex) | ||
− | = | + | = 10:00 - 10:30 Welcome = |
− | |||
− | |||
− | |||
* Review and Approve Agenda | * Review and Approve Agenda | ||
+ | ** The agenda is approved | ||
+ | |||
* Approval of minutes of Technical Committee TCon | * Approval of minutes of Technical Committee TCon | ||
+ | ** the minutes of the Tecnical Committee TCon were approved uninamously. | ||
+ | |||
* Review of activities to date, agenda topics (so that we don't bypass topics before time). | * Review of activities to date, agenda topics (so that we don't bypass topics before time). | ||
Line 24: | Line 23: | ||
[ftp://ftp.ihe.net/Pharmacy/TF_Maintenance-2016/CPs/Incoming/CP-PHARM-101.docx CP-PHARM-101] | [ftp://ftp.ihe.net/Pharmacy/TF_Maintenance-2016/CPs/Incoming/CP-PHARM-101.docx CP-PHARM-101] | ||
[ftp://ftp.ihe.net/Pharmacy/TF_Maintenance-2016/CPs/Incoming/CP-PHARM-109.docx CP-PHARM-109] | [ftp://ftp.ihe.net/Pharmacy/TF_Maintenance-2016/CPs/Incoming/CP-PHARM-109.docx CP-PHARM-109] | ||
+ | * CP109: The code generation tools cannot differentiate between Amount of Units of consumable and substitution handling, because they start in a similar way, | ||
+ | * Kai Heitmann suggests to add a template-id to the templates. | ||
+ | * Using template id's is usually combined with the use of a content modules. | ||
+ | * the other issue is the optionality. Jurgen suggests to assign a status SHALL instead. This has to be checked with the Austrian implementation. | ||
+ | * We would have to create mini content modules if we go for the status SHALL. | ||
+ | * This also touches the topic of versioning of templates. PCC has run into issues and have not been able to solve this issue yet. | ||
+ | |||
+ | * CP101: We suggest to keep CP101 as it was. The ommission was already integrated and accepted. Stephane will reverse any change. | ||
= 11:00 - 13:00 Supply = | = 11:00 - 13:00 Supply = | ||
* Pending Issues of White Paper Supply | * Pending Issues of White Paper Supply | ||
+ | ** The white paper has sufficient content and material. This includes the barcode supplement. Only editiorial action to be carried out. | ||
+ | ** The supplement from GS1 has to integrated into the white paper in a white paper format. | ||
+ | ** The next step is to create a profile. | ||
+ | ** In the discussion with HL7 (O&O) an agreement has been made for use of chapter 4 and 17 of HL7v2. | ||
* Supply transactions | * Supply transactions | ||
+ | *In IHE Pharmacy we will concentrate on the functional profile. | ||
+ | ** See powerpoint slides from Jose | ||
+ | *** Resupply request | ||
+ | *** Resupply response | ||
+ | *** Request status check query | ||
+ | *Do we need any transport profiles? In FHIR the REST concept can be used for transportation of resources. | ||
+ | * For the return or recall procedure we have the following transactions. | ||
+ | ** Return permission request | ||
+ | ** Return authorization | ||
+ | ** Recall order | ||
+ | ** Recall order acknowledgement. | ||
+ | * The return permission is also used for example to return stock in case of elapsed date. | ||
+ | * Inventory Transactions; | ||
+ | ** inventory query | ||
+ | ** Stock level report. | ||
+ | ** Consumption or usage report. | ||
+ | |||
* Barcode transactions | * Barcode transactions | ||
+ | * There are 2 barcode transactions: | ||
+ | ** Please read the barcode.The barcode reader returns a string of numbers. | ||
+ | ** Please tell me what this string says. The barcode processor does not interpret the meaning of the string, It only decodes the string. | ||
+ | ** The interpretation is not part of the profile. | ||
+ | * There is also discussion on a seperate transaction where the barcode reader initiates the process and sends a string back. | ||
+ | * The transactions are given names: | ||
+ | # request scan code | ||
+ | # send scanned code | ||
+ | # retrieve scanned code | ||
+ | ** UBP-1 is just the request, UPB-3 is just the response | ||
+ | ** UPP-4 is a synchronous request and response for scan | ||
+ | |||
* FMD | * FMD | ||
+ | ** Chirstian Hay has given input.Jose will send the document out once more to the | ||
+ | ** Every product has to be scanned in a similar way in an IHE compliant manner. | ||
+ | ** This could be at different moments, for example at the point of dispense or at the moment of consumption. | ||
= 13:00 - 14:00 Lunch = | = 13:00 - 14:00 Lunch = | ||
Line 36: | Line 79: | ||
* The Austrian Social Insurance (Responsible for the entire server-part + implementing an API for the client-side) | * The Austrian Social Insurance (Responsible for the entire server-part + implementing an API for the client-side) | ||
+ | ** presented by Rainer Schugerl from the Social Insurance. | ||
+ | ** Seconded by mr.Michael Daimler as technical expert. | ||
+ | |||
* The CompuGroup (which have developed an API for the client-side) | * The CompuGroup (which have developed an API for the client-side) | ||
+ | ** Mr. Karl Holzer is on the Webex | ||
+ | |||
* e-Medication and ELGA | * e-Medication and ELGA | ||
+ | ** Currently in introduction phase starting with 10 pharmacies. There will be affinity domains in Vienna and Steiermark shortly. | ||
+ | ** Many interactions. There is a need for caching, but this is not possible in the current architecture. | ||
+ | ** Also centralized intelligence is recommendable. | ||
+ | ** Provision of Medication List. The system makes a PML. This is an on-demand generated document. | ||
+ | ** This is a centralized complex system. Stephane suggests to look at MTP, This has been discussed in Austria. | ||
+ | ** The central system cannot express the state of the prescriptions on the Medication List. | ||
+ | ** As a patient you cannot hide parts of the medication. You can only provide the whole document or not. | ||
+ | ** Medication safety checking is responsibility of the local care provider. This is not enforced centrally. | ||
+ | ** Apart from the e-medication Austria will also have an e-prescription project. This is a seperate system. The reimbursment process is complex in Austria, because it depends on the situation of the patient. He could have different insurrances and right om reimbursements. | ||
+ | ** Error-messages: the documents are validated, but there is no standard mechanism to handle the error-messages. | ||
+ | * Question whether IHE Pharmacy would be interested in e-Prescription. This would only be feasable if an architect would be funded to create the profile. This would have to be started with a description of the use case. | ||
+ | * CGM is responsible for the central API. The seperate IT vendors do not have to worry of creating a ML. | ||
+ | ** here also the problem of reporting of the errors is recognized. | ||
+ | ** also the consistency of the code (of the medication) in relationship with the description of the medication. | ||
+ | ** There were also issues with the qualifiers of the author of the prescription. | ||
+ | ** Question whether IHE Pharmacy will look into FHIR? | ||
= 15:30 - 16:30 Outreach: Liaison activities and reports, projects = | = 15:30 - 16:30 Outreach: Liaison activities and reports, projects = | ||
− | * IHE DCC conference call ( | + | * IHE DCC conference call |
+ | ** see DCC minutes : ([[IHE_Domain_Coordination_Committee_Teleconference_Minutes_2016-06-28#Domain_Announcements ]]). | ||
+ | ** We have put topics about FHIR transportation and the Supply topic forware. | ||
* ISO | * ISO | ||
− | ** 19256 - Medicinal Product Dictionaries | + | ** 19256 - Medicinal Product Dictionaries |
+ | ** This has relationship with the catalogue profile. | ||
+ | ** There will an IHE transaction for the catalogue. | ||
+ | *** One transaction is a batch update of products. | ||
+ | *** The other transaction is to verify a single product. | ||
** IDMP and its impact on IHE | ** IDMP and its impact on IHE | ||
** 19293 - Dispense record | ** 19293 - Dispense record | ||
Line 48: | Line 118: | ||
* HL7 | * HL7 | ||
* NCPDP - MoU | * NCPDP - MoU | ||
− | |||
= 16:45 - Adjourn = | = 16:45 - Adjourn = |
Latest revision as of 15:50, 29 June 2016
Meeting Minutes
Participants
- Juergen Brandstaetter
- Simon Letellier
- Leonidas Tzimis
- Michael Tan
- José Costa Teixeira
- Stéphane Spahni
- Marc Robberecht (Webex)
10:00 - 10:30 Welcome
- Review and Approve Agenda
- The agenda is approved
- Approval of minutes of Technical Committee TCon
- the minutes of the Tecnical Committee TCon were approved uninamously.
- Review of activities to date, agenda topics (so that we don't bypass topics before time).
10:30 - 11:00 Change proposals
- CP109: The code generation tools cannot differentiate between Amount of Units of consumable and substitution handling, because they start in a similar way,
- Kai Heitmann suggests to add a template-id to the templates.
- Using template id's is usually combined with the use of a content modules.
- the other issue is the optionality. Jurgen suggests to assign a status SHALL instead. This has to be checked with the Austrian implementation.
- We would have to create mini content modules if we go for the status SHALL.
- This also touches the topic of versioning of templates. PCC has run into issues and have not been able to solve this issue yet.
- CP101: We suggest to keep CP101 as it was. The ommission was already integrated and accepted. Stephane will reverse any change.
11:00 - 13:00 Supply
- Pending Issues of White Paper Supply
- The white paper has sufficient content and material. This includes the barcode supplement. Only editiorial action to be carried out.
- The supplement from GS1 has to integrated into the white paper in a white paper format.
- The next step is to create a profile.
- In the discussion with HL7 (O&O) an agreement has been made for use of chapter 4 and 17 of HL7v2.
- Supply transactions
- In IHE Pharmacy we will concentrate on the functional profile.
- See powerpoint slides from Jose
- Resupply request
- Resupply response
- Request status check query
- See powerpoint slides from Jose
- Do we need any transport profiles? In FHIR the REST concept can be used for transportation of resources.
- For the return or recall procedure we have the following transactions.
- Return permission request
- Return authorization
- Recall order
- Recall order acknowledgement.
- The return permission is also used for example to return stock in case of elapsed date.
- Inventory Transactions;
- inventory query
- Stock level report.
- Consumption or usage report.
- Barcode transactions
- There are 2 barcode transactions:
- Please read the barcode.The barcode reader returns a string of numbers.
- Please tell me what this string says. The barcode processor does not interpret the meaning of the string, It only decodes the string.
- The interpretation is not part of the profile.
- There is also discussion on a seperate transaction where the barcode reader initiates the process and sends a string back.
- The transactions are given names:
- request scan code
- send scanned code
- retrieve scanned code
- UBP-1 is just the request, UPB-3 is just the response
- UPP-4 is a synchronous request and response for scan
- FMD
- Chirstian Hay has given input.Jose will send the document out once more to the
- Every product has to be scanned in a similar way in an IHE compliant manner.
- This could be at different moments, for example at the point of dispense or at the moment of consumption.
13:00 - 14:00 Lunch
14:00 - 15:30 Joint meeting with the Austrian e-Medication project group
- The Austrian Social Insurance (Responsible for the entire server-part + implementing an API for the client-side)
- presented by Rainer Schugerl from the Social Insurance.
- Seconded by mr.Michael Daimler as technical expert.
- The CompuGroup (which have developed an API for the client-side)
- Mr. Karl Holzer is on the Webex
- e-Medication and ELGA
- Currently in introduction phase starting with 10 pharmacies. There will be affinity domains in Vienna and Steiermark shortly.
- Many interactions. There is a need for caching, but this is not possible in the current architecture.
- Also centralized intelligence is recommendable.
- Provision of Medication List. The system makes a PML. This is an on-demand generated document.
- This is a centralized complex system. Stephane suggests to look at MTP, This has been discussed in Austria.
- The central system cannot express the state of the prescriptions on the Medication List.
- As a patient you cannot hide parts of the medication. You can only provide the whole document or not.
- Medication safety checking is responsibility of the local care provider. This is not enforced centrally.
- Apart from the e-medication Austria will also have an e-prescription project. This is a seperate system. The reimbursment process is complex in Austria, because it depends on the situation of the patient. He could have different insurrances and right om reimbursements.
- Error-messages: the documents are validated, but there is no standard mechanism to handle the error-messages.
- Question whether IHE Pharmacy would be interested in e-Prescription. This would only be feasable if an architect would be funded to create the profile. This would have to be started with a description of the use case.
- CGM is responsible for the central API. The seperate IT vendors do not have to worry of creating a ML.
- here also the problem of reporting of the errors is recognized.
- also the consistency of the code (of the medication) in relationship with the description of the medication.
- There were also issues with the qualifiers of the author of the prescription.
- Question whether IHE Pharmacy will look into FHIR?
15:30 - 16:30 Outreach: Liaison activities and reports, projects
- IHE DCC conference call
- see DCC minutes : (IHE_Domain_Coordination_Committee_Teleconference_Minutes_2016-06-28#Domain_Announcements ).
- We have put topics about FHIR transportation and the Supply topic forware.
- ISO
- 19256 - Medicinal Product Dictionaries
- This has relationship with the catalogue profile.
- There will an IHE transaction for the catalogue.
- One transaction is a batch update of products.
- The other transaction is to verify a single product.
- IDMP and its impact on IHE
- 19293 - Dispense record
- openMedicine status and meetings
- HL7
- NCPDP - MoU