Internet2 Medical Middleware (MedMid) Working Group:
Draft Workplan Scenarios

 
draft-internet2-medmid-workplan-scenarios-10.html
v0.10     Last modified: 7-Jan-03
Comments to: Steve Olshansky, Editor
MedMid Flywheel
Internet2

1           Introduction

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:

2           Detailed Scenarios

 2.1         Title: Access to resources including protected health information (PHI) by visiting health care providers

2.1.1        Description

A visiting physician (or other provider such as a nurse, laboratory technician) is given access to specific patient records at a health care facility .

2.1.2        Generic format

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.

2.1.3        Example

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.

2.1.4        Alternate format

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.

2.1.5        System Requirements

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:

REQ[3]=> Shared language (common vocabulary/definitions for machine readable policies) for describing affiliations, entitlements
REQ[4]=> Audit Capability
REQ[5]=> Emergency override ("break the glass") capability
REQ[6]=> Access to general network resources such as printers and shared drives, and to the Internet, at the visited facility
REQ[7]=> Mechanism for sufficient authorization, for user to make entry into record (institutional directory)
REQ[8]=> Authoritative directories of people and roles

2.1.6        Assumptions

2.1.7        Uniqueness

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.

2.1.8        Advanced features

2.1.8.1        "Reverse Access" to remote clinical records

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.

2.2         Title: Role-based Access to Directory Information between a University Medical School and its Independent Hospital

2.2.1        Description

A person is given appropriate access to online hospital directory information based on their role (affiliation) with the Medical School.

2.2.2        Generic format

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.

2.2.3        Example

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.

2.2.4        System Requirements

[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[10]=> Ability to base authorization decisions on factors beyond role

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[8]=> Authoritative directories of people and roles

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.

2.2.5        Uniqueness

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.

2.2.6        Advanced features

2.2.6.1       Hospital belongs to a Multi-hospital group

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.

2.2.6.2       Access to directory information at multiple affiliated 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

2.2.6.3       Appointments at 2 medical schools and chief at 2 clinical locations

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.

2.2.6.4       Reconciliation of multiple directories

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.

2.3         Title: Sharing of Electronic Curricular Materials Between Medical Schools

NOTE: Requirements process for this scenario still in initial stages. Requirements noted below are draft and subject to substantial change or evolution

2.3.1        Description

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.

2.3.2        Example

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.

2.3.3        Generic format

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.

2.3.4        System Requirements

REQ[1]=> Authentication and authorization system, for access to protected resources

REQ[2]=> (Policy/Procedure) Prearranged inter-institutional agreement(s), describing:
REQ[3]=> Shared language (common vocabulary/definitions for machine readable policies) for describing affiliations, entitlements
REQ[4]=> Audit Capability

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[8]=> Authoritative directories of people and roles
REQ[13]=> Anonymize data (i.e. remove identifying data), and/or assign metadata/DRM tags
REQ[14]=> Solutions should be flexible (manageable) to accommodate frequent changes in organizational structures and/or affiliations

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)

2.3.5        Assumptions

2.3.6        Uniqueness

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.

2.3.7        Advanced features

2.3.7.1       Grant access to individuals based on their credentials

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.

2.3.7.2       Include commercial and other information sources

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.

2.3.7.3       Enable annotation, and re-use in other forms based upon agreed usage parameters

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.

3           Requirements Summary

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

?

Yes

?    

14

Flexibility

?

Yes

Yes

   

15

Data reconciliation

?

Yes

?    

16

Normalized collection
of rights

? ?

?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

 

4           Acknowledgements

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/