Pharm Tech Minutes 2016.06.28

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

CP-PHARM-101 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

• 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
• 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:

1. request scan code
2. send scanned code
3. 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.

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

16:45 - Adjourn

Pharmacy Technical Committee