Hi Abyot,
Do you have any plan for Patient Identifier Management functions ?
Is it ok if i work on this ?
Regards,
···
–
Viet Nguyen
It would be great if the Chief complainer for silly Names for Things could provide a small piece of advice on this matter…
···
On Mon, Feb 1, 2010 at 11:09 AM, Viet Nguyen phamquocviet@gmail.com wrote:
Hi Abyot,
Do you have any plan for Patient Identifier Management functions ?
Is it ok if i work on this ?
Absolutely ! You can work on any part of the system.
···
On Mon, Feb 1, 2010 at 11:09 AM, Viet Nguyen phamquocviet@gmail.com wrote:
Hi Abyot,
Do you have any plan for Patient Identifier Management functions ?
Is it ok if i work on this ?
Regards,
–
Viet Nguyen
you are taking about me? What silly names do we have in mind?
···
2010/2/1 Lars Helge Øverland larshelge@gmail.com
On Mon, Feb 1, 2010 at 11:09 AM, Viet Nguyen phamquocviet@gmail.com wrote:
Hi Abyot,
Do you have any plan for Patient Identifier Management functions ?
Is it ok if i work on this ?
It would be great if the Chief complainer for silly Names for Things could provide a small piece of advice on this matter…
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Yes. Just kidding, no silly names this time.
We are going to implement system generated patient identifiers for the patient module.
VN team has suggested:
-
Set of characters dependent on the organisation unit
-
Set of digits, include date and number of patients in the day.
Viet has suggested an algorithm dependent on patient information and the time of creation.
Jason has suggested an UUID.
···
2010/2/1 Bob Jolliffe bobjolliffe@gmail.com
you are taking about me? What silly names do we have in mind?
you are taking about me? What silly names do we have in mind?
Yes. Just kidding, no silly names this time.
Oh well. I guess we can always try silly indentifiers instead 
We are going to implement system generated patient identifiers for the patient module.
VN team has suggested:
- Set of characters dependent on the organisation unit
- Set of digits, include date and number of patients in the day.
Viet has suggested an algorithm dependent on patient information and the time of creation.
Jason has suggested an UUID.
I think identifier for a person and identifier for a person’s file are subtley different. Patients may already have a number of personal state-issued identifiers (hence the flexible identifier type). Many of these might well provide the quality of uniqueness but not necessarily the anonymity you would look for when for example tracking lab samples. But it seems what you are looking at is the generation of a file number for the patient. Like would be written on top of the cardboard folder in “real life”. In which case I would be tempted to follow the simplicity of the VN team suggestion. Of course patients can migrate between org units which needs to be taken into account. If privacy is more of a concern then this information can instead be hashed, probably along similar lines to Viet’s algorithm.
A few things to consider:
-
there should be a check digit built in to the identifier
-
regular expression validation can be useful
-
if the identifier is meant to be human readable (and writable) as well as machine readable then you don’t want to go much over 8 characters
-
before designing an identifier we should be very clear what the identifier should be used for. There are lots of examples of “scope creep” where identifiers primarily designed for social security, tax, national identification etc are “repurposed” as health identifiers. Often they do not have the required characteristics for this. So maybe that’s the starting point - what exactly can we say this identifier is to be used for and not used for.
The openmrs guys have some experience of issuing patient identifiers (and printed barcodes) in Kenya. We should look at what they have done. I have no idea if what they do represent s best practice or not but they do have concrete experience to share.
A couple of broader references:
A discussion on the use of SSN which also contains some useful criteria to frame thinking about identifier design: http://epic.org/privacy/medical/hhs-id-798.html
A report commisioned in Ireland which specifically addresses the problem of re-purposing: http://www.hiqa.ie/media/pdfs/Unique_Health_Identifier_Report.pdf
That’s all the thoughts I can muster for now.
Cheers
Bob
Hi Viet,
what are your thoughts on this? Is the identifier meant to be human readable? What is the main purpose of the identifier?
Lars
···
2010/2/1 Bob Jolliffe bobjolliffe@gmail.com
2010/2/1 Lars Helge Øverland larshelge@gmail.com
2010/2/1 Bob Jolliffe bobjolliffe@gmail.com
you are taking about me? What silly names do we have in mind?
Yes. Just kidding, no silly names this time.
Oh well. I guess we can always try silly indentifiers instead
We are going to implement system generated patient identifiers for the patient module.
VN team has suggested:
- Set of characters dependent on the organisation unit
- Set of digits, include date and number of patients in the day.
Viet has suggested an algorithm dependent on patient information and the time of creation.
Jason has suggested an UUID.
I think identifier for a person and identifier for a person’s file are subtley different. Patients may already have a number of personal state-issued identifiers (hence the flexible identifier type). Many of these might well provide the quality of uniqueness but not necessarily the anonymity you would look for when for example tracking lab samples. But it seems what you are looking at is the generation of a file number for the patient. Like would be written on top of the cardboard folder in “real life”. In which case I would be tempted to follow the simplicity of the VN team suggestion. Of course patients can migrate between org units which needs to be taken into account. If privacy is more of a concern then this information can instead be hashed, probably along similar lines to Viet’s algorithm.
A few things to consider:
there should be a check digit built in to the identifier
regular expression validation can be useful
if the identifier is meant to be human readable (and writable) as well as machine readable then you don’t want to go much over 8 characters
before designing an identifier we should be very clear what the identifier should be used for. There are lots of examples of “scope creep” where identifiers primarily designed for social security, tax, national identification etc are “repurposed” as health identifiers. Often they do not have the required characteristics for this. So maybe that’s the starting point - what exactly can we say this identifier is to be used for and not used for.
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
Ola
···
2010/2/4 Lars Helge Øverland larshelge@gmail.com
2010/2/1 Bob Jolliffe bobjolliffe@gmail.com
2010/2/1 Lars Helge Øverland larshelge@gmail.com
2010/2/1 Bob Jolliffe bobjolliffe@gmail.com
you are taking about me? What silly names do we have in mind?
Yes. Just kidding, no silly names this time.
Oh well. I guess we can always try silly indentifiers instead
We are going to implement system generated patient identifiers for the patient module.
VN team has suggested:
- Set of characters dependent on the organisation unit
- Set of digits, include date and number of patients in the day.
Viet has suggested an algorithm dependent on patient information and the time of creation.
Jason has suggested an UUID.
I think identifier for a person and identifier for a person’s file are subtley different. Patients may already have a number of personal state-issued identifiers (hence the flexible identifier type). Many of these might well provide the quality of uniqueness but not necessarily the anonymity you would look for when for example tracking lab samples. But it seems what you are looking at is the generation of a file number for the patient. Like would be written on top of the cardboard folder in “real life”. In which case I would be tempted to follow the simplicity of the VN team suggestion. Of course patients can migrate between org units which needs to be taken into account. If privacy is more of a concern then this information can instead be hashed, probably along similar lines to Viet’s algorithm.
A few things to consider:
there should be a check digit built in to the identifier
regular expression validation can be useful
if the identifier is meant to be human readable (and writable) as well as machine readable then you don’t want to go much over 8 characters
before designing an identifier we should be very clear what the identifier should be used for. There are lots of examples of “scope creep” where identifiers primarily designed for social security, tax, national identification etc are “repurposed” as health identifiers. Often they do not have the required characteristics for this. So maybe that’s the starting point - what exactly can we say this identifier is to be used for and not used for.
Hi Viet,
what are your thoughts on this? Is the identifier meant to be human readable? What is the main purpose of the identifier?
Lars
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
So what have they done in openmrs?
···
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
Exactly the kind of question that needs to be asked. I am sure Saptarshi, having developed modules for OpenMRS would know, and if not there is an active openmrs mailing list and lots of documentation on their wiki, and the source code is available.
A more long term question: Are we still planning to integrate this community system with OpenMRS as in e.g. using their API for patient management etc. or is that no longer the plan?
Ola
···
2010/2/4 Lars Helge Øverland larshelge@gmail.com
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
So what have they done in openmrs?
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
So what have they done in openmrs?
Exactly the kind of question that needs to be asked. I am sure Saptarshi, having developed modules for OpenMRS would know, and if not there is an active openmrs mailing list and lots of documentation on their wiki, and the source code is available.
Yes should be easy to find out. There was some discussion some months back which I followed vaguely. I am pretty sure Saptarshi has already looked into what they do.
A more long term question: Are we still planning to integrate this community system with OpenMRS as in e.g. using their API for patient management etc. or is that no longer the plan?
From what I have seen it looks like there was a departure from that proposed approach to one that is more similar to existing dhis paradigms. Hopefully with half an eye still kept on possible integration …
Cheers
Bob
···
2010/2/4 Ola Hodne Titlestad olatitle@gmail.com
2010/2/4 Lars Helge Øverland larshelge@gmail.com
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Ola
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Google knows everything …
···
On 4 February 2010 15:56, Bob Jolliffe bobjolliffe@gmail.com wrote:
2010/2/4 Ola Hodne Titlestad olatitle@gmail.com
2010/2/4 Lars Helge Øverland larshelge@gmail.com
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
So what have they done in openmrs?
Exactly the kind of question that needs to be asked. I am sure Saptarshi, having developed modules for OpenMRS would know, and if not there is an active openmrs mailing list and lots of documentation on their wiki, and the source code is available.
Yes should be easy to find out. There was some discussion some months back which I followed vaguely. I am pretty sure Saptarshi has already looked into what they do.
A more long term question: Are we still planning to integrate this community system with OpenMRS as in e.g. using their API for patient management etc. or is that no longer the plan?
From what I have seen it looks like there was a departure from that proposed approach to one that is more similar to existing dhis paradigms. Hopefully with half an eye still kept on possible integration …
Cheers
Bob
Ola
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Was just talking to Sundeep and Eric about the integration using the OpenMRS API just a few minutes back…
It would be useful to talk to ppl here once again, if its on anyone’s agenda and if Sundeep, Kristin and Jorn believe we can use the existing work by Abyot, Viet, Bharath etc in Patient module to use with the OpenMRS API.
As for the ID generation thing, I was collaborating with Andy by modifying the registration module, but then Mike Seaton suggested he can build a separate id_gen module instead of taking much modified registration workflow… It takes the good lessons learnt from id generation concepts and tries to keep it simple
···
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme
My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
2010/2/4 Ola Hodne Titlestad olatitle@gmail.com
2010/2/4 Lars Helge Øverland larshelge@gmail.com
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
So what have they done in openmrs?
Exactly the kind of question that needs to be asked. I am sure Saptarshi, having developed modules for OpenMRS would know, and if not there is an active openmrs mailing list and lots of documentation on their wiki, and the source code is available.
A more long term question: Are we still planning to integrate this community system with OpenMRS as in e.g. using their API for patient management etc. or is that no longer the plan?
Ola
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Hi Saptarshi
Was just talking to Sundeep and Eric about the integration using the OpenMRS API just a few minutes back…
It would be useful to talk to ppl here once again, if its on anyone’s agenda and if Sundeep, Kristin and Jorn believe we can use the existing work by Abyot, Viet, Bharath etc in Patient module to use with the OpenMRS API.
Probably should move this conversation to another thread.
As for the ID generation thing, I was collaborating with Andy by modifying the registration module, but then Mike Seaton suggested he can build a separate id_gen module instead of taking much modified registration workflow… It takes the good lessons learnt from id generation concepts and tries to keep it simple
This looks promising. Would be nice to be able to reuse this stuff.
Cheers
Bob
···
On 4 February 2010 17:10, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems ProgrammeMy Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
2010/2/4 Ola Hodne Titlestad olatitle@gmail.com
2010/2/4 Lars Helge Øverland larshelge@gmail.com
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
So what have they done in openmrs?
Exactly the kind of question that needs to be asked. I am sure Saptarshi, having developed modules for OpenMRS would know, and if not there is an active openmrs mailing list and lots of documentation on their wiki, and the source code is available.
A more long term question: Are we still planning to integrate this community system with OpenMRS as in e.g. using their API for patient management etc. or is that no longer the plan?
Ola
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Hi,
This id will be given to each patient, so it should be human readable.
I have just had a quick look at the id_gen_module of OpenMRS . It would be very nice if we can use that module for DHIS, as it has eveything we need …
I will try to get source code and see what I can do.
···
On Thu, Feb 4, 2010 at 11:16 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Saptarshi
On 4 February 2010 17:10, Saptarshi Purkayastha sunbiz@gmail.com wrote:
Was just talking to Sundeep and Eric about the integration using the OpenMRS API just a few minutes back…
It would be useful to talk to ppl here once again, if its on anyone’s agenda and if Sundeep, Kristin and Jorn believe we can use the existing work by Abyot, Viet, Bharath etc in Patient module to use with the OpenMRS API.
Probably should move this conversation to another thread.
As for the ID generation thing, I was collaborating with Andy by modifying the registration module, but then Mike Seaton suggested he can build a separate id_gen module instead of taking much modified registration workflow… It takes the good lessons learnt from id generation concepts and tries to keep it simple
This looks promising. Would be nice to be able to reuse this stuff.
Cheers
Bob
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems ProgrammeMy Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
2010/2/4 Ola Hodne Titlestad olatitle@gmail.com
2010/2/4 Lars Helge Øverland larshelge@gmail.com
On Thu, Feb 4, 2010 at 3:38 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:
Hi,
Is there some reason for not simply reusing what OpenMRS has done in this area?
Seems like we are dealing with a lot of fundamental patient level issues (not just in this thread) that I am sure have been discussed and taken care of already in a mature and widely used application like OpenMRS.
So what have they done in openmrs?
Exactly the kind of question that needs to be asked. I am sure Saptarshi, having developed modules for OpenMRS would know, and if not there is an active openmrs mailing list and lots of documentation on their wiki, and the source code is available.
A more long term question: Are we still planning to integrate this community system with OpenMRS as in e.g. using their API for patient management etc. or is that no longer the plan?
Ola
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp
–
Viet Nguyen
Good!
···
On Thu, Feb 4, 2010 at 11:24 PM, Viet Nguyen phamquocviet@gmail.com wrote:
Hi,
This id will be given to each patient, so it should be human readable.
I have just had a quick look at the id_gen_module of OpenMRS . It would be very nice if we can use that module for DHIS, as it has eveything we need …
I will try to get source code and see what I can do.
OK. Good point.
Even if we generate the facility part of the id on-demand we would still want it to be fixed length…?
Please continue discussing about the identifier on this thread.
I don’t have strong opinion about this problem, let John and guys discuss and finish it. Then I could do the coding part…
Regards,
···
2010/3/4 Bob Jolliffe bobjolliffe@gmail.com
2010/3/4 Lars Helge Øverland larshelge@gmail.com:
2010/3/4 Bob Jolliffe bobjolliffe@gmail.com
I agree depending on the uniqueness of names is not a good idea. I
saw John said that facilities in India do have codes - the 16 digit
ones which are built hierarchicly (is that a word?).
OK I wasn’t aware of this code… Certainly if we could generate a string
based on the orgunit code plus its ancestors it will be unique. How does one
generate a fixed-length alphanumeric string based on this sequence of names
btw?
I’m thinking that we just generate the local part. The facility codes
already exist. So in Db you would have fields for patient id and
issuing-facility. I think it is common to store the issuing authority
with an id anyway. In most cases the issuing-facility might be null
because it could be assumed. If a patient is moved into the db from
somewhere else, or if patients are combined from different facilities
for one of many reasons, then the facility code would need to be
populated to avoid clashes. This bears some resemblance I think to
the uuid disambiguation referred to by Saptarshi.
–
Viet Nguyen
awwwhhh… Viet that’s sweet!!
We all sometimes get bored with these discussion… I sympathize…
But they are important to realize the philosophy (Sellars, 1963) of science
···
Regards,
Saptarshi PURKAYASTHA
Director R & D, HISP India
Health Information Systems Programme
My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
2010/3/4 Viet Nguyen phamquocviet@gmail.com
2010/3/4 Bob Jolliffe bobjolliffe@gmail.com
2010/3/4 Lars Helge Øverland larshelge@gmail.com:
2010/3/4 Bob Jolliffe bobjolliffe@gmail.com
I agree depending on the uniqueness of names is not a good idea. I
saw John said that facilities in India do have codes - the 16 digit
ones which are built hierarchicly (is that a word?).
OK I wasn’t aware of this code… Certainly if we could generate a string
based on the orgunit code plus its ancestors it will be unique. How does one
generate a fixed-length alphanumeric string based on this sequence of names
btw?
I’m thinking that we just generate the local part. The facility codes
already exist. So in Db you would have fields for patient id and
issuing-facility. I think it is common to store the issuing authority
with an id anyway. In most cases the issuing-facility might be null
because it could be assumed. If a patient is moved into the db from
somewhere else, or if patients are combined from different facilities
for one of many reasons, then the facility code would need to be
populated to avoid clashes. This bears some resemblance I think to
the uuid disambiguation referred to by Saptarshi.
OK. Good point.
Even if we generate the facility part of the id on-demand we would still want it to be fixed length…?
Please continue discussing about the identifier on this thread.
I don’t have strong opinion about this problem, let John and guys discuss and finish it. Then I could do the coding part…Regards,
Viet Nguyen
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp