Talk:ITS Acceptance Factors

Tooling requirement

I agree that the availability of tooling to support an ITS is crucial -- but think that requiring a beta of the tools to be available before INM accepts the workitem is too high a hurdle - I would suggest that the proposed work item should include a plan that will deliver tooling prior to a specification being brought forwards for ballot Charliemccay 09:50, 1 Jun 2006 (CDT)

This is a discussion item - but I'd prefer to be strict and not work on theoretical ITSs until it can be clearly shown that tooling can and will be generated. Rene spronk 15:12, 1 Jun 2006 (CDT)

My concern here is that to get to a point when you have a specification robust enough to have the tooling done, you are a long way down the line of deveoping the ITS -- maybe there is a "proposal development stage" where ITS ideas for which there is not yet tooling can be openly discussed -- I understand that you want to control use of committee agenda time and mailinglist bandwidth -- but not at the price of folk working up substantial proposals in isolation. Charliemccay 06:18, 13 Jul 2006 (CDT)

scope of an ITS

The scope of an ITS should not be limited to representing RIM objects "for transmission in messages" -- so I have removed that part of the criteria Charliemccay 09:50, 1 Jun 2006 (CDT)

The point of the ITS is to represent data so that it may be transmitted. We don't define database models, so the communication aspect has to be emntioned somewhere. Rene 15:10, 1 Jun 2006 (CDT)

OK -- have changed the text from "transmission" to "exchange of information between systems". Again, CDA does not address transmission, and the core of HL7v3 is the representation of clinical information for exchange. Charliemccay 06:26, 13 Jul 2006 (CDT)

requirement for dependance upon non-optional HDF artefacts

This is a hard rule to maintain, since "non-optional" is ill defined in this context. It is possible to create HL7v3 artefacts without defining interactions (they are not needed for CDA documents) - so the definition of the interaction is an "optional" part of the HDF. A reasonable constraint would be that the ITS must be derived from artefacts that are products of the HL7 Development Framework. Charliemccay 09:50, 1 Jun 2006 (CDT)

Suggest to add the context stuff, but not relax the requirement. The HDF describes some things that are optional, e.g. Application Roles. One should not be able to create an ITS that is based on Application Roles. The UML ITS requires a DAM-DIM mapping, a) something that's not in the HDF -this is also covered by your suggestion to relax the requirement-, and b) something that may not be a *mandatory* product of the HDF. If committees aren't forced to create the artefact (and they may choose not to create it), then how can it ever be a basis for an ITS? There needs to be consensus first within the organization that an extension to the HDF is useful before the ITS can be created. Rene spronk 15:17, 1 Jun 2006 (CDT)

OK -- We disagree in this - I think that it should be clear in the ITS that it has constraints -- it seems to me fine that an ITS be defined that requires Application Roles - indeed in an SOA world I can almost imagine such a thing. What certainly is important is that any such constraint be made clear. There is a risk that we create a gridlock - with an ITS not being produced for anything that is not a mandatory part of the methodology, yet requiring all committees to change all their artefacts (even just all their new artefacts) to support some new technology is a high hurdle. What we want is a sensible way to be able to specify ways to use V3 specifications is an implementation technology, taking into account implementation concerns. This should be done as an iterative process, and certainly we need a roadmap that allows new technical approaches to be developed in stages.

Once we have an ITS that uses Application Roles, we will then see more value in defining and maintaining them -- we need the chiken and the egg to develop together Charlie@ramseysystems.co.uk 06:09, 13 Jul 2006 (CDT)

Implemnetation concerns

I have added a bullet requiring that the ITS proposal address implementation issues, and follow industry best practice for the technology in question. The implementation issues that I have in mind are things like:

1. How easy is it for a developer familar with the technology to work with?
2. How well is it supported by current tools?
3. How well will it be supprted by future tools?
4. Does it result in easy to maintain implementations?
5. Does it result in efficient implementations (bandwidth / response times)?

Clearly some of these will be difficult to measure, but not impossible Charliemccay 06:40, 13 Jul 2006 (CDT)