| draft-internet2-medmid-workplan-scenarios-10.html v0.10 Last modified: 7-Jan-03 |
Comments to: Steve
Olshansky, Editor MedMid Flywheel Internet2 |
The scenarios below are selected as focus areas for the MedMid workplan. Their inclusion here resulted from extensive review and discussion of various possible scenarios, seeking to distill our focus down to a handful of scenarios having the most impact on the medical R&E community, and with an eye toward other middleware efforts under way within the Internet2 community, in order to leverage those activities where applicable. The near-term goal is the extraction and prioritization of requirements. The long term goal is the specification and development of middleware systems to enable the scenarios presented below.
Initial implementations will likely be web based but the intent is to make these scenarios and their ensuing requirements independent of transport or access protocols.
The following three scenarios are presented below:
A visiting physician (or other provider such as a nurse, laboratory technician) is given access to specific patient records at a health care facility .
The visiting care provider (visitor) needs temporary access to local (visited) network and the Internet at the visited facility to securely log into their home facility for identification, access and authorization. The home facility consults the business agreement with the visited facility and present the visitor’s access authorization based upon the rules contained in the agreement. The visited facility grants access based upon the presented credentials (authentication and authorization) of the visitor and makes appropriate records of all transactions/access for later audit if required.
Amy, a physician specializing in internal medicine is attending to her patient, Bill who has been admitted to Cherryville Community Hospital (CCH). Amy is an employee of Cherryville Clinics (CC), which has established a business relationship with CCH. While at CCH, Amy needs to access Bill’s in-patient records to see how he has been doing, make some notes on his progress and order tests and medications. Amy also need access to general network resources such as printers, the Internet, and shared directories.
The care provider needs temporary remote access to protected resources at another facility. While still at the home facility, credentials are presented to a remote facility, authentication and authorization decisions are made accordingly, and access is granted to resources residing at the remote facility.
REQ[1]=> Authentication and authorization system, for access to protected resources
REQ[1a]=> Digital signatures required for medical orders, and sufficient key management infrastructure to enable their efficient use
REQ[2]=> (Policy/Procedure) Prearranged inter-institutional agreement(s), describing:
Historically, each physician/provider has been cleared to practice and given network/application access at each institution where they have privileges. Under this future scenario, they could use the relationship that they have with one entity to extend their access to other entities. This approach would reduce administrative workload required to enter the same person into multiple institutional access structures. This would in turn speed up access and termination, and reduce errors.
It would also be desirable for the visitor, while at the visited facility to be able to access clinical records for their patient located at their home facility in order to access patient history, medications, and update the clinical record.
A person is given appropriate access to online hospital directory information based on their role (affiliation) with the Medical School.
Individuals belonging to separate but affiliated organizations are able to access "unlisted" online directory information across organizational boundaries based on their roles. In the simplest case, a person at a university would be given access to the protected directory of an affiliated hospital based on the person’s role at the university (e.g., medical school faculty or staff). This will require identification, authentication and authorization of the requestor (assumption) of information and the secure transmission of the requested information back to the requestor. Appropriate access to information should not depend on the physical location of the requestor.
Tom, a Professor in Cell Biology, wants to call Jane, Chief of the Division of Infectious Diseases in the Department of Medicine, to discuss sensitive matters dealing with their work on the Faculty Promotions and Tenure Committee. Jane has her clinics and office in the hospital, which is a separate corporation linked to the university by an affiliation agreement. Her directory information resides on the firewall-protected hospital network. Tom has his lab and offices in a university-owned building and is connected to the "open" university network with all of his contact information posted on the publicly-accessible university directory.
Physician-related online directory information at the hospital is restricted for internal use but an agreement between the hospital corporation and the university gives authenticated medical school faculty, students and staff rights to access this information. Tom accesses the online university directory and enters Jane’s name. He is authenticated as a medical school faculty member and presented directory information from the hospital directory that include Jane’s phone number, office location and email address. The public and all non-authorized users at the university are only presented with Jane’s hospital, department and division affiliations as well as her academic rank in the School of Medicine.
[Prioritization Note]=> Address read access first, then other access (write/execute/edit/delete)
Affiliation with a certain group allows access to some privileges within the directory structure?
REQ[9]=> Affiliation should have the ability to be granular,
and address subgroups as needed.
NOTE: Need to differentiate role v.
affiliation
· Affiliation = relationship between things, role = functionality that something can do? (MRG)· Affiliation = relationship between user and responsible entity· Allows organization to assert things about a person· Role = is associated with a set of authorization, access privileges, restrictions, permissions· Roles asserted by other entities may or may not map to similar role at target organization
REQ[1]=> Authentication and authorization system, for access to protected resources
REQ[11]=> Ability to correlate and resolve identity conflicts (Jane Smith in system A is or is not the same person as Jane Smith in system B)
REQ[12]=> Directory access control capability
REQ[14]=> Solutions should be flexible (manageable) to accommodate frequent changes in organizational structures and/or affiliations
REQ[15]=> Need the ability to reconcile and synchronize directory information if and as necessary.
This scenario deals with basic role-based access to directory information in an environment that is more typical of relationships between corporations than universities. Most medical schools are now relying on part time faculty and ever changing affiliations with independent hospital corporations to educate their students. Access to reliable directory information that spans institutional borders is critical in this environment.
Frequently, an affiliated hospital is a member of a larger multi-hospital group or company. Although directory information within the group or company may be aggregated, it will be important to segregate out data by affiliated hospital since agreements for affiliation and authorization to access information will likely be made with individual hospitals.
A single medical school has affiliation agreements with multiple hospitals and needs to manage role-based access to directory information at each of the hospitals
Two hospitals belonging to the same group or corporation, appoint one person to serve as chief of Department X at both locations - splitting clinic time equally between the two hospitals. Since the two hospitals have affiliations with different medical schools, this individual also holds appointments as the Chair of Department X at both medical schools. Thus, one person is Chief of Department X at two different hospitals as well as Chair of the same Department at two different medical schools. A directory search from a university should list only the appointments affiliated with that university and not reveal information about appointments at other medical schools or at non-affiliated hospitals.
User directory information resides on the firewall-protected hospital network. Other instances of user directory information may also resides within affiliate corporation(s). Need ability to reconcile between systems, to authoritatively identify unique individuals.
A faculty member at one medical school wants to give students and faculty at another medical school access to electronic curricular materials that he/she has developed.
Dr. Sarah Jones, a distinguished professor of Pathology, has produced a unique annotated electronic atlas of pathology cases. This collection contains video clips, high-resolution images of tissue sections and instructional diagrams. The individual elements of the collection have been assigned universal medical language metadata tags to facilitate the searching and retrieval of information. The collection is housed in the university’s digital library and is used extensively by faculty and staff at her home institution. Sarah is in discussion with several publishers regarding further development of this collection and wants to protect her intellectual property from general distribution. She is currently on a sabbatical leave at Cross-Town Medical School and has granted faculty in the Anatomy and the Pathology departments as well as all medical students at this sister institution rights to view her collection.
As part of a problem-based learning assignment Bill, a first-year medical student at Cross-Town Medical School, is searching the local digital library for information related to liver pathology. Finding nothing of relevance in the local digital repository, he requests an off-site search. Among the items returned in the list are several relevant diagrams and images from Dr. Jones’ collection. Bill was presented these objects because he was previously authenticated as a Cross-Town student and is able to view the material in accordance with the access rights given by Dr. Jones to all Cross-Town medical students. There would be a system check to see if Bill’s home institution is a subscriber to that resource, when accessed.
An owner of electronic intellectual property that is being maintained in a digital library at the home institution has granted the right to view this material to individuals associated with another institution based on their roles at the institution. An individual belonging to an authorized group requests an object located in an "off-site" digital library. Following identification and authentication against a local directory, individuals would be given access to appropriate objects in the "off-site" digital library and/or other resources based on their roles and the different sets of access permissions granted by the resource "owner." Initial set of authorizations is received by the user, then the user would later request and receive further authorizations as needed when accessing particular resources not already covered under the initial authorizations.
REQ[1]=> Authentication and authorization system, for access to protected resources
REQ[9]=>Affiliation should have the ability to be granular, and
address subgroups as needed.
Role v. affiliation, need to define
REQ[11]=> Ability to correlate and resolve identity conflicts (Jane Smith in system A is or is not the same person as Jane Smith in system B)
REQ[16]=> Normalized collection of rights for user, based on affiliations.Initial authorizations received by user, then additional authorizations requested/granted later as needed.
REQ[17]=>Role based access control (RBAC) -- ability to use available data about users and content (could be attributes, metadata, or other) to control access by users to content.
REQ[18]=>Mechanisms in place to ensure authorized use of content objects - Digital Rights Management (DRM)
This is a basic scenario describing the sharing of faculty-generated intellectual property between institutions where limitations are places on the distribution of the content.
Expanding this case to provide access to all board-eligible and board-certified pathologists as well as pathology faculty members at the sister institution will necessitate the use of credentialing information in addition to directory information.
The digital library of the future will likely contain material (or pointers to such material) that has a variety of different owners. Being able to appropriately assign and manage access rights in this environment will be important.
Allowing a user to add annotations in such a way as to remain distinct and separate from the original media, e.g. by reference to asset ID and time code, to facilitate use in learning environments is potentially a very powerful feature. Similarly, permitting certain portions of the material to be recombined into another format, e.g. a student assembling portions of relevant materials into an aggregate format for a class project, is useful as well.
| Req. # |
Description |
Scenario 2.1 |
Scenario 2.2 |
Scenario 2.3 |
Middleware component | Notes |
| 1 |
AuthN/Z system |
Yes |
Yes |
Yes |
Ent. Directory; Shibboleth | |
| 1a |
Digital Signatures/PKI |
Yes |
? | ? | PKI; S/MIME | |
| 2 |
Policy agreements |
Yes |
? | Yes |
||
| 3 |
Shared language |
Yes |
? | Yes |
||
| 4 |
Audit Capability |
Yes |
? | ? |
||
| 5 |
Emergency override |
Yes |
? | ? | ||
| 6 |
Network Access |
Yes |
? | ? | ||
| 7 |
Write authZ |
Yes |
? | ? | Shibboleth+ | |
| 8 |
Authoritative Dirs. |
Yes |
Yes |
Yes |
Ent. Directory | |
| 9 |
Nested AuthZ |
? | Yes |
? |
Shibholeth; *AuthZ Info Sys | |
| 10 |
Situational AuthZ |
? | Yes |
? | *AuthZ Info Sys | |
| 11 |
Join capability |
? |
Yes |
? |
MetaDir; *Fed Ident. Mgmt. | |
| 12 |
AuthZ re directory |
? | Yes |
? | *AuthZ Info Sys.; Shibboleth+ | |
| 13 |
Anonymize/Assign
|
? | Yes |
? | ||
| 14 |
Flexibility |
? | Yes |
Yes |
||
| 15 |
Data reconciliation |
? | Yes |
? | ||
| 16 |
Normalized collection |
? | ? | ?Yes |
||
| 17 |
Role based metadata access |
? | ? | ?Yes |
*AuthZ Info Sys; Ent. Directory; Shibboleth+ | |
| 18 | DRM System(s) | ? | ? | ?Yes | *fDRM | Federated DRM: see http://www.ait.utk.edu/fdrm.html |
These scenarios have been developed under the auspices of MedMid, the Internet2 Medical Middleware working group, which exists to further the development of middleware for healthcare education and practice, and related areas. The working group was formed by the Internet2 Health Sciences Initiative and Internet2 Middleware Initiative, and in cooperation with the Association of American Medical Colleges (AAMC). The scenarios forming the basis of this document were initially provided by:
Jere Retzer (Scenario 1)
Manager of Advanced Internet Programs
Oregon Health Science University
Dave Damassa (Scenarios
2 and 3)
Dean for Information Technology
Professor of Anatomy and Cellular Biology
School of Medicine
Tufts University
The process of further developing the scenarios and articulating the requirements has been a joint effort of the above, and:
Jack Buchanan
MedMid Working Group Chair
Associate Professor of Biomedical Engineering,
Medicine, and Physiology
University of Tennessee Health Science Center
Michael Gettes
Principal Technologist
Office of Information Services
Georgetown University
Bill Gordon
Database Architect
Academic Information Technology and Libraries
- Systems Development Team
University of Cincinnati Medical Center
Keith Hazelton
Senior IT Architect
Division of Information Technology
University of Wisconsin-Madison
Mary Kratz
Manager, Health Sciences Initiative
Internet2
Steve Olshansky
Middleware/MedMid Flywheel
Internet2
Links for further information:
| MedMid | http://middleware.internet2.edu/medmid/ |
| Internet2 Health Sciences Initiative | http://www.internet2.edu/health/ |
| Internet2 Middleware Initiative | http://middleware.internet2.edu/ |
| Association of American Medical Colleges (AAMC) | http://www.aamc.org/ |