On this episode of the Informonster Podcast, Charlie Harp discusses FHIR, from its design, history and implementations to its unique quirks and possible future uses, with Clinical Architecture’s own FHIR Services Product Manager, Carol Graham, and EVP of Client Services, Carol Macumber.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
On this episode of the Informonster Podcast, Charlie Harp discusses FHIR, from its design, history and implementations to its unique quirks and possible future uses, with Clinical Architecture’s own FHIR Services Product Manager, Carol Graham, and EVP of Client Services, Carol Macumber.
Contact Clinical Architecture
• Tweet us at @ClinicalArch
• Follow us on LinkedIn and Facebook
• Email us at informonster@clinicalarchitecture.com
Thanks for listening!
[inaudible]
Speaker 2:Hi, I'm Charlie harp. And this was the ProMaster podcast today on the informants or podcast. We're going to be talking about fire. No, not the flammable substances, but the actual fire standard and the terminology resources specifically. And today with me, I have Carol McCumber, our EVP of client services and Carol Graham, who is the product manager for our pivot product and fire related product enhancements or product offerings. I'd like to go ahead and start by asking Carol Matt to give us a little background and her talk about her involvement in fire.
Speaker 3:Sure. Uh, I am, uh, Carol Machamer. Um, I'm currently a vocabulary work group co-chair, uh, with HL seven, which means, you know, I'm part of the group that has responsibility over the terminology services, resources, and related operations. Um, and in my other copy of spare time, I'm also the vice-chair of the atrial seven terminology authority who has the responsibility of managing some of the relationships with the external code system owners that contribute content that's used in fire, um, and other Onyx within the HL seven family.
Speaker 2:Great, thank you, Carol. Carol Graham, how about you?
Speaker 3:Hi, I am a hybrid of clinician and technical person by background on both a registered nurse and have an it background, basic it training I could say. And so I've done clinical care in the past and been doing healthcare it for about the last 20 years and been at clinical architecture three. And so I participate in the vocabulary work group at HL seven, and I'm responsible here at clinical architecture for the ways that we use fire in a number of different products.
Speaker 2:Excellent. And I am Charles Park, CEO of clinical architecture, fire enthusiast, and a big fan of both Carol's. I know we're going to get into some topics around terminology, resources, release plans, and other things relative to fire, but one of the things I think would be good. And I'm going to ask you Carol Graham to do this for somebody who's dialing into the podcast or tuning into the podcast that doesn't have a clue about what we're talking about. When we say fire, how would you like to give like a quick fire elevator speech?
Speaker 3:Sure. Fire is an acronym F H I R. That stands for fast healthcare interoperability resources, and it's the latest generation of interoperability standards in healthcare. It's owned and approved by HL seven and published through ISO standards as well. So it's ISO compliant, et cetera. And it's an international standard for exchanging patient data and clinical data in healthcare. It's based on rest as a services paradigm, and data can be exchanged in a number of different formats. XMO Jason, et cetera. And so the key concepts in fire are kind of an uncoupling of the data, which is referred to as resources and the services are the operations that you can do on the data. And that helps with exchanging data in a number of different ways. And it's the next generation of interoperability. So that unlike say HL seven 82, which is more transactional or event driven or CCDA, which is more kind of document driven. Fire is kind of a hybrid that lets you mix and match the pieces that you need to achieve the data exchange that you're looking for for your particular use case.
Speaker 4:Thank you, Carol. Carol Machamer. You got anything additional on that?
Speaker 5:I guess I would say for a lot of people, their familiarity with fire, perhaps, you know, where they started hearing about it first is, you know, within rules that we see coming out of our, you know, at least the U S federal government, Oh, with regards to providing standardized patient access API application interface, access, and fire has been deemed both by the center for Medicare and Medicaid services. And HHS is office of the national coordinator as these standard, uh, that would be utilized for that exchange.
Speaker 4:One of the things that I think is interesting about fire when I first heard about fire years ago, it was probably an NHL seven conference or AMIA, and it represents a pretty powerful idea because in healthcare we still have all these silos of information and these barriers, interoperability and fire is really, I've always seen fire as this mechanism for the canonical normalization of data. So unlike HL seven, which is really the HL seven standard has been around forever. When you look at the two dot X standard, it's really a messaging format and you have a message and the message has a purpose and you bundle things up in the message. There's a lot of wiggle room in the messages, the segments, it's a container for moving information. It's a little bit different than fire cause a lot of people I think get hung up on, well, how is it different than HL seven? And you guys correct me if you think I'm wrong. But to me, what fire tries to do, as opposed to saying here's a container to send a message about a thing that you want to do, fire is really saying, take the data that you have in your system when I need it. And here's a standard canonical representation that I want you to put it in. So that we're all talking the same thing, the same bits for this type of data, as opposed to here's a container to put your data into. Does that make sense or do you guys think I'm way off base?
Speaker 5:I mean, I think that makes sense. And you know, one of the differentiating factors, and I think part of the reason that people or implementers kind of love, you know, the approach that fire's taken in terms of how the standard is being developed really is a focus on implementation and implementers and applying this like 80 20 rule when assessing, you know, what changes should or could or would be made to fire the fact that it's an international standard that allows for extensibility and extensions brings it to the table as something that can transcend borders, I suppose, but still provide a standardized way to exchange health care information.
Speaker 2:Well, it's got, I mean, Graham grieve, it has a very pragmatic roots. It wasn't like some standards. It kind of evolved out of a group of people saying, Hey, we want to do this fire actually evolved out of somebody trying to solve an actual problem. And then it kind of evolved from there. Okay. Well on our agenda, one of the things we have is fire terminology resources, and what's next? Who wants to take a crack at that one?
Speaker 5:Nope, I can start. And I'm sure Terrell will help me fill in some gaps. Here is a part of the, you know, kind of foundation and infrastructure of fire terminology plays a very special and critical role terminology is in the need for standardized terminology through the use of things like code systems and value sets or, or concept maps is seen across all of the resources, um, within the fire ecosystem, whether they're considered kind of infrastructural or internal fire terminology to support things like resource status and other things that are tied mainly to the messaging standard, all the way to the use of external terminologies and incorporating Pointe and snowman and other clinical terminologies into the mix, the current resources kind of support that base functionality of describing your terminology, your code system, and the metadata associated with it, then providing you a resource to exchange that through the value set resource, those two or our current normative resources within fire, where we're looking to then next kind of bring, you know, the reality of concept map and ability to associate concepts from different code systems with each other to the next probably normative release. So not necessarily this interim one that's being planned, but into the next moment of release. As, as we within the vocabulary work group, kind of see that as being fundamental, the operation, some may find, you know, are two basic in terms of what they allow you to do with a conform it fire terminology service. You know, we might be talking about that kind of year as part of the podcast. Uh, but what is included are the basic functionalities that we're anticipating that people need, uh, in terms of interacting with terminology within a fire server. Uh, so you, the ability to look up codes within a code system to validate that a code is a member of a value set and, or do things like, you know, give me a translation, one code and the target terminology, if it's available within a concept map, give me the associated concept. So, you know, that kind of covers what's there right now. Um, and along with, you know, a very immature resource for those who are developing terminology services called terminology capabilities, which allows the fire terminology service to communicate with the user, what it supports. So what operations it supports, what resources its support, and just as importantly, kind of what kind of systems it supports and what my default behavior is, um, when you're interacting with my fire terminology service,
Speaker 2:Thank you, Carol Carol Graham, as the person that tries to make sure that we're staying current with our products, dealing with fire as a terminology service vendor, what do you think are some of the challenges and some of the things that are interesting about us trying to replicate or work with the fire terminology standard,
Speaker 3:The challenges that we as a vendor face is sort of what Carol alluded to, and I'm gonna build on it a little bit, is that as a terminology company or a terminology and semantic interoperability experts, we have certain ways that are fairly robust and fine-grained of implementing our terminology management. And so one of the challenges is aligning what we have with what fire offers. Obviously I've feel like we've been able to do that fairly successfully, or I wouldn't be doing what I do, but that's one of the challenges. And the thing that I think is more interesting though, is ways that fire enables a lot of new kinds of applications that are really fast and easy to stand up. And so think about the interoperability of wearable devices, being able to send patient monitored data into a clinical application, or to even integrate with a clinical data repository so that patients have their data they're on their mobile device to be able to take with them to an appointment with a doctor or other provider, or think about very specialized uses. Some of the things that we learned about at say far dev days where people who've never done clinical programming before, but they have lived with type one diabetes all their life. And they're able to quickly integrate information from their monitoring device, with information from their insulin pump and create a very customized and highly functional application that can be verified and deployed very quickly. And fire has enabled that in ways that its predecessors just couldn't do. And I think that's also really interesting.
Speaker 2:Thank you. So when we look at the future of fire, you know, fire had kind of a slow burn fuel part of the fund at the beginning. The, the most exciting thing about fire to me is rallying cry.
Speaker 4:People see it as a way to leverage information across the silos of healthcare. And I think one of the things that drives adoption of standards like fire is an ecosystem. So one of the reasons why I think fire has gotten a lot of interest and attention is because it allows for people that are developing applications that help represent data and share data, are able to build things they can sell into the fire ecosystem, which is powerful and also drives adoption and kind of pushing the system vendors to try to do a better job of being able to work with fire and interact with fire. But one of the things that I think for some people is a struggle is the release cycle process for fire. You know, I was on the phone with somebody the other day. Who's, you know, building something that supports, you know, DTS U2, and we're currently staring down the barrel or five. And so I guess my question would be based upon what you guys know with fire and their release plans. When do you think it's going to slow down a little bit? Or what are your thoughts on their release process in general?
Speaker 5:Yeah, I mean, I think it's all about perspective, right? So some may, may think God, the standards world moves so slowly it's monolithic and why in the world does it take a year or is to go from one version to another, whereas others who maybe have, have a little bit more practical experience implementing the standards, realize that programming change costs money. And certainly also makes an assumption that others are moving to another version at the same pace that you are. Um, otherwise the interoperability really isn't there as far as fire is concerned. I think they're trying to balance this, this rapid uptake from the marketplace, but also, you know, the demand from at least in the U S you know, the federal government and the versions that they are writing into law and trying to meet the needs for new resources while also not moving too quickly, that the folks who are just now trying to program are four and are still, you know, working through that process, won't have to already start thinking about, you know, our four B to that. And then I, you know, you can share, you know, that coming out of this September work group. Um, I think, you know, the fire management board along with, you know, the HL seven community has landed on some tentative timeline for the next few releases. Um, and, and the next one is, is actually kind of an interim, our four B um, that is really has been born of the need for some new resources, um, within the medication space. Uh, pharmacy writes a medication definition along with some evidence-based, um, medication resources. Uh, so our four B, which is kind of slotted for the January, 2021, uh, ballot cycle, um, will be a technical correction with very limited new resources. And I can tell you, you know, from the vocab worker perspective, we would love see concept map included in our four B with some corrections and improvements, not necessarily to normative status, but some improvements that hum have taken the last, you know, six state months for the vocabulary community to come to agreement to the prospect of waiting for our five, um, which would start somewhere on the may 20, 21 ballot, uh, for content feedback, um, and not be into normative and Stu site cause until September, 2021. So that's a year out from now, um, and not published until, you know, Q2 of 2022, um, is somewhat daunting. It has to be. And I think they're doing a decent job of trying to balance those needs, um, with the fact that the industry, you know, can't deal with her, keep up with any turn faster than that.
Speaker 4:What are some of the successes that you guys have seen relative to fire things that you would consider to be something that we can look at to show that fire's doing what people want it to do? Drama?
Speaker 5:Sure. I mean, I think there are, there are a few examples. I mean, I think, you know, for those of us, um, in the U S are looking for standardization, you know, across, uh, the larger EMR and the payers and so on, um, you know, looking to us S and the progress that ONC is making in terms of supporting the effort for there to be a U S based and focused, um, implementation of fire, uh, you know, we can look to you at score and how that's been collaborating with the other groups at ONC to align with things like S CDI, uh, I think to bring the next level of sophistication of standardization within us, um, although it's not finalized and they're still, you know, versions of us core being developed, I think that's a good sign, a sign in the right direction to just the reality that was, uh, brought to light with COVID and how, uh, we aren't quite ready to, um, not only take in data and standardize analyze it and share it in real time with a pandemic in play. Um, I think as a motivator for a lot of people, you know, I think I read an article recently, you know, they kind of talked about how terminology and standard are at the core of improving decision-making and reporting patient data across that care continuum. There's, COVID obviously, you know, kind of showed how there's all of these scenarios where a patient would be moving for primary care or emergency care to perhaps back to a hospice or senior care facility, and the ability to make quick decisions and tracking of those laboratory results is necessary. Uh, and the use of terminology standards can help reduce to terminology standards and just exchange standards. Like fire can help reduce the time spent in trying to manually resolve differences in the data that's being received, um, and increase the efficiency of exchanging and tracking and reporting that kind of information across the various systems. And throughout that patient's journey,
Speaker 2:Anything to add Carol Graham, I think that really covers it. So one of the things about fire that's, I think sometimes people don't completely understand is fire as a canonical model. It basically lays out this is what a resource is, and this is what we expect to be in it. And then you have the value sets and the content that is expected in fire. Um, because obviously if you have a standard packaging or a standard canonical format, that's great. But if your data in that format is all different, you still have a pretty significant interoperability problem. Do you guys want to talk about the UTG and content and fire?
Speaker 5:Yeah, sure. I can start off. I mean, so for those of you who aren't familiar with our, uh, alphabet soup within the April seven, uh, community, um, UTG stands for unified terminology governance, um, and really that, you know, that project, which is, uh, being run out of the vocabulary work group aims at providing a more modern approach and tools associated with what was a very slow manual harmonization process within the atrial seven community. So what that means is they're putting in place, um, new tools and processes to guide the process by which content that's used within the HL seven product families, uh, is maintained, um, and harmonized, right? So, uh, there are, there is a lot of content that's used in V2, V3 and fire that are symmetrically equivalent, um, yet exists in different code systems. Uh, and there's not always going to be the opportunity to kind of harmonize to a single code system, but where that makes sense and is possible a UTG aims at identifying those, um, and providing a single code system resource or identifier. And what it's also doing is providing a place for, uh, the implementers who are creating implementation guides to get help with creating code system resources and value set resources, um, that are going to be used within products like fire. Um, it also, you know, kind of brings continuous integration and release, uh, to the HL seven content process. Whereas before harmonization, I think occurred, you know, a few times every year, um, which meant if you missed the latest harmonization cycle, it would take months for you to be able to make it get approved changes to some of the atrial seven code systems. We have modernization comes a lot of advantages, but also raises new questions, you know, for folks, including us and Carol in particular about how do you manage content coming out of UTG. Um, and when is the most appropriate time to pick up a new and integrate into your terminology server? So, I mean, I think there's, there's lots of opportunities for, um, for people to, to take a look at UTG and what's being planned and coming out of April seven and provide some feedback for boots on the ground and people implementing terminology services about how that content can be packaged and consumed.
Speaker 4:Excellent. Thank you, Carol Carol Graham, when people need to get content from fire, where do you go to get that? Where do you get the value sets from?
Speaker 3:Well, if you don't want to get it from us in our terminology platform, the value sets for fire there are downloads right on the webpages for the fire specification. Those are moving to UTG in the future. I know there's a first initial release of UTG that's out there, but I know they're like Carol mentioned, the UTG group are working out some details and cleaning up some of the content, but getting it from HL seven, either through the UTG website or through the fire specification website itself is the original source of truth. And then folks like us who have a terminology platform include that as part of our available subscribed content, if folks need terminology beyond what is directly coming from HL seven.
Speaker 5:Yeah. I mean, I think one of the, they're probably the most practical reasons why people should be excited about UTG is its ability to package all of the HL seven content. That's not valid bound in one single place, making it available via a web browser and in a single package has never happened in the history of April seven before, for those of us who have been working with HL seven content painfully recall, you know, getting each HL seven V2 version, getting the HL seven V3, getting the fire content, all of that occurred from different places in different formats. And with UTG. Now you have the opportunity to get everything in one place.
Speaker 4:I mean, but let me ask a question about that because you guys are know a lot more about this, but is the intent of UTG. So you have the intentional and extensional value sets, the ones that are based on a specific set of codes and the ones that are really based upon subsetting, um, uh, ontologies based on a set of rules that some content updates very frequently. Um, I don't imagine that the UTG is going to get up subsets whenever a terminology update happens. Are they just going to maintain the rules and expect the people that are using the data to actually spend the rule-based value sets? Or are they planning on keeping that current? What do you know about that?
Speaker 5:So for the value set piece, it's not the intent for UTG to act as a live terminology service by which new expansions would be generated. It's more of a repository to represent the versions of those value sets that have been published, right? So if within an implementation guide, a value set has been defined as an enumerated list. It is then, you know, included within UTG repository. And when it's updated by the owners of that implementation guide, because it's published a new version, then the new value set would be registered at versions within your teaching. A lot of the code systems that are utilized within HL seven products, you know, especially within the finance and payer area, um, contain references to proprietary content. In which case, the only thing that exists within UTG is, you know, the code system resource that represents the, met the metadata associated with that external proprietary third system, along with its a unique identifier to ensure consistency across atrial seven implementations and a naming system resource, which we haven't really talked about previously, uh, that allows for, you know, alternative identifiers, including things like oil.
Speaker 4:So earlier I talked about success stories with fire. We see a lot of excitement with fire and people are starting to think about using it as a persistent messaging function and not just kind of this ad hoc requests. And I might say these wrongs, so you guys can jump in and help me, but you've got fire casting where it's kind of a consistent fire communication between two systems and, you know, I'm sure there are plans to continue to enhance and add resources. But when you think about fire and you think about, let's say the next couple of years, you guys have any thoughts about what types of things will get spun up or be developed in fire to help solve some of these problems we have in healthcare.
Speaker 5:A lot of people, when, when you start talking about fire, they have concerns around, you know, kind of scalability, right? It's fine in theory that, you know, like a patient resource and being able to exchange that, but in reality, you know, you're exchanging millions of these and, you know, so how does fire scale? And then I think there are some kind of efforts that are being led either through governance initiatives, um, or within the fire community to kind of address that concern about scalability. Um, so there's, you know, the fire bulk data, there's a proposal going through the atrial seven community for balloting and may around on cease fire at scale taskforce, which no one will be surprised, has an acronym. And this one is fast, fast F a S T exchange exchange metadata using restful headers. I don't know the intimate details about that effort as it just came out. But I think it's indicative of just the community's willingness to spin up these projects as necessary as you know, limitations and gaps are being identified by the community. And I think along with scalability, I mean, I think people, you know, always with sensitivity of that's passed along and included within healthcare content, um, you know, security and privacy and, and I know there's efforts underway within those groups also to try to address some of those gaps
Speaker 3:And maybe something about Providence as well, that's becoming more and more an issue. And certainly is trying to help address that the more interoperability, the more data we exchange from the more places, the more redundancy that there is, the more important that Providence becomes in authenticating the data and knowing that we got the most current right thing from the place it came from.
Speaker 2:Absolutely. I kind of think about data provenance like that is like transponders on an aircraft. These modern data platforms are like airports and you need an air traffic controller to know whether you're going to land that plane or not. And you want to know where it came from and where it's supposed to be going. And so I would imagine more, we try to leverage fire to span these systems. The more that that's going to be a, of something of interest and probably not just with fire too, but I think in, in some of the other standards we have, you know, we've been sharing data for a while now kind of, I think people get data and then they find ways to try to incorporate it. Not always successfully because in a lot of ways we're still learning as we go through this, this kind of journey. But, but I think those are things. What do you guys think about genomics and other types of data biomarker data? Have you seen much development in firearms?
Speaker 5:Um, yeah, I, I will admit via genomics area is not my, uh, area of deep specialized knowledge, but I can say, you know, that there is a large genomics community on that have been working towards, uh, developing resources, uh, to exchange, uh, genomic information. And they have brought to the table new code systems that probably weren't in play or have been, had been widely utilized, um, within the HL seven world, uh, to the table and for getting them documented and identifiers, you know, standardized for them. And, and I think fire, you know, is providing that motivation
Speaker 3:And it, it becomes really interesting too, because it's sort of at minimum a two-pronged problem, right. Of exchanging the underlying molecular sequence information and the ways that we need to harmonize that across the industry for better interoperability. And then also exchanging the observational data. What's the meaning of this genomic information and how does that apply to the patient's care to their medication profiles and all of those kinds of applicability in the clinical world. And so it's kind of two pronged and the group in the genomics group and fire are trying to undertake to help solve both.
Speaker 2:Absolutely. I mean, cause like genomics is still, it's still a very young, that's going to be interesting. Uh, no matter, no matter where we go and if you've got two problems, one is you're dealing the massive dataset
Speaker 4:And you're dealing with a lot of complexity and variation and then you're dealing with, you know, how I can simplify that information so we can compute on it and make decisions and do reasoning based upon things like genetic variances and things like that. So I think it's an interesting space to watch. And I'll be curious to see how fire grapples with it since I'm an engineer first and other things after one of the things that Carol mentioned was, you know, fire at scale. And I think that people have to remember fire is a, is a canonical layer on top of an existing model in all these different systems. And one of the things that I think is interesting when you talk about putting the fire layer there, but every single one of these systems you deal with has a different internal canonical model where the representation data is different. And I dealt with this back when we were at zinc. So we were dealing with orders and you know, the way one system portrays an order and the way the other system portrays an order could be fundamentally canonically different. I mean, one of the examples was always an activity order and you could have something called activity and the order detail is, you know, up and ad-lib, but you could have another place where they don't have the concept of activity. They just have up anabolism. So you've got this canonical difference. And when you go to populate this interoperability layer, the engineers that are looking at what they have in the data model, and they're looking at what fire wants and the way fire portrays the data, you know, they have to make a decision and they have to figure out how do I take what I've got and make it fit into the box of fire so that I can send it and say that I'm fire compliant. And I think that's one of the things a lot of people don't think about, no talk about is that, you know, it's one thing to kind of mandate. Here's how I want you to exchange data, but it's kind of like if you lived in a neighborhood and every Friday they sent out something that said, you're making chicken cacciatore tonight and everybody gets chicken cacciatore and you look in the fridge and all you've got is a can of tuna in a vanilla wafers. You can't really make chicken cacciatore, at least, you know, you can try, you can try to approximate it. I don't recommend it. And I do think that's one of those things that is a challenge with fire because as people continue to augment what they want in those resources, even things are optional. There's an expectation that I'm going to get this package and it's going to look like this. That's the whole basis of fire. But if people can't populate that model because their systems just aren't sophisticated enough to do that fire itself, can't fix that canonical gap sometimes going from my internal data model to a standard, whether it's fire or HL seven or CCDA or whatever it is, I have to put energy and work the structural distance between where I'm going and where I'm coming from. You know, that's measured in work and that work impacts systems. And those systems are the things that get squeezed. You start talking about doing things at scale. You know, one of the things that should happen in our industry is that as people articulate the resources and fire, if we're part of the smart ecosystem in healthcare, what will happen is people who are designing systems will stop trying to reinvent the wheel. And at the very least say, well, what does fire or quiet and is the fire model suitable for what we want to do in our system? Because the closer we get to fire, as we start rolling out new capabilities, the less work we have to do to accommodate fire. Like when we, when we develop things at clinical architecture that use patient data, whether you're talking about in our clinical product or in the inferencing model for some medical or whatever we do the first place we go, correct me. If I'm wrong, we look at the standards. We say, what are the standards need? Because a lot of smart people sat down and tried to figure out, you know, what should be in an allergy resource? What should be in a condition resource? There's no reason why anybody developing a system in health care, shouldn't stop and say, what are these really smart people think that we would need the fire because it's practical. It doesn't have all the weird abstraction that say, you know, the HL seven rim model had where I kind of appreciated what they did in the room model. But a lot of it was, seemed very esoteric to me and not really examining the pragmatic way we grapple and use patient data and help.
Speaker 3:It seems to me though that that concept of the way fire has evolved. And it being practical is what lends itself to that next generation of interoperability and making the kind of thing work that you're talking about about everybody doesn't have to invent their own data model anymore. And gosh, wouldn't it be nice if we could get to that point in healthcare, right?
Speaker 5:Yeah. I mean, and there's some kind of like easy gimmes, uh, in terms of, you know, uh, how, you know, government bodies, like the ONC that are making recommendations can utilize fire to ensure the exchange of certain information that they know can help solve other problems. Right. I mean, I think one of those examples is, you know, in the final version of the rule, it might've been, you know, uh, the ONC added additional data elements or requirements that will make patient matching easier, right. They added previous addresses to what needs to be made available for matching and email addresses. Right? So it's almost like I've had the same Hotmail address since I was 17. I've lived in 10 different places probably since then, you know, but that email address has followed me around. At what point is that something that's starting to be considered? Um, but you know, the combination of, uh, the ONC rule and the API APIs and the fire resources that contain that information could make that possible, right. For people to say, Hey, let's try to use email addresses to help go through process of patient matching.
Speaker 4:Sure. I think the only challenge is people giving real email addresses.
Speaker 5:Hey, if you're going to lie about your address or your email address. Yeah. I mean, nothing's going to help us. Nothing's going to help us organize that
Speaker 3:Wrong phone number or email address on my little, uh, barcode card that goes at the grocery store than I am to my doctor.
Speaker 5:I want her to be able to reach email addresses. I mean, there's some there, there, because a lot of times that's what you use as you're logging into your patient portal. So no, it doesn't, uh, in last year, um, you know, I've got seven different identities. Uh, it doesn't behoove you to provide, you know, erroneous emails, obviously still some issues there, but just kind of an example of
Speaker 4:You're you're talking about, there's a lot of things that we tend to get stuck in a rut it's like refactoring software. Occasionally you look at what you're doing. You're saying, wait a minute, that just doesn't make sense anymore. I mean, the world has changed. We're missing the boat because we're stuck in this rut of looking at things in a very particular way. It's absolutely correct. And true. Carol, you're the product manager for our lovely fire terminology services and clinical architecture and the initiatives we have around that. You want to talk about that a little bit?
Speaker 3:Sure. One of the things that we undertook to do when we built fire terminology services is to give that standardized interface into the services. So obviously folks who are familiar with our sabbatical platform know that we have a very robust suite of API APIs, but we also wanted to accommodate that space where customers might want to have an industry standard mechanism for interacting with our terminology services. And so while we didn't initially want to provide per se and full-blown buyer server, we certainly wanted to be accommodating and provide buyer compliant, terminology services for interacting with the content that we provide through our platform. And so that's what we have today. Our services are or compliant in QA. Now we've had Stu three services for a while. We still maintain backward compatibility to DST U2. We hope to retire that fairly soon, obviously as four B and R five come out. And as soon as our customers no longer need it, then that'll be retired. But that's kind of our general approach of how we map, how we align the content assets and the functionality that's available in a terminology platform. Like some medical with the industry standard that is fire terminology services.
Speaker 4:Are there any events coming up around fire in the next, between now? And let's say the end of 2020, I mean, AMIA is coming up,
Speaker 2:But anything else?
Speaker 3:Well, we just finished with the fall work group where all the big work groups at HL seven convened to get their work done. And as Carol talked about, you know, she's pretty heavily involved in that. So I'll let her speak to that more. If we want to, there's a fire dev day is coming up. I forget the exact date in November. Um, we always participate in that as an attendee. Sometimes we also present and sometimes we engage at the work group Connectathons we did not do that this year because we didn't have a new product to engage with at the connected on, but those are the HL seven specific events that are coming up. What else would you say Carol Mack?
Speaker 5:Well, I guess just, yeah, just the January meeting. I mean, it seems far off, but you know, the three months in between, you know, working group meetings and official fire connected plans go pretty quickly. Yeah.
Speaker 3:Yes it does. And I mean, obviously, you know, we have a new product in the pipeline that's fire enabled. So at some point we may talk about that at one of the connected Don's or other industry meetings. So we won't be invisible at all of those going forward.
Speaker 5:Yeah. And I'll, I'll use this opportunity, you know, to put my April seven volunteer and vocab coach and her hat on to encourage it, any of our listeners here to participate in the fire, connect with them and, and encourage their friends and family to provide their use cases to the terminology services track. Um, you know, often we kind of joke when those meetings are in person, you know, myself or Rob house and Rob Muchler will get up in front of everybody and say, we know you're all using terminology, but you're not interacting with terminology services. We will buy you a better choice if you do. So sometimes we get lucky a lot of times when people show up the developers show up at those connected bonds and they're very focused on their particular implementation and their use case and, you know, proven conformance to the standard and are less focused on, you know, the, uh, standardization of the appropriate use of terminology resources. I think eventually, you know, within the organizations, they get to that portion and they think through that process, but we sure would love to have them participating and interacting with terminology services at the connect with them, because that allows, you know, the people that develop terminology services to see the different use cases, see the data in the wild and improve the resources and the operations, you know, that are being put out there for use by mentors.
Speaker 2:Excellent. Well, anything else, either one of you folks would like to put out there before we wrap this up?
Speaker 3:Not for now. I just think we're, um, under our quota on fire puns for a conversation of this length. So it's a, that's a miss for us.
Speaker 5:I don't know Carol. I can feel the burn.
Speaker 2:Well, that's a sure fire way to end this, uh, podcast, ladies and gentlemen, um, product side chat today, you go, it'd be the title of this thing when we're done fireside chat with Charlie and two Carol's Carol one and two Cal squared. That's right. I really appreciate you guys taking the time. And I'm very grateful to have both of you out there representing us and doing your art to make fire better and help the industry do a better job of making the most of the data that we're pushing around. So thank you to Carol and Carol, and thank you to everybody for listening. I am Charlie at heart, and this has been the infant monster podcast. Thank you very much.
Speaker 1:[inaudible].