aamc.org does not support this web browser. Learn more about the browsers we support.

New section

Content Background

New section

AAMC Curriculum Inventory (CI) Technical User Guide

A technical guide for the 2022 AAMC CI upload season and beyond.

New section

New section

Logo for the AAMC Curriculum Inventory

The AAMC CI is a technically complex, large-scale data collection. For a successful CI experience, it requires those with expertise in curriculum, data management and IT to come together. Data and technical staff may be expert in data organization and software development, however, may be uncertain about the meaning of the curriculum content within the CI. Educational staff may be expert in curriculum and the data reports they need but may be uncertain of the back-end programming of their CI’s technical platform.

This document was created by the Association of American Medical Colleges (AAMC) Curriculum Inventory (CI) staff and is intended for supporting schools and informing vendors in annually uploading their curriculum inventory data to the AAMC.

The purpose of this Guide is to provide instruction and explanation to CI users on the technical basis for the AAMC CI’s structure and contents with language understandable from an educational and technical perspective. Through the CI Technical User Guide, we hope to:

  • Support those with education expertise to be facile with the CI standards’ technical specifications.
  • Facilitate conversations about CI between educational and information technology staff.
  • Illustrate how the AAMC CI applies the MedBiquitous data exchange specifications.

Contents of this Guide:

  • Section I: Background

    • MedBiquitous data exchange specifications
    • Compliance with the MedBiquitous specifications and AAMC CI Business Rules
    • Complementary guides and resources
    • CI XML data file and upload options
    • Multilingual CI data
    • Formatting CI data with quality in mind
  • Section II: CI XML and technical specifications
    • CI technical specifications one-pager
    • CI technical specifications details and XML sample
  • Section III: Appendices
    • A: Optional elements in the MedBiquitous specifications that AAMC CI does not collect

    • B: Elements in the MedBiquitous specifications that are edited or new for 2022

    • C: Business rules and errors

    • D: Valid competency relationships

    • E: Complete XML sample from this Guide

    • F: Literature references

    • G: AAMC CI Codebook

  • Authors and acknowledgment

  • Contact

Section I: Background

MedBiquitous data exchange specifications

The purpose of data exchange standards is to provide structure so that data can be formatted and organized. This enables data to be shared, and to be used to create reports and interpretations. The AAMC CI uses the MedBiquitous data exchange specifications to govern the structure and type of data that can be submitted to the AAMC. MedBiquitous is the standards development program of the AAMC that creates IT standards for health professions education and quality improvement.

The MedBiquitous specifications which inform the AAMC CI are the:

  1. Competency Framework Specifications
  2. Competency Object Specifications
  3. Curriculum Inventory (CI) Specifications
  4. Healthcare Learning Object Metadata (LOM) Specifications
  5. Professional Profile Specifications

Please note that you must create an account, separate from your AAMC account, to access the MedBiquitous website standards. For questions about the MedBiquitous specifications please contact medbiq@aamc.org.

Compliance with the MedBiquitous specifications and AAMC CI Business Rules

The MedBiquitous Curriculum Inventory Implementation Guidelines version 1.0 (dated November 1, 2012) states: Before implementing the Curriculum Inventory, analyze the context in which it will be used and determine:

  1. Which data elements and attributes are necessary to achieve your goals.
  2. Whether additional business rules or policies are necessary to achieve your goals.
  3. Whether your business partners have additional requirements or business rules or policies.

A school’s CI data must first conform with the MedBiquitous specifications. Then, the AAMC CI has additional business rules which must be met to successfully upload CI data to the AAMC. It may be helpful to review the documents in the following order:

  1. MedBiquitous specifications (the 5 listed above) and their related documents
  2. AAMC CI Business Rules

The MedBiquitous specifications require that CI data be formed into a file format called XML; further explanations of what XML is can be found in the next section of this Guide. A school’s CI XML file will not successfully upload to the AAMC unless it meets all the requirements of all these documents. If a CI XML data file does not conform with the MedBiquitous specifications when it is uploaded to the AAMC, it will cause an error and the file will not continue to load. The CI data file will not be checked for compliance with the business rules until conformity with the MedBiquitous specifications is met.

The business rules can be thought of as additional requirements to ensure data quality. The business rules provide limitations so that documentation practices which may be technically allowable but not educationally sound are removed from CI data. Adherence to data quality is addressed in additional ways beyond the business rules and is described further in this Guide.

To confirm whether a CI XML data file is conforming with the MedBiquitous specifications, a school or vendor can check a CI XML data file against MedBiquitous’ XSD file available here: http://ns.medbiq.org/curriculuminventory/v10/. An XSD file is an XML schema definition file which is used by IT staff to ensure each piece of content in the XML file is formatted correctly. One way to examine your CI XML data file to ensure it is well-formed based on the MedBiquitous specifications is to use a program like Notepad++. A program like Notepad++ will help a user identify whether their CI XML data file does not conform to any of the MedBiquitous specifications.

Once a CI XML data file is confirmed to conform with the MedBiquitous specifications, it also needs to be in compliance with the AAMC CI Business Rules. This can be tested by uploading the CI XML data file to CI Staging; if there are any business rule errors, an error message will be generated.

Once the MedBiquitous specifications and business rules are met in an uploaded CI XML data file, a school’s Verification and Accreditation Support Reports will be generated for review. Examples of these reports are available on the Resources to Use Your CI Effectively webpage.

Please note that some special character formats are difficult to use within XML. For example, hyphens within XML are ok (e.g., 2021-2022), whereas extended dashes (e.g., 2021 – 2022) may be difficult to process. Please confer with your vendor and/or IT staff for guidance about how to document in XML for your specific software.

Complementary guides and resources

This CI Technical User Guide is written to support the technical effort of adhering to the MedBiquitous specifications and AAMC CI Business Rules, allowing for the successful upload of your curriculum to the AAMC CI. This Guide should be used in conjunction with the MedBiquitous specifications and their related documents, available on the Resources for CI Developers and the MedBiquitous webpages.

Additional AAMC CI resources that may be useful to review, in this suggested order, as you use this Guide include:

  1. CI Glossary (PDF)
  2. CI Frequently Asked Questions (PDF)
  3. Guide to Building a CI
  4. CI Portal User Guide (PDF)
  5. Physician Competency Reference Set (PCRS)
  6. Standardized Vocabulary for Instructional Methods, Assessment Methods, and Resources (PDF)

CI XML data file and upload options

XML stands for eXtensible Markup Language. It is a common language used for sharing data on the Internet and is meant to be readable for both people and computers. In a curriculum management system (CMS), the curriculum data may display in a variety of formats that are understandable for faculty, staff, and students. A CI’s technical platform takes a school’s curriculum mapping data and converts it into an XML file that can be shared with the AAMC.

Like any language, the syntax of XML has rules about what is well-formed and what is poorly formed language. For the purposes of this Guide, the goal is not to reproduce a crash course in XML. Rather, it is to help educators and IT staff understand how the AAMC CI uses XML to capture curriculum data.

For technical staff, many developers may already be familiar with XML. Some may need additional resources to familiarize themselves more deeply, such as this World Wide Web Consortium (W3C) XML resource, or this W3Schools XML tutorial. It is essential that IT developers who interact with the AAMC CI have an understanding XML language.

For educators, many may have little experience with XML beyond the AAMC CI. While some basic knowledge of XML can be helpful for discussions with your IT colleagues, the expectation is not for educators to become deeply fluent in XML. The XML samples in this Guide may help educators to feel informed about how to best review their CI data for accuracy and completeness. If you are curious and wish to find more resources regarding XML in addition to those above this How To Geek's What Is An XML File (And How Do I Open One)? explanation may be useful.

A school’s CI XML data file can be uploaded by schools or on their behalf by vendors – how to set up a school’s data sender (either the school themselves or a participating CI vendor on their behalf) is described in the CI Portal User Guide.

A school’s CI XML data file can be uploaded to the AAMC directly through the CI Portal, or can be shared via a Web service. Schools who create their own data files often use the CI Portal for uploading their data to the AAMC, while schools with a CI participating vendor often have a Web service feature within their vendor software. A Web service allows schools or vendors to use their own process to upload CI data to the AAMC. More information about the use of a Web service is available in the CI Portal User Guide and the XML Tools document on the Resources for CI Developers webpage. Please note that CI participating vendors and schools wishing to use a Web service to upload their CI data to the AAMC must confirm an IP address (or IP address range) by June 1 annually in order to have that IP address or range allow-listed with the AAMC.

Multilingual CI data

If portions of CI data are written in languages other than English, those portions should also be spelled out in parentheses in English to ensure non-English data is represented in curriculum reports. For example, a school may have an optional course regarding medical Spanish, and perhaps that course/module is titled, “Medicina en Español.” In the school’s CI data XML file, the course/module title would read: Medicina en Español (Medical Spanish), having both the Spanish and English spellings of the course/module title.

Formatting CI data with quality in mind

The CI data which AAMC collects is used for a variety of purposes: the reports generated support schools in benchmarking, program evaluation, continuous quality improvement, curriculum renewal, and accreditation. The reports also are used to inform AAMC initiatives, conduct research, and inform advocacy work. Because the data is used to inform decisions and disseminate knowledge, it is vital that the CI data shared with the AAMC is of high quality.

CI data needs to be accurate and complete.

Accuracy is the first priority; completeness is the next priority. While the AAMC has multiple post-data collection processes to clean and cull data, it is resource intense and has limitations, as additional data cannot be collected for a given year once the collection period closes.

The goals of a school’s CI are to:

1. Represent the experience of any hypothetical, proto-typical student. For example, perhaps each student chooses one of four sub-internships. The CI file needs to make it clear that although there were four sub-internship options, any student would be responsible for taking only one of those four.

2. Represent the breadth of curriculum offered at a school. For example, while the individual student chooses one sub-internship, the four choices offered include primary care, pediatrics, surgery, and hospital medicine. All four sub-internship options in this hypothetical case would need to be represented in the CI.

The concept “garbage in, garbage out” from the fields of computer science and mathematics applies here too – if inaccurate and incomplete data are entered in a CI, the reports created from this data will be of uncertain value. The more high-quality, detailed information in your CI, the more comprehensive and useful curriculum reports can be. If a set of CI data is determined to be potentially inaccurate or incomplete, it may result in that portion of CI data being removed from the overall data set.

Further in this Guide, data quality issues as they relate to each element are described. Before reading the specific data quality issues for each element, and in addition to the data quality recommendations in the Guide to Building a CI, let us examine some data quality guidelines that apply to all your CI data:

1. Do not include identifiable data. Please do not include personal identifying information (e.g., professor’s names, contact information, University name, etc.) in your CI data sent to AAMC. A common place identifiable data is included inadvertently is within learning objectives:

  • Sample event-level learning objective with identifiable data: “After today’s session, students will be able to list all of Dr. Sample’s rules for anatomy lab safety.”
  • Sample program-level learning objective with identifiable data: “Upon graduation, students will reflect all the behaviors within Sample University’s code of professionalism.”

Other common areas for inadvertent identifying data are the event or course descriptions. When these fields are used to house instructions and communication channels to the students:

  • Sample event description with identifiable data: “Send your proposal to d.sample@ptu.edu once your team has completed the review”.
  • Sample course description with identifiable data: “Tuesday and Wednesdays will be spent in Trustworthy Hospital’s ICU while Monday, Thursday, and Fridays will be spent at the Named Outpatient Facility."

2. Check spelling errors. Many software programs have spell-check programs, but even in those cases, it is helpful to confirm that spelling errors are being effectively identified. For example, the word “clinical” is often misspelled or shortened (e.g., clin) which can make it difficult to capture in reports.

3. Write learning objectives well. Learning objectives are a rich source of data when querying curriculum for content. Learning objectives within the AAMC CI exist at the program, course/module, and event level. Multiple chapters within the Guide to Building a CI discuss factors to consider when evaluating learning objectives for quality. A library collection with resources for writing learning objectives well is available in the virtual AAMC Curriculum Community.

4. Spell out acronyms. Universally known and unique acronyms such as ACLS may be easier to search. However, acronyms with more than one possible meaning may make it difficult to determine content.. For example, perhaps your school has the “BEST” program (Better Education for Student Teachers). Without the parentheses to make the content clear, it would be difficult to include the “BEST” program’s content in curriculum reports.

5. Choose consistent terminology. Establish a standardized way to refer to your content in each topic so that you have consistency across courses and content. For example, will your CI have the words “cancer,” “neoplasm,” “oncological,” “tumor,” or will you provide your faculty and staff a list of terms to use consistently across your CI? The AAMC CI keyword list is a useful resource to ensure consistency across some terminology in your CI.

6. Avoid duplicates. In general, duplicate learning objectives, events, and course/modules should be avoided. Because the CI tries to represent the experience of any proto-typical student, duplicates within the CI should only be present if any proto-typical student would encounter the same content more than once. Because some software systems use real calendar data to populate the CI, it may be that duplicate courses or events are inadvertently brought into the CI. For this reason, it is important to confirm that there are no duplicates in the CI submission before it is shared with the AAMC, unless those duplicates are there deliberately to represent the curriculum accurately and completely.

7. Avoid documenting what did NOT occur in the curriculum in your CI uploaded to AAMC. The AAMC CI is a place to document what did happen, what was taught. While capturing what was canceled or did not occur may be important for schools to document for internal purposes, that kind of data should not be included in schools’ CI data uploads to AAMC. In addition to canceled curriculum, another way schools may be tempted to document what did not occur could be in specific content areas. For example, a school might document in the description of an event that this event covered “adult diabetes, NOT pediatric diabetes.” If you were to later do a search for pediatric diabetes in your CI, this event’s content might be included in the report when in fact it should not. Using keywords is a more effective way to document what curriculum content was related to pediatrics. Please see the AAMC CI Keywords on the Resources to Use Your CI Effectively webpage.

8. Use “nested course/modules.” In the Guide to Building a CI, there is further detail about when and how to use the nested course/module (i.e., sequence block) feature in the “Course-Level Details for Your CI” chapter. This allows the curriculum to show hierarchy, and group courses to show both the experience for any proto-typical student, and the breadth of curriculum offered. Additional features of nested course/modules are described in Section II.

Return to Top ↑

Section II: CI XML and technical specifications

Return to Top ↑

Section III: Appendices

A: Optional elements in the MedBiquitous specifications that AAMC CI does not collect

The following elements within the MedBiquitous CI specifications are optional and not used by the AAMC CI, and do not need to be included in schools’ uploads to the AAMC CI. The AAMC CI must collect all elements and attributes of the MedBiquitous specifications which are required. The MedBiquitous document to refer to for the below listed elements is MedBiquitous Curriculum Inventory (CI) Specifications, DRAFT version v10 2021-01-06.

  • Supporting link
  • Integration
  • Elements from other name spaces.
  • Educational context
  • Profession
  • Specialty
  • Event description
  • Event interprofessional
  • Academic level description
  • Sequence and Sequence description
  • Pre-condition
  • Post-condition
  • SequenceBlockLevels – scheduling

The following elements are not described within this Guide. However, it is acceptable for schools to use these aspects of the MedBiquitous specifications and include them in their CI submissions to the AAMC:

  • From the SequenceBlock attribute Required, “Required in Track”
  • The SequenceBlock attribute “Order”
  • Track

B: Elements in the MedBiquitous specifications that are edited or new for 2022

The following elements within the MedBiquitous CI specifications have been changed for 2022, and can be explored further within this Guide:

  • Description (of the overall curriculum) is now optional (previously was required)
  • Instructional method duration (new)
  • Phase start and phase end per course/module (new)

The new field for documenting program objectives’ domains is new to the AAMC CI, but not specifically described in the MedBiquitous documents. Program objective domain is described fully within this Guide.

C: Business rules and errors

Download Appendix C Business rules and errors (PDF)

D: Valid competency relationships

Download Appendix D Valid competency relationships (PDF)

E: Complete XML sample from this Guide

Download Appendix E Complete XML sample from this Guide (PDF)

F: Literature references

Download Appendix F Literature reference (PDF)

G: AAMC CI Codebook

When asked “what is in the AAMC CI?”, one could provide this entire Guide as an explanation of the CI’s contents. However, the XML described in this Guide may be difficult for some stakeholders to understand. To help schools communicate with their stakeholders, including those interested in performing research using CI data, to understand what data is in the AAMC CI, the following list of data points in more plain language is provided.

  • School information
    • Name
    • AAMC Institutional ID
    • MD or DO program
    • Number of years (e.g., 3 or 4) in program
    • Address
  • Report information
    • Report ID
    • Report date (i.e., submission date)
    • Start date of report
    • End date of report
    • Language (English)
  • Program-level information
    • Narrative description of overall curriculum
    • Program objectives
    • Program objectives’ domains (e.g., patient care, professionalism)
  • Phases
    • Number of phases
    • Titles of phases
    • Which courses occur in each phase
      • Time (in days, converted to weeks) per phase, based on courses which occur in each phase
  • Events
    • Unique ID
    • Title
    • Duration in hours/minutes
    • Start and end dates of events
    • Keywords
    • Learning objectives
    • Resources (e.g., written and visual media, clinical case)
    • Instructional methods (e.g., lecture, team-based learning)
      • Which method is primary
      • Duration in hours/minutes per instructional method
    • Assessment methods (e.g., practical laboratory exam, written or computer-based test)
      • Formative or summative per method
    • Course in which each event occurs
  • Courses (including clerkships, modules, blocks, themes, etc.)
    • Unique ID
    • Title
    • Type (e.g., discipline-based, system-based, etc.)
    • Narrative description
    • Learning objectives
    • Duration in days
    • Start and end date
    • Whether course is a clerkship
      • For clerkships, whether it is rotational or longitudinal
    • Organizational structure (i.e., nested course structure, if any, including minimum and maximum courses that are taken)
    • Which events occur in a course
    • Phases in which a course occurs
  • Learning objectives
    • Learning objective unique ID
    • Actual text of learning objective
    • Category of learning objective
      • Program objective domains (e.g., patient care, professionalism, etc.)
      • Program objectives
      • Course-level learning objectives
      • Event-level learning objectives
    • Learning objective relationships
      • Relationships from each of schools’ program objectives to PCRS competency statements
      • Hierarchical relationships among schools’ learning objectives (e.g. 1 program objective has these 5 course-level learning objectives linked to it)

Return to Top ↑

Authors and acknowledgments

Primary authors:

  • Angela D. Blood, Director of Curricular Resources, AAMC, Washington, D.C.
  • Walter Fitz-William, Senior Data Specialist, AAMC, Washington, D.C.

We wish to thank the following CI Committee and members for their review and feedback:

  • Matthew Drilling, Instructional Design Coordinator, Des Moines University College of Medicine
  • Jose Lopez, Director of Academic Technology, Texas Tech University Health Sciences Center El Paso
  • Christina Magnifico, Program Director, Medical Education Technology, University of Kansas School of Medicine

We wish to acknowledge the following AAMC staff for their assistance in editing and providing feedback:

  • Anne Farmakidis, Senior Director of Educational Resources and Scholarship, AAMC, Washington, D.C.
  • Linh Le, Curriculum Inventory Program Specialist, AAMC, Washington, D.C.
  • John Nash, Director of Business Operations, AAMC, Washington, D.C.
  • Johmarx Patton, Director of Educational Technology and Standards, AAMC, Washington, D.C.

Return to Top ↑

Contact

CI Technical User Guide questions can be sent to ci@aamc.org.

Return to Top ↑

New section

New section