RE: [saf] Spec changes

Jeff,

More stuff inline :-)

Some changes I propose for the main spec based on our recent discussions:

- CatalogueSource -> CatalogueEditor (or something that denotes the more fine grained control) Jeff – makes sense.

- Case Manager -> remove? We have no real use for a Case Manager in the spec and certainly not in our implementation. I think this is redundant unless we consider adding "Case" as well as a concept –which might complicate things. Jeff – Case Manager is an Orchestrator, and seems to be implementation specific.

What are the differences with the Diagnostician? If the Case Manager is reduced to only forwarding stuff to the Diagnostician, couldn't we just do without him?

- Add TypeRegistry –maybe with a better name? Also, this by no means mandates the actual existence of a registry in the system, but simply a point where users can find existing types. How this is to be implemented is a detail out of the spec (e.g. could be implemented as an actual registry/store, or as a query mechanism that collects this information from the various places in the framework). Jeff – Why wouldn’t the Catalog be a good place to store the Type information? Answering my own question: Architecturally, it is probably best to separate Practitioner/SymptomEmitter registered information from CatalogEditor supplied information. In an implementation, a single data store could be used for both (simplifying administration, maintenance, etc). Does that sound about right?

Kind of agree. We should not mandate implementations. We had a discussion with Dave about this, he might be able to chip in, but generally, the Catalogue contains the "knowledge" in your system in a sense. The symptom and prescription types are building blocks but not really knowledge, so they should be kept separately.

- I have some issues with the interfaces as set out in the spec. "Interfaces" imply specific interaction semantics, and the way they are currently spelled out makes me uncomfortable. In a sense, what we have there are not interfaces, but Roles! But we already have the term role for the active roles in the framework, so this makes things tricky (imagine: "The role of SymptomHandler can be taken by the role of Diagnostician" :-\ ) And these roles have some operations which we should spell out not in the common format ("getPrescriptionTypes" etc) but in a more loose way ("get/list prescription types"). Then in the relevant appendix we make it more concrete with specificities, e.g. REST. Jeff – I think the first column in our Interface table is just the ‘name’ of the Interface, not a role. For example, SymptomHandler is not a role, but just the name of an interface. Agree that the operations should be defined in a loose way.

Yes I know it's the name of the interface as it is, but conceptually it's something like a role: SymptomEmitter and PrescriptionEmitter don't even have operations in them! Which means they're there simply to denote that an entity in the system (e.g. Practitioner) has this specific rights/permissions/role. Exact terminology is eluding me right now, but I hope you guys understand what I mean...

Stavros

Thoughts?

If we can agree on some of these, I can start editing the main spec.

Cheers,

Stavros

Fujitsu Laboratories of Europe

______________________________________________________________________

 Fujitsu Laboratories of Europe Limited

 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE

 Registered No. 4153469

 This e-mail and any attachments are for the sole use of addressee(s) and

 may contain information which is privileged and confidential. Unauthorised

 use or copying for disclosure is strictly prohibited. The fact that this

 e-mail has been scanned by Trendmicro Interscan does not guarantee that

 it has not been intercepted or amended nor that it is virus-free.

saf message