Clinical Architecture Blog

The Road to Precision Medicine

The term “Precision Medicine” has been in the news of late. For those of you who missed it, here is a blurb from the website:

“Precision medicine is an emerging approach to promoting health and treating disease that takes into account individual differences in people’s genes, environments, and lifestyles, making it possible to design highly effective, targeted treatments for cancer and other diseases.”

For many of us who have been in this industry for years, the idea of individualized medicine is not an epiphany. It is the promise of any electronic medical record and a vision that could not be realized without the help of computers and software, as the amount of information and orchestration would not be possible for a human care provider alone. We have been building software systems in healthcare for decades trying to harness the power of technology to improve how we care for patients and yet the dream of individualized care has eluded us.

So the question is, what has been stopping us? The answer is not a simple one.

On one hand, computers and software have been leveraged in healthcare in several significant ways. Computers allow for smart pumps, MRIs and other amazing diagnostic and monitoring tools. They allow us to move information around, store it in a digital format for quick retrieval and analysis; to some degree, over various populations. But all of these things still require a human operator to use them in a trusted way. In other words, they are “tools” that we can use like a hammer to drive a nail. How does a tool become something more than a tool you might ask? Consider an anachronistic little tool some of us used to use quite a bit, the paper map.

PaperMap-(1).pngUsing a paper map is a good metaphor for healthcare. It is difficult to use a map and drive at the same time, dangerous in fact. Maps need to be understood and you have to figure out the shortest way and guess where the traffic might be good or bad. At some point in our recent history we replaced the paper map with something that does all of this for us, a personal global position system or GPS. We tell the GPS where we want to go and the GPS tells us when to turn, routes us around traffic and knows exactly when we will get there. Every now and then there is a road block or we forget to update our maps and we have to take over, but by and large we rely on this technology to guide us while we drive the car.
Any early adopter that bought a GPS when they were “new” has stories of GPS misadventures. When you
gps.pngwere trying to find a Starbucks and ended up at a person’s house in a residential neighborhood. (I thought about ringing the doorbell and demanding a Caramel Macchiato…). Or you are late for a meeting because the GPS took you to an address 45 minutes in the wrong direction. But for each misadventure there were hundreds of successes and today the GPS (whether a standalone device or an app on our smart phone) is, barring operator malfunction or poor reception, nearly infallible. As a result we have grown to trust the GPS. Trust that it knows what’s going on and will provide us with guidance that will drive (pun intended) us toward our desired outcome.

What will it take to build software that healthcare providers can rely on in a similar manner?

It will require that we create a software ecosystem that delivers highly relevant clinical and administrative guidance that can be trusted by human providers. Like GPS, this ecosystem should support care delivery, not seize control, so providers are still in the driver’s seat.

For a software application to earn this level of trust, it will need to be a true clinical application. The goal of this series of posts is to describe the characteristics of a true clinical application and discuss what it will take to move our industry into the future.

When we started Clinical Architecture over seven years ago, we chose the name of the company based on our belief that the healthcare industry needed someone that was dedicated to establishing foundational components for healthcare, a “clinical architecture” for others who share our vision to leverage. Our product Symedical, which was designed to allow software systems to “understand” information they acquire, host, share and exchange, regardless of the format or terminology, was a fundamental first step in this process. And, there is more where that came from. We are committed to be a catalyst for change and, like any catalyst, we are aware that we cannot do it alone.

The first step towards getting somewhere is to decide that you are not going to stay where you are.

In the next few weeks, as I share these thoughts, I ask you to let me know what you think.
Posted: 1/26/2015 10:24:45 PM by Charlie Harp | with 0 comments

Clinical Architecture and Apelon - Collaborating to Evolve and Enhance your Terminology Ecosystem

There was a press release issued today announcing our new agreement with Apelon.  Apelon has amazing, knowledgable and trusted resources that have been serviing this industry for decades.  Clinical Architecture has the most innovative and comprehensive terminology tooling in the market today.  We felt that by working together we could accomplish great things for our mutual clients and the industry in general.  I am very excited to have the opportunity to work with the Apelon team and honored that they thought enough of our Symedical product to collaborate with us at this level.  

Please stop by either booth at HIMSS (Apelon #5055, CA #1077) to ask us about it and score a commemorative chocolate bar.

Posted: 2/20/2014 9:18:03 AM by Charlie Harp | with 1 comments

Symedical for the iPad is now available in the iTunes app store!

I am extremely pleased to announce that Clinical Architecture has just released Symedical Mobile Map Manager (SM3) for iPad and iPad Mini.


This application allows a clinical map administrator to connect to one or many Symedical servers and monitor and manage exceptions, work on mapping tasks or review submitted maps and publish them to the mapping run time.
Our goal was to create a convenient, intuitive, and highly functional application that allows the resources that are responsible for managing the mapping to do so quickly and from anywhere they can connect their iPad to the web.  

Here are a few screen shots:
Server configuration and selection

Map Asignments and Quick approval

Term Mapping console

The SM3 App is free, but requires access to a Symedical server running the most recent version (1.5.1) with the Mobile Administration option enabled (and you must be at least 4 years old).   If you would like a demo or to try it out, contact our sales department and we can make it happen.  

We will also be showing it off at HIMSS, so feel free to stop by and see what it's like to have the power of interoperability in the palm of your hand.
Posted: 2/7/2014 11:50:45 AM by Charlie Harp | with 0 comments

Clinical Architecture at HIMSS in Orlando

Clinical Architecture will have a booth at the 2014 HIMSS conference in Orlando February 22-27th.

We will be camped out in booth # 1077 and would love to meet with you.

Please visit our HIMSS Meeting request page to schedule a face to face and learn how you could:
  • Simplify how you obtain and update standard terminologies, ontologies and maps.
  • Distribute, manage, localize and monitor terminology across your entire user base with relative ease.
  • Free your developers from the hamster wheel of terminology by integrating our powerful runtime APIs.
  • Realize the value of true clinical interoperability with Symedical’s semi-automated mapping and normalization pipelines.
  • Take advantage of unstructured data in ways you never thought possible with Symedical’s new SIFT engine.
  • Use the Symedical Mobile Map Manager for iPad to reduce the latency and increase the fidelity of your clinical interoperability.
We are looking forward to seeing you in Orlando!


Posted: 2/3/2014 3:10:12 PM by Charlie Harp | with 0 comments

Fit for Purpose - by Shaun Shakib, PhD

A mentor of mine once used the expression “Fit-For-Purpose” and I believe it captures an important and practical principle for orienting a discussion around the use of clinical terminology.  Controlled clinical terminology is a means, not an end and it is too easy to become obsessed with the systems, artifacts, and science around terminology and forget the many valuable reasons and objectives for implementing it.  Your objectives must drive your approach to the creation, management and implementation of terminology.  This discussion is not a comprehensive list of considerations, rather it provides examples of things you should think about when implementing and utilizing terminology.

Here are some use scenarios defined in the Lexical Query Services specification that capture the types of things you might want to do with terminology:

  1. Mediation - Using terminology to transform/translate messages or data records from one form or representation into another. (data exchange)
  2. Normalization – Eliminating redundant and invalid content by unifying the multiple codes and terms used to describe concepts into a single, concept-based terminology. (analytics and decision support)
  3. Standardization - translating local codes to standards for the purpose of information exchange. (data exchange and regulatory requirements)
  4. Information Acquisition - Using terminology to aid in the process of entering coded data (pick-lists, structured documentation).
  5. Information Display - Using terminology to translate coded data elements into human or machine-readable external forms.
  6. Indexing and Inference - Using terminology to inquire about associations which may or may not pertain between various concepts.

Once you know what you want to do with terminology it is important to consider the lifecycle of the content and the interaction it has with your systems.   These considerations will drive decisions regarding the architecture of your terminology environment and your strategy for integrating (mapping) and structuring internal and external/third party content.

Considerations such as:

  1. Can you use a standard terminology directly or do you require a layer of abstraction to insulate from potential semantic shift or drift in the standard?
  2. Will you have a need to author new content?
  3. What standard terminologies do you require?
  4. How does your use of terminology fit into your organizations overall data governance strategy?

Answering these types of questions will help ensure that you don’t spend a lot of time, money, and effort building something you can’t use or something that requires an unnecessarily large team of individuals to maintain and enhance.

Here are some basic capabilities you should look for in your terminology management environment:

  1. Obtaining and updating content – process and tools for acquiring, transforming, and loading both initial and ongoing updates of terminology content
  2. Content distribution – delivering content to other vocabulary servers or applications
  3. Batch and computer assisted Term Mapping – integration of local terminologies and standards
  4. Browsing, authoring, subsetting and extending content
  5. Deploying content to a runtime environment
  6. Monitoring the performance of the content in runtime
  7. Versioning capability

Implementing capabilities such as these requires resources that are supported by tooling and processes.  It is important to note that the degree to which these capabilities are automated (how good your tools and processes are) will have significant impact on the resources needed to implement and maintain content and the quality/consistency of the work product.  Investments in this solution (total cost of ownership) will come in the form of time (content creation, management, mapping and maintenance) and money (content and software licensing).
Finally, since the architecture you put in place and content you create will be foundational, it is important to address current needs effectively while allowing for future enhancements and growth.  This means that the ideal “Fit-For-Purpose” solution must also be flexible and extensible.  It must scale with your future needs.
These are just some of things to consider, the key message is don’t let the tail wag the dog.  Let your purpose drive your approach to clinical terminology.

Posted: 9/2/2013 2:21:10 PM by Shaun Shakib, PhD | with 0 comments