Difference between revisions of "Pharm Tech Minutes 2016.11.03"

From IHE Wiki
Jump to navigation Jump to search
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== Participants ==  
 
== Participants ==  
Stéphane Spahni
+
:*Stéphane Spahni
Simon Letellier
+
:*Simon Letellier
Leonidas Tzimis
+
:*Leonidas Tzimis
Michael ...?
+
:*Michael Dobrindt
Jose Costa Teixeira
+
:*Jose Costa Teixeira
  
 
== Minutes ==
 
== Minutes ==
Line 13: Line 13:
 
To be decided later
 
To be decided later
  
Discussion on transactions for "product lookup" (cf attachment):
+
Discussion on transactions for "product lookup" (cf [ftp://ftp.ihe.net/Pharmacy/yr8_2016-2017/Technical%20Committee/Whitepapers/Supply%20of%20products%20for%20healthcare/Supply%20-%203-11-2016%20-%20Scenarios%20for%20barcode%20lookup.pptx attachment]):
 +
 
 
There are several occasions when a product is looked up, to get additional information. Typically this is:
 
There are several occasions when a product is looked up, to get additional information. Typically this is:
 
* Inventory information (i.e. related to a specific physical item) - Examples: Falsified medicines check (a serial number may be considered "suspect").
 
* Inventory information (i.e. related to a specific physical item) - Examples: Falsified medicines check (a serial number may be considered "suspect").

Latest revision as of 17:34, 3 November 2016

Participants

  • Stéphane Spahni
  • Simon Letellier
  • Leonidas Tzimis
  • Michael Dobrindt
  • Jose Costa Teixeira

Minutes

Discussion on barcode transactions: we started by confirming the transactions UBP-1 to UBP-3. These are barcode-related. Open question: Is UBP-3 the same as UBP-1? To be decided later

Discussion on transactions for "product lookup" (cf attachment):

There are several occasions when a product is looked up, to get additional information. Typically this is:

  • Inventory information (i.e. related to a specific physical item) - Examples: Falsified medicines check (a serial number may be considered "suspect").
  • Catalog information (i.e. related to a kind of product) - Examples: lookup a product type to see if it contains latex.

Other cases may appear, i.e. find a patient record from an implanted device, or find an order for a customized item.

Discussion about the options for the first two cases:

Option 1: Two transactions: Catalog info lookup + Inventory item lookup

    • Advantages: immediately relatable to Catalog and Inventory actors
    • Disadvantages: System must know which transaction to use.


  • Option 2: One transaction "Product information lookup", and one intermediary actor that defines whether that is a product lookup
    • Advantages: Most flexible configuration, since the actor can be implemented on either end
    • Disadvantages: More complicated, perhaps unnecessary complexity


  • Option 3: One transaction "Product lookup" that is supported by a Product data provider, which can be associated with either a Catalog actor, or a Inventory actor, or an Order actor...
    • Advantages: Simpler for all actors.
    • Disadvantages: Must be confirmed if it makes sense from the perspective of the Catalog and Inventory actors: Do they have this transaction?


Work on white paper

Adding two use cases to the white paper. Initial draft / key points were discussed. Jose will update the document.




New use cases drafted for white paper to include that scope: