OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [rights-requirements] HIPAA, HL7 and general questions


Title: RE: [rights-requirements] HIPAA, HL7 and general questions

>I could be utterly confused as to the schedule of events, but as I
>recall, the plan is now to effectively close off input for requirements
>(v1.0) as of the date of [TC approval of ??] the document Hari is
>calling the August 28 Requirements document.  Right?  How could that
>possibly be optimal?

I think it is very important to be clear about "requirements v1.0" and "requirements".  "Requirements (v1.0)" is very confusing to me.  According to the schedule, inputs for requirements v1.0 were due a long time ago.  The schedule was subsequently extended and the new deadline has passed as well.  Many requirements were still accepted after the deadline for inclusion into requirements v1.0.

What this means is that we want to get something out to the world, a set of requirements that we all agree on.  There are several things that this does not mean.

a) This does not mean that input for requirements has been closed.
b) This does not mean that XrML v2.1 satisfies all the requirements in requirements v1.0.
c) This does not mean that XrML v2.1 does not satisfy all the requirements in requirements v1.0.
d) This does not mean that our first version of the rltc spec will satisfy all the requirements in requirements v1.0.
e) This does not mean that our first version of the rltc spec will not satisfy all the requirements in requirements v1.0.

f) This does not mean that our first version of the rltc spec will satisfy all the requirements in requirements v1.1.
g) This does not mean that our first version of the rltc spec will not satisfy all the requirements in requirements v1.1.

What it does mean is that we have a set of requirements we call 1.0, and we publish it as a document that we think we can go forward with, and that if there are any people who would like to use the spec that do not see their requirements there we would expect their feedback.

The work we have not gotten to yet is the work in the specification committee whereby we evaluate the technical details of the requirements through CRs.  Which ones are fully met?  Which ones are not met at all?  Which ones are somewhat-met but could be met better?  What is the impact of not meeting it?  Is there a feasible work-around?  What is the probability that it can be added in an ammendment (new functionality) without breaking backward compatibility?  What is the cost of meeting it?  etc.  Suppose at some point in time we take all the requirements we have at that point in time and break them into three sets w, x, y, and z.  W being all the ones that are satisfied now.  X being the ones that can feasibly be satisfied.  Y being the ones that we don't have any solutions for at the moment (because of our own limited expertise) but that we have a good feeling for could be added in a backward compatible ammendment at some future point when the demand for such requirement grows and the expertise is available to meet it.  Z being the ones that are technologically not possible for a long time, so long that it would be reasonable to have a new version (in some respects may not be backward compatible or some translation may need to be done) by that time.  (The industry can easily handle a new version of the core every 10 years (provided the amount of change in the spec is commensurate with the amount of change in the industry), for example, but not every two months).  Then I think we should try to satisfy X in addition to W, make sure we are confident in our analysis of Y and Z and move on.  There may be some requirements from requirements v1.0 document that end up in Y and Z.  There may also be some requirements from requirements v1.1 document that end up in X and W.  Technologically, I don't think there needs to be a descrimination based upon the version number.

So, I think I agree with you, with that clarification.  I also agree with Bob G. that it makes sense to get some first-hand input from HL7 and whatnot on our requirements v1.0 (though we already have lots of second-hand input).  I also agree with Bob A. that we can't gate progress on a spec just so that we can meet face-to-face with every person who might want to use our spec.  I don't necessarily see a tension in what everyone is saying, if someone can get an expert from HL7 to look at our requirements v1.0, that'd be great.  If it turns out that our second-hand sources already covered all their requirements, I don't think the effort would have been a waste of time.  If it turns out that there is a genuine language architecture requirement we haven't included, I would be disappointed if it didn't show up in requirements v1.1, or whatever we call it.

Thanks,
Thomas.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC