This wiki has undergone a migration to Confluence found Here

Difference between revisions of "CMHAFF call, Thursday, Oct 26"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
ATTENDEES:  
+
ATTENDEES: David Tao, Nathan Botts, Gary Dickinson, Adamu Haruna
  
 
AGENDA
 
AGENDA
*Discuss timeline (which is now growing short) and plan to complete work on time. '''Need to refrain from adding new material and focus on getting existing material into shape for ballot, by resolving questions and open issues.'''  
+
*Discussed timeline (which is now growing short) and plan to complete work on time. '''Need to refrain from adding new material and focus on getting existing material into shape for ballot, by resolving questions and open issues.'''
 
**Initial content deadline Nov 26
 
**Initial content deadline Nov 26
 
**Reconciliation deadline Dec 3: is it needed, since ballot reconciliation was done long ago, and it was a comment-only ballot?
 
**Reconciliation deadline Dec 3: is it needed, since ballot reconciliation was done long ago, and it was a comment-only ballot?
 
**Final content deadline Dec 17
 
**Final content deadline Dec 17
*NIB to be reviewed at MH Friday meeting on Nov 3
+
**There are six remaining cMHAFF calls. David will propose subdividing cMHAFF into five "chunks" that will be reviewed in the first five calls, allowing for a final overall review in the last meeting. It will important to stick to this schedule and off-line review (not just in-meeting review) will be required.
 +
*NIB was reviewed. It will be proposed at MH Friday meeting on Nov 3
 
*Review and decision on specific comments
 
*Review and decision on specific comments
**DKT2 -- Decision Tree diagram. I suggest dropping it, unless I can find a volunteer to draw a greatly simplified version that maps to cMHAFF.  
+
**DKT2 -- Decision Tree diagram. We will skip it for now. Nathan may have a new version suitable for an Appendix.  
**DKT5 and DKT8 -- Product development. Are all aspects of the product development life cycle appropriate to mention, if there are not corresponding conformance criteria for all of them?
+
**DKT5 and DKT8 -- Product development. Are all aspects of the product development life cycle appropriate to mention, if there are not corresponding conformance criteria for all of them? We decided to leave this as is.
**DKT6 -- Environmental Scan
+
**DKT6 -- Environmental Scan -- We agreed with the changes.
**DKT7 -- statement about cMHAFF and regulations
+
**DKT7 -- statement about cMHAFF and regulations. Agreed.
**DKT9 -- Secure Coding practices reference
+
**DKT9 -- Secure Coding practices reference. Nathan will send David a reference he found.
**DKT13&14 -- Risk Management references
+
**DKT13&14 -- Risk Management references. Agreed.
**DKT18 -- OK to say that Product Information does not all have to be in one place?
+
**DKT18 -- OK to say that Product Information does not all have to be in one place? Yes.
**DKT21 -- Liability discussion. OK now after revision?
+
**DKT21 -- Liability discussion. OK now after revision? Yes.
**DKT28 -- new text on identity proofing, and limitation of its scope
+
**DKT28 -- new text on identity proofing, and limitation of its scope. OK after revision to refer to "other HIT systems" (not required if standalone app).
**DKT29 -- Strong authentication options
+
**DKT29 -- Strong authentication options. Agreed.
**DKT34 -- Data Provenance
+
**DKT34 -- Data Provenance, OK after slight revisions to mention CDA and FHIR as examples.
**DKT41 -- Audit standard?
+
**Did not get to the last 3
**DKT47 -- Initial set of definitions. Check for important missing terms.
+
***DKT41 -- Audit standard?
**DKT48 -- Platform-specific considerations
+
***DKT47 -- Initial set of definitions. Check for important missing terms.
*Review Section 2.2 '''cMHAFF Label''' major simplification (based on last week's conversation). '''I propose to make this a non-normative Appendix, since it will take too much time to gain consensus, it's beyond our scope to execute, and it could divert attention from the Conformance Criteria which are the most important (normative) part of cMHAFF.'''  
+
***DKT48 -- Platform-specific considerations
*Adamu sent an email on October 6th that we should consider (copied below)
+
*Review Section 2.2 '''cMHAFF Label''' major simplification (based on last week's conversation). '''I propose to make this a non-normative Appendix, since it will take too much time to gain consensus, it's beyond our scope to execute, and it could divert attention from the Conformance Criteria which are the most important (normative) part of cMHAFF.'''  We agreed to move it to the Appendix, and that the simplification was a good idea.  
 
 
== Adamu's Oct 6th Email ==
 
 
 
Hi all,
 
Coming back to PAS document and the general discussion about cMHAFF .
 
   
 
I think in general we need to figure out how we could leverage or incorporate or complement PAS as whole ( without UK specific standards) into cMHAFF . Not for this ballot session but may be during the resolution of the comments after January. PAS has a bit different style from all the specs we’ve looked at, in a sense that it looks at the project life cycle of the apps..  Product development in fact will become highly relevant in light of FDA precertification program : https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/Default.htm  and some companies have already been selected : https://www.fda.gov/NewsEvents/Newsroom/PressAnnouncements/ucm577480.htm
 
 
In essence, FDA will follow & check your SW design and process and certifies it (like ISO certification ) so they don’t have to certify each individual product coming from that company. Any product from that will go directly to the market and FDA will go straight to post market data collection phase. This  makes SW process/product development life cycle very key or central here …and that is where PAS comes in for health and wellness apps.
 
 
cMHAFF covers almost everything from PAS i.e. from the consumer or market perspective => translated backwards to what developer should do before releasing the product/app to the market .  I think we can plug PAS ( or some part of it ) in 3.2  to guide the developer on what process to follow to meet cMHAFF conformance at the front end . Or we can also check PAS Annex A (informative ) : relation between PAS and IEC 62304  i.e. how PAS selected keys parts and light version of IEC 62304
 
 
I don’t know how in practice we can do this but definitely we should not re-do the work but smartly reference or incorporate or point to the developer what process to follow in product development …( liaison or work together to pick some parts into cMHAFF annex or direct reference)
 
 
Please , let’s have a look as general task  outside the current ballot preparation . I think after January we need to see how to proceed to  position cMHAFF to not only address current FDA direction but a  “go to” framework for various app stakeholders in the consumer health industry 
 
 
My two cents…
 
 
   
 
   
 
/Adamu
 
/Adamu

Revision as of 20:17, 26 October 2017

ATTENDEES: David Tao, Nathan Botts, Gary Dickinson, Adamu Haruna

AGENDA

  • Discussed timeline (which is now growing short) and plan to complete work on time. Need to refrain from adding new material and focus on getting existing material into shape for ballot, by resolving questions and open issues.
    • Initial content deadline Nov 26
    • Reconciliation deadline Dec 3: is it needed, since ballot reconciliation was done long ago, and it was a comment-only ballot?
    • Final content deadline Dec 17
    • There are six remaining cMHAFF calls. David will propose subdividing cMHAFF into five "chunks" that will be reviewed in the first five calls, allowing for a final overall review in the last meeting. It will important to stick to this schedule and off-line review (not just in-meeting review) will be required.
  • NIB was reviewed. It will be proposed at MH Friday meeting on Nov 3
  • Review and decision on specific comments
    • DKT2 -- Decision Tree diagram. We will skip it for now. Nathan may have a new version suitable for an Appendix.
    • DKT5 and DKT8 -- Product development. Are all aspects of the product development life cycle appropriate to mention, if there are not corresponding conformance criteria for all of them? We decided to leave this as is.
    • DKT6 -- Environmental Scan -- We agreed with the changes.
    • DKT7 -- statement about cMHAFF and regulations. Agreed.
    • DKT9 -- Secure Coding practices reference. Nathan will send David a reference he found.
    • DKT13&14 -- Risk Management references. Agreed.
    • DKT18 -- OK to say that Product Information does not all have to be in one place? Yes.
    • DKT21 -- Liability discussion. OK now after revision? Yes.
    • DKT28 -- new text on identity proofing, and limitation of its scope. OK after revision to refer to "other HIT systems" (not required if standalone app).
    • DKT29 -- Strong authentication options. Agreed.
    • DKT34 -- Data Provenance, OK after slight revisions to mention CDA and FHIR as examples.
    • Did not get to the last 3
      • DKT41 -- Audit standard?
      • DKT47 -- Initial set of definitions. Check for important missing terms.
      • DKT48 -- Platform-specific considerations
  • Review Section 2.2 cMHAFF Label major simplification (based on last week's conversation). I propose to make this a non-normative Appendix, since it will take too much time to gain consensus, it's beyond our scope to execute, and it could divert attention from the Conformance Criteria which are the most important (normative) part of cMHAFF. We agreed to move it to the Appendix, and that the simplification was a good idea.

/Adamu