MCC eCare Plan Discussion
- MCC eCare plan presented ballot reconciliation and disposition plan for January 2023 for comments only ballot on MCC eCare Plan IG
- MCC eCare Plan project team to post block vote details by email to PCWG ahead of MCC eCare Plan conference call in 4 weeks
FHIR IG for physical Activity
1.0.0-ballot - STU1 ballot-draft
Lloyd McKenzie - presented NIB for HL7 FHIR® Implementation Guide: Physical Activity, Release 1 - US Realm
Link to IG - https://build.fhir.org/ig/HL7/physical-activity/
Responses to questions:
- Lloyd clarified that (a) physical activity measures captured can contribute to frailty scores and (2) the IG is cross clinical domain, not just cardiology
- Lloyd indicated the project team will engage with USCDI panel to inform | explain work on the IG
- Lloyd also confirmed that the IG content and quality are in good shape
Motion to approval the FHIR IG NIB accepted by PCWG and submission for May 2023 ballot cycle:
Moved: Lloyd McKenzie, Seconded: Shelley Spiro
Voting members: Lloyd, Shelly, Emma Jones, Jay Lyle, Gay Dolin, Karen Bertodatti (Chair: Stephen Chu)
Outcome
- Votes: 6-0-0
- Motion carried
Action - NIB to be submitted by PCWG co-chair
...
Wednesday, 5 pm ET, https://zoom.us/j/5328571160
Attendance
Name | Affiliation | Name | Affiliation |
---|---|---|---|
Care Plan DAM Discussion
DAM to do in R2:
1. inclusion of CCS: probably not
2. update detail on existing model (goals, barriers, etc.) based on confluence notes
we need to weed/ consolidate notes
create a list, e.g., barrier: def [link to minutes]
barrier: examples [link1, link2, not link3]
. . .
OR
go ahead and update model; let co-chairs identify gaps/opportunities
AND
ensure requirements are represented in use cases
3. update detail based on other efforts (MCC, PACIO, etc.)
4. provide detail needed for 'manifestation' model
update 1e use case?
update some other use case?
add a use case?
5. outline per guidance
conceptual, with optional logical refs to existing standards
data elements: may use 'conceptual' types
* do we need conceptual types
terminology: content domains, not bindings
* change current: 'conceptual' (rels) & 'logical' (elements) to
=> 'conceptual high level' & 'conceptual detail level'
* remove RIM colors, parameterized classes, BFO classes
behavioral:
use case (functional) vs storyboard (descriptive)
* do we need both
structural
class diagram vs data element list
* do we need element list
* do we need identified behavioral interactions to "trigger" structural packages