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.

Follow Us

Have a question or topic idea?

Transcript

Hi, I’m Charlie Harp, and this is the Informonster Podcast. Today on the Informonster Podcast, we’re going to be talking about FHIR. No, not the flammable substances, but the actual FHIR standard and the terminology resources specifically. And today with me, I have Carol Macumber, our EVP of Client Services, and Carol Graham, who is the product manager for our Pivot product and FHIR related product enhancements or product offerings. I’d like to go ahead and start by asking Carol Mac to give us a little background and talk about her involvement in FHIR.

确定。Uh, hi, everybody. So, uh, Carol Machamer. Um, I’m currently a Vocabulary Work Group co-chair, uh, with HL7, 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 copious spare time, I’m also the vice-chair of the HL7 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 FHIR, um, and other products within the HL7 family.

Great, thank you, Carol. Carol Graham, how about you?

Hi, I am a hybrid of clinician and technical person by background. I’m 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 HL7, and I’m responsible here, at Clinical Architecture, for the ways that we use FHIR in a number of different products.

Excellent. And I am Charles Harp, CEO of Clinical Architecture, FHIR enthusiast, and a big fan of both Carols. I know we’re going to get into some topics around terminology resources, release plans, and other things relative to FHIR, 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 FHIR, how would you like to give like a quick FHIR elevator speech?

确定。FHIR是一个缩写,代表H F irFast Healthcare Interoperability Resources, and it’s the latest generation of interoperability standards in healthcare. It’s owned and approved by HL7, 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, JSON, et cetera. And so the key concepts in FHIR are kind of an uncoupling of the data, which is referred to as resources, and the services or 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 HL7 V2, which is more transactional or event driven, or CCDA, which is more kind of document driven, FHIR 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.

Thank you, Carol. Carol Macumber, you got anything additional on that?

I guess I would say, for a lot of people, their familiarity with FHIR, 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 US federal government, uh, with regards to providing standardized patient access API application interface access, and FHIR has been deemed both by the Center for Medicare and Medicaid services and HHS’s Office of the National Coordinator as the standard, uh, that would be utilized for that exchange.

One of the things that I think is interesting about FHIR, when I first heard about fire years ago, it was probably at an HL7 conference or AMIA, and it represents a pretty powerful idea because in healthcare we still have all these silos of information, and these barriers to interoperability, and FHIR is really, I’ve always seen FHIR as this mechanism for the canonical normalization of data. So unlike HL7, which is, really, the HL7 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 FHIR because a lot of people I think get hung up on, “Well, how is it different than HL7?” And you guys correct me if you think I’m wrong, but to me, what FHIR tries to do, as opposed to saying, “Here’s a container to send a message about a thing that you want to do,” FHIR 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?

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 FHIR’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 FHIR. 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 healthcare information.

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.” FHIR 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 FHIR terminology resources, and what’s next? Who wants to take a crack at that one?

I can start. And I’m sure Carol will help me fill in some gaps here. A part of the, you know, kind of foundation and infrastructure of FHIR 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 concept maps, is seen across all of the resources, within the FHIR ecosystem, whether they’re considered kind of infrastructural or internal FHIR 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 LOINC, and SNOMED, 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 are our current normative resources within FHIR, 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 normative of release, as we within the Vocabulary Work Group, kind of see that as being fundamental. The operation, some may find, you know, are too basic, in terms of what they allow you to do with a conformant FHIR terminology service. You know, we might be talking about that kind of here, as part of the podcast. But what is included are the basic functionalities that we’re anticipating that people need, in terms of interacting with terminology within a FHIR server. Uh, so you know, 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, given 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, and along with, you know, a very immature resource for those who are developing terminology services, called Terminology Capabilities, which allows the FHIR terminology service to communicate with the user what it supports. So what operations it supports, what resources it supports, and just as importantly, kind of what kind of systems it supports and what my default behavior is, when you’re interacting with my FHIR terminology service.

Thank you, Carol. Carol Graham, as the person that tries to make sure that we’re staying current with our products dealing with FHIR 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 FHIR terminology standard?

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 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 FHIR offers. Obviously, I 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 FHIR 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 there, 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, FHIR 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 FHIR has enabled that in ways that its predecessors just couldn’t do, and I think that’s also really interesting.

谢谢你！所以,当我们看FHIR的未来,you know, FHIR had kind of a slow burn, if you’ll pardon the pun, at the beginning. The most exciting thing about FHIR to me is the rallying cry. 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 FHIR is an ecosystem. So one of the reasons why I think FHIR 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 FHIR 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 FHIR and interact with FHIR. But one of the things that, I think for some people, is a struggle is the release cycle process for FHIR. 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 of R5. And so I guess my question would be, based upon what you guys know with FHIR 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?

是的,我的意思是,我认为这都是关于角度来看,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 had 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. Otherwise the interoperability really isn’t there. As far as FHIR 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 US 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 R4 and are still, you know, working through that process, won’t have to already start thinking about, you know, R4 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 FHIR management board, along with, you know, the HL7 community, has landed on some tentative timeline for the next few releases (sic). And the next one is actually kind of an interim, R4 B, that is, really, has been born of the need for some new resources within the medication space, or pharmacy. Right? So medication definition, along with some evidence-based medication resources. So R4 B, which is kind of slotted for the January, 2021, uh, ballot cycle, will be a technical correction with very limited new resources. And I can tell you, you know, from the Vocab Work Group perspective, we would love see concept map included in R4 B with some corrections and improvements, not necessarily to normative status, but some improvements that have taken the last, you know, six to eight months for the vocabulary community to come to agreement to. The prospect of waiting for R5, um, which would start somewhere on the may 2021 ballot, for content feedback, and not be into normative and SDU cycles until September, 2021, so that’s a year out from now, and not published until, you know, Q2 of 2022, is somewhat daunting. It has to be. And I think they’re doing a decent job of trying to balance those needs, with the fact that the industry, you know, can’t deal with, or keep up with any turn faster than that.

What are some of the successes that you guys have seen, relative to FHIR? 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? Carol Macumber?

确定。I mean, I think there are, there are a few examples. I mean, I think, you know, for those of us, in the US who are looking for standardization, you know, across, uh, the large EMRs, and the payers, and so on, you know, looking to US core, and the progress that ONC is making, in terms of supporting the effort for there to be a US based and focused implementation of FHIR, you know, we can look to US core and how that’s been collaborating with the other groups at ONC to align with things like USCDI, uh, I think to bring the next level of sophistication of standardization within the US. Although it’s not finalized, and there are still, you know, versions of US core being developed, I think that’s a good sign; a sign in the right direction. Just the reality that was, uh, brought to light with COVID and how, we aren’t quite ready to not only take in data, standardize, analyze it, and share it in real time, with a pandemic in play, I think is a motivator for a lot of people, you know? I think I read an article recently, you know, that kind of talked about how terminology and standard are at the core of improving decision-making and reporting patient data across that care continuum because COVID, obviously, you know, kind of showed how there’s all of these scenarios where a patient would be moving from primary care to 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 terminology standards and just exchange standards, like FHIR, can help reduce the time spent in trying to manually resolve differences in the data that’s being received, and increase the efficiency of exchanging, and tracking, and reporting that kind of information across the various systems and throughout that patient’s journey.

Anything to add Carol Graham?

I think that really covers it.

So one of the things about FHIR that’s, I think sometimes people don’t completely understand, is FHIR is 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 FHIR 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 in FHIR?

是的,当然。我可以开始。我的意思是,所以对于那些of you who aren’t familiar with our alphabet soup within the HL7 community, UTG stands for Unified Terminology Governance. And really that, you know, that project, which is 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 HL7 community. So what that means is they’re putting in place new tools and processes to guide the process by which content that’s used within the HL7 product families is maintained and harmonized, right? So, there is a lot of content that’s used in V2, V3 and FHIR that are semantically equivalent, yet exist in different code systems. 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, and providing a single code system resource or identifier. And what it’s also doing is providing a place for the implementers, who are creating implementation guides, to get help with creating code system resources and value set resources that are going to be used within products like FHIR. It also, you know, kind of brings continuous integration and release to the HL7 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 and get approved changes to some of the HL7 code systems. With modernization comes a lot of advantages, but also it 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 lots of opportunities for people to take a look at UTG and what’s being planned, and coming out of HL7, and provide some feedback for boots on the ground and people implementing terminology services, about how that content can be packaged and consumed.

Excellent. Thank you, Carol. Carol Graham, when people need to get content from FHIR, where do you go to get that? Where do you get the value sets from?

Well, if you don’t want to get it from us in our terminology platform, the value sets for FHIR – there are downloads right on the webpages for the FHIR 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 HL7, either through the UTG website, or through the FHIR 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 subscribable content, if folks need terminology beyond what is directly coming from HL7.

是的。我的意思是,我觉得最之一practical reasons why people should be excited about UTG is its ability to package all of the HL7 content that’s not ballot-bound in one single place, making it available via web browser, and in a single package, has never happened in the history of HL7 before. For those of us who have been working with HL7 content painfully recall, you know, getting each HL7 V2 version, getting the HL7 V3, getting the FHIR 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.

I mean, but let me ask a question about that because you guys 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 ontologies based on a set of rules. 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?

所以的价值,并不是意图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 UTG. A lot of the code systems that are utilized within HL7 products, you know, especially within the finance and payer area, 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 metadata associated with that external proprietary third system, along with its a unique identifier to ensure consistency across HL7 implementations, and a naming system resource, which we haven’t really talked about previously, that allows for, you know, alternative identifiers, including things like [inaudible].

So earlier I talked about success stories with FHIR. We see a lot of excitement with FHIR, and people are starting to think about using it as a persistent messaging function and not just kind of this ad hoc request. And I might say these wrong, so you guys can jump in and help me, but you’ve got FHIRcasting, 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 FHIR 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 FHIR to help solve some of these problems we have in healthcare?

A lot of people, when, when you start talking about FHIR, they have concerns around, you know, kind of scalability, right? It’s fine in theory to have, 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 FHIR scale? And then I think there are some kind of efforts that are being led, either through government initiatives, um, or within the FHIR community, to kind of address that concern about scalability. Um, so there’s, you know, the FHIR bulk data, there’s a proposal going through the HL7 community for balloting in May, around ONC’s FHIR At Scale Taskforce, which no one will be surprised, has an acronym. And this one is FAST 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 data that’s passed along and included within healthcare content. Um, you know, security and privacy, and I know there’s efforts underway within those groups also to try to address some of those gaps.

And maybe something about provenance as well, that’s becoming more and more at issue. And certainly FHIR 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 provenance becomes in authenticating the data and knowing that we got the most current, right thing from the place it came from.

绝对的。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 the more we try to leverage fire to span these systems, the more that that’s going to be something of interest and probably not just with FHIR, too. But I think, 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 FHIR around that?

Um, yeah, I, I will admit the genomics area is not my area of deep specialized knowledge, but I can say, you know, that there is a large genomics community that have been working towards, uh, developing resources to exchange genomic information, and they have brought to the table new code systems that probably weren’t in play, or have been widely utilized within the HL7 world, to the table and for getting them documented and identifiers, you know, standardized for them. And, and I think FHIR, you know, is providing that motivation.

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 genomics group and FHIR are trying to undertake to help solve both.

绝对的。我的意思是,导致基因组学仍是一样,it’s still very young, that’s going to be interesting, no matter, no matter where we go and if you’ve got two problems. One is you’re dealing the massive data-set, 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 FHIR grapples with it, since I’m an engineer first and other things after. One of the things that Carol mentioned was, you know, FHIR at scale. And I think that people have to remember FHIR 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 FHIR layer there, every single one of these systems you deal with has a different internal canonical model. the way they representation data is different. And I dealt with this back when we were at Zynx and 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 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 and ad-lib. 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 FHIR wants and the way FHIR 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 FHIR, so that I can send it and say that I’m FHIR compliant?” And I think that’s one of the things a lot of people don’t think about, and don’t 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 and 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 FHIR because as people continue to augment what they want in those resources, even things that 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 FHIR. But if people can’t populate that model because their systems just aren’t sophisticated enough to do that, FHIR itself can’t fix that canonical gap. Sometimes going from my internal data model to a standard, whether it’s FHIR, or HL7, or CCDA, or whatever it is, OMA, 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 when 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 in FHIR, if we’re part of a 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 FHIR require, and is the FHIR model suitable for what we want to do in our system?” Because the closer we get to FHIR, as we start rolling out new capabilities, the less work we have to do to accommodate FHIR. Like when we develop things at Clinical Architecture that use patient data, whether you’re talking about in our ClinEvolve product, or in the inferencing model for Symedical, or whatever we do, the first place we go, correct me if I’m wrong, we look at the standards. We say, “What do 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 healthcare shouldn’t stop and say, “What do these really smart people think that we would need?” FHIR, because it’s practical, it doesn’t have all the weird abstraction that say, you know, the HL7 RIM model had, where I kind of appreciated what they did in the RIM 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 in healthcare.

不过,在我看来,这一概念的way FHIR 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?

是的。I mean, and there’s some kind of like easy gimmes, in terms of, you know, how, you know, government bodies, like the ONC, that are making recommendations can utilize FHIR 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, 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 the ONC rule, and the APIs, and the FHIR 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.”

确定。I think the only challenge is people giving real email addresses. (Laughs)

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.

I’m much more likely to give a wrong phone number or email address on my little, uh, barcode card that goes at the grocery store than I am to my doctor. I want her to be able to reach me.

是啊!电子邮件地址。我的意思是,有一些,他们的re there because a lot of times that’s what you use as your login into your patient portal. So no, it doesn’t, uh, unless you’ve, you know, got seven different identities, it doesn’t behoove you to provide, you know, erroneous emails. Obviously still some issues there, but just kind of an example.

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, and 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 FHIR terminology services at Clinical Architecture, and the initiatives we have around that. You want to talk about that a little bit?

确定。One of the things that we undertook to do, when we built FHIR terminology services, is to give that standardized interface into the services. So obviously folks who are familiar with our Symedical platform know that we have a very robust suite of 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, a full-blown FHIR server, we certainly wanted to be accommodating and provide FHIR 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 four compliant, in QA now we’ve had STU-III services for a while. We still maintain backward compatibility to DST U2. We hope to retire that fairly soon, obviously, as 4B and R5 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 Symedical with the industry standard that is FHIR terminology services.

Are there any events coming up around FHIR in the next, between now and, let’s say, the end of 2020? I mean, AMIA is coming up, but anything else?

Well, we just finished with the Fall Work Group, where all the big work groups at HL7 convene 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 FHIR Dev Day that is coming up. I forget the exact date, but it is in November. 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 Connectathon, but those are the HL7-specific events that are coming up. What else would you say, Carol Mac?

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 FHIR Connectathons go pretty quickly.

Yes it does. And I mean, obviously, you know, we have a new product in the pipeline that’s FHIR enabled, so at some point we may talk about that at one of the Connectathons or other industry meetings, so we won’t be invisible at all of those going forward.

是的。And I’ll, I’ll use this opportunity, you know, to put my HL7 volunteer and vocab co-chair hat on to encourage any of our listeners here to participate in the FHIR Connectathon with, 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, or Rob Mcclure 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 beverage of your choice if you do so.” Sometimes we get lucky. A lot of times people show up, the developers show up at those Connectathons,, 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 and 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 Connectathon, 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.

Excellent. Well, anything else either one of you folks would like to put out there before we wrap this up?

Not for now. I just think we’re under our quota on FHIR puns for a conversation of this length. So it’s a – that’s a miss for us.

I don’t know Carol. I can feel the burn.

Well, that’s a sure-FHIR way to end this podcast, ladies and gentlemen. Um,

Podcast AKA FHIRside chat.

There you go.

That might be the title of this thing when we’re done, “FHIRside Chat with Charlie and Two Carols.”

Carol one and two.

Carol 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 part to make FHIR 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 Harp, and this has been the Informonster Podcast. Thank you very much.