SMART on FHIR – Apps for Healthcare



good afternoon my name is David McCauley I'm a senior vice president in medical informatics long time Cerner associate and I hope you're here to hear about smart on fire apps for healthcare and I'll apologize that this is a little bit closer to the application and user side of our work here at Cerner and maybe a little bit less about the deep technologies and the cool infrastructure talks that you are hearing for the rest of the DEFCON but I'm promised to do a little bit of Technology as I go through this we've got a lot to cover so I'm going to go pretty quickly but I'm going to start off with a challenge that I am consistently now hearing when I get engaged in marketing to important clients large IT ends and this is a almost verbatim statement from a CEO of a very important and well-known IDN who currently uses one of those other vendors products and his quote was EHRs are becoming commodity platforms the winner will be the EHR vendor that provides the best platform for innovation the most open and the most extensible platform so if that's a challenge that we have to face in the market how do we meet it how do we become the best platform for innovation and the most open platform so the vision I'm going to present today here is to develop an app store approach that lets clinical that elet's innovative clinical apps emerge that can plug and play inside any compliant EHR the model for this is obvious every one of us has something in our pocket that draws many different apps from these well-known app stores and what I'm going to propose here or described here is a is a nascent effort to create a new kind of app store that's based on what's called the smart platform and I'll go into a lot more detail in a few minutes about where the smart platform comes from and what it is that the name smart is an acronym for that rather unproduced pronounceable string of words so let's just call it smart but you can think of substitutable apps as the as the kind of essence of it so smart on fire EHR as open platform so I think I've introduced the notion that people are beginning to think of EHRs less of as a solution and more of as a platform on top of which solutions can be delivered and we've kind of always had it that way with our own products because you can add on additional products to complete the solution but what's changing is that people are now expecting that these add-ons can come from other people besides Cerner so the EHR platform becomes responsible for these core services it's the legal record it has to manage workflow and orders and documentation and things like that but edge extensions which encompass both missing functionality from the core platform and new and innovative applications that no one has thought of yet the same way that your iPhone has apps on it that Apple never dreamed of when they created an app store these edge extensions will be layered on top of to complete the functionality and this is not such a far-fetched idea if you had put this out in front of a audience of Informatics and CIOs and cm iOS five or six years ago they might have sort of said I don't think that's possible but with the dramatic success of the other app store models and with the emergence of some new standards which we'll talk about in a minute this is now actually not only within reason I think this is going to happen and I want Cerner to be at the forefront of it so what I'm going to cover here probably too many slides in too little time but I'll race the room as best I can is the three key technologies that make this possible the first of those is a new thing from hl7 called fire which is the API the second our fire profiles which is where the semantic plug-and-play interoperability comes from and then the third is the smart platform itself which is conventions on how to use a web browser or web as part of the the application once I described those three technologies I'm going to put a sequence diagram up that shows how they relate to each other how the flow goes back and forth then I'm going to show you some screenshots from some proof points that we did at hymns in in April whenever it was and then we'll end up with some discussions about the things that might go wrong the open issues I doubt if we'll have time for Q&A but hopefully we will I'll hang around this is a info infographic that we put out at hims we gave this out at our booth the Cerner booth and it reflects what we pulled off for the demo there and I'm going to come back to these particular apps but we had six different apps from three different sources four sources that were plugged in to four different container systems Cerner as an EHR Intermountain as a legacy EHR and then Harris and hewlett-packard put wrappers around the VA x' vista EHR and those four vendors these six app providers and we had them all working inside millennium and inside these other vendors products at hims in April and it was quite successful tremendous positive feedback from the community when we showed this including officials from ONC and others who were really pretty dazzled by the potential how do we make it work here's how start with fire fire is a RESTful API it comes from hl7 and it stands for fast health interoperability resource I like to say that it keeps the good parts of hl7 and gets rid of the cruft any of you who have dealt with hl7 v3 know what I'm talking about and the uptake inside hl7 s community when fire was first put forward has been astonishing it's the fastest growing most exciting thing that's ever happened in hl7 there's the logo restful api is in this audience probably most of you know what that means most of the people I present this to don't know what it means I'll just highlight summarize it to say that it's focuses on resources and the nouns rather than remote procedure calls the verbs so it defines the simple set of activities get put delete post that anybody who does web development is familiar with and it defines those in terms of the core resources that make up a medical record or clinical data it's very easy for developers to grok they can read the document and start writing code in a few hours unlike previous hl7 these fire resources are the key the resources are valuable if they actually describe stuff we care about and want to move back and forth across these API boundaries the good news is that the hl7 community has defined a large and growing number of resources so every one of these categories has a little snippet of XML or JSON that's defined to capture 80% of the use cases for that particular snippet of information the 80/20 rule is used here to keep these things from growing to be so huge that no one can manage them and I'll describe in a few minutes what you do if what you need isn't included in the 80% but suffice it to say that the common stuff is in these resources I've highlighted the ones in blue that will be easily familiar to you problems medications patients encounters allergies but have overcome they all become important now what does it look like to fetch a fire defined resource so here's the URL that would be issued some service in this case open API dot fire me which is a service run by some developers at Boston Children's then the name of the resource that you're fetching in this case an observation in Cerner world that would be a clinical event and they're in the fire world they carve they're called observations and then the the identifier and here's what comes back down it's kind of small print you probably can't see it out there but I'll step through a few key aspects of it the resource type observation if I was querying for a patient I'd put patient if I was querying for an encounter I'd put encounter pretty simple the resource unique ID that's got to be globally unique within the space that within the namespace of this of this URL there are semantics that come back with the resource that tells you how to interpret the clinical value and in this case the resource contains a link back to the patient that this systolic blood pressure describes now you'll notice that I got straight to the blood pressure without going through the patient first presumably I had some other way of knowing the patient that was connected to this resource and I'll show you how you do that in a minute but taken together these resources oops I'm slide not in the sequence I remembered how do you fetch these resources I showed you one where you fetch it by the ID so the parameter their ID equals 23 an equivalent way is to actually just use a simple URL this will work only for the identifiers the named identifier you can also fetch with various query parameters in this case fetch me any patient whose name contains the string e ve I could also constrain it to fetch any patient whose gender text field and the JSON structure that be gender dot text if your nesting downward contains the string ma le or more likely I would actually do that query by specifying a code value so that I could be sure not to get female in addition to male because ma le actually is in the middle of Fe MA le so if you really want to get just males you would query by a code set and that funny-looking string there is the URI the uniform reference indicator for the code set that is typically used to code administrative gender I can also fetch using fire with things like complex textual queries bone or liver and medicine metastasis and then I can fetch in a more typical way at by essentially cascading so you see here I'm constraining to patient 23 and then fetching the procedures between these two dates constrained to patient 23 all sorts of different ways to slice and dice grabbing the data that you want now a system that implements fire doesn't have to doesn't have to build out every one of these query capabilities you have to declare what kinds of queries you support using a profile which we'll talk about in a minute so those of you who might be in a position to actually write Cerner services to support fire API you may be getting heartburn looking at some of these query types and say wait a minute our back-end doesn't support a query like that so don't don't panic you only have to support it if you need it now if you take these resources all together and consider the URLs and the relative URLs to be pointers you've effectively constructed a graph of interesting information about your patient so in this case this is the diagnostic report that has pointers to the practitioners that's in our world providers or clinicians the organization devices patients and the observations that are linked therein now fire profiles all those resources are great the problem is the way they comment off the specifications page at hl7 they're unconstrained so it's a list of attributes and there's no no constraint as to whether the attribute is required required but only one required but many not required and so forth so what profiles do is layered on top of the fire resources and they constrain the cardinality of each attribute they specify the value sets or the nomenclature for coded fields and most importantly or very importantly they specify if you have a complex piece of data that requires multiple resources to describe it how those resources are linked together to describe the higher-level entity and I'm going to give you an example in a second in detail about what on the surface would seem fairly simple describing a blood pressure but which turns out to be remarkably hard and any of you who've worked with Cerner's clinical event model and tried to figure out how to match up systolic and diastolic blood pressures know what I'm talking about it's tricky the fire profiles can also define those extensions that I described if the off-the-shelf resource doesn't contain something that you need you can write an extension for example the off-the-shelf patient resource from hl7 does not include ethnicity but in the u.s. that's a field is required for or certain kinds of reporting so that's a common extension for us patient implementations the profiles for the patient resource now the profiles the reason I put so much time into them is they are what enables plug-and-play it's one thing to have an API that everybody agrees upon but if when you move the data back and forth you can't understand that data you really haven't achieved a whole lot of good the profile describes enough detail about the data that's moving that you have what I call semantics by contract now the great vision of informatics ascend the last decade was computable semantics and that's why we had reference information models and all sorts of things that would get passed along with the data and in theory the receiving system could look at all the reference models and say I can figure out what you meant by just sheer logic it didn't work it was a dismal failure so semantics by contract which is what a profile gives you is not nearly as elegant it's not going to generate any PhDs but I think it will make systems that can actually work and in the fire the smart on fire world that I'm proposing we would develop a set of profiles that are for use in the use case of smart on fire now there can be more than one profile for a resource depending upon your needs now here's what a blood pressure might look like mapped out as three related observations the high level observation is the grouper in cerner world terms that's the combined patient blood pressure that grouper has in it pointers to two independent observations one of which captures the stolid blood pressure and one of which captures the diastolic blood pressure and you can see in both cases or in all three cases there are loin codes specifying exactly what it is you've got I think I left oh and here's the loin code so that's the loin code for the for the combined and this is the systolic and this is the diastolic you have to get to that degree of specificity if you want systems to plug and play interestingly enough fire is a draft standard in the course of its initial proposal to its current DST you status which is its first version as a draft standard they've changed this through times so this is this has to be specified because even the people that are designing the fire have realized they didn't get a right the first two times so that's where the profiles are so critical now you might say oh my goodness in order to get a blood pressure I have to do three different queries once for the parent and then once for the systolic and once for the diastolic oh my gosh that's not going to work here's what that query would look like and the little magic trick is this parameter that says include the relative linked the related targets so what you get back when you issue the query is not a single resource in this case you get back an atom feed that includes the high level parent blood pressure it includes the nested systolic blood pressure the nested diastolic blood pressure and a denormalization if you would or copy of the patient resource and in addition it gives you the URLs internally to reassemble this graph in memory in your app and it gives you links as do all atom feeds to go get the next batch of data so this is an inherently what we would what I would call a continual query it might fetch back say 25 blood pressures for this patient and if you want more it'll give you a link that says if you click this link or if you issue this get against that link you'll get the next 25 now that puts big burdens on those of us who implement systems because there's that link has to manage enough State so that you can figure out where you where you're left off and you return the next 25 instead of the previous 25 now how do we get profiles this is the politically challenging business and politically challenging part how do we get widespread adoption of these profiles well first off you got to start with credible profiles and then you got to get the vendor community to agree these make sense the good news is that we have worked on at Intermountain that we know I have access to because of our relationship our close relationship with Intermountain where they've developed over the last several decades something they call clinical element models and it turns out their catalog of 6,500 or so clinical element models are essentially profiles so our plan is to take those clinical element models and to work with a broader vendor community not just Cerner but but other vendors who are interested in this project with us to turn them into fire profiles and then to extend them as necessary so we have a good plan and we have a good start with the clinical models check back with me in six months and I'll tell you whether we're getting some adoption of this or not now the profiles have to refer coded values to code sets or to nomenclatures if you had given this challenge to the informatics community must say six or seven years ago before high tech and before meaningful use it would have there would have been collective groans in the room because coming up with an agreement on what nomenclature should describe these common things in clinical medicine has been incredibly tedious controversial conflicted and whatever but the good news is that the twenty two billion dollars of meaningful use even if it may not have bought us a whole lot else it did buy us consensus on what the right nomenclatures are for most of the core terms of clinical medicine so problems and conditions are in sno-med medications are in rxnorm finally that's a good enough nomenclature to mean you don't have to use a vendor specific like multum or FDB observations lab values blood pressures are in loin code sets are most of them captured in an hl7 standard code set and so forth now this is not to say that the problems are all solved there's very complex detail structured data about history and physical exam that really hasn't been addressed yet and we'll have to solve that problem as we go forward now the final that's leg number one like number two firefire profile leg number three of the smart platform itself the smart apps the web app specification these are the things we actually demonstrated at him as you can see here's some screenshots I'll show you in more detail in a few minutes it's and for substitutable medical apps it was initially proposed by two professors at Harvard Medical School in 2009 they on the basis of that article in the New England Journal of Medicine got a major grant from Owens and they fleshed out the models in the last couple of years I was privileged to be an advisor to their group representing the vendor community so it was able to enabled me to keep track of what they were doing initially I was skeptical and said you guys are never going to succeed nice idea no one will care now I've become a believer a smart app is nothing but a web app it has some conventions or some specifications that tell you what subset of HTML basically html5 and how to use javascript that web app is embedded in the EHR in an ideal scenario in Cerner's world that's an imp age so in page is the container into which we embed the smart apps in fact a smart app is nothing but a special case of imp age and then there's some conventions on how you launch this app with the URL that contains enough information for the app to know how to talk to the data source that's specified by the fire service available from that EHR so the URL typically will have the address of the app itself obviously and then one of the parameters will be something about who the patient is and who the provider is I'm just calling that EHR context and then another parameter will be where's the data how do I get to the data where's the fire service endpoint the data access occurs through fire obviously if you go to the smart website don't be confused because their original design was based on RDF to move data back and forth they've since shifted to fire but the website isn't completely switched over so they're parts of it they still talk about RDF RDF would have been a good choice but hl7 went with this restful fire model which is going to have much more acceptance than an RDF model and then ooofff 2 is the is the security model it's being fleshed out most of Cerner's work was well both one this is OAuth 2 which is a little bit of an issue for us now here's the sequence diagram that hopefully will capture these interactions so the swimlanes here on the far left let's say your left is millenium and an imp age that sits inside millenium in the middle is the smart app might be hosted locally inside our data center could be if it's a trusted app outside on the internet somewhere and then second from the end is the authentication service and then the fire service itself now typically the authentication service and the fire service would be exposed by in our case millennium but in order to avoid having to have a 3d wrap-up these sequence arrows I just pushed them off to the right so you can you can you'll see how that works in a second here so the first thing that happens is the app gets launched and the simple way to launch an app is to click on a menu choice in power chart the ones we did at hymns were done this way but there's no reason why an app couldn't also be launched by discern or any other kind of triggering mechanism that the vendor zhr supports so discern could fire based on some condition open a window and launch the app so that that app is now in the window so for all practical purposes to CERN click the link for you now the app URL contains the ehrs context typically that's the patient provider and organization and it contains the address of the authorization and fire services you can think of those as the URLs for the fire service and for the authorization service so step two is the app now in possession of that knowledge turns around and asks the authorization service for permission to access this patient record the authorization service then private that's all part of OAuth the authorization service then privately makes an assessment that it's okay or not okay or that the privilege is requested are sufficient or not sufficient and I've got those as dotted lines here going back to millennium where the authorization service has to have a millennium specific vendor specific negotiation to say yes I'll give you a key or no I want in this case let's assume they do the authorization service says you're in it hands back an authorization token which is a secret key back to the smart app the next step is the app now it hasn't put up a web page yet for the user this is all still happening in the quick processing the smart app typically will then take that key the token and make a fire request to the fire service probably in our case hosted by millennium to get some information to fill out that initial page so what it's typically going to do is get the patient it might also get something about their provider the organization the encounter it might even go ahead and get a lot of data about the patient if it knows that on that first page you want to throw up a lot of data so that first conversation is up to the app but since they have access to the full set of fire services the app can do whatever it needs it doesn't have to be pre negotiated by anybody you just issue the queries that you need to and then the app returns the HTML to the M page which is just an Internet Explorer embedded browser which displays it to the clinician so from the clinicians perspective they click the link some wheels turned in the background and a web page shows up that understands who they are who the patient is and gives them something interesting to do then subsequent interactions between the clinician and the app are just like using any web app information is captured by the HTML and JavaScript it's posted to the web server the web server does additional fetches of additional patient data as necessary puts that back on the screen you repeat that process until the app is finished and then you're done so hopefully that makes sense as a high-level for sort of the sequence of how these things interrelate to each other there's nothing out of the ordinary about this this is the standard way off to based remote services get proxy authorization to do their work what's cool about it is it's a clean separation between the data access channel which is fire and the visual experience which is HTML those two are cleanly separated which means this model would work equally well for a mobile app and all you would do is that instead of those two left-hand columns being Cerner Millennium it would be a mobile app and the fire service would point to whatever data store the mobile app needs access to could be the patient's portal it could be millennium could be healthy intent could be population health services whatever now there's one variation of this that's actually quite common which is the app itself issues fire calls from within the browser instead of doing an HTML back to the web server and then having the web server do the query so if you're a node type and you believe in kind of JavaScript driven Apps as opposed to web server driven apps then the model works exactly the same way and the call to the fire service is just an ajax call from the JavaScript running inside the browser embedded in milennium sitting on the desktop this is how actually most of them are actually being written probably now obviously this is very similar to other things we do at Cerner in particular to M pages which you know in pages as most of you know as blazed the trail for us here in terms of creating extensions driven by both Cerner teams as well as client teams and even in a few cases some third-party companies the downside of M pages and I use this in quote the limitations is a better way is that it's a proprietary approach so an app vendor that wants to build for imp ages is not building for anybody other than Cerner now that may be sufficient for some app vendors but we think a broader community will emerge if there's a more open standards-based way to invoke these services in pages doesn't use oauth2 at the moment and because it grew up around sort of ad-hoc needs driven by CCL and the services didn't always exist it it oftentimes many of our in pages aren't using back-end services care where services is very similar to fire in that it supports restful api s but it also has mixed in with it a number of RPC services which is not strictly speaking part of the fire standard there's some debate about how to add that but at the moment you can't call that part of the standard and maybe most importantly is there isn't a concept like the fire profiles in the care where services so they tend to return the data in terms of whatever the local hospitals coded values are which means that a care where service at hospital a is going to return different codes than a care where service running a hospital B and that obviously limits the users who would want to build plug-and-play apps and it likewise is considered Cerner proprietary although it's open in the sense that we let all of our clients purchase it and use it so much work to leverage in building out smart on fire on top of em pages and leveraging the care where a framework but I hope you can see that there's some of the differences there so let me talk a little bit about the apps that we showed at Millennium I mean at hims here I'm just come back and remind you here these are the vendors each of the four vendors showed this set of apps and we were using fire services we just made up some simple profiles because we didn't have time to do formal profiles so it was very lightweight and simple approach that was clearly demonstration purposes but it but it actually worked flawlessly many thanks to a number of you who we tapped on the shoulder at the last minute to get this pulled together so one of the things that I heard about in the previous talk was this notion of micro interactions and I would say that one of the things that makes apps smart apps attractive is that they are optimized around these micro interactions and I'll try to show you that they don't have to be but the ones that we picked are so in this case here's the built-in growth chart that ships as part of Cerner's power chart straightforward clinicians can use it it's kind of confusing if you're not a clinician so the smart team built a visually much more sophisticated equivalent view this pulls the exact same patient data out of millennium but it wraps it in a much more sophisticated visual experience but much more importantly than the fact that this is prettier it also includes a view of that same data that is tailored for the parents of the child not for the clinician so this is a little bit of micro optimization of the user experience and in this case it lets the child's weight be symbolized with an icon instead of a graph point on a curve and it shows the child's height silhouetted against the mother in the father's height so that the parents get a sense of how the child is growing compared to where they ought to be very cool when I show this to our Pediatrics team they say I wish we had the resources to go build that that's something we'd really like to do but that's why we have apps okay a similar situation this is developed at Boston Children's and it's a simple display of pediatric blood pressures but what's different about it is that when you hover over the color coding of abnormality it gives you an explanation as to why for this particular height and weight of the child this blood pressure is abnormal even though in a larger child it might be completely normal and what our doctors have to do in millenium today is look up the blood pressure on the screen and then consult a nomogram in a textbook or taped to the wall to see if the blood pressure is abnormal for us what is this is seven-year-old 125 centimeter child with this simple little app which probably is no more than a few hundred lines of code that problem goes away another kind of micro optimization here's a case of a client authored app this is called evidential and it was built by the informatics team at Mayo and they're going to spin it out as a commercial product and what evidentially launch the app it pulls the documents for the current encounter out of millennium before it opens the page and then it puts the page up of the current documents you pick one of the documents and you can read the document just like you could within millennium and you'd say okay why would you do that we've already got a way to read documents well the reason is because they parse the document for medically interesting concepts and then they offer for the clinician a heavily curated set of links to the best evidence for the management of that clinical condition so it's a highly customized highly optimized reference tool that is linked to the current patient in the current patients documents it's a pretty cool idea it's not technically all that sophisticated but building that curated list of documents takes a place like the Mayo Clinic to do it that's not something that's going to get done in the Cerner content group at least probably not second thing it does is it allows the physician to email what they call an information prescription to the patient through the portal about the clinician about the condition so in addition to giving the physician something deep to chew on it gives the physician something that they can email to the patient through the portal now the demo that we did at hims we didn't hook it into our portal but it would be pretty straightforward to basically have the right mouse clicks a syn to the patient have it essentially pushed the queue of documents waiting for the patient at the patient portal here's another app that came from Intermountain very simple one screen app that displays the patient's bilirubin this is in a newborn and some of you know that when newborns emerge they may not have the liver up to speed yet in processing the blood breakdown products that are accompanied the birth process and if they don't they can get mental retardation from something called kernicterus and the treatment is simple you have to put the patient under ultraviolet lights for a few hours and that actually triggers off enzymes in the skin that break down the hemoglobin is it's a super simple way to prevent a devastating problem but if you don't know that your patient needs to be under those lights you're essentially committing malpractice so Intermountain built this simple display hooked it up to a little trigger that when that lab value comes in it pops it up and shows the doctor exactly where that patient sits on the need to be treated or not and if they do need to be treated then you can track that to completion to make sure that you can you've you've gone far enough to remove them from the UV therapy they've driven the incidence of kernicterus to zero at Intermountain by using simple techniques like this highly focused micro optimized education is another app the third-party company called polyglot it's optimized for medication handout information for patients who don't speak English they the app pulls in the Med profile for the patient when it first launches you pick a particular drug and you get a drug handout simplified information with icons that indicate when you take the drug and when you don't take it but more interestingly a list of 17 languages that they've translated these into and in this case I selected Korean and you get that drug information in Korean now multum supports English and Spanish I don't know that we've gone past English and Spanish but I can be pretty sure we're not going to get to Korean anytime soon but somebody's written an app that gets us there and then interesting product called visual diagnosis which is a tool and other decision support tool reference information that's optimized to help physicians take care of skin lesions in this case oh and actually any visual diagnosis that's the name visual DX it started out as skin lesions but it also includes radiographic findings and the like the app starts by launching and fetching the medications and the problems out of the patients record so that the clinician can see if the disease that the patient has matches what they're finding on the patient's body without having to type anything in so this is a little shortcut that gets you into that app and gets you useful information more quickly in this case I believe the patient has Legionnaires disease and you click on that and you get the app comes back now with the diagnostic information to help you interpret whether what you're seeing on the chest x-ray matches the patient that you have in front of you this is an app that we have actually deployed via the standard in page model but since it was too complicated to figure out how to query the diagnosis and the drug information from every Cerner client without a common nomenclature in place when we deploy it via the in page model the clinician has to type it in and it's not a big deal and it's a useful app and the clinicians like it but that one little trick of fetching that data using the fire service makes the app that much quicker and easier to launch so what kind of apps might appear clearly you've seen some examples here of decision support where we have complex or evolving logic and complex visualizations things that can't be captured in a simple static discern rule or an order set patient provider data sharing I've given you a couple of examples of where there's two views of the same data one demise for the doctor when optimized for the patient that I think will become an increasingly common metaphor mobile health applications where it's a it's a handheld device smartphone that using these fire services and those profiles I think will find to be very powerful and then it can work the other direction and the app can actually bring patient data into the workflow like from the population health cloud down into the vendors EHR this is how we'll push healthy intent out to non Cerner EHRs in places like Chicago and then this platform is also a good way to deploy national scale services like some of the genomics work that dr. Nolan described earlier in the morning where you want it to feel like it's a part of the EMR even though the data itself lives completely in the cloud what could stop this what could go wrong fire is unproven there's lots to learn about how well it works at scale fire doesn't have transactions support that is probably going to be a concern in the long run and even though you could combine spire services to give you a so alike model it doesn't have an official service oriented architecture support although there's some debate about how to add that in will vendors take their existing proprietary api's and most of the vendors have something equivalent to care where services and support fire on top of that we don't know we hope so we don't know will vendors adopt the profiles and the inherent mapping that's necessary to make the profile speak standard on the outside map to the local codes on the inside that's a lot of work and any of you have involved with mapping know how much that is how much work that is and will these app ecosystems emerge will there be app stores my guess is there'll be a Cerner app store and there might be an all scripts app store I don't know if we'll see a EHR health app store that merges across vendors in some ways really don't care as long as there's a robust model market out there what kind of apps will our clients allow to run you can be pretty sure they're not going to the doctors just point to any old app out there and fire it off because that app could be an app that just sucks data out and sells it overseas for for money and then if the apps are all coming from different creators what's going to happen to usability and color schemes and things like that do we need standards for usability of the apps so I'm ending with 6 seconds to spare and I'll stop there thank you you

7 Comments

  1. hi, thank you for the video! I would like to know how to switch from hl7 2.x (v2) to fhir, is there a roadmap or something?

  2. what is cerner doing on AI

  3. I'm a brazilian pediatrician. I loved you https://sb-apps.smarthealthit.org/apps/growth-chart/
    Is it possible run this app in localhost ????
    I do not have much knowledge but I have some friends who can help me… How do I make it work offline (in localhost machine —like a xampp or as a website)??
    I know the growth chart is meant to be run inside an EHR system like Cerner or Epic and pulls the age, height and weight information from those systems, but I do not use those systems.
    Is it possible to modify the app to work in Apache + Tomcat + Mysql localhost system??
    Thankyou — sorry for my bad english.

  4. <3 FHIR is being adopted! I look forward to the improvements this standard will bring to healthcare in our future! better late than never…..

  5. Hi Thanks, nice explanation. Can you please explain that how two independent fhir based application communicates.?

  6. checking in…it's been more than 6 months 🙂 how is the CEM to FHIR profile adoption going? – love the content! thanks.

  7. very interesting, thanks for the upload

Leave a Reply

Your email address will not be published. Required fields are marked *