This wiki has undergone a migration to Confluence found Here

Difference between revisions of "2016 04 13 Minutes - CQF Data Model Call"

From HL7Wiki
Jump to navigation Jump to search
 
Line 27: Line 27:
 
** 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.
 
** 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: 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.
+
* 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.

Latest revision as of 18:13, 13 April 2016

Back to the CQI Work Group Wiki
Back to the CQI WG Health Quality Information Models Wiki

Attendees

  • Claude Nanjo
  • Karl Poterack
  • Lizzie DeYoung
  • M'Lynda Owens
  • Marc Hadley
  • Richard Esmond
  • Ryan Clark
  • Chris Markle
  • Ken Kawamoto
  • Ashley McCrea
  • Bryn Rhodes

Agenda

  • Status update on tooling work
  • Review proposed attributes for the model
  • Address comments received on the model

Meeting Notes

In this call we reviewed the following spreadsheet: https://docs.google.com/spreadsheets/d/1bp2SXuuUxo6iYi3R_S15WQKlptjX-xCPdrYAnL4D1NQ/edit#gid=237906698

  • 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.