The PCAST Security Model

As the PCAST Workgroup produces its report suggesting implementation options to ONC, the team members have worked hard to communicate the principles embodied in the report so that the group can make informed recommendations.

Dixie Baker and Carl Gunther have produced one of the most useful visual aids- an overview of the security model described in the PCAST report.

It illustrates 10 steps for secure, audited, universal data exchange

1.   A user authenticates him/herself to the local system, within the context of an authorized role.

2. On behalf of authenticated and authorized user and role, local server sends metadata search parameters to the Data Element Access Service (DEAS).

3.  The DEAS mediates the request and searches metadata as permitted by privacy metadata within context of authorized role sent with query.  The transaction is recorded in audit trail.

4.  The DEAS returns a data locator list (Uniform Resource Identifiers) resulting from metadata search.

5.  The Local server requests data from URIs returned from DEAS.

6.  The data storage location server mediates the request and returns encrypted records to local server.

7.  On behalf of an authenticated and authorized user and role, the server sends a DEAS request for encryption key for each data element provided.

8.  The DEAS mediates the request and retrieves the key as authorized from key management service.  The transaction is recorded in the audit trail.

9.  The DEAS returns  the key to local server, along with digitally signed privacy preferences

10.  After use, system destroys the cleartext and key, possibly retaining the ciphertext.

This 10 step process illustrates "Separation of Concerns" - the idea that privacy is protected by isolating components and the responsibility for managing data among separate entities and infrastructure.   In this case, the data, the metadata, and the keys to access the data are kept in separate places, minimizing the risk of a privacy breach of any one component of the architecture.

It remains to be seen how all the key exchange will work in practice.  As we create secure transport infrastructure I think we'll see a progression from organizational level keys (as are used in the Direct Project) to individual level keys (as might be used to authenticate a clinician accessing data) to keys managed by a third party to unencrypt specific data elements (as the PCAST report suggests).

Also, it will be interesting to see if clinicians will accept the idea of saving data from healthcare information exchanges in encrypted form, since if the provider uses the information to make a clinical decision, they'll need to have that information in the health record as documentation supporting that action.

My guess is that we'll see a progression of levels of sophistication as we evolve toward the ultimate PCAST vision.   The PCAST Workgroup has discussed push by the patient, simple search, and complex search via use cases which illustrate how we can incrementally adopt PCAST ideas over time.   I'll blog about that tomorrow.