Pharm Tech Minutes 2016.06.28

From IHE Wiki
Jump to: navigation, search

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.

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