1. Point-of-care Identity Management (PCIM)

2. Principle #1
Incorrect association of patient and device data can contribute to improper treatment which can be harmful or fatal to patients.

3. Principle #2
The design process for any clinical use of device data shall include identification of the means by which correct association of device data with a particular patient will be assured, and a rigorous risk analysis covering the ways correct association can fail and how the risks can be mitigated. 

4. The risk analysis and design analysis flow from study of the use cases for the total system of systems exchanging information of patient-device associations.
As part of this, it is necessary to identify the specific information exchanges that need to exist for systems to communicate about associations between patient identities and device identities in the use cases.

5. The purpose of the PCIM profile is to specify transactions that meet those needs for identified use cases.

6. Identity assertion
Anybody can say anything about any entity. Within the scope we are looking at, different assertions have different value for establishing a reliable unique identity.
There must be criteria for “good enough”
There must be mechanisms for resolving conflicts if discrepant association assertions exist in the system of systems

7. Unique identities and identification factors
Within the relevant domain (e.g. hospital, national, worldwide), a unique identifier belongs to no more than one person
In some situations, identity is defined or confirmed using more than one attribute if a patient (identification factor), for example, date of birth, name and mother’s maiden name.

8. Need flexibility in where in the system you create assertions of patient-device association
Ex. the device could do the main part of the job (authorized person admits patient to device by barcoding wristband).
Some system is used to read barcodes of patient, device, person making the association.

9. System Issues
What is the single source of truth for patient-device associations (if such a thing exists)

10. Conflict resolution
There may be times when inconsistent Patient-Device association assertions exist in the system
To what extent can automation help in a particular point in the workflow?
But in general when inconsistency detected: then user interface presents information to a person for so that they may resolve the problem

11. Is there a need to support a device asking what patient it is associated with?
Intuitive answer is yes?

12. Some Transactions Device to Patient Association Assertion
Device to Patient Association Query
Device to Patient Association Conflict Notification

13. ID-less data?
Is it proper to permit transactions in the system of systems that lack patient demographic data?
Possible answer: yes, but not in the enterprise-facing interfaces.
That is, that would be dangerous outside a stated boundary, but there is a place for it between components of the system of systems that synthesizes what gets sent to the enterprise

14. ID-less Devices
Some devices have little perceived need and little capability for dealing with patient identity data, but somewhere within the system of systems the association to patient identity must be asserted and verified.

15. ID-less devices
Proposition: it is the ID-less devices that are most in need of identity-management services in order to be patient-safe!
Implication: there is a place for ID-less data, just not escaping the bounds of the device-oriented system of systems

17. Proto-slides…