Prescribing Behavior

At the InterSystems Global Summit a few weeks ago I heard about this new approach to solving medical problems, in lieu of medications. It’s the idea of prescribing behavior to a patient, just the same as a medication would be prescribed. The idea is basically centered around an app store for clinicians. A doctor will issue a prescription for an app, and use the medical app store software to ensure adherence to proper use of the app. The clinician will be notified when the patient installs the app, and will be able to track whether the patient is using the app as it was intended to be used. If the patient is not using the app then appropriate follow up actions can be taken (e.g. text message, phone call). It could be essentially the same workflow that happens today with medication adherence.

This brings up a couple of interesting ideas. One is that our day to day behaviors sometimes lead to improved outcomes (and perhaps more often than not!). If a patient has Type 2 Diabetes then diet and excercise can have tremendous benefit. This particular example is, of course, not a new discovery. The less understood, or perhaps less quantifiable aspect here is the impact from improved emotional health. Does happiness truly help a patient to combat certain diseases? Some researchers think so. In this line of thinking, an app that somehow tracks and improves happiness levels could also be used to collect data correlating to disease outcomes.

Another interesting idea is how this might impact the existing pharma industry. Surely there are still and will remain very valid reasons for and effective outcomes resulting in the prescription of real medications. I am in no way advocating this is a silver bullet, and we do not need medications. However I do know, from personal experience how technology can influence change in habits, for better or for worse. And I also have seen how our culture today readily embraces convenience – people want to have their cake and eat it too. If doctors start prescribing apps, and medication sales decline, pharma might need to rethink its strategy – perhaps it gets in on the app store business.

Although there are clinicians using this now from what I have heard, from the overall industry perspective I believe this is still a medium to long term plan. If I were to guess it would weigh heavily on the fact that there is still a generation gap with technology adoption. All in all the clinician app store approach is all about encouraging the patient by providing motivation to adopt and maintain behaviors that result in better outcomes. And things that improve outcomes are things that I am very much a fan of.

IHE Patient Care Coordination – Past, Present, and Future: Part III

The Future!

This is the third post in a series on the past, present and future of the IHE PCC domain. So what’s next? Lots of stuff! At our face to face meeting this past summer we held a strategy meeting to discuss what we are doing with our domain as we were in a place of needing such clarification. The results of that two or so hour long session were new vision and mission statements, and a set of shiny new strategic goals for our domain.


The vision of PCC is to continually improve patient outcomes through the use of technology connecting patients and their care providers across healthcare disciplines and care paths.


The mission of PCC is to develop and maintain interoperability profiles to support coordination of care for patients where care crosses providers, patient conditions and health concerns, or time.

Strategic Goals

The strategic goals of PCC, which are 3–5 years in length, are to focus on content, workflow and nursing.. These three goals originate out of the work we have been focused on for the past several years and so they are not new concepts to us. However we felt it important to document specifics items around these goals to ensure our path forward is clear.


PCC has had such a heavy focus on content over its lifetime, and naturally content standards and implementation guidance is changing along with the landscape of HIT. HL7 has recently produced the Consolidated CDA implementation guide, which directly competes with PCC content profiles. I am not convinced this was entirely intentional on HL7’s part, as the implementation guide itself is actually quite good and there are even a few references to PCC content templates within it. To be more specific, C-CDA replaces the family of HITSP implementation guides that all sit on top of PCC content templates, but C-CDA also has breaking changes to the existing PCC templates, and at the current time is US realm only. This last bit is a big challenge for many non-US implementers, and the reason why adoption and uptake of C-CDA has been primarily US focused vendors. Due to these recent events around content PCC feels that it should be proactive and engaged with HL7 to ensure that the responsibility to create and maintain content templates is shared between the two organizations.

So what roles do each play as it relates to content? I believe HL7 should continue to play the role of providing the framework aspect of content with a bit of guidance based on healthcare domain, so they would own how any given CDA section and CDA entry should be structured with minimal guidance on implementation details of those templates. PCC would own the more specific implementations of those artefacts based on specific clinical use cases. This would include extensions to the schema, value sets and optionality. This makes sense as HL7 has a lot of experience with vetting standards to ensure they are broadly adoptable, and IHE has a lot of experience working with stakeholders from a variety of medical disciplines and has a great process already in place (Connectathons) to test profiles.


Workflow has long been a focus of PCC but really only in piecemeal, which is the same approach many other IHE domains follow. By piecemeal I mean more focused inwardly on solving a clinical use cases that have been brought to our domain rather than taking a cross-domain approach. Yes we do have a few profiles that have crossed into other domains, but by and large we author those profiles within PCC and have not always actively engaged other domains in our efforts. I believe PCC is well positioned to expand outside of our domain and across to other IHE domains to bring together workflows that are realized in the real world but have yet to be well represented in the interoperability profiling space.

PCC has received several profile proposals this year (four to be exact) that came from other IHE domains. Those domains are Radiology and Patient Care Devices. So you can imagine our delight of this news after our recent strategy sessions which concluded this exact effort is something we should be working on. It seems to be confirmation in every way that we are moving in the right direction.


The Nursing Sub-committee of PCC was established in 2008 and has had decent participation over the years, however the uptake of work produced from this sector of PCC has not been strong. I believe this is primarily because the content profiles we have produced easily apply to both nursing and clinician/physician based content. The difference however, is primarily in the workflows, and workflow also happens to be one of our strategic goals. We have learned that nursing workflows are often times vastly different from their counterpart clinician/physician workflows. And so we are presented with an opportunity to provide better guidance in this space.

In Closing

Overall PCC is in a great place right now, on the cusp of exploring new opportunities as the world of HIT and interoperability continues to mature and change. If you are interested in getting involved check out our wiki page here.

2015 IHE NA Connectathon

It’s time to rock your interop at the 2015 IHE North America Connectathon! If you are not familiar with IHE Connectathons there is certainly sufficient information on the internet to educate you. If you or your company has an opportunity to participate and you are on the fence I would strongly encourage you to attend. Not only is it a great technical conformance testing event, it is also a great networking and idea sharing opportunity. Registration opens on August 25th, 2014. So go forth, register, code, configure, and interoperate! Hope to see you there!


*Infographic courtesy of HIMSS Marketing

IHE Patient Care Coordination – Past, Present, and Future: Part II

The Present

Today the PCC domain is in a place of discovering where it is we are going next. We have published a few dozen profiles over the past several years, many of which are content focused, but some of which also cover integration and workflow. As the HIT interoperability landscape evolves PCC must continually assess the work it is producing for validity in the marketplace. Specifically with the advent of HL7’s Consolidated CDA implementation guide we now have duplicate templates and a split in the market. PCC has many international stakeholders that continue to reference our templates, however most US based systems are focused first on C-CDA as it is core to the interoperability components of Meaningful Use Stage 2 compliance.

So how are we figuring this out? We are talking amongst ourselves first and foremost to better understand what our vision and mission is, what our core values are so we stay true to our purpose and role within IHE and the industry. Secondly we are talking with external organizations to ensure we align and/or harmonize our work efforts as appropriate, lest we find ourselves suffering from the Ostrich Effect.

To provide a little background (and expand on my previous post) we have created and published a total of 23 content profiles, 7 integration profiles, and 5 workflow profiles since 2005. This year we are publishing two profiles, one of which is new, the other is a re-write/update, and also a white paper. Our profiles are Multiple Content Views (MCV) and Reconciliation of Clinical Content and Care Providers (RECON). Our white paper is A Data Access Framework using IHE Profiles (DAF).

MCV provides guidance on how text in CDA documents may be tagged to achieve different rendering behaviors. For example, a patient does not necessarily need or want to see all of the details of their lab results, they may just want to simply know if the results are “good” or “bad.” MCV provides a mechanism upon which data can be presented to meet this requirement. However, in no way does MCV change, remove or exclude data from the CDA document itself – it is still intact, in the narrative text and/or in the structured entries. MCV is really focused only on rendering of the data, and the narrative text in CDA documents is what is primarily leveraged to achieve this end.

RECON was originally published in 2011, focusing on problems, medications, and allergies sections. Upon further assessment last year it was determined that we needed to make two adjustments to the existing RECON profile : provide an easier implementation path and expand to include additional sections of data. RECON is important to patient safety to ensure that the right data is available to the right person at the right time. Without reconciliation in any given clinical workflow pertinant data may exist across multiple documents or locations in the system and the care provider may not have time to find that data, and assemble in a way that is meaningful for appropriate care of the patient. For more detail see the use cases outlined in the RECON profile. This is especially true in an emergency situation where time is of the utmost importance.

The DAF white paper describes a framework by which IHE profiles can support multiple means of access through substitutable modules (IHE profiles). This work effort was brought to IHE via the US ONC, and is not so much an attempt to map out implementation guidance, but to explore how various IHE profiles could be implemented to create successful interoperability scenarios, based on various use cases and business requirements. This effort utilized a few different enterprise architecture frameworks to assist including:

We covered these new profiles, as well as other PCC topics on our annual domain update webinar this week. This webinar was recorded and will be available online soon at

If you look at our work this year as well as last year you will see a pattern emerging that our focus is shifting away from straight templating of content, and more toward how that content is used in various systems and situations. I see this as a natural next step in the evolution of content-based standards. However our templates are still quite important to many non-US based stakeholders, and so IHE and HL7 are working together at the executive leadership level to resolve the issues around duplication of templates that exist today. My sincerest hope is that IHE PCC is able to remain in the content template guidance space as it is vitally important to working through content requirements for a number of international stakeholders.

IHE Patient Care Coordination – Past, Present, and Future: Part I

The Past

As co-chair elections are around the corner it got me to thinking about where the Patient Care Coordination (PCC) domain has been, where we are today, and where we are going. We operate in such a fast changing world in health IT and if you blink your eyes you will miss opportunities to innovate and impact the future of health IT in a positive way. This will be a multi-part blog post that takes a look at the past, present and future of the PCC domain.

My first IHE Patient Care Coordination (PCC) meeting was early in 2007 at the first face to face meeting for writing profiles of that cycle. I was not only a green software engineer (more or less) but also completely new to the world of health IT. My involvement at that time was a whopping six months, and that six months was spent primarily working on a new login process for my company’s patient portal application. So much for bringing any clinical application development experience to the table. Fortunately I was surrounded by peers in IHE whose knowledge and experience far exceeded my own and I had the opportunity to learn from and lean on their expertise. My task was to help write an obstetric profile, one that was based on various paper standards in use. At the end of that summer we had published the Anteparum Summary (APS) content profile (now in Final Text). In addition to participating in creating the APS profile I also had the opportunity to implement this profile along with the family of ITI profiles for document exchange (XDS, PIX, ATNA, CT) within an HIE.

In the following years in PCC we continued working on several other profiles covering a broad range of clinical use cases, providing guidance on content as well as integration. My focus was specifically around obstetric profiles, focusing on the ante, intra and post partum phases of the birthing process. I switched companies and continued developing interoperability solutions for the next several years. Along the way my IHE PCC colleagues bestowed the honor upon me of co-chair of the technical committee. I did that for a couple of years, and it was then that I developed a much more complete understanding of the processes within IHE as well as the importance of and opportunity of this organization to influence the world of health IT and ultimately improve patient care and outcomes.

After one term I stepped down as technical co-chair due to workload constraints (my wife and I also were blessed with a total of four children from 2004 to 2011 so family was certainly a big part of my life, and still is). A year or so later one of my colleagues convinced me to run for PCC Planning Committee co-chair, I thought on it for about 30 minutes and accepted the nomination and was voted in. As we are moving into another year of the IHE development cycle co-chair elections are upon us once again and I intend to run for another term of PCC Planning co-chair. Should I have the honor of serving my domain for another two years, I intend to sail us in some slightly new directions, focusing more on workflow and a bit less on content (but certainly not excluding content!), but more on that later in a subsequent blog post.

From the inception of the PCC domain in 2005 until the present (2014), PCC has published upwards of 35 profiles and several white papers. It has largely filled a gap in the industry providing content template guidance that has been eagerly adopted by implementers as well as international programs and initiatives (e.g. Meaningful Use, epSOS, ASIP Sante). We are now at a juncture of figuring out where to go next. Content template guidance will likely be a part of our future, but we must also consider our role in the workflow space, and how we can help to improve patient outcomes by providing guidance on the use of standards around interoperability.

Navigating IHE PCC Content Templates

One of the challenges with reading and understanding how CDA templates link together in PCC is that we are continuing to create new content templates, and have several still in Public Comment or Trial Implementation state. This means that we have document, section and entry content templates in several different published documents instead of neatly wrapped up in a single technical framework document. A single technical framework document (volume 2) is the end goal, but we must eat this elephant one bite at a time and deal with the complexities that come with such a task. Basically templates can be documented in one of 3 places: PCC Technical Framework Volume 2 (hereafter referred to as PCC-TF–2), CDA Content Modules Supplement, or profile supplements to the PCC-TF–2. Where templates are documented depends on their current state in the IHE development and publication process: Public Comment, Trial Implementation or Final Text. So yes, it is a bit confusing to navigate at first, but once you understand the makeup it is actually fairly straightforward. First let us cover these 3 locations, then we will talk about specifics of the types of templates and where each might be found.

PCC Technical Framework Volume 2

This contains all templates that are in Final Text state. That is, those templates that have been released into production. It is certainly possible that document templates in profile supplements may reference templates here.

CDA Content Modules Supplement

This is a holding tank for section and entry templates that are in the Public Comment or Trial Implementation state. PCC created this document several years ago to accomodate the need to share templates in draft state (Public Comment or Trial Implementation) across and between various profile supplements. At the time we had a lot of duplication across profile supplements and it quickly became very complicated to manage so this was a nice change. As it turned out this also became a great tool for other IHE domains to use as well. The QRPH domain has several templates in this same published document.

Profile Supplements

New IHE profiles are written initially as supplements to the Final Text version of the technical framework. This was intentionally designed in this way so that profiles must go through a period of implementation and testing to determine if they are ready to be released into the wild, which in IHE is defined as Final Text. More information on the process can be found on the IHE wiki. Getting back to the topic at hand, only document content templates will be found in profile supplements. Those document templates will reference section and/or entry templates that will be found in either the PCC-TF–2 or CDA Content Modules. So now that you understand a bit about where templates can be found here is a quick breakdown of the different types of templates that are found in these locations.

Document Templates

Document templates contain a list of section (and sometimes entry) templates and are identified by a name and a LOINC code. Document templates may be found in either the PCC-TF–2 or in profile supplements.

Section Templates

Section templates may contain other sections or entries, or both. These templates may be found in either the PCC-TF–2 or the CDA Content Modules Supplement, however are typically not found in profile supplements.

Entry Templates

Entry templates are essentially the same as Section templates, in that they may be found in PCC-TF–2 or CDA Content Modules, but typically not in profile supplements.

In summary consider the matrix below that shows where each type of template may be found. Note the the PCC-TF–2 is the only location where all three are found, and this makes sense as the ultimate goal is to roll everything into the technical framework.


Finding a Template

To find a particular template of interest the best way is to look in the table of contents in the appropriate document, alternately one could search by name, or better yet by the template identifier. Every template in PCC (as well as other domains) is assigned a unique template identifier. The registry for these templates is available on the wiki, however these template identifiers also appear in the three document locations covered in this post (reference above matrix for which ones appear in which document). So while searching by name will get you most of the way there, searching by the unique template identifier is gaurenteed an exact match.

This revised approach of template management has certainly helped PCC (and QRPH) to manage the influx of new templates over the past several years, with the trade-off that finding the template you are looking for takes a bit of understanding of where to look. Hopefully this post fills in some of the gaps for folks who need it.

Collaboration is Key

I attended the IHE North America Connectathon Conference this year on January 29th for the first time ever. I have been to several IHE Connectathon testing events, but never to the conference where the “suits” are. I was pleasantly surprised by the content and ensuing discussions over the course of the day. I was surprised to see that approximately 80% of the audience’s hands were raised when asked by one of the presenters who had never attended one of these events before. I think this is fantastic and represents that IHE is healthy and growing.

Keith summarizes the event nicely on his blog post here, so I will not be covering those details, but I do want to elaborate on the value of collaboration, which was a key theme that was presented and discussed at the conference. I have seen projects fail to succeed based on poor or no collaboration between the participants. Collaboration is challenging because of many different barriers including geography, language, and personality.

Sheer distance between individuals creates a natural barrier. It takes more effort to communicate when you are not face to face with your teammates. It can be done yes, but often times is not because of the extra effort required. Not being able to see body language, or pick up on other non-verbal cues makes for tough communication. However, this can be overcome through the use of video conferencing technology, chat tools, and other online collaboration tooling. When such tools are not available, careful consideration of how ideas are presented and discussed can be used to create productive outcomes on a remote conference call.

Language barriers can also impact overall collaboration efforts. Many of us come from different cultural backgrounds and speak different native languages, with different accents. While the ability to communicate is typically present from either teammate, the question comes down to the effectiveness of that communication. The effort required for someone to understand my native Georgian tongue, for example, may be somewhat challenging (probably an understatement!), or vice versa. However, I have found over the years that the more I work with individuals from other countries and backgrounds the better I am able to understand and also to be understood through the use of direct and plain language and clear thoughts. So this challenge is definitely something that practice and experience can help to overcome.

Personality is probably the single biggest challenge around collaboration. I have seen projects slow down immensly because of personality differences. To be able to stay above the personality conflicts and focus on the end goal is the sign of a team with a strong leader. Even in the absense of strong leadership to provide this guidance I encourage everyone to consider how they can help to better such a situation. Stay professional, focus on the mission at hand and keep asking if every conversation, work item, etc is somehow contributing to the successful completion of the mission of the project.

With the growing landscape of telecomutters we are seeing more and more remote collaboration. Joint work between SDOs, profiling organizations, governments programs, vendors, and patient advocates will ever more rely on remote collaboration. Yes, there are face to face meetings, but they are expensive both to the facilitator and the attendee, difficult to coordinate and often times result in low turnout. So as a participant in the healthcare IT movement in an ever-growing remote culture please think through how you as an individual can contribute to the overall success of any given project or initiative that you find yourself a part of in HIT. If we all become aware of our role(s) in the project, and study on how we can be most effective then we can transcend the above challenges and create successful outcomes!

Use Cases – A Path to Clarity

Some call them user stories, others all them use cases but all in all they serve much the same purpose: to align the business and the technical interests in a project. Use cases have many benefits when used correctly and I have seen them used effectively in several different areas of life including healthcare standards, software development, and family decisions.

Use cases are beneficial in many ways. At the very basic level they bring needed clarity to any given situation by stepping back to consider what it really is that is trying to be achieved. I’ve seen so many software developers that just jump in and start designing and coding without vetting the business requirements first. And I know this especially well because I used to be one of those developers (it is an impulse problem, and as a developer gains experience he/she should learn to control it) . Use cases act as a bridge between the business and technical interests by providing a communication path for these different groups. In earlier software design and development models the generally accepted approach was to thoroughly vet the requirements, which included use cases, by the business analyst/product team. Once everything was vetted properly, which could take months, documentation was handed off to the development team to execute on them and deliver software. The problem with this model is that there is little to no communication between those two groups. As we have learned in the past decade or so requirements often change before software is delivered to the field, and methods have been created to combat this challenge. Use cases and user stories are often used as a central discussion point in support of such methods. Use cases also bring confirmation of the goals of the project by illustrating what the software (or whatever the use case is being applied to) is supposed to achieve. It is a way to “check your answer,” similar to what one would do to validate a math problem.

I have much experience with use cases in the realm of healthcare information technology standards profiling in my work within Integrating the Healthcare Enterprise (IHE). A profile in IHE provides implementation guidance for systems in the healthcare domain. One of the base level requirements of a profile is a use case, or set of use cases. I have been involved in the development of over 15 IHE profiles over the past several years and every time I discuss a profile with someone, be they architects, engineers, product managers or VPs, I always get back to the use case at some point. It is a very effective way to center the conversation around one central goal, consistently representing the message across and between these different groups.

Use cases can often be effectively applied to planning family excursions as well. My wife and I are very fortunate to have four children, and this means that we must thoroughly think through any vacations we plan, day trips or other traveling we may choose or be required to do as a family. Although we do not use the same terms as I would in my professional career, we use the concept of use cases constantly by playing out what our trip will look like. For example, say we are planning a camping trip, we need to plan what to bring (because no one wants to be stuck in the woods without the necessary supplies to care for a two year old). So we could play it out in conversation, my wife may say to me “Honey, we will be changing a few diapers while we are in the woods so we will need to bring plenty of supplies.” And I may say “Ah of course! This is a fantastic idea and makes complete sense! Let’s be sure to pack those items so we do not end up in an undesirable situation.” This of course is a bit of a stretch because we would not necessarily need to have such an explicit conversation. At this point in our child rearing experiences we inherently know that diapers, wipes and a sealable trash bag are a must on our packing list. However the point I am making here is that all of us do this in our heads on a daily basis, whether it is for a camping trip, a grocery store run, or something else that needs to be planned. It is a natural part of our psyche, so it makes sense that this can be effectively applied in a work situation as well.

In the event that use cases are not used for a project or at least not done so properly many negative consequences may occur. The worst case scenario would be a complete mismatch between what the stakeholders are expecting and what the development team delivers. In the camping trip example this would be the failure of one spouse delivering what the other spouse is expecting. Projects that fail to keep communication lines open between stakeholders and the development team are at a very high risk of this landing in this situation. It is easier than you might think to accidently “fool” the stakeholders of what is being developed. Without consistent hands on functionality demonstrations and reviews it is hard to really get a pulse on how closely aligned the development work is aligned with the project requirements.

Use cases help to mitigate this risk by bringing together all parties on agreement and understanding of the story the software should tell, that is, the functionality that the user will interact with, the problem being solved, and how from any end user’s perspective it solves it. Not using use cases usually results in the developer writing code as directed but without at least in part understanding why. This results in a high risk of delivering a solution that is far off the original target as understood by the stakeholders. In the camping example from above this would mean a messy situation in the middle of nowhere. In which case I would at least hope there is a water source and the temperature is not too cold! In a work environment this means money lost, unhappy customers, or worse: patients not properly cared for because the system the clinician is using does not provide the appropriate functionality.

Use cases need not be complicated. If you are in doubt of how to start my suggestion is just to write a short narrative of what you want to accomplish. If you find your narrative becoming overly complex then split it apart to more manageable pieces. Most importantly remember that use cases are meant to help clarify the business requirements, improve communication and ultimately create better results in whatever situation they are applied to.

New Beginnings, Passion, and Purpose!

Although I am not typically a big New Year’s resolution sort of guy I have, somewhat unexpectedly, ended up in a position this year of having an opportunity to start fresh with my career. I have had the very fortunate opportunity to join with Ready Computing as a Standards and Interoperability Architect. We are a small healthcare IT consultancy, who also dabbles a bit in other industries. This new opportunity will allow me to continue problem solving in the healthcare domain, which I cannot express in words how excited I am about.

So that brings me to the purpose of this blog which is primarily to explore thoughts on healthcare IT, but since this is my personal blog I cannot guarantee that will always be the case. I am also married and a father of four and an avid Toyota Land Cruiser fan. I enjoy working on my truck as it presents me with a different sort of problem solving than I get in my career, which I find helps to maintain perspective and understand different approaches to solutions, not unlike that of how learning a new programming language can help to make one more proficient at their primary programming langauge. My point here is that I may wander off into other topics.

Initially the reason I got into HIT was simple – I needed a job, a raise to support my new family and more opportunity in the technology space and found that at a company that happened to be focused in HIT. I was fortunate enough to have the opportunity through my last two employers to participate in the development and implementation of several todo: IHE profiles – and for this I am ever grateful because it has afforded me the opportunity to be a part of the last frontier of electronification of an industry.

However the real reason I remain passionate about HIT and refuse to leave it (as long as I have the option not to) is because of my own experiences with the US healthcare system with my family. In spring 2012 my wife rushed our oldest daughter (seven years old at the time) to the hospital with terrible stomach pains. She spent three hours in the closest emergency room to our home, and then was transported to a children’s hospital for further examination. I found out about all this about twelve hours after it started when my wife was finally able to contact me via my cell phone as I was in Napoleon’s Apartments in the Louvre in Paris, France. I was in Paris for IHE committee meetings. I flew home the following day, our daughter was in stable condition but could not eat solid foods. We had a team of doctors trying to figure out what was going on, and my wife and I felt more or less helpless. We were in the hospital a total of nine days and were discharged with a diagnosis of Eosinophilic Gastroenteritis, and our daughter with a feeding tube installed with a week’s supply of formula. She stayed on the formula for nine more days. She could also drink orange gatorade so we made every form of gatorade we could imagine – popsicles in all shapes and sizes, slushies, etc. We were still trying to process all this, and in typical fashion read many of the worst case scenarios – about people with this disease who could eat nothing but hypoallergenic formula for the remainder of their lives.

To make a long story short we had a comprehensive allergy test run and found her allergic to the following foods: pork, beef, lamb, peaches, beans, tree nuts, soy, navy beans, peanuts, dairy, eggs and mustard. In the end this has all turned out quite well as from that point forward we knew what it was we were dealing with. Additionally, since her reaction is gastric and not anaphylactic we can simply avoid consumption of food (versus airborne exposure) she is allergic to and she will be fine. And she has been ever since. She is now a happy nine year old, doing well in school and maintaining a healthy weight.

While our experience was fortunately not a tragic one, it still made me begin to think through the many ways things may have not turned out so well, and often do not for so many families. In our case we had been dealing with this disease since she was born but we did not know it. For some families seven years would be too long. Had her reaction been anaphylatic and not gastric we may have found ourselves in a very different situation.

So this is my story, and now the reason behind my passion for driving forward the electronification of healthcare in the US and worldwide. I very much look forward to continuing the march, continuing the innovation and continuing the betterment of healthcare!