 Jason, over to you. Thank you, Steve. So it's a pleasure to be here. What I would like to talk about is two activities that we have been doing in the open group. Health care has only been a forum in the open group for five years, and it was a board-mandated forum, and a slightly different way to come into the organization. But I think you'll see that we have been busy. I want to talk about a reference architecture, a framework that we call the O'Hara, and then talk about something that we recently acquired, I guess, from the US federal government called the THM, which is an information model. Just a little background. How many people here care about their health? OK, I actually noticed a few people without their hands up, and I'm going to come to you afterwards, because I find that interesting. The health care industry is truly one of the largest worldwide. Its growth is one of the fastest among all industries, and it's unsustainable. It's widely recognized that the pace of growth is not sustainable. Yes, in the US it's 17% of gross domestic product, but in developed countries it's 10%. It's a lot of money. And it's not like everything's going well. The third leading cause of death in the US is estimated to be 250,000 people a year, 700 people a day, more than a jumbo jet crashing each day. There is no doubt, but the health care industry has been slow to respond to the fourth industrial revolution, but that's changing. That's changing through AI, through predictive analytics, through the use of enterprise architecture, through the use of medical devices, personal, as well as in the hospital. So what we have in the HERA is a framework to help cure what ELS Health Care. We've developed a holistic view, which I'm going to show you in two seconds or so. It's guided by the principle of better outcomes for patients, better outcomes as defined by patients. It's informed by evidence. It aligns business strategy and technology and operations. It's based on the key elements of the time-tested notion of plan, first you plan, then you build, then you run. Here's what it looks like. Oops, I went too far, perhaps. Let's see. No. So it's a cloverleaf. We call it a fidget spinner. There are 12 steps in this framework, and this is truly an overarching framework. Notice in the middle, it has the person or the family or people. It also is agile, and I'll explain that in a minute, even though it may look like it's waterfall because there's some kind of linearity going on here, but it's not waterfall. It's based on plan, build, run, as I said, where plan is all about management. Build is all about the architectural model, and run is about the operations of the program. When I say and we say that when the forum has developed this as an agile reference architecture, what we mean is that, obviously, if it's a new business, you might start in a waterfall fashion. You might talk about, OK, what's your vision? What's your strategy? And how do you run through this cycle? But if you have a business as most of the ones that we work for that are operating, you can start anywhere along those 12 steps and go anywhere else. I'll explain. So if we just look at the management model, the vision, that's where we start, right? It's quite straightforward. You can read it on the slide. And then you go to strategy. What strategies do you need? Taking into account the ecosystem, the regulatory environment, your competitors, and so forth, what are the capabilities that you need to develop? What is the portfolio that you need to develop to transform your company? Once you get into what is traditionally in the architectural framework, there's a lot of work to do. There's developing the business processes that are going to be managed and changed. There is the information model. The information model is critical, and that's where the FIM comes in. And that's where we marry the two. And there'll be a lot to say about that as I go through this. There are, there's the applications step and some of the most commonly used standards for health care are now based on APIs. There's the technology. And then in the run, in the operations model, there's four steps. There's, okay, you operate the business, and then you measure your key performance indicators, and then you analyze your data to improve, and then you evolve as a company. What are the next steps in HERA? And by the way, I should say, HERA has been, we've developed applications. We've used it to explain work done in the opioid crisis on prescription drug programs in hospital, in a hospital in Norway, in eclinical quality measures in the Medicaid program in the U.S. But we really want to focus now on making it executable. How are we going to do that? If you really think back just two hours ago, maybe to Mark Langhorst's presentation, 3.1 Archimate can help build out any of these steps, virtually any of these steps. And we are really looking forward to engaging members of the open group in helping to build down to that next level, Mark talked about. And I was impressed by this idea that if you have a framework at this level but you want to operate at this level, you've got to have some kind of tools that cover that gap. We're working actually tomorrow, we're talking to the Dutch quasi-government organization called Nictes, which has developed a hospital reference architecture in Archimate, not surprisingly, in Archimate. And we're talking about combining the two because FIM is broader. That's one way. Another is that we're expanding collaborations. Not only with the Netherlands, we were just talking to the World Economic Forum in The Hague where we were invited. Being considered as a secretariat for one of their projects on standardizing clinical informatics, we'll see where that goes. We're an agile organization. They're trying to get their stuff together and get people involved. Some of our Platinum members are much engaged in that project. They're focused on outcome measures, patient focused outcome measures. And then we want to test and demonstrate the FIM in a variety of situations. So let me transition now to talk about the information model. I could, I'll say just a word. I look back at the history of development of enterprise architecture, which has happened in my lifetime. Early paper by Evans and Hague that was published in Harvard Business Review. Really talking about information. IBM's initial, I think it's, I forget what it's called. I think I'm thinking PBS, but it's initial architectural framework, information focus. Zachman at the beginning, looking at information structure architecture only later in the late 90s calling it enterprise architecture. Togaf, a boundaryless information flow. So there is a pretty heavy focus on information and digitizing it. At this point, we're gonna watch a short video that we had help through the US government in developing that pretty much explains it. FIM, the Federated Health Information Model. Advancing healthcare interoperability by harmonizing standards. Thanks to rapid 21st century technology developments. Today, we use all kinds of digital products that transfer key information to help us do things we value like managing our finances, shopping online, finding a flight, looking a place to stay, reserving transit, keeping up with family and friends and last but not least, managing our health and healthcare. Unfortunately, transferring healthcare information among all of those who need it often feels like being stuck in a time warp. Consider for example, Mr. John Smith. John is a 70 year old retired veteran who lives on a modest pension with his wife, Mary. He suffers from multiple health problems. Heart disease, chronic low back pain, obesity, borderline diabetes and bouts of depression. When John begins to experience moderate chest pain, his internist refers him to a cardiologist. When John and Mary arrive at the office, they are given page after page of forms to fill out about John's health, insurance and basic demographics. They complete them while knowing the same information already exists in the EHR at his primary care physician's office. Imagine their frustration. Why couldn't this information be sent electronically to the new cardiologists? Of course, the answer is that most EHRs don't easily talk to one another. They don't interoperate. Everyone is handicapped by poor interoperability in healthcare. Most healthcare stakeholders experience information sharing challenges every day. For example, clinical staff know they don't always have the most up to date patient information. Yet they need to make decisions in real time. Not having information needed to provide high value care is frustrating and costly. Sometimes the source of frustration is too much information. Providers often have to scour through detailed clinical narratives, looking for key information to gain an accurate picture of their patient's healthcare needs. As a result, clinicians often lack confidence in the information they use to make vital decisions with their patients. We need better solutions to help information flow securely and timely so patients can receive the highest value healthcare possible. At the heart of this problem is lack of standards agreement. Consider a real life example of what can happen in the absence of agreed on standards. Our story goes back over 100 years ago to Baltimore, Maryland, the fifth largest US city at the time. One summer's day, back to 1904, a small fire began to spread through Baltimore so quickly that local fire departments called for help from surrounding areas. Naturally, neighboring firefighters responded. They came with fire trucks and hoses, ready to extinguish the flames and limit the damage. However, their hoses did not fit the fire plugs in Baltimore. With no standard size for couplings, water could not be transported to the flames. Firefighters stood by helplessly as the fire burned out of control and much of central Baltimore burned down in what became the third largest fire disaster in American history. Unlike the Baltimore example, the primary barrier to gaining standards agreement in healthcare today is not physical or technical, rather it's economic and social. Alas, it's easier to create new standards than to build consensus on making existing standards work. Fortunately, compatibility among healthcare standards does not mean that everyone needs to use the same standard. As long as standards are mapped to a common logical information model, they can work together and information can flow. This is the purpose and promise of the Federated Health Information Model, which we call the FEM. The FEM is an expandable health information model and different standards can be mapped to it. By providing a common map for different standards, the FEM can harmonize standards developed by different organizations. The FEM provides a detailed map of healthcare information put into distinct groupings or domains. This map of health information and associated standards can be used to increase interoperability so health information is available when and where it is needed. The result is more efficient healthcare systems, better care and improved patient outcomes, and much less frustration for providers and for patients and caregivers like John and Mary Smith. Okay, so if the FEM is so great, why did the government give it away? Which they sort of did. After 10 years of funding, $5 million over 200,000 person hours. First, there was an extraordinary lack of understanding. I mean, really, while the Klinger-Cohen Act, which was designed, which was intended to bring federal agencies together in their data models and their ability to exchange information is responsible for the creation of the FEM and the 10 years of work that was done on it in the US federal government. The fact is that no offense, enterprise architects do enterprise architecture very well, but they don't do marketing. And marketers don't do enterprise architecture very well. So nobody knew much about it. Also, you've got all that UML and it scares some people and I'll get into that in a minute. So it was a little hard to understand. Also, there was no basic sort of... So it was on the web, unlike us, we now have the FEM on the web and we can track who uses it. We have a daily tracker, we can do analysis. Federal government didn't do that. For all we know, Epic, Cerner, McKesson, Athena Health, all borrowed this open source to put into their own proprietary information models. We don't really know. There were adoption questions naturally. They didn't know how many folks had adopted it. Also something happened about a year ago. The VA and the DOD, which were two of the major sponsors of the FEM. In fact, the FEM came from the Veterans Health Information Model. Those two organizations let approximately $10 billion of contract money to Cerner to develop an electronic health information model that could allow veterans and people in active military service to be able to get their data shared among their providers and about 70% of veterans receive care outside of the veteran administration in the private sector which use all kinds of different electronic health records. There was a bit of ideology in the current administration. Let it hit the private sector and see how it can compete there. And then there is this, and Clay Christensen's terms, hugely disruptive technology called FIRE, Fast Health Interoperability Resources which has grown up over a 10-year-plus period. And this is a very complicated story, how it got there. But HL7 International is the largest health care standards body. I see some of you shaking your head and you know. What you have on that top line is you've now got clinicians doing smart on FIRE. You've got employer organizations doing Argonaut on FIRE. You've got buyers, whether it's public or private insurance companies participating in DaVinci. You've got Epic and the other nine top 10 EHRs who have to some extent incorporated FIRE into their business model. In the middle you've got government there. In the US, in Netherlands and other places, there are regulations that specify standards that shall be used. The US is pretty light on this, but whenever a government organization says do this, the market moves because they like, the market likes that kind of certainty. So FIRE has really taken hold. How many of you have an iPhone and see that app with the heart? Press on that. You'll see that you can download your medical record from your provider. And if you look at the small writing, you'll see that they use the FIRE API to transfer that information. Google, Amazon Web Services, and Microsoft are all jumping on board and you can see that there is international presence in using the FIRE as well. So what we knew we had to operate in this environment where the FIRE had just taken off. It may be on the top of the Gartner hype cycle, it may be part way up, the Gartner hype cycle and the trough of disillusionment and then the even trajectory after that may not even apply, don't know. But what we did with support from ONC is we put together a group of experts, architects, master architects who wrote the FIM, including physician, informaticists and various architects as well as federal people in the federal government. And we asked them, what do you think is potentially the greatest value of the FIM? And this is what we learned. First, we learned some things about FIRE. We learned that FIRE is immensely popular because it's easy to use. It's based on an API. Somehow in healthcare, again, late to the game of the fourth industrial revolution. But the idea that you could use APIs to transfer things quickly and easily only was adopted in healthcare quite recently. But here's the problem. FIRE enables a relatively easy agreement of exchange of information between two entities, but it does not ensure that that methodology will allow two other agencies to exchange information. So as a result, the adoption of FIRE while it's fantastic is resulting in over 10,000 profiles that are kept in the repository. What's it gonna be in five years or a year? It's almost like a whole new interoperability problem on a meta level. These aren't really standards. They're working on it, but we wanted to know how can FIM address this issue. What we knew is that meeting the need of having a common health information model, common logical information model, some people call it, is really necessary. It helps solve the N squared problem if you're, I'm sure you're familiar with that, where if everybody has to develop unique means of interoperability, then N squared, if you have seven entities that wanna exchange data, you got 49 interoperability instances. If you map to a common logical information model as the video showed, even though you don't have to use the same standards, they can be translated and it becomes N and far more manageable. So, we knew that the complexity of FIRE was preventing its uptake, FIM was preventing its uptake, so that what we were told is that making FIM accessible, easy to use, making it easy to do the right thing was our goal. So how did we do that? We created something called the FIM Profile Builder, FPB, and we're trademarking it and we're hosting it on our website. We're in the process of doing it, but we demonstrated that it works. And what does it do? It takes the front end part of the FIM, where you have, by the way, it's not just an information model, it's an information and terminology model. So, you saw the UML model, there's actually over 42 domains, covers about 90% of the healthcare that's typically exchanged. Each of those, well, each of those domains has classes, there's over 1,000 classes and there's 6,000 elements under each of those. And each, if you go onto our website, which I'm gonna quickly show you at the end of the talk, you can see the model, you can explore it, you can see the terminology bindings to it. That's its strength. What we were able to do in the demonstration period when we were transferring the FIM to the open group was build something called a FIM Profile Builder. We were able to build a user interface that uses the FIM so that instead of looking at all that UML, you can type in what it is that you're interested in and all of the elements in the FIM that are relevant to immunization reports, for example, pop up, and then you can constrain them as resources, which is what is done in FIRE. You constrain them, you say whether they're mandatory or whether they're used but not standard or whether you don't even have them or need them or want them and then that template gets saved, so it's reusable. The template then goes through this thing called the FIM Profile Builder Generator, which is based on something called MDMI, model-driven, model-driven something or the other, sorry. Model-driven health tools, MDHT, and something called MDMI, and it generates FIRE profiles and implementation guides. And what we did is we tested the automated generated FIM FIRE profile with the one that the Argonaut Group, which the government is looking at and which is being used all over the world, that's how it's done. It's done manually. These profiles are created manually for interoperability. We were able to generate exactly the same profile automatically. We're talking to our colleagues in the Netherlands tomorrow and did last week in the Hague with the Dutch Ministry of Health, Welfare, and Sport about how the FIM could help what's likely to be mandated use of certain kinds of standards called ZIBs or detailed clinical models. So let me very quickly to finish out, show you, are we showing it here? Yes, this is our new website and I encourage you to visit it, www.fim.org. It's full of interesting things, naturally I think so. It has the animation. It has the model. It has the FIM profile builder. Not quite hosted yet, but you can download the software so we're getting there, we'll be there soon. And then it talks about who the FIM is for. So it starts with managers. And for managers, it addresses the value propositions of the FIM and the FIM profile builder. And it shows the FIM animation, because as you saw, the FIM animation is at a level where basically your grandmother can understand it. And then it has a video, one of three, on the FIM profile builder. It also then talks to modelers who are going to be interested in the FIM model, which you can access there. And as it says, the FIM model is based on hundreds of use cases coming out of not just the federal government but based on the standards, the international standards like SNOMED CT where there's, I don't know, 300,000 standards, I think. It addresses the informaticists who are doing the terminology bindings to the information model. And then the developers who are really, that's where the action is. Those are the people who are out there using the FIRE. Our hope is we'll use the FIM and make these profiles assist in a significant way in achieving interoperability so that your health data is available to you and those who provide your care when you need it, where you need it so they can use information and clinical decision support to give you the best care possible and to avoid those medical errors, which is just part of the issue. That's not even, medical errors doesn't even get into the whole quality side of things. So that's really, I don't know where we are on time, but that's all I have to say. Please have a seat, Jason. We've got a few questions. Thank you for that. And again, thank you for standing in for Oliver. Absolutely. While you sit down, you might want to give a plug for tomorrow. Yes, yes, thank you. So tomorrow from when we start 8.30, I think, actually, through to 12.30, we will be having a workshop. And Oliver will be talking about smart hospitals in India. And unfortunately, he had a colleague from DXC who could not make it due to visa, but I want to give a shout out to DXC and Phillips and IBM as really major workers in the forum. Tomorrow, we're also going to have people from the Dutch government who are, and this organization called Nictus, who are going to come talk to us about their hospital reference architecture, which they built out in Archimage. So we're looking forward to that. And we would really like to encourage, I would like to encourage, as many people who know and use Archimate to come join us. I used to think, Steve, as you know, that you had to know healthcare to use Archimate in O'Hara. I don't believe that anymore. So I would encourage you to come. Good. Well, on that line of hearing getting people from the Dutch government, and you said you were in the haig last week. First question came in, how are and how does O'Hara and the FIM benefit people outside the US? Oh, cool. So yes, you're right. That was a US-centric talk with some deviations, but so if it benefits people outside the US in exactly the same way that it does benefit people in the US and in some cases, easier. So if you're in a country, let's take the Netherlands since we're sitting in the Netherlands right now, there's universal care. Whether it's a developed country or a developing country, there are governments that take healthcare. I'm not gonna say more seriously. They take a more active, that's all right. They take a more active role in setting standards and requiring coverage and access. Fire is being used all over the world. There are dev days, HL7 dev days in many, many countries. It's HL7 is an international group. So exactly in the same way that it helps folks in the US, the three main standards that are binded to the FIM SNOMED CT, LOINC and RXNORM are used in virtually all European countries, not every one. There's also the opportunity if you're in a country where you use other standards to bind those standards to the FIM and it will work the same to me, mathematical magic that the common logical information model does for interoperability. Okay, okay. How does the FIM handle extensions? Well it's an extensible model and so you simply add on to it. In the sense of fire, you add more resources. So it's an information model, it shows relationships. You can look at it, if you have an allergy condition, who you see and what the nature of the allergy is, is it a food intolerance or not. It's extensible. DeVida, some of you may have heard of, it's the big dialysis company but it's also an insurer built a renal domain. So all you need is people who have an interest and you just add on to the FIM. Want to extend it, right. For the thousands of fire profiles already out there, do you plan to set up a process to extract the templates out of them? Never thought of it. No, but talk to me afterwards and tell me why it's a good idea. I mean, we're talking to HL7 and we're figuring out, this is fairly new, right? We just became stewards of the FIM in September. Right, yeah, very new. This has happened over a year period. So in healthcare, collaboration is so key. The use of other standards. You saw those puzzles with all those different puzzle pieces, all those different standards organizations. So that may be a good idea. I don't know. Okay, last question, Jason. Why would an organization need the FIM if they already have the mature fire available to use? Well, fire is not mature. Fire is not actually even a standard yet at HL7, but like I'm told by them and others, that really good standards get used before they become formal, before they become normalized is what HL7's balloting process, how it works. So first of all, it's not a mature standard. It requires manually building these profiles for information exchange, but if you're a hospital or you're an insurance company or you're a large physician collaboration and you wanna exchange data, not just with one other hospital in your network, but with physical therapy, labs, the number of exchange instances is huge. You don't wanna keep building these things over and over and over again. So really, the argument for automating the building of fire profiles is our low-hanging fruit, and that's what we're going after. Great, Jason, thank you very much. We'll leave it there. Thank you.