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

["M. Paramasivam" <parama@microsoft.com>]

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.



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. 



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.


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>