Chair: @Bryn Rhodes
Scribe: @Bryn Rhodes
NOTE: This attendance applies if you are present at the related meeting/call, regardless if you have signed a different attendance for your WG.
Attendees
Present | Name | Affiliation |
---|---|---|
Minutes Approved as Presented
X |
---|
This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."
Agenda Topics
Agenda Outline | Agenda Item | Meeting Minutes from Discussion | Decision Link(if not child) |
---|---|---|---|
Management | Minutes Approval | ||
Methodology | CDS Hooks Hook Definition Notice of Intent to Ballot: | Reviewed NIB and content Motion: Isaac Vetter/Ken Kawamoto: 13-0-0 | |
CDS Compartment Harmonization Proposal | Continued discussion focused on how the provider systems would know to use this label. The use case is within an HIE, satisfying consent use cases where participants have indicated the information can be shared but only in emergency (which averting a patient safety event would fall under emergency). It's still not clear how providers would know whether or not a given data element should be labelled with this. The gist of this is that most of the use cases so far in CDS usually the access clearance in a particular instance is bound by the access token provided by the client. This is fundamentally trying to change that so that a CDS Server can have broader access and take into consideration that the client requesting the hook is not necessarily authorized to access. Agree with the use case and intent, but provide the caveat that it will be difficult (if not impossible) in general to understand when to apply this, given that it's not possible in general to determine what data is required for CDS, because the specific CDS algorithms may not be known ahead of time. Committee also provides the feedback that there should be no expectation (and it should be clearly stated as such) that this has to be used in all cases. It should be a specific policy decision to enable use cases in particular environments. Also recognize that this is not the only mechanism to achieve this use case and implementations should be free to choose alternative mechanisms. | ||
FDA Guidance Comments
| There are four criteria that result in being exempt. One is that it's presented to healthcare professionals, another is that the supporting evidence is displayed (decision support is not independently driving the decision). The challenge is if you provide information to patients, it's not to the healthcare professional, and then by those definitions, it would be considered a medical device. Unless it's low risk The problem is they separate non-serious, serious, and critical. Example would be OTC medication for cold symptoms. But providing information directly to the patient could be construed as being a medical device by these criteria. Argument can be made that lots of shared decision making and education materials could be considered potential serious risk because it's advising a patient to consider more care. The concern is that this could be so broadly construed that a patient using Wikipedia to look up symptoms could be classified as a medical device (because it's presenting information to a non-healthcare professional). | ||
JIRA/Tracker Update
| |||
CQL STU Comments | Moved to next meeting | ||
FHIR Trackers | Moved to next meeting | ||
Project Updates | Moved to next meeting | ||
Management | Next agenda 11/20 call cancelled for AMIA 11/27 call:
| ||
Adjournment | Adjourned at 1:00ET |
Supporting Documents
Outline Reference | Supporting Document |
---|---|
Minute Approval | 2019-10-30 Meeting Agenda |