Use of FHIR encounter$everything to represent OpenMRS encounters [spoiler alert: contains actual samples]

[Suranga Kasthurirathne]

Hi everyone,

This week we developed support for the FHIR $everything operation for encounters. Basically, this returns a bundle of FHIR objects that together, represent the collection of data resources that represent an OpenMRS Encounter.

The request for all data associated with an OpenMRS is

GET /Encounter/{uuid}/$everything

Assume that I want to export an OpenMRS encounter with two observations and a provider.

This is what the FHIR encounter$everything operation for this request looks like

http://pastebin.com/j0kdyNPV

We've already discovered some fixes to this - especially the removal of the profiles/vitalsigns url in the Observation resource.

Please feel free to take a look, throw stones and ask questions :-)

--

Best Regards,

Suranga

[Suranga Kasthurirathne]

Hi everyone,

A quick update on what we're working on right now -

1) There was a problem in how we represented concept maps in the observation resource.
As you know, the OpenMRS data model stores the following data on each concept map -

name : (etc.) height
Source: (etc.) LOINC
code: (etc.) 8302-2

Problems:
1) LOINC, CIEL, SNOMED mappings may sometimes lack names. For example, consider: http://demo.openmrs.org/openmrs/dictionary/concept.htm?conceptId=5090. As you can see, these mappings do not have names assigned.

In such a case, we currently use concept maps' uuid instead of the 'name'. Should we do this, or else simply not include the FHIR name parameter where OpenMRS lacks this info?

2) FHIR resource mapping includes a system url for each concept mapping type. For example, for a concept mapping of LOINC, the defined system url is http://loinc.org. LOINC, SNOMED and CIEL have such mappings, which are stored as constants. However, many OpenMRS concept sources don't have such url's defined. Since we can't report these as simply UNDEFINED (its against the FHIR spec) can we use global properties for users to define these instead?

3) Also, we seem to have used an extension to map an extension to an encounter. We will be getting rid of this, and using the encounter field instead.

--

Best Regards,

Suranga

[Grahame Grieve]

hi Suranga

name : (etc.) height
Source: (etc.) LOINC
code: (etc.) 8302-2

Problems:
1) LOINC, CIEL, SNOMED mappings may sometimes lack names. For example, consider: http://demo.openmrs.org/openmrs/dictionary/concept.htm?conceptId=5090. As you can see, these mappings do not have names assigned.

In such a case, we currently use concept maps' uuid instead of the 'name'. Should we do this, or else simply not include the FHIR name parameter where OpenMRS lacks this info?

This is observation.name name? (now known as 'code')

Put whatever you have. 

2) FHIR resource mapping includes a system url for each concept mapping type. For example, for a concept mapping of LOINC, the defined system url is http://loinc.org. LOINC, SNOMED and CIEL have such mappings, which are stored as constants. However, many OpenMRS concept sources don't have such url's defined. Since we can't report these as simply UNDEFINED (its against the FHIR spec) can we use global properties for users to define these instead?

put nothing if you can't work it out. CIEL should identify the source for everything, and the code populates it if it's there, otherwise leave it blank

3) Also, we seem to have used an extension to map an extension to an encounter. We will be getting rid of this, and using the encounter field instead.

great. FHIR is a moving target, but mostly we move to *better*

Grahame

[Suranga Kasthurirathne]

Hi everyone,

We (or more truthfully, Harsha) worked on a number of improvements to the previous version of the encounter$everything operation.

You can find the updated bundle here.

1) Note the WONDERFUL new system value url's for concept mappings! as you can see, this observation has eight different concept mappings.

2) We've also upgraded to using observation.encounter instead of observation.extension for linking to encounters.

Question for the OpenMRS experts:

1) In OpenMRS, each Observation has a specific Location assigned.. which is why we have a location extension in the FHIR Observation resource to specify this. Under practical circumstances, will the location specified per Observation change from the location specified per the Encounter that it belongs to? Is there value is specifically listing a Location per each Observation?

If we don't need to include locations per Observation, we don't need to worry about the <extension url=..." which still says "http://resources.openmrs.org/doc/fhir/profiles/vitalsigns.xml#location" :-(

--
OpenMRS Developers: http://om.rs/dev
Post: d...@openmrs.org | Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions: http://om.rs/id
 
*** ALERT! This group will be moved to OpenMRS Talk effective 10 April 2015 at 19:00 UTC. Please visit https://talk.openmrs.org/t/openmrs-developers-group-changes-2015-04-10/1508 for details and to make necessary changes.

To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@openmrs.org.

--

Best Regards,

Suranga

[Darius Jazayeri]

In my experience, having obs.location != obs.encounter.location is a <1% use case. But I'm sure there's some random scenario where it's important.

Can you suppress exporting that value + extension except when it differs from the encounter location?

-Darius

[Burke Mamlin]

We've had obs.location forever (in fact, it used to be required), but I'm not not sure why it's there.  I searched my old emails for a hint; no luck.  I may have overlooked it, but I didn't see location in HL7v2 OBX or OBR... nor in FHIR's Observation resource.

I'd second Darius, but guessing obs.location != obs.encounter.location is <0.0001% and less sure there's some random scenario where it's important. :-)

How about just not implementing obs.location in FHIR, assuming it will eventually be deprecated within OpenMRS?  When we introduce the ability to track technical transactions of obs, it will  become more obsolete.

Regarding concept mappings, I would expect "display" to be something human readable, not a UUID.  If you were to include UUIDs, which could be useful to clients, OpenMRS-specific UUIDs would make more sense, IMHO, as an extension on the code.  If you don't have a human readable display value for a reference term (i.e., name is blank), then omit the display value in the FHIR resource.

Cheers,

-Burke

[Harsha Kumara]

@Burke, +1 for avoid using location within FHIR Observation and let client to use location in Encounter resource. As Darius mentioned we also can include location as extension in Observation if and only if it's differ from Encounter. But if we going to depreciate Location within OpenMRS, we no need to do this either.

Regarding concept mappings why concept mappings not associate with a name most of the time[1]? For example if we take concept mappings of LOINC code, it's always better to include the name and code together. @Burke I agree that we should include readable value for display as it's meant to include more readable term which is concept name. 

[1] - http://qa01.openmrs.org:8080/openmrs/dictionary/concept.htm?conceptId=5088

Thanks,

Harsha

Harsha Kumara

Software Engineer

WSO2 Inc.

Sri Lanka.

[Suranga Kasthurirathne]

Thanks everyone,

Agree what was discussed about obs.location, so we can go ahead and remove it from the FHIR Observation resource.

And yes, many of the concept mappings we were looking at don't seem to have names. Maybe @Andy can comment on this?

Harsha, are you suggesting something like "conceptmappingname:uuid" for concept mapping name?

PS: My My, it seems that we're on the brink of starting to modify the OpenMRS API to match the FHIR API ;-)

[Harsha Kumara]

Hey Suranga,

If you look at [1], it has some mapping names also. But mapping names for some mappings are not there. It's better the mapping name also associate with relevant concept name of each concept source which is associate with concept dictionary concept. 

[1] - http://qa01.openmrs.org:8080/openmrs/dictionary/concept.htm?conceptId=5090

Thanks,

Harsha

[Burke Mamlin]

Include name iff it is populated.  Also, don't forget to include the local code (i.e., the UUID of the concept on the server itself).  For example:

"code": {

  "coding": [

    {

      "system": "http://qa01.openmrs.org:8080/openmrs/",

      "code": "5090AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA",

      "display": "Height (cm)"

    },

    {

      "system": "http://snomed.info/sct",

      "code": "50373000",

      "display": "Body Height"

    },

    {

      "system": "http://loinc.org",

      "code": "8302-2",

    }

  ]

}

-Burke