First FHIR / OMRS use case

@surangak created a Building FHIR Support wiki page for the project and started some conversation on the dev list. I thought we might be better served to bring the conversation to our forum.

Use case

How to export a patient’s observations list using FHIR

In the OMRS data model, observations are typically grouped together as OpenMRS encounters and encounters can be grouped as visits. We think that the proper way to represent this would be via the FHIR Composition resource (which is listed as a type of infrastructure resource) .

Proposed Approach

  • Client makes a request to the OMRS FHIR module for all Patients with name = Bob.
  • OMRS FHIR responds with a bundle of FHIR Patients with name = Bob.
  • Client selects the correct Bob and request all of Bob’s Compositions (encounters).
  • OMRS FHIR responds with a bundle of FHIR Compositions.
  • Client selects a single composition (encounter) and requests all of the Observations for that encounter.
  • OMRS FHIR responds with a bundle of Observations for that encounter.
  • Client find CD4 Count and displays it.

An OpenMRS Encounter represents a clinical transaction at a point in time comprised of observations, orders, (eventually) notes, and (eventually) miscellaneous form data. An OpenMRS Visit can group one or more encounters into a clinic visit or hospitalization and has start & stop timestamps. The FHIR Encounter aligns very closely with OpenMRS Visit. The OpenMRS Encounter appears to align more closely with FHIR Composition.

Given this, what would be the best way to model an OpenMRS Encounter using FHIR resources?

If a FHIR Composition is the corresponding resource for the OpenMRS Encounter, what is the best approach to record the OpenMRS Encounter Type? Would it be FHIR Composition Class or a FHIR Composition Type?


Wouldn’t a better first scenario to be to expose data via one of the well-defined FHIR resources, e.g. implement Condition and have this expose the diagnoses captured via the reference application’s Visit Note (and represented in the EMR API module)?

I have added an architecture diagram to the Wiki page. I am not yet allowed to post images here.
@Burke, I don’t think composition is right either as class or type. Composition is clearly targeted at CDA documents, take a look at the limitations on codes.

@darius, the more I read about your ideas on semantic representation, the more I like it. And I think that we should seriously consider using or replicating your design for our work.

@r_friedman, I think that there are a lot of parallels between the design that I proposed, and what you’ve shared. The main difference I feel is that i’m trying to be lazy, and re-using some of the components from the FHIR reference application that Grahame built :smile: So basically, the components that you included in your drawing are in mine as well, only that it’s part of the reference application. Hmm… I agree that XSD is important, just not sure if its a achievable scope for phase one. I guess that is a discussion for later. But more importantly, i’d like to ask about the ‘vocab code lists’ components included in the pre-processor. Whats the specific task that this component is to accomplish ? is it to map non-loinc dictionaries to lOINC / SNOMED codes ?


Building Java objects from XSDs and pre-defined objects is what lets us update/extend by regenerating rather than editing. It’s also what lets module builders map their objects to FHIR objects. I have no object to using parts of Grahame’s app so long as it’s written in Java; from looking at the presentation, I fear it might be in C#.

It seems to me that there will be cases where an OMRS object matches up pretty well with a FHIR object but has some additional data that would come in via an extension. Also, I see OMRS xAttributes coming in via an extension.

I see various local OMRS code lists, such as encounter type, visit type, concept type, concept class, that may need representation on the FHIR side. Also lists of possible answers, like concept sets, may need to represented on the FHIR side.

Obs groups will need profiles to associate their related parts (see the blood pressure illustration).

If people have to generate all these FHIR objects manually, it will be an on-going source of errors.


I’d like to take a step back and discuss implementation use cases.

What @darius suggested seems very interesting because it has a direct relationship to the EMR API module in terms of semantic information.

An alternative would be the observation resource, which I foresee may be more widely used. For example, it could be specialized to report a wide range of information such as,

a) Vital signs: temperature, blood pressure, respiration rate
b) Laboratory Data and other Diagnostic Measures  Measurements emitted by Devices        
c) Clinical assessments such as APGAR 
d) Personal characteristics: height, weight, eye-color  Diagnoses (Note: trackable conditions, allergies, adverse reactions and more complex structures are handled elsewhere)      
e) Social history: tobacco use ; family supports ; cognitive status 
f) Core characteristics: pregnancy status, death assertion


The negative of this is that a) its a larger use case and b) will require work to the EMR API module, but on the other hand, it’ll be more widely used ?

@SurangaK – I’m not sure what you are trying to do. Some if not all of a)-f) are existing profiles. Are you trying to implement profiles using concepts from the concept directory? Or are you simply indicating the sorts of observations that we should support? Are you saying that we should be prescriptive about the content of the profiles? Or that the profiles are an example arising from the PIH system? Or that we should provide base profiles and let users modify them via extensions? I don’t have any firm views on the approach. I do have some doubts about the profiles. The profiles are entirely clinical, and we have to be able to gather M&E and public health indicator information during exam/treatment. So I would like to allow for the possibility of extending the profiles relating to clinical exams to include data elements for M&E and public health purposes such as the questions/answers I put on the dev list.
Suranga, I don’t know how you handled CDA, whether you used a fixed content like you did in HL7 or whether the content can be changed by scripting. Are you proposing any sort of ability to modify that profile? Is that ability through writing FHIR extensions or otherwise? I don’t know what you mean by “specializing” the observation resource. Do you mean specializing like with specifying codesets or by representing obs groups? @Darius, maybe you could help by saying in more detail what you mean. Are you trying to represent the content of particular screens or something larger including a note or what?

@r_friedman, my main point is that, though I wasn’t on the design call, I don’t think that this is the right first use case:

It’s too general, and OpenMRS-data-model-centric. Instead I think we should take a FHIR-centric approach and pick one of the resources listed under General at Of these, my opinions are:

  • AdverseReaction -> possible, I guess people represent this as obs, but not technically interesting
  • AllergyIntolerance -> this is in the data model since 1.7, but hardly used, so I prefer to wait on this until we’ve implemented allergies in the reference application
  • CarePlan -> I doubt that many OpenMRS implementations structure this well, so it’s a bad first example
  • Condition -> I like this because the reference application captures this and so do many existing implementations. Technically we might need to figure out how to combine encounter diagnosis obs groups (in the refapp style), with AMPATH2005-inspired Problem Added/Problem Removed obs, with the 1.7-era problem list
  • FamilyHistory -> Like AllergyIntolerance, we could pick this, and I guess it would be straightforward, but not that interesting.
  • Procedure -> Doable but not interesting.
  • Questionnaire -> I don’t like picking this because it seems like the catch-all resource to show you all data that isn’t covered by the specific ones above.

I see a side benefits to us if we don’t just approach FHIR as a data exchange format, but if we leverage it’s opinionated view of what meaningful medical concepts are, and find ways to standardize our views of these.

E.g. I think it would be wonderful if we have the ability to ask OpenMRS “what diagnoses were made for this patient” and it can answer intelligently regardless of whether the implementation uses the “visit diagnoses” CIEL concept like the refapp, or it uses the Problem Added/Problem Removed approach promulgated by the Infopath module.

@darius, if anything, you’ve convinced me that we were seeking to address a use case that is too generic. I was going to vote for Observation resource because it could be used for SO MANY things, but reading your explanation on why you were proposing other resources teaches me otherwise.

One major concern that I do have is that if we are to use the EMR API (which is great design, I fully agree) we will by tying FHIR to OMRS 2.0. Is that something that we’d want to do at this stage ?

PS: Could you please explain more about your statement?

@surangak, I mean that FHIR lets us ask “what diagnoses were made for this patient?”. To answer that question generically across 100% of OpenMRS implementation is impossible, but too often we let that stop us from doing worthwhile things.

In this case, 99% of implementations probably record this data in two specific ways.

  1. The most common way of modeling data is for a diagnosis to be represented as the answer to the Problem Added concept. This was first done by AMPATH in the very first OpenMRS installation in 2005, and copied by many.
  2. The up and coming better-practice way of modeling data is for a diagnosis to be represented as an obs group with the Visit Diagnoses concept. This is what’s done in the Reference Application

So, we can solve this problem in the 99% case, and we can take this opportunity to demonstrate a good-practice way of not letting “implementations may have done an infinite number of things” paralyze us.

Technically, I could see this module being aware_of the emrapi module (but not have a hard requirement), and depending on some configuration setting either it draws diagnoses from emrapi, or else it does some queries specific to the Problem Added approach.

Hi, For Bangladesh HIE, we are using FHIR. Its still early days, but we are trying to POST encounters by using a specific FHIR bundle. And we follow about the same approach. We have a bundle with “Composition” as header, having sections for Encounter, condition (diagnosis), etc etc. We are essentially trying to use Grahame Grieve’s reference implementation as FHIR model and using JSON. We have also taken a whole lot of cue from David Hay’ blogs.

Specifically for Bangladesh HIE, you can find more info here:

Regarding, Encounter type: We should keep in mind that an OpenMRS Encounter may not be bound to a Visit at all. FHIR Encounter is mostly used for administrative information. We tend to use Encounter.class as OpenMRS’ Visit type, and Encounter.type as OpenMRS’ Encounter Type. For Encounter.type, we intend to define a known valueSet in our terminology Server.

1 Like

@angshuonline, I’m not sure if you are familiar with the term “mind blown”, but that’s what I am right now. So Bangladesh is using OpenHIE, and has built / is building FHIR support to post data into the SHR ? that’s what I inferred by looking at that link you sent me. Is this the same project that Hannan Khan and Fatema are involved with ? that sounds amazing !!!

@surangak, BHIE has same architecture (in terms of components) as OpenHIE, however, we are not using OpenSHR or OpenHIM. Client side (Facility) side we are using OpenMRS and/or Bahmni (built on top of OpenMRS). Unlike Rwanda, Bangladesh is not targeting a specific program like Antenatal/PostNatal care as such, so the contracts are much more generic. In future, we might support additional profiles like IHE (with CDA), but right now focus is on building a FHIR based contract. We are still in our early days and so far, we sync only Diagnosis (ICD10) and incrementally building other observations (Chief complaints, symptoms, vitals, etc etc).

Hi there,

@darius, so to clarify my understanding, when you say “so, we can solve this problem in the 99% case, and we can take this opportunity to demonstrate a good-practice way of not letting ‘implementations may have done an infinite number of things’ paralyze us

You’re basically saying that having a FHIR module that uses the two aforementioned approaches to record diagnosis will encourage implementers to also use these, instead of creating their own, correct ?