Attendees

Agenda

RE: relatedClinicalStatement -
- Ken: Name attributes explicitly but keep the relatedClinicalStatement structure but discourage its use. May be used to consistently generate extension mechanism for physical representation.
- Bryn: If we discourage use, we should simply leave it out. Extensibility should be in the realm of the physical representation. There should be a bridge from the LM to the PM extension mechanism.
- Proposed approach - Demonstrate that we can remove generic mechanisms such as relatedStatement in the LM but still support extensibility in PM. Exercise: Show how a relationship modeled explicitly as a named attribute (with a relationship to a model of meaning via the is-about metadata field) in LM is then mapped to an extension in a FHIR profile or in generated code.
RE: Merging Reason and Indication - The group felt that both should be merged and go under proposal. For ProcedureProposal, it should be called Indication - TODO: Verify this can be done in ADL (i.e., renaming a field in a specialization)
RE: Comments: A reviewer noted that the attribute 'comments' is too lightweight. We discussed two approaches: a composite structure with code (type of comment) and text (content of comment) vs an explicitly named attribute based on comment type (e.g., notesToClinician). The group favored the latter approach since it is consistent with the discussion on related clinical statement above.