FHIR, SMART, CDS Hooks overview

my name is josh mandel i'm the chief architect at microsoft healthcare and the chief architect for the smart health it project and i'm excited to get to share with you today an overview of some of the core standards in health data interoperability that i've been working on over the course of the last decade or so both in my role in the academic world at boston children's hospital and harvard medical school and more recently in my role in industry at microsoft so what i would like to do with this session is actually to try to do a live demonstration or at least a live view on top of some of the core resources that are out there and publicly available i will of course share slide decks and background materials that present sort of a start to finish overview of a lot of these standards and specifications but i thought it would be fun to go back to primary sources for today's overview so with that what i will do is launch into a screen share where i'm going to open up a view onto some of these specifications themselves including the hl7 fire project and including smart health it so let's start out with hl7 fire this is one of the core standards that's been developed over the last nine years or so which is really about providing a set of data models in health care and about providing a way to work with those data models and there's a lot of material here in the fire specification at hl7.org that's been developed by a very large community including folks with clinical expertise and folks with data and interoperability expertise and the way that the specification is arranged is in a set of levels building from the most foundational aspects of the of the fire design which includes how information is sent from point a to point b what data look like when they go over the wire and then up into some of the aspects of how requests and responses are made if you want to query for data that are available from a system and then we get into the levels that actually define some of the data models themselves that deal with clinical entities so things like patients and practitioners and organizations as well as clinical details including allergies or problems that you might find on a problem list or observations that you might make in a lab and i find that one of the easiest ways to dig in is actually to start from the middle from some of these data models that folks are in general intuitively familiar with so i'm going to open up one of these links here to the patient data model and that'll open up a tab here that's focused on the patient resource in fire and one of the first things you'll notice in fire as you browse through any one of these different resource definitions is that there's this consistent kind of header showing you some information about how this data model or how this resource was defined and who's responsible for it so we can see for the patient resource there's a group called the hl7 patient administration work group and we won't go into the details here except to say that each resource belongs to one of the work groups inside of hl7 and this is very important because this is the group that's responsible for maintaining content over time and providing improvements because fire is a work in progress like any specification uh it is never completely done um and that brings us to the next point here which is every resource in fire has what's called a maturity level which is to say how stable is this resource how much has it changed recently over the past revisions of fire and the stability of the patient resource is actually at the highest level this is what's called a normative maturity level which means we've actually committed to not making any incompatible changes in the future we may still add things to it but we won't change what's already there so that gives you a sense of just some of the metadata that's provided for each fire resource and then there's background for every resource on how it's intended to be used and the different use cases that it's intended to handle but what i really want to focus on here with the patient resource is what's called the resource content and this is the core of the data model itself not the context of how it's used or who's responsible for developing it but what is a patient resource and what this tells us for example is a patient resource in fire it can have an identifier can have a flag that tells you whether the patient a record is active or not the patient can have any number of names and any number of phone numbers telecom contact details patient can have a gender and a birth date and so on and this is really the core content of a fire specification is that for every resource defined there's these lists of element or field definitions and then there's a syntax here that i won't go into a lot of detail about but just to give you the gist of it this syntax describes whether these elements are required or optional how many times the elements can appear when you send somebody a patient record so if i'm sending you a patient record it can have no gender attached to it or it can have one gender attached to it so anywhere from zero to one but when it comes to names you might not know any names for this patient or you might know several different names maybe a name from the time of birth and then another married name for a patient that would be an example of a patient with maybe two names in the record and every one of these data elements also has a type and these types are defined by fire to give you access to the common properties that you would need for different aspects of data so the type of a birthdate field is a date which picks out sort of one calendar day and the type of the active flag is a boolean which means it's going to tell us true or false yes this patient record is active or no it's not and then some of the data types are more complex rather than just a single number or a single boolean a data type like human name actually provides more details and if i click on this i'm going to be taken to a new page of the specification which is the data types page and the firespec is a web of links just like the world wide web is so when i click on human name for that patient resource i'm taken to a page that's got information about the human name data type and just like patient had a number of elements to it human name also has a number of elements to it so it can be broken down into a family name uh possibly any number of given names prefixes suffixes uh and so on a human name even optionally can have a period which tells you the date range in which the person was known by that name so if you have several different names that you used in different time periods that can be captured as well but one of the important things to note here is that every time we see these data elements defined they tend to be things that are optional things that we can say if we know them but we don't have to convey them every time so the expectation is not that every system that knows a patient's name is also going to know which dates to use or which dates were the active dates for you assigning that name to the patient so that's a very quick look at one fire resource and looking at the data models in the fire specification but if we zoom out a little bit i'll show you the overview of all of the data models all the resource types included in the fire specification so if i click here on resources i'll be taken to the resource index and this is a list of over 100 resources that are currently in the fire specification that correspond to the different levels that we talked about earlier so just like a patient resource tells me about an individual patient who might be a member of a clinical practice there's also a practitioner organizat a practitioner resource that tells me about who the different clinicians might be in a practice and an organization resource that might tell me about the different hospitals that exist out there in the world so fire provides a set of these data models and once you know how to navigate them they'll look and feel a lot like that first one that we that we reviewed so the practitioner resource follows a similar pattern to what we saw for patient in this case a practitioner can have some identifiers can have any number of names and contact information just like a patient but a practitioner also has some additional data elements that didn't belong on the patient resource so for example a practitioner can have a list of qualifications and those correspond to things like certifications or licenses that that practitioner has maybe a license to practice medicine or maybe a membership in a professional society during a certain period of time and so that's an example of a data model on the administrative side that tells us about who's practicing in a given organization and similarly there's a way to model organizational structures and fire we won't go into details on it but i just want to call out that that set of resource definitions all exist and then i want to show maybe one kind of clinical resource and what i'll show you here is the observation resource and this is very broadly used in fire to capture many aspects of a clinical record anything that can be observed so that includes things like vital signs laboratory results as well as social history smoking status there's a lot of background and context that will take you through the details of how the observation resource is used but there's a few things that i want to show you in the data models themselves for this observation resource and so one is the use of of what's called choice types so in fire when you make an observation depending on what you're observing you may use different data types so if i am observing somebody's blood count i might want to report a number of units in terms of cells per volume but if i'm observing somebody's skin color i might do that using a coated set of values that capture different um different skin tones or skin color ranges and if i'm evaluating you know for example the time or date on which an event occurred i might use a date time or a time value and so in fire the way this is captured is to define a data element that has this little x here in brackets that's going to tell me the details that says you can choose among any of the different data types that are listed below but anytime i make an observation i'm going to pick exactly one of these the one that's appropriate to the kind of observation that i'm making and so that gives you a sense of how some flexible data can be captured using a core or consistent set of standards and so that's just a little bit on the data modeling in fire but what makes fire really powerful is that it's not just a set of data models it's not just a set of these resource definitions fire also provides ways of interacting ways that allow clients to connect to servers and query for data look for certain information send information back it provides a mechanism for information exchange and there's actually a few ways to do this in fire but the core mechanism that i'll focus on today is what's called fire's rest api it actually lives at this page http.html in the fire specification and the idea here is that a fire server can expose information to authorized clients to be able to fetch data um fetch data from that server so for example allowing a client to search for a set of patients or a set of providers that that server knows about through a set of interactions so for example a client can read data from a server clients may have permission to update data that exists already in a server or to create new data so for example a client that is managing an individual patient's home address may be able to update that patient record to let the server know that the patient has moved from one place to another or a client that is managing home blood pressure readings may have permission to create new resources to create an observation inside of that server based on those home blood pressure readings that are taken and so the idea here is that the the fire specification defines these apis for these basic interactions and these allow clients to connect to servers in a consistent and standardized way so let me show you a quick example of what some of this looks like in practice and i'm going to start with an example of a fire server and what i'll do to begin with is just open up a testing data endpoint i'm going to click on this testing data server and this one is open to the world to view and explore and it doesn't have any real clinical data in it but it has synthetic data that are generated from a project called cynthia so one of the things that any fire server can do is report what's called the server's metadata in the form of this capability statement and so what we're looking at on the screen here is the response that the server made sort of rendered to to provide some indentation and some color syntax highlighting but really there's what's called a json javascript object notation resource and this is a serialization format for sending data over the wire from point a to point b and it's kind of a low level format you see these curly braces and quotes and colons that are delimiting the various aspects of the resource that's been returned i won't spend much time on the capability statement resource but this is how a server can advertise to clients what version of fire it's using and what different resource types it supports so for example if i want to know whether this server supports access to patient resources patient records i can look through the capability statement here and i can find that like yes indeed there are number of places where we refer to the patient resource in this server and there's one particular spot that'll tell me officially this server supports the patient resource among its list of supported resources and so that's sort of the way that a client can discover what a server does by looking at the capability statement that the server advertises but the other thing a client can do is just try to issue a query and see what it gets back so for example rather than asking the server do you support patients this url here allows a client to talk to the server and say what patients do you know about what are the patient records currently in your system and if i issue that query what i get back here is what's called a fire bundle containing my search results well what is a bundle it is a set of fire resources that match a query so in this case i can see this is a search set so it's a set of responses to my query and it uses what's called an array of entries every entry in this bundle is one resource that matched my query so digging into the details here this is a patient resource that matched my query for any patients that you know about so in this case i can see the resource type is a patient and earlier when we were looking at the patient resource we saw that patients could have names and addresses and identifiers and that's some of what we're seeing on the screen here so for example this is a view of this patient's name there's a given name of clara and a family name of montagnes and this patient has a list of phone numbers in this case there's only one in the list which of course is this fictitious phone number here and similarly has a gender a female and a birth date in 1965 and so on and so we call this instance data because it's representing one instance of the patient resource but the shape of the instance data matches that set of properties that we reviewed when we were looking at the definition of the fire resource itself and so in a similar way the fire api allows you to provide more precise queries so for example maybe i want to query for patients not not just get a list of all patients but you know maybe i want to find a list of all patients whose name is clara so if i look for a name equals clara what i'll get back here is a bundle with just one patient resource in it the previous result had more resources actually i had quite quite a few resources if i look at the number of resources that count in that bundle you can see this list of entries is is quite long my overall response goes from line 20 here to line 10 000 or so and i am only getting one page of results so you can see i'm getting 50 results um on this page but if i search for just patients where the name is clara then i get a much smaller set of results and in this demo server there's actually just a total of one single patient whose name is clara that's an example of how you can use what fire calls search parameters and these are key value pairs that get appended to the resource type that we're searching for fire search parameters are very useful because they allow us not just to winnow down a list of patients but they also allow us to do things like for example if i wanted to look for laboratory observations i might want to look for observation resources instead of patient resources and then i might want to say rather than giving me every observation that's been taken on everyone in the whole ehr maybe i just want to look for laboratory observations about patients whose name is clara and fire calls this chaining it allows you to look for observations based on the name of the patient that the observation is pointing to and so in this case i can see there's 78 observations that have been returned here those might not all be laboratory observations so i can add a further search parameter and say category equals laboratory and when i do that instead of getting 78 results now i've just got 34 results and so you get the sense that the more search parameters you tack on the the finer grained or narrower it's possible to make a search and this really provides quite a strong degree of interoperability so for example it's kind of a funny thing to search for observations based on the patient's name but a much more common use case would be to search for observations based on a patient's identifier patient id so if i know clara's id is this long string here i happen to have copied that from the page a moment ago then i can search for observations based on this one single patient in this case since there's only one patient named clara there's only one patient with this id i'll get the same number of results but this query is much more common because that's a way to look for specific observations about a given patient and indeed it's so common that this patient search parameter searching for patients by id is defined on almost every clinical resource that makes sense to search for and fire so rather than searching for observations i might search for conditions which would represent and fire something like a problem that lives on a patient's problem list and in this case if i look for conditions about this particular patient i'll see if there's 10 being tracked on her problemist right now and so uh you know here's just scrolling through some of the resources and examples here i can view information uh this is a patient where one of the conditions was miscarriage in the first trimester and another one of the conditions that's listed in her record here is obesity a body mass index above 30. so those are some examples of ways that you can search for fire resources in a server and if you know the patient id you can find all the relevant data for that patient and you can you can imagine how you could start to build up a set of queries if you know a patient id to look for observations and conditions another resource that is very useful in fire is the allergy intolerance resource so we can see if this patient has any allergies in this case there are none that are returned here about this particular patient that we've been focused on but building up these queries allows you to search for many different kinds of data in the system and so this is sort of the promise of fire between the the data models on the one hand for all these different resources and this http api that allows you to search and create and view data in a server putting these things together gives you a very powerful kind of health data interoperability clients can connect to servers in a consistent way and be able to use these open standards to search for data and manage health care records so what's missing if we have this rich set of data models and we have an http api that gives you back structured data for clients who are authorized to do searches what's really missing here well there's there's a number of things that are missing from this story and it's quite instructional to think through it in terms of use cases that really matter at the national level and i've been involved in a number of these projects looking at health data interoperability in the u.s and one of the first things that comes up is that in fire all the data models that we looked at when we dig into the way that those cardinalities for the different elements are defined we'll see they're almost all optional so if all i tell you is i've got a server and it's supporting the fire specification well almost every one of these aspects of the patient record for example might be missing so identifier could be missing active status could be missing name telecom gender birthday deceased address marital status all these data elements are optional which means it could be perfectly valid to have a fire patient where all these things are missing and the reason that the fire patient resource is defined this way is it's intended to be used in many different contexts so if you're keeping a health record for a hospital you probably want to populate a lot of these fields very consistently but if you're maintaining uh an immunization registry for example that's just looking at total numbers for public health uh you might be happy enough just to track patients based on their gender um and race maybe that's that's for example all you need to track in your registry well that raises some questions because then it means that your different use cases actually have different requirements in fire the way we deal with this is by making sure that the base specification leaves open all of these possibilities we don't want to rule out any of the use cases but then when you want to accomplish something more specific you've got a little bit more work to do so for example in the case of managing health record data in the u.s we have a set of profiles that help constrain fire that help describe how to use fire in the context of managing electronic health records in the united states and there's a set of guidance that's published as what's called an implementation guide here as the fire us core implementation guide and this is really important because it provides a target for regulations so the office of the national coordinator for health i.t right now in in the united states points to this particular set of fire profiles the u.s core profiles and says that every certified ehr is going to have to support these profiles in order to maintain its certification in the coming years and so we'll see these profiles provide constraints on top of the existing fire resources so for example if we look at the patient profile we'll see a few kinds of constraints that that a profile can include first thing that a profile can do is can require support can make elements mandatory even though in the base fire specification they're optional so for example here in the u.s core specification we say that each patient must have an a medical record number so patient identifier as well as a name um and then gender as well as each patient must support a set of fields there's an important difference here between each patient must have and each patient must support this is a little bit subtle but what this means is that every patient record that you send over the wire these fields will be present uh the implication is you should always know them if you're engaging in these interoperability use cases following this guide versus must support which means you might or might not know them for any given patient but if you do know them you must be able to share those data in an interoperable way following this guide so for example you might not know the patient's birth date but if you know it then you must include it in the patient resource that you share so that's what it means for birth date to be must support so that's the first major thing that a fire profile can do is introduce requirements for data that are optional in the core the second thing a profile can do is layer on extensions to the fire data and this is another subtle point but if you think about the fire data models that we've been looking at they're fairly comprehensive they have a lot of details about the various resources patients and practitioners and observations and so on but you might imagine there's some kinds of data that aren't being captured and so here's a great example in the us we actually have regulations that require health providers and health data record systems to be capable of capturing information about a patient's race and ethnicity and birth sex so that's something that we require in the u.s but they're not properties on the core fire patient resource if we look in the base definition for fire we won't see race and we won't see ethnicity there and the reasons are complicated but in some countries these things are not routinely tracked in some countries it's actually forbidden to track these things or at least very uncommon unless there's a specific medical need it might be seen as potentially unfair to track these these kinds of data culturally very different answers to some of the same questions and so in fire when we decide to put an element in the core fire data model we do it because the majority of systems support it and so for something like race and ethnicity if we look worldwide the majority of systems don't support those fields today they're not part of the base fire specification but they can be defined indeed they are defined at the level of a fire profile like u.s core and so in this example we'll see the u.s core patient builds on top of the fire patient resource by adding race and ethnicity and birth sex as fire extensions and if you were looking closely you might have noticed some of these already in the examples that we were browsing through earlier so when we were searching for all patients in the system and we found clara's record here scrolling through it one of the things we found is a list of extensions and so this first extension here is listed as a us core race extension with a category of black or african american and a text rendering of similarly black or african american and fire provides this flexibility to add extensions to any resource and indeed to any data element in any resource and this really opens up the specification to deeper kinds of interoperability where in particular use cases we have needs for data that don't appear in the core of fire and the important thing with the way this is done is to ensure that when these extensions are sent developers or systems that are receiving these data have a way to look more information up about what this extension means so maybe an app has never seen some particular extension before but the extension is identified by a url and when things are properly managed this url will actually resolve so a developer could say i don't know what this what this thing means what is this omb category that's showing up in my patient resource i didn't expect it but by looking up information about this extension by url we'll find a link to the structure definition for fire u.s core race and it says well this is an extension for race that allows various kinds of codes to be used and so it provides a formal definition for what that extension means and this is a big part of why fire's extensibility model is successful it allows developers to layer on additional data but in a discoverable way so we've seen examples of profiles that can make certain kinds of data required even though they're optional in the course spec and profiles that can add extensions to a resource even though those extensions represent data that were not captured in the resource of the core specification and there's one other really important thing that profiles can do and for that i want to look at an example from the laboratory domain so let's look at the laboratory observation profile in the fire us core implementation guide and so if i scroll through here we'll see the same kinds of structures locking down requirements about what data must be present and what data must be supported and the other thing that's done is vocabulary binding so fire again is intended as an international specification and in different countries and different jurisdictions there's different kinds of standardized vocabularies that are used for different aspects of a medical record and so fire often leaves these things open so in fire when you make an observation the code it can be a coded value from any structured vocabulary you like and in some countries there may be national codes but in the us we use link codes for these kinds of lab observations and so the fire us core guide actually locks this down and imposes a requirement that link codes be used when they're known or that snomed ct codes can be used when those are known so if we look at the definition in fire the observation resource has a code and in this example the uh the implementation guide provides what's called a binding meaning we bind the vocabulary or we tie the vocabulary for this code field to a specific value set in this case the value set of link codes and if you don't know what's in that value set again you can click through and read more information about how that set of link codes is defined and you can also scroll down and see the beginning of what would be a very long list of every link code in existence and i'm scrolling too quickly on purpose because the point here is not to read all the different link codes describing every possible lab observation but just to see that there's a level of detail and consistency that you can apply here in a fire profile like the u.s core implementation guide that you wouldn't have in the base fire specification so switching back to the base fire specification earlier i asked what's missing well we've answered that question in one part by saying what's missing in the base fire specification are these kinds of use case specific profiles and for that we need to look to specific jurisdictions and specific use cases to see how these things can be most usefully defined the other thing that's missing in the core fire specification is a set of requirements that would allow us to plug apps in to a health record system how do you handle all the complexities of things like embedding an app inside of your electronic health record system providing contextual information so that app knows what patient record is open and so that app knows what user has launched it and to make sure that the app has permissions to access certain kinds of data and so to fill in those gaps we've we built a set of specifications called the smart on fire specifications as part of the smart health it project and we've standardized those specifications today uh by working with hl7 and working with a standards acceleration group called the argonaut project and i want to take you on a quick tour of how some of this works and again just to sort of tie this back to some national priorities in the u.s the smart health it standards for embedding apps in an ehr and connecting patient apps to a health record these have been named by the federal government as requirements so that every certified electronic health record vendor in the country needs to support these kinds of standards so if i go to apps.fire.org i can get sort of a layman's view of some of the apps that exist and are out there that have been developed to work with the smart health it standards today and i want to show you just a quick demo so you can get a sense of how this works but this is an open gallery where any app developer can come and publish information about the apps that they've built so i'll show you an example of an app called meducation and this is a tool that takes a patient's medication list and can render it in a format that makes it easy to get an overview of what meds the patient's taking and what times of day and then very importantly this app does language translations so if a patient maybe just speaks russian there's no sense in giving them an english language print out but this app will help translate the medication list into over 18 languages so i won't go through the details of this particular app but i want to show you a couple features of the gallery one is that it provides a way to test out an app i'll sort of cross my fingers and see if this works in a live demo and it doesn't this is this is the challenge of doing a live demo but i'll show you a different app so you can get a sense of what that looks like this is an app that we developed at boston children's hospital it's an open source growth chart application that can embed into the ehr as a clinician-facing view and part of what smart provides is a way to launch an app into a health record system and so this might involve picking a patient record so the app knows which patient's data to work with or that information might come from the context of an existing ehr session so if you're building a clinician-facing app the clinician can in one click or automatically have the upload information about the right patient and then once the app launches it's able to fetch data in this case it's fetching the patient resource which we looked at and it's facing that it's fetching observation resources which we also looked at to be able to plot these observations over time and show you how a child is growing versus standard curves for their age and conditions so that's an example of what it looks like to launch one of these apps inside of a smart gallery but i also want to call out that these apps very same app can be written to run not just against our testing server that's smarthealthit.org but these very same apps can be registered with certified electronic health records so in the case of this education app this is one that's currently registered with athenahealth with epic and with cerner and so each of these vendors and indeed every certified vendor in the us soon will have its own marketplace or gallery or orchard of applications where app developers can register what they've built and this is particularly important for clinician-facing applications where you might want to build something once and deploy it not just across different clinical sites of one vendor but across different clinical sites irrespective of vendors and so this really provides a way for app developers to scale their work building an app once and integrating in a number of places now one of the challenges with this level of deep interoperability is that there are still differences vendor by vendor and site by site in terms of the way that these data are captured and so part of the job of an app developers over time to understand those differences and build apps in a kind of defensive mode build apps that are prepared to deal with data that might be missing or prepared to deal with subtle differences in the way that data are captured from system to system and over time the goal is to extend profiles like us core to provide access to more data with more consistency but we think that the starting blocks that we've got with the smart on fire specification is already very useful and so one of the tools that we provide for developers is the smart app launcher this is a way that anybody who's developing an app let's see if i can correctly type in the name of the domain anybody who's developing an app can connect to the smart app launcher and test their app against it and i won't go through the details of it but what i want to show you is this overview of different ways that the smart specification provides of connecting an app to the electronic health record to deal with a few core use cases so one of them is a provider facing what we call ehr launch and so the goal here is that a practitioner is working inside of an ehr and they want to click one button and launch an app of their choice and make it so that app knows immediately who the practitioner is so that's called single sign-on and so the app also knows which patient record has been open that's called patient record context and so that's what the provider facing ehr launch does very important for workflow integrated apps and the other main pattern that i think is worth calling out is what we call patient standalone launch and so the idea here is a developer might be building an app that's going to run on a patient's mobile phone and it's going to be something like the apple health records app is one example of an app that follows this pattern first the user launches the app and then from inside the app they want to connect to their health records they might even want to connect to their health records for more than one health system and so that's what this patient standalone launch provides is a way for a running app to connect out reach out to a health system and with a patient's permission connect to the health records inside of that system so if we look at a quick example of what that looks like we can see sort of a demo app that would be a patient-facing app um so you could imagine this might be like a mobile application that's running on your phone you start the app and you tell it what health system you want to connect to now in real life rather than a url here you'd see a nice provider directory where you would search for providers by name or location and then once you pick the provider that you wanted to connect to you would connect and sign in to that provider here in our demo environment it's a very simple sign-in screen where basically any username and password will work but there's kind of an approval process that allows an end user to see which app is trying to connect to their record and gives the end user a chance to say yes i want to share these data or no i don't want to share these data with a particular app so if you're interested in learning more from the perspective of developing a smart app the website here docs.smarthealthit.org has a lot of links and details including tutorials uh that will take you through the process of building and testing an app with these underlying components so i want to return to my question from earlier what's missing we've got the fire specification that tells you how to move data around we've got the us core profiles that tell you how to model data what fields are going to be present in a consistent way we've got the smart app launch specification that allows an app to connect and do single sign-on and workflow integration so that app can be embedded right in your ehr or so that patients can share data with the apps of their choice what's missing once we layer all of this on well the answer is actually what i've described at this point is sort of the regulatory target for today so the final rules that came out from the office of the national coordinator for health i.t if we look at their timeline that they've published as part of the most recent cures rule we'll see that effectively um this has been the focus the specifications that i've shown you today really are the focus for the next couple of years so if we look in onc's publication of this timeline they proposed a rule last year it was finalized this spring and then starting at the beginning of next year and into 2022 we have implementation timelines for every certified electronic health record system to start exposing these fire apis and to start building out access so that patients and clinicians can use the smart app launch specifications to connect apps to their ehrs so this represents really the current time frame but if we zoom out and think about the ecosystem overall there are still some room some areas for improvement and so one of those is integration of clinical decision support it's obvious that if i have any kind of decision support system i could build an app around it and use the smart health it specification to wrap that app and embed it in the ehr and that works really nicely for apps that clinicians know they need to launch so if i know that this growth chart app is going to give me decision support to help me figure out whether a child is growing according to expectations i can launch the growth chart app get the information i need and get on with my day but there are many kinds of decision support where the the actual questions that a clinician might need to ask only come up rarely and you want a kind of stake in it that's asking these questions automatically and in the background and so this is a real frontier uh we've been working on a set of specifications that builds on top of the smart on fire specifications called cds hooks clinical decision support hooks and these have been standardized in their first version through hl7 last year and we're working on improvements in a continuous basis but the goal here is really to provide deeper integration into the workflow into the clinician experience to allow specific decision support services to be triggered in the context of a workflow so the details live here in this cds hooks specification but maybe the easiest way to to actually share this information is to navigate to the cds hooks sandbox which is sort of a demo ehr environment that gives you a sense of how some of this can work and this is not a real ehr it's sort of a tool for developers but i'll just give you a sense for example if i'm on a screen of my ehr that has to do with medication prescribing and i'm about to prescribe a drug based on the draft prescription that i've written maybe at this point i've picked out a medication and a dose over here on the right hand side of the screen you can see some developer information some low level details about a request that's being sent on the basis of my draft prescription and the request basically says dr mandel is in the process of prescribing uh zofran one pill once a day uh four milligrams and it's sending this request to any clinical decision support services that are listening and those decision support services have been registered with the ehr and can respond with a list of suggestions or information for the end user to see so i'll hide the developer details here and just show you in the user experience one of the services i connected to has given me this information here it says you're writing a prescription that's going to cost 1200 a month and you can save roughly 1200 a month with a generic um so that's important information to know but the service can also provide a suggestion in the form of this button here which is tied to a different prescription so if i click on this suggestion what i'll see is my ehr prescribing pad here is going to be updated so keep keep a close eye on this word here zofran because when i click on this suggestion change to generic my interface gets updated now i've just got a generic on danzatron prescription and a new cycle has been kicked off we send a request out to the cds services and now i got a service that responds with just cost information and no additional suggestions about how i might change it so that's just an example of the kind of workflow integration that you can accomplish with clinical decision support hooks and providing an open specification for this is really important because there's many different electronic health records that all offer different capabilities but if we can pick out specific points in the workflow we can start to use those as the targets for decision support interactions and that allows clinical decision support vendors to build these kinds of tools once and integrate and connect in a consistent way so just as a quick example in the cds hooks specification we define these trigger points or these hooks inside of the ehr and so when you're prescribing a new medication the relevant hook would be something like order select so this is when you're choosing a new drug or a new procedure to order it provides context it sends out a query to an external service to say which user is selecting this medication which patient is it about what medication has been selected and so on and based on this context the external service can see these data can request additional data using fire and then respond with a list of cards so that's just a very quick view of some of the capabilities that are being introduced in the cds hooks specification there's active work happening in the hl7 community on this and really that's just the glimpse that i wanted to give you as part of that question of what's missing or what's next there are a number of regulatory targets where this kind of deep integration of decision support can be a real help one example of those regulatory targets would be the the cms pama uh protecting access to medicare act requirements for imaging orders so there's been a strong national push to make sure that when advanced imaging studies like a ct or an mri are being ordered to make sure that it's an appropriate test given the clinical conditions and so those kinds of checks for appropriate use are a great use case for something like cds hooks because it can integrate very naturally with the underlying ehr workflow so i'm going to pause there having done an introduction to hl7 fire having done a quick view of some of the fire implementation guides having shown you a little bit about how the smart app launch specification provides this deep integration provides a framework for giving apps access to the data they need inside a clinical record and giving you a quick forward pointer to the clinical decision support hooks community what i'll leave you with is the docs.smarthealthit.org website which includes links to the various kinds of specs that we've been looking through today as well as to the underlying fire community and it's a great very active international community and i'd love to to take the time to answer questions so please do reach out and we'll use this time to dig into areas that might be of special interest to you thanks so much

Channel: Josh Mandel

Views: 957

Keywords:

Id: z5FnHpSxMvs

Length: 45min 0sec (2700 seconds)

Published: Thu Nov 05 2020