[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [rights-requirements] HIPAA, HL7 and general questions
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.html)
-----------------------------------
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