Note that this comment is "Not Persuasive", since there are no change as result of the comment. RE: 1) We reviewed the ballot material with an eye to ascertain whether this specification is advantageous, disadvantageous or neutral with regard to clinician burden reduction and patient safety assurance. Have clinician burden and patient safety been considered? Is there any formal documentation of this analysis? Are there specific points of guidance which might be included to show how this specification can be used to enhance front-line clinician practice, reduce burden and ensure patient safety? US Core descended directly from the Argonaut guide to support FHIR Version STU3 and eventually FHIR R4 and The ONC  U.S. Core Data for Interoperability (USCDI) v1 . The USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange.  We refer the commenter the  USCDI Fact Sheet   and the ONC's Cures Act Final Rule  to learn more about the benefits of a nationwide, interoperable health information exchange. RE: 2a) Not clear if/how provenance is captured, represented and persisted (over time) in this specification. Knowing who did what when were and why is essential. Capture points include: i) point of origination (at the source, for newly captured content), ii) point of update (for newly updated content whilst preserving previous content and its provenance). Who = subject of care/information (typically the patient) Who = participant in action taken, including role (e.g., performer, assistant, observer) and credentials (e.g., MD, RN, PharmD, therapist, MA...) Who = author of information captured or updated Who = organization What = action taken When = date/time of action taken When = date/time of information capture or update Where = physical location of action taken Where = physical location of information capture or update Where = network address and/or device ID where information captured or updated Why = rationale, purpose of action taken 2b) Provenance elements, if not captured at the point of origination or point of update, are often forever lost beyond that moment. 2c) Granularity of provenance (e.g., binding authorship to content) may be at the dataset or element level, as appropriate. 2d) Provenance elements are intrinsic to what the source system or device already “knows” at the point of origination or update and thus should not increase burden by requiring extra input on the part of the entering author (clinician or other end user). US Core provides  explicit and detailed guidance for supporting Basic Provenance .  This contents was the result of a thorough and extensive engagement with members of the Argonaut community and the HL7 security working group.  It was agreed that most important information is the last organization making a meaningful clinical update to the data, and the prior system providing the data, the ‘last hop’.  Participants didn’t dispute the potential need to recreate the full chain, but didn’t see this as relevant to the immediate end-user. RE:  3) For FHIR IGs, please include reference to Clinical Safety - FHIR Implementer’s Safety Checklist: [_http://hl7.org/fhir/safety.html_] Agree and US Core already has a section on Clinical Safety  which includes a link to  http://hl7.org/fhir/safety.htm