[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [rights-requirements] HIPAA, HL7 and general questions
Thanks Hari and Parama for notes.
Appended below is a hint as to why I mentioned W3C. Note that each
reviewable REQ deliverable (PUBLICLY reviewable deliverable) is
a document bearing the title "... Requirements..." and that
there are multiple versions (**iterative** as I have tried to
emphasize) and that each has an accompanying set of instructions for
public input.
If indeed there is no linkage between OASIS Standard (XrML-TNG)
Version 1.0 and our:
"RLTC Requirements Document Version 1.0"
"RLTC Requirements Document Version 1.1"
["RLTC Requirements Document Version 1.2" ...]
(variable dates post 2002-08-28)
and
if there is genuinely time and opportunity for public input to
these Requirement Documents [Version *.*] as informing work on the
deliverable called "OASIS Standard (XrML-TNG) Version 1.0,
2003-MM-DD"
then many of my puzzlements are diminished. I saw no mention of the
notion of "public review" of an "RLTC Requirements Document" in the
published schedule, and no timeframe for such review.
What we have on the website now as a collection of
ZIP files, text files, and whatnot is not, in my opinion,
a publicly reviewable TC REQ deliverable. The first such candidate
deliverable would seem to be the document that is to be published
on August 28th.
Best wishes,
Robin
--- Examples of Requirements Specifications for Public Review ---
Web Services Architecture Requirements
http://www.w3.org/TR/wsa-reqs
http://www.w3.org/TR/2002/WD-wsa-reqs-20020819
http://www.w3.org/TR/2002/WD-wsa-reqs-20020429
Comments on this document should be sent to
www-wsa-comments@w3.org (public archive).
Discussion of this document takes place on
the public www-ws-arch@w3.org mailing list
(public archive) per the email communication
rules in the Web Services Architecture Working Group charter.
Requirements for a Web Ontology Language
http://www.w3.org/TR/webont-req/
http://www.w3.org/TR/2002/WD-webont-req-20020708/
http://www.w3.org/TR/2002/WD-webont-req-20020307/
Comments on this document should be sent to
public-webont-comments@w3.org, a mailing list
with a public archive. General discussion of
related technology is welcome in the mailing
list w3c-rdf-logic@w3.org, which also has a public archive.
XML-Signature Requirements
http://www.w3.org/TR/xmldsig-requirements
http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html
http://www.w3.org/Signature/Drafts/xmldsig-requirements-990728.html
http://www.w3.org/TR/1999/xmldsig-requirements-990623
-----
On Thu, 22 Aug 2002, Reddy, Hari wrote:
> Hello Robin/All:
> I apologize for answering earlier as I was away...Let me clarify certain
> points to the entire Requirements SC:
>
> From your note below:
> -------------------------------
> Here's what I understand Hari to have said (not that it was a decision
> reached by group consensus):
>
> * following the scheduled September 4th TC meeting, the version 1.0
> requirements document is essentially frozen
>
> [Hari-start]
> I am disturbed and confused by this. Let me make it perfectly clear, there
> is NO correlation between the version number of the Requirements Document
> and the Specification Version. I point to the most recent email that I sent
> out to the SC dealing with the submission of requirements late in the
> process
> (http://lists.oasis-open.org/archives/rights-requirements/200208/msg00020.ht
> ml)
> -----------------------------------
> Text:
> Title: RE: [rights-requirements] Reqs from AIT/FDRM project
> Hello Robin:
> I want to clarify some points that were reviewed at the last Requirements SC
> call...I apologize in that I haven't issued the minutes yet...I have
> reviewed this with John who will be working with the AIT/FDRM group.
>
> I view the Requirements from the AIT/FDRM project as being valuable and
> germane to our work. What I would like the team to do is to deliver Version
> 1.0 of the Requirements Draft per the schedule on the Aug-28. Within this
> document will be requirements extracted from the documentation and artifacts
> that are available presently from the AIT/FDRM project. During the RLTC
> General Body review period, we will make it quite clear that we are
> expecting another set of requirements shortly after Sept 9. When we receive
> the requirements from the AIT/FDRM group shortly after the Sept 9th meeting,
> we, as a team, will review these against the Requirements Ver 1.0 document.
> Any new Requirement will be part of a change request and issued as part of
> Version 1.1. The Spec SC will then review the Version 1.0 and Version 1.1
> and provide a response.
>
> In this manner we respect those groups that have worked diligently to
> provide source requirements thus far and are awaiting response while still
> enabling other groups to submit their specific requirements. We are also
> enabling the other SCs and external liaisons that we have established to
> begin their respective analyses.
>
> Regards,
> Hari
> -----------------------------------
> In keeping with this process, I need to review the AIT/FDRM project some
> more to extract requirements. If you have any more information on this I
> would greatly appreciate it of you could send it to me or the list...
>
> As I keep mentioning to people, requirements gathering is an ongoing
> process. WE ARE NOT STOPPING THE REQUIREMENTS GATHERING PROCESS AFTER THE
> RELEASE OF VERSION 1.0. IN FACT, WE WILL NOT STOP AFTER THE RELEASE OF THE
> SPEC. I have stated and received OASIS approval of continuing this work as
> an ongoing TC; the TC will no disband after the first release. I don't know
> how many times I have to state this. We will do the analysis and respect
> every requirement as we have done to date. If there is new requirement we
> will initiate a change request to have the change approved by the General
> Body. The Specification SC (most of which are on the Requirements SC) will
> provide responses to the Requirements documents what ever version number
> they have. The bottom line is that it does not benefit anyone if there is a
> great rights language requirement that does not get implemented. Our
> challenge is to develop a baseline that allows the other SCs and other
> internal and external constituents to review and comment on the output.
>
> [Hari-end]
>
> - note that the published schedule says "RLTC Requirements SC Draft
> Approved" where I would expect the text to say "RLTC Requirements
> SC Draft Discussed and Voted On"
>
> [Hari-start]
> The entire schedule was written in the affirmative style which was not
> objected to by anyone. It's been like that for since it was worked on a few
> months ago. I apologize for any sudden confusion. As with every document
> that I have sent out, I have asked for comments/feedback. I received some
> input on what the colors mean. This is not the first time that you have seen
> this format. I am interpreting no feedback means consensus. The schedule
> also clearly does not include iteration. I can't do much in an Excel
> spreadsheet...
> [Hari-end]
>
> - note that this timeframe gives one week for review of a document
> that we have not yet seen (?), in a genre that is not yet
> clarified; no evidence that this review is to be public
>
> [Hari-start]
> I have worked extremely late hours for the past few months to provide to you
> and the team in-process work for the past few months. I did this explicitly
> to address this concern of having only 1 week to review. As a team we have
> reviewed the taxonomy and even made several changes. After every change, I
> reparsed the entire set for consistency. So in essence you have seen the
> "document". I just need to finish the several more (SLC, EFF, WS) for the
> release tonight which I stated again on the call yesterday. I have also did
> the analysis on the HL7 (Healthcare) use cases that were submitted to the
> XACML TC (they were the first ones in the document) and also the EbXML
> Registry Object.
> [Hari-end]
>
>
> - following the September 4th TC meeting (assuming the approval of
> the V1.0 Requirements SC Draft), any new requirement documents which
> is received will be acknowledged as received, and its contents
> analyzed; if the analysis proves to simply affirm the data points
> in the v1.0 REQ, these will be noted clerically as supportive; if
> the analysis proves to levy requirements *not* already envisioned
> in the 1.0 REQ, Hari says they will be labeled as v1.1 reqs and
> will NOT be relevant to the design work which is scheduled to
> result in an OASIS Standard of May 2003
>
> [Hari-start]
> This is inconsistent with my statements and I hope that I have addressed any
> confusion above.
> [Hari-end]
>
> Hari, can you clarify if any of this is incorrect based on what you
> have articulated orally and in writing?
> -------------------------------
>
>
> To answer your other points about discussions with Liora on HL7. I
> absolutely welcome her input and would welcome her participation in the
> RLTC. I also hope that she will have a version of the RLTC requirements to
> facilitate her review. I also welcome the establishment of a formal liaison
> with HL7 to formalize the relationship just as we have done with ISO/JTC1
> (MPEG) and TV-Anytime.
>
> With respect to XBRL, Zack's schedule has been extremely busy and has
> prevented him personally to participate. I have had long discussions with
> Zack, as has Brad Gandee, discussing the work of the RLTC and the
> architectural approach which he agreed upon. During the conversation, we
> also envisioned the linking of the RLTC work with some of the sub groups
> within XBRL.
>
> I hope that I have addressed your points.
>
>
> Regards,
> Hari
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Robin Cover [mailto:robin@isogen.com]
> Sent: Thursday, August 22, 2002 3:53 PM
> To: M. Paramasivam
> Cc: Rights-Requirements SC
> Subject: RE: [rights-requirements] HIPAA, HL7 and general questions
>
>
> Parama,
>
> Thank you for this response. It may be useful to follow up with
> a statement of current understanding, which may or may not lead to
> an easy agreement.
>
> On Thu, 22 Aug 2002, M. Paramasivam wrote:
>
> [Parama]
> > Here's my perspective:
> >
> > 1. The requirements process is open ended. It is simply not the case
> > that new requirement documents cannot be accepted after Aug 28th. It is
> > not clear to me how people have ended up with that impression.
>
> Here's what I understand Hari to have said (not that it was a decision
> reached by group consensus):
>
> * following the scheduled September 4th TC meeting, the version 1.0
> requirements document is essentially frozen
>
> - note that the published schedule says "RLTC Requirements SC Draft
> Approved" where I would expect the text to say "RLTC Requirements
> SC Draft Discussed and Voted On"
> - note that this timeframe gives one week for review of a document
> that we have not yet seen (?), in a genre that is not yet
> clarified; no evidence that this review is to be public
> - following the September 4th TC meeting (assuming the approval of
> the V1.0 Requirements SC Draft), any new requirement documents which
> is received will be acknowledged as received, and its contents
> analyzed; if the analysis proves to simply affirm the data points
> in the v1.0 REQ, these will be noted clerically as supportive; if
> the analysis proves to levy requirements *not* already envisioned
> in the 1.0 REQ, Hari says they will be labeled as v1.1 reqs and
> will NOT be relevant to the design work which is scheduled to
> result in an OASIS Standard of May 2003
>
> Hari, can you clarify if any of this is incorrect based on what you
> have articulated orally and in writing?
>
> [Parama]
> > 2. The requirements process has resulted in a pretty versatile framework
> > for accepting new requirements. This framework has demonstrated
> > integrity by accommodating several different classes of requirements.
> > Incorporating new requirements is much more streamlined and systematic;
> > without such a process we would be lost and unable to classify new
> > requirements as they come in.
>
> I have expressed appreciation similarly to Hari, privately and I think
> publicly, for the meticulous, careful audit trail supported by numbers
> and preservation of the "raw" data. It represents a lot of work, and
> could serve as a model for some processes I've seen in the past which,
> by comparison, were haphazard and imprecise.
>
> [Parama]
> > 3. I completely disagree that the work here is bizarre. I have been on
> > other rights languages requirements gathering efforts and this is by far
> > the most organized effort, and has established a systematic process to
> > assimilate and incorporate new requirements. I am very optimistic that
> > this process will lead to a comprehensive survey of the requirements
> > landscape.
>
> The respect in which I used the word "bizarre" (I could have used a better
> adjective, probably) is not that the effort is purported to be
>
> * disorganized
> * unsystematized
> * inherently unaccommodating of new requirements
>
> The respect in which I find it puzzling is that:
>
> * the identification of "entities" from whom input would be sought seems
> unrepresentative, for example
>
> - failing to identify the ODRL effort, which arguably is the ONLY real
> alternative to XrML as a rights language (see Bill Rosenblatt's
> recent review of ODRL and OMA's use in OMA Download)
> - failing to establish a contact with principals in HL7/HIPAA (?) as
> indicated on the official entity list, even though healthcare was
> identified as a major player [the use cases presented in the
> unsolicited XACML paper notwithstanding]
> - failing to obtain meaningful input from the financial services
> industry, despite identification of SEC compliance as a candidate
> application
>
> *[the most puzzling of all, however], the "SC draft" declared to
> be "Approved" on September 4th appears to have no scheduled phase for
> public review.
>
> In my experience, the whole idea of requirements engineering is to obtain
> input and evaluation from the stakeholders in such a manner that the
> designers can confidently create something representing the users' wishes.
> Asking for documents would be stage 1; creating a draft Requirements
> Document REQ 1.0 would be stage 2; soliciting public review of the
> Draft Requirements Document would be stage 3; correction and augmentation
> of the Requirements Document based upon public review would be stage 4.
>
> The idea of the SC creating one draft of the REQ document, getting signoff
> from plenary one week later, and then declaring REQ v1.0 finished is
> IMO very odd, if we believe that the document called the "SC Draft" could
> serve
> as the first meaningful (prose) expression of the TC's proposed requirements
> set that is suitable for public review.
>
> By "suitable" I mean socially plausible. Having ZIP files on the file
> server and (still only partially complete XSL files) is hardly an
> optimal method for publicizing and getting public feedback. One could
> argue (I did) that the 'SC Draft' is the instrument which would permit
> the most important kind of feedback from the public, given that the
> notion of "submitting requirements specs" is not in the daily
> job description for many who have legitimate interest. As far as I
> know, this is precisely why W3C and other standards efforts would
> publish a Requirements document and solicit public feedback:
>
> i.e., publicize the draft REQ document in appropriate channels, create
> an email address for public comments, establish a comment period for
> the draft, publicize a method for contributing additions/corrections
> in the most suitable format for evaluation, etc.
>
> *Skipping* a meaningful public review process for REQ v1.0 as relevant
> to the proposed OASIS Standard v1.0 will be interpreted by some as
> evidence of an insular, staged affair.
>
> Robin Cover
>
>
> > Thanks
> > --Parama
> > -----Original Message-----
> > From: Robin Cover [mailto:robin@isogen.com]
> > Sent: Wednesday, August 21, 2002 6:04 PM
> > To: Rights-Requirements SC
> > Subject: [rights-requirements] HIPAA, HL7 and general questions
> >
> > Req SC:
> >
> > In today's Requirements conference call I heard the phrase "health
> > records" mentioned at least twice, so I decided to blast off a note to
> > Liora Alschuler (one of the HL7 principals who also knows about XML).
> > Her response, quoted below in part, puts me in doubt about what to tell
> > her, as she is concerned to be involved in the OASIS RLTC work, and to
> > ensure that their requirements are represented.
> >
> > What should I tell her?
> >
> > Then I recalled that:
> >
> > 1) Hal Lockhart has a section 'Clinical Record Use Cases' (buried) in
> > his XACML use cases document, and
> >
> > 2) that the early proposals and charters for the OASIS TC mentioned
> > HIPAA specifically:
> >
> > "Additionally, fields such as healthcare (HIPPA compliance) and
> > financial services (SEC regulations compliance) have now recognized
> > the need for the ability to express usage and access rights for
> > documents, records and services..." [March 2002]
> >
> > http://lists.oasis-open.org/archives/rights/200203/msg00000.html
> >
> > I'm not sure what to tell Liora, given the SC's proposed timeframe, but
> > it
> > puts me into the same mental state of questioning as I had when the ODRL
> >
> > requirements came flying in, late, out of the blue. Not to be critical
> > of the work of the Requirements SC, but in these two cases, it's a
> > puzzle why these people were not included in the requirements gathering
> > effort. Can someone explain?
> >
> > I see in the Minutes from the June 19, 2002 meeting (I was not present,
> > not having joined the group yet):
> >
> > <q>
> > ------------------------------------------------------------------
> > "An assignment of initial representatives was made. The following
> > final list was agreed upon by the Requirements SC:
> >
> > 1. MPEG ("Motion Picture Expert Group") - BG
> > 2. XBRL ("extensible Business Reporting Language") - HR
> > 3. ebXML/UBL ("electronic business XML/Universal Business
> > Language")-BobG
> > 4. OeBF ("Open eBook Forum") - BG
> > 5. AAP ("American Association of Publishers") - BG
> > 6. CEN/ISS DRM Working Group - BG/HR
> > 7. OMA ("Open Mobile Alliance") - JE
> > 8. Reuters - DP
> > 9. Creative Commons - JE
> > 10. Digital Consumer - JE
> > 11. Web Services - BobA
> > ------------------------------------------------------------------
> > </q>
> > http://lists.oasis-open.org/archives/rights-requirements/200206/msg00004
> > .html
> >
> >
> > I have to wonder what on earth could have been "final" about this list,
> > and why... given that the TC charter/proposal explicitly mentions HIPAA,
> >
> > financials, and SEC. Why do we not see HL7/HIPAA and ODRL on this list?
> >
> > What other signiticant industry sectors are entirely missing? What do
> >
> > we have in hand now about "financial services (SEC regulations
> > compliance)..." -- with or without the assistance of XBRL?
> >
> > 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? Arguably, we already have a poor track record.
> >
> > It occurs to me that the mistake we are about to make (slamming
> > the door shut on requirements that are just now beginning to show up,
> > based partly on narrow selectivity of input groups) is going to be
> > compounded if a requirements specification is presented (as I heard) to
> > the plenary TC on August 28th for evaluation by that group. The TC as a
> >
> > whole, arguably, has been a less than thorough in identifying
> > stakeholders; the TC is not likely to have the expertise evaluate the
> > competency of the Requirements document that seems to have left out a
> > range of industry players who indeed *have* requirements, hitherto
> > collected or not.
> >
> > Hmmm... musing here... Once there's an initial REQ draft (why not call
> > it that?) prepared for review, it seems to me that the most important
> > REQ review body is the WORLD; the most relevant review process would be
> > one which publicizes the draft and invites comments from industry
> > sectors
> > that have legitimate interest in "rights" (expression language), who can
> >
> > look at this REQ draft and say: "good start, but you left out a whole
> > pile
> > of concerns central to OUR work..." What grounds do we have to believe
> > this would not happen, if an initial draft Requirements document were
> > presented to the world for review? As far as I know, for example, W3C
> > always puts Requirements specifications into public space for public
> > review *before* moving forward.
> >
> > Anyway, here's a cut from Liora's note:
> >
> > --------------------------------------------------------------------
> > Let me see if I can give an example that might be relevant to the
> > current DRM discussion. HIPAA confidentiality regs currently state (and
> > this is one provision that may actually change before publication in
> > October of this year) that a provider must make a copy of their privacy
> > policy available to patients and must be able to prove that they have
> > done so, but does not require that patients sign anything acknowledging
> > that they agree to release of their documents under defined
> > circumstances -- the "consent" document. In practice, most institutions
> > already require patient signature for consent to release information
> > under defined circumstances and they are likely to continue to do so.
> >
> > In an electronic "DRM" scenario, before release of documents, it strikes
> >
> > me that "trading partners" would need to know whether one of them
> > required such a signed statement and whether it had been obtained.
> > Further, they might need to know the contents of the the signed, since
> > the provisions of the consent agreement can vary materially, even under
> > HIPAA...
> > --------------------------------------------------------------------
> >
> > Liora seemed to suggest that if this domain were to be considered as to
> > its rights-language requirements, one would need to go through HIPAA
> > specs and the HL7 RIM (Reference Information Model) to make sure the
> > underlying requirements in the data models were accounted for in the
> > RLTC requirements specification. So one might ask: can we do this job
> > at this point, or would it actually make more sense for Liora to do this
> > job once there's a draft requirements document to inspect?
> > You can all guess my answer. Members in our SC are still in doubt about
> > what is meant (and why) in some of the initial analysis; the materials
> > are
> > hardly ready for review (and correction/supplementation) by "the world"
> > of legitimately interested parties.
> >
> > HIPAA
> > http://cms.hhs.gov/hipaa/hipaa1/default.asp
> >
> > HL7 Reference Information Model
> > http://www.hl7.org/library/data-model/RIM/modelpage_mem.htm
> >
> > Enough for now, except to say what I said in almost the first meeting:
> > requirements gathering as part of software development is a strongly
> > iterative process that takes into account the rate at which the endeavor
> > is
> > publicly (socially) understood -- with respect to significance in terms
> > of
> > self-interest and self-preservation. I question now more than at the
> > beginning whether our SC effort is taking cognizance of fundamental
> > principles of requirements engineering. In the range of my experience,
> > what we are doing is rather bizarre. For the public record.
> >
> > Robin Cover
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC