[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC