Clinical Architecture Blog

Information Management #1 – Digital Empathy

If you are reading this blog three things are likely true.  (1) you are somehow involved in healthcare IT (2) you can be classified somewhere on the information-nerd spectrum and (3) you are looking for some answers to the issues that plague our industry.  If you fit into those three categories (as I do) you almost certainly realize that if our industry had a “coin of the realm” it would be information.
We collect it, receive it, store it, display it, send it, aggregate it and analyze it.  So it is a safe bet to say that information is important to us.  Unfortunately, it is also the bane of our very existence.  Why?  The answer is simple... Sometimes it lies to us

Just as “good data” is useful and illuminating, “bad data” is noisy and deceiving. 

In healthcare IT, information can function in a number of roles.  We have reference information that comes from elsewhere and is leveraged to define a portion of our application.  We have master information, which is typically something we create and manage to define other, more local, portions of our application.  We have instance information, which moves through and accumulates in our application.  Regardless of which type of information you are considering, being able to identify which pieces of information are good and which are bad can dramatically affect the performance of your application.
While instance information is typically the most abundant form of information in an application, the impact of bad instance information is typically limited to the instance or the information it is directly related to.  Reference information and master information, however, are typically what the instance information relies on to define its identity, classification and other critical meta-data that defines the path and patterns of the instance, and all other instances, through the application.  As a result, bad reference or master information can have a significant impact on the performance of an application.
As we as an industry have tried to leverage our information in bigger and better ways it has created an awareness of the importance of data quality, data management and data governance.  But before we can discuss any of these notions lets first ask ourselves a question: “What is the definition of bad information?”  Assuming that if we can identify bad information and remove it, whatever remains will be good information.

For the purposes of this article we will consider the concept of bad information within a specific environment, a software application. 
If you were to ask most people who is impacted by bad information in a healthcare application they would likely respond with “the user”.  This typically being a provider or someone who supports the care process.  They might also respond with “the patient”.  In this case the patient is a manifestation of the instance information so that is also a valid response.  Some, hopefully the engineers, would also respond with “the application”, this is true and it is something people do not always consider. 

I'm sorry Dave, I'm afraid I can't do that

In a modern application the system does not just hold and display information to the user, it is also a consumer of information.  In fact, the application itself is the most susceptible to the impact of bad information. It does not have the ability to independently question whether the information is good or bad – it must believe that the information is good in order to function. This should not be a surprise, the annals of science fiction are littered with the rusted corpses of robot villains that, when presented with the notion that their data was incorrect, tragically self-destructed with smoke billowing from their cooling ports and shuddering cries of “does not compute!”
My point is, there is a significant difference to what a human considers bad information and what a software application considers bad information.  (There is more to be said about this but I am saving that for the next post)
In software design we spend a great deal of time trying to document and understand the players involved in the use of our solutions.  This same consideration is rarely extended to the software itself.  This can be a fairly significant oversight.  This imbalance in consideration can result in a situation where we build an application that streamlines the entry of data for our user population that is totally useless when the software is trying to assist the provider with decision support or research.  In order to truly manage information, we need to understand and respect this dynamic.  For lack of a better term let’s call this awareness digital empathy.
Digital Empathy: Understanding that a modern healthcare application is a legitimate consumer of all variants of information and must act on the available information in a literal and logical manner.
What are the major axioms of digital empathy?  Let’s try to think like an application.
1.       Words are meaningless
When I watched the Charlie Brown Thanksgiving special as a kid I would always be annoyed when an adult spoke to one of the peanuts kids.  “Waa wa wah, wah wa wawa wah”. What the heck are they saying and why can’t I understand.  This is what it is like for the application whenever someone enters free text information.  Software relies on structured data sets, using terminologies in order to process information.  Unstructured free text is just “Wa wah wawa wah” that it can store and display later for another peanut parent to interpret (not Pigpens parents – they were hauled off by social services).
2.       Every  term is sacred
There is a part of human brain called the reticular activating system or RAS.  This RAS is the mechanism that constantly pays attention to the world around you, tunes out the noise and alerts you when something needs your attention.  Software applications do not have an RAS, so every piece of information is viewed as relevant unless there is specific logic or content that tells it otherwise. Part of making this leap in understanding is realizing that ALL the information we feed software is important to the software, regardless of where it comes from.
3.       Terminology matters
Software knows the codes systems that is knows.  For an application to consume information, it can’t just be a structured code, it must be the code system the application is expecting.  When I am orchestrating information across an enterprise consistency in terminology is huge.  The exact same application, operating in multiple locations, with different local terminologies is not the exact same application.  Also, in most applications, the ‘words are meaningless’ axiom applies to terminologies as well.  The software pays attention to the code and where it believes it came from (the code system or dictionary).  If you change the description on a code and, in doing so, change the meaning… guess what… “waa waah wawa wah wawa”…
There are innovative technologies, like our Symedical® platform, that help applications cope with these and other limitations that are common in healthcare applications.  But even with that kind of advantage, possessing digital empathy is an important tool when you are trying to understand and isolate bad information. 
In the next post in this series we will discuss the different types of bad information and where they come from. 

Please feel free to share your thoughts on this post and if you feel any important axioms for digital empathy were missed.
Posted: 9/9/2015 11:20:15 PM by Charlie Harp | with 0 comments

A Meaningful Scavenger Hunt


In order to comply with the many of the requirements for meaningful use and other state and federal programs we are required to interoperate or report using specified terminologies or "standards".  Here are a few examples from the Standards Advisory from

Purpose Standard
Allergy Reactions SNOMED-CT
Care Team Member National Provider ID (NPI)
Ethnicity OMB
Encounter Diagnosis SNOMED-CT / ICD-10-CM
Family Health History SNOMED-CT
Gender Identity SNOMED-CT
Immunizations CVX/MVX
Lab Tests LOINC
Medications RxNorm
Medication Allergies RxNorm
Numerical References and Values The Unified Code of Units and Measures (UCUM)
Patient Conditions SNOMED-CT
Preferred Language ISO 639-1 / ISO 639-2 / ISO 639-3 / RFC 5646
Dental Procedures Code on Dental Procedures and Nomenclature (CDT)
Medical Procedures CPT-4 / HCPCS / ICD-10-PCS
Race OMB
Radiology RadLex
Sex HL7 Administrative Gender
Sexual Orientation SNOMED-CT
Smoking Status SNOMED-CT
Unique Device Identification FDA Unique Device Identifier
Vital Signs LOINC
 While the above is a list that provides “guidance”, it is a little vague.  For example:
  • There are over 400,000 concepts in SNOMED-CT.  Which ones do I use for ‘sexual orientation’, which do I use for ‘gender identity’?  Why do we use a totally different terminology, HL7, for ‘sex’? 
  • How can there be more than one "standard" for interoperating with medical procedures and  Encounter Diagnosis?  Do I have to support both to comply?
  • Can I post-coordinate RadLex?  Is there a specific way that should be done?
  • UCUM is not a terminology… it is a grammar.  How do I use it as a “standard”?
  • The NPI is less of a standard and more of a giant spreadsheet in the sky.  How can I be sure I have the right identifier for the provider?

Beyond the ambiguity, there is additional complexity.  The listed standards are all released with different schedules and all come from different sources.  They all have different formats and varying levels of complexity.  

These are just the standards required for Meaningful Use.  Terminologies required by other regulatory initiatives, like the CMS Health Services Delivery specialty codes, are only made available in PDF documents.

Anyone working with these standards should also know that they change over time.  That means that in order to use them effectively you not only need to find them and understand them, you need to keep them current as well.

Great! You've killed the invisible swordsman.

In the 1986 movie “The Three Amigos!” there is a scene where the amigos (Steve Martin, Chevy Chase and Martin Short) need to find the way to the lair of the villain, El Guapo, to save the damsel in distress.  They are given the following guidance:

“We go east...through the desert until we come to the singing bush.  When we find the singing bush...we say the magic chant, each fire one shot in the air...and that will summon the invisible swordsman...and he will then show us the way to El Guapo's”.
Whenever I think about standard terminologies it reminds me of this scene (and click the YouTube link above for the full effect).  As an industry we need to do something that should be fairly straight forward, use the required standards.  What we end up with is a vague scavenger hunt that requires us to become terminologist and experts on not one but twenty terminologies.  
To do this properly you could probably occupy a team of four to eight full time resources finding, loading, updating and verifying all that content.  But you don’t have to…
For several years now, our Symedical® platform has provided our clients with access to over 300 content assets, including standard terminologies, delivered in a standard format and updated automatically.  I am delighted to let you know that very soon we will be making this service, complete with automated delivery, available as a standalone offering.
We are calling it the Clinical Architecture Content Cloud and it will give you what you need in a format you can use.  Watch this space for a press release that will provide more details.

Have a great weekend!  Next week I will post the first in a series of articles on managing data in healthcare.
Posted: 8/6/2015 11:21:14 PM by Charlie Harp | with 1 comments

Semantically Enabled Medication Reconciliation

I was recently asked “Why is semantic interoperability important to medication reconciliation?”
My default answer is if you are using terminology to convey information, sharing that terminology between software applications and expecting to do anything useful, semantic interoperability is not just important, it is necessary.  But that would be trite… so let’s approach the answer to this question in a more verbose and systematic way.  And let’s start with an underlying fundamental question.

What is medication reconciliation?

Here is how the CMS website defines it:

“The process of identifying the most accurate list of all medications that the patient is taking, including name, dosage, frequency, and route, by comparing the medical record to an external list of medications obtained from a patient, hospital, or other provider.”

Here is how the Institute for Healthcare Improvement described it:

“The process of creating the most accurate list possible of all medications a patient is taking — including drug name, dosage, frequency, and route — and comparing that list against the physician’s admission, transfer, and/or discharge orders, with the goal of providing correct medications to the patient at all transition points within the hospital.”

My (engineering biased) definition of Medication Reconciliation is as follows:

A workflow in a clinical application where the software aggregates medication history data for the patient, from multiple sources, into a single medication history summary (a best possible medication history or BPMH) in order to provide accurate display and enhanced clinical decision support.

Why do Medication Reconciliation?

According to the World Health Organization, an up-to-date and accurate patient medication list is essential to ensure safe prescribing in any setting.

According to a Leapfrog Hospital Survey in 2012:

  • 10 to 67 percent of patients have at least one prescription medication history error at hospital admission
  • Medication reconciliation errors are estimated to contribute to 20 percent of adverse Drug events (ADEs) within hospitals.
The primary driver for Medication Reconciliation is patient safety through the reduction of ADEs related to an incomplete understanding of what medication the patient is on, or should be on.
It is also worth noting that medication reconciliation is also a part of Meaningful Use Stage 1:

Certification Criteria* §170.314(b)(4)
Clinical information reconciliation
Enable a user to electronically reconcile the data that represent a patient’s active medication, problem, and medication allergy list as follows. For each list type:
(i) Electronically and simultaneously display (i.e., in a single view) the data from at least two list sources in a manner that allows a user to view the data and their attributes, which must include, at a minimum, the source and last modification date.
(ii) Enable a user to create a single reconciled list of medications, medication allergies, or problems.
(iii) Enable a user to review and validate the accuracy of a final set of data and, upon a user’s confirmation, automatically update the list.

What does Semantic Interoperability have to do with it?

First, let’s demystify the term semantic interoperability. 

In order to accomplish the objective of medication reconciliation we need to be prepared to take information from somewhere else and make sense of it in our application.  There is a decent chance that the information we are receiving will have codes that are not the codes that our application uses.  The process of translating this “other code” into a code our application can use is semantic interoperability.  Most of the time this is accomplished using a concept map.  So, at its most fundamental level, semantic interoperability is using a map to translate from one set of codes to another.  This is how we have accomplished a form of legacy semantic interoperability for decades.

Unfortunately, the terminologies we use in healthcare are not static.  Healthcare is always changing, and with it, so do the terminologies and knowledge we produce to support it.  For medication reconciliation to work, we must be able to react to new and changing information in a timely manner.  As a result, in order to ensure quality and timeliness, we need to be diligent about the mapping process. 

When it comes to creating and maintaining a map the economics are pretty straight forward.   Your options are to allocate your own resources to do it, hire consultants to do it or license software to semi-automate the process, like our product, Symedical.  Regardless of the approach you choose, mapping is not a one-time event, it is a long term commitment. 

Code-Based Interoperability

The national library of medicine provides a data service called RxNorm.  The original objective of RxNorm was to support interoperability between known drug terminologies.  More information on RxNorm can be found here.

There is a common misconception that RxNorm solves the medication interoperability problem.  The truth is RxNorm can help but it does not solve the problem.  A code-based map (or Meta-thesaurus) can be very useful if the following conditions are true.

1)      You can always identify the source of a code you receive (the author of the code)
2)      The code always matches the term (a human has not overridden the term)
3)      The source never changes the meaning of a code
4)      A new term is not introduced at the source before it is introduced in the map

Having a mechanism that maps the term on a semantic level, based on the term itself not just the code, is important if you want to avoid service failures and potentially patient safety risk.
The important thing to remember is that static maps were something that was “good enough” in the past when anecdotal interoperability was all that was required.  As we increase the degree to which we leverage external information we increase the need for a more dynamic and “aware” interoperability mechanism.

The Medication Terminology Landscape

RxNorm is a fairly decent standard terminology for medications that is available in the public domain here in the US.  There are also a number of very good commercial medication compendia that are commonly used:
  • Cerner-Multum
  • Elsevier-Gold Standard
  • Hearst Health-fdbHealth
  • Truven Health-Micromedex
  • Wolters Kluwer-Medi-Span
In the US we also have another terminology that is used quite a bit, the National Drug Code or NDC.  This is a product level code that commonly represents packaging information in addition to the medication itself.

While having a plethora of quality terminology options is good on many levels, it also increases the likelihood that we will receive a code that we do not understand.  We also need to remember that we might receive patient medication history data that is using a home grown code or even free text information.


Beyond interoperability

Just realizing that we require semantic interoperability to accomplish the objective of medication reconciliation is not all we need to do it well.

Aggregating and translating medication codes is a basic requirement, but in order to establish the “best possible medication history” we will need to perform some additional semantic and / or ontological magic.

Unstructured Text

Much of the information we have in healthcare systems today is locked in unstructured notes.  Many of these notes like a history of present illness, medication questionnaires and previous inpatient visit discharge notes may contain relevant history.  Having the ability to extract medication history details from unstructured text can provide important information that you might otherwise miss.  Having a semantic platform that can be configured to target drug history or order details and turn that information into computable codes and values can provide a whole new dimension of information that would otherwise be lost.

Medication History Summarization

When you receive information from your external sources, structured or unstructured, and you go through the process of translating the data to a terminology your system understands, you still have another potential issue.  It is likely that you will be inundated with duplicated information and potential noise.  In order to consolidate this information into a best possible medication history you will need to synthesize a medication history summary.  This process removes the duplicates and organizes the medication history in a way that makes sense to the clinician.  In addition, that medication history will now make sense to the clinical decision support algorithms that are looking for interactions, duplicates and other potential issues.

There are a number of mechanisms that you can leverage to achieve this kind of summarization.

Post Coordination

You can have content or a mechanism that takes normalized history items and breaks them apart into their components.  Once you have the components for each item you can conceptually group them. 
For example, if I receive multiple instances of Warfarin, as in the example below, through post coordination we can remove the duplication and summarize the medication information at a level that makes the most sense for our use case.


Classification and Indication Grouping

In addition to ingredients there are other groupers that can be used to summarize medications.  One of these if the medication’s class and another is the known or likely reason the patient is taking the medication, commonly called the indication.  These groupings can be useful to see if there are therapeutic duplications or to determine if what looks like a duplication is actually a change in therapy over time.  This type of data is available from several of the drug information vendors that were listed previously.  These types of relationships can be accessed through database calls or through a terminology service API.
These kinds of summarizations and groupings will enable you to display and create functionality that can assist clinicians in reconciling any number of disparate medication lists received by the application.

Semantic Interoperability

In this article my objective was to answer the question about the need for semantic operability to effectively perform medication reconciliation and get to that “Best Possible Medication History”.   It is important to remember that interoperability is not the end of a process but the beginning.  Interoperability allows us to understand what’s being communicated by another system but now how to make the best use of that information.  Having the ability to leverage information that informs and improves our decision making process is the reason terminologies exist. 

Having a platform that provides the right workflow for smart automation of the interoperability process as well as services to support unstructured text processing and clinical summarization is critical to a cost effective medication reconciliation process and the delivery of safe patient care.  Our Symedical product provides all of the tooling and services necessary to establish a framework for next generation medication reconciliation and beyond.
Posted: 7/21/2015 9:02:48 AM by Charlie Harp | with 0 comments

understanding ICD-10-CM - Part III - A Terminology by the Book

When you are trying to implement a terminology in a software application, the intent of the terminology can have a significant impact on how easy or difficult that process will be.  A terminology that was designed for software tends to elegantly support the patterns of use.  This type of terminology, if you are a data nerd like I am, is a delight to work with and makes the life of the integrator much easier.

Unfortunately, ICD-10-CM is not that kind of terminology.  ICD-10-CM is clunky, unstable and requires significant manual intervention to leverage the information in the format provided by CMS.  if you are wondering why this would be the case, you just have to remember that ICD-10-CM is first and foremost… a book. 

To understand a terminology, you need to know its history, purpose and drivers.  When you examine the ICD-10-CM terminology, it is easy to see that it has been, and still is, meant to be a book.  Not the kind of book you want to curl up with and read in a Naugahyde chair by the fireplace.    It is the book you use to find codes and perhaps kill a large spider with when you are not wearing shoes.

You might be asking “Charlie, how can you say it is a book?  What evidence do you have to support this outlandish claim?”  I will back up my claim with irrefutable evidence.

The Evidence

Exhibit A - Loosely coupled and unstable hierarchy

The codes are organized first into chapters, twenty-one to be exact. 

These chapters divide the codes into groupings based on a combination of etiology, body system and code purpose.  These chapters do not have stale identifiers, but are typically correlated to numbers based on the chapter sequence.

Each chapter is divided into sections.

These sections logically group the rubrics (three digit codes) into a code range.  The sections do not have stable identifiers but are typically associated with the code ranges.  For example, in chapter 11, “Diseases of the digestive system,” there is a section called ‘Diseases of appendix’ that covers rubrics from K35 to K38.

In a true terminology, the organizational hierarchy would have stable identifiers that are unambiguously linked to the rubrics.  In this case, the chapters and sections would be classes and subclasses used to organize and navigate the rubrics they contain.

Chapters and sections are artifacts typically found in a…what do you call it?  Oh yeah… a book.

Exhibit B - Alpha Indexes instead of synonyms

ICD-10-CM has three “Alpha Indexes”.  The Alphabetic Index consists of the following parts: the Index of Diseases and Injury, the Index of External Causes of Injury, the Table of Neoplasms and the Table of Drugs and Chemicals.

The idea is that the user goes to the appropriate alpha index and finds the words they are looking for and that listing either directs them to the appropriate code OR redirects them to another word in the alpha index.

For example: 

Let’s say you were looking for the code for “Abdominalgia”…

You would go to the “Index of Diseases and Injury” and run your finger down the list until you find it.  Next to it you would see the following:

See Pain, Abdominal

You would then flip the index to the P’s and run your finger down the list to “Pain, Abdominal” and you would see 16 codes and in that list you find the one you want “Pain, abdominal, rebound” and next to it you see the following:

See Tenderness, abdominal, rebound

So we flip the index again to the T’s and find what we are looking for “Tenderness, abdominal, rebound” and next to it you see eight codes and you pick the basic one: R10.829

The external cause index works in a similar fashion to this.

The drug and neoplasm tables are used to establish lookup grids for pre-coordinated scenarios.
In the Table of Neoplasms, the alpha index items are anatomic locations for each row and each column represents the nature of the neoplasm (Benign, In Situ, Uncertain, Unspecified, Malignant Primary, Malignant Secondary) with additional “manifestation” codes and “see also” codes listed when appropriate.

In the table of Drugs, the alpha index items are the drug formulations for each row and each column represents a drug-related event (Adverse Effect, Underdosing, Intentional Poisoning, Accidental Poisoning, Assault Poisoning and undetermined poisoning) with “see also” codes listed when appropriate.
Alphabetic indexes are something you find in the back of (wait for it) … a book.

Exhibit C - Important relationships and associations conveyed as unstructured text

ICD-10-CM codes have relationships to other codes.  They might be designated as ‘Code Also’, ‘Code Additional’, ‘Code First’, ‘Excludes1 (does not include)’, ‘Excludes2 (Should not be coded with)’ and ‘Includes’ (which is actually more synonyms).  How are these relationships provided?  As wild carded text in the chapter, section or code header associated with the codes in the book.

Here is an example of this from the XML provided by CMS:

E09 - Drug or chemical induced diabetes mellitus

Code First

poisoning due to drug or toxin, if applicable (T36-T65 with fifth or sixth character 1-4 or 6)

Use additional

code for adverse effect, if applicable, to identify drug (T36-T50 with fifth or sixth character 5) code to identify any insulin use (Z79.4)


diabetes mellitus due to underlying condition (E08.-)
gestational diabetes (O24.4-)
neonatal diabetes mellitus (P70.2)
postpancreatectomy diabetes mellitus (E13.-)
postprocedural diabetes mellitus (E13.-)
secondary diabetes mellitus NEC (E13.-)
type 1 diabetes mellitus (E10.-)
type 2 diabetes mellitus (E11.-)

As humans reading a book, we can see the above information and sort out the details.  If ICD-10-CM were meant to be a terminology, this ontological information would be conveyed via concrete relationships between terms.  This would make it easier for the software to assist the human in understanding how the codes should be used together to fulfill their objective.

Terminologies provide relationships as defined links between terms (a structure typically referred to as triples (code->relationship type->code). This makes it easier for the software to consume so that it can provide concrete assistance.

Exhibit D – Um… it’s a BOOK!
Ladies and gentlemen – photographic evidence that the defendant is in fact a book.   This information format being its primary delivery system be it in electronic or hard back form.  The prosecution rests.
(Sorry – watched a Matlock marathon last weekend and got a little carried away…)

What does it all mean?toserveman.jpg

As I said at the beginning of this post, to understand a terminology, its capabilities and limitations, it is always best to understand its origins, code structure and intent.  In the case if ICD-10-CM, the fact that it is designed to be first and foremost a book just means that we need to lower our expectations of its capabilities as a terminology. 

In the case of ICD-10-CM, what this means is that in its “natural” form (for example, if you get the XML from CMS like we do), the content has the following limitations:

1. It is challenging to search for a term – in its natural state, all synonymy is trapped in the indexes.  The indexes are not structured in a way that makes them easy to implement.  This makes ICD-10-CM difficult to integrate into an application unless you do some work to build or license an interface terminology.

2. It is challenging to browse the hierarchy – while the rubric-based hierarchy is logical, it is not provided as an actual hierarchy with relationships.  Also, since the chapters and sections lack stable identifiers, it is up to the implementer to stabilize them and synthesize the implied hierarchy for the chapter, section and rubric.

3. It is challenging to traverse relationships – because the relationships like “code-first,” “code also,”  “excludes,” etc. are not managed as triples, but rather as ranged free text expressions.  There is no practical way to navigate them without human or advanced algorithmic interpretation.

In healthcare, we are still in transition, still evolving away from a model in which humans in back rooms are mapping and coding.  ICD-10-CM is a remnant of that old model.  In the domain of “modern” informatics, the latest and greatest terminology we are being mandated to use is an anachronism, the equivalent to a View-Master in a world full of Virtual Reality headsets.

What can we do about it?

We can finds ways to cope with it.  ICD-10-CM is moving ahead and, despite the issues it represents, I think it is the right decision.  Mostly because as an industry, we have put too much time and money into making it happen. If we don’t do it now, how much credibility will we be able to salvage?  At this point, it is a moral imperative.

The Silver Lining

Sometimes you have to get to a tipping point, a point where you say to yourself, “Wow, that was not a good idea.”  This tipping point forces you to reconsider the direction, perhaps even to question everything.   It is how we gain experience.  I believe that ICD-10-CM is that tipping point for pre-coordinated terminologies in healthcare that could help us to change how we think in the future.

In the meantime, at Clinical Architecture, we have created a version of ICD-10-CM in which we have transformed what we found in the ICD-10-CM XML from CMS into an actual stable ontology.  We provide this at no additional charge to our Symedical clients (along with over 400 other content assets).  We will also be making this available as a flat file data offering in our Content Cloud, which will be available at the end of July.  Feel free to contact us if you would like to learn more.

I am going to take a break from ICD-10-CM for a while.  If you have any question or additional thoughts, please leave them in the comments and I will be happy to share and address them.

Posted: 6/23/2015 11:11:46 AM by Charlie Harp | with 0 comments

Spring 2015 Update

This is a brief intermission from your regularly scheduled blog entries…

I wanted to pop in and share with you an update from our offices in Carmel, Indiana. This is a slight departure from our usual blog content, but we wanted let you know what’s been going on at Clinical Architecture so far this year.


Last month we made the quick drive up to Chicago for HIMSS15 and had a great week giving demos, discussing business, seeing old friends and meeting new people. One of the things we did different this year was to replace our usual gadget raffle with a donation sweepstakes. Each day we had a drawing and the winner received the opportunity to designate a charity to receive a $500 donation. The response to this was amazing and I was the lucky person who got to notify the winners. Not only were they excited they won, they were all truly passionate about giving back and thankful for the opportunity to select a charity to receive the donation. Here are the charities the winners selected:

Our booth at HIMSS15:


New Location

In March, we opened an office in Salt Lake City, Utah. Our Chief Informatics Officer, Shaun Shakib, is holding down the fort at this new location and enjoying a beautiful view of the mountains.

View from the Salt Lake City Office:


New Faces

We are welcoming several new faces to our team this spring. Stephanie Broderick has joining Clinical Architecture as Vice President of Product Management. Stephanie brings over 25 years of product management and software development leadership to Clinical Architecture, with 20 of those years spent creating healthcare IT solutions for First Databank and Medi-Span. We are also adding to our Customer Support and QA groups with several recent graduates from Indiana University and Xavier University. We are always looking for great talent. Let us know if you or someone you know is interested in working with us.

Cool New Products

We are excited to announce we are launching a new product this summer. Keep your eye out for updates about our stand alone content delivery system, which will simplify obtaining and updating the terminology assets you need.

Come and see us!

We are looking forward to HIMSS16 in Las Vegas next year! But before then, you can visit us at this year’s AHIMA show in New Orleans, Louisiana. We will be at the Annual AHIMA Convention September 27th – 30th at booth 551. Stop by and see us if you are attending!

Charlie will continue your regular scheduled blogging with his series about ICD-10 next in the next few weeks.


Amanda O'Rourke, Director of Marketing
Posted: 5/15/2015 6:21:04 AM by Amanda O'Rourke | with 0 comments