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

Joint with Security/CBCC at San Antonio WGM, January 17

From HL7Wiki
Revision as of 15:40, 1 February 2017 by David tao (talk | contribs) (Created page with "*David presented a proposal (to be posted on the Mobile Health Workgroup page under “Documents”) for collaboration with Security and CBCC, where Mobile Health would be a ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  • David presented a proposal (to be posted on the Mobile Health Workgroup page under “Documents”) for collaboration with Security and CBCC, where Mobile Health would be a “general contractor” for cMHAFF, but Security and CBCC would be “subcontractors” and subject matter experts for appropriate topics, such as privacy, consent, authentication, encryption, auditing, etc. There was a high degree of interest, and lots of questions and comment made throughout the presentation. The following points were made. MH response (if any) is given in parentheses following each point.
  • Important for MH to clearly define the term “Mobile Health” and what it is and is not. This is important not just for cMHAFF but for MH WG as a whole.
  • Patient Generated Health Data (PGHD) is included in mobile data.
  • “Risk Management” as stated in the presentation was considered vague and odd to be by itself. Instead, there should be risk management for various topics, such as security, privacy, safety… (Agreed, but cMHAFF has Risk Management as a statement that the developer should have a defined risk management process)
  • Researchers should be added as a beneficiary of cMHAFF. (Agreed)
  • Point to existing work where possible, be like a “directory” (Agreed, but need to consider ease of use for small, immature developers who can’t afford to read lots of “thousand page documents”)
  • Providers also use apps and should be listed as users. (True, but this is scoped as a consumer MHAFF, so it’s only focused on that space. Providers are consumers too.)
  • Add topic: establishing trust relationships and accountability. Reference was made to work by the Bill Gates Foundation.
  • State: What are the threats and vulnerabilities that are being mitigated? WHY is each criterion important? (Agreed)
  • Consumers really need guidance as to the risk of the app content. E.g., are the medical or health claims valid? Are there any special considerations that the user needs to know about? For example, a medical device needs to back up its medical claims and is regulated by FDA. If the claims are not “medical” then it is less clear. However, the principle of backing up any claims (citing evidence) is good to include. Including a conditional SHALL[IF] for medical devices
  • Look at the API Task Force recommendations (I explained that we did)
  • cMHAFF Section 3.4.3 maybe should move to Privacy.
  • To be international, be clear when limitations are domain specific, and whether they apply if travelling to a different country. Follow EHR WG’s precedent, “in accordance with applicable laws and jurisdiction” or statement like that.
  • Find a happy medium between writing too much, vs only referencing other material (which would force the reader to go to many places)
  • Study Sync4Science (NIST effort, including apps for patient to contribute to research data), which has assessment criteria for apps. Get SfS contact information from Johnathan Coleman.
  • American Psychiatric Association (contact: Lori Simon) has similar requirements.
  • We agreed to discuss cMHAFF topics on selected CBCC Tuesday Calls (2-3 Eastern Time), starting in February. The cMHAFF team will organize specific “asks” to bring to each meeting.
  • Alexander Mense will send us the EU Patient Bill of Rights, which is relevant.
  • John Moehrke questioned the assertion that Mobile Apps are different.
  • John advised that we should help readers know what they should worry about, not how they should deal with it, in order to be more resilient to rapid technological changes. (We need to think about this, and whether we can omit the “how”)
  • Other recommended references ISO IEC/TR 80001-2-3 (Application of risk management for IT-networks incorporating medical devices -- Part 2-3: Guidance for wireless networks) and ISO/IEC 82304-1:2016 (Health software -- Part 1: General requirements for product safety)