So one of the things that has come up in our on-going efforts to implement the FHIR module for OpenMRS is how we deal with the ContactPoints FHIR data type. ContactPoints in FHIR represent a means of contacting an individual, for example, a phone, fax, email, pager, etc. In OpenMRS, we think these data are usually stored as Attributes (PersonAttributes, LocationAttributes, ProviderAttributes). That’s all well and good. The problem is in determining the relative priority of the different values (what FHIR calls their “rank”). I.e., if a person has multiple phone numbers, which phone number should we prefer using?
There are two ways to address this that we’ve come up with (thanks to @corneliouzbett and @jecihjoy):
Add a preferred flag to the appropriate *Attribute classes, similar to what is done for PersonName, PersonIdentifier, etc. Alternatively, we could add a “ranking” value similar to the rank in the FHIR data model.
Setup a different *AttributeType to indicate preferred phone number, etc.
The first of these involves making a change to the platform data model, but is otherwise relatively clean. The second of these does not involve changes to the core data model but may involve changes to implementations to, e.g., implement a “Preferred Phone Number” PersonAttributeType.
We thought it would be best to reach out to the OpenMRS community to see if there were any options we hadn’t considered or any preferences one way or the other.
The reason why i do not like adding a preferred field to person attribute types is, unlike PersonName, PersonAddress, or PatientIdentifier, which are a specific type or category of something, person attribute types are too generic that there are many uses of them where the preferred flag does not apply.
I have been thinking of the best way to map ContactPoint to Openmrs. My vision is to have a Person or Location or Provider contact details represented in Fhir as follows:
Using the above as an example been extracted from a person resource, the person has three contact points 2 phone numbers and 1 email address. ContactPoint with rank 1 is the preferred phone number since rank specify preferred order of use (1 being the highest). the system is mapped to fhir value-set ( http://hl7.org/fhir/ValueSet/contact-point-system)
How to achieve this, isn’t straight forward. First, you need to create a person attribute type for PHONE and EMAIL, then you can insert value to the person attribute with person attribute type phone, with this you can’t have multiple values for phone numbers.
So the only way I could think of for having multiple phone numbers is to append rank at the end when creating attribute type i.e PHONE-1, PHONE-2 - meaning the person attribute value with PersonAttributeType PHONE-2 is the preferred phone number for that person. It might work but it’s not the right way. It’s hackish, can’t imagine how the code will look like.
On the second thought PersonAttributeType table has column format and foreign_key.
So what if I create a new table contact_points (FHIR2 module specific). Then add as a new person attribute type with format (org.openmrs.ContactPoint).
But PersonContactPoint will be specific to the person only, what of Location and Provider does it mean you will have another object ProviderContactPoint e.t.c
Yes it would be specific to the person. Just like we have PersonAttribute, LocationAttribute, and ProviderAttribute, where each is specific to person, location, and provider.
We could easily make those all descend from an abstract ContactPoint class, but if we’re going to have a semantic linkage to the right “owner” than we do need one type that belongs to Person, one type that belongs to location, etc.
Hi @dkayiwa@ibacher@corneliouzbett how did you conclude on the idea of having multiple phone number for a patient? Currently it appears the GP for FhirConstants.PERSON_CONTACT_POINT_ATTRIBUTE_TYPE allows only one UUID for a contact. Could it be expanded to include an array of uuids to map to the telecom object of fhir otherwise how do I achieve this? cc @mozzy
I actually don’t know that just supporting comma-separated values is the right idea. If the goal is just to represent multiple phone numbers, you just need the one attribute type. If the goal is to represent more than that (e.g., preference order, potentially different types of contact types) than we actually need more information than just a list of UUIDs. Otherwise, we’ll have no way of preserving the semantic meaning (“secondary phone number”, “email address”).
It would be better if we could encode that via the attribute type and maybe some FHIR2 module metadata class that maps an attribute type to a FHIR representation… somehow.
Right. The real question, I think, isn’t where we make the change but how we capture that secondary information, i.e., “this attribute represents a mobile phone”.
We need some way of configuring:
Whether an attribute maps to a contact point
How the attribute gets represented as a contact point
We’ve used mapping tables in the FHIR2 module for various purposes and maybe there’s a way we can leverage that here?