This transcription is provided by artificial intelligence. We believe in technology but understand that even the smartest robots can sometimes get speech recognition wrong.

 Welcome to this week in Health IT News, where we look at three stories in 20 minutes or less that will impact health. It. It's Tuesday Newsday and here's what we have on tap. 12 Ways AI will revolutionize healthcare in the next year. Penn Medicine debuts free machine learning platform. And chime submits a response to C M Ss and O N C on interoperability rules.

So here we go. My name is Bill Russell. We're covering healthcare, c i o and creator of this week in health. It a set of podcasts and videos. Dedicated to developing the next generation of health IT leaders. This podcast is brought to you by health lyrics. Have something within Health IT that is going sideways.

Let's talk. We deliver turnarounds. Visit health lyrics.com to schedule your free consultation. We are the fastest growing podcast in the health IT space with news and interviews that are targeted to the application of technology in healthcare. We have two shows a week this week Influence Every Friday, which is a discussion with industry influencers.

And Tuesday is Newsday, as we said earlier this week, news, where we explore the news that's impacting the professionals that are focused on the use of technology in the, in the delivery of health. Uh, if you enjoy the show, please share it with a peer. If you have a story that you would like us to cover, please send it to us at Bill at this week in health it.com.

Our first story is chimes response to c m s and O N C on interoperability. In February of this year, the uh, C M SS and O N C released a proposed regulation tackling interoperability, which also addressed, uh, patient access to data, data blocking policies and changes in certification while on Friday.

Chime submitted a 44 page letter to C M S A and O N C outlining a series of recommendations. The letter's really worth a read. I'm gonna go over the summary that Chime provides early in the document, page two of the document, and they address seven areas that are, uh, really high level of what, what they've really dive into in the 44 pages.

Uh, here's just quick summary. So the first one, interim final rules. And essentially what what Chime is asking for is give us more time to respond. The magnitude is great, and the timeline to to respond is too, too small. I mean, there's so many different areas they're trying to address here. Uh, patient ident identity, uh, information blocking, certification, penalties.

There's so much to address. Just coming out with a final rule and giving them . Uh, a short period of time to respond is not enough. So they're saying give us more time to respond. Give us interim final rules so that we can respond, uh, at multiple occasions. So the second is really timelines. So, , they're saying, Hey, 24 month timelines, uh, to implement certified technology or a d t changes is not enough.

Let's make it 36 months. Part of that rationale is that some, uh, entities didn't really fall under the incentives to implement certified technology, and because they haven't, if you now broadly address this across healthcare, , you're going to put an undue burden on those, uh, organizations that weren't, uh, provided incentives to put certified technology in place, uh, originally.

So, you know, move that from 24 to 36 months is essentially what they're asking for. The next section is, is about information blocking. And, uh, this addresses a couple different areas. The first is penalties. What they're saying essentially is that the, the defined . The, the thing defined as, uh, healthcare providers, which is hospitals, health systems, and a bunch of other things, um,

That there already are penalties in place for a lot of the things that are being talked about in this, uh, proposal from the O C and C M S. And essentially, you know, you're double-dipping here. You're gonna create, uh, you, you're just creating too many penalties on top of penalties. So we already have penalties to address healthcare providers.

Maybe these penalties need to be more specific to, uh, certain, uh, entities or actors as they're defined here. That, um, would make more sense 'cause you're, you're inviting more actors in with the use of APIs and other things. Let's address the penalties there not on providers which already have a host of penalties that could, uh, easily be enforced against the acts that they're talking about in this, uh, proposal.

So, uh, the second thing under information blocking is to find the actors. And this is a really interesting one because without stating it right, you know, they essentially say . Hey, you know, apple and others don't fall under hipaa. And so this, this, this protected data, this data about the patient is being moved into the Apple ecosystem and it's, it's not being regulated at all by hipaa.

And so they're saying, Hey, let's level the playing field and let's make sure we protect the patient data in, in all cases, as well as some other things that are associated here. But let's define the actors and let's level the playing field. And then the third thing they talk about is security. Obviously, when you open up APIs, , there's, uh, a lot of concerns, um, in terms of liability.

You know, if somebody comes in via the APIs, connects our data, and then shares it out in a way that, uh, we wouldn't share it out as a health system, you have, uh, some liability concerns there. You also have just safeguards in general. You care about your patients, you wanna protect their data, and so there's, there's a, a back and forth in terms of security and, uh, some recommendations.

Let me see if, uh, Well, the, the recommendations are very specific. You're, you're gonna have to read the document to really get into them, but, um, but essentially, you know, how, how are product providers expected to know what kinds of risks they're undertaking when they connect to the APIs? It, it, it's really a discussion.

It's a back and forth of saying, Hey, provide some more clarity around this. The next section I, I think, is the section that Chime really weighs in heavily, and that's patient id. And so let, let me just cover a couple of things. At C M C M S seeks input on how the agency could leverage its program authority to provide support for those working to improve patient matching.

So patient matching is a significant. A challenge when it comes to interoperability because you have to ensure that the patient, first of all, who's requesting the data, is the actual patient. You're sharing that data with the right patient, and then when that patient shows up to a new, uh, location and they provide data or they're seeking data, that you're, you're matching those effectively.

You need to make sure that the patient who presents is the patient whose record you're looking at. Otherwise, you end up with medical errors, uh, as well as just waste fraud. You, you end up with, uh, uh, multiple tests and all those kinds of things. So patient identification obviously is a critical issue. C M SS is seeking some input here.

Uh, c m s specifically requests input on whether they should expand the use of Medicare id, which, which, uh, chime, uh, is all behind, expand the use of Medicare ID card. Uh, I guess that's as far as you can get without actually having a national identifier. Uh, which, um, which, you know, again, China supports it would expand the ability for health systems to make that match on a, uh, single identifier, which would be, uh, nice as opposed to relying on demographic, a mix of demographic data and, um,

And some other identifiers, phone numbers and, and other things that happen to be there. Let's see, so c m s as an agency, explorers patient matching while not specifically called out in the R five biometrics, has been discussed as a possible option and c m and Chime just wants to point out that, you know, While they support biometrics, there's a, all, a couple of issues with biometrics variability cost.

Uh, it's not really good in all care settings. Uh, there's some other things, connectivity risks and, and some pediatric concerns as well. Uh, additionally, c m s requests feedback on whether the agency should, should support connecting EHRs to other complimentary, uh, data sources. And Chime really focuses in on this and, and I think they focus in on

Uh, using O N C, uh, claims data for patient matching and those kind of things, uh, I'm not sure I would've focused in on that, but, um, . But I, using claims data is a really good way of doing patient matching. And so there's a, there's a discussion and a recommendation around, uh, using the O N C claims data.

Obviously there's a whole bunch of other ways that people do matching in other industries. I think that can be utilized here as well. So here's some of the recommendations in this area, and again, I think this is an area where Chime. Uh, has really spent a lot of time, they've done a lot of research. They, they, uh, launched a couple of, uh, programs that didn't necessarily pan out, but that really moved the ball down the field.

So, uh, the recommendations are add patient matching to, uh, certification requirements that the vendors must meet. At a minimum, vendors should be required to attest to their matching rate. I think that's a great recommendation. Uh, make it a violation under the data blocking not to share patient matching rates.

Again, just doubling down on that first recommendation. Uh, support the standardization of some demographic data, uh, particularly applying the US Postal Code Service, uh, to address on some c m s data. So essentially what they're saying is, Hey, can we, can we standardize, I mean c m s and health systems and whatnot, if we can provide some standards around that

Just basic demographic data, that's gonna go a long way. Uh, fourth thing is advance the addition of other regulatory of, of other regularly collected data elements such as email address. Uh, to the, uh, U S C D I and add Medicare ID to the U S C D I, you know, the Medicare ID is not, uh, again, they, they note this in the, in the overall document, that not a big deal for health systems to put another ID in there.

Medicare id, uh, is collected by a bunch of health systems already. It could be collected by all of them, uh, with, you know, just a simple tweak to the, uh, E H R. So, uh, some good recommendations there and some strong recommendations and, uh, around that. Um, you know, chime has spent a lot of time there and is really, uh, voicing the, uh, the, uh, the, the pragmatic concerns of patient matching across the board.

So the final three categories that chime addresses, uh, real quick health it, and support of the care continuum. Obviously outside of the four walls of the hospital, now you have. Some, uh, some challenges in terms of maintaining that, uh, the continuity of the record and, and interoperability across that care continuum.

And what they're saying is there should be more emphasis on the ability to ingest, not just the ability to provide the data via APIs. Uh, good recommendation, obviously without standards and, and those kind of things, you end up with some challenges in terms of ingesting the data, even if it is provided via an a p i.

And then the final, uh, the final area that they address is the, uh, conditions of maintenance around the, uh, CURES Act. And this is around information blocking assurance of, uh, exchange of data, uh, communication with regard to health. It. And those kind of things. So the, the Cure Acts, uh, the Cures Act placed no limitations on the protection of communication.

Uh, i e gag clauses between vendors and providers and the O N C has proposed to broadly interpret the subject matter of communications that are. Protected from violations of the maintenance of certification, and they go on and talk about those things. Chime applauds, O C's efforts in this area around communications.

It's a thoughtful approach to this topic. Providers have long been plagued by gag clauses, and some have repeatedly been prohibited through contracts to share information, like screenshots, even if it was related to patient safety. So Chime supports the, uh, efforts around communications, which is great. . So the next thing that Chime addresses is the uh, is Fire Is Fire Standard released by the Argonaut Project.

So the Cures Act requires that patients be able to access their information via APIs without special effort. O n C proposes to adopt Fire Release two as the baseline standard for the new a p i standard citing that it's widely adopted across the industry. So, um, O N C gives four options. Option one, adopt Just Fire Release two.

Option two, adopt Fire Release two and three. Option three, adopt fire Release two and four. And option four is adopt Just fire Release. Four and they wanna do this over a 24 month timeframe. So here's what Chime has to say. O N C has proposed only 24 months to transition to release two. While we believe that moving to release four is preferable, we are concerned about the readiness of the industry to accomplish this.

In the short proposed timeline of 24 months from the time the final rule is published, there are providers and vendors at different levels and, and adequate time is needed for the industry to adapt. It is our belief that those who are already leading with the use of fire start with either release two or three.

Further, at the Argonaut Council meeting held in February, it was largely agreed that including input from some of the vendors, including input from some of the vendors that the industry should move forward with release four. So Chime comes down on, um, option four, which is adopt. Just fire release four.

But if you have to start somewhere, go ahead and start with option two and then rapidly move to release four. That's what they have to say around fire. And then to close this out, they go on to talk about APIs and they want to require app management companies to obtain a business associate agreement, b a a with providers or establish a safe harbor for providers in the event.

Data is released by a third party app, which is not intended by the patient. We talked about this with Anise Chopra at himss, and the challenge here is that you know you're gonna have the ability to provide the APIs out as a provider, and then these third party developers are gonna be able to access the data.

Let's assume they do everything right and they access the data correctly on behalf of the patient they provided to the patient. And that whole, uh, supply chain works well. Um, but they have a breach or they release the data in some other way that they shouldn't release it. Uh, what they're asking for is that there's essentially some way to protect the healthcare provider who is just following a government regulation and providing that data.

but, uh, is not really responsible for that data being released, but, uh, can through this, uh, proposed rule, be held responsible. So, uh, this is, this is a conversation that needs to happen. It needs to be ironed out before we just widely make these APIs available. So that's a, uh, good call on chimes part. And then the last thing is just about real, real world testing, which we, uh, focused on a little earlier, which is, You know, let's focus on ingesting the data as well as providing the data through, uh, APIs.

And they go on to tack on this one last thing, which is including, uh, requiring vendors to be able to accept their own ingest, their own c c D, which is a, uh, you know, pretty sound recommendation when you think about it. So we spent an awful lot of time on this story. I wanna jump to our next story. . So a C I O Friend, uh, posted this out on social media.

It's 12 ways AI will revolutionize healthcare in the next year from health data management.com. And the reason I love this article is I, I continually have people asking me, you know, where, where do you practically see AI being, uh, implemented? And it's not only this article, but a couple others I'll, I'll share with you that, uh, we're just, I.

Every article I read now, feels like has AI in it. So let me give you some of the ways, uh, re re-imagining medical imaging. Uh, researchers are using AI-based approaches to increase the power of mammography, transforming it to a more targeted tool for assessing breast cancer. For, for example, a team in, in Massachusetts leveraging machine learning.

Multiple ways to improve breast cancer screening. The researchers developed an AI based method now in clinical use, and the article just keeps going on and cites these improving predictions of suicide risks. Streamlining diagnosis, automating malaria detection, offering a window on the brain using AI for eye health and disease, amplifying fire's, use of.

Health information exchange. We're seeing, uh, AI and machine learning start to be applied to, uh, normalizing data and making data available, uh, which is really interesting. Reducing the burden of healthcare administration. AI could stabilize, uh, or could, uh, have an impact on a, a sizable impact on medical coding and billing, enabling a revolution in acute care stroke, uh, again, and they, they cite, uh, another study here, uh, narrowing the gaps in mental health care as well.

So identifying it, uh, earlier on or when people present, uh, identifying opioid, uh, uh, and, uh, abuse and alcohol and other things. . Uh, bringing voice first technology to healthcare. So we talked about that at at HIMSS with, uh, with, uh, nuance about some of the things they're doing around machine learning and ai and, uh, unmasking the potential for intimate partner violence.

Um, you know, you can, you can apply machine learning and ai. It's really good at identifying patterns, at seeing and understanding patterns. Uh, well before humans do. And when it does, it can, uh, you, it can, it can essentially bring those to the forefront, make those, uh, uh, identifiable for the caregivers so that they can address those things.

So I, I, I think there's a ton of these stories out there. We're seeing 'em over and over again. I had a couple other stories, uh, but in the interest of time, I . See, um, but you're gonna hear a lot of machine learning and ai, uh, things coming down the pike. This is a great story. Health data management, uh, may, let's see, May 20th,

issue. I can't read that. It's too small. I need better eyes. Maybe machine learning and AI will help me with that someday. Our last story and I think is, uh, you know, again, another example of of what's coming down the Pike. Penn Medicine debuts free machine learning platform. This was in healthcare IT news.

Uh, it's an open source, uh, open source platform that Penn, uh, is, uh, making available. Uh, for biomedical research and it's, uh, it's interesting from two perspective, uh, from multiple perspectives actually. Um, but the thing I'm gonna focus in on is not the machine learning platform 'cause I'm sure it's fantastic.

Um, I. But I'm gonna focus in on the open source aspect of it. I think we're gonna see more and more of this. I think we're going to see, uh, health systems start to open up those platforms so that people can see behind the covers and see, uh, the analysis that's actually happening. They can actually see how the variables are being manipulated and they can, uh, look at those, uh, mechanisms so that they can, uh, really analyze the data better, utilize the data better.

Uh, Uh, within, uh, clinical care settings. And I think you're just gonna see, and plus you're gonna see a more rapid development on top of their platform and the ability for health systems to open up and to invite others in as co-creators in new solutions. So I think this is a, I think this is an exciting trend.

Uh, it's not only, uh, Penn Medicine. I think there's another one that's cited in here. There is, it's, uh, . , uh, children's Home of Cincinnati, uh, is, is, uh, utilizing clat Health. It's teaming up with Children's Home, um, on pilot study around artificial intelligence, powered by mobile decision to app support. So you're, uh, Walters CLOs doing stuff around lo so you're seeing, again, machine learning AI is gonna be everywhere.

I think this open source . Uh, approach to it is also gonna be interesting to watch. I think you're gonna see more of it. I think instead of, uh, organizations trying to monetize, um, applications and software, I think they're gonna start to, uh, really focus in on their core business. I. Go figure and, uh, make these things available so that they can get really good and really efficient and really effective at their core business.

So, uh, kudos to Penn for, uh, jumping out and taking a lead there that is, uh, phenomenal and, uh, you know, really look forward to seeing more and more health systems. Take that route. So we have an exciting show this Friday with, uh, Dr. Andrew Rosenberg of, of Michigan Medicine. He joins us to discuss, uh, experience and we put, we look in both directions.

We look in the, uh, In internally, uh, the internal, uh, experience of users of health it, and we also look at the consumer experience, the external, uh, experience as well. Uh, this past Friday we had a quick visit with Chad Brizendine. Uh, you'll want to check that out. He is, uh, exceptionally smart and practical.

In his approach, I thought he shared some, uh, great things around transparency. Uh, plus we have many more guests coming up. Eric, I, Blanca, Stanford, Charlie, Lockheed, blockchain entrepreneur, uh, Andrew, Andy Crowder of Scripps is gonna be on. Um, and we have several others lined up. And that we're working on scheduling right now.

So if you want to hear from someone, just drop me a line at Bill at this week in health it.com and let's see if we can get them, uh, get them on the show. This show is a production of this week in Health It. For more great content, you can check out the website at this week in health it.com or the YouTube channel at this week in health it.com/video.

Thanks for listening. That's all for now.