This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "CMHAFF Tuesday, January 31"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "David Tao and Nathan Botts met jointly with Security and CBCC workgroups. To be added")
 
 
Line 1: Line 1:
David Tao and Nathan Botts met jointly with Security and CBCC workgroups.  
+
David Tao and Nathan Botts met jointly with Security and CBCC workgroups, as planned at the San Antonio Working Group Meeting.  
  
To be added
+
*David walked through Use Cases B and C from the cMHAFF document, to illustrate typical types of apps that cMHAFF is intended for.
 +
**Johnathan Coleman said that these are similar to the Sync4Science project that he recommended (in San Antonio) that Mobile Health become familiar with. He specifically mentioned an online consent form in Sync4Science that would be helpful for MH to consider.
 +
**Johnathan suggested expanding the tables in the Use Cases, to address the '''Three Pillars of security -- Importance of: Integrity, Confidentiality, and Availability.''' Currently, the table only has Importance of Data Integrity.
 +
**We should clarify what "white label" means.
 +
**Kathleen suggested that Use Case B is similar to Heart and UMA projects. There should be a way for patients to control what is available to app, e.g., restricting access to certain types of data like immunizations. This is similar to the Data Segmentation initiative.
 +
**Ken Salyards said that Use Case B poses no concerns about confidentiality, depending on who's in control of the PHR (assumes it's the consumer)
 +
**The arrow between the phone and the EHR in Use Case 3 is only one way (send to EHR), but should be revised to be two way (access EHR data also)
 +
*General advice was that the scenarios should be written in terms of risks: vulnerabilities and threats to each "pillar" mentioned above. We should start with the common threats to any IT system (and reuse materials already written for those), and then assess what are the unique threats due to mobile?
 +
**The previous joint work between MH and PHR (Tim McKay and John Ritter) may have already done this.
 +
**There may be some new long-term risks in a different category, e.g., business risks like what if mobile apps become regulated medical devices?
 +
**Johnathan Colemen mentioned SEI Risk model, which includes network risks, physical risks, SW defect risks, and environmental risks. He also recommended the NIST IT Contingency Planning Guide.
 +
**The Security WG Wiki has a resource page with lots of good information. In particular, they recommended "cheat sheets" for Security Risk Assessment and Privacy Risk Assessment. (Afterwards, David downloaded the Security Cookbook document, and the Risk Assessment Cookbook Tutor Powerpoint presentation.
 +
*MH will review the recommended materials, and return to CBCC when ready for the next round, which would included the risk assessments and the associated conformance criteria. Many of the conformance criteria will be requirements to mitigate the stated risks to security and privacy.

Latest revision as of 15:57, 1 February 2017

David Tao and Nathan Botts met jointly with Security and CBCC workgroups, as planned at the San Antonio Working Group Meeting.

  • David walked through Use Cases B and C from the cMHAFF document, to illustrate typical types of apps that cMHAFF is intended for.
    • Johnathan Coleman said that these are similar to the Sync4Science project that he recommended (in San Antonio) that Mobile Health become familiar with. He specifically mentioned an online consent form in Sync4Science that would be helpful for MH to consider.
    • Johnathan suggested expanding the tables in the Use Cases, to address the Three Pillars of security -- Importance of: Integrity, Confidentiality, and Availability. Currently, the table only has Importance of Data Integrity.
    • We should clarify what "white label" means.
    • Kathleen suggested that Use Case B is similar to Heart and UMA projects. There should be a way for patients to control what is available to app, e.g., restricting access to certain types of data like immunizations. This is similar to the Data Segmentation initiative.
    • Ken Salyards said that Use Case B poses no concerns about confidentiality, depending on who's in control of the PHR (assumes it's the consumer)
    • The arrow between the phone and the EHR in Use Case 3 is only one way (send to EHR), but should be revised to be two way (access EHR data also)
  • General advice was that the scenarios should be written in terms of risks: vulnerabilities and threats to each "pillar" mentioned above. We should start with the common threats to any IT system (and reuse materials already written for those), and then assess what are the unique threats due to mobile?
    • The previous joint work between MH and PHR (Tim McKay and John Ritter) may have already done this.
    • There may be some new long-term risks in a different category, e.g., business risks like what if mobile apps become regulated medical devices?
    • Johnathan Colemen mentioned SEI Risk model, which includes network risks, physical risks, SW defect risks, and environmental risks. He also recommended the NIST IT Contingency Planning Guide.
    • The Security WG Wiki has a resource page with lots of good information. In particular, they recommended "cheat sheets" for Security Risk Assessment and Privacy Risk Assessment. (Afterwards, David downloaded the Security Cookbook document, and the Risk Assessment Cookbook Tutor Powerpoint presentation.
  • MH will review the recommended materials, and return to CBCC when ready for the next round, which would included the risk assessments and the associated conformance criteria. Many of the conformance criteria will be requirements to mitigate the stated risks to security and privacy.