Page History

The MedBiquitous Public Comment Forum provides a place for public comment on any efforts by the MedBiquitous program that do not reside in another space (for example, ANSI Standards Action).

The MedBiquitous Community is comprised of individuals across the health professions and globe passionate about the need for open education data standards. Participants from industry, academia, and government organizations alike are welcome.

The health professions are undergoing many changes during the digital transformations of higher education, continuing education and healthcare. Standards are a key element of the infrastructure that is essential to track clinical education and training, measure its efficacy, integrate education and improvement resources with systems at the point of care, deploy online courses in different environments, and link education and performance data to core competencies and curricula. Technology standards also provide the opportunity for organizations to work together in new and innovative ways.

MedBiq -Curriculum Inventory Specifications v1_11_Confluence.pdf

REVISION REQUEST

Remove Data item “Supporting Link”; Page 16

• Description: The supporting link field allows schools to provide a web address that could contain documentation on their curricular structure. This data item is optional.
• Current State: The AAMC does not use the supporting link field and cursory testing suggests many of these links are non-functional. E.g., 404 Page Not Found.
• CIWG Decision: No change and provide guidance on excluding data from upload.
• Rationale: Element is already optional in the specification.

Program Title; Page number 16.

• Description: Title is meant to allow schools to provide some form of identifying information about their submissions.  The data item “Title” is required.
• Current state: Currently, this is required, and schools have no consistent structure to the information contained in this field.  AAMC does not use this field.  Most schools enter their school name and the academic year, both of which AAMC already knows; this field is redundant. 
• Proposal for change: Remove the data item “Title,” or make the data item “Title” optional and communicate formatting standards.
  • Data:
    • Examples from 2017-2018: 
      • 2017/2018
    • Medical School Curriculum July 1, 2017 - June 30, 2018
      • 2017/18
      • 2017/2018 CI
      • 2017-18
      • 2017-18 SOM-All
      • 2017-2018 CI Report
      • 2017-2018 CIP Report 9-6-18
      • 2017-2018 CIR upload
• CIWG Decision: No change but provide guidance on how to format titles.

Change “Program Description” to optional; Page number 16.

• Description: Program Description is meant to allow schools to provide some form of identifying information about their submission.
• Current state: Currently, this is required, and schools have no consistent structure to the information contained in this field.
• Proposal for change:  It is difficult to provide constraints around free-text, so the quality is difficult to verify.  AAMC has not and does not plan to use this item.  People submit a variety of data types, much of which is not usable.  It is extraneous burden for members to complete data fields which do not serve a purpose.
• CIWG Decision: Make optional

Profession/Specialty; Page 21-22

• Current: The data items “Profession” (the appropriate response is “physician” for all AAMC CI submissions) and “Specialty” (e.g., anesthesiology, cardiology, etc.) currently are tagged at the program level from the MedBiquitous Healthcare LOM specifications.
• Proposed: Remove the data items “Profession” and “Specialty” from the AAMC CI specification requirements.
• CIWG Decision: No change and provide guidance on excluding data from upload.
• Rationale: Elements are already optional in the specification.

Remove data item “Educational Context”; Page number 21

• Description: The data item “Educational Context” specifies what type of educational program it is (e.g., patient education, primary education, etc.) It is an optional field.
• Current State: AAMC does not use the data from this item.
• Proposal for Change: All AAMC’s submissions are coming from the same educational context. For MedBiquitous, it seems likely to create some discrepancy in quality in any case, as many of our schools might call themselves “undergraduate education” programs, but this might overlap with nursing schools with undergraduate bachelor programs. It may be that all medical schools are meant to be considered “undergraduate professional education” but it is unclear.
• CIWG Decision: No change and provide guidance on excluding data from upload.
• Rationale: Element is already optional in the specification.

Interprofessional; Page number 26

• Description: The data item “Interprofessional” is an optional.
• Current State: The placement of this data item as an attribute of an event is odd. There are other data items like “clinical environment” or “service-oriented” that also could be considered attributes of an event but are instead included in the AAMC/MedBiquitous standardized instructional methods. Currently the AAMC does not use this item for reporting results; more school training would be needed to have people use this item consistently in their data sets.
• Proposal for Change: To be determined. This data item should be reviewed with representative members and vendors. It should not be continued “as is.”
• CIWG Decision: No change, item optional; provide guidance on excluding data from upload.
• Rationale: Element is already optional in the specification.

Primary instruction method vs. time per method; Page number 28

• Description: The data items “instructional method” and/or “Assessment method” are required for events. Schools can indicate more than one method (or repetition of the same instructional method) but must indicate which method is “primary.”
• Current State: Vendors who use a scheduling/calendaring function to populate their CI may find this change relatively easy; vendors who do not may find this change challenging. A business rule implication may be whether or not to require schools account for 100% of time in events with various instructional methods.
• Proposal for Change: Remove the concept of “primary” and replace instead with “amount of time” (hours, minutes) per method tagged for instruction, assessment, and resources. Keep the ability to tag multiple instructional and assessment methods to a single event, including repetition of the same method.
• CIWG Decision: Keep attribute “primary” and add attribute “amount of time.”

Formative and summative; Page number 29

• Current: Each “Assessment method” within an event must be tagged with either a “Formative” or “Summative” purpose. The LCME still uses the terms “Formative” and “Summative.” As curriculum evolves, schools often use a “formative” assessment method mid-course so that students can improve, but also assign a nominal amount of grade contribution to these formative assessments (e.g., weekly quizzes during the semester will add up to 15% of the course grade.) The separation between summative and formative in terms of grading is becoming blurry.
• CIWG Decision: Preferred option to leave as-is for now with awareness that this is not future proofed. Refer to definitions somewhere else.

Expectations/Competency Objects; Page number 31

• Current: “Expectations” encompass many concepts: objectives, competencies, learning outcomes, milestones, performance levels, EPAs. Expectations and Competency Objects essentially mean the same thing: learning objectives, although both terms are used in the CI specification documents. It is confusing for users of the specifications to have multiple terms within a document with the same meaning.
• CIWG Decision: No change.
• Rationale: Narrowing scope/applicability of the standard.

Expectation IDs; Page number 31 (Competency Object Framework – pages 17-18)

• Description: Expectations at each level (e.g., program, sequence block, etc.) are assigned an ID by AAMC.
• Current State: There is not a field that explicitly asks for expectation IDs which schools have assigned to their expectations. This is a numeric value that has no meaning to schools so isn’t valuable to share back. Schools may develop schema for creating their own expectation IDs that have meaning, and would be valuable for AAMC to share back with them in reports. Some schools are currently using the “description” field for this purpose, but others have evolved using the description field for other things, and as these uses may have meaning to schools, we’re likely to get negative feedback if we try to relabel “description” as “ID,” rather than creating a new optional field.
• Proposal for Change: Create a new optional field for expectation ID per expectation at each level (e.g., program, sequence block, event).
• CIWG Decision: This is already possible in the specification.

Program expectation domains and competencies; Page numbers: 32.

• Description:  Program expectations are linked to PCRS competencies.  Program expectations, or program objectives, and their domains, are not separate fields so schools include them both. 
• Current state:  Having domains included at the same hierarchical level as program objective competency statements creates data quality issues.  Creating a new field for domains would allow AAMC to create new reports. 
• Proposal for change: Create a new optional field for Program Expectation (objective) domains.  Allow schools to create links between program expectation domains and their program expectations.  Create business rules to prevent domains being included program objective competency statements.  The current requirement of program expectation links to PCRS competencies will remain a requirement. 
• CIWG Decision: No change
• Rationale: This is already possible in the specification.

Academic Level Label; Page number 35.

• Description: The data “Academic Level” includes a section for “Label.”
• Current: Schools are not clear that what AAMC is looking for is a title for each academic level. The specifications do not define that academic level is meant to follow a cohort of students; additional edits to the CI FAQ list may be warranted.
• Proposal for change: Edit “Academic Level – Label” to “Academic Level – Title.”
• CIWG Decision: No change but make the instructions clearer.
• Rationale: Changing documentation is a simpler marketplace level change than changing the data model.

Academic Levels; Page 35.

• Current: The AAMC needs some kind of organizational approach in the CI to tell which pieces of the curriculum come earlier or later. Removing the Academic Levels and not replacing them with anything would remove AAMC’s ability to know the order the curriculum occurs in.
• CIWG Decision: No change
• Rationale: Level to Phase change is superficial with no changes to underlying data dictionary or logical model. Marketplace level change of data model not warranted.

Sequence Block (#19) and Integration Block (#18); Page numbers 36.

• Current: two organizational concepts for events – sequence blocks with start/end dates and durations, and integration blocks without start/end dates and durations.
• Goal: to make a system that is flexible enough to accommodate different curriculum and curriculum evolution, but also one that is user-friendly in its word choices and as simple as possible in its documentation requirements.
• Proposal:
  • Create the concept “course/module” to replace sequence blocks
  • To hold/organize events in the CI
  • Synonymous with block/unit (for our CI purposes, understanding that there’s a valid counter argument here)
  • Still have the same qualities as sequence blocks do now (e.g., titles, description, duration, learning objectives, can be nested etc.), with the caveat that we will allow courses to cross over phases (formerly academic levels), as was voted on but never implemented in MedBiq release 1.1
  • Include field for course/module “type” as the CI already does this with clerkship type (rotation or integrated are the current choices), allowing users to choose more than one.  Categories to include:
    • Discipline-based (e.g., pharmacology, medicine)
    • Systems-based (e.g., The Gastro-Intestinal System, Food to Fuel)
    • Integrated (i.e., normal/abnormal presentations)
    • Clerkship (predominantly clinical, real-patient experiences)
    • Rotational (i.e., course repeats throughout year but contains different cohorts)
    • Longitudinal (i.e., crosses time while simultaneous courses are experienced)
    • Extra-curricular (e.g., orientation)
    • Required or Optional
    • Elective or Selective
• CIWG Decision:
  • Request #18: No Change. Integration blocks will remain. Consideration for changes to what they are called will be considered
  • Request #19: No Change. Consideration for change to “course.” Similar to previous changes to other element naming conventions, marketplace impact of change compared to improved documentation should be heavily weighed.
  • Attribute list to replace “ClerkshipModel” still under consideration.

Preconditions & Postconditions; Page 41

• Description: Describes preconditions (e.g., prerequisite) that must be met for a learner to take this course. Describes how the curriculum changes depending on the learner’s performance in the sequence block. These are optional attributes of all sequence blocks. This is an open-text field.
• Current State: In the 2017-2018 data, three schools used the precondition field, none used the postcondition field. AAMC has not used data from this standard for reporting.
• CIWG Decision: No change and provide guidance on excluding data from upload.
• Rationale: Elements are already optional in the specification.

Definition for Sequence block event; Page numbers 41 and 47.

• Current state: The definition for “Sequence block event” includes the phrase “an education,” which does not make sense.
• Proposal for change: Update wording on page 40 so that “an education” is replaced with “a learning or assessment event.”  The same wording is repeated on page 44.  On page 44, the wording should be updated to: “If a sequence block contains nested sequence blocks to reflect the structure of the curriculum, it is not necessary for parent sequence blocks to contain events, although they may.”
• CIWG Decision: Update as per the Proposal for Change.

Competency object reference; Page number 41

• Current:  For the item “competency object reference,” the description reads: 
• A reference to the unique id for a learning objective, competency, learning outcome, (all of which are known as competency objects) associated with this event. CompetencyObjectReference has the following format: /CurriculumInventory/
• Proposed: Change the word “event” to “sequence block,” as this is a typo.
• Purpose: Clarity in the document(s) will help users better understand the specifications.
• CIWG Decision:  Fix typo.

Revision request #25: Events in nested sequence blocks; Page number 47

• Current state: Sequence blocks are required to have at least one event in a CI data submission. With nested sequence blocks, these do not necessarily each need evets within them, if ultimately the nesting ends in at least on event.
• Proposal for change: Update description so that its clear eventually the nested sequence blocks need to have at least one event. “The parent block does not need to contain events.”
• CIWG Decision: Simple update to text to clarify description.

Revision request #26: Event reference; Page number 49

• Current state:  The item “Event reference” the last sentence reads, “All in one line, where X is the id of an event in this Curriculum Inventory.”  This does not make sense.
• Proposal for change:  Edit to read “All the text in the line above, where X is the ID of event in this Curriculum Inventory, needs to be on one line.”
• CIWG Decision: Make requested edit to documentation. (Note: from a mathematical perspective, the original phrasing is correct.)