Pharm Tech Minutes 2010.09.17

Goal of this TConf

Exact definition of the Community Pharmacy Manager as central actor.

Key points of the discussion

Proposed Filtering part of the CPM

The “Filtering” part of it makes sense and is approved (PHARM-1 query)

===> Approved

·

Proposed Interception part of the CPM

The relaying of the “Receive Document Set” transaction (ITI-43)

===> Approved

§ Reason: In multi-domain scenarios it could be unwanted that every domain has permission to talk to every other domain (e.g. by XCA). That’s why PHARM-1 was introduced. This benefit would be lost, if the same principle would not be applied at the retrieving of the documents (of the search-result). Therefore it makes absolutely sense to relay the document retrieve.

The relaying of the “Provide and Register document set (ITI-41) is still under discussion

===> Open issue

§ (A) Relaying submissions by the CPM:

• Clients must not care about status management, because this is done by the CPM (during relaying the submission).

• Since all transactions from the clients go to the CPM (and not directly to the repositories), database-based back-end-systems can perfectly be “covered“ behind the CPM by simply putting an IHE “wrapper” around it.

• This is a very important point for acceptance!

§ (B) NOT relaying submissions (they go directly from the document source to the repository)

• More alike the standard XDS procedures

• Routing the transaction over a CPM might be unwanted in some scenarios (e.g. when documents are stored in a local repository at client side)

• Robert Horn explained that the upcoming IHE profile for “workflow” will most likely introduce special “status management” transactions which allow clients to perform right status updates (e.g. Dispense actors would set the status of a prescription when submitting a dispense by a special transaction derived from the upcoming new profile).

• By this relaying submissions of documents over the CPM for status management purposes would not be necessary and conflicting the topology of the upcoming workflow-profile.

---

Jürgen's option

Supported by Arianna Cocchiglia & Luca Zalunardo (Arsenàl.IT), Geert Claeys (Agfa HealthCare)

This matter is not easy to decide, both variants have their arguments. After the recent discussion and summary of all arguments Jürgen personally tend to approach (B).

The reason for that

1 … is mainly Robert Horns statement about the upcoming IHE workflow profile. It sounds like the profile will require the “clients” to do status management and so doing interception of submissions would not be necessary and even more: it would be a topology conflict with the “workflow” profile!!

2 At the same time, relaying submissions (A) is not as much important as relaying “retrieves” (which brings the great advantage to preserve distinction between affinity domains). It was just intended for giving “the chance” to do status management (see point 1).

3 Furthermore database-based back-end systems can also be covered in (B) – it just don’t “look” so nice.

4 If real implementations want to do status-management by interception of submissions, they can do it anyway at their repository they use for pharmacy.