The Learning Experience: Celebrating a Year of MongoDB Developer Days

One year ago today MongoDB held our first regional Developer Day event, a full-day experience designed to teach the fundamentals and advanced capabilities of MongoDB. Developer Day events have been held in person in over 35 cities, across 16 countries, and in seven languages. Initially created by a core team with a passion for enabling developers, a group of talented MongoDB Developer Advocates and Solution Architects have since scaled the program to directly engage and teach thousands of developers worldwide.

As developer relations programs go, engaging builders through hands-on workshops is hardly a new approach. But the difference at MongoDB is how closely we collaborate cross-functionally with other teams, and how focused we are on providing authentically hands-on, engaging experiences for developers.

From the start, the MongoDB Developer Day program was a collaborative effort to take a platform that is easy to get started with and to introduce more advanced capabilities in a compelling way. Based on the helpful and positive feedback we continue to get from participants, we know Developer Days help developers gain skills and a sense of accomplishment as they alternate between instruction and applying that learning through hands-on exercises.

To share more about what has made Developer Days so successful, I asked members of that core team—Lead Developer Advocate Joel Lord, and Sr Developer Advocates Mira Vlaeva and Diego Freniche Brito—to reflect on key areas that went into creating this enduring experience.

Photograph of the Developer Day class at MongoDB.local New York City. There are roughly 70 people in the photo standing in front of the presentation stage.
Our Developer Day class at MongoDB.local NYC in May, 2024

A sense of accomplishment

“We all agreed that a Developer Day should focus on hands-on learning, where developers can experiment with MongoDB, potentially make mistakes, and take pride in building something on their own,” Mira said. “The goal was to build a fun learning experience rather than just sitting and listening to lectures all day.”

The curriculum was designed to encourage developers to work together at certain points as they advance from data modeling and schema design concepts to implementing powerful Atlas Search and Vector Search capabilities. “One of my favorite moments of the day is when people start working together,” Joel said. “At the beginning of the day, our attendees can be a little hesitant, but they quickly begin to collaborate with each other, and it's wonderful to witness that happen.”

Building great Developer Days together

While our MongoDB Developer Relations team designed the agenda and course material, it was our partnerships with other teams and stakeholders that helped Developer Days take flight. There were many key stakeholders that shared a vision for enabling developers to realize more value with our platform.

As Joel remembers, “We had to work and collaborate with a number of other teams, which was, at the time, new to us.” Among the key teams involved, Diego added, “Working with Field and Strategic Marketing teams has been a great experience. They help us so much with all the really important tasks… there's so much they've done that Developer Days wouldn't be a reality without them.”

The program has expanded our collaboration with several other teams, including marketing, product, and sales, to ensure our courses remain up-to-date and we make the most of our time in each city by welcoming developers from key accounts.

Continued success and improvements

To ensure Developer Days were as impactful as possible, we initially ran the program as a pilot in seven cities. In addition to noting live observations and interactions, we used surveys to collect feedback and report on an NPS (net promoter score) to assess whether the event exceeded participant expectations. These initial events were spaced out enough that the team could implement improvements and try new approaches at subsequent Developer Days.

“We had the opportunity to run the same labs multiple times, make small changes each time, and observe how people react to the different configurations,” said Mira, who continues to contribute improvements such as new interactive elements.

As we continue to bring the Developer Day experience to new cities, we’re also taking Developer Days online. “There are so many reasons why people may not be able to attend our in-person events,” said Lauren Schaefer, who recently rejoined MongoDB Developer Relations to lead the program forward. “I look forward to working with my team to tackle the challenges of bringing our curriculum successfully online.”

So a year later, I want to say thank you to everyone who has made Developer Days a success—from seven staff members who supported our first event in Chicago, to the roughly 100 talented people across MongoDB who are now part of the program. Even more importantly, I’m thankful for all of the participants (across 35 great cities and 16 countries!) that joined us for this full-day experience. As I love to say at the beginning of every Developer Day, we’re here to learn from each other. I hope you’ve learned as much from us as we have from you!

To learn more about MongoDB’s global community of millions of developers—and to check out upcoming events like Developer Days—please visit our events page.

← Previous

The Dual Journey: Healthcare Interoperability and Modernization

Interoperability in healthcare isn’t just a buzzword; it’s a fundamental necessity. It refers to the ability of IT systems to enable the timely and secure access, integration, and use of electronic health data. However, integrating data across different applications is a pressing challenge, with 48% of US hospitals reporting a one-sided sharing relationship in which they share patient data with other providers who do not, in turn, share patient data with the hospital. The ability to share electronic health data seamlessly across various healthcare systems can revolutionize patient care, enhance operational efficiency, and drive innovation. In this post, we’ll explore the challenges of healthcare data sharing, the role of interoperability , and how MongoDB can be a game-changer in this landscape. The challenge of data sharing in healthcare Today's consumers have high expectations for accessing information, and many now anticipate quick and continuous access to their health and care records. One of the biggest IT challenges faced by healthcare organizations is sharing data effectively and creating seamless data integrations to build patient-centric healthcare solutions. Healthcare data has to be shared in multiple ways: Between internal applications to ensure seamless data flow across various internal systems. Between primary and secondary care , to coordinate care across healthcare providers. To patient portals and telemedicine to enhance patient engagement and remote care. To payers, institutions, and patients themselves , to streamline interactions with insurance companies and regulatory bodies. To R&D units to accelerate medical research and pharmaceutical developments. The complexity of healthcare data is staggering, and hospitals regularly need to integrate dozens of different applications—all of which means that there are significant barriers to healthcare data sharing and integration. A vision for patient-centric healthcare Imagine a world where patient data is shared in real-time with all relevant parties—doctors, hospitals, labs, pharmacies, and insurance companies. This level of interoperability would streamline the flow of information, reduce errors, and improve patient outcomes. Achieving this, however, is no easy feat as healthcare data is immensely complex, involving various types of data such as unstructured clinical notes, lab tests, medical images, medical devices, and even genomic data. Furthermore, types of data mean different things depending on where and where it was collected. Achieving seamless data sharing also involves overcoming barriers to data sharing between different healthcare providers and systems, all while adapting to evolving regulations and standards. Watch the " MongoDB and FHIR: Navigating Healthcare Data " session from MongoDB.local NYC on YouTube. The intersection of modernization and interoperability Modernization of healthcare IT systems and achieving interoperability are two sides of the same coin. Both require significant investments and a focus on transitioning from application-driven to data-driven architecture. By focusing first on data and then connecting applications with a developer data platform like MongoDB Atlas , healthcare organizations can avoid data silos and achieve vendor-neutral data ownership. As healthcare interoperability standards define a common language, organizations might question whether, instead of reinventing the wheel with their own data domains, they can use the interoperability journey (and its high investments) to modernize their applications. MongoDB’s document data model supports the JSON format, just like FHIR (Fast Healthcare Interoperability Resources) and other interoperability standards, making it a more efficient and flexible data platform for developing healthcare applications beyond the limitations of external APIs. FHIR for storing healthcare data? The most implemented standard worldwide, HL7 FHIR , treats each piece of healthcare data as a self-contained resource, which can be accessed through unique URLs on FHIR servers, similar to how web pages are accessed on the internet. FHIR adopted a pragmatic approach for which there was no need to define a complete and unique set of resources for all the clinical data, but trying to get what most of the electronic health records (EHR) share. That is the 80% / 20% approach. For the 20% of non-standardized data, they created the famous FHIR Extensions , to extend every resource to the specific needs. However, FHIR is not yet fully developed, with only 15 of the 158 resources it defines having reached the highest level of maturity. The constant changes can be as simple as a name change or can be so complex that data has to be rearranged. FHIR is designed for exchange of data, however, as questioned above, it might be thought to be used also for persistence. In this post from Alastair Allen, he discusses the problems that could arise when using FHIR for persistence depending on the use case, and this chart aids in the decision-making. Figure 1: Using FHIR for persistence depending on the complexity of the use case For specific applications with no complex data, such as an Enterprise Master Patient Index (EMPI) to match and unify patient demographics across applications or to integrate data from wearables, leveraging FHIR for persistence is a good approach. However, building a primary operational repository for broader applications like a Patient Summary or even a Healthcare Information System (HIS) presents a significant challenge. This is because the data model these applications require for a specific organization goes beyond the capabilities of FHIR, and solving the bias through FHIR extensions makes this an inefficient approach. OpenEHR as an alternative approach In Catalonia, Spain—for about 8 million people and roughly 60 public hospitals—there are 29 different hospital EHR systems. This fact converts Catalonia to a long-experienced actor in healthcare interoperability. Each hospital maintains a team of developers exclusively focused on building interoperability interfaces. This is not a one-time cost, but it is a fact that there will be an increasing demand for data sharing. This will never end, and the costs are increasingly higher. In Catalonia, as well as in other European regions, some thought about changing the paradigm. Rather than implementing interoperability interfaces, why not create new applications that are implicitly interoperable? This is what openEHR proposes, defining the clinical information model from the maximal perspective and developing applications that consume a subset of the clinical information system. This is what the openEHR fans relate to as “Interoperability.” It’s not a protocol but an open architecture. However, while FHIR is very versatile—offering data models for administrative and operational data efficiently—openEHR focuses exclusively on clinical data. So while a combination of FHIR and openEHR can solve part of the problem, future healthcare applications need to integrate a wide variety of data, including medical images, genomics, proteomics, and data from complex medical devices—which could be complicated by the lack of a single standard. Overcoming this challenge with the document model and MongoDB Now, let’s discover the power of the document model to advance interoperability while modernizing systems. MongoDB Atlas features a flexible document data model, which provides a flexible way of storing and organizing healthcare data using JSON-like documents. With a flexible data schema, healthcare organizations can accommodate any data structure, format, or source into one platform, providing seamless third-party integration capabilities necessary for interoperability. While different use cases will have different solutions, the flexibility of the document model means MongoDB is able to adapt to changes. Figure 2 below shows a database modeled in MongoDB, where each collection stores a FHIR resource type (e.g., patients, encounters, conditions). These documents mirror the FHIR objects, conserving its complex hierarchy. Let's imagine our application requires specific fields not supported by FHIR, and there is no need for an FHIR extension because it won’t be shared externally. We can add a metadata field containing all this information that is as flexible as needed. It can be used to track the standard evolution of the resource, the version of the document itself, tenant ID for multi-tenant applications, and more. Figure 2: Data modeled in MongoDB Another possibility is to add the searchable fields of the resource as key-value pairs so that you can retrieve data with a single index. We can maintain the indexes by automating this with the FHIR search parameters. In a single repository, we can combine FHIR data with custom application data. Additionally, data in other protocols, such as DICOM metadata and OMOP, can be integrated, providing unparalleled flexibility in accessing your data. This setup permits access through different endpoints within one repository. Using MQL (the MongoDB Query Language), you can build FHIR APIs or use the MongoDB SQL interface to provide SQL querying capabilities to connect your preferred business intelligence tools. Figure 3: Unified and flexible data store and flexible data retrieval MongoDB’s developer data platform At the center of MongoDB’s developer data platform is MongoDB Atlas, the most advanced cloud database service on the market. It provides integrated full-text search capabilities, allowing applications to perform when making complex queries without the need to maintain a separate system. With all the possibilities of generative AI, multi-dimensional vectors to represent the meaning of the data are becoming a necessity for all vendors and organizations. MongoDB’s capabilities of storing vectors alongside the operational data while providing the vector search aggregation stage functionality, enables fast data retrieval with the possibility of pre-filtering your data with any of the data existing in your operational database. This is executed in a single query, deriving in a best-of-class performance operation. Figure 4: Vector embeddings These capabilities transform a single database into a unique, powerful, and easy-to-use interface capable of handling diverse use cases without the need for any single-purpose databases. Solving the dual challenge with MongoDB Achieving interoperability and modernization in healthcare IT are challenging but essential. MongoDB provides a powerful platform that meets organizations’ modern data management needs. By embracing MongoDB, healthcare organizations can unlock the full potential of their data, leading to improved patient outcomes and operational efficiency. Figure 5: Closing the gap between interoperability and modernization journey with MongoDB Refactoring applications to incorporate interoperability resources as part of documents—and extending them with all the requirements for your modern needs—will ensure organizations’ data layers remain robust and adaptable. By doing so, organizations can create a flexible architecture that can seamlessly integrate diverse data types and accommodate future advancements. This approach not only enhances data accessibility and simplifies data management but also supports compliance with evolving standards and regulations. Furthermore, it enables real-time data analytics and insights, fostering innovation and driving better decision-making. Ultimately, this strategy positions healthcare organizations to effectively manage and leverage their data, leading to improved patient outcomes and operational efficiencies. For more detailed information and resources on how MongoDB can transform organizations’ healthcare IT systems, we encourage you to apply for an exclusive innovation workshop with MongoDB's industry experts to explore bespoke modern app development and tailored solutions for your organization. Additionally, check out these resources: MongoDB and FHIR: Navigating Healthcare Data with MongoDB How Leading Industries are Transforming with AI and MongoDB Atlas The MongoDB Solutions Library is curated with tailored solutions to help developers kick-start their projects For developers: From FHIR Synthea data to MongoDB

August 28, 2024
Next →

MongoDB and Partners: Building the AI Future, Together

If you’re like me, over the past year you’ve closely watched AI’s developments—and the world’s reactions to them. From infectious excitement about AI’s capabilities, to impatience with its cost and return on investment, every day has been filled with AI twists and turns. It’s been quite the roller coaster. During the ride, from time to time I’ve wondered where AI falls on the Gartner hype cycle, which gives "a view of how a technology or application will evolve over time." Have we hit the "peak of inflated expectations" only to fall into the "trough of disillusionment?" Or is the hype cycle an imperfect guide, as The Economist argues? The reality is that it takes time for any new technology—even transformative ones like AI—to take hold. And every advance, no matter how big, has had its detractors. A famous example is that of Picasso (!), who in 1968 said, “Computers are useless. They can only give you answers.” (!!) For our part, MongoDB is convinced that AI is a once-in-a-generation technology that will enhance every future application—a belief that has been reinforced by the incredible work our partners have shared at MongoDB’s 2024 events. Speeding AI development MongoDB is committed to helping organizations of all sizes succeed with AI, and one way we’re doing that is by collaborating with the MongoDB partner ecosystem to create powerful, user-friendly AI development tools and solutions. For example, Fireworks.ai —which is a member of the MongoDB AI Applications Program ecosystem —created an inference solution that hosts gen AI models and supports containerized deployments. This tool makes it easier for developers to build and deploy powerful applications with a range of easy-to-use tools and customization options. They can choose to use state-of-the-art, open-source language, image, and multimodal foundation models off the shelf, or they can customize and fine-tune models to their needs. Jointly, Fireworks.ai and MongoDB provide a solution for developers who want to leverage highly curated and optimized open-source models and combine these with their organization’s own proprietary data—and to do so with unparalleled speed and security. “MongoDB is one of the most sophisticated database providers, and it’s very easy to use,” said Benny Chen , cofounder of Fireworks.ai. "We want developers to be able to use these tools, and we want to work with providers who enable and empower developers." Nomic , another MAAP ecosystem member, also enables developers with best-in-class solutions across the entire unstructured data workflow. Their Embed offering, available through the Nomic API , allows users to vectorize large-scale datasets for use in text, image, and multimodal retrieval applications, including retrieval-augmented generation (RAG), using only their web browser. The Nomic-MongoDB solution is a highly efficient, open-weight model that developers can use to visualize the unstructured datasets they store in MongoDB Atlas . These insights help users quickly discover trends and articulate data-driven value propositions. Nomic also supported the recently announced vector quantization in MongoDB Atlas Vector Search , which reduces vector sizes while preserving performance. Last—but hardly least!—there’s our new reference architecture with MAAP partners AWS and Anthropic. Announced at MongoDB.local London , the reference architecture supports building memory-enhanced AI agents, and is designed to streamline complex processes and develop smarter, more responsive applications. For more—including a link to the code on Github— check out the MongoDB Developer Center . Making AI work for anyone and everyone The companies MongoDB partners with aren’t just making gen AI easier for developers—they’re building tools for everyone. For example, Capgemini has invested $2 billion in gen AI and is training 100,000 of its employees in the technology. GenYoda, a solution that helps insurance professionals with their daily work, is a product of this investment. GenYoda leverages MongoDB Atlas Vector Search to analyze large amounts of customer data, like policy statements, premiums, claims history, and health information. Using GenYoda, insurance professionals can quickly analyze underwriters’ reports to make informed decisions, create longitudinal health summaries, and streamline customer interactions to improve contact center efficiency. GenYoda can ingest 100,000 documents in just a few hours and respond to users’ queries in two to three seconds—a metric on par with the most widely used gen AI models. And it produces results: in one example, by using Capgemini’s solution an insurer was able to increase productivity by 15%, add new reports 25% faster (thus speeding decision-making), and reduce the manual effort of searching PDFs, increasing efficiency by 10%. Building the future of AI together So, what’s next? Honestly, I’m as curious as you are. But I’m also incredibly excited. At MongoDB, we’re active participants in the AI revolution, working to embrace the possibilities that lie ahead. The future of gen AI is bright, and I can’t wait to see what we’ll build together. To learn more about how MongoDB can accelerate your AI journey, explore the MongoDB AI Applications Program .

November 4, 2024