Operation Vocabulary e-mail string
From John Moehrke: The concern is more obvious with the hierarchical structure, but exists the same or worse.
From Steve Connolly: Note that the hierarchical structure shown in Tony's email is not included in the balloted version of the RBAC Permission Catalog. The questions you pose are directed at a proposed hierarchy of operations. The current flat list of operations does not imply any of the relationships (generalization, subsumption) that the hierarchy does. We have yet to reach consensus on the types of questions you raise which will have to be addressed if the Security WG decides to move forward with a revised version of the Permission Catalog. (Steve C)
From John Moehrke: Steve, Thanks for forwarding this to me. It is unfortunate this was a private discussion and not in the open.
I guess this list doesn't look as bad as I had envisioned. But I still see trouble ahead when there are two ways to say mostly the same thing. For example I can understand how EXPORT is a form of COPY which is a form of REPRODUCE, but how will policies be compared/executed that use REPRODUCE, COPY and EXPORT? Will they always be seen as equal? Further if the access control request is asking if the user can export a report, will it be mandatory that they have EXPORT permission or is COPY good enough (JohnM)
From Tony Weida: Mike, Richard et al., As we all know, the Security WG has specified an operations vocabulary for balloting in the v2 HL7 RBAC Permission Catalog (following precedent of the approved v1 catalog), while CBCC has specified an operations code system for harmonization in the HL7 Vocabulary Repository (as required by HL7 for RIM-based information models). Differing requirements have resulted in differences between the two versions, but as of today, they remain entirely consistent where they overlap. I trust we're agreed that this consistency is desirable and should be preserved. In support of that goal, I'll compare and contrast the two.
Operations In the following list, RED ITALIC operations appear only in the permission catalog, BLUE UNDERLINED operations appear only in the vocabulary repository, and BLACK BOLD operations appear in both:
OPERATE
CREATE
READ
UPDATE
APPEND
ANNOTATE
MODIFY STATUS
ABORT
ACTIVATE
CANCEL
COMPLETE
HOLD
JUMP
NULLIFY
OBSOLETE
REACTIVATE
RELEASE
RESUME
SUSPEND
DELETE
PURGE
EXECUTE
REPRODUCE
COPY
BACKUP
RESTORE
EXPORT
PRINT
DERIVE
CONVERT
EXCERPT
TRANSLATE
MOVE
ARCHIVE
REPLACE
FORWARD
TRANSFER
SIGN
VERIFY
Note that all attributes in HL7 RIM-based information models must be populated from value sets that are derived from code systems, both in the HL7 Repository. Hopefully, therefore, the red operations can be added to the Vocabulary Repository through a future harmonization proposal.
Common Attributes All operations have a unique uppercase alphabetic code, e.g., UPDATE. All have a brief definition/description. Importantly, wording of definitions is reasonably consistent across operations (compromises were made for previously balloted definitions and to limit otherwise never-ending discussion during WG calls).
Whenever an operation appears in both the Catalog and the Repository, the code and definition/description are the same; to promote continued consistency, the repository entry ends with "Note: The preceding definition is taken from the HL7 RBAC specification. There is no restriction on how the operation is invoked, e.g., via a user interface."
RBAC Catalog Attributes Operations in the RBAC catalog additionally have a meaningless alphanumeric identifier, e.g., P1001. (I don't understand what real value the identifier adds to the unique alphabetic code, but don't see any real harm either.)
Vocabulary Repository Attributes Operations in the vocabulary repository are organized in a taxonomy (generalization hierarchy; subsumption hierarch) as indented above. The taxonomy explicitly clarifies the subsumption relationships among operations that are implicit in their definitions/descriptions. (See Graham Grieve's negative major ballot comment on the Permission Catalog.) As an aside, note that SIGN and VERIFY were added after the taxonomy was developed; SIGN (or variants thereof) should be classified if/when putting forward a taxonomy that includes SIGN.
Each operation also has a print name, synonyms (as appropriate), and a mode, e.g., leaf or selectable (a non-leaf that can nonetheless be coded in a v3 data element, just as leaves can).
Towards Continued Consistency Since operations appear in two HL7 products, the RBAC Permission Catalog and the Vocabulary Repository, there is ongoing danger that they might diverge. Hopefully, all concerned will seek to maintain consistency in response to ballot and/or harmonization requests for changing one artifact or the other. (TonyW)
