Meduperson

1. Meduperson Rationale and related efforts Brief Progress Report

2. Eduperson • Eduperson is an LDAP (directory) schema which is: • Designed to describe people in an educational institution. • Designed to define roles and privileges within an institution and for authentication and authorization to them. • Designed to provide a basis for transfer of this information between institutions in a secure, standard, fashion.

3. Meduperson • At one level, Meduperson is a extension of Eduperson to the health affairs campus. • Defines whether residents get football tickets. • Will include credentialing information appropriate to Health Science role. • Data from licensure boards, AAMC, AMA, other professional associations, as needed to define role in institution.

4. Meduperson • But, stakes are higher in this world! • We do need to know who should have a library card and who should pay tuition. • We also need to know a lot more: • Who is making entries in the medical chart? • Who is prescribing medication? • Who is otherwise treating patients? • What is their authority to do so, and how was that authority derived? • How can we preserve that authority over time and space? (I.e. non-repudiation; between entities)

5. Meduperson • The practice of medicine, even in a single academic institution, involves multiple entities: • Universities • Hospitals • Practice Plans • Patients • Payers • Contractors and Subcontractors

6. Meduperson • HIPAA, plus other evolving law, says an entity is not only responsible for the security and privacy of the patient record with respect to its own acts, but also with regard to the acts of all its business partners, including clinical collaborators. • In an electronic world, is each entity going to individually credential every player, including every contract nurse or ward clerk, and keep up with those credentials on a dynamic basis?

7. Meduperson • In the academic world, Meduperson, like Eduperson, is about library access, student health, and football tickets. • In the Patient Care environment, it provides a potential framework for authorization, authentication, non-repudiation within an entity. • It also provides a basis for secure and private transmission of this information to business partners, including clinical collaborators, within and between institutions.

8. Meduperson • In HIPAA terms, if implemented correctly, Meduperson provides a mechanism to meet not only the patient security and privacy requirements within an entity, but also the HIPAA chain-of-trust and need to know requirements which apply to entities and their business partners.

9. Meduperson • Even if current events cause a relaxation or delay of some HIPAA requirements, these events also highlight: • The extreme vulnerability of our present clinical information systems. • Our general inability to extract information in a secure, private, timely fashion from a population of patients. • Such information may be clearly relevant to national security as well as to individual patient welfare.

10. Meduperson • Activities: • Attempting to better define attributes and ultimate purpose—discussions with AAMC, OMG, AMIA, NCHICA, others. • Wrote unsuccessful NSF CISE grant under network centered middleware program. • Internet2 Consortium • Los Alamos National Labs • Oregon Health and Science University • University of Tennessee Health Science Center • Virginia Tech • A different, more generic, I2 application was funded.