Talk:ITS Acceptance Factors

Relationship with other ITSs

Removed "The relationship with other HL7 ITS specifications must be described in the proposal, to help clarify when it would be appropriate to use the ITS, and whether it would replace any existing ITS specifications.". If it replaces an ITS, then it is a new version thereof. ITS A has no relationship with ITS B, they both have a relationship with the abstract models. The mapping (or mappability -if that's a word-) of instances according to ITS A to instances according to ITS B is an interesting excercise but certainly not a requirement. Statements as to when which ITS is applicable are interesting, but that's up to the implementers to decide. Rene spronk 08:35, 13 Jul 2006 (CDT)

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)

From the viewpoint of the committee this is entirely about agenda time and resources. Like any other proposal to extend the standard it has to have a certain level of completeness before it is accepted for inclusion in a ballot. Those that are working on a proposal can always discuss principles/issues with the committee (prior to it becoming a workitem) - but such discussions rarely result in action items for the committee, they're used by those that are creating the proposal to test the waters. When it coms to tooling the burden is on those that bring forward the proposal. No tools = an incomplete proposal. Rene spronk 08:27, 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)

(Grahame) I don't think that it's reasonable that if you propose an ITS that has implications outside INM, then all those changes must be approved before INM will consider the ITS as a workitem. Most likely the changes would only make sense in the context of an ITS that enables / leverages the changes, so they wouldn't be adopted without the ITS being an INM work item. Certainly they should be well-described and on a parallel track, and INM couldn't finalise anything till they were adopted, but it's unreasonable to refuse to adopt a work item until they are adopted and we could propose changes with consequences outside INM that are not in the scope of the HDF (unless it becomes a whole lot more detailed...)

I know there's a chicken and egg problem here. Let's put it this way: if an ITS is based on a new FooBar artefact/model, there needs to be strong indication that the HL7 community would be willing to create that FooBar model wherever this is needed. If the HL7 community doesn't see any benefit in FooBar models (the HL7 community may, or may not, benefit from the new ITS) then the newly proposed ITS doesn't stand a chance of surviving. So maybe it doesn't need to be a requirement that the HDF be changed prior to acepting the workitem, but some (other) indication that the HL7 community supports the creation new FooBar artefact is a necessety. IMHO the FooBar artefact would have to have merits on its own - irrespective of whether it's used by an ITS. Rene spronk 08:19, 13 Jul 2006 (CDT)

Implementation 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)