While it is important to maximize these adoption drivers, a subset of these drivers can be sufficient to spur the adoption of new standards and interoperable solutions.
diff --git a/site.index.json b/site.index.json index b42dad9..f961c9c 100644 --- a/site.index.json +++ b/site.index.json @@ -1 +1 @@ -[{"id":0,"doc":"Playbook","title":"About the Playbook","url":"about/index.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top About the Playbook Better Data Better Health The purpose of this Playbook is to capture the learnings of the MITRE team as they with the cooperation of a growing community launched the CodeX HL7 FHIR Accelerator led development of the minimal Common Oncology Data Elements mCODE and other FHIR Implementation Guides and deployed FHIR based solutions to help patients providers and others in the real world It is hoped that MITRE s experience can provide a recipe to successfully launch and implement new healthcare specialty interoperability initiatives For more comments and questions please email mcode mitre org Organization The MITRE Corporation MITRE was established to advance national security in new ways and serve the public interest as an independent adviser MITRE continues to deliver on that promise every day applying our systems thinking approach to provide solutions that enhance our national security and way of life Our non profit status sets us apart Motivated by impact our people discover new possibilities create unexpected opportunities and lead as pioneers for the public good"},{"id":1,"doc":"Resources","title":"Technical Standards Development Deep Dive","url":"resources/tech-standards.html","content":"On This Page Standards Development Deep Dive Clinical Requirements FHIR IG Development HL7 Standardization Back to top Technical Deep Dive into FHIR Based Standards Development Tailored for clinical subject matter experts standards developers and systems implementers Health data standards help patients health systems payers researchers and others who need to work together communicate using a common language Health data standards can specify clearly how data are collected stored shared and or used such that every piece of data can be unambiguously understood by all entities within the health ecosystem These standards are not the end product and instead are an essential means empowering accurate electronic data sharing to improve health care and access and to reduce burden and costs The following sections will guide clinical and technical experts through Health Level 7 HL7 processes to refine clinical requirements and develop implementation guides IGs It is advised that throughout the process the teams undertaking these efforts utilize existing communities and resources including chat fhir org HL7 Work Groups and FHIR Accelerators These external groups have extensive expectance in all aspects of FHIR software development and can significantly reduce the time required to develop real world impactful software for the specialty community The best standards are standards that are demanded by product consumers community driven and developed within an open royalty free standards organization often recommended or mandated by the government well documented demonstrated to provide value easy to implement in systems and workflows and widely adopted by the community CodeX mCODE Standards Development Tutorial The following is an excellent video by May Terry key mCODE author that provides a deep dive into the strategy and process employed to develop the mCODE FHIR IG standard for oncology This strategy and approach should be applicable across health specialties Selected points from the video are summarized in text and graphics on the rest of this page Introduction and Agenda 5 mins mCODE Development History 4 mins mCODE Modeling Methodology 7 mins Define Use Case 5 min Gathering Relevant Clinical Information 13 mins Translate Information into FHIR IGs 15 mins Validate FHIR IG 5 mins Case Study CardX 5 mins Case Study GenomeX 4 mins mCODE Deeper Dive Q A and general discussion 89 mins Key Organizations and Foundational Standards Health Level Seven HL7 develops approves and maintains medical interoperability standards across the world While it is possible to develop interoperability standards outside HL7 in practice it is unlikely these standards will be widely adopted without HL7 approval As a result it is critical to follow HL7 processes and collaborate with HL7 work groups when starting or modifying any IG This collaboration is best started early in the IG development process at or before the first draft of the IG is complete The Office of the National Coordinator for Health Information Technology ONC is the principal federal entity charged with coordination of nationwide efforts to implement and use the most advanced health information technology and the electronic exchange of health information ONC spearheads assembling community agreement on a standardized set of health data classes and constituent data elements for nationwide interoperable health information exchange called the United States Core Data for Interoperability USCDI ONC also coordinates the USCDI initiative which supports domain or program specific data element lists that operate as extensions to the existing USCDI The mCODE team is coordinating closely with the USCDI cancer domain team ONC has increasingly partnered with HL7 the preeminent organization for gathering communities to develop standards that enable health data interoperability Of the many important efforts within HL7 two are foundational for the work described in this Playbook Fast Healthcare Interoperability Resources FHIR and US Core FHIR Implementation Guide Both are further explained below Standards Development Overview The following graphic illustrates key steps that are necessary and or useful in developing and publishing a quality HL7 standard FHIR Implementation Guide This process is agile thus the cycles representing steps with iterations and interactions between each cycle Diagram describing the development of a FHIR Implementation Guide from Clinical Requirements to FHIR IG Development to HL7 Standardization Simple Clinical Concept Example Systolic Blood Pressure The following example shows how the FHIR Implementation Guide development process outlined above can be applied to a simple clinical concept such as systolic blood pressure Step 1 Clinicians are consulted about what information and factors need to be captured regarding systolic blood pressure for example What is the measurement value What units are used to measure the value Note that this is a simplified example to introduce the process There are other factors to be considered e g how is blood pressure measured where it is measured on the body body position etc Step 2 Create a data dictionary to capture how that information from Step 1 should be represented Consult with clinical terminology subject matter experts to fill out the data dictionary Review results with clinicians and gain their approval Diagram showing example data dictionary for exchanging systolic blood pressure Step 3 Determine the FHIR design from the data dictionary to exchange the required systolic blood pressure information Review results with the community clinicians terminologists technologists and gain consensus Diagram showing example FHIR design for exchanging systolic blood pressure from HL7 FHIR US Core 7 0 0 Additional Considerations to Enable Cross Health Data Interoperability When defining Use Cases and the associated data standards make interoperable data exchange the top priority Data exchange standards can also influence and provide value for data collection Data that will be exchanged must be collected or be computed from data that are collected How the data are stored within systems can be defined by the implementor to meet engineering requirements Implementers may find value in leveraging data exchange standards in their storage schemes How the data are displayed and manipulated e g interfaces for collection aggregation review computation analysis and others can be defined by the implementor to the benefit of users Implementers may find value in leveraging data exchange standards in their display and manipulation schemes Following the Design Principles has many benefits including helping to ensure consistency with other efforts which is critical in working towards a unified lifetime Standard Health Record where an individual s health data is captured accurately and consistently across medical systems and specialties see figure below Leveraging established clinical requirements and a common standards framework of US Core and standard terminologies as CodeX Use Cases and mCODE do enables individual specialties to develop their IGs independently and yet as consistently as possible The Standard Heath Record vision could extend the CodeX mCODE approach to help new specialties expand communities and to develop and test standards that are interoperable across specialties and that drive adoption and value for patient health care and research Image is placeholder only will replace with accessible image Clinical Requirements Information Needs and Data Dictionary For clinical subject matter experts the goal is to guide the initial steps of the implementation development process to prioritize information requirements within a data dictionary needed for the use case Thus a well rounded team of clinical subject matter experts is necessary for guidelines on how to establish this team see the Clinical Requirements section in the high level overview of standards development One of the first tasks of the clinical requirements team is to define the scope of the data dictionary Both CodeX and FHIR design principles recommend a minimalist approach cover the most common and important use cases not necessarily all edge cases This approach speeds development work improves the odds of reaching consensus and creates a final product that can be expanded to meet future needs This sub step and subsequent steps are typically iterative For example the clinical expert group may develop a first draft of the Data Dictionary Subsequent steps often result in requests to the clinical experts for clarification or suggestions for updates to the Data Dictionary based on FHIR development implementation and testing Defining the Data Dictionary A data dictionary is a conversion of the clinical information needed for the use case into logical model data elements To begin to define the data dictionary the clinical expert group will identify a set of clinical requirements for a use case The clinical requirements and data dictionary template provides an example assessment of a cancer patient and instructions for filling out the template The spreadsheet Clinfo_NGS contains necessary data elements for the use case data sources references to prior work and under the Use Case Relevance column is an expert assessment of Relevance to Patients Like Mine to help prioritize the minimal set of information needed A blank spreadsheet for clinical requirement development can be found in the Clinfo_Template spreadsheet Once information needs have been prioritized the group should consider whether the data elements should be Required Data is unusable or makes no sense if not present Optional Data is not always relevant and not needed for data to be usable Must Support Software is required to support this data element The group can next develop the data dictionary a Rosetta Stone that defines data elements mapped to the clinical information requirements An example data dictionary and a blank template can be found in the clinical requirements and data dictionary template in the DEDToClinfo_Example and DEDToClinfo_Template spreadsheets respectively Common Challenges Related to Compiling Clinical Information Requirements and a Data Dictionary Starting with a large set of important data needs elements rather than focusing on the needs for each prioritized use cases Not thinking about how to maximize the utility of information across other use cases For example the information needed for initial diagnosis of cancer might also be used for clinical trials matching or conducting trials Slight changes to the initial requirements could enable the same information to be useable across all three use cases Asking for interpreted information rather than source data because that is established practice For example asking for age rather than collecting birth data and date time of the encounter These and other potential pitfalls can be largely avoided by following the Design Principles compiled based on CodeX and mCODE experience Clinical Review of the Data Dictionary Before handing the data dictionary over to the FHIR IG development team the clinical team should answer the following questions Does the Data Dictionary address the goal and needs of the use cases From a clinical perspective will the new data dictionary be compatible with other known or prospective data dictionaries with the specialty and outside of it FHIR IG Development Integrating Clinical Requirements into a Specialty FHIR Implementation Guide Once the clinical subject matter expert group has at least a draft of their data dictionary for the use case work can begin on incorporating the clinical information into one or more FHIR IGs Once the FHIR IG development team has been assembled both the IG development team and the clinical requirements team will collaborate to ensure the clinical information needs are captured properly in the FHIR IG that the FHIR IG is implementable in systems and processes and that it is consistent with the Design Principles A specialty should aim for a single core IG that represents the minimal clinical requirements for a set of Use Case concepts that are common within the specialty The mCODE FHIR IG is an example of a core IG The core IG can be appended and improved as Use Cases are executed Supplemental IGs can be built when new data requirements are not considered core but important for smaller Communities and or edge applications Framework for FHIR Implementation Guide Development As is likely clear by now use of the FHIR exchange standard is foundational to the recommendations in this Playbook technical experts will need a deep understanding of FHIR to guide processes Below are some helpful guides to better understanding FHIR Fast Healthcare Interoperability Resources FHIR is the health data sharing framework widely used now and is being mandated for certain applications through ONC US Core FHIR Implementation Guide IG encapsulates into the FHIR framework the data classes and data elements defined through US Government coordination and the United States Core Data for Interoperability USCDI and will evolve as Government work evolves HL7 requires IGs designed for the US healthcare system to be based on the US Core FHIR framework unless a waiver is approved by HL7 FHIR Tutorials FHIR Basics for Post Acute Care by Jessica Skopac MITRE approachable introduction to FHIR for the non technical HL7 Courses on FHIR Intro to FHIR by James Agnew Smile CDR FHIR for Developers Getting Started by Gino Canessa Microsoft Standard Terminology refs HIMSS CMS A terminology code system is a managed collection of structured terminologies concepts like procedures diagnoses treatments measurements results and others with the objective that there is one globally unique code alpha numeric typically to represent each concept Code systems terminologies and vocabularies are not the same things but are highly related and often used together or for the same idea SNOMED CT LOINC CPT are some examples of widely used code systems The benefit of representing a concept with standard terminology in an IG and elsewhere is that the concept can be implemented in FHIR or other standards in health information systems and understood everywhere the concept is collected stored exchanged and used FHIR Shorthand FSH is a domain specific language for defining FHIR artifacts involved in creation of FHIR Implementation Guides IG The goal of FSH is to allow Implementation Guide IG creators to more directly express their intent with fewer concerns about underlying FHIR mechanics and efficiently produce high quality FHIR IGs FSH is an HL7 standard FSH is increasingly used around the world There are excellent tutorials on how to leverage FSH to create FHIR IG FSH School Mark Kramer Learn to FSH A friendly introduction to FHIR Shorthand DevDays 2023 Amsterdam PDF version Data Model The first task of the FHIR IG development group is to review the output of the clinical group s data dictionary It is helpful if some members of each group have been working together even before the first draft of the dictionary has been completed Questions between the groups will be common and essential to taking additional steps The next step is to start development of a conceptual model from the data dictionary and begin the process of identifying existing FHIR artifacts IGs profiles and extensions that the developing IG can use it is critical that specialty communities minimize changes and modification to existing FHIR artifacts to maintain consistency within the larger healthcare data exchange community This helps ensure the final IG and associated software more easily accepted and adopted across all healthcare domains Below is mCODE s conceptual model and an interactive version can be found within the mCODE IG Example conceptual modeling diagram for mCODE STU 3 2023 draw io was used to create the mCODE modeling diagram Terminologies As previously noted terminologies standard clinical code systems are important for unambiguously defining how data within the data element are represented When a term cannot be found within an existing code system it s possible to work with the owner of the code system to add new terms provided the justification is convincing Profiles and Extensions FHIR profiles customize the standard FHIR base Resource definitions by constraining which values and elements of a resource are required and which are not for a particular context or use case FHIR extensions add data elements and or constraints for the standard FHIR base resource definitions to create more specific customized resource definitions for a particular context or use case The following shows how mCODE derived profiles from the aforementioned framework of the US Core FHIR IG The subsequent three figures illustrate how the mCODE conceptual model is represented in the FHIR IG for patient demographics labs and medications to match the clinical information needs as structured data Diagram of FHIR Resource derivations showing how mCODE is built on US Core and FHIR Base resources To ensure consistency with the wider interoperability community the IG development team should first check the FHIR Implementation Guide Registry FHIR Package Registry and FHIR Extension Registry for existing FHIR artifacts that might be reused in the developing IG If an appropriate existing artifact cannot be found new resources profiles or extensions may need to be created Before creating a new FHIR artifact the IG development team should discuss the proposed artifact and its purpose with the HL7 Working Group responsible for the FHIR Resource being extended All FHIR resources and profiles have an HL7 Working Group that is responsible for their development The HL7 Working Group is listed on the FHIR resource page itself or in the case of a profile in the footer of the profile page Reviewing the proposed artifact with the responsible working group provides an opportunity for them to understand the purpose for the extension and offer guidance in alignment with their development strategy for the resource When packages and other IGs are leveraged by a project they become dependencies of that project When depending on other FHIR packages and IGs to leverage it is important to consider what versions to use since in many cases multiple versions may exist There are many factors that should be considered when determining what version of a FHIR package or IG to use Have they been officially published and if not when will they publish This will affect the development timeline What level of adoption does that version have or will have in the near future Using the latest version may push adoption further out in time relative to using an older version in broader use What regulations may apply Regulations can stipulate what versions can be used e g US Core version requirements for product certifications Planning FHIR IG Development A Patient Demographics Example There are a number of important high level questions to consider when developing a FHIR IG These questions can be found in the higher level FHIR IG Development section Example Patient Demographics Diagram of an mCODE Patient Bundle entry based on external profiles Relevant external profiles are added as an entry to the mCODE Patient Bundle profile Possible because mCODE s bundle is open only CancerPatient is a required entry Guidance for inclusion is narrative not computable or enforceable Validating Modeling Assumptions Next create a comprehensive set of FHIR resources that capture the product of the previous steps One approach to validating the work is to match it to representative use case personas The next figure illustrates how parts of a particular patient journey are mapped into data elements and FHIR See other mCODE examples represented in the mCODE FHIR IG A particular patient journey mapped into data elements and FHIR to validate the model Creating the FHIR Implementation Guide Initial creation of a FHIR IG can start quite early and iterate as the model is improved HL7 Standardization Health Level Seven HL7 is the preeminent organization for gathering communities to develop standards that enable health data interoperability The US and other nations increasingly look to HL7 as the place for health standards development p HL7 Standards Process Agreeing on content of the FHIR IG to be standardized and then moving the IG through the HL7 process can take many months on the order of a year from start to publication of a standard Time required depends on level of alignment of the IG authors and also on how familiar project s standards process leader is with HL7 processes and people but can be many months to more than a year Projects should make sure to include sufficient time in the use case plan and also start the standardization process early before a complete draft FHIR IG is available Resources that are important to review and understand HL7 Essentials Index to information on HL7 HL7 processes and other information that is relevant to anyone planning to work or working in HL7 Understanding the Standards Process Explains what HL7 does rationale for the processes and how to maximize the benefits of using the process FHIR Implementation Guide Process Flow When creating a FHIR IG that is intended to an HL7 standard there are a number of specific steps to complete A timeline based on HL7 s early 2024 processes is shown here This is subject to change Please check the previous link for the latest HL7 s graphic HL7 Process Flow and Timeline is also helpful in that steps in the HL7 process are linked to details on each step Maintaining HL7 Standards Once the first version of a specialty standard the Standard for Trial Use STU has been completed and published work begins on maintaining the standard over time Any standard that is valued implemented into systems used widely will generate requests for updated versions Updates to specialty standards may be needed for a variety of reasons The base standards on which your standard depends e g FHIR US Core may be updated and may require or at least motivate changes to standards that depend on them Users or the vendors may ask for updates Government rules and regulations may motivate changes Because changes to your standard may be required over time it s important to keep a core of the original IG development team intact and add to that core with the necessary skills e g clinical FHIR HL7 available when needed It s important to keep a good relationship with the sponsoring HL7 Work Group It s necessary to have a system to collect organize prioritize and address requests for changes and other comments likely the same system used for building the original standard e g Jira at HL7 Be aware that the interest of the original teams and even that of the Use Case champions may change as the work enters maintenance As repeatedly emphasized in this Playbook think about which members of the community care most about ensuring a standard is maintained in a well governed careful manner For example vendors who ve implemented the standard and included the standard in products to many customers should care about how the standard is maintained and evolved Best Practices for Smoother HL7 Standardization Based on the CodeX mCODE Experience The standards process leader for the use case should have thorough knowledge of HL7 processes and standardization schedule Build HL7 standardization into your use case plan from the start Allow plenty of time to go through the process Have a good relationship with a sponsoring HL7 Work Group and its leadership Ensure they are included in plans and progress In many cases HL7 Work Group may have deep expertise within the community s specialty however even if they do not they will know HL7 standards HL7 processes and work that other Work Groups are doing that may be related to your work Collaborate with a HL7 FHIR Accelerator like CodeX This path has the benefit of working within an organization that will be more knowledgeable of and connected closely to HL7 people and processes Discuss any new extension and its purpose with the HL7 Working Group that has responsibility for the FHIR Resource being extended so that they understand the need and can provide guidance NOTE Add more best practices"},{"id":2,"doc":"Resources","title":"Implementation and Testing Deep Dive","url":"resources/implementation_deep_dive.html","content":"On This Page Standards Development Deep Dive Deep Dive into Implementation and Testing Tailored for technical systems developers and test leaders The goal of implementation and testing is to ensure that the developed IG Implementation Guide is translated into real world software and that this software provides value to end users To achieve this the IG developers often need to coordinate with workflow subject matter experts end users and software vendors to develop open source demonstration software including reference implementations and develop testing tools to support software adoption These resources will help speed the implementation process guide developers in adapting the software to real world instances and excite end users about the potential benefits of the community s use case Here we will walk through the development processes identifying common readily available free tools that the community can use to manage test and update the community s software Software Development Lifecycle SDLC The SDLC guides software through key steps in the development process Requirement gathering Software Design Coding Testing Deployment Maintenance and Support While software vendors will oversee this process when they adapt the community s IG for local instances of the IG software the community will need to follow this process for any of its open source software such as reference implementations or testing tools This discussion provides a detailed overview of the process and methodologies waterfall agile and others used to guide software development teams through the SDLC phases Development Recommendations Requirements Gathering See the Use Cases Planning page for guidance on requirement gathering Software Design Software design typically encompasses both the function of the software and the user interface However what end users see and how they interact with the data is typically the purview of software vendors As such discussions on the community s role in software design focus on the design of standardized data exchange and IG development See the Standards Development section and the associated Standards Development Deep Dive for guidance on IG development Coding Development Environment It is strongly recommended that the community develop open source software within an environment that allows a team of developers to effectively manage the code Key personnel like developers can and often do change over the course of the project As a result it is critical that there is a single repository for the community s code ideally one that can be made public when software is ready for release There are many options for code management and software repositories the most common repository for open source projects is GitHub To ensure that developers can work collaboratively yet independently it is also recommended that they use project management software such as Trello Jira or Microsoft Teams to track development goals and resolve bug fixes in a timely manner FHIR Artifacts A common starting point for many looking to jumpstart their development is leveraging existing FHIR software artifacts such as the HAPI FHIR software which provides working JAVA software for many basic FHIR resources HAPI FHIR HL7 s Confluence page and other FHIR open source repositories provide basic FHIR software that can be adapted for the community s purposes Testing Software testing can be broken down into three software states as described in the Implementation Testing section Initial testing Initial development and testing stage conducted by developers Prototyping second round testing conducted with willing potential end users Real world implementation implementation and testing of instances of software within live software systems using real world workflows and data The first two states are the primary focus of community software development The final state real world implementation relies on community partnerships with software vendors or healthcare organizations to implement instances of software within local systems Discussions should focus on the community s role in initial testing and prototyping and leave real world implementation decisions to software vendors It is vital to develop testing tools for the development team and the community to ensure that the IG and associated implementations function as intended Properly developed IG testing tools can facilitate uniform adoption of the community s IG standards and simplify individual implementations by helping developers identify issues with their software or with the IG One tool that can be adapted to test the community s IG is the Inferno testing toolkit which is widely used within the FHIR community to test numerous IGs and by the Assistant Secretary for Technology Policy Office of the National Coordinator ASTP ONC to verify EHRs meet certification requirements for interoperability Another testing tool option is AEGIS Touchstone a commercial testing framework that is also widely used across the FHIR community Initial Testing Much of the development and testing strategy will rely on developers coordinating with use case subject matter experts One critical need in this stage of testing is for accurate synthetic patients to test workflows To avoid the time consuming monotonous process of manually creating test patients developers should use software to generate synthetic patients like Synthea Synthea is widely use by open source medical development communities at Connectathons and in private industry because it can generate populations of realistic patients with medical data such as medications allergies conditions and clinical notes For more information on Synthea s current capabilities and instructions for generating patient data see Synthea s GitHub page for more details Prototyping To both guide community members in their individual implementations and demonstrate the software to end users the community should develop an open source demo otherwise known as a reference implementation of their IG A reference implementation is a system agnostic implementation of an IG that serves as an idealized representation of how the data exchange should function Often it is a simple client server data exchange with a few workflow examples to demonstrate software functionality and utility FHIR IG creators use reference implementations to test and get feedback from both developers and end users in dedicated implementation feedback sessions and during Connectathons HL7 maintains an instance of the HAPI FHIR server for everyone to use It should be noted however that the public HAPI FHIR server has millions of FHIR resource instances and can be heavily loaded particularly during Connectathons Since these resource instances are public testers should never use real patient data on the HAPI FHIR servers or any other open access environment Finally because of the large testing community using the HL7 HAPI FHIR server HL7 may occasionally purge test data to ensure continued server functionality for all HealthIT gov also provides a FHIR Sandbox that includes FHIR R4 servers and the Inferno testing tool HL7 and Logica Health provide free services for developing SMART on FHIR apps graphical front ends Electronic Health Record EHR simulators and OAuth authentication support In this stage of development the Inferno testing toolkit and AEGIS Touchstone as described above are also great tools for testing throughout this stage Real world Testing There is an overlap between real world testing and deployment as real world testing deploys software to local systems The goal of this stage is to verify the efficacy and efficiency of the community s software identify any lingering issues with IG development and gather feedback and prepare the community for larger scale implementations This step is largely overseen by software vendors who are best equipped to make implementation and testing decisions within their software systems Deployment See the Adoption subsection of Adoption Value for high level guidance on promoting adoption of software Maintenance and Support Software Versioning There is one constant in life change FHIR its underlying standards security protocols and the community s IG will all have regular updates some of which introduce major changes to ensure continual improvement and refinement of data exchange processes When creating software development plans it is a necessity to have a well established version control process within GitHub or whatever code repository management software the community chooses to use See this article for specific recommendations and guidance on maintaining version control for the community s software releases Over time the HL7 community has developed multiple versions of FHIR profiles including the foundation for all United States based FHIR Implementation Guides US Core HL7 releases new US Core versions regularly often every year and regulations are being proposed to require a minimum version of US Core that certified medical software vendors must use HL7 is creating draft guidance on how to navigate how IGs can support multiple versions of US Core"},{"id":3,"doc":"Resources","title":"Roles","url":"resources/roles.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources By project role Standards Development Deep Dive Implementation Deep Dive About Back to top Playbook Content by Role The most important Playbook sections recommended for particular types of experts on a standards focused project team Available Roles The Playbook aims to be valuable to a range of organizations and people interested in creating implementing and using health data standards A potentially large number of roles has been consolidated into the following three groups Leadership Clinical Subject Matter Experts Technical Experts For individuals in any particular role there certainly could be value to reviewing also the content recommended for other roles Leadership Important content for people in a leadership role such as specialty and Use Case Champions potential participants in governance organizational executives program and project managers task leads funding organization leaders and similar positions Recommended reading is focused on the executive level description of the tracks summarized in the Introduction plus other key executive content Key Playbook Sections Introduction Getting Started Community Building Use Cases Planning Standards Development Implementation Testing Adoption Value Case Studies Clinical SMEs Important content for people in a clinical or specialty subject matter expert role such as patients doctors nurses health technicians researchers health terminologists clinical experts from vendors and or payers and similar positions Clinical SMEs who may also help to translate health requirements into FHIR IGs may also find the Technical Experts useful Key Playbook Sections Introduction Use Cases Planning Standards Development Overview Clinical Requirements Deep Dive Adoption Value Case Studies Technical Experts Important content for people in a technical expert role such as data modelers terminologists informaticists FHIR Implementation Guide developers software developers designers testers HL7 participants and similar positions Key Playbook Sections Introduction Standards Design Principles Standards Development Overview FHIR IG Development Deep Dive Standardization in HL7 Implementation Testing"},{"id":4,"doc":null,"title":"Resources","url":"resources/index.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources By project role Standards Development Deep Dive Implementation Deep Dive About Back to top Resources On this Resource page you ll find the MITRE Health Data Interoperability Playbook sections recommended for people in particular roles lower level details on particular topics and links related to the tools tracks and Case Studies Explore By Role The most important Playbook sections recommended for particular experts on a standards focused project team Playbook Content for Particular Roles Technical Deep Dives Detailed Playbook tracks for clinical subject matter experts standards developers and systems implementers Standards Development Technical Deep Dive Implementation Testing Deep Dive Tools Resources that new specialty standards initiatives can use for more efficient work Playbook Checklist of the most important steps across all five Tracks download Community charter template download Role and resource planning speadsheet download Data Dictionary Template spreadsheet download SVG Tool used for creating interactive diagrams like the mCODE conceptual data model diagram Links to External Resources Key References Five Tracks Community Building Questions to Address Before Getting Started CodeX HL7 FHIR Accelerator Community CodeX HL7 Membership List CodeX Membership Options CodeX Governance Use Cases Planning CodeX Use Case Development Guidelines CodeX Use Cases Plans and Progress Standards Development Overview and Technical Deep Dive CodeX Standards Design Principles Video tutorial on the development of mCODE May Terry MITRE Nov 2023 2 hr 33 min Office of the National Coordinator for Health Information Technology ONC Health Level Seven HL7 HL7 Essentials Understanding the Standards Process FHIR Implementation Guide Process Flow Fast Healthcare Interoperability Resources FHIR United States Core Data for Interoperability USCDI USCDI specialty supplements to USCDI US Core FHIR Implementation Guide Health Information Coding Systems Health Information Terminology Standards FHIR Shorthand FSH Language for creating FHIR IGs FSH School Tutorial Learn to FSH A friendly introduction to FHIR Shorthand Video minimal Common Oncology Data Elements mCODE FHIR Implementation Guide Implementation Testing CodeX Trial Matching Use Case Phase 1 pilot report More links coming soon Adoption Value Stakeholder Specific Value Propositions White House Cancer Moonshot leveraging mCODE OSTP and ARPA H noted CodeX as an important partner in strengthening the nation s clinical trial infrastructure President s Cancer Panel noted the importance of mCODE in their recommendations for NCI s National Cancer Plan CMS using mCODE in their Enhancing Oncology Model FDA championing CodeX REMS Integration Use Case CDC s use of mCODE for Central Cancer Registry Reporting IG ONC s US Core Data for Interoperability USCDI Cancer is aligned with mCODE ONC included select mCODE data elements in their USCDI proposed Quality Data Element List Key References Case Studies mCODE Standard and CodeX Community Improving Cancer Data Interoperability The Promise of the Minimal Common Oncology Data Elements mCODE Initiative Osterman et al JCO Clinical Cancer Informatics Journal Nov 2020 Unlocking the promise of learning from everyone with cancer Schnitzer STAT Feb 2023 2019 Cancer Data Summit Getting Started with mCODE Latest mCODE FHIR IG CodeX HL7 FHIR Accelerator Community CodeX HL7 Membership List CodeX Membership Options CodeX Governance CodeX Use Case Development Guidelines CodeX Use Cases CodeX Standards Design Principles CodeX Radiation Therapy Treatment Data Use Case Radiation Therapy Treatment Data Use Case CodeX Page Minimum Data Elements for Radiation Oncology An American Society for Radiation Oncology Consensus Paper Hayman et al 2019 Operational Ontology for Oncology O3 A Professional Society Based Multistakeholder Consensus Driven Informatics Standard Supporting Clinical and Research Use of Real World Data From Patients Treated for Cancer May et al et al 2023 PACIO Project PACIO Project Overview PACIO Project Charter PACIO Project Website HL7 Confluence Page for the PACIO Project Use Cases Dashboard Meeting Index YouTube Channel FHIR Implementation Guides Personal Functioning and Engagement Implementation Guide GitHub Repository Advance Directives Interoperability Implementation Guide GitHub Repository Re assessment Timepoints Implementation Guide GitHub Repository Standardized Medication Profile Implementation Guide GitHub Repository Transitions of Care Coming soon GitHub Repositories PACIO Project HL7 Reference Implementation Sample Data Prev Case Studies"},{"id":5,"doc":null,"title":null,"url":"solutions/index.html","content":"Solutions"},{"id":6,"doc":"Playbook","title":"Implementation \u0026 Testing","url":"playbook/implementation.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Implement into Systems Test Pilot Feedback Track 5 Adoption Value Case Studies Resources About Back to top Track 4 Implementation Testing Health data standards must be implemented into software systems and workflows to provide a new or enhanced potentially valuable function in the health ecosystem Assessing the potential for real value requires testing including pilots in increasingly realistic settings Both implementation and testing are necessary for each use case concept workflow standards and or software There are other significant biproducts of this Implementation Testing track It is both an opportunity to ensure the necessary community members are actively involved within increasingly realistic environments and to attract new organizations by demonstrating value For Implementation Testing to progress effectively activities and necessary resources must be included thoughtfully in the use case plans and prepared for as the use case initiative moves forward The rest of this section covers experience gained in a Implementation b Testing and c Feedback on the previously discussed Use Case Planning and Standards Development tracks Implement FHIR IG s into Systems and Workflows Every use case requires implementing at least part of a FHIR IG into software to support generally new aspects of the envisioned workflow to be piloted It s highly recommended to engage market leading software vendors in the specialty space Vendors typically have prior experience testing a customer base that may be interested in new approaches and credibility that will attract others Candidate vendors should be engaged in the community and committed to implement and test and more as early in the use case project as possible If in the early phases engaging leading vendors is not possible implementation into prototypes and or testing software may be a satisfactory first step to allow useful assessments Questions that should be addressed during Implementation include Is the IG understandable based on technical specifications and documentation Is the IG implementable Is the system within which the IG is implemented consistent and interoperable with other systems with which data exchange would be needed Is the workflow represented within the use case and IG realistic and consistent from the developer perspective will also need user input during testing In all cases it s critical to receive specific comments and recommendations for change that can be taken back to the FHIR IG and the use case team so that adjustments can be considered adjustments that could be very helpful before testing becomes intense Test and Pilot Testing and pilots within use cases tend to start simply and then ramp up to as realistic a scenario as possible via multiple phases Testing of the implemented IG should start as early as possible even if on a subset of the future functionality The following table is a simplified set of testing axes that aim for a higher degree of realistic challenges from the top of the table to the bottom A particular test or pilot might combine components from different rows and not just across a single row Example options for elements of system testing that aim for a higher degree realistic challenges from the top of the table to the bottom Difficulty Use Case Workflow Software Data Participants Environment Synthea is an open source synthetic patient generator With no cost and no restrictions Synthea has empowered multiple CodeX pilots as well as testing and research around the world Lower 1 data element via 1 exchange in the workflow Simple test scripts Synthetic data Developers Developer s computers Higher More elements and exchanges Prototypes of needed components of future software systems De identified data Some developers and intended users Connectathons with multiple organizations Highest and Most Realistic All required data elements via all envisioned exchanges in the workflow Software systems intended for deployment and adoption Real patient data Envisioned end users actors from multiple entities of each type of organization required by the workflow Full scale real world pilots within the envisioned organizations e g health system lab Likely includes some testing sandboxes in those organizations Note that the use of real patient data bottom row involves patient and institutional consent appropriate privacy and security protections and should be planned for many months before testing aims to start Early testing provides early feedback and engages key community members in activities that bring the use case concept and IG closer to life However CodeX use cases have found it useful to start with relatively simple tests that can be run 6 12 months after the start of the project including components similar to the first row in the table above Over time CodeX use cases typically ramp up through increasingly ambitious tests to real world pilots including components similar to the bottom row e g demonstrating the full use case workflow using software systems intended for sale or otherwise deployed using real patient data driven by the intended users and within many organizations across which the future use case is planned to operate See the Radiation Therapy Treatment Data Case Study for a good example of planning and ramping up of testing Obviously these real world pilots require substantial planning commitment preparation and legal regulatory steps well in advance of the execution of the pilot This advanced planning is particularly important for testing within real healthcare settings working with real patients and using real patient data For each of the tests and pilots considerations typically include the elements below These elements should be nearly finalized when initial planning is complete especially the commitment of the necessary resources Objectives What improvements in health care and research will the use case provide e g What will be made better faster less expensive more accessible Test Configuration What parts of the use case workflow are being tested and where are they being tested Resources Skill sets e g project management clinical technical logistical legal operational and other skills Software e g EHRs specialty systems payer systems and others Facilities e g health system labs homes registries and others Funding e g for facilities and expertise Success What metrics are available to assess current capabilities What level of improvement will be measured during the test How will success be measured Feedback to Update Previous Work As Needed Even early phase pilots can provide valuable feedback on how implementable the IG is in software the usability of the updated systems and the costs human burden and potential benefits of the new workflow Both implementation and testing can surface the need for updates to the use case concept workflow standards and or software A test or pilot may need to be repeated once these updates are agreed and implemented Prev Standards Development Next Adoption Value"},{"id":7,"doc":"Playbook","title":"Standards Development","url":"playbook/standards.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Clinical Requirements FHIR IG Development HL7 Standardization Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Track 3 Standards Development A Common Language for Better Health Effective communication allows clinicians and patients to collaborate and ensure better health outcomes To communicate effectively all stakeholders in the health landscape need a common language and the same is true for associated data systems Unfortunately too often data systems are siloed with their own local dialects of data unable to easily communicate with other systems without time consuming data translation efforts To improve data communications and ultimately patient care development of data standards guiding the collection storage sharing and use is necessary The discussion on this page focuses primarily on standards around data sharing which may or may not also be how data is stored This allows clinicians patients researchers payers public health and software systems unambiguously understand and communicate every piece of data to other entities within the healthcare ecosystem The following graphic illustrates key steps that are necessary and or useful in developing and publishing a quality HL7 standard FHIR Implementation Guide This process is agile thus the cycles representing steps with iterations and interactions between each cycle Key steps needed to develop an HL7 standard FHIR Implementation Guide To develop clear standards for data communication projects need three things Clinical Requirements The target product is a data dictionary a database documenting a minimal agreed set of clinical data elements necessary to complete the use case s workflow The data dictionary includes the origin of data criticality to the workflow relationships between data elements and data format FHIR Implementation Guide IG Development A FHIR IG is an instruction manual for developers on how to send and receive the data necessary to conduct the use case built from the data dictionary HL7 Standardization Health Level Seven HL7 has governed medical interoperability standards since 1987 HL7 standardization of proposed Implementation Guides is key to gaining acceptance within the larger medical community government oversight agencies and software vendors Implementers could use IGs that are not HL7 standards however they would be less likely to gain widespread adoption This page provides an executive overview intended for leadership of the standards development approach leveraged by MITRE in the CodeX HL7 FHIR Accelerator and other projects Of course much of the standards development and implementation work will fall to clinical and technical subject matter experts Targeted guidance for these experts can be found on the Resources page and on the Technical Deep Dive into FHIR Based Standards Development page These pages also include Video tutorial on the development of mCODE More general tutorials on FHIR interoperability standards Role of United States Core Data for Interoperability USCDI and USCDI in data Interoperability Guides for writing IGs including tutorials on FHIR Shorthand FSH Guidance on when to reuse vs create FHIR artifacts such as profiles and extensions The standards development process can be lengthy Even seemingly small proposals could take many months to fully progress to standardization then implementation in software adoption and value A clear understanding of topics presented here can facilitate work towards the ultimate goal of working impactful specialty software To further speed progress it is recommended that Community focus on the minimum set of necessary data elements This narrow focus allows all aspects of software development use case planning interoperability standards development and implementation and testing to be completed sooner than larger efforts With software and standards developed faster the benefits to the larger Community can be demonstrated sooner Standards and software can always be refined and updated to include additional data and functionality later There are several standards for data exchange within the healthcare ecosystem It is recommended that implementors use the latest data exchange standard FHIR though very rarely other domain specific interoperability standards may be needed Information on for technical experts FHIR data exchange FHIR IG development tools and processes and other data standards used in this space can be found on the Resources page and on the Technical Deep Dive into FHIR Based Standards Development CodeX and mCODE both utilized FHIR throughout their processes as a result the processes described below are directly applicable to FHIR data exchange processes Clinical Requirements Information Needs and Data Dictionary Establishing clinical requirements requires converting clinical concepts into discrete data elements to enable standardization of capture and transport of data To establish these requirements the community s clinical experts will need to develop a data dictionary based on the minimum set of data elements necessary to meet the workflow needs of the use case To streamline the development it is recommended that the clinical requirement team have A well respected chair or co chairs to guide the team A team of 5 20 subject matter experts whose backgrounds cover the necessary clinical expertise for the Use Case To ensure that viewpoints are not overlooked it is recommended that the team represent a diverse set of experts across patient doctor nurse technician informatician researchers software vendors and payers At least one objective moderator to guide discussion and align diverse views One or more experts have previous experience in clinical data capture analysis and data dictionary development One or more experts familiar with interoperability standards such as United States Core Data for Interoperability USCDI USCDI and US FHIR Core profiles to ensure proposed data formats match generally accepted formats used in the wider medical community One or more experts involved in the use case development process Tools and techniques for aligning diverse expert opinions to build a consensus across the panel and the larger specialty Community Use familiar terminology and medical terms when building the data dictionary Knowledge of similar use cases and data exchange needs so that the panel s work can be easily built upon and harmonized with external projects A group charter outlining scope timelines decision processes and other key aspects for clinical requirement development A sample charter can be found on the Resources page downloadable from here Follow the Design Principles Further details for clinical experts can be found in the Clinical Requirements Deep Dive resource section of this site FHIR IG Development Specialty FHIR Data Communication Standards Once the clinical subject matter expert group has a draft data dictionary work can begin with incorporating the clinical information into one or more IG s The IG development and HL7 standards approval processes are technical requiring a FHIR IG development team of interoperability experts to complement the clinical requirements expert team It is recommended that the interoperability team have A well respected chair or co chairs to guide the team A team of 3 10 technical subject matter experts also have an appreciation for the Use Case To ensure that viewpoints are not overlooked it is recommended that the panel is a diverse set of experts including data modelers FHIR Implementation Guide developers terminologists system developers informaticists software implementors and clinical specialty experts At least one objective moderator to guide discussion and align diverse views Two or more experts familiar with the FHIR data exchange and standards including USCDI USCDI and US FHIR Core profiles to ensure proposed data formats match generally accepted formats used in the wider medical community One of these experts should be familiar with FHIR IG development processes including FHIR Shorthand FHIR profiles and extensions and similar IG development efforts within HL7 At least one implementor who can guide IG development efforts to enable streamlined software creation and testing Tools and techniques for aligning diverse expert opinions to build a consensus across the panel and the larger specialty Community Knowledge of similar development efforts within HL7 to enable collaboration and harmonization of efforts with external projects Knowledge of similar use cases and data exchange needs so that the panel s work can be easily built upon and harmonized with external projects A group charter outlining scope timelines decision processes and other key aspects for FHIR IG development A sample charter can be found on the Resources page downloadable from here Follow the Design Principles As noted the clinical expert team needs to work in tandem with the IG development team to ensure the clinical information needs are captured properly in the FHIR IG that the FHIR IG is implementable in systems and processes Each group needs feedback from the other to successfully build and implement specialty data exchange software To guide implementation developing a logical model representing the data dictionary is needed The static graphic below is a representation of mCODE s version 3 called Standard for Trial Use or STU 3 conceptual model published in 2023 Conceptual models are notional loosely represent the actual FHIR model enable clinical and other SMEs to more easily understand the context and use of elements and illustrate how data elements relate to each other Visit the latest version of the mCODE FHIR IG and explore an interactive version of this graphic and dive into the details of this mCODE concept model Example conceptual modeling diagram for mCODE STU 3 2023 draw io was used to create the mCODE modeling diagram Framework for FHIR Implementation Guide Development A specialty should aim for a single core IG that represents the minimal clinical requirements for a set of Use Cases concepts that are common within the specialty The mCODE FHIR IG is an example of a core IG The core IG can be appended and improved as Use Cases are executed Supplemental IGs can be built when new data requirements are not considered core but important for smaller Communities and or edge applications The community s specialty interests may not be well represented in existing FHIR profiles and standard data elements similar to the terminology challenges encountered during the data dictionary development In these cases existing FHIR artifacts including profiles and extensions may need to be developed or updated to better support the community s data needs It is critical that specialty communities minimize changes and modification to existing FHIR artifacts to maintain consistency within the larger healthcare data exchange community This helps ensure the final IG and associated software can be more easily accepted and adopted across all healthcare domains During the IG development process and after updates to the IG are common Updates to the IG could be motivated by updates to underlying standards e g new FHIR versions new USCDI UCSDI versions US Core FHIR profile updates terminology code system updates and others government mandates and regulation changes and shifting changes in need functionality and technology Care should be taken to plan long term upgrade processes to ensure the IG and associated software can be adapted to changing needs and functionality requirements Further HL7 has established processes for IG updates becoming more restrictive as the IG meets standardization milestones It will be necessary to have a system to organize prioritize and address requests for changes and other comments during the IG development processes Questions for Planning FHIR IG Development Are there related external FHIR IG initiatives Are there projects being driven by others in government and or industry that need to be reviewed consulted and or partnered with What existing FHIR resources and profiles best fit the data model What existing resources and profiles best match the required data elements in the data model What existing resources and profiles result in the fewest FHIR extensions that are needed What existing FHIR resources and profiles allow for use of the necessary terminologies Do the selected FHIR resources and profiles require data elements that may not be present in an exchange What FHIR profiles must be created Profiles are created when further specifications extensions or constraints are needed on a FHIR base resource or an existing dependent FHIR profile What FHIR extensions are needed Extensions are used to add data elements that may be missing in FHIR resources and profiles to accommodate a business need What existing resources and profiles need to be extended to support the required data elements in the data model What documentation is needed by senior managers and implementers to understand and effectively implement How will the data be accessed What requirements are needed for data querying and access Change management What version control system will be used Further details for technical experts can be found in the FHIR Implementation Guide IG Development Deep Dive resource section of this site HL7 Standardization and Approval Path Towards Wider Standards Adoption To gain wider acceptance Implementation Guides need formal approval from the healthcare interoperability standards body HL7 As the IG is drafted the IG development team needs to begin processes for eventual HL7 community balloting and approval of the IG Often the sooner these processes are started the smoother the HL7 standards processes help ensure harmonization of IG development efforts across projects and communities This said the standards process is often lengthy and can take many months to over a year from start to publication of an interoperability standard Specific details about the HL7 process and FHIR development in general can be found in the resources section HL7 standards process timeline for new FHIR IGs It is recommended that the IG development team used to develop the FHIR IG also guide the IG through the HL7 standards processes To better navigate HL7 processes the IG team should Have an advisor who has thorough knowledge of HL7 processes and standardization schedule Coordinate with HL7 and HL7 work groups associated with the specialty domain Build HL7 standardization throughout the development processes started with the use case development Allow plenty of time to go through the process Build a relationship and coordinate with HL7 Work Groups Work Groups may not have deep expertise in individual health specialties However they will know HL7 standards and processes and may be aware of IG work past current and planned that is similar Support from the HL7 Work Group will help smooth the IG standardization process It is critical that any proposed new FHIR artifacts such as FHIR profiles or extensions be discussed with HL7 and the appropriate HL7 Work Group They can help harmonize FHIR profiles and extensions to better address both the specialty s and the wider community s needs and interest Utilize existing HL7 community to coordinate and harmonize work especially HL7 FHIR Accelerators who will be knowledgeable and connected closely with HL7 people and processes and ongoing work within their domain As stated previously HL7 IG standardization and approval mark the gateway towards broader acceptance of the developing IG and the beginning of implementation and testing processes Again all the development steps use case planning interoperability standards development and implementation and testing are cyclic and rely on feedback from other steps to produce valuable software for the specialty community Further details for standards experts can be found in the HL7 Standardization Deep Dive resource section of this site Prev Use Cases Planning Next Implementation Testing"},{"id":8,"doc":"Playbook","title":"Design Principles","url":"playbook/design_principles.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Design Principles Below are principles that have guided the CodeX HL7 FHIR Accelerator Community and in the design planning development testing adoption and value of FHIR based data standards including mCODE These principles guide and are elaborated upon in the Playbook Tracks and Case Studies If additional specialties follow these principles the resulting standards are more likely to be developed efficiently to be compatible across specialties as part of each patient s life time health to be adopted in practice and to provide value for patients and all stakeholders A dedicated and diverse community is essential to the design and execution of a health data standards project Each use case needs committed representation from all stakeholders needed to drive the use case e g patients providers health systems Gov t agencies vendors payers and others Compelling use cases are the foundation upon which solutions are designed and driven Define each use case as a project that addresses a single important narrowly focused problem Build a use case plan that is end to end including the scope resources data requirements and a pragmatic strategy for how standards will be adopted and provide value in the real world Prioritize use cases that address salient challenges However start with simpler not simple use cases that have commitment from all the community members needed to succeed Prioritize use cases that improve collection and sharing of quality core standardized data related to patient care and outcomes should be the top priority Clinical information requirements are a first priority for each use case Build consensus within a diverse team of clinical experts on the minimal data requirements needed to address core use case requirements Define clinical requirements as discrete observations and actions e g patient birth date 11 04 1989 vs patient is 34 years old If previous work in the space exists seek to work with the other initiatives and adapt their work rather than re do How clinical requirements are represented in FHIR Implementation Guides IG influence their useability and their interoperability across specialties Develop first a single core IG that represents the minimal clinical requirements for small set of use cases concepts common within the specialty This core IG can be improved upon as use cases are executed and supplemented within related IGs when data requirements are important for just a small subset of the community Leverage government backed interoperability standards whenever possible e g United States Core Data for Interoperability USCDI Fast Healthcare Interoperability Resources FHIR US Core FHIR Implementation Guide for core patient data and others Leverage the available tools see the Resources page for modeling and IG development to produce higher quality FHIR IGs that are more coherent across specialties use cases and projects Leverage global code systems and terminology standards e g LOINC SNOMED CT CPT and other systems Standardize work through an open royalty free health standards development organization preferably Health Level Seven HL7 Build use cases within a vision of a coherent lifetime Standard Health Record for every patient Enable standardized data to become the basis for every patient s health record and standard of care Empower patients to be engaged with and have control of their health data Collect patient data once generally around the encounter and reuse it for future patient encounters and multiple use cases Enable consistent representation of health data concepts that could be used across specialties subspecialties and use cases Prev Before Starting Next Community Building"},{"id":9,"doc":null,"title":"Adoption \u0026 Value","url":"playbook/adoption.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Adoption Value Case Studies Resources About Back to top Track 5 Adoption Value Adoption in the real world is best driven by understanding the market forces that will drive new standards based solutions including user demand government mandates and the promise of improved care and research Value in the real world depends on the level of adoption and the quality of the underlying new standards based processes and systems being adopted Once work has progressed to the adoption planning phase the use case team should also have a clear view even before the first system or process has been deployed with new standards whether the prospects for community adoption and value are strong or not A variety of resources are useful in driving adoption and measuring value Use case champions and the organizations they represent e g medical societies providers vendors regulators and others are key as they can influence communities of potential adopters and understand and leverage market forces To support champions publication and promotion peer reviewed papers popular press articles conference presentations of results is useful in establishing use case value for healthcare and research Adoption in the Real World As noted above all the previous tracks discussed will help establish the level and drivers of demand for the standards based use case It is important to leverage the champions and community to communicate the value demonstrated during pilots Pilot successes contribute to the following factors that spur adoption Real world pilots of the new standards based solutions demonstrate real world value e g increased benefits and speed decreased costs and burden Customers e g patients providers payers researchers and others increasingly demand standards based solutions Government regulations and rules changes increasingly require standards based solutions Vendors will seek competitive advantage through implementing standards While it is important to maximize these adoption drivers a subset of these drivers can be sufficient to spur the adoption of new standards and interoperable solutions A simplified illustration of the above market forces and others is shown below Push forces result from stakeholders requiring the use of new standards Pull forces result from stakeholders requesting products that benefit from standards based solutions A specialty specific version of this graphic could be created for specialty Communities See also the stakeholder specific Value Propositions on the community Building page Diagram showing forces that can demand pull and require push data standards The better these forces can be aligned the more effectively a project can move and have impact Value in the Real World When driving adoption of new standards and new standards based workflows it is important to measure the costs and benefits throughout the new systems Such assessments will help improve the standards workflow design and user interfaces Further when results are positive these assessments will help accelerate demand adoption and value in an enlarging community of users See the Delivering Value and Growth and Impact sections of the mCODE Standard and CodeX Community Case Study for examples of the measurement and communication of value for the mCODE standard and associated use cases NOTE Add more content here Prev Implementation Testing Next Case Studies"},{"id":10,"doc":"Playbook","title":"Community Building","url":"playbook/community.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Champions Governance Growth Value Propositions Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Track 1 Community Building Gathering the right organizations and people is the most challenging foundational and necessary experience for success Most people reviewing this site understand that enabling true health data interoperability is as much a social challenge as it is a medical or technical challenge It takes people who share a vision and mission who can align diverse views of how to get there and who will invest the resources needed to change the status quo and gain sustainable growth and momentum Actions that CodeX has found indispensable include a engaging champions b establishing governance c growing the community and d communicating value propositions that enable growth These actions are expanded upon below Champions An essential first step when starting a new specialty initiative or starting a new use case within that initiative is to identify champions In CodeX successful champions are organizations and individuals that Commit to leading the initiative and or use case Know the challenges and opportunities leading to potential use cases organizations people and related initiatives within the larger specialty community Command the attention of a larger community and can influence future users and stakeholders to engage Motivate implementation of new standards into vendor solutions Motivate the changes in health processes needed to use and benefit from of the standards based systems Attract the resources needed to succeed Drive one or more key tracks of the initiative and or use case Community Building Use Case Planning Standards Development Implementation Testing Adoption Value Champions and all who actively participate will most likely understand the challenges for which standards based data interoperability provide substantial benefits These participants will develop a shared vision for a future where patient data can be collected once and then used with no or little manipulation for many use cases around patient care research and other applications It s clear that champions have significant responsibilities But they also realize future benefits in terms of prioritizing use cases defining direction achieving objectives and ultimately improving health care and research within their organizations and across the landscape Large medical professional societies and government organizations have been the most frequent CodeX use case champions but other stakeholders have also been effective champions The founding champions for the overall CodeX initiative which started by addressing challenges in oncology were American Society of Clinical Oncology ASCO with reach to all oncologists and centers and The MITRE Corporation with deep expertise in convening FHIR standards and systems engineering Governance A governance framework is important for any initiative involving many organizations often with divergent interests and views An agreed generally by member organizations and documented governance framework ensures that the community hears and understands participants views and interests Governance delineates how and by whom decisions are taken Example decisions include updates to the governance structure itself Membership structure and fees resolving conflicts administrative support starting new use case work and providing funding and resources to projects in special cases when the community can t provide funding and resources The CodeX Accelerator provides the governance for use cases around cancer and the mCODE standard cardiovascular disease and genomics so far Other governance schemes are possible but would require more effort to start and to coordinate effectively across specialties The graphic below captures the CodeX governance structure as of 2024 The tiered structure offers participation at different levels of responsibility and time commitment Details of the current CodeX governance scheme can be found on their website Block diagram showing structure of CodeX governance including Steering Committee Operating Committee Use Case Projects and Community of Practice Regarding CodeX Governance The elected steering committee makes major decisions including governance structure use cases funding decisions and moving projects into the execution stage The vast majority of all the community s volunteer resources are invested in the use case projects The community of practice near the bottom of the graphic is open to the public and has been an effective feeder of new organizations and talents into CodeX membership and use cases One key factor in CodeX s oncology work is the mCODE Executive Committee and its Technical Review Group External Expert Groups circle on right These groups provide clinical subject matter expertise across oncology fields and ensure the mCODE FHIR Implementation Guide is based on the most credible and recent clinical knowledge A strategy for sustaining work is important Communities cannot achieve success overnight and cannot continue to achieve success without sustained resourcing In CodeX participants provide the range of skills and support necessary to drive each use case forward Funding for overarching program management near the top of the graphic above comes largely from membership fees plus some volunteer effort Based on 2024 CodeX Membership view current membership list and Membership fee structure view current fee structure Membership fees provided about 800K USD for 2024 Community Growth To advance use cases the community needs a variety of organizations and skillsets to establish an overarching vision of adoption and real world value Thus the community must be grown such that there are participants with direct experience related to each of the envisioned roles in the specialty initiative and its use cases For example in the CodeX Radiation Therapy Case Study the team included participants from radiation therapy societies health systems payers and vendors Skillsets included clinical practice radiation oncologists radiation physicists software engineers informaticists FHIR experts HL7 standards process experts and more Getting the right set of people together at the right times in the process can be challenging It is ideal to have redundancy among these roles to bring in a diversity of experience and to provide forward momentum as participants cycle on and off the project Champion leadership and collaboration as a committed and focused team is critical The good news is that a promising use case has the potential to attract new participants These participants appreciate the potential value of the work are willing to invest resources to realize that value and want to be at the table where decisions are made and work is executed Value Propositions To grow the community required for a standards initiative to succeed it s important to understand and communicate the value propositions for different stakeholder groups Further it s helpful to think about stakeholder value in two directions a How can the standards initiative provide value to each stakeholder group and b How can each stakeholder group provide value to the standards initiative Below are value statements looking in both directions for six stakeholder groups Providers Health Systems Associated Specialty Societies How can the standards initiative provide value to Providers Health Systems and Associated Specialty Societies The initiative s Use Cases and standards could enable better care at lower cost more accurate and complete data that can be collected and shared more readily thus improving diagnoses treatment consultations automation level of effort and expenses Shared decision making between patients and providers could be realized Valuable secondary uses of the standards based data could be realized e g quality measure reporting payer communications prior authorization procedures research and many other opportunities How can Providers Health Systems and Associated Specialty Societies provide value to the standards initiative By representing informing and convincing a broad group of clinical and administrative constituents that this initiative should be supported By committing experts who can provide deep clinical knowledge By demanding standards based solutions from their vendors By finding and providing funding Patients Associated Advocate Societies How can the standards initiative provide value to Patients and Associated Advocate Societies The initiative s Use Cases and standards could enable better patient care at lower cost more accurate and complete data that can be collected and shared more readily thus improving diagnoses treatment consultations automation level of effort and expenses A common motto of CodeX work is that every patient s journey improves all future care in addition to providing excellent care to the patient at hand Shared decision making between patients and providers could be realized How can Patients and Associated Advocate Societies provide value to the standards initiative By representing informing and convincing a broad group of patients and caregivers By providing the patient s perspective to ensure a patient centered approach is at the center of Use Cases and standards work Patients will increasingly demand the ability to aggregate share and control their health data and thus motivate standards adoption Regulators government agencies may include functions that fit into other stakeholder groups as well How can the standards initiative provide value to Regulators Standards that are developed can align with and accelerate government rules and regulations How can Regulators provide value to the standards initiative By committing experts who can provide deep regulatory knowledge By providing funding Vendors EHR and other health IT companies How can the standards initiative provide value to Vendors Vendors can help align customer interests and thus reduce their level of effort on custom implementations They can provide input to ensure standards are implementable in their systems and are consistent across specialties cost effective development and maintenance Vendors who participate actively have a first mover advantage that can drive their products to market ahead of competitors How can Vendors provide value to the standards initiative By implementing and delivering when their customers ask for products based on standards By committing experts who can provide deep technical implementation knowledge By looking across customers and across specialties and suggesting ways to develop standards to optimize implementation use and maintenance within systems By providing funding Payers How can the standards initiative provide value to Payers Easier access to necessary clinical data standardized across customers needed to make decisions Automation of processes e g prior authorization claims processing Higher quality care supported by standard data will be informed by payers who are at the forefront of pay for value approaches to care How can Payers provide value to the standards initiative Can demand the use of standards by associated health systems and vendors By committing experts who can provide deep knowledge of payer requirements By demanding standards based solutions from their vendors By providing funding Researchers How can the standards initiative provide value to Researchers More patient point of care data can be gathered and aggregated faster and with less expense for research use e g less data curation and mapping Substantially increased speed ease of execution and cost effectiveness through standardized data sharing across studies and institutions Potential funding How can Researchers provide value to the standards initiative By committing experts who can provide deep knowledge of research requirements By demanding standards based solutions from their vendors By providing funding Prev Design Principles Next Use Cases Planning"},{"id":11,"doc":"Playbook","title":"Playbook Introduction","url":"playbook/index.html","content":"Playbook Menu Intro Tracks Why Who How Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Introduction Playbook Tracks The MITRE Health Data Interoperability Playbook aims to help health communities create FHIR based data standards that provide substantial improvements to patient care and research within individual specialties and across all specialties Why Why is the Playbook being created and shared now Three primary reasons First data interoperability remains a serious impediment to better and more affordable health care Multiple recent studies demonstrate interoperability driven impediments including Average treatment delays of a month which can result from prior authorizations data sharing breakdowns It takes an average of 17 years for research to reach clinical practice It can take 3 years for public health data to be aggregated and available for broader use Nearly 1 trillion per year for healthcare administrative costs which could be reduced with more efficient standardized data exchange Second formerly disparate elements are converging to make this a prime time for other specialties to create FHIR based data standards to address challenges Patients providers payers researchers and others are realizing the need for standards that provide semantic interoperability Recent government rules and regulations are driving standards based approaches upon which specialty communities can build Vendors are working to meet customer demands and government direction delivering products increasingly based on standards CodeX and mCODE have leveraged these underpinnings from the start The third reason to share this Playbook is that MITRE has had a primary role in creating and building a Community within the CodeX HL7 FHIR Accelerator building applications using the mCODE cancer data standard and the accelerating adoption of CodeX s mCODE based use cases to address interoperability challenges in the oncology space This success has led leaders in the cardiovascular and genomics domains to start work in CodeX It has also led many additional medical specialties to ask MITRE s experts questions such as What are CodeX and mCODE What impact are CodeX and mCODE making to enable data interoperability and solve real health challenges What was your approach and its rationale How could my specialty replicate the impacts realized by CodeX and mCODE and perhaps move even faster These questions are just some of the motivations that led MITRE to consolidate and share its experience in this Playbook There are approaches in addition to MITRE s that may be useful to review Whatever approach the community follows the outcome must aim to be consistent with other specialties and in the best interest of all patients who typically need the services of multiple specialties during their lifetime MITRE s Playbook Tracks and Design Principles aim to ensure the necessary level of consistency and quality and have a track record of success Who Who is the intended audience for the Playbook The Playbook will be valuable to a range of organizations and people interested in creating and leveraging specialty health data standards to address real world challenges The Playbook should be particularly helpful for specialty leaders exploring how to replicate the CodeX model for oncology within their own specialty Specialty leaders may be motivated to work with CodeX and other specialties to speed work and increase coherency Parts of the Playbook will be useful to particular stakeholders e g patient organizations health systems specialty societies government agencies payers vendors etc and roles e g decision makers funders project managers community organizers clinical experts informaticists standards developers system engineers communications personnel etc involved in just a subset of the spectrum of all future work The Key Playbook Sections by Role provided here aims to help guide people with leadership clinical or technical responsibilities to quickly find the most relevant information for them To get the most out of the Playbook it would be helpful for leaders to have at least a high level knowledge of standards that are foundational in the Playbook United States Core Data for Interoperability USCDI Fast Healthcare Interoperability Resources FHIR US Core FHIR Implementation Guide USCDI specialty supplements to USCDI Health Information Coding Systems Health Information Terminology Standards Standards implementers should of course have a much deeper understanding of these foundations How How is this Playbook organized The Playbook is organized around the approach used by the CodeX community to drive development and value of standard FHIR Implementation Guides This approach has five tracks that overlap in time interact substantially and have been improving with experience The first graphic below is a simplified representation of the five tracks The second graphic shows a notional timeline of the overlapping and interacting tracks for a hypothetical use case In CodeX the time from the start of the work to initial adoption of a use case solution has been on the order of 3 5 years Flow diagram of the five Playbook work tracks Waterfall diagram of a notional timeline for implementing the five Playbook tracks showing that they are related and overlapping Here is a brief description of each Playbook track with a link to the more detailed page for each Community Building Community starts with leadership from committed champions who have broad reach a grasp of key challenges and potential use cases and the ability to grow the community with skilled and active participants The community must establish a fair and sustainable governance framework to enable the community to grow coordinate and work toward its goals Use Cases Planning The community must prioritize and define specific projects each including the key challenge to be addressed new work and data flows to be realized and clinical information needed Use case work must be organized and scheduled all the way through to adoption and measuring value Resources organizations champions people skills needed to succeed must be secured Specific use cases attract additional subsets of each specialty to the community Standards Development Standards development starts with compiling clinical experts minimal set of core information requirements for each use case Clinical requirements are incorporated into HL7 Fast Healthcare Interoperability Resources FHIR Implementation Guides IGs based on a set of Design Principles and standardized updated and maintained the within the Health Level Seven HL7 standards organization Implementation Testing Implementers must integrate FHIR IG s into systems and workflows These standardized systems and workflows undergo increasingly ambitious tests leading to pilots within the types of organizations that will ultimately benefit from the work Feedback from testing is used to update Planning and Standards work Testing serves to demonstrate the potential value of the work and often attracts additional participants to the community Adoption Value To have value standardized systems must be used widely in the real world Getting to this point starts by understanding during project Planning which factors will move the market Factors include user demand government mandates and the promise of improved care and research demonstrated during testing It s critical to measure such improvements in the real world to see where updates could make solutions even better quality cost time and to motivate new users to adopt Though not shown in the graphic real world use will lead to additional feedback for any or all the other tracks The above five tracks are explored in greater depth by following the links in the above list and via the Playbook Menu found on all pages Questions that a new specialty should ask themselves before embarking on the above tracks are covered on the Before Starting page A downloadable Playbook Checklist will be useful as a new specialty embarks on the work across Playbook tracks Also provided in the Playbook are Design Principles that help drive efficient and consistent standards development work These Principles when used by different specialty initiatives will also help ensure alignment between initiatives within and across specialties Case Studies show how real projects have leveraged the tracks including the history of activities outcomes and lessons that may be useful for new specialties Playbook sections recommended for people in particular roles lower level details on particular topics and links and tools related to the tracks and Case Studies can be found on the Resources page Next Before Starting"},{"id":12,"doc":"Playbook","title":"Before Starting","url":"playbook/getting_started.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Before Starting Your Project Four Questions to mostly Answer in Advance of Launching a New Specialty Standards Initiative When people from outside the oncology space learn about how the mCODE Standard and CodeX Community are revolutionizing interoperability for cancer data see the mCODE and CodeX Case Study they often ask How could we replicate this experience to improve interoperability within our specialty Other pages in this Playbook share experience aimed to help a new specialty standards initiatives deliver real value However MITRE has found that the following four questions should be asked and largely answered before treading too far into a new specialty standards initiative Each question references the Key Playbook Tracks that can be consulted for more details on how questions could be addressed The following graphic maps the four questions to be answered before starting the initiative boxes A D in green below to a notional use case timeline for the five tracks to execute once the initiative is started circles 1 5 below and explained in the Introduction Note that all four questions map to the early period of the Community Building track and three questions map to the early period of the use cases planning track Diagram showing four key questions to ask before starting work mapped to a notional timeline for the Playbook work tracks Next the four questions to answer before launching a new specialty standards initiative How can specialty community champions drive success Leadership for the specialty initiative as a whole and for each specialty use case is key to the steps below and elsewhere in the Playbook Understand specialty needs engage large constituencies collaborate with related initiatives mobilize resources and drive success Engage medical professional societies and government organizations Lead a project that grows in complexity and participation and help the community source skills and funding Establish a governance framework that facilitates communications consensus building decision making project management effort and resource distribution Key Playbook Track Community Building Which use cases will the specialty work on first Prioritize work into manageable segments to minimize initial use case complexity Each use case includes a scoped health IT or process challenge that a defines validates and or motivates improvements to underlying workflows data requirements and data standards b attracts more needed participants and skillsets into the community and c motivates demand adoption and value Ideally software collects and shares data using the same standard which can expand with and support multiple use cases CodeX Use Cases typically start with easier not easy problems and solutions around which stakeholders can more quickly align and demonstrate value for the community New specialties may find parallels in the CodeX Oncology Use Cases providing a jump start for the specialty community use case development Key Playbook Tracks Community Building Use Cases Planning What s the strategy for adoption of standards based solutions Each use case needs a pragmatic vision for how the specialty community will adopt resulting solutions into their software ecosystems and improve care and or reduce burden Community engagement of future users has proven invaluable in Codex Data users whether customers or government agencies can encourage vendors to implement community proven software solutions Key Playbook Tracks Community Building Use Cases Planning Adoption Value Are the necessary resources available to start the first use case s and deliver success Launching use cases and demonstrating solutions require specific types of organizations champions skillsets and often financing at the right times Resource needs are often less clear at the start but become increasingly clear as work is planned and accelerated Use case scope and timelines can be scaled to available resources and still be successful In CodeX rapid promising use case results generally from the early phases of a use case helped attract and justify the involvement of new organizations gather the needed skillsets and secure funding Key Playbook Tracks Community Building Use Cases Planning Prev Introduction Next Design Principles"},{"id":13,"doc":"Playbook","title":"Use Cases \u0026 Planning","url":"playbook/use_cases_planning.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning What is a Use Case Guidelines Use Case Discovery Use Case Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Track 2 Use Cases Planning Scoped use cases are critical to success A use case plan serves to document agreed scope steps schedules and resources needed to deliver solutions successfully What is a use case A use case in this context is a project that requires electronic collection storage sharing and or use of standardized data within a new well scoped workflow relative to current practice Implementation and adoption of the use case should enable measurable improvements in the health ecosystem including more effective faster and or less expensive patient care and research A specific use case provides the framework for all that comes next Thus a well scoped and compelling use case is critical for success A use case attracts the subset of the larger community who care deeply about the objectives and can drive work A use case allows Standards Development work to focus on the data elements needed to execute new systems and workflows A prototypical use case is the Radiation Therapy Treatment for Cancer Use Case This use case has worked successfully to replace inefficient sharing of documents PDF from a radiation therapy services to oncologists leveraging an mCODE based FHIR exchange of structure radiation treatment summary data This work is already deployed in real world systems improving information quality and reducing clinical burden See the Radiation Therapy Treatment Data Case Study A workflow diagram for the CodeX Radiation Therapy Treatment Data for Cancer Use Case CodeX Use Case Development Guidelines CodeX created Use Case Development Guidelines as a framework and decision process for successful use case work via three Stages Discovery Planning and Execution development implementation adoption and impact Diagram of CodeX use case development progression from Discovery to Planning to Execution stages Below are key learnings around the CodeX use case discovery and planning stages The CodeX execution experience will be referenced in the Implementation Testing and Adoption Value sections of this website Use Case Discovery Identifying and Prioritizing Potential Specialty Projects Use case discovery in CodeX generally starts with use case champions who engage and gain commitment from potential participants Together they build a list of possible use cases and work to agree on their first or next use case project based in part on the factors below New specialties should look at CodeX oncology use cases They may find that there is a parallel use case in their specialty e g for clinical trials registry reporting quality measurement prior authorization and others that cut across specialties for which previous oncology work could provide a jump start in the new specialty Modeling new specialty work after existing work could also serve to make the new effort compatible with prior efforts thus serving implementers health systems and patients well For the CodeX Program Management Office with the opportunity for input from the Steering and Operating Committees to assess the readiness of a use case to go into the CodeX Discovery Stage the following information is requested High level version of concept stakeholders do not need to be in complete agreement and alignment List of organizations and individuals committed to lead the discovery discussions and alignment List of other specific organizations across stakeholder groups that could be candidates for working the concept through discovery planning and execution By the end of the discovery stage and before moving into the planning stage a CodeX use case project has the following attributes Based on a thorough landscape analysis the proposed approach is unique and or advances the field The potential to substantially improve patient care and research within and or across specialties Shares the vision of collecting patient data once mainly to support patient care and exchanging for multiple uses Believed to be viable some risk is of course natural and acceptable Leverages clinically based FHIR Implementation Guides for automated collection and exchange of a minimal set of clinical data Leverages resources and open FHIR based API based data exchange Leverages Gov t supported frameworks including USCDI the US Core FHIR IG and others Leverages mCODE and or explores updates to mCODE and other foundational IGs May develop supplemental data elements IGs more specific to a use case Driven by the community with leadership from champions representatives from all necessary stakeholders and committed resources Expedites use case project work based on agile project plans with short phases quick results Will during the Execution stage pilot workflows and systems in real world settings that demonstrate the art of the possible and can be adopted and scaled Other considerations that MITRE has found useful to determining readiness to proceed A new specialty should consider starting with one or two less ambitious use cases based on simpler new workflows that share a minimal set of standardized data This raises the probability of success at speed and can help a new community to become a functional team Ask the right questions What s driving the need for the use case Is the need related to clinical workflow improvements research improvements new regulatory requirements cost or burden reduction and or other factors Who are the target actors e g patients physicians nurses researchers payors regulators and others Develop use case scenarios Write scenarios such that the widest group of potential participants can review and understand Create example personas for roles in the proposed workflow Cite clinical sources and other prior work Use Case Planning From Starting Work to Providing Value in the Ecosystem Once the community has prioritized a use case the next step is to develop a plan Here are considerations that CodeX documents in their Use Case Development Guidelines Problem Why are current solutions inadequate Solution What new systems and workflows are planned Identify which roles actors and standardized data are needed for each component of the solution Impact Where will the health ecosystem be substantially improved with the envisioned solution Champions Which organizations and people are committed to lead Which others are needed and where does engaging them stand Resources Which organizations and people are committed to participate actively Which others are needed and where does engaging them stand Are there additional personnel facilities and or financial resources required to succeed that are not committed yet Think about the types of resources needed over the entire project through planning development implementation testing adoption and realizing value in the real world Describe the options and plans for attaining these It can be difficult to estimate resource needs accurately especially in the early phases of a use case Note that use case scope and schedule can be adjusted to the availability of resources and still result in a successful project Provided on this site is a Role and Resource Planning speadsheet template download which should help define resource requirements and fulfillment Outside Activities Are there other consortia or other organizations outside of this use case with which the team may want to collaborate with Identify outside work that could be competitive with the current use case Schedule of Work Break the plan into phases Each phase might be 3 9 months Phase themes stories workflows objectives and development FHIR IGs software will vary One pattern that is common in CodeX is a first phase starting with exchanging synthetic data for a minimal set of data elements progressing to a phase with de identified data then a phase with real patient data Later phases include strategies for driving adoption and for measuring value in the real world Participation realism and results all become more ambitious with each new phase Specify measures of success for each phase out to at least a year or two Note risks and other issues within the plan that require additional alignment within the use case team Communication There is value to leveraging channels of communication web email lists that are public to gain attention engage outsiders and publicize progress and maintaining other channels that are private within the governing organization like CodeX or the use case team Prev Building Community Next Standards Development"},{"id":14,"doc":"Case Studies","title":"Radiation Therapy Treatment Data","url":"casestudies/radiation_therapy.html","content":"On This Page Community Building Use Cases Planning Standards Development Implementation Testing Adoption Value Back to top Case Study CodeX Radiation Therapy Treatment Data Use Case The Radiation Therapy Treatment Data RTTD Use Case is an excellent example of how a successful CodeX oncology use cases was started how it was driven what impacts it is having as of 2024 and lessons learned This should be especially valuable to a new medical specialty looking to conceive plan and execute a new project within a broader special standards initiative Community Building Key Playbook Track Community Building In March 2020 the American Society for Radiation Oncology ASTRO joined CodeX as a founding member with a proposal to standardize radiation therapy treatment summaries They suggested leveraging work published by ASTRO and others in the ldquo Minimum Data Elements for Radiation Oncology An American Society for Radiation Oncology Consensus Paper rdquo ASTRO noted that the radiation therapy community had been interested in standardizing the complex treatment data that is gathered before during and after a course of radiation therapy treatment but did not have the infrastructure or FHIR expertise to sufficiently act on this idea ASTRO joined CodeX with the vision of connecting with other industry partners leveraging the CodeX FHIR Accelerator s platform benefiting from expertise in FHIR modeling and planning the use case Nearly one year after ASTRO joined CodeX the American Association of Physicists in Medicine AAPM joined as a founding member to support this effort AAPM provided professional society expertise along with work developed by the AAPM Big Data Subcommittee i e Operational Ontology for Oncology O3 At this point the discovery phase of the CodeX Radiation Therapy Treatment Data RTTD Use Case began with the leadership and in kind support of ASTRO and AAPM which consisted of leveraging existing standards focused work and collaborating with related radiation therapy professional societies The graphic below represents the multi professional society engagement and approach that the CodeX RTTD team took to ensure existing work and expertise from leaders in the field were adopted repurposed and modified to fit within the scope of our use case The lack of data standardization within the radiation oncology community is an international issue that the below group of societies had started working toward resolving and which the CodeX RTTD team modeled in FHIR Diagram showing engagement between AAPM HL7 mCODE CodeX and other professional societies Use Cases Planning Key Playbook Track Use Cases Planning The development history for the Radiation Treatment Therapy Data Use Case is summarized the RTTD FHIR IG https hl7 org fhir us codex radiation therapy 2024May history html A summary of the use case phased plan is shown in the following graphic RTTD Use Case work ramped up to realistic pilots over a five year period Now let s dive a little deeper into the RTTD Use Case story ASTRO and AAPM with the assistance of The MITRE Corporation planned and kicked off the CodeX Radiation Therapy Treatment Data RTTD Use Case in early 2021 The team s initial objective was to identify define and model data components in an ldquo end of treatment rdquo radiation therapy RT care summary i e a summary report that could be sent to the larger oncology team once the RT course has been completed As previously mentioned the data components were informed by the Minimum Data Elements for Radiation Oncology An American Society for Radiation Oncology Consensus Paper and refined by consensus after stakeholder discussion Once the ldquo end of treatment rdquo summary modeling was completed in June 2021 the RTTD stakeholders agreed that defining components of a RT prescription and an in progress treatment summary would also be of value to the healthcare community In progress treatment summaries convey information about a patient in the midst of receiving treatment The group again leveraged the Minimum Data Elements for Radiation Oncology Consensus Paper to identify potential data requirements refined the definition of each data element via collaboration and stakeholder expertise and modeled the FHIR specifications that would ultimately be published in the CodeX RT Implementation Guide IG Standards Development Key Playbook Track Standards Development In January 2021 the RTTD Use Case approached the Integrating the Healthcare Enterprise Radiation Oncology IHE RO Exchange of Radiotherapy Summaries XRTS Work Group about aligning the data model and FHIR structures created by the RTTD team with the technical architecture and transactions being defined in the XRTS technical specification document The XRTS Work Group includes leading electronic health record EHR and radiation oncology information system ROIS vendors that consist of roughly 80 of the U S ROIS market Varian Elekta RaySearch and Epic The CodeX RTTD and XRTS teams aligned visions and began working together to develop the CodeX RT Implementation Guide and the architecture and transactions within the XRTS Profile and technical specification As a result of this collaboration radiotherapy profiles were added to mCODE STU2 i e the Radiotherapy Course Summary and Radiotherapy Volume profiles along with new value sets and extensions required to express a radiotherapy treatment summary Radiotherapy specifications beyond what was considered minimal which is a tenet of mCODE were published in the CodeX RT IG STU 1 along with details that support 1 a radiation therapy prescription and 2 in progress treatment summaries The image below depicts the profiles that fall within each portion of the radiotherapy clinical workflow Diagram showing various FHIR profiles associated with phases of radiotherapy clinical workflow Implementation Testing Key Playbook Track Implementation Testing The radiotherapy profiles and data elements were tested in December 2021 and May 2022 at IHE RO XRTS Workshops by radiation oncology information technology vendors Varian Elekta and RaySearch along with Epic an electronic health record system vendor The CodeX RTTD and IHE RO XRTS teams will continue to test the CodeX RT IG at future IHE RO XRTS Connectathons Additionally all insight and relevant feedback received from IHE RO vendor testing at Workshops and formal Connectathons will be reviewed and assessed by the CodeX RTTD Use Case team for necessary updates and changes to the RT IG Clinical modifications to the RT IG s FHIR model will also be shared with the IHE RO technical team to update the IHE RO XRTS technical specification and retested at subsequent vendor Connectathons This continuous feedback loop between the CodeX RTTD and IHE RO XRTS team is represented in the graphic below which is a critical component of this team s success Diagram showing feedback loop between CodeX and IHE RO Adoption and Value Key Playbook Track Adoption Value As of early 2024 the RTTD Use Case has accrued significant accomplishments including Adoption of mCODE RT profiles and the RT Implementation Guide in US radiation oncology information system vendors that support 80 of treatment sites Publishing the first version of the CodeX RT Implementation Guide A second version to be published in Fall 2024 Adding 275 SNOMED CT codes related to RT to the Global Patient Set which are now publicly available for international use Incorporating mCODE radiotherapy profiles in the production system of a recent version of RayCare i e RayCare 6A Realizing the official product release of Varian s ARIA FHIR API in December 2023 which includes FHIR RT profiles Targeting VA and Varian pilot to be deployed at Madison VA site in summer 2024 The pilot will test the exchange of RT FHIR profile information The CodeX RTTD and IHE RO XRTS teams are continuing to work in harmony to leverage areas of expertise and explore opportunities for advancement of this work The CodeX RTTD team is always looking for new CodeX members vendor organizations to test the Radiation Therapy Implementation Guide and pilot sites to test and assess the clinical applicability of the standard If you d like to get involved email the CodeX team"},{"id":15,"doc":"Case Studies","title":"The PACIO Project","url":"casestudies/pacio.html","content":"On This Page PACIO How it Started First Use Case Design Principles Starting the Community Building the Community Delivering Value Growth and Impact Resources Back to top Case Study The PACIO Project How it Started The PACIO Project started with a simple question How do we get post acute care PAC health data to follow the patient through transitions of care The solution was to build a community to develop and drive adoption of Fast Healthcare Interoperability Resources FHIR in post acute care data exchange standards to facilitate transitions of care and care coordination across the healthcare continuum Background Forty five percent of Medicare patients leaving acute care end up in some form of post acute care Diagram of post hospitalization acute care service utilization by Medicare patients in 2014 The post acute care population includes some of the most complex and vulnerable patients many having multiple chronic conditions managed by different practitioners across time and settings There is often poor communication between clinical care teams leading to inadequate information during transitions and poor continuity of care that can lengthen stays increase costs and result in poorer outcomes There is a heavy reliance on patient and family caregiver recall of information which may not be reliable or possible which raises provider and patient burden Providers may need to track down or recreate missing information through redundant processes Meanwhile patients may not receive needed transition critical care right away while missing data is assembled Schematic diagram illustrating the complexity of care coordination between patient caregivers and CMS Environmental Scan In fall of 2018 the Centers for Medicare and Medicaid Services CMS Division of Chronic and Post acute Care DCPAC engaged MITRE to facilitate a Technical Advisory Group roundtable discussion Convening 75 post acute care clinicians vendors and subject matter experts with a series of one on one discussions with PAC providers health IT vendors and provider organizations the MITRE team and this community to gain insight and urgency into the state of the PAC interoperability landscape These activities identified common themes around challenges to health data interoperability in PAC including lack of incentives lack of standards and not understanding the value of interoperability The graphs below display results from this foundational environmental scan Based on these results CMS in partnership with the HHS Office of the National Coordinator for Health It ONC and MITRE established the PACIO Project Bar chart indicating the number of citations for different challenges to PAC interoperability Bar chart of common PAC interoperability use cases Armed with the environmental scan information the PACIO Project was created with the following mission goals and priorities Mission The PACIO Project is a collaborative effort to advance interoperable health data exchange between post acute care PAC and other providers patients and key stakeholders across healthcare and to promote health data exchange in collaboration with policy makers standards organizations and industry through a consensus based approach Goals Promote interoperability Develop open standard non proprietary FHIR APIs Promote adoption of FHIR APIs Promote reusability Promote innovation Support migration path from older systems to interoperable systems Help establish trust framework for nationwide information exchange Priorities Reach consensus on Governance purpose and goals Decide on a tightly scoped use case s to produce impact Reuse adapt develop FHIR implementation guides for data models Although the PACIO Project is not an HL7 FHIR Accelerator it operates using similar transparent collaboration processes such as developing multiple use cases defining data models and authoring FHIR Implementation Guides IGs One primary difference is the PACIO Project does not require financial contributions from its participants PACIO FHIR IGs are regularly tested at HL7 and CMS Connectathons and test events When testing indicates that the IG is ready materials are prepared for the HL7 Ballot which seeks validation and acceptance by the broader HL7 Community Ultimately the PACIO Project advocates for vendor adoption A conceptual timeline of FHIR IG development as applicable to PACIO First Use Case In selecting the PACIO Project s first use case the community first looked at available prior work Participants did not want to reinvent the wheel and wanted instead to leverage as much existing development as possible The process began by examining the existing HL7 Clinical Document Architecture CDA specifications From this list of specifications an experienced physician within the PACIO Community prioritized it ranking the importance of the data from 1 most important to 3 least important for a variety of different actors physician nurse practitioner registered nurse therapist administrator and the patient family The broader PACIO Community reviewed the rankings and judged whether they accurately captured importance and priorities Participants identified several high priority sections highlighted in yellow in the table below and medium priority sections blue as high value for potential use cases Image of a spreadsheet used to identify and prioritize elements and their importance for PACIO Next the PACIO Community determined which of the high and medium priority use cases candidates were already covered in FHIR and from that identified three potential final candidates for collaborative work Functional Status Mental or Cognitive Status and Advance Directives High Priority Use Cases Image of a spreadsheet used to identify data elements in high priority use cases Medium Priority Use Cases Image of a spreadsheet used to identify data elements in medium priority use cases Many participants collaborating in this first use case were new to the data standards development process The group determined that a simpler use case was preferable in order to produce a useable standard more quickly Further discussions with HL7 work groups indicated that Advance Directives while an important use case would be very complex and not ideal as a starting use case Some members of the Community favored beginning with Functional Status and others Mental Cognitive Status Since the assessment framework for both were similar the Community decided to tackle both concurrently as the initial use cases Leveraging use cases based on CMS post acute care assessments also allowed the PACIO Project to leverage the CMS Data Element Library DEL add footnote with citation which added significant value for the sponsoring CMS Division of Chronic and Post Acute Care DCPAC team With the initial use cases decided the group set out to define the required components for data exchanges captured in the diagram below These components guided the PACIO work for early connectathons Diagram showing use case components and their relationships Design Principles In addition to the principles outlined generally in this playbook the PACIO Project followed these additional design principles People don t know what they want until you show it to them Steve Jobs How many people knew they needed a modern smart phone before 2007 Most did not but today almost everyone has a smart phone as an indispensable tool People often have a general sense that something might be great to have but to actually see a tangible example helps people conceptualize new ideas and how they can contribute to its improvement The PACIO Project has taken this approach from its inception focusing on developing reference implementation prototypes to help illustrate what is possible with a focus on getting to the demonstration as quickly as possible at conferences at connectathons and any venue where people can see listen and explore together Develop Minimum Viable Products MVPs With any new venture or use case it is important to show progress as quickly as possible to build excitement and momentum To get to that point quickly the PACIO Project focused on scoping and prioritizing initial development as tightly as possible to show critical value inexpensively in the shortest amount of time Key questions are What is the minimum functionality that is needed to be useful How can we effectively demonstrate that functionality in the quickest way possible Show the Art of the Possible Equally important to making progress and generating excitement it is important to lean forward be ambitious and push limits to motivate participants and observers while building upon what has been done before Starting the Community Networking has been fundamentally responsible for the success of The PACIO Project Community Everyone involved in the early phase of the project opened their contact list to identify leaders with the experience influence and subject matter expertise in critical areas to help kickstart the project PACIO Project leadership from MITRE and CMS drafted and sent a letter to leaders from government vendors associations clinicians and consultants detailing the purpose of the PACIO Project its high level goals and priorities how it might operate and included an invitation to attend a kick off meeting to find out more Over 80 people attended the initial kick off meeting in February 2019 both in person at MITRE and virtually The kick off meeting covered the project goals and priorities in more detail and discussed next steps including the process for creating a Project Charter and deciding on what use cases to tackle first PACIO Project Charter The PACIO Project Charter acts as a guiding document providing in detail The purpose of the PACIO Project Governance Process including how the group will make decisions Project roles descriptions and responsibilities How decisions will be made Who owns the materials generated The PACIO Project is purely a volunteer effort so the project does not have the concept of participant tiers or a pay to play model Everyone has an equal voice and all viewpoints are heard and considered Early in the Charter development process a vocal minority suggested PACIO focus on developing standards in CDA instead of FHIR After some discussion and consideration of all viewpoints the PACIO leadership team decided to stick to the purpose expressed in the invitation letter and focus on FHIR related standards development That was the only time that a major project decision was made by the leadership team instead of the Community and that method should be used only when a consensus based approach is not possible as it can undermine the sense of Community In this case it was critical for setting a consistent focused direction for the project and clearing the way for early progress and momentum Otherwise the Community transparently developed and approved all aspects of the PACIO Project Charter and it has continued to be the guiding Governance for the project with only minor modifications Deciding who owns materials generated during a project can be a sticky issue but that turned out not to be the case with the PACIO Project It is essential to establish clear expectations for ownership of the materials developed early to avoid problems later Ideally the owning organization should be An unbiased entity that will manage the materials in the best interest across the overall project An entity that will continue to exist for the foreseeable future with appropriate contacts for copyright and license issues In the case of the PACIO Project with the exception of the FHIR IGs which HL7 owns MITRE has been designated the owner of PACIO Project materials for the following reasons MITRE is a non profit organization that serves the public interest as an unbiased independent adviser MITRE cannot compete with industry MITRE is established and has longevity MITRE can easily transfer ownership to another entity in the future In short taking on ownership of a community generated artifact is a great use of a Federally Funded Research and Development Center FFRDC PACIO materials are developed transparently and inclusively consistent with ANSI and HL7 standard development practices All source code for reference implementations is freely available on GitHub through the Apache 2 0 license a very permissible license that also protects trademarks like the PACIO name and logo The Apache 2 0 license allows the software to be easily integrated into derivative works with attribution while not encroaching on the licensing of the derivative software Selecting Use Case Leaders Champions The project charter also highlighted important roles within the project and the responsibilities associated with each role including the leadership structure for individual use cases under the project Use case leaders are critical to the success of the PACIO Project so while solicitations for leaders are open to all candidates for those roles must be considered carefully Using the role definitions in the PACIO Charter as a guide PACIO Project leadership engages in an interview process to determine the qualifications of prospective use case leaders and determine their suitability for the role Selection criteria for use case leaders focus on experience leading diverse groups conflict management and the ability to build consensus knowledge of the domain and if applicable technical ability and experience building FHIR standards When In Doubt Vote The Community votes on all major decisions using parliamentary procedures as specified in the charter This includes the establishment or modifications to the strategy to complete work approving a document for ballot or publication approval of a new use case and other important decisions Votes must be recorded in the minutes and provide a record of what has been decided Documentation of past voting results can prevent reopening discussions that have also been resolved if the same topic arises in a subsequent conversation If someone wishes to reconsider they can make a motion to reopen a topic for discussion seconded and voted on by the community Such motions should be deliberative and not in the event that no documentation exists of the group s previous decision If there is any doubt whether a vote is needed for a particular decision a motion second and vote should be taken Branding Branding is an important aspect of any public facing project The best branding is memorable with a short pronounceable name and recognizable logo and can help the project gain traction In the case of the PACIO Project there was much discussion and several names and logos were suggested Ultimately the name PACIO Post Acute Care InterOperability pronounced pass ee o was selected The selected logo displays a series of nodes healthcare facilities networked with a large central node the patient in the center highlighting the importance of patient centered care The PACIO Community approved this logo and name and uses it in all PACIO materials to establish the branding for the project Building the Community Observer Meetings Not all initial participants at the kick off meeting continued to stay involved as some have decided the project does not align with their interests or the time requirement is too much to actively contribute To provide a way for the latter group to stay apprised of PACIO Project progress a monthly half hour PACIO Observers meeting series provides a summary of project updates This type of meeting can serve as an effective recruiting tool as some Observers become weekly Contributors Contributor Use Case and Tech Team Meetings There are many ways participants can contribute to the PACIO Project Participants can start by joining the weekly Contributors Meeting where quick use case updates key discussions and final PACIO Community votes take place The community also discusses specific use case topics during this meeting but as the project has grown each use case typically has a meeting series to dive deeply into the data modeling and standard development process specific to that use case Participants can choose whether to attend those use case specific meetings if they want to be more involved Conferences The PACIO Project also presents at several conferences every year to spread awareness of the project and its objectives To socialize the project and brand PACIO buttons were printed below showing the PACIO Project Website and worn at conferences to invite discussion and further participation PACIO project button handed out at conferences The PACIO Project also maintains a YouTube channel featuring overviews on topics and recorded demonstrations from connectathons and other events Educate A large part of the PACIO Project is educating the community on the healthcare standards process to build and enable leaders to scale the work more broadly As a result the PACIO Project has been able to address more use cases with greater delegation of responsibilities to use case leaders Clinician expertise is vital to determine what information is needed in a post acute care setting but the PACIO Project has found that the community is far more effective if there is a high level general understanding of how health data elements are specified in a standard It is very helpful for the community to understand the differences between optional must support and required elements as well as the role of terminologies and the potential impacts selected elements and terminologies on the FHIR IG Not everyone in the community needs to be an expert on these topics but some level of familiarity with these concepts has helped the community to understand and reach consensus as quickly as possible Progress happens at the speed of trust and consensus The community appreciates the education the PACIO Project has provided on technical concepts and has opened new horizons for community members to a point where they have invited others to join PACIO Listen to and Respect Everyone The PACIO Project strives to listen to every point of view and treat everyone with respect There are no dumb ideas or questions This provides an inclusive environment for people to bring their unique perspectives voice their opinions and ask key questions which produces great discussions and conclusions on challenging topics Invite Guest Speakers The PACIO Project has invited numerous guest subject matter experts to speak on related topics projects or research that can inform the development of PACIO standards raise awareness and result in collaboration opportunities Several of these sessions have been critical to the development of the PACIO Project s IGs and community growth Get Things Done The PACIO Community is made up of very busy people who donate their time to help solve problems to improve healthcare for all It is important that the PACIO Project be respectful of participants time by establishing clear and efficient meeting agendas and expectations Even as a volunteer organization there is an expectation that participants fulfill commitments and collectively show meaningful progress to provide value for their time Many long time community members appreciate this focus and the PACIO Project s reputation helps draw new members into the community because they see things getting done Meeting deadlines and fulfilling commitments also raises the profile of the PACIO Project within the broader healthcare community Break Bread Whenever Possible Getting together at conferences and gatherings is great for building relationships morale and bonds within the community particularly through topics and venues outside of the PACIO work itself Have dinner see a ballgame visit a museum A sense of community keeps participants engaged and energized Record What Happened The PACIO Project records its meetings and places meeting materials on its HL7 Confluence site This not only provides a record for future reference but it also helps new and potential participants get up to speed quickly on what the project has been doing and where we are in the various work streams It also lends flexibility to those unable to attend a specific meeting due to other commitments so they can catch up on discussions they missed at their convenience Delivering Value Initial Demonstration To adhere to the design principles detailed above the PACIO Project built a demonstration that quickly provided a minimal set of functionalities showing tangible value and what is possible using the CMS Data Element Library DEL The CMS DEL is a web based repository containing the assessments CMS requires PAC providers to submit at specified intervals for example at admission and discharge during every patient s stay at a PAC facility The PACIO Project s initial focus was to demonstrate how the CMS DEL assessment metadata could be represented in FHIR to display forms in an application and collect responses This involved several key steps in preparation for the PACIO Project s first HL7 Connectathon in September 2019 Develop a prototype FHIR IG for the CMS Data Element Library DEL Create a Pseudo DEL FHIR server that implemented that prototype FHIR IG populated with the public assessment metadata in the actual CMS DEL system Develop a reference PAC assessment application FHIR client that could display assessment forms using the DEL metadata and collect the responses Demonstrate that the Pseudo DEL and PAC Assessment application could interoperate to display and capture the assessments required by CMS Integration Tracks The September 2019 HL7 connectathon was a success and gave the PACIO Project a great platform to build from for the next HL7 connectathon in January 2020 With the development of the Functional Status and Cognitive Status FHIR IG the PACIO Project sought to demonstrate what could be done with the assessment data once it was collected By pushing the envelope we expanded the September connectathon work into a multi scene demonstration showing how assessment data not only can be collected but shared across multiple acute and PAC facilities The January 2020 connectathon work also incorporated other FHIR IGs developed by other projects to test and show that independent FHIR IGs can work together effectively as a system of systems Over time PACIO Project Connectathon tracks have grown to demonstrate FHIR data exchanges across up to 23 different systems using up to 17 different FHIR IGs by 14 different vendors and organizations Beyond the PACIO Project IGs other IGs include those developed by the Gravity Da Vinci CARIN Alliance and FHIR At Scale Taskforce FAST FHIR Accelerators as well as other independent projects and core FHIR Specifications Through the PACIO connectathon tracks the following FHIR Implementation Guides have been tested working together as a system PACIO Personal Functioning and Engagement PFE PACIO Advanced Healthcare Directives Interoperability ADI PACIO Re assessment Timepoints PACIO Transitions of Care TOC PACIO Standardized Medication Profile SMP Electronic Long Term Services and Support eLTSS Multiple Chronic Condition eCare Plan MCC eCarePlan Gravity Social Determinants of Health Clinical Care SDOH CC Da Vinci Data Exchange for Quality Measures DEQM Da Vinci Coverage Requirements Discovery CRD Da Vinci Documentation Templates and Rules DTR Da Vinci Prior Authorization Support PAS Da Vinci Payer Data Exchange Plan Net Provider Directory CARIN Digital Insurance Card FAST National Directory of Healthcare Providers Services NDH Physical Activity FHIR Structured Data Capture SDC FHIR US Core The PACIO Project approaches connectathons differently than most other projects and organizations Most projects develop the necessary FHIR IGs for the track and provide other materials including a reference implementation but the preparation to connect systems and software does not start until the actual connectathon The PACIO Project does all of that but recruits a core set of participants weeks in advance and works to have a fully functional demonstration with those participants the week before the connectathon The actual connectathon is used to fine tune the demonstration and resolve any issues before recording the full demonstration Starting the connecting process ahead of time allows the PACIO Project to test more complicated cross project data interactions Unexpected participants are still welcome and always add further value to the connectathon but they integrate with participants who are already connecting making it easier for them to participate PACIO Testing Events Sometimes the HL7 and CMS Connectathons do not align timing wise with project requirements In those cases the PACIO Project conducts its own testing events Project management at HL7 allows testing outside of connectathons as long as participation is open and transparent the outcomes are recorded similar to what is collected at the end of a connectathon and any issues raised are captured in the HL7 Jira issue tracking system When conducting testing events the PACIO Project makes every effort to match what is done during the life cycle of a connectathon track namely Provide track descriptions using the same form as for HL7 connectathons Conduct a kick off meeting to orient participants to the track Setup Zoom calls and breakout sessions as needed Publish a track report listing track testing goals participants scenario roles accomplishments challenges and next steps Growth and Impact As of 2024 the PACIO Project has published five FHIR IGs Two others were moving toward their first edition HL7 ballot and two more were being updated for second edition HL7 ballot The PACIO Project has also been an active member of USCDI and USCDI development providing many comments each year as the USCDI and USCDI versions progress resulting in several new published data classes and data elements such as Advance Directives Functional Status Mental Cognitive Status and Patient Communication Status USCDI updates inform FHIR US Core development New regulations are requiring certain providers not yet PAC providers to implement newer US Core versions for certified APIs This would mandate support for these new data elements to comply with EHR certification requirements The PACIO Project s development and testing of relevant FHIR IGs through vendors in the PACIO Community brings additional credibility to the PACIO comments The PACIO Project is well known and positively regarded by CMS Office of the National Coordinator ONC and HL7 with multiple references in the Federal Register ONC Interoperability Standards Advisory ISA trade journals and both domestic and international FHIR interoperability specification lists Many consider the PACIO Project to be the go to source for PAC subject matter expertise and standards development The PACIO Project continues to attract new members from new sources validating the project s strategy of presenting and participating in a broadening list of conferences on a variety of use cases The PACIO Advance Directives work has visibility at the highest levels of the FHIR Project Team who have taken a personal interest in the project The PACIO Project also is pursuing pilots and production opportunities This has been more challenging than in other cases since post acute care facilities were not included in the Electronic Health Record EHR Incentive Program and therefore did not receive funding to install and upgrade their EHR systems like other parts of healthcare As a result the number of available providers who have EHR systems sophisticated enough to participate in pilots and production environments is much more limited Nevertheless the PACIO Project is forging a pathway forward for standardized exchange of post acute care data Resources PACIO Project Website HL7 Confluence Page for the PACIO Project Use Cases Dashboard Meeting Index YouTube Channel FHIR Implementation Guides Personal Functioning and Engagement Implementation Guide FHIR Shorthand FSH Advance Directives Interoperability Implementation Guide FHIR Shorthand FSH Re assessment Timepoints Implementation Guide FHIR Shorthand FSH Standardized Medication Profile Implementation Guide FHIR Shorthand FSH Transitions of Care Coming soon GitHub Repositories PACIO Project HL7 Reference Implementation Sample Data"},{"id":16,"doc":"Case Studies","title":"The mCODE Standard and CodeX Community","url":"casestudies/mcode_codex.html","content":"On This Page mCODE and CodeX Getting Started First Use Case Growing the Community Expanding the Work Adoption Value Conclusions Back to top Case Study The mCODE Standard and CodeX Community This Case Study summarizes from MITRE s perspective the history of the mCODE FHIR standard and the CodeX Community Included here are how both started how they grew lessons learned and progress toward solving challenges facing initially cancer patients researchers and others This Case Study should be especially valuable to those interested in starting within CodeX or elsewhere broad new standards initiatives for additional medical specialties Introduction and Agenda 5 mins mCODE Development History 4 mins mCODE Modeling Methodology 7 mins Define Use Case 5 min Gathering Relevant Clinical Information 13 mins Translate Information into FHIR IGs 15 mins Validate FHIR IG 5 mins Case Study CardX 5 mins Case Study GenomeX 4 mins mCODE Deeper Dive Q A and general discussion 89 mins Before reviewing the mCODE standard and CodeX Community experience here is a brief definition of each What is the mCODE Standard mCODE is an HL7 standard FHIR Implementation Guide IG integrating an agreed core set of common data elements for cancer These data elements are deemed valuable to patients and other stakeholders via multiple use cases potentially available in every electronic health record for cancer patients and machine computable mCODE consists of approximately 30 FHIR profiles and roughly 100 data elements organized into six thematic groups see below Patient Information Health Assessment Genomics Group Disease Characterization Cancer Treatments and Outcomes Diagram of oncology stakeholders and categories of related data elements in the mCODE FHIR standard What is the CodeX Community CodeX is a member driven HL7 FHIR Accelerator hosting a growing community working together to drive substantial improvements around the most important challenges facing specialty health care and research Initial CodeX Use Cases projects focused on improving collecting and sharing mCODE based data in the oncology space Through 2024 cardiovascular and genomics Communities have also started work within CodeX The following graphic summarizes a core CodeX strategy Enabling all patient data to be collected once and then shared and used as consented by the patient for many different use cases CodeX vision that a cancer patient s data can be collected once and more easily shared for multiple use cases provided the data are standardized Getting Started Key Playbook Track Community Building History 2017 2018 Origin The lucky spark was a chance encounter between former medical colleagues Dr Jay Schnitzer and Dr Monica Bertagnolli on an airplane in 2017 Bertagnolli was a preeminent cancer surgeon at Brigham and Women s and was leading the American Society of Clinical Oncology ASCO and Alliance for Cancer Trials in Oncology ACTO Dr Schnitzer was Chief Medical Officer and Chief Technology Officer at MITRE with a growing portfolio of health information technology research Drs Bertagnolli and Schnitzer had been circling around how to achieve a Learning Health System where caring for every patient enables learning from every patient Every person with any disease should have access to high quality care and also will have the opportunity for their experience to help others in the future Drs Bertagnolli and Schnitzer had also been circling around one of the fundamental challenges to achieving a Learning Health System Lack of a single standard for collecting and sharing patient data electronically They organized the first clinical requirements team convened under the auspices of ASCO co chaired by Drs Jim Chen and Doug Blaney and staffed with world class experts from across the oncology space The team s mandate was to agree on first use cases a narrow scope was important and on a minimal set of clinical data to address use case requirements This data dictionary later seeded a new standard for cancer data the minimal Common Oncology Data Elements Learnings ASCO and MITRE led by Drs Bertagnolli and Schnitzer became what we now call Champions for the new oncology specialty initiative As champions they Committed their leadership Offered many of the key capabilities needed to start and succeed ASCO and ACTO clinical MITRE standards and systems engineering Both convening power Had access to potential members of the community and the resources needed to develop and leverage mCODE ASCO and ACTO access to almost all clinical cancer organizations and vendors MITRE deep expertise in standards and systems engineering Both strong links to Federal health agencies Established the need for clinical expert consensus on very specific use cases and associated minimal data requirements First Use Case Project Draft Standard Key Playbook Tracks Community Building Use Cases Planning Standards Development History 2018 2019 First Project EHR Endpoints for Cancer Clinical Trials ICAREdata study The original mCODE clinical team envisioned a small set of use cases in its initial conceptual work It was clear that success required executing a project where standardized data collection and sharing in the real world would test the value of the new data standard The use case for the ICAREdata project was to capture and share using the mCODE standard high quality clinical treatment data from electronic health records EHRs that could be used for oncology clinical trials and other research ACTO and MITRE became the ICAREdata Use Case Champions Over time multiple health systems clinical trials Epic pharmaceutical companies NCI and FDA participated in hosted and or funded development and testing Initial work focused on standardizing and collecting just three key data elements cancer type disease status e g progressing stable and reason for treatment change all modeled within the fledgling mCODE IG Learnings ACTO and MITRE understood that the best way to develop a cancer data standard is to focus on the small set of core data elements needed for specific use cases e g specific challenges that if empowered by standardized data could have a substantial impact ACTO and ASCO s credibility and clinical network facilitated the engagement of outstanding clinical experts and vendors Adoption and Value in real world settings was in the Plan from the start This ultimately helped refine mCODE and workflows and led to greater participation and substantial funding This use case also helped identify the skillsets necessary during different phases of use case work mCODE Design The ICAREdata Use Case provided helped establish an approach and structure for mCODE around patient assessments disease treatment outcomes genomics and design principles mCODE V 1 0 IG was balloted in the Health Level Seven HL7 standards organization in 2019 and benefited substantially from the ICAREdata experience mCODE design principles started to become clear during the ICAREdata Use Case and have improved and served mCODE s evolution since Principles include a Focus on discrete data collected during patient encounters b Acquire clinical expert input first and engage other experts as the IG is developed c Base the IG on government and industry requirements and trends e g FHIR US Core d Leverage the best existing clinical data modeling efforts e Adopt global standard code systems More details in the Design Principles section Growing the Community Key Playbook Tracks Community Building Implementation Testing History 2019 2020 Cancer Data Summit Interest in mCODE was starting to build and new use cases were being proposed A small group of leaders from across the oncology space patients providers researchers payers gov t agencies vendors and others convened for two days in October 2019 to brainstorm on the future of standardized cancer data obstacles to success and next steps Below is one of the many storytelling roadmaps from the Summit One outcome was support for creating a clinical requirements group which became the mCODE Executive Committee and an implementation group which became the CodeX HL7 FHIR Accelerator Learnings The Summit provided substantial benefits Extremely useful feedback was provided by a diverse set of leaders Noticeable alignment between diverse views happened during the two day event Strategies for next steps were shared Many who attended the Summit expressed interest in staying involved and many of those became Champions and participants in the future mCODE Executive Committee and CodeX Community Whiteboard illustrations from the Cancer Data Summit in October 2019 showing the participants vision of the promise of a common standard for cancer data such as mCODE mCODE Executive Committee and Technical Review Group This body was organized under the leadership of ASCO and included clinical leaders and experts from major cancer related societies government agencies and others as needed This group followed from the original clinical requirements team convened by ASCO in 2019 see above The mandate continues to be to maintain and evolve the clinical data dictionary that underpins mCODE It has proven beneficial to have this strictly clinical group focusing on clinical requirements and interpretation An expert can be an invaluable contributor to mCODE without being deeply involved in the technical and logistical work that CodeX would take on However a valuable small subset of those involved in the Executive Committee have joined CodeX standards and use case work CodeX Community To complement the Executive Committee s clinical leadership MITRE led the creation of CodeX within HL7 s then new FHIR Accelerator Program CodeX was established and still operates with a focus on creating FHIR IGs but also just as importantly a focus on implementing FHIR IGs into software and workflows testing these in the field and supporting adoption and value measurement in the real world A lightweight process Governance structure and Membership fee model were established There were 9 founding members and other categories members by the end of 2020 Establishing the goal of adoption and value of a standard rather than focusing primarily on standards development was and is not easy This generally takes a greater commitment of resources and time from more parts of the community to achieve the goal However this goal resonated with the growing community and ultimately paid off in new use cases members adoption and value in the real world Initial Vendor Implementation Epic and others started to integrate parts of mCODE in their software Demand for mCODE from large cancer centers through ASCO ACTO and the Summit provided substantial motivation for vendors to deliver mCODE infused systems to their customers Expanding the Work Use Cases Solving Real World Problems Led by Champions Powered by a Growing Community Key Playbook Tracks Community Building Use Cases Planning Implementation Testing History 2021 2024 NOTE Check numbers Growth in number of CodeX Use Cases Dec 2020 5 Use Cases Dec 2021 8 Use Cases including first genomics Use Cases Dec 2023 12 Use Cases including first cardiovascular Use Cases CodeX Use Cases today Learnings CodeX leadership agreed to a use case selection process to help ensure use cases have the ingredients e g the Tracks described on this website to succeed The table below lists use case start dates and the champions that drove them Medical societies and government agencies were the most frequent champions Growth in CodeX Membership Feb 2020 9 Members Feb 2021 20 Members Dec 2021 30 Members Jun 2022 40 Members May 2024 50 Members Two main drivers for attracting new members included promising progress within ongoing use cases as well as new use cases which engage different segments of a given specialty ex the radiology segment of the oncology space Successful use cases engaged at least one generally more of each of the types of organizations needed to execute the use case Progression of Use Cases and Champions That Drove Them NOTE Check Names and Dates Start Execution Cancer Use Cases Community Champions 2017 2018 mCODE and CodeX Launch ASCO ACTO MITRE visioning 2018 19 EHR Endpoints for Cancer Clinical Trials ICAREdata ASCO Alliance for Clinical Trials in Oncology engaged Epic multiple cancer centers 2019 20 mCODE Executive Committee and Technical Review Group formed to provide clinical review of proposed new mCODE data elements CodeX Accelerator launched to provide framework and Governance for initially cancer mCODE based Use Cases 2020 mCODE Extraction MITRE 2020 Trials Matching American Cancer Society Cancer Action Network which engaged multiple cancer centers vendors 2020 Radiation Therapy American Society for Radiation Oncology American Association of Physicists in Medicine engaged Epic Varian Elekta other societies cancer centers 2020 Registry Reporting Center for International Blood Marrow Transplant Research Centers for Disease Control and Prevention 2021 Prior Authorization Evernorth and many others Genomics 2 Use Cases HL7 Genomics Work Group Kaiser 1st specialty beyond oncology 2022 Risk Evaluation and Mitigation Food and Drug Administration Cardiovascular 2 Use Cases University of Nebraska American College of Cardiology American Heart Association 2nd specialty beyond oncology 2023 Quality Measures American Society for Radiation Oncology Evernorth Telligen CodeX Use Cases today The evolution of the mCODE FHIR IG standard was strongly driven by CodeX Use Cases and their requirements for core oncology data elements to fuel solutions The static graphic below is mCODE s conceptual model as of October 2023 Visit the latest version of the mCODE FHIR IG where you can click on individual boxes in the graphic to dive into the details of where mCODE stands today The mCODE STU3 conceptual modeling diagram built through defining the needs of different cancer use cases Delivering Demonstrable Value as of early 2024 Key Playbook Tracks Implementation Testing Adoption Value In less than 5 years the CodeX Community and other adopters have demonstrated the value of levering the mCODE standard for data collection and sharing to the point where an increasing number of oncology stakeholders are seeing potential value and requesting support from vendors As of early 2024 there are numerous examples of success Vendor Adoption Infographic showing industry adoption of CodeX standards 2024 Numbers are based on what the team has heard directly There may be additional independent efforts adopting the CodeX FHIR standards Adoption for Routine Care Research by Rodrigo Dienstmann et al Oncoclinicas Data at the largest cancer center outside of North America NOTE check was conducted on 3 069 cancer patients whose data was collected stored and used based on the mCODE standard They found that mCODE enabled a substantial increase in availability of data essential to cancer care improved quality of capture of critical genetic factors for colorectal cancer enhanced real world estimates of progression free survival and significantly increased the patient clinical trials match rate Mayo Pilots using mCODE found NOTE Add more Adopted by and Aligned with Federal Initiatives White House Cancer Moonshot supported by MITRE OSTP and ARPA H noted CodeX as an important partner in strengthening the nation s clinical trial infrastructure President s Cancer Panel noted the importance of mCODE in their recommendations for NCI s National Cancer Plan CMS using mCODE in their Enhancing Oncology Model FDA championing CodeX REMS Integration Use Case CDC s use of mCODE for Central Cancer Registry Reporting IG ONC s US Core Data for Interoperability USCDI Cancer is aligned with mCODE ONC included select mCODE data elements in their USCDI proposed Quality Data Element List Box diagram highlighting adoption metrics for CodeX and mCODE Conclusions from the mCODE CodeX Case Study Key Playbook Tracks Community Building Use Cases Planning Standards Development Implementation Testing and Adoption Value Between 2019 and 2024 the CodeX Community and colleagues improved and leveraged mCODE to address difficult problems in oncology substantially improving cancer care and research During 2022 2024 the cardiology and genomics Communities started their CodeX journey This Playbook is a compilation of the experience from CodeX and elsewhere that is hoped will speed the work of additional new specialties that are considering following the mCODE CodeX model"},{"id":17,"doc":null,"title":"Case Studies","url":"casestudies/index.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies mCODE Radiation Therapy PACIO Project Resources About Back to top Case Studies This section highlights projects that have contributed to and leveraged the MITRE Health Data Interoperability Playbook to achieve success mCODE Standard and CodeX Community Organizations American Society of Clinical Oncology ASCO MITRE Corporation The history of the mCODE FHIR standard and the CodeX Community how both started how they grew lessons learned and progress toward solving challenges facing initially cancer patients researchers and others This case study should be especially valuable to those interested in starting broad new standards initiatives for additional medical specialties CodeX Radiation Therapy Treatment Data Use Case Organizations American Society for Radiation Oncology ASTRO American Association of Physicists in Medicine AAPM Learn how developing a core set of structured data elements for oncology electronic health records EHRs changed oncology radiation therapy The RTTD CodeX use case developed implemented tested and is driving adoption of FHIR based standards and systems such that a radiation oncology information systems can seamlessly generate and share patients radiation therapy treatment summary information across health systems and providers and b clinicians can then use the radiation therapy treatment summary information to make informed impactful decisions related to a patient s health PACIO Project Organizations CMS Division of Chronic and Post Acute Care DCPAC PACIO Project Learn how streamlining transitions of care and care coordination through FHIR changed post acute care The PACIO Post Acute Care InterOperability Project is all about care coordination Forty five percent of Medicare patients who leave hospitals go into some kind of post acute care Post acute care accounts for 74 billion in Medicare payments annually so it is a large part of our healthcare system Post acute care patients are typically very complex and have multiple transitions in their healthcare journey When a person transitions between healthcare settings including ambulatory care acute care long term post acute care LTPAC and home and community based services HCBS mdash their care is often fragmented and can lead to poor health outcomes increased burden and increased costs The PACIO Project is helping to fix these problems Prev Adoption Value Next Resources"},{"id":18,"doc":null,"title":"Welcome to MITRE Health Data Interoperability Playbook","url":"index.html","content":"Welcome to the MITRE Health Data Interoperability Playbook Sharing MITRE s experience developing and deploying health data standards that address real world challenges in patient care and medical research All medical specialty communities are invited to learn and join the mission Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Better Data Better Health In 2017 leaders within The MITRE Corporation and the American Society of Clinical Oncology ASCO recognized a fundamental challenge across the oncology field the lack of a single standard for collecting and sharing a patient s health data electronically This lack of standardization led to numerous issues including difficulties in exchanging data data errors delays in analyzing data and prescribing treatments excessive costs for care and research and an undue burden across the entire health ecosystem To address these issues MITRE and ASCO partnered with a diverse group of leading experts to develop the minimal Common Oncology Data Elements mCODE a FHIR based standard for oncology data collection and sharing MITRE also worked with Health Level Seven HL7 to launch the CodeX HL7 FHIR Accelerator a growing community of providers patient advocates researchers payers vendors regulators and other stakeholders who are driving adoption of mCODE through new standards based solutions to a range of real world challenges This Health Data Interoperability Playbook the Playbook consolidates MITRE s experience leading mCODE CodeX and similar projects to create a roadmap for specialty champions and their teams to drive new FHIR based data standards that improve health care and research The Playbook is organized around five tracks that form a framework for the CodeX mCODE approach Community Building Use Cases Planning Standards Development Implementation Testing and Adoption Value Questions that a new specialty should ask themselves before embarking on the above tracks are included on the Before Starting page Design Principles are a foundation for efficient development of quality standards and will help ensure alignment between different standards development initiatives within and across specialty communities A downloadable Playbook Checklist will help specialty communities embark on new standards initiatives across Playbook tracks Case Studies show how specific projects have leveraged the tracks Additional details related to the tracks and Case Studies can be found in the Resources section Next Introduction Featured Case Studies Projects that have developed and used the principles and practices covered in the Playbook mCODE Standard and CodeX Community Learn how the CodeX Community changed oncology care and research by standardizing data exchange through a core set of FHIR data elements CodeX Radiation Therapy Treatment Data Use Case Read how the American Society for Radiation Oncology and American Association of Physicists in Medicine joined CodeX to build a community and standardize FHIR based radiation therapy treatment summaries PACIO Project Review how the PACIO project is streamlining transitions of care and care coordination between post acute care PAC and other providers patients and key stakeholders through FHIR View all Case Studies"}] \ No newline at end of file +[{"id":0,"doc":"Playbook","title":"About the Playbook","url":"about/index.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top About the Playbook Better Data Better Health The purpose of this Playbook is to capture the learnings of the MITRE team as they with the cooperation of a growing community launched the CodeX HL7 FHIR Accelerator led development of the minimal Common Oncology Data Elements mCODE and other FHIR Implementation Guides and deployed FHIR based solutions to help patients providers and others in the real world It is hoped that MITRE s experience can provide a recipe to successfully launch and implement new healthcare specialty interoperability initiatives For more comments and questions please email mcode mitre org Organization The MITRE Corporation MITRE was established to advance national security in new ways and serve the public interest as an independent adviser MITRE continues to deliver on that promise every day applying our systems thinking approach to provide solutions that enhance our national security and way of life Our non profit status sets us apart Motivated by impact our people discover new possibilities create unexpected opportunities and lead as pioneers for the public good"},{"id":1,"doc":"Resources","title":"Technical Standards Development Deep Dive","url":"resources/tech-standards.html","content":"On This Page Standards Development Deep Dive Clinical Requirements FHIR IG Development HL7 Standardization Back to top Technical Deep Dive into FHIR Based Standards Development Tailored for clinical subject matter experts standards developers and systems implementers Health data standards help patients health systems payers researchers and others who need to work together communicate using a common language Health data standards can specify clearly how data are collected stored shared and or used such that every piece of data can be unambiguously understood by all entities within the health ecosystem These standards are not the end product and instead are an essential means empowering accurate electronic data sharing to improve health care and access and to reduce burden and costs The following sections will guide clinical and technical experts through Health Level 7 HL7 processes to refine clinical requirements and develop implementation guides IGs It is advised that throughout the process the teams undertaking these efforts utilize existing communities and resources including chat fhir org HL7 Work Groups and FHIR Accelerators These external groups have extensive expectance in all aspects of FHIR software development and can significantly reduce the time required to develop real world impactful software for the specialty community The best standards are standards that are demanded by product consumers community driven and developed within an open royalty free standards organization often recommended or mandated by the government well documented demonstrated to provide value easy to implement in systems and workflows and widely adopted by the community CodeX mCODE Standards Development Tutorial The following is an excellent video by May Terry key mCODE author that provides a deep dive into the strategy and process employed to develop the mCODE FHIR IG standard for oncology This strategy and approach should be applicable across health specialties Selected points from the video are summarized in text and graphics on the rest of this page Introduction and Agenda 5 mins mCODE Development History 4 mins mCODE Modeling Methodology 7 mins Define Use Case 5 min Gathering Relevant Clinical Information 13 mins Translate Information into FHIR IGs 15 mins Validate FHIR IG 5 mins Case Study CardX 5 mins Case Study GenomeX 4 mins mCODE Deeper Dive Q A and general discussion 89 mins Key Organizations and Foundational Standards Health Level Seven HL7 develops approves and maintains medical interoperability standards across the world While it is possible to develop interoperability standards outside HL7 in practice it is unlikely these standards will be widely adopted without HL7 approval As a result it is critical to follow HL7 processes and collaborate with HL7 work groups when starting or modifying any IG This collaboration is best started early in the IG development process at or before the first draft of the IG is complete The Office of the National Coordinator for Health Information Technology ONC is the principal federal entity charged with coordination of nationwide efforts to implement and use the most advanced health information technology and the electronic exchange of health information ONC spearheads assembling community agreement on a standardized set of health data classes and constituent data elements for nationwide interoperable health information exchange called the United States Core Data for Interoperability USCDI ONC also coordinates the USCDI initiative which supports domain or program specific data element lists that operate as extensions to the existing USCDI The mCODE team is coordinating closely with the USCDI cancer domain team ONC has increasingly partnered with HL7 the preeminent organization for gathering communities to develop standards that enable health data interoperability Of the many important efforts within HL7 two are foundational for the work described in this Playbook Fast Healthcare Interoperability Resources FHIR and US Core FHIR Implementation Guide Both are further explained below Standards Development Overview The following graphic illustrates key steps that are necessary and or useful in developing and publishing a quality HL7 standard FHIR Implementation Guide This process is agile thus the cycles representing steps with iterations and interactions between each cycle Diagram describing the development of a FHIR Implementation Guide from Clinical Requirements to FHIR IG Development to HL7 Standardization Simple Clinical Concept Example Systolic Blood Pressure The following example shows how the FHIR Implementation Guide development process outlined above can be applied to a simple clinical concept such as systolic blood pressure Step 1 Clinicians are consulted about what information and factors need to be captured regarding systolic blood pressure for example What is the measurement value What units are used to measure the value Note that this is a simplified example to introduce the process There are other factors to be considered e g how is blood pressure measured where it is measured on the body body position etc Step 2 Create a data dictionary to capture how that information from Step 1 should be represented Consult with clinical terminology subject matter experts to fill out the data dictionary Review results with clinicians and gain their approval Diagram showing example data dictionary for exchanging systolic blood pressure Step 3 Determine the FHIR design from the data dictionary to exchange the required systolic blood pressure information Review results with the community clinicians terminologists technologists and gain consensus Diagram showing example FHIR design for exchanging systolic blood pressure from HL7 FHIR US Core 7 0 0 Additional Considerations to Enable Cross Health Data Interoperability When defining Use Cases and the associated data standards make interoperable data exchange the top priority Data exchange standards can also influence and provide value for data collection Data that will be exchanged must be collected or be computed from data that are collected How the data are stored within systems can be defined by the implementor to meet engineering requirements Implementers may find value in leveraging data exchange standards in their storage schemes How the data are displayed and manipulated e g interfaces for collection aggregation review computation analysis and others can be defined by the implementor to the benefit of users Implementers may find value in leveraging data exchange standards in their display and manipulation schemes Following the Design Principles has many benefits including helping to ensure consistency with other efforts which is critical in working towards a unified lifetime Standard Health Record where an individual s health data is captured accurately and consistently across medical systems and specialties see figure below Leveraging established clinical requirements and a common standards framework of US Core and standard terminologies as CodeX Use Cases and mCODE do enables individual specialties to develop their IGs independently and yet as consistently as possible The Standard Heath Record vision could extend the CodeX mCODE approach to help new specialties expand communities and to develop and test standards that are interoperable across specialties and that drive adoption and value for patient health care and research Image is placeholder only will replace with accessible image Clinical Requirements Information Needs and Data Dictionary For clinical subject matter experts the goal is to guide the initial steps of the implementation development process to prioritize information requirements within a data dictionary needed for the use case Thus a well rounded team of clinical subject matter experts is necessary for guidelines on how to establish this team see the Clinical Requirements section in the high level overview of standards development One of the first tasks of the clinical requirements team is to define the scope of the data dictionary Both CodeX and FHIR design principles recommend a minimalist approach cover the most common and important use cases not necessarily all edge cases This approach speeds development work improves the odds of reaching consensus and creates a final product that can be expanded to meet future needs This sub step and subsequent steps are typically iterative For example the clinical expert group may develop a first draft of the Data Dictionary Subsequent steps often result in requests to the clinical experts for clarification or suggestions for updates to the Data Dictionary based on FHIR development implementation and testing Defining the Data Dictionary A data dictionary is a conversion of the clinical information needed for the use case into logical model data elements To begin to define the data dictionary the clinical expert group will identify a set of clinical requirements for a use case The clinical requirements and data dictionary template provides an example assessment of a cancer patient and instructions for filling out the template The spreadsheet Clinfo_NGS contains necessary data elements for the use case data sources references to prior work and under the Use Case Relevance column is an expert assessment of Relevance to Patients Like Mine to help prioritize the minimal set of information needed A blank spreadsheet for clinical requirement development can be found in the Clinfo_Template spreadsheet Once information needs have been prioritized the group should consider whether the data elements should be Required Data is unusable or makes no sense if not present Optional Data is not always relevant and not needed for data to be usable Must Support Software is required to support this data element The group can next develop the data dictionary a Rosetta Stone that defines data elements mapped to the clinical information requirements An example data dictionary and a blank template can be found in the clinical requirements and data dictionary template in the DEDToClinfo_Example and DEDToClinfo_Template spreadsheets respectively Common Challenges Related to Compiling Clinical Information Requirements and a Data Dictionary Starting with a large set of important data needs elements rather than focusing on the needs for each prioritized use cases Not thinking about how to maximize the utility of information across other use cases For example the information needed for initial diagnosis of cancer might also be used for clinical trials matching or conducting trials Slight changes to the initial requirements could enable the same information to be useable across all three use cases Asking for interpreted information rather than source data because that is established practice For example asking for age rather than collecting birth data and date time of the encounter These and other potential pitfalls can be largely avoided by following the Design Principles compiled based on CodeX and mCODE experience Clinical Review of the Data Dictionary Before handing the data dictionary over to the FHIR IG development team the clinical team should answer the following questions Does the Data Dictionary address the goal and needs of the use cases From a clinical perspective will the new data dictionary be compatible with other known or prospective data dictionaries with the specialty and outside of it FHIR IG Development Integrating Clinical Requirements into a Specialty FHIR Implementation Guide Once the clinical subject matter expert group has at least a draft of their data dictionary for the use case work can begin on incorporating the clinical information into one or more FHIR IGs Once the FHIR IG development team has been assembled both the IG development team and the clinical requirements team will collaborate to ensure the clinical information needs are captured properly in the FHIR IG that the FHIR IG is implementable in systems and processes and that it is consistent with the Design Principles A specialty should aim for a single core IG that represents the minimal clinical requirements for a set of Use Case concepts that are common within the specialty The mCODE FHIR IG is an example of a core IG The core IG can be appended and improved as Use Cases are executed Supplemental IGs can be built when new data requirements are not considered core but important for smaller Communities and or edge applications Framework for FHIR Implementation Guide Development As is likely clear by now use of the FHIR exchange standard is foundational to the recommendations in this Playbook technical experts will need a deep understanding of FHIR to guide processes Below are some helpful guides to better understanding FHIR Fast Healthcare Interoperability Resources FHIR is the health data sharing framework widely used now and is being mandated for certain applications through ONC US Core FHIR Implementation Guide IG encapsulates into the FHIR framework the data classes and data elements defined through US Government coordination and the United States Core Data for Interoperability USCDI and will evolve as Government work evolves HL7 requires IGs designed for the US healthcare system to be based on the US Core FHIR framework unless a waiver is approved by HL7 FHIR Tutorials FHIR Basics for Post Acute Care by Jessica Skopac MITRE approachable introduction to FHIR for the non technical HL7 Courses on FHIR Intro to FHIR by James Agnew Smile CDR FHIR for Developers Getting Started by Gino Canessa Microsoft Standard Terminology refs HIMSS CMS A terminology code system is a managed collection of structured terminologies concepts like procedures diagnoses treatments measurements results and others with the objective that there is one globally unique code alpha numeric typically to represent each concept Code systems terminologies and vocabularies are not the same things but are highly related and often used together or for the same idea SNOMED CT LOINC CPT are some examples of widely used code systems The benefit of representing a concept with standard terminology in an IG and elsewhere is that the concept can be implemented in FHIR or other standards in health information systems and understood everywhere the concept is collected stored exchanged and used FHIR Shorthand FSH is a domain specific language for defining FHIR artifacts involved in creation of FHIR Implementation Guides IG The goal of FSH is to allow Implementation Guide IG creators to more directly express their intent with fewer concerns about underlying FHIR mechanics and efficiently produce high quality FHIR IGs FSH is an HL7 standard FSH is increasingly used around the world There are excellent tutorials on how to leverage FSH to create FHIR IG FSH School Mark Kramer Learn to FSH A friendly introduction to FHIR Shorthand DevDays 2023 Amsterdam PDF version Data Model The first task of the FHIR IG development group is to review the output of the clinical group s data dictionary It is helpful if some members of each group have been working together even before the first draft of the dictionary has been completed Questions between the groups will be common and essential to taking additional steps The next step is to start development of a conceptual model from the data dictionary and begin the process of identifying existing FHIR artifacts IGs profiles and extensions that the developing IG can use it is critical that specialty communities minimize changes and modification to existing FHIR artifacts to maintain consistency within the larger healthcare data exchange community This helps ensure the final IG and associated software more easily accepted and adopted across all healthcare domains Below is mCODE s conceptual model and an interactive version can be found within the mCODE IG Example conceptual modeling diagram for mCODE STU 3 2023 draw io was used to create the mCODE modeling diagram Terminologies As previously noted terminologies standard clinical code systems are important for unambiguously defining how data within the data element are represented When a term cannot be found within an existing code system it s possible to work with the owner of the code system to add new terms provided the justification is convincing Profiles and Extensions FHIR profiles customize the standard FHIR base Resource definitions by constraining which values and elements of a resource are required and which are not for a particular context or use case FHIR extensions add data elements and or constraints for the standard FHIR base resource definitions to create more specific customized resource definitions for a particular context or use case The following shows how mCODE derived profiles from the aforementioned framework of the US Core FHIR IG The subsequent three figures illustrate how the mCODE conceptual model is represented in the FHIR IG for patient demographics labs and medications to match the clinical information needs as structured data Diagram of FHIR Resource derivations showing how mCODE is built on US Core and FHIR Base resources To ensure consistency with the wider interoperability community the IG development team should first check the FHIR Implementation Guide Registry FHIR Package Registry and FHIR Extension Registry for existing FHIR artifacts that might be reused in the developing IG If an appropriate existing artifact cannot be found new resources profiles or extensions may need to be created Before creating a new FHIR artifact the IG development team should discuss the proposed artifact and its purpose with the HL7 Working Group responsible for the FHIR Resource being extended All FHIR resources and profiles have an HL7 Working Group that is responsible for their development The HL7 Working Group is listed on the FHIR resource page itself or in the case of a profile in the footer of the profile page Reviewing the proposed artifact with the responsible working group provides an opportunity for them to understand the purpose for the extension and offer guidance in alignment with their development strategy for the resource When packages and other IGs are leveraged by a project they become dependencies of that project When depending on other FHIR packages and IGs to leverage it is important to consider what versions to use since in many cases multiple versions may exist There are many factors that should be considered when determining what version of a FHIR package or IG to use Have they been officially published and if not when will they publish This will affect the development timeline What level of adoption does that version have or will have in the near future Using the latest version may push adoption further out in time relative to using an older version in broader use What regulations may apply Regulations can stipulate what versions can be used e g US Core version requirements for product certifications Planning FHIR IG Development A Patient Demographics Example There are a number of important high level questions to consider when developing a FHIR IG These questions can be found in the higher level FHIR IG Development section Example Patient Demographics Diagram of an mCODE Patient Bundle entry based on external profiles Relevant external profiles are added as an entry to the mCODE Patient Bundle profile Possible because mCODE s bundle is open only CancerPatient is a required entry Guidance for inclusion is narrative not computable or enforceable Validating Modeling Assumptions Next create a comprehensive set of FHIR resources that capture the product of the previous steps One approach to validating the work is to match it to representative use case personas The next figure illustrates how parts of a particular patient journey are mapped into data elements and FHIR See other mCODE examples represented in the mCODE FHIR IG A particular patient journey mapped into data elements and FHIR to validate the model Creating the FHIR Implementation Guide Initial creation of a FHIR IG can start quite early and iterate as the model is improved HL7 Standardization Health Level Seven HL7 is the preeminent organization for gathering communities to develop standards that enable health data interoperability The US and other nations increasingly look to HL7 as the place for health standards development p HL7 Standards Process Agreeing on content of the FHIR IG to be standardized and then moving the IG through the HL7 process can take many months on the order of a year from start to publication of a standard Time required depends on level of alignment of the IG authors and also on how familiar project s standards process leader is with HL7 processes and people but can be many months to more than a year Projects should make sure to include sufficient time in the use case plan and also start the standardization process early before a complete draft FHIR IG is available Resources that are important to review and understand HL7 Essentials Index to information on HL7 HL7 processes and other information that is relevant to anyone planning to work or working in HL7 Understanding the Standards Process Explains what HL7 does rationale for the processes and how to maximize the benefits of using the process FHIR Implementation Guide Process Flow When creating a FHIR IG that is intended to an HL7 standard there are a number of specific steps to complete A timeline based on HL7 s early 2024 processes is shown here This is subject to change Please check the previous link for the latest HL7 s graphic HL7 Process Flow and Timeline is also helpful in that steps in the HL7 process are linked to details on each step Maintaining HL7 Standards Once the first version of a specialty standard the Standard for Trial Use STU has been completed and published work begins on maintaining the standard over time Any standard that is valued implemented into systems used widely will generate requests for updated versions Updates to specialty standards may be needed for a variety of reasons The base standards on which your standard depends e g FHIR US Core may be updated and may require or at least motivate changes to standards that depend on them Users or the vendors may ask for updates Government rules and regulations may motivate changes Because changes to your standard may be required over time it s important to keep a core of the original IG development team intact and add to that core with the necessary skills e g clinical FHIR HL7 available when needed It s important to keep a good relationship with the sponsoring HL7 Work Group It s necessary to have a system to collect organize prioritize and address requests for changes and other comments likely the same system used for building the original standard e g Jira at HL7 Be aware that the interest of the original teams and even that of the Use Case champions may change as the work enters maintenance As repeatedly emphasized in this Playbook think about which members of the community care most about ensuring a standard is maintained in a well governed careful manner For example vendors who ve implemented the standard and included the standard in products to many customers should care about how the standard is maintained and evolved Best Practices for Smoother HL7 Standardization Based on the CodeX mCODE Experience The standards process leader for the use case should have thorough knowledge of HL7 processes and standardization schedule Build HL7 standardization into your use case plan from the start Allow plenty of time to go through the process Have a good relationship with a sponsoring HL7 Work Group and its leadership Ensure they are included in plans and progress In many cases HL7 Work Group may have deep expertise within the community s specialty however even if they do not they will know HL7 standards HL7 processes and work that other Work Groups are doing that may be related to your work Collaborate with a HL7 FHIR Accelerator like CodeX This path has the benefit of working within an organization that will be more knowledgeable of and connected closely to HL7 people and processes Discuss any new extension and its purpose with the HL7 Working Group that has responsibility for the FHIR Resource being extended so that they understand the need and can provide guidance NOTE Add more best practices"},{"id":2,"doc":"Resources","title":"Implementation and Testing Deep Dive","url":"resources/implementation_deep_dive.html","content":"On This Page Standards Development Deep Dive Deep Dive into Implementation and Testing Tailored for technical systems developers and test leaders The goal of implementation and testing is to ensure that the developed IG Implementation Guide is translated into real world software and that this software provides value to end users To achieve this the IG developers often need to coordinate with workflow subject matter experts end users and software vendors to develop open source demonstration software including reference implementations and develop testing tools to support software adoption These resources will help speed the implementation process guide developers in adapting the software to real world instances and excite end users about the potential benefits of the community s use case Here we will walk through the development processes identifying common readily available free tools that the community can use to manage test and update the community s software Software Development Lifecycle SDLC The SDLC guides software through key steps in the development process Requirement gathering Software Design Coding Testing Deployment Maintenance and Support While software vendors will oversee this process when they adapt the community s IG for local instances of the IG software the community will need to follow this process for any of its open source software such as reference implementations or testing tools This discussion provides a detailed overview of the process and methodologies waterfall agile and others used to guide software development teams through the SDLC phases Development Recommendations Requirements Gathering See the Use Cases Planning page for guidance on requirement gathering Software Design Software design typically encompasses both the function of the software and the user interface However what end users see and how they interact with the data is typically the purview of software vendors As such discussions on the community s role in software design focus on the design of standardized data exchange and IG development See the Standards Development section and the associated Standards Development Deep Dive for guidance on IG development Coding Development Environment It is strongly recommended that the community develop open source software within an environment that allows a team of developers to effectively manage the code Key personnel like developers can and often do change over the course of the project As a result it is critical that there is a single repository for the community s code ideally one that can be made public when software is ready for release There are many options for code management and software repositories the most common repository for open source projects is GitHub To ensure that developers can work collaboratively yet independently it is also recommended that they use project management software such as Trello Jira or Microsoft Teams to track development goals and resolve bug fixes in a timely manner FHIR Artifacts A common starting point for many looking to jumpstart their development is leveraging existing FHIR software artifacts such as the HAPI FHIR software which provides working JAVA software for many basic FHIR resources HAPI FHIR HL7 s Confluence page and other FHIR open source repositories provide basic FHIR software that can be adapted for the community s purposes Testing Software testing can be broken down into three software states as described in the Implementation Testing section Initial testing Initial development and testing stage conducted by developers Prototyping second round testing conducted with willing potential end users Real world implementation implementation and testing of instances of software within live software systems using real world workflows and data The first two states are the primary focus of community software development The final state real world implementation relies on community partnerships with software vendors or healthcare organizations to implement instances of software within local systems Discussions should focus on the community s role in initial testing and prototyping and leave real world implementation decisions to software vendors It is vital to develop testing tools for the development team and the community to ensure that the IG and associated implementations function as intended Properly developed IG testing tools can facilitate uniform adoption of the community s IG standards and simplify individual implementations by helping developers identify issues with their software or with the IG One tool that can be adapted to test the community s IG is the Inferno testing toolkit which is widely used within the FHIR community to test numerous IGs and by the Assistant Secretary for Technology Policy Office of the National Coordinator ASTP ONC to verify EHRs meet certification requirements for interoperability Another testing tool option is AEGIS Touchstone a commercial testing framework that is also widely used across the FHIR community Initial Testing Much of the development and testing strategy will rely on developers coordinating with use case subject matter experts One critical need in this stage of testing is for accurate synthetic patients to test workflows To avoid the time consuming monotonous process of manually creating test patients developers should use software to generate synthetic patients like Synthea Synthea is widely use by open source medical development communities at Connectathons and in private industry because it can generate populations of realistic patients with medical data such as medications allergies conditions and clinical notes For more information on Synthea s current capabilities and instructions for generating patient data see Synthea s GitHub page for more details Prototyping To both guide community members in their individual implementations and demonstrate the software to end users the community should develop an open source demo otherwise known as a reference implementation of their IG A reference implementation is a system agnostic implementation of an IG that serves as an idealized representation of how the data exchange should function Often it is a simple client server data exchange with a few workflow examples to demonstrate software functionality and utility FHIR IG creators use reference implementations to test and get feedback from both developers and end users in dedicated implementation feedback sessions and during Connectathons HL7 maintains an instance of the HAPI FHIR server for everyone to use It should be noted however that the public HAPI FHIR server has millions of FHIR resource instances and can be heavily loaded particularly during Connectathons Since these resource instances are public testers should never use real patient data on the HAPI FHIR servers or any other open access environment Finally because of the large testing community using the HL7 HAPI FHIR server HL7 may occasionally purge test data to ensure continued server functionality for all HealthIT gov also provides a FHIR Sandbox that includes FHIR R4 servers and the Inferno testing tool HL7 and Logica Health provide free services for developing SMART on FHIR apps graphical front ends Electronic Health Record EHR simulators and OAuth authentication support In this stage of development the Inferno testing toolkit and AEGIS Touchstone as described above are also great tools for testing throughout this stage Real world Testing There is an overlap between real world testing and deployment as real world testing deploys software to local systems The goal of this stage is to verify the efficacy and efficiency of the community s software identify any lingering issues with IG development and gather feedback and prepare the community for larger scale implementations This step is largely overseen by software vendors who are best equipped to make implementation and testing decisions within their software systems Deployment See the Adoption subsection of Adoption Value for high level guidance on promoting adoption of software Maintenance and Support Software Versioning There is one constant in life change FHIR its underlying standards security protocols and the community s IG will all have regular updates some of which introduce major changes to ensure continual improvement and refinement of data exchange processes When creating software development plans it is a necessity to have a well established version control process within GitHub or whatever code repository management software the community chooses to use See this article for specific recommendations and guidance on maintaining version control for the community s software releases Over time the HL7 community has developed multiple versions of FHIR profiles including the foundation for all United States based FHIR Implementation Guides US Core HL7 releases new US Core versions regularly often every year and regulations are being proposed to require a minimum version of US Core that certified medical software vendors must use HL7 is creating draft guidance on how to navigate how IGs can support multiple versions of US Core"},{"id":3,"doc":"Resources","title":"Roles","url":"resources/roles.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources By project role Standards Development Deep Dive Implementation Deep Dive About Back to top Playbook Content by Role The most important Playbook sections recommended for particular types of experts on a standards focused project team Available Roles The Playbook aims to be valuable to a range of organizations and people interested in creating implementing and using health data standards A potentially large number of roles has been consolidated into the following three groups Leadership Clinical Subject Matter Experts Technical Experts For individuals in any particular role there certainly could be value to reviewing also the content recommended for other roles Leadership Important content for people in a leadership role such as specialty and Use Case Champions potential participants in governance organizational executives program and project managers task leads funding organization leaders and similar positions Recommended reading is focused on the executive level description of the tracks summarized in the Introduction plus other key executive content Key Playbook Sections Introduction Getting Started Community Building Use Cases Planning Standards Development Implementation Testing Adoption Value Case Studies Clinical SMEs Important content for people in a clinical or specialty subject matter expert role such as patients doctors nurses health technicians researchers health terminologists clinical experts from vendors and or payers and similar positions Clinical SMEs who may also help to translate health requirements into FHIR IGs may also find the Technical Experts useful Key Playbook Sections Introduction Use Cases Planning Standards Development Overview Clinical Requirements Deep Dive Adoption Value Case Studies Technical Experts Important content for people in a technical expert role such as data modelers terminologists informaticists FHIR Implementation Guide developers software developers designers testers HL7 participants and similar positions Key Playbook Sections Introduction Standards Design Principles Standards Development Overview FHIR IG Development Deep Dive Standardization in HL7 Implementation Testing"},{"id":4,"doc":null,"title":"Resources","url":"resources/index.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources By project role Standards Development Deep Dive Implementation Deep Dive About Back to top Resources On this Resource page you ll find the MITRE Health Data Interoperability Playbook sections recommended for people in particular roles lower level details on particular topics and links related to the tools tracks and Case Studies Explore By Role The most important Playbook sections recommended for particular experts on a standards focused project team Playbook Content for Particular Roles Technical Deep Dives Detailed Playbook tracks for clinical subject matter experts standards developers and systems implementers Standards Development Technical Deep Dive Implementation Testing Deep Dive Tools Resources that new specialty standards initiatives can use for more efficient work Playbook Checklist of the most important steps across all five Tracks download Community charter template download Role and resource planning speadsheet download Data Dictionary Template spreadsheet download SVG Tool used for creating interactive diagrams like the mCODE conceptual data model diagram Links to External Resources Key References Five Tracks Community Building Questions to Address Before Getting Started CodeX HL7 FHIR Accelerator Community CodeX HL7 Membership List CodeX Membership Options CodeX Governance Use Cases Planning CodeX Use Case Development Guidelines CodeX Use Cases Plans and Progress Standards Development Overview and Technical Deep Dive CodeX Standards Design Principles Video tutorial on the development of mCODE May Terry MITRE Nov 2023 2 hr 33 min Office of the National Coordinator for Health Information Technology ONC Health Level Seven HL7 HL7 Essentials Understanding the Standards Process FHIR Implementation Guide Process Flow Fast Healthcare Interoperability Resources FHIR United States Core Data for Interoperability USCDI USCDI specialty supplements to USCDI US Core FHIR Implementation Guide Health Information Coding Systems Health Information Terminology Standards FHIR Shorthand FSH Language for creating FHIR IGs FSH School Tutorial Learn to FSH A friendly introduction to FHIR Shorthand Video minimal Common Oncology Data Elements mCODE FHIR Implementation Guide Implementation Testing CodeX Trial Matching Use Case Phase 1 pilot report More links coming soon Adoption Value Stakeholder Specific Value Propositions White House Cancer Moonshot leveraging mCODE OSTP and ARPA H noted CodeX as an important partner in strengthening the nation s clinical trial infrastructure President s Cancer Panel noted the importance of mCODE in their recommendations for NCI s National Cancer Plan CMS using mCODE in their Enhancing Oncology Model FDA championing CodeX REMS Integration Use Case CDC s use of mCODE for Central Cancer Registry Reporting IG ONC s US Core Data for Interoperability USCDI Cancer is aligned with mCODE ONC included select mCODE data elements in their USCDI proposed Quality Data Element List Key References Case Studies mCODE Standard and CodeX Community Improving Cancer Data Interoperability The Promise of the Minimal Common Oncology Data Elements mCODE Initiative Osterman et al JCO Clinical Cancer Informatics Journal Nov 2020 Unlocking the promise of learning from everyone with cancer Schnitzer STAT Feb 2023 2019 Cancer Data Summit Getting Started with mCODE Latest mCODE FHIR IG CodeX HL7 FHIR Accelerator Community CodeX HL7 Membership List CodeX Membership Options CodeX Governance CodeX Use Case Development Guidelines CodeX Use Cases CodeX Standards Design Principles CodeX Radiation Therapy Treatment Data Use Case Radiation Therapy Treatment Data Use Case CodeX Page Minimum Data Elements for Radiation Oncology An American Society for Radiation Oncology Consensus Paper Hayman et al 2019 Operational Ontology for Oncology O3 A Professional Society Based Multistakeholder Consensus Driven Informatics Standard Supporting Clinical and Research Use of Real World Data From Patients Treated for Cancer May et al et al 2023 PACIO Project PACIO Project Overview PACIO Project Charter PACIO Project Website HL7 Confluence Page for the PACIO Project Use Cases Dashboard Meeting Index YouTube Channel FHIR Implementation Guides Personal Functioning and Engagement Implementation Guide GitHub Repository Advance Directives Interoperability Implementation Guide GitHub Repository Re assessment Timepoints Implementation Guide GitHub Repository Standardized Medication Profile Implementation Guide GitHub Repository Transitions of Care Coming soon GitHub Repositories PACIO Project HL7 Reference Implementation Sample Data Prev Case Studies"},{"id":5,"doc":null,"title":null,"url":"solutions/index.html","content":"Solutions"},{"id":6,"doc":"Playbook","title":"Implementation \u0026 Testing","url":"playbook/implementation.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Implement into Systems Test Pilot Feedback Track 5 Adoption Value Case Studies Resources About Back to top Track 4 Implementation Testing Health data standards must be implemented into software systems and workflows to provide a new or enhanced potentially valuable function in the health ecosystem Assessing the potential for real value requires testing including pilots in increasingly realistic settings Both implementation and testing are necessary for each use case concept workflow standards and or software There are other significant biproducts of this Implementation Testing track It is both an opportunity to ensure the necessary community members are actively involved within increasingly realistic environments and to attract new organizations by demonstrating value For Implementation Testing to progress effectively activities and necessary resources must be included thoughtfully in the use case plans and prepared for as the use case initiative moves forward The rest of this section covers experience gained in a Implementation b Testing and c Feedback on the previously discussed Use Case Planning and Standards Development tracks Implement FHIR IG s into Systems and Workflows Every use case requires implementing at least part of a FHIR IG into software to support generally new aspects of the envisioned workflow to be piloted It s highly recommended to engage market leading software vendors in the specialty space Vendors typically have prior experience testing a customer base that may be interested in new approaches and credibility that will attract others Candidate vendors should be engaged in the community and committed to implement and test and more as early in the use case project as possible If in the early phases engaging leading vendors is not possible implementation into prototypes and or testing software may be a satisfactory first step to allow useful assessments Questions that should be addressed during Implementation include Is the IG understandable based on technical specifications and documentation Is the IG implementable Is the system within which the IG is implemented consistent and interoperable with other systems with which data exchange would be needed Is the workflow represented within the use case and IG realistic and consistent from the developer perspective will also need user input during testing In all cases it s critical to receive specific comments and recommendations for change that can be taken back to the FHIR IG and the use case team so that adjustments can be considered adjustments that could be very helpful before testing becomes intense Test and Pilot Testing and pilots within use cases tend to start simply and then ramp up to as realistic a scenario as possible via multiple phases Testing of the implemented IG should start as early as possible even if on a subset of the future functionality The following table is a simplified set of testing axes that aim for a higher degree of realistic challenges from the top of the table to the bottom A particular test or pilot might combine components from different rows and not just across a single row Example options for elements of system testing that aim for a higher degree realistic challenges from the top of the table to the bottom Difficulty Use Case Workflow Software Data Participants Environment Synthea is an open source synthetic patient generator With no cost and no restrictions Synthea has empowered multiple CodeX pilots as well as testing and research around the world Lower 1 data element via 1 exchange in the workflow Simple test scripts Synthetic data Developers Developer s computers Higher More elements and exchanges Prototypes of needed components of future software systems De identified data Some developers and intended users Connectathons with multiple organizations Highest and Most Realistic All required data elements via all envisioned exchanges in the workflow Software systems intended for deployment and adoption Real patient data Envisioned end users actors from multiple entities of each type of organization required by the workflow Full scale real world pilots within the envisioned organizations e g health system lab Likely includes some testing sandboxes in those organizations Note that the use of real patient data bottom row involves patient and institutional consent appropriate privacy and security protections and should be planned for many months before testing aims to start Early testing provides early feedback and engages key community members in activities that bring the use case concept and IG closer to life However CodeX use cases have found it useful to start with relatively simple tests that can be run 6 12 months after the start of the project including components similar to the first row in the table above Over time CodeX use cases typically ramp up through increasingly ambitious tests to real world pilots including components similar to the bottom row e g demonstrating the full use case workflow using software systems intended for sale or otherwise deployed using real patient data driven by the intended users and within many organizations across which the future use case is planned to operate See the Radiation Therapy Treatment Data Case Study for a good example of planning and ramping up of testing Obviously these real world pilots require substantial planning commitment preparation and legal regulatory steps well in advance of the execution of the pilot This advanced planning is particularly important for testing within real healthcare settings working with real patients and using real patient data For each of the tests and pilots considerations typically include the elements below These elements should be nearly finalized when initial planning is complete especially the commitment of the necessary resources Objectives What improvements in health care and research will the use case provide e g What will be made better faster less expensive more accessible Test Configuration What parts of the use case workflow are being tested and where are they being tested Resources Skill sets e g project management clinical technical logistical legal operational and other skills Software e g EHRs specialty systems payer systems and others Facilities e g health system labs homes registries and others Funding e g for facilities and expertise Success What metrics are available to assess current capabilities What level of improvement will be measured during the test How will success be measured Feedback to Update Previous Work As Needed Even early phase pilots can provide valuable feedback on how implementable the IG is in software the usability of the updated systems and the costs human burden and potential benefits of the new workflow Both implementation and testing can surface the need for updates to the use case concept workflow standards and or software A test or pilot may need to be repeated once these updates are agreed and implemented Prev Standards Development Next Adoption Value"},{"id":7,"doc":"Playbook","title":"Standards Development","url":"playbook/standards.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Clinical Requirements FHIR IG Development HL7 Standardization Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Track 3 Standards Development A Common Language for Better Health Effective communication allows clinicians and patients to collaborate and ensure better health outcomes To communicate effectively all stakeholders in the health landscape need a common language and the same is true for associated data systems Unfortunately too often data systems are siloed with their own local dialects of data unable to easily communicate with other systems without time consuming data translation efforts To improve data communications and ultimately patient care development of data standards guiding the collection storage sharing and use is necessary The discussion on this page focuses primarily on standards around data sharing which may or may not also be how data is stored This allows clinicians patients researchers payers public health and software systems unambiguously understand and communicate every piece of data to other entities within the healthcare ecosystem The following graphic illustrates key steps that are necessary and or useful in developing and publishing a quality HL7 standard FHIR Implementation Guide This process is agile thus the cycles representing steps with iterations and interactions between each cycle Key steps needed to develop an HL7 standard FHIR Implementation Guide To develop clear standards for data communication projects need three things Clinical Requirements The target product is a data dictionary a database documenting a minimal agreed set of clinical data elements necessary to complete the use case s workflow The data dictionary includes the origin of data criticality to the workflow relationships between data elements and data format FHIR Implementation Guide IG Development A FHIR IG is an instruction manual for developers on how to send and receive the data necessary to conduct the use case built from the data dictionary HL7 Standardization Health Level Seven HL7 has governed medical interoperability standards since 1987 HL7 standardization of proposed Implementation Guides is key to gaining acceptance within the larger medical community government oversight agencies and software vendors Implementers could use IGs that are not HL7 standards however they would be less likely to gain widespread adoption This page provides an executive overview intended for leadership of the standards development approach leveraged by MITRE in the CodeX HL7 FHIR Accelerator and other projects Of course much of the standards development and implementation work will fall to clinical and technical subject matter experts Targeted guidance for these experts can be found on the Resources page and on the Technical Deep Dive into FHIR Based Standards Development page These pages also include Video tutorial on the development of mCODE More general tutorials on FHIR interoperability standards Role of United States Core Data for Interoperability USCDI and USCDI in data Interoperability Guides for writing IGs including tutorials on FHIR Shorthand FSH Guidance on when to reuse vs create FHIR artifacts such as profiles and extensions The standards development process can be lengthy Even seemingly small proposals could take many months to fully progress to standardization then implementation in software adoption and value A clear understanding of topics presented here can facilitate work towards the ultimate goal of working impactful specialty software To further speed progress it is recommended that Community focus on the minimum set of necessary data elements This narrow focus allows all aspects of software development use case planning interoperability standards development and implementation and testing to be completed sooner than larger efforts With software and standards developed faster the benefits to the larger Community can be demonstrated sooner Standards and software can always be refined and updated to include additional data and functionality later There are several standards for data exchange within the healthcare ecosystem It is recommended that implementors use the latest data exchange standard FHIR though very rarely other domain specific interoperability standards may be needed Information on for technical experts FHIR data exchange FHIR IG development tools and processes and other data standards used in this space can be found on the Resources page and on the Technical Deep Dive into FHIR Based Standards Development CodeX and mCODE both utilized FHIR throughout their processes as a result the processes described below are directly applicable to FHIR data exchange processes Clinical Requirements Information Needs and Data Dictionary Establishing clinical requirements requires converting clinical concepts into discrete data elements to enable standardization of capture and transport of data To establish these requirements the community s clinical experts will need to develop a data dictionary based on the minimum set of data elements necessary to meet the workflow needs of the use case To streamline the development it is recommended that the clinical requirement team have A well respected chair or co chairs to guide the team A team of 5 20 subject matter experts whose backgrounds cover the necessary clinical expertise for the Use Case To ensure that viewpoints are not overlooked it is recommended that the team represent a diverse set of experts across patient doctor nurse technician informatician researchers software vendors and payers At least one objective moderator to guide discussion and align diverse views One or more experts have previous experience in clinical data capture analysis and data dictionary development One or more experts familiar with interoperability standards such as United States Core Data for Interoperability USCDI USCDI and US FHIR Core profiles to ensure proposed data formats match generally accepted formats used in the wider medical community One or more experts involved in the use case development process Tools and techniques for aligning diverse expert opinions to build a consensus across the panel and the larger specialty Community Use familiar terminology and medical terms when building the data dictionary Knowledge of similar use cases and data exchange needs so that the panel s work can be easily built upon and harmonized with external projects A group charter outlining scope timelines decision processes and other key aspects for clinical requirement development A sample charter can be found on the Resources page downloadable from here Follow the Design Principles Further details for clinical experts can be found in the Clinical Requirements Deep Dive resource section of this site FHIR IG Development Specialty FHIR Data Communication Standards Once the clinical subject matter expert group has a draft data dictionary work can begin with incorporating the clinical information into one or more IG s The IG development and HL7 standards approval processes are technical requiring a FHIR IG development team of interoperability experts to complement the clinical requirements expert team It is recommended that the interoperability team have A well respected chair or co chairs to guide the team A team of 3 10 technical subject matter experts also have an appreciation for the Use Case To ensure that viewpoints are not overlooked it is recommended that the panel is a diverse set of experts including data modelers FHIR Implementation Guide developers terminologists system developers informaticists software implementors and clinical specialty experts At least one objective moderator to guide discussion and align diverse views Two or more experts familiar with the FHIR data exchange and standards including USCDI USCDI and US FHIR Core profiles to ensure proposed data formats match generally accepted formats used in the wider medical community One of these experts should be familiar with FHIR IG development processes including FHIR Shorthand FHIR profiles and extensions and similar IG development efforts within HL7 At least one implementor who can guide IG development efforts to enable streamlined software creation and testing Tools and techniques for aligning diverse expert opinions to build a consensus across the panel and the larger specialty Community Knowledge of similar development efforts within HL7 to enable collaboration and harmonization of efforts with external projects Knowledge of similar use cases and data exchange needs so that the panel s work can be easily built upon and harmonized with external projects A group charter outlining scope timelines decision processes and other key aspects for FHIR IG development A sample charter can be found on the Resources page downloadable from here Follow the Design Principles As noted the clinical expert team needs to work in tandem with the IG development team to ensure the clinical information needs are captured properly in the FHIR IG that the FHIR IG is implementable in systems and processes Each group needs feedback from the other to successfully build and implement specialty data exchange software To guide implementation developing a logical model representing the data dictionary is needed The static graphic below is a representation of mCODE s version 3 called Standard for Trial Use or STU 3 conceptual model published in 2023 Conceptual models are notional loosely represent the actual FHIR model enable clinical and other SMEs to more easily understand the context and use of elements and illustrate how data elements relate to each other Visit the latest version of the mCODE FHIR IG and explore an interactive version of this graphic and dive into the details of this mCODE concept model Example conceptual modeling diagram for mCODE STU 3 2023 draw io was used to create the mCODE modeling diagram Framework for FHIR Implementation Guide Development A specialty should aim for a single core IG that represents the minimal clinical requirements for a set of Use Cases concepts that are common within the specialty The mCODE FHIR IG is an example of a core IG The core IG can be appended and improved as Use Cases are executed Supplemental IGs can be built when new data requirements are not considered core but important for smaller Communities and or edge applications The community s specialty interests may not be well represented in existing FHIR profiles and standard data elements similar to the terminology challenges encountered during the data dictionary development In these cases existing FHIR artifacts including profiles and extensions may need to be developed or updated to better support the community s data needs It is critical that specialty communities minimize changes and modification to existing FHIR artifacts to maintain consistency within the larger healthcare data exchange community This helps ensure the final IG and associated software can be more easily accepted and adopted across all healthcare domains During the IG development process and after updates to the IG are common Updates to the IG could be motivated by updates to underlying standards e g new FHIR versions new USCDI UCSDI versions US Core FHIR profile updates terminology code system updates and others government mandates and regulation changes and shifting changes in need functionality and technology Care should be taken to plan long term upgrade processes to ensure the IG and associated software can be adapted to changing needs and functionality requirements Further HL7 has established processes for IG updates becoming more restrictive as the IG meets standardization milestones It will be necessary to have a system to organize prioritize and address requests for changes and other comments during the IG development processes Questions for Planning FHIR IG Development Are there related external FHIR IG initiatives Are there projects being driven by others in government and or industry that need to be reviewed consulted and or partnered with What existing FHIR resources and profiles best fit the data model What existing resources and profiles best match the required data elements in the data model What existing resources and profiles result in the fewest FHIR extensions that are needed What existing FHIR resources and profiles allow for use of the necessary terminologies Do the selected FHIR resources and profiles require data elements that may not be present in an exchange What FHIR profiles must be created Profiles are created when further specifications extensions or constraints are needed on a FHIR base resource or an existing dependent FHIR profile What FHIR extensions are needed Extensions are used to add data elements that may be missing in FHIR resources and profiles to accommodate a business need What existing resources and profiles need to be extended to support the required data elements in the data model What documentation is needed by senior managers and implementers to understand and effectively implement How will the data be accessed What requirements are needed for data querying and access Change management What version control system will be used Further details for technical experts can be found in the FHIR Implementation Guide IG Development Deep Dive resource section of this site HL7 Standardization and Approval Path Towards Wider Standards Adoption To gain wider acceptance Implementation Guides need formal approval from the healthcare interoperability standards body HL7 As the IG is drafted the IG development team needs to begin processes for eventual HL7 community balloting and approval of the IG Often the sooner these processes are started the smoother the HL7 standards processes help ensure harmonization of IG development efforts across projects and communities This said the standards process is often lengthy and can take many months to over a year from start to publication of an interoperability standard Specific details about the HL7 process and FHIR development in general can be found in the resources section HL7 standards process timeline for new FHIR IGs It is recommended that the IG development team used to develop the FHIR IG also guide the IG through the HL7 standards processes To better navigate HL7 processes the IG team should Have an advisor who has thorough knowledge of HL7 processes and standardization schedule Coordinate with HL7 and HL7 work groups associated with the specialty domain Build HL7 standardization throughout the development processes started with the use case development Allow plenty of time to go through the process Build a relationship and coordinate with HL7 Work Groups Work Groups may not have deep expertise in individual health specialties However they will know HL7 standards and processes and may be aware of IG work past current and planned that is similar Support from the HL7 Work Group will help smooth the IG standardization process It is critical that any proposed new FHIR artifacts such as FHIR profiles or extensions be discussed with HL7 and the appropriate HL7 Work Group They can help harmonize FHIR profiles and extensions to better address both the specialty s and the wider community s needs and interest Utilize existing HL7 community to coordinate and harmonize work especially HL7 FHIR Accelerators who will be knowledgeable and connected closely with HL7 people and processes and ongoing work within their domain As stated previously HL7 IG standardization and approval mark the gateway towards broader acceptance of the developing IG and the beginning of implementation and testing processes Again all the development steps use case planning interoperability standards development and implementation and testing are cyclic and rely on feedback from other steps to produce valuable software for the specialty community Further details for standards experts can be found in the HL7 Standardization Deep Dive resource section of this site Prev Use Cases Planning Next Implementation Testing"},{"id":8,"doc":"Playbook","title":"Design Principles","url":"playbook/design_principles.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Design Principles Below are principles that have guided the CodeX HL7 FHIR Accelerator Community and in the design planning development testing adoption and value of FHIR based data standards including mCODE These principles guide and are elaborated upon in the Playbook Tracks and Case Studies If additional specialties follow these principles the resulting standards are more likely to be developed efficiently to be compatible across specialties as part of each patient s life time health to be adopted in practice and to provide value for patients and all stakeholders A dedicated and diverse community is essential to the design and execution of a health data standards project Each use case needs committed representation from all stakeholders needed to drive the use case e g patients providers health systems Gov t agencies vendors payers and others Compelling use cases are the foundation upon which solutions are designed and driven Define each use case as a project that addresses a single important narrowly focused problem Build a use case plan that is end to end including the scope resources data requirements and a pragmatic strategy for how standards will be adopted and provide value in the real world Prioritize use cases that address salient challenges However start with simpler not simple use cases that have commitment from all the community members needed to succeed Prioritize use cases that improve collection and sharing of quality core standardized data related to patient care and outcomes should be the top priority Clinical information requirements are a first priority for each use case Build consensus within a diverse team of clinical experts on the minimal data requirements needed to address core use case requirements Define clinical requirements as discrete observations and actions e g patient birth date 11 04 1989 vs patient is 34 years old If previous work in the space exists seek to work with the other initiatives and adapt their work rather than re do How clinical requirements are represented in FHIR Implementation Guides IG influence their useability and their interoperability across specialties Develop first a single core IG that represents the minimal clinical requirements for small set of use cases concepts common within the specialty This core IG can be improved upon as use cases are executed and supplemented within related IGs when data requirements are important for just a small subset of the community Leverage government backed interoperability standards whenever possible e g United States Core Data for Interoperability USCDI Fast Healthcare Interoperability Resources FHIR US Core FHIR Implementation Guide for core patient data and others Leverage the available tools see the Resources page for modeling and IG development to produce higher quality FHIR IGs that are more coherent across specialties use cases and projects Leverage global code systems and terminology standards e g LOINC SNOMED CT CPT and other systems Standardize work through an open royalty free health standards development organization preferably Health Level Seven HL7 Build use cases within a vision of a coherent lifetime Standard Health Record for every patient Enable standardized data to become the basis for every patient s health record and standard of care Empower patients to be engaged with and have control of their health data Collect patient data once generally around the encounter and reuse it for future patient encounters and multiple use cases Enable consistent representation of health data concepts that could be used across specialties subspecialties and use cases Prev Before Starting Next Community Building"},{"id":9,"doc":null,"title":"Adoption \u0026 Value","url":"playbook/adoption.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Adoption Value Case Studies Resources About Back to top Track 5 Adoption Value Adoption in the real world is best driven by understanding the market forces that will drive new standards based solutions including user demand government mandates and the promise of improved care and research Value in the real world depends on the level of adoption and the quality of the underlying new standards based processes and systems being adopted Once work has progressed to the adoption planning phase the use case team should also have a clear view even before the first system or process has been deployed with new standards whether the prospects for community adoption and value are strong or not A variety of resources are useful in driving adoption and measuring value Use case champions and the organizations they represent e g medical societies providers vendors regulators and others are key as they can influence communities of potential adopters and understand and leverage market forces To support champions publication and promotion peer reviewed papers popular press articles conference presentations of results is useful in establishing use case value for healthcare and research Adoption in the Real World As noted above all the previous tracks discussed will help establish the level and drivers of demand for the standards based use case It is important to leverage the champions and community to communicate the value demonstrated during pilots Pilot successes contribute to the following factors that spur adoption Real world pilots of the new standards based solutions demonstrate real world value e g increased benefits and speed decreased costs and burden Customers e g patients providers payers researchers and others increasingly demand standards based solutions Government regulations and rules increasingly require standards based solutions Vendors will seek competitive advantage through implementing standards While it is important to maximize these adoption drivers a subset of these drivers can be sufficient to spur the adoption of new standards and interoperable solutions A simplified illustration of the above market forces and others is shown below Push forces result from stakeholders requiring the use of new standards Pull forces result from stakeholders requesting products that benefit from standards based solutions A specialty specific version of this graphic could be created for specialty Communities See also the stakeholder specific Value Propositions on the community Building page Diagram showing forces that can demand pull and require push data standards The better these forces can be aligned the more effectively a project can move and have impact Value in the Real World When driving adoption of new standards and new standards based workflows it is important to measure the costs and benefits throughout the new systems Such assessments will help improve the standards workflow design and user interfaces Further when results are positive these assessments will help accelerate demand adoption and value in an enlarging community of users See the Delivering Value and Growth and Impact sections of the mCODE Standard and CodeX Community Case Study for examples of the measurement and communication of value for the mCODE standard and associated use cases NOTE Add more content here Prev Implementation Testing Next Case Studies"},{"id":10,"doc":"Playbook","title":"Community Building","url":"playbook/community.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Champions Governance Growth Value Propositions Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Track 1 Community Building Gathering the right organizations and people is the most challenging foundational and necessary experience for success Most people reviewing this site understand that enabling true health data interoperability is as much a social challenge as it is a medical or technical challenge It takes people who share a vision and mission who can align diverse views of how to get there and who will invest the resources needed to change the status quo and gain sustainable growth and momentum Actions that CodeX has found indispensable include a engaging champions b establishing governance c growing the community and d communicating value propositions that enable growth These actions are expanded upon below Champions An essential first step when starting a new specialty initiative or starting a new use case within that initiative is to identify champions In CodeX successful champions are organizations and individuals that Commit to leading the initiative and or use case Know the challenges and opportunities leading to potential use cases organizations people and related initiatives within the larger specialty community Command the attention of a larger community and can influence future users and stakeholders to engage Motivate implementation of new standards into vendor solutions Motivate the changes in health processes needed to use and benefit from of the standards based systems Attract the resources needed to succeed Drive one or more key tracks of the initiative and or use case Community Building Use Case Planning Standards Development Implementation Testing Adoption Value Champions and all who actively participate will most likely understand the challenges for which standards based data interoperability provide substantial benefits These participants will develop a shared vision for a future where patient data can be collected once and then used with no or little manipulation for many use cases around patient care research and other applications It s clear that champions have significant responsibilities But they also realize future benefits in terms of prioritizing use cases defining direction achieving objectives and ultimately improving health care and research within their organizations and across the landscape Large medical professional societies and government organizations have been the most frequent CodeX use case champions but other stakeholders have also been effective champions The founding champions for the overall CodeX initiative which started by addressing challenges in oncology were American Society of Clinical Oncology ASCO with reach to all oncologists and centers and The MITRE Corporation with deep expertise in convening FHIR standards and systems engineering Governance A governance framework is important for any initiative involving many organizations often with divergent interests and views An agreed generally by member organizations and documented governance framework ensures that the community hears and understands participants views and interests Governance delineates how and by whom decisions are taken Example decisions include updates to the governance structure itself Membership structure and fees resolving conflicts administrative support starting new use case work and providing funding and resources to projects in special cases when the community can t provide funding and resources The CodeX Accelerator provides the governance for use cases around cancer and the mCODE standard cardiovascular disease and genomics so far Other governance schemes are possible but would require more effort to start and to coordinate effectively across specialties The graphic below captures the CodeX governance structure as of 2024 The tiered structure offers participation at different levels of responsibility and time commitment Details of the current CodeX governance scheme can be found on their website Block diagram showing structure of CodeX governance including Steering Committee Operating Committee Use Case Projects and Community of Practice Regarding CodeX Governance The elected steering committee makes major decisions including governance structure use cases funding decisions and moving projects into the execution stage The vast majority of all the community s volunteer resources are invested in the use case projects The community of practice near the bottom of the graphic is open to the public and has been an effective feeder of new organizations and talents into CodeX membership and use cases One key factor in CodeX s oncology work is the mCODE Executive Committee and its Technical Review Group External Expert Groups circle on right These groups provide clinical subject matter expertise across oncology fields and ensure the mCODE FHIR Implementation Guide is based on the most credible and recent clinical knowledge A strategy for sustaining work is important Communities cannot achieve success overnight and cannot continue to achieve success without sustained resourcing In CodeX participants provide the range of skills and support necessary to drive each use case forward Funding for overarching program management near the top of the graphic above comes largely from membership fees plus some volunteer effort Based on 2024 CodeX Membership view current membership list and Membership fee structure view current fee structure Membership fees provided about 800K USD for 2024 Community Growth To advance use cases the community needs a variety of organizations and skillsets to establish an overarching vision of adoption and real world value Thus the community must be grown such that there are participants with direct experience related to each of the envisioned roles in the specialty initiative and its use cases For example in the CodeX Radiation Therapy Case Study the team included participants from radiation therapy societies health systems payers and vendors Skillsets included clinical practice radiation oncologists radiation physicists software engineers informaticists FHIR experts HL7 standards process experts and more Getting the right set of people together at the right times in the process can be challenging It is ideal to have redundancy among these roles to bring in a diversity of experience and to provide forward momentum as participants cycle on and off the project Champion leadership and collaboration as a committed and focused team is critical The good news is that a promising use case has the potential to attract new participants These participants appreciate the potential value of the work are willing to invest resources to realize that value and want to be at the table where decisions are made and work is executed Value Propositions To grow the community required for a standards initiative to succeed it s important to understand and communicate the value propositions for different stakeholder groups Further it s helpful to think about stakeholder value in two directions a How can the standards initiative provide value to each stakeholder group and b How can each stakeholder group provide value to the standards initiative Below are value statements looking in both directions for six stakeholder groups Providers Health Systems Associated Specialty Societies How can the standards initiative provide value to Providers Health Systems and Associated Specialty Societies The initiative s Use Cases and standards could enable better care at lower cost more accurate and complete data that can be collected and shared more readily thus improving diagnoses treatment consultations automation level of effort and expenses Shared decision making between patients and providers could be realized Valuable secondary uses of the standards based data could be realized e g quality measure reporting payer communications prior authorization procedures research and many other opportunities How can Providers Health Systems and Associated Specialty Societies provide value to the standards initiative By representing informing and convincing a broad group of clinical and administrative constituents that this initiative should be supported By committing experts who can provide deep clinical knowledge By demanding standards based solutions from their vendors By finding and providing funding Patients Associated Advocate Societies How can the standards initiative provide value to Patients and Associated Advocate Societies The initiative s Use Cases and standards could enable better patient care at lower cost more accurate and complete data that can be collected and shared more readily thus improving diagnoses treatment consultations automation level of effort and expenses A common motto of CodeX work is that every patient s journey improves all future care in addition to providing excellent care to the patient at hand Shared decision making between patients and providers could be realized How can Patients and Associated Advocate Societies provide value to the standards initiative By representing informing and convincing a broad group of patients and caregivers By providing the patient s perspective to ensure a patient centered approach is at the center of Use Cases and standards work Patients will increasingly demand the ability to aggregate share and control their health data and thus motivate standards adoption Regulators government agencies may include functions that fit into other stakeholder groups as well How can the standards initiative provide value to Regulators Standards that are developed can align with and accelerate government rules and regulations How can Regulators provide value to the standards initiative By committing experts who can provide deep regulatory knowledge By providing funding Vendors EHR and other health IT companies How can the standards initiative provide value to Vendors Vendors can help align customer interests and thus reduce their level of effort on custom implementations They can provide input to ensure standards are implementable in their systems and are consistent across specialties cost effective development and maintenance Vendors who participate actively have a first mover advantage that can drive their products to market ahead of competitors How can Vendors provide value to the standards initiative By implementing and delivering when their customers ask for products based on standards By committing experts who can provide deep technical implementation knowledge By looking across customers and across specialties and suggesting ways to develop standards to optimize implementation use and maintenance within systems By providing funding Payers How can the standards initiative provide value to Payers Easier access to necessary clinical data standardized across customers needed to make decisions Automation of processes e g prior authorization claims processing Higher quality care supported by standard data will be informed by payers who are at the forefront of pay for value approaches to care How can Payers provide value to the standards initiative Can demand the use of standards by associated health systems and vendors By committing experts who can provide deep knowledge of payer requirements By demanding standards based solutions from their vendors By providing funding Researchers How can the standards initiative provide value to Researchers More patient point of care data can be gathered and aggregated faster and with less expense for research use e g less data curation and mapping Substantially increased speed ease of execution and cost effectiveness through standardized data sharing across studies and institutions Potential funding How can Researchers provide value to the standards initiative By committing experts who can provide deep knowledge of research requirements By demanding standards based solutions from their vendors By providing funding Prev Design Principles Next Use Cases Planning"},{"id":11,"doc":"Playbook","title":"Playbook Introduction","url":"playbook/index.html","content":"Playbook Menu Intro Tracks Why Who How Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Introduction Playbook Tracks The MITRE Health Data Interoperability Playbook aims to help health communities create FHIR based data standards that provide substantial improvements to patient care and research within individual specialties and across all specialties Why Why is the Playbook being created and shared now Three primary reasons First data interoperability remains a serious impediment to better and more affordable health care Multiple recent studies demonstrate interoperability driven impediments including Average treatment delays of a month which can result from prior authorizations data sharing breakdowns It takes an average of 17 years for research to reach clinical practice It can take 3 years for public health data to be aggregated and available for broader use Nearly 1 trillion per year for healthcare administrative costs which could be reduced with more efficient standardized data exchange Second formerly disparate elements are converging to make this a prime time for other specialties to create FHIR based data standards to address challenges Patients providers payers researchers and others are realizing the need for standards that provide semantic interoperability Recent government rules and regulations are driving standards based approaches upon which specialty communities can build Vendors are working to meet customer demands and government direction delivering products increasingly based on standards CodeX and mCODE have leveraged these underpinnings from the start The third reason to share this Playbook is that MITRE has had a primary role in creating and building a Community within the CodeX HL7 FHIR Accelerator building applications using the mCODE cancer data standard and the accelerating adoption of CodeX s mCODE based use cases to address interoperability challenges in the oncology space This success has led leaders in the cardiovascular and genomics domains to start work in CodeX It has also led many additional medical specialties to ask MITRE s experts questions such as What are CodeX and mCODE What impact are CodeX and mCODE making to enable data interoperability and solve real health challenges What was your approach and its rationale How could my specialty replicate the impacts realized by CodeX and mCODE and perhaps move even faster These questions are just some of the motivations that led MITRE to consolidate and share its experience in this Playbook There are approaches in addition to MITRE s that may be useful to review Whatever approach the community follows the outcome must aim to be consistent with other specialties and in the best interest of all patients who typically need the services of multiple specialties during their lifetime MITRE s Playbook Tracks and Design Principles aim to ensure the necessary level of consistency and quality and have a track record of success Who Who is the intended audience for the Playbook The Playbook will be valuable to a range of organizations and people interested in creating and leveraging specialty health data standards to address real world challenges The Playbook should be particularly helpful for specialty leaders exploring how to replicate the CodeX model for oncology within their own specialty Specialty leaders may be motivated to work with CodeX and other specialties to speed work and increase coherency Parts of the Playbook will be useful to particular stakeholders e g patient organizations health systems specialty societies government agencies payers vendors etc and roles e g decision makers funders project managers community organizers clinical experts informaticists standards developers system engineers communications personnel etc involved in just a subset of the spectrum of all future work The Key Playbook Sections by Role provided here aims to help guide people with leadership clinical or technical responsibilities to quickly find the most relevant information for them To get the most out of the Playbook it would be helpful for leaders to have at least a high level knowledge of standards that are foundational in the Playbook United States Core Data for Interoperability USCDI Fast Healthcare Interoperability Resources FHIR US Core FHIR Implementation Guide USCDI specialty supplements to USCDI Health Information Coding Systems Health Information Terminology Standards Standards implementers should of course have a much deeper understanding of these foundations How How is this Playbook organized The Playbook is organized around the approach used by the CodeX community to drive development and value of standard FHIR Implementation Guides This approach has five tracks that overlap in time interact substantially and have been improving with experience The first graphic below is a simplified representation of the five tracks The second graphic shows a notional timeline of the overlapping and interacting tracks for a hypothetical use case In CodeX the time from the start of the work to initial adoption of a use case solution has been on the order of 3 5 years Flow diagram of the five Playbook work tracks Waterfall diagram of a notional timeline for implementing the five Playbook tracks showing that they are related and overlapping Here is a brief description of each Playbook track with a link to the more detailed page for each Community Building Community starts with leadership from committed champions who have broad reach a grasp of key challenges and potential use cases and the ability to grow the community with skilled and active participants The community must establish a fair and sustainable governance framework to enable the community to grow coordinate and work toward its goals Use Cases Planning The community must prioritize and define specific projects each including the key challenge to be addressed new work and data flows to be realized and clinical information needed Use case work must be organized and scheduled all the way through to adoption and measuring value Resources organizations champions people skills needed to succeed must be secured Specific use cases attract additional subsets of each specialty to the community Standards Development Standards development starts with compiling clinical experts minimal set of core information requirements for each use case Clinical requirements are incorporated into HL7 Fast Healthcare Interoperability Resources FHIR Implementation Guides IGs based on a set of Design Principles and standardized updated and maintained the within the Health Level Seven HL7 standards organization Implementation Testing Implementers must integrate FHIR IG s into systems and workflows These standardized systems and workflows undergo increasingly ambitious tests leading to pilots within the types of organizations that will ultimately benefit from the work Feedback from testing is used to update Planning and Standards work Testing serves to demonstrate the potential value of the work and often attracts additional participants to the community Adoption Value To have value standardized systems must be used widely in the real world Getting to this point starts by understanding during project Planning which factors will move the market Factors include user demand government mandates and the promise of improved care and research demonstrated during testing It s critical to measure such improvements in the real world to see where updates could make solutions even better quality cost time and to motivate new users to adopt Though not shown in the graphic real world use will lead to additional feedback for any or all the other tracks The above five tracks are explored in greater depth by following the links in the above list and via the Playbook Menu found on all pages Questions that a new specialty should ask themselves before embarking on the above tracks are covered on the Before Starting page A downloadable Playbook Checklist will be useful as a new specialty embarks on the work across Playbook tracks Also provided in the Playbook are Design Principles that help drive efficient and consistent standards development work These Principles when used by different specialty initiatives will also help ensure alignment between initiatives within and across specialties Case Studies show how real projects have leveraged the tracks including the history of activities outcomes and lessons that may be useful for new specialties Playbook sections recommended for people in particular roles lower level details on particular topics and links and tools related to the tracks and Case Studies can be found on the Resources page Next Before Starting"},{"id":12,"doc":"Playbook","title":"Before Starting","url":"playbook/getting_started.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Before Starting Your Project Four Questions to mostly Answer in Advance of Launching a New Specialty Standards Initiative When people from outside the oncology space learn about how the mCODE Standard and CodeX Community are revolutionizing interoperability for cancer data see the mCODE and CodeX Case Study they often ask How could we replicate this experience to improve interoperability within our specialty Other pages in this Playbook share experience aimed to help a new specialty standards initiatives deliver real value However MITRE has found that the following four questions should be asked and largely answered before treading too far into a new specialty standards initiative Each question references the Key Playbook Tracks that can be consulted for more details on how questions could be addressed The following graphic maps the four questions to be answered before starting the initiative boxes A D in green below to a notional use case timeline for the five tracks to execute once the initiative is started circles 1 5 below and explained in the Introduction Note that all four questions map to the early period of the Community Building track and three questions map to the early period of the use cases planning track Diagram showing four key questions to ask before starting work mapped to a notional timeline for the Playbook work tracks Next the four questions to answer before launching a new specialty standards initiative How can specialty community champions drive success Leadership for the specialty initiative as a whole and for each specialty use case is key to the steps below and elsewhere in the Playbook Understand specialty needs engage large constituencies collaborate with related initiatives mobilize resources and drive success Engage medical professional societies and government organizations Lead a project that grows in complexity and participation and help the community source skills and funding Establish a governance framework that facilitates communications consensus building decision making project management effort and resource distribution Key Playbook Track Community Building Which use cases will the specialty work on first Prioritize work into manageable segments to minimize initial use case complexity Each use case includes a scoped health IT or process challenge that a defines validates and or motivates improvements to underlying workflows data requirements and data standards b attracts more needed participants and skillsets into the community and c motivates demand adoption and value Ideally software collects and shares data using the same standard which can expand with and support multiple use cases CodeX Use Cases typically start with easier not easy problems and solutions around which stakeholders can more quickly align and demonstrate value for the community New specialties may find parallels in the CodeX Oncology Use Cases providing a jump start for the specialty community use case development Key Playbook Tracks Community Building Use Cases Planning What s the strategy for adoption of standards based solutions Each use case needs a pragmatic vision for how the specialty community will adopt resulting solutions into their software ecosystems and improve care and or reduce burden Community engagement of future users has proven invaluable in Codex Data users whether customers or government agencies can encourage vendors to implement community proven software solutions Key Playbook Tracks Community Building Use Cases Planning Adoption Value Are the necessary resources available to start the first use case s and deliver success Launching use cases and demonstrating solutions require specific types of organizations champions skillsets and often financing at the right times Resource needs are often less clear at the start but become increasingly clear as work is planned and accelerated Use case scope and timelines can be scaled to available resources and still be successful In CodeX rapid promising use case results generally from the early phases of a use case helped attract and justify the involvement of new organizations gather the needed skillsets and secure funding Key Playbook Tracks Community Building Use Cases Planning Prev Introduction Next Design Principles"},{"id":13,"doc":"Playbook","title":"Use Cases \u0026 Planning","url":"playbook/use_cases_planning.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning What is a Use Case Guidelines Use Case Discovery Use Case Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Track 2 Use Cases Planning Scoped use cases are critical to success A use case plan serves to document agreed scope steps schedules and resources needed to deliver solutions successfully What is a use case A use case in this context is a project that requires electronic collection storage sharing and or use of standardized data within a new well scoped workflow relative to current practice Implementation and adoption of the use case should enable measurable improvements in the health ecosystem including more effective faster and or less expensive patient care and research A specific use case provides the framework for all that comes next Thus a well scoped and compelling use case is critical for success A use case attracts the subset of the larger community who care deeply about the objectives and can drive work A use case allows Standards Development work to focus on the data elements needed to execute new systems and workflows A prototypical use case is the Radiation Therapy Treatment for Cancer Use Case This use case has worked successfully to replace inefficient sharing of documents PDF from a radiation therapy services to oncologists leveraging an mCODE based FHIR exchange of structure radiation treatment summary data This work is already deployed in real world systems improving information quality and reducing clinical burden See the Radiation Therapy Treatment Data Case Study A workflow diagram for the CodeX Radiation Therapy Treatment Data for Cancer Use Case CodeX Use Case Development Guidelines CodeX created Use Case Development Guidelines as a framework and decision process for successful use case work via three Stages Discovery Planning and Execution development implementation adoption and impact Diagram of CodeX use case development progression from Discovery to Planning to Execution stages Below are key learnings around the CodeX use case discovery and planning stages The CodeX execution experience will be referenced in the Implementation Testing and Adoption Value sections of this website Use Case Discovery Identifying and Prioritizing Potential Specialty Projects Use case discovery in CodeX generally starts with use case champions who engage and gain commitment from potential participants Together they build a list of possible use cases and work to agree on their first or next use case project based in part on the factors below New specialties should look at CodeX oncology use cases They may find that there is a parallel use case in their specialty e g for clinical trials registry reporting quality measurement prior authorization and others that cut across specialties for which previous oncology work could provide a jump start in the new specialty Modeling new specialty work after existing work could also serve to make the new effort compatible with prior efforts thus serving implementers health systems and patients well For the CodeX Program Management Office with the opportunity for input from the Steering and Operating Committees to assess the readiness of a use case to go into the CodeX Discovery Stage the following information is requested High level version of concept stakeholders do not need to be in complete agreement and alignment List of organizations and individuals committed to lead the discovery discussions and alignment List of other specific organizations across stakeholder groups that could be candidates for working the concept through discovery planning and execution By the end of the discovery stage and before moving into the planning stage a CodeX use case project has the following attributes Based on a thorough landscape analysis the proposed approach is unique and or advances the field The potential to substantially improve patient care and research within and or across specialties Shares the vision of collecting patient data once mainly to support patient care and exchanging for multiple uses Believed to be viable some risk is of course natural and acceptable Leverages clinically based FHIR Implementation Guides for automated collection and exchange of a minimal set of clinical data Leverages resources and open FHIR based API based data exchange Leverages Gov t supported frameworks including USCDI the US Core FHIR IG and others Leverages mCODE and or explores updates to mCODE and other foundational IGs May develop supplemental data elements IGs more specific to a use case Driven by the community with leadership from champions representatives from all necessary stakeholders and committed resources Expedites use case project work based on agile project plans with short phases quick results Will during the Execution stage pilot workflows and systems in real world settings that demonstrate the art of the possible and can be adopted and scaled Other considerations that MITRE has found useful to determining readiness to proceed A new specialty should consider starting with one or two less ambitious use cases based on simpler new workflows that share a minimal set of standardized data This raises the probability of success at speed and can help a new community to become a functional team Ask the right questions What s driving the need for the use case Is the need related to clinical workflow improvements research improvements new regulatory requirements cost or burden reduction and or other factors Who are the target actors e g patients physicians nurses researchers payors regulators and others Develop use case scenarios Write scenarios such that the widest group of potential participants can review and understand Create example personas for roles in the proposed workflow Cite clinical sources and other prior work Use Case Planning From Starting Work to Providing Value in the Ecosystem Once the community has prioritized a use case the next step is to develop a plan Here are considerations that CodeX documents in their Use Case Development Guidelines Problem Why are current solutions inadequate Solution What new systems and workflows are planned Identify which roles actors and standardized data are needed for each component of the solution Impact Where will the health ecosystem be substantially improved with the envisioned solution Champions Which organizations and people are committed to lead Which others are needed and where does engaging them stand Resources Which organizations and people are committed to participate actively Which others are needed and where does engaging them stand Are there additional personnel facilities and or financial resources required to succeed that are not committed yet Think about the types of resources needed over the entire project through planning development implementation testing adoption and realizing value in the real world Describe the options and plans for attaining these It can be difficult to estimate resource needs accurately especially in the early phases of a use case Note that use case scope and schedule can be adjusted to the availability of resources and still result in a successful project Provided on this site is a Role and Resource Planning speadsheet template download which should help define resource requirements and fulfillment Outside Activities Are there other consortia or other organizations outside of this use case with which the team may want to collaborate with Identify outside work that could be competitive with the current use case Schedule of Work Break the plan into phases Each phase might be 3 9 months Phase themes stories workflows objectives and development FHIR IGs software will vary One pattern that is common in CodeX is a first phase starting with exchanging synthetic data for a minimal set of data elements progressing to a phase with de identified data then a phase with real patient data Later phases include strategies for driving adoption and for measuring value in the real world Participation realism and results all become more ambitious with each new phase Specify measures of success for each phase out to at least a year or two Note risks and other issues within the plan that require additional alignment within the use case team Communication There is value to leveraging channels of communication web email lists that are public to gain attention engage outsiders and publicize progress and maintaining other channels that are private within the governing organization like CodeX or the use case team Prev Building Community Next Standards Development"},{"id":14,"doc":"Case Studies","title":"Radiation Therapy Treatment Data","url":"casestudies/radiation_therapy.html","content":"On This Page Community Building Use Cases Planning Standards Development Implementation Testing Adoption Value Back to top Case Study CodeX Radiation Therapy Treatment Data Use Case The Radiation Therapy Treatment Data RTTD Use Case is an excellent example of how a successful CodeX oncology use cases was started how it was driven what impacts it is having as of 2024 and lessons learned This should be especially valuable to a new medical specialty looking to conceive plan and execute a new project within a broader special standards initiative Community Building Key Playbook Track Community Building In March 2020 the American Society for Radiation Oncology ASTRO joined CodeX as a founding member with a proposal to standardize radiation therapy treatment summaries They suggested leveraging work published by ASTRO and others in the ldquo Minimum Data Elements for Radiation Oncology An American Society for Radiation Oncology Consensus Paper rdquo ASTRO noted that the radiation therapy community had been interested in standardizing the complex treatment data that is gathered before during and after a course of radiation therapy treatment but did not have the infrastructure or FHIR expertise to sufficiently act on this idea ASTRO joined CodeX with the vision of connecting with other industry partners leveraging the CodeX FHIR Accelerator s platform benefiting from expertise in FHIR modeling and planning the use case Nearly one year after ASTRO joined CodeX the American Association of Physicists in Medicine AAPM joined as a founding member to support this effort AAPM provided professional society expertise along with work developed by the AAPM Big Data Subcommittee i e Operational Ontology for Oncology O3 At this point the discovery phase of the CodeX Radiation Therapy Treatment Data RTTD Use Case began with the leadership and in kind support of ASTRO and AAPM which consisted of leveraging existing standards focused work and collaborating with related radiation therapy professional societies The graphic below represents the multi professional society engagement and approach that the CodeX RTTD team took to ensure existing work and expertise from leaders in the field were adopted repurposed and modified to fit within the scope of our use case The lack of data standardization within the radiation oncology community is an international issue that the below group of societies had started working toward resolving and which the CodeX RTTD team modeled in FHIR Diagram showing engagement between AAPM HL7 mCODE CodeX and other professional societies Use Cases Planning Key Playbook Track Use Cases Planning The development history for the Radiation Treatment Therapy Data Use Case is summarized the RTTD FHIR IG https hl7 org fhir us codex radiation therapy 2024May history html A summary of the use case phased plan is shown in the following graphic RTTD Use Case work ramped up to realistic pilots over a five year period Now let s dive a little deeper into the RTTD Use Case story ASTRO and AAPM with the assistance of The MITRE Corporation planned and kicked off the CodeX Radiation Therapy Treatment Data RTTD Use Case in early 2021 The team s initial objective was to identify define and model data components in an ldquo end of treatment rdquo radiation therapy RT care summary i e a summary report that could be sent to the larger oncology team once the RT course has been completed As previously mentioned the data components were informed by the Minimum Data Elements for Radiation Oncology An American Society for Radiation Oncology Consensus Paper and refined by consensus after stakeholder discussion Once the ldquo end of treatment rdquo summary modeling was completed in June 2021 the RTTD stakeholders agreed that defining components of a RT prescription and an in progress treatment summary would also be of value to the healthcare community In progress treatment summaries convey information about a patient in the midst of receiving treatment The group again leveraged the Minimum Data Elements for Radiation Oncology Consensus Paper to identify potential data requirements refined the definition of each data element via collaboration and stakeholder expertise and modeled the FHIR specifications that would ultimately be published in the CodeX RT Implementation Guide IG Standards Development Key Playbook Track Standards Development In January 2021 the RTTD Use Case approached the Integrating the Healthcare Enterprise Radiation Oncology IHE RO Exchange of Radiotherapy Summaries XRTS Work Group about aligning the data model and FHIR structures created by the RTTD team with the technical architecture and transactions being defined in the XRTS technical specification document The XRTS Work Group includes leading electronic health record EHR and radiation oncology information system ROIS vendors that consist of roughly 80 of the U S ROIS market Varian Elekta RaySearch and Epic The CodeX RTTD and XRTS teams aligned visions and began working together to develop the CodeX RT Implementation Guide and the architecture and transactions within the XRTS Profile and technical specification As a result of this collaboration radiotherapy profiles were added to mCODE STU2 i e the Radiotherapy Course Summary and Radiotherapy Volume profiles along with new value sets and extensions required to express a radiotherapy treatment summary Radiotherapy specifications beyond what was considered minimal which is a tenet of mCODE were published in the CodeX RT IG STU 1 along with details that support 1 a radiation therapy prescription and 2 in progress treatment summaries The image below depicts the profiles that fall within each portion of the radiotherapy clinical workflow Diagram showing various FHIR profiles associated with phases of radiotherapy clinical workflow Implementation Testing Key Playbook Track Implementation Testing The radiotherapy profiles and data elements were tested in December 2021 and May 2022 at IHE RO XRTS Workshops by radiation oncology information technology vendors Varian Elekta and RaySearch along with Epic an electronic health record system vendor The CodeX RTTD and IHE RO XRTS teams will continue to test the CodeX RT IG at future IHE RO XRTS Connectathons Additionally all insight and relevant feedback received from IHE RO vendor testing at Workshops and formal Connectathons will be reviewed and assessed by the CodeX RTTD Use Case team for necessary updates and changes to the RT IG Clinical modifications to the RT IG s FHIR model will also be shared with the IHE RO technical team to update the IHE RO XRTS technical specification and retested at subsequent vendor Connectathons This continuous feedback loop between the CodeX RTTD and IHE RO XRTS team is represented in the graphic below which is a critical component of this team s success Diagram showing feedback loop between CodeX and IHE RO Adoption and Value Key Playbook Track Adoption Value As of early 2024 the RTTD Use Case has accrued significant accomplishments including Adoption of mCODE RT profiles and the RT Implementation Guide in US radiation oncology information system vendors that support 80 of treatment sites Publishing the first version of the CodeX RT Implementation Guide A second version to be published in Fall 2024 Adding 275 SNOMED CT codes related to RT to the Global Patient Set which are now publicly available for international use Incorporating mCODE radiotherapy profiles in the production system of a recent version of RayCare i e RayCare 6A Realizing the official product release of Varian s ARIA FHIR API in December 2023 which includes FHIR RT profiles Targeting VA and Varian pilot to be deployed at Madison VA site in summer 2024 The pilot will test the exchange of RT FHIR profile information The CodeX RTTD and IHE RO XRTS teams are continuing to work in harmony to leverage areas of expertise and explore opportunities for advancement of this work The CodeX RTTD team is always looking for new CodeX members vendor organizations to test the Radiation Therapy Implementation Guide and pilot sites to test and assess the clinical applicability of the standard If you d like to get involved email the CodeX team"},{"id":15,"doc":"Case Studies","title":"The PACIO Project","url":"casestudies/pacio.html","content":"On This Page PACIO How it Started First Use Case Design Principles Starting the Community Building the Community Delivering Value Growth and Impact Resources Back to top Case Study The PACIO Project How it Started The PACIO Project started with a simple question How do we get post acute care PAC health data to follow the patient through transitions of care The solution was to build a community to develop and drive adoption of Fast Healthcare Interoperability Resources FHIR in post acute care data exchange standards to facilitate transitions of care and care coordination across the healthcare continuum Background Forty five percent of Medicare patients leaving acute care end up in some form of post acute care Diagram of post hospitalization acute care service utilization by Medicare patients in 2014 The post acute care population includes some of the most complex and vulnerable patients many having multiple chronic conditions managed by different practitioners across time and settings There is often poor communication between clinical care teams leading to inadequate information during transitions and poor continuity of care that can lengthen stays increase costs and result in poorer outcomes There is a heavy reliance on patient and family caregiver recall of information which may not be reliable or possible which raises provider and patient burden Providers may need to track down or recreate missing information through redundant processes Meanwhile patients may not receive needed transition critical care right away while missing data is assembled Schematic diagram illustrating the complexity of care coordination between patient caregivers and CMS Environmental Scan In fall of 2018 the Centers for Medicare and Medicaid Services CMS Division of Chronic and Post acute Care DCPAC engaged MITRE to facilitate a Technical Advisory Group roundtable discussion Convening 75 post acute care clinicians vendors and subject matter experts with a series of one on one discussions with PAC providers health IT vendors and provider organizations the MITRE team and this community to gain insight and urgency into the state of the PAC interoperability landscape These activities identified common themes around challenges to health data interoperability in PAC including lack of incentives lack of standards and not understanding the value of interoperability The graphs below display results from this foundational environmental scan Based on these results CMS in partnership with the HHS Office of the National Coordinator for Health It ONC and MITRE established the PACIO Project Bar chart indicating the number of citations for different challenges to PAC interoperability Bar chart of common PAC interoperability use cases Armed with the environmental scan information the PACIO Project was created with the following mission goals and priorities Mission The PACIO Project is a collaborative effort to advance interoperable health data exchange between post acute care PAC and other providers patients and key stakeholders across healthcare and to promote health data exchange in collaboration with policy makers standards organizations and industry through a consensus based approach Goals Promote interoperability Develop open standard non proprietary FHIR APIs Promote adoption of FHIR APIs Promote reusability Promote innovation Support migration path from older systems to interoperable systems Help establish trust framework for nationwide information exchange Priorities Reach consensus on Governance purpose and goals Decide on a tightly scoped use case s to produce impact Reuse adapt develop FHIR implementation guides for data models Although the PACIO Project is not an HL7 FHIR Accelerator it operates using similar transparent collaboration processes such as developing multiple use cases defining data models and authoring FHIR Implementation Guides IGs One primary difference is the PACIO Project does not require financial contributions from its participants PACIO FHIR IGs are regularly tested at HL7 and CMS Connectathons and test events When testing indicates that the IG is ready materials are prepared for the HL7 Ballot which seeks validation and acceptance by the broader HL7 Community Ultimately the PACIO Project advocates for vendor adoption A conceptual timeline of FHIR IG development as applicable to PACIO First Use Case In selecting the PACIO Project s first use case the community first looked at available prior work Participants did not want to reinvent the wheel and wanted instead to leverage as much existing development as possible The process began by examining the existing HL7 Clinical Document Architecture CDA specifications From this list of specifications an experienced physician within the PACIO Community prioritized it ranking the importance of the data from 1 most important to 3 least important for a variety of different actors physician nurse practitioner registered nurse therapist administrator and the patient family The broader PACIO Community reviewed the rankings and judged whether they accurately captured importance and priorities Participants identified several high priority sections highlighted in yellow in the table below and medium priority sections blue as high value for potential use cases Image of a spreadsheet used to identify and prioritize elements and their importance for PACIO Next the PACIO Community determined which of the high and medium priority use cases candidates were already covered in FHIR and from that identified three potential final candidates for collaborative work Functional Status Mental or Cognitive Status and Advance Directives High Priority Use Cases Image of a spreadsheet used to identify data elements in high priority use cases Medium Priority Use Cases Image of a spreadsheet used to identify data elements in medium priority use cases Many participants collaborating in this first use case were new to the data standards development process The group determined that a simpler use case was preferable in order to produce a useable standard more quickly Further discussions with HL7 work groups indicated that Advance Directives while an important use case would be very complex and not ideal as a starting use case Some members of the Community favored beginning with Functional Status and others Mental Cognitive Status Since the assessment framework for both were similar the Community decided to tackle both concurrently as the initial use cases Leveraging use cases based on CMS post acute care assessments also allowed the PACIO Project to leverage the CMS Data Element Library DEL add footnote with citation which added significant value for the sponsoring CMS Division of Chronic and Post Acute Care DCPAC team With the initial use cases decided the group set out to define the required components for data exchanges captured in the diagram below These components guided the PACIO work for early connectathons Diagram showing use case components and their relationships Design Principles In addition to the principles outlined generally in this playbook the PACIO Project followed these additional design principles People don t know what they want until you show it to them Steve Jobs How many people knew they needed a modern smart phone before 2007 Most did not but today almost everyone has a smart phone as an indispensable tool People often have a general sense that something might be great to have but to actually see a tangible example helps people conceptualize new ideas and how they can contribute to its improvement The PACIO Project has taken this approach from its inception focusing on developing reference implementation prototypes to help illustrate what is possible with a focus on getting to the demonstration as quickly as possible at conferences at connectathons and any venue where people can see listen and explore together Develop Minimum Viable Products MVPs With any new venture or use case it is important to show progress as quickly as possible to build excitement and momentum To get to that point quickly the PACIO Project focused on scoping and prioritizing initial development as tightly as possible to show critical value inexpensively in the shortest amount of time Key questions are What is the minimum functionality that is needed to be useful How can we effectively demonstrate that functionality in the quickest way possible Show the Art of the Possible Equally important to making progress and generating excitement it is important to lean forward be ambitious and push limits to motivate participants and observers while building upon what has been done before Starting the Community Networking has been fundamentally responsible for the success of The PACIO Project Community Everyone involved in the early phase of the project opened their contact list to identify leaders with the experience influence and subject matter expertise in critical areas to help kickstart the project PACIO Project leadership from MITRE and CMS drafted and sent a letter to leaders from government vendors associations clinicians and consultants detailing the purpose of the PACIO Project its high level goals and priorities how it might operate and included an invitation to attend a kick off meeting to find out more Over 80 people attended the initial kick off meeting in February 2019 both in person at MITRE and virtually The kick off meeting covered the project goals and priorities in more detail and discussed next steps including the process for creating a Project Charter and deciding on what use cases to tackle first PACIO Project Charter The PACIO Project Charter acts as a guiding document providing in detail The purpose of the PACIO Project Governance Process including how the group will make decisions Project roles descriptions and responsibilities How decisions will be made Who owns the materials generated The PACIO Project is purely a volunteer effort so the project does not have the concept of participant tiers or a pay to play model Everyone has an equal voice and all viewpoints are heard and considered Early in the Charter development process a vocal minority suggested PACIO focus on developing standards in CDA instead of FHIR After some discussion and consideration of all viewpoints the PACIO leadership team decided to stick to the purpose expressed in the invitation letter and focus on FHIR related standards development That was the only time that a major project decision was made by the leadership team instead of the Community and that method should be used only when a consensus based approach is not possible as it can undermine the sense of Community In this case it was critical for setting a consistent focused direction for the project and clearing the way for early progress and momentum Otherwise the Community transparently developed and approved all aspects of the PACIO Project Charter and it has continued to be the guiding Governance for the project with only minor modifications Deciding who owns materials generated during a project can be a sticky issue but that turned out not to be the case with the PACIO Project It is essential to establish clear expectations for ownership of the materials developed early to avoid problems later Ideally the owning organization should be An unbiased entity that will manage the materials in the best interest across the overall project An entity that will continue to exist for the foreseeable future with appropriate contacts for copyright and license issues In the case of the PACIO Project with the exception of the FHIR IGs which HL7 owns MITRE has been designated the owner of PACIO Project materials for the following reasons MITRE is a non profit organization that serves the public interest as an unbiased independent adviser MITRE cannot compete with industry MITRE is established and has longevity MITRE can easily transfer ownership to another entity in the future In short taking on ownership of a community generated artifact is a great use of a Federally Funded Research and Development Center FFRDC PACIO materials are developed transparently and inclusively consistent with ANSI and HL7 standard development practices All source code for reference implementations is freely available on GitHub through the Apache 2 0 license a very permissible license that also protects trademarks like the PACIO name and logo The Apache 2 0 license allows the software to be easily integrated into derivative works with attribution while not encroaching on the licensing of the derivative software Selecting Use Case Leaders Champions The project charter also highlighted important roles within the project and the responsibilities associated with each role including the leadership structure for individual use cases under the project Use case leaders are critical to the success of the PACIO Project so while solicitations for leaders are open to all candidates for those roles must be considered carefully Using the role definitions in the PACIO Charter as a guide PACIO Project leadership engages in an interview process to determine the qualifications of prospective use case leaders and determine their suitability for the role Selection criteria for use case leaders focus on experience leading diverse groups conflict management and the ability to build consensus knowledge of the domain and if applicable technical ability and experience building FHIR standards When In Doubt Vote The Community votes on all major decisions using parliamentary procedures as specified in the charter This includes the establishment or modifications to the strategy to complete work approving a document for ballot or publication approval of a new use case and other important decisions Votes must be recorded in the minutes and provide a record of what has been decided Documentation of past voting results can prevent reopening discussions that have also been resolved if the same topic arises in a subsequent conversation If someone wishes to reconsider they can make a motion to reopen a topic for discussion seconded and voted on by the community Such motions should be deliberative and not in the event that no documentation exists of the group s previous decision If there is any doubt whether a vote is needed for a particular decision a motion second and vote should be taken Branding Branding is an important aspect of any public facing project The best branding is memorable with a short pronounceable name and recognizable logo and can help the project gain traction In the case of the PACIO Project there was much discussion and several names and logos were suggested Ultimately the name PACIO Post Acute Care InterOperability pronounced pass ee o was selected The selected logo displays a series of nodes healthcare facilities networked with a large central node the patient in the center highlighting the importance of patient centered care The PACIO Community approved this logo and name and uses it in all PACIO materials to establish the branding for the project Building the Community Observer Meetings Not all initial participants at the kick off meeting continued to stay involved as some have decided the project does not align with their interests or the time requirement is too much to actively contribute To provide a way for the latter group to stay apprised of PACIO Project progress a monthly half hour PACIO Observers meeting series provides a summary of project updates This type of meeting can serve as an effective recruiting tool as some Observers become weekly Contributors Contributor Use Case and Tech Team Meetings There are many ways participants can contribute to the PACIO Project Participants can start by joining the weekly Contributors Meeting where quick use case updates key discussions and final PACIO Community votes take place The community also discusses specific use case topics during this meeting but as the project has grown each use case typically has a meeting series to dive deeply into the data modeling and standard development process specific to that use case Participants can choose whether to attend those use case specific meetings if they want to be more involved Conferences The PACIO Project also presents at several conferences every year to spread awareness of the project and its objectives To socialize the project and brand PACIO buttons were printed below showing the PACIO Project Website and worn at conferences to invite discussion and further participation PACIO project button handed out at conferences The PACIO Project also maintains a YouTube channel featuring overviews on topics and recorded demonstrations from connectathons and other events Educate A large part of the PACIO Project is educating the community on the healthcare standards process to build and enable leaders to scale the work more broadly As a result the PACIO Project has been able to address more use cases with greater delegation of responsibilities to use case leaders Clinician expertise is vital to determine what information is needed in a post acute care setting but the PACIO Project has found that the community is far more effective if there is a high level general understanding of how health data elements are specified in a standard It is very helpful for the community to understand the differences between optional must support and required elements as well as the role of terminologies and the potential impacts selected elements and terminologies on the FHIR IG Not everyone in the community needs to be an expert on these topics but some level of familiarity with these concepts has helped the community to understand and reach consensus as quickly as possible Progress happens at the speed of trust and consensus The community appreciates the education the PACIO Project has provided on technical concepts and has opened new horizons for community members to a point where they have invited others to join PACIO Listen to and Respect Everyone The PACIO Project strives to listen to every point of view and treat everyone with respect There are no dumb ideas or questions This provides an inclusive environment for people to bring their unique perspectives voice their opinions and ask key questions which produces great discussions and conclusions on challenging topics Invite Guest Speakers The PACIO Project has invited numerous guest subject matter experts to speak on related topics projects or research that can inform the development of PACIO standards raise awareness and result in collaboration opportunities Several of these sessions have been critical to the development of the PACIO Project s IGs and community growth Get Things Done The PACIO Community is made up of very busy people who donate their time to help solve problems to improve healthcare for all It is important that the PACIO Project be respectful of participants time by establishing clear and efficient meeting agendas and expectations Even as a volunteer organization there is an expectation that participants fulfill commitments and collectively show meaningful progress to provide value for their time Many long time community members appreciate this focus and the PACIO Project s reputation helps draw new members into the community because they see things getting done Meeting deadlines and fulfilling commitments also raises the profile of the PACIO Project within the broader healthcare community Break Bread Whenever Possible Getting together at conferences and gatherings is great for building relationships morale and bonds within the community particularly through topics and venues outside of the PACIO work itself Have dinner see a ballgame visit a museum A sense of community keeps participants engaged and energized Record What Happened The PACIO Project records its meetings and places meeting materials on its HL7 Confluence site This not only provides a record for future reference but it also helps new and potential participants get up to speed quickly on what the project has been doing and where we are in the various work streams It also lends flexibility to those unable to attend a specific meeting due to other commitments so they can catch up on discussions they missed at their convenience Delivering Value Initial Demonstration To adhere to the design principles detailed above the PACIO Project built a demonstration that quickly provided a minimal set of functionalities showing tangible value and what is possible using the CMS Data Element Library DEL The CMS DEL is a web based repository containing the assessments CMS requires PAC providers to submit at specified intervals for example at admission and discharge during every patient s stay at a PAC facility The PACIO Project s initial focus was to demonstrate how the CMS DEL assessment metadata could be represented in FHIR to display forms in an application and collect responses This involved several key steps in preparation for the PACIO Project s first HL7 Connectathon in September 2019 Develop a prototype FHIR IG for the CMS Data Element Library DEL Create a Pseudo DEL FHIR server that implemented that prototype FHIR IG populated with the public assessment metadata in the actual CMS DEL system Develop a reference PAC assessment application FHIR client that could display assessment forms using the DEL metadata and collect the responses Demonstrate that the Pseudo DEL and PAC Assessment application could interoperate to display and capture the assessments required by CMS Integration Tracks The September 2019 HL7 connectathon was a success and gave the PACIO Project a great platform to build from for the next HL7 connectathon in January 2020 With the development of the Functional Status and Cognitive Status FHIR IG the PACIO Project sought to demonstrate what could be done with the assessment data once it was collected By pushing the envelope we expanded the September connectathon work into a multi scene demonstration showing how assessment data not only can be collected but shared across multiple acute and PAC facilities The January 2020 connectathon work also incorporated other FHIR IGs developed by other projects to test and show that independent FHIR IGs can work together effectively as a system of systems Over time PACIO Project Connectathon tracks have grown to demonstrate FHIR data exchanges across up to 23 different systems using up to 17 different FHIR IGs by 14 different vendors and organizations Beyond the PACIO Project IGs other IGs include those developed by the Gravity Da Vinci CARIN Alliance and FHIR At Scale Taskforce FAST FHIR Accelerators as well as other independent projects and core FHIR Specifications Through the PACIO connectathon tracks the following FHIR Implementation Guides have been tested working together as a system PACIO Personal Functioning and Engagement PFE PACIO Advanced Healthcare Directives Interoperability ADI PACIO Re assessment Timepoints PACIO Transitions of Care TOC PACIO Standardized Medication Profile SMP Electronic Long Term Services and Support eLTSS Multiple Chronic Condition eCare Plan MCC eCarePlan Gravity Social Determinants of Health Clinical Care SDOH CC Da Vinci Data Exchange for Quality Measures DEQM Da Vinci Coverage Requirements Discovery CRD Da Vinci Documentation Templates and Rules DTR Da Vinci Prior Authorization Support PAS Da Vinci Payer Data Exchange Plan Net Provider Directory CARIN Digital Insurance Card FAST National Directory of Healthcare Providers Services NDH Physical Activity FHIR Structured Data Capture SDC FHIR US Core The PACIO Project approaches connectathons differently than most other projects and organizations Most projects develop the necessary FHIR IGs for the track and provide other materials including a reference implementation but the preparation to connect systems and software does not start until the actual connectathon The PACIO Project does all of that but recruits a core set of participants weeks in advance and works to have a fully functional demonstration with those participants the week before the connectathon The actual connectathon is used to fine tune the demonstration and resolve any issues before recording the full demonstration Starting the connecting process ahead of time allows the PACIO Project to test more complicated cross project data interactions Unexpected participants are still welcome and always add further value to the connectathon but they integrate with participants who are already connecting making it easier for them to participate PACIO Testing Events Sometimes the HL7 and CMS Connectathons do not align timing wise with project requirements In those cases the PACIO Project conducts its own testing events Project management at HL7 allows testing outside of connectathons as long as participation is open and transparent the outcomes are recorded similar to what is collected at the end of a connectathon and any issues raised are captured in the HL7 Jira issue tracking system When conducting testing events the PACIO Project makes every effort to match what is done during the life cycle of a connectathon track namely Provide track descriptions using the same form as for HL7 connectathons Conduct a kick off meeting to orient participants to the track Setup Zoom calls and breakout sessions as needed Publish a track report listing track testing goals participants scenario roles accomplishments challenges and next steps Growth and Impact As of 2024 the PACIO Project has published five FHIR IGs Two others were moving toward their first edition HL7 ballot and two more were being updated for second edition HL7 ballot The PACIO Project has also been an active member of USCDI and USCDI development providing many comments each year as the USCDI and USCDI versions progress resulting in several new published data classes and data elements such as Advance Directives Functional Status Mental Cognitive Status and Patient Communication Status USCDI updates inform FHIR US Core development New regulations are requiring certain providers not yet PAC providers to implement newer US Core versions for certified APIs This would mandate support for these new data elements to comply with EHR certification requirements The PACIO Project s development and testing of relevant FHIR IGs through vendors in the PACIO Community brings additional credibility to the PACIO comments The PACIO Project is well known and positively regarded by CMS Office of the National Coordinator ONC and HL7 with multiple references in the Federal Register ONC Interoperability Standards Advisory ISA trade journals and both domestic and international FHIR interoperability specification lists Many consider the PACIO Project to be the go to source for PAC subject matter expertise and standards development The PACIO Project continues to attract new members from new sources validating the project s strategy of presenting and participating in a broadening list of conferences on a variety of use cases The PACIO Advance Directives work has visibility at the highest levels of the FHIR Project Team who have taken a personal interest in the project The PACIO Project also is pursuing pilots and production opportunities This has been more challenging than in other cases since post acute care facilities were not included in the Electronic Health Record EHR Incentive Program and therefore did not receive funding to install and upgrade their EHR systems like other parts of healthcare As a result the number of available providers who have EHR systems sophisticated enough to participate in pilots and production environments is much more limited Nevertheless the PACIO Project is forging a pathway forward for standardized exchange of post acute care data Resources PACIO Project Website HL7 Confluence Page for the PACIO Project Use Cases Dashboard Meeting Index YouTube Channel FHIR Implementation Guides Personal Functioning and Engagement Implementation Guide FHIR Shorthand FSH Advance Directives Interoperability Implementation Guide FHIR Shorthand FSH Re assessment Timepoints Implementation Guide FHIR Shorthand FSH Standardized Medication Profile Implementation Guide FHIR Shorthand FSH Transitions of Care Coming soon GitHub Repositories PACIO Project HL7 Reference Implementation Sample Data"},{"id":16,"doc":"Case Studies","title":"The mCODE Standard and CodeX Community","url":"casestudies/mcode_codex.html","content":"On This Page mCODE and CodeX Getting Started First Use Case Growing the Community Expanding the Work Adoption Value Conclusions Back to top Case Study The mCODE Standard and CodeX Community This Case Study summarizes from MITRE s perspective the history of the mCODE FHIR standard and the CodeX Community Included here are how both started how they grew lessons learned and progress toward solving challenges facing initially cancer patients researchers and others This Case Study should be especially valuable to those interested in starting within CodeX or elsewhere broad new standards initiatives for additional medical specialties Introduction and Agenda 5 mins mCODE Development History 4 mins mCODE Modeling Methodology 7 mins Define Use Case 5 min Gathering Relevant Clinical Information 13 mins Translate Information into FHIR IGs 15 mins Validate FHIR IG 5 mins Case Study CardX 5 mins Case Study GenomeX 4 mins mCODE Deeper Dive Q A and general discussion 89 mins Before reviewing the mCODE standard and CodeX Community experience here is a brief definition of each What is the mCODE Standard mCODE is an HL7 standard FHIR Implementation Guide IG integrating an agreed core set of common data elements for cancer These data elements are deemed valuable to patients and other stakeholders via multiple use cases potentially available in every electronic health record for cancer patients and machine computable mCODE consists of approximately 30 FHIR profiles and roughly 100 data elements organized into six thematic groups see below Patient Information Health Assessment Genomics Group Disease Characterization Cancer Treatments and Outcomes Diagram of oncology stakeholders and categories of related data elements in the mCODE FHIR standard What is the CodeX Community CodeX is a member driven HL7 FHIR Accelerator hosting a growing community working together to drive substantial improvements around the most important challenges facing specialty health care and research Initial CodeX Use Cases projects focused on improving collecting and sharing mCODE based data in the oncology space Through 2024 cardiovascular and genomics Communities have also started work within CodeX The following graphic summarizes a core CodeX strategy Enabling all patient data to be collected once and then shared and used as consented by the patient for many different use cases CodeX vision that a cancer patient s data can be collected once and more easily shared for multiple use cases provided the data are standardized Getting Started Key Playbook Track Community Building History 2017 2018 Origin The lucky spark was a chance encounter between former medical colleagues Dr Jay Schnitzer and Dr Monica Bertagnolli on an airplane in 2017 Bertagnolli was a preeminent cancer surgeon at Brigham and Women s and was leading the American Society of Clinical Oncology ASCO and Alliance for Cancer Trials in Oncology ACTO Dr Schnitzer was Chief Medical Officer and Chief Technology Officer at MITRE with a growing portfolio of health information technology research Drs Bertagnolli and Schnitzer had been circling around how to achieve a Learning Health System where caring for every patient enables learning from every patient Every person with any disease should have access to high quality care and also will have the opportunity for their experience to help others in the future Drs Bertagnolli and Schnitzer had also been circling around one of the fundamental challenges to achieving a Learning Health System Lack of a single standard for collecting and sharing patient data electronically They organized the first clinical requirements team convened under the auspices of ASCO co chaired by Drs Jim Chen and Doug Blaney and staffed with world class experts from across the oncology space The team s mandate was to agree on first use cases a narrow scope was important and on a minimal set of clinical data to address use case requirements This data dictionary later seeded a new standard for cancer data the minimal Common Oncology Data Elements Learnings ASCO and MITRE led by Drs Bertagnolli and Schnitzer became what we now call Champions for the new oncology specialty initiative As champions they Committed their leadership Offered many of the key capabilities needed to start and succeed ASCO and ACTO clinical MITRE standards and systems engineering Both convening power Had access to potential members of the community and the resources needed to develop and leverage mCODE ASCO and ACTO access to almost all clinical cancer organizations and vendors MITRE deep expertise in standards and systems engineering Both strong links to Federal health agencies Established the need for clinical expert consensus on very specific use cases and associated minimal data requirements First Use Case Project Draft Standard Key Playbook Tracks Community Building Use Cases Planning Standards Development History 2018 2019 First Project EHR Endpoints for Cancer Clinical Trials ICAREdata study The original mCODE clinical team envisioned a small set of use cases in its initial conceptual work It was clear that success required executing a project where standardized data collection and sharing in the real world would test the value of the new data standard The use case for the ICAREdata project was to capture and share using the mCODE standard high quality clinical treatment data from electronic health records EHRs that could be used for oncology clinical trials and other research ACTO and MITRE became the ICAREdata Use Case Champions Over time multiple health systems clinical trials Epic pharmaceutical companies NCI and FDA participated in hosted and or funded development and testing Initial work focused on standardizing and collecting just three key data elements cancer type disease status e g progressing stable and reason for treatment change all modeled within the fledgling mCODE IG Learnings ACTO and MITRE understood that the best way to develop a cancer data standard is to focus on the small set of core data elements needed for specific use cases e g specific challenges that if empowered by standardized data could have a substantial impact ACTO and ASCO s credibility and clinical network facilitated the engagement of outstanding clinical experts and vendors Adoption and Value in real world settings was in the Plan from the start This ultimately helped refine mCODE and workflows and led to greater participation and substantial funding This use case also helped identify the skillsets necessary during different phases of use case work mCODE Design The ICAREdata Use Case provided helped establish an approach and structure for mCODE around patient assessments disease treatment outcomes genomics and design principles mCODE V 1 0 IG was balloted in the Health Level Seven HL7 standards organization in 2019 and benefited substantially from the ICAREdata experience mCODE design principles started to become clear during the ICAREdata Use Case and have improved and served mCODE s evolution since Principles include a Focus on discrete data collected during patient encounters b Acquire clinical expert input first and engage other experts as the IG is developed c Base the IG on government and industry requirements and trends e g FHIR US Core d Leverage the best existing clinical data modeling efforts e Adopt global standard code systems More details in the Design Principles section Growing the Community Key Playbook Tracks Community Building Implementation Testing History 2019 2020 Cancer Data Summit Interest in mCODE was starting to build and new use cases were being proposed A small group of leaders from across the oncology space patients providers researchers payers gov t agencies vendors and others convened for two days in October 2019 to brainstorm on the future of standardized cancer data obstacles to success and next steps Below is one of the many storytelling roadmaps from the Summit One outcome was support for creating a clinical requirements group which became the mCODE Executive Committee and an implementation group which became the CodeX HL7 FHIR Accelerator Learnings The Summit provided substantial benefits Extremely useful feedback was provided by a diverse set of leaders Noticeable alignment between diverse views happened during the two day event Strategies for next steps were shared Many who attended the Summit expressed interest in staying involved and many of those became Champions and participants in the future mCODE Executive Committee and CodeX Community Whiteboard illustrations from the Cancer Data Summit in October 2019 showing the participants vision of the promise of a common standard for cancer data such as mCODE mCODE Executive Committee and Technical Review Group This body was organized under the leadership of ASCO and included clinical leaders and experts from major cancer related societies government agencies and others as needed This group followed from the original clinical requirements team convened by ASCO in 2019 see above The mandate continues to be to maintain and evolve the clinical data dictionary that underpins mCODE It has proven beneficial to have this strictly clinical group focusing on clinical requirements and interpretation An expert can be an invaluable contributor to mCODE without being deeply involved in the technical and logistical work that CodeX would take on However a valuable small subset of those involved in the Executive Committee have joined CodeX standards and use case work CodeX Community To complement the Executive Committee s clinical leadership MITRE led the creation of CodeX within HL7 s then new FHIR Accelerator Program CodeX was established and still operates with a focus on creating FHIR IGs but also just as importantly a focus on implementing FHIR IGs into software and workflows testing these in the field and supporting adoption and value measurement in the real world A lightweight process Governance structure and Membership fee model were established There were 9 founding members and other categories members by the end of 2020 Establishing the goal of adoption and value of a standard rather than focusing primarily on standards development was and is not easy This generally takes a greater commitment of resources and time from more parts of the community to achieve the goal However this goal resonated with the growing community and ultimately paid off in new use cases members adoption and value in the real world Initial Vendor Implementation Epic and others started to integrate parts of mCODE in their software Demand for mCODE from large cancer centers through ASCO ACTO and the Summit provided substantial motivation for vendors to deliver mCODE infused systems to their customers Expanding the Work Use Cases Solving Real World Problems Led by Champions Powered by a Growing Community Key Playbook Tracks Community Building Use Cases Planning Implementation Testing History 2021 2024 NOTE Check numbers Growth in number of CodeX Use Cases Dec 2020 5 Use Cases Dec 2021 8 Use Cases including first genomics Use Cases Dec 2023 12 Use Cases including first cardiovascular Use Cases CodeX Use Cases today Learnings CodeX leadership agreed to a use case selection process to help ensure use cases have the ingredients e g the Tracks described on this website to succeed The table below lists use case start dates and the champions that drove them Medical societies and government agencies were the most frequent champions Growth in CodeX Membership Feb 2020 9 Members Feb 2021 20 Members Dec 2021 30 Members Jun 2022 40 Members May 2024 50 Members Two main drivers for attracting new members included promising progress within ongoing use cases as well as new use cases which engage different segments of a given specialty ex the radiology segment of the oncology space Successful use cases engaged at least one generally more of each of the types of organizations needed to execute the use case Progression of Use Cases and Champions That Drove Them NOTE Check Names and Dates Start Execution Cancer Use Cases Community Champions 2017 2018 mCODE and CodeX Launch ASCO ACTO MITRE visioning 2018 19 EHR Endpoints for Cancer Clinical Trials ICAREdata ASCO Alliance for Clinical Trials in Oncology engaged Epic multiple cancer centers 2019 20 mCODE Executive Committee and Technical Review Group formed to provide clinical review of proposed new mCODE data elements CodeX Accelerator launched to provide framework and Governance for initially cancer mCODE based Use Cases 2020 mCODE Extraction MITRE 2020 Trials Matching American Cancer Society Cancer Action Network which engaged multiple cancer centers vendors 2020 Radiation Therapy American Society for Radiation Oncology American Association of Physicists in Medicine engaged Epic Varian Elekta other societies cancer centers 2020 Registry Reporting Center for International Blood Marrow Transplant Research Centers for Disease Control and Prevention 2021 Prior Authorization Evernorth and many others Genomics 2 Use Cases HL7 Genomics Work Group Kaiser 1st specialty beyond oncology 2022 Risk Evaluation and Mitigation Food and Drug Administration Cardiovascular 2 Use Cases University of Nebraska American College of Cardiology American Heart Association 2nd specialty beyond oncology 2023 Quality Measures American Society for Radiation Oncology Evernorth Telligen CodeX Use Cases today The evolution of the mCODE FHIR IG standard was strongly driven by CodeX Use Cases and their requirements for core oncology data elements to fuel solutions The static graphic below is mCODE s conceptual model as of October 2023 Visit the latest version of the mCODE FHIR IG where you can click on individual boxes in the graphic to dive into the details of where mCODE stands today The mCODE STU3 conceptual modeling diagram built through defining the needs of different cancer use cases Delivering Demonstrable Value as of early 2024 Key Playbook Tracks Implementation Testing Adoption Value In less than 5 years the CodeX Community and other adopters have demonstrated the value of levering the mCODE standard for data collection and sharing to the point where an increasing number of oncology stakeholders are seeing potential value and requesting support from vendors As of early 2024 there are numerous examples of success Vendor Adoption Infographic showing industry adoption of CodeX standards 2024 Numbers are based on what the team has heard directly There may be additional independent efforts adopting the CodeX FHIR standards Adoption for Routine Care Research by Rodrigo Dienstmann et al Oncoclinicas Data at the largest cancer center outside of North America NOTE check was conducted on 3 069 cancer patients whose data was collected stored and used based on the mCODE standard They found that mCODE enabled a substantial increase in availability of data essential to cancer care improved quality of capture of critical genetic factors for colorectal cancer enhanced real world estimates of progression free survival and significantly increased the patient clinical trials match rate Mayo Pilots using mCODE found NOTE Add more Adopted by and Aligned with Federal Initiatives White House Cancer Moonshot supported by MITRE OSTP and ARPA H noted CodeX as an important partner in strengthening the nation s clinical trial infrastructure President s Cancer Panel noted the importance of mCODE in their recommendations for NCI s National Cancer Plan CMS using mCODE in their Enhancing Oncology Model FDA championing CodeX REMS Integration Use Case CDC s use of mCODE for Central Cancer Registry Reporting IG ONC s US Core Data for Interoperability USCDI Cancer is aligned with mCODE ONC included select mCODE data elements in their USCDI proposed Quality Data Element List Box diagram highlighting adoption metrics for CodeX and mCODE Conclusions from the mCODE CodeX Case Study Key Playbook Tracks Community Building Use Cases Planning Standards Development Implementation Testing and Adoption Value Between 2019 and 2024 the CodeX Community and colleagues improved and leveraged mCODE to address difficult problems in oncology substantially improving cancer care and research During 2022 2024 the cardiology and genomics Communities started their CodeX journey This Playbook is a compilation of the experience from CodeX and elsewhere that is hoped will speed the work of additional new specialties that are considering following the mCODE CodeX model"},{"id":17,"doc":null,"title":"Case Studies","url":"casestudies/index.html","content":"Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies mCODE Radiation Therapy PACIO Project Resources About Back to top Case Studies This section highlights projects that have contributed to and leveraged the MITRE Health Data Interoperability Playbook to achieve success mCODE Standard and CodeX Community Organizations American Society of Clinical Oncology ASCO MITRE Corporation The history of the mCODE FHIR standard and the CodeX Community how both started how they grew lessons learned and progress toward solving challenges facing initially cancer patients researchers and others This case study should be especially valuable to those interested in starting broad new standards initiatives for additional medical specialties CodeX Radiation Therapy Treatment Data Use Case Organizations American Society for Radiation Oncology ASTRO American Association of Physicists in Medicine AAPM Learn how developing a core set of structured data elements for oncology electronic health records EHRs changed oncology radiation therapy The RTTD CodeX use case developed implemented tested and is driving adoption of FHIR based standards and systems such that a radiation oncology information systems can seamlessly generate and share patients radiation therapy treatment summary information across health systems and providers and b clinicians can then use the radiation therapy treatment summary information to make informed impactful decisions related to a patient s health PACIO Project Organizations CMS Division of Chronic and Post Acute Care DCPAC PACIO Project Learn how streamlining transitions of care and care coordination through FHIR changed post acute care The PACIO Post Acute Care InterOperability Project is all about care coordination Forty five percent of Medicare patients who leave hospitals go into some kind of post acute care Post acute care accounts for 74 billion in Medicare payments annually so it is a large part of our healthcare system Post acute care patients are typically very complex and have multiple transitions in their healthcare journey When a person transitions between healthcare settings including ambulatory care acute care long term post acute care LTPAC and home and community based services HCBS mdash their care is often fragmented and can lead to poor health outcomes increased burden and increased costs The PACIO Project is helping to fix these problems Prev Adoption Value Next Resources"},{"id":18,"doc":null,"title":"Welcome to MITRE Health Data Interoperability Playbook","url":"index.html","content":"Welcome to the MITRE Health Data Interoperability Playbook Sharing MITRE s experience developing and deploying health data standards that address real world challenges in patient care and medical research All medical specialty communities are invited to learn and join the mission Playbook Menu Intro Tracks Before Starting Design Principles Track 1 Community Building Track 2 Use Cases Planning Track 3 Standards Development Track 4 Implementation Testing Track 5 Adoption Value Case Studies Resources About Back to top Better Data Better Health In 2017 leaders within The MITRE Corporation and the American Society of Clinical Oncology ASCO recognized a fundamental challenge across the oncology field the lack of a single standard for collecting and sharing a patient s health data electronically This lack of standardization led to numerous issues including difficulties in exchanging data data errors delays in analyzing data and prescribing treatments excessive costs for care and research and an undue burden across the entire health ecosystem To address these issues MITRE and ASCO partnered with a diverse group of leading experts to develop the minimal Common Oncology Data Elements mCODE a FHIR based standard for oncology data collection and sharing MITRE also worked with Health Level Seven HL7 to launch the CodeX HL7 FHIR Accelerator a growing community of providers patient advocates researchers payers vendors regulators and other stakeholders who are driving adoption of mCODE through new standards based solutions to a range of real world challenges This Health Data Interoperability Playbook the Playbook consolidates MITRE s experience leading mCODE CodeX and similar projects to create a roadmap for specialty champions and their teams to drive new FHIR based data standards that improve health care and research The Playbook is organized around five tracks that form a framework for the CodeX mCODE approach Community Building Use Cases Planning Standards Development Implementation Testing and Adoption Value Questions that a new specialty should ask themselves before embarking on the above tracks are included on the Before Starting page Design Principles are a foundation for efficient development of quality standards and will help ensure alignment between different standards development initiatives within and across specialty communities A downloadable Playbook Checklist will help specialty communities embark on new standards initiatives across Playbook tracks Case Studies show how specific projects have leveraged the tracks Additional details related to the tracks and Case Studies can be found in the Resources section Next Introduction Featured Case Studies Projects that have developed and used the principles and practices covered in the Playbook mCODE Standard and CodeX Community Learn how the CodeX Community changed oncology care and research by standardizing data exchange through a core set of FHIR data elements CodeX Radiation Therapy Treatment Data Use Case Read how the American Society for Radiation Oncology and American Association of Physicists in Medicine joined CodeX to build a community and standardize FHIR based radiation therapy treatment summaries PACIO Project Review how the PACIO project is streamlining transitions of care and care coordination between post acute care PAC and other providers patients and key stakeholders through FHIR View all Case Studies"}] \ No newline at end of file