Thank you so much for providing such valuable information. The idea of an immutable code sounds great. We’ll definitely explore that and see how best we can come up with a workable solution. I’ll be in touch in case I need your expert opinion if you do not mind.
···
On Fri, Aug 25, 2017 at 8:37 PM, Derek Ritz derek.ritz@gmail.com wrote:
Hi all.
I’d like to wholeheartedly support Jorge’s comment re: IDs. The job of an ID is to be different from all the other IDs. It is a best practice to not include any other information inside the ID itself, but rather to associate these other data with the ID as attributes (that can evolve over time).
I would even take Jorge’s idea of using the country code to define a namespace one step further. There is no downside to using a standards-based GUID as the ID for database purposes; they are easily generated and guaranteed to be unique. Other “shorthand” IDs or codes can be associated with this computer-generated ID and used for human-interaction use cases. The GUID, however, can then be used to support computer-based data sharing workflows and there is no risk of collision… ever. There is a lot to like about that.
I’d also add a note regarding data exchange interfaces. The OpenHIE workflow specification for facility registries references the globally-balloted Care Services Discovery (CSD) profile, which can be found here: http://wiki.ihe.net/index.php/Care_Services_Discovery). There is also a brand new, FHIR-based version of CSD, the mCSD profile… and information about this can be found here: http://wiki.ihe.net/index.php/Mobile_Care_Services_Discovery_(mCSD). Both of these profiles were authored by OpenHIE community members. CSD is fully supported by the both facility registry reference implementation products in the OpenHIE community and these products have both passed certification tests for CSD multiple times.
I hope this is helpful.
Warmest regards,
Derek.
–
You received this message because you are subscribed to a topic in the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/facility-registry/9caXEBOdyUg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
On Fri, Aug 25, 2017 at 1:42 PM, Jorge Queipo jqueipo@usa-ctc.com wrote:
Hello,
Just for point 3:
I think for an “intelligent” coding system can have some problems. For example, including the district code could present problems over time if there is redistricting, for example, and the facility is impacted by that process.
I think that there should be a machine immutable code with a defined name space so that you know that within that name space it is unique and will not change. I say this because if there is any future sharing of the facility list perhaps with other systems that rely on the facility registry, there could be code collisions, but not if the name space is defined. For example, the name space could be one of the ISO country codes defined for Malawi (MW, MWI, 454) and then a machine code. (so smart standard-based name space, non smart identifier)
In the example of the smart code that uses the district prefix, if the facility was impacted you would either have to keep the now incorrect convention in order to not break data exchange contract but would be confusing to users that understand the naming convention or you would change it to reflect the new district and thus have data exchange or other system-to-system impacts.
I believe that there should be an immutable code and this could then be complemented by long and short names (which themselves may change). Would also think that as facilities and attributes of the facility can change over time, it would be of value for the system to be able to track the changes over time (for example the fact that the facility was redistricted and thus had one parent at point in time x and another at point in time y or the facility name changed). Thus a history or log of facility attributes over time with a current flag or other means to identify the latest record.
Regards,
Jorge
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
On Thu, Aug 24, 2017 at 2:51 AM, Kondwani Kuthyola k.kuthyola@gmail.com wrote:
Good day Wendy,
Thank you very much for your assistance, you’re a star. Perhaps I should rephrase one part highlighted in red as it is too vague:
"
- The server specifications(RAM, Hard disk space, Operating system and processor speed) on which the system is running
- The programming language used to code the System.
- How the coding of the facilities was implemented i.e the format used.
Rephrase: We would like to know how you computed your unique identifiers for each health facility. Malawi’s current coding system for a given facility is CP0101, with the first 2 letters representing the name of the district, the next two digits representing the first district in the country and the last two digits representing the first facility within that district. The problem with this coding system is that we will have issues where there are 100 facilities in a district. So we are currently looking at exploring intelligent or non intelligent identifier options available that we could possibly use. Perhaps we could go with the same coding system and looking at how we could integrate the luhn algorithm to the code itself.
- The linkage that is there between this system and other third party systems (interoperability)/ benefits of this Health facility registry.
- The challenges the might have been faced during the development and how they were resolved.
- The database used to manage the facilities
"
Thank you once again for coming back to me.
Kind regards,
Kondwani
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Thu, Aug 24, 2017 at 6:49 AM, Wendy Schultz schultz@instedd.org wrote:
Dear Kondwani,
Scott Teesdale, community manager for the Facility Registry community, currently out on paternity leave passed your message along to our internal team for follow up. Our engineering team is reviewing your questions and will respond via email shortly.
Kind regards,
~wendy
Kondwani Kuthyola
Baobab Health Trust,
P.O. Box 31797,
Lilongwe 3,
Malawi.
+265993741034
–
Wendy L. Schultz-Henry
Chief Operating Officer
Secretary and Treasurer to the Board of Directors
InSTEDD
100 S. Murphy Avenue
Sunnyvale, CA 94086
+1.408.396.9068 mobile
wendy.schultz-henry@ Skype
wschultz @ Twitter
On Tue, Aug 22, 2017 at 9:54 AM, Scott Teesdale steesdale@instedd.org wrote:
FYI…
---------- Forwarded message ----------
From: Kondwani Kuthyola k.kuthyola@gmail.com
Date: Aug 22, 2017, 9:28 AM -0500
To: Facility Registry (OHIE) facility-registry@googlegroups.com
Subject: Master Health Facilities Register
Hi all,
We are in the process of developing a Master Health facility Register system for the Ministry of Health in Malawi. We are currently trying to gather requirements for our system and as such, we’d like to do a comparative analysis of different facilities registers currently implemented in various countries (Tanzania, Nigeria, Kenya, Ethiopia, Philippines, e.t.c.) globally. Thus, we seek your assistance on how we could gather the information below as it has proven to be a stumbling block in requirements gathering process:
Wherever possible, we’d like to know:
- The server specifications(RAM, Hard disk space, Operating system and processor speed) on which the system is running
- The programming language used to code the System
- How the coding of the facilities was implemented i.e the format used.
- The linkage that is there between this system and other third party systems / benefits of this Health facility registry
- The challenges the might have been faced during the development and how they were resolved.
Your assistance in this regard will be highly appreciated.
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Kondwani Kuthyola
Baobab Health Trust,
P.O. Box 31797,
Lilongwe 3,
Malawi.
+265993741034