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

[Robin Cover <robin@isogen.com>]

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