Looking forward to discussing in person. I'll try to put together some additional design documentation, but in an attempt to respond to your points, see below:
Yes, this is essentially what I have done in pih-biometrics for Neurotechnology. Neurotechnology also comes with an out of the box product, called NServer. I chose to simply roll my own since the API was pretty straightforward to work with and it gives me more control and understanding of what is going on. But it is really just a lightweight wrapper application of the underlying Neurotechnology service, in order to expose a set of REST web services that we can access from OpenMRS. So I think we are aligned here, and even though we'll both have to write our own wrapper applications, I hope we can come up with a harmonized API.
I hadn't really thought much about this merge use case, but it is an interesting one. One question overall is - is it a problem (or could it be a benefit) to have multiple fingerprint records associated with a single patient? Do we really need to merge these, or can we keep them both as separate identifiers, which might both return valid matches?
I have also based our API thus far on a base64 encoded text representation of the template. Neurotechnology is capable of supporting (and converting between) it's internal proprietary template format, ISO, and ANSI, from what I can tell. I'm not sure if there is an advantage to storing fingerprints in ISO format if matching is more efficient and/or accurate in the proprietary format, and as long as it can import/export templates in ISO format for integration with other systems. I'd be interested in any thoughts or experience that you or others may have on this.
In the design that I have been working up, the fingerprint itself is not stored in OpenMRS. It is not even necessarily in MySQL (I have used Sqllite in my initial setup). The way I have been thinking about it - the fingerprint server is conceptually distinct from OpenMRS, and could even contain records of persons that are not stored in the OpenMRS system. Perhaps there are other systems that need fingerprinting at a facility that do not exactly overlap. So I have deliberately tried to keep any notion of an "OpenMRS person/patient" out of the fingerprinting server itself. The main drawback to this that I can tell is that registering a patient and/or storing a reference to the patient's fingerprint is transactionally separate from registering the fingerprint with the fingerprint server. So it is theoretically possible to end up with patients with no fingerprints registered, or fingerprints that are registered before a patient is created (and perhaps that patient registration never completes).
What M2Sys calls the "RegistrationID" is called the "SubjectID" in Neurotechnology, and so this is the verbage that I have used in my initial design. We can call it whatever we think is most correct / whatever the standard in the industry is, if there is a generally agreed one, it doesn't really matter to me, but it sounds like we are aligned around this.
In the pih-biometrics system, I associate a completely independent SubjectId/RegistrationId with the fingerprint, and then expect we will associate that with the patient. Whether this is stored as a patient identifier, person attribute, or obs - I'm not sure. A patient identifier makes decent sense to me, and if you have this requirement, then that should work. I don't know if you have particular constraints around the nature of this SubjectId/RegistrationId. In my initial pass, I am simply generating a new UUID and using that, and I haven't seen any indication yet that this is a bad choice.
Agreed. I have added this to pih-biometrics as the "status" endpoint, which contains various properties (which we will likely need to discuss and agree upon), including "status = AVAILABLE/NOT_AVAILABLE" as a first pass.
This is an area I am very interested in discussing more and understanding best practice. Neurotechnology seems to support bundling multiple modalities into a single template - one creates a subject, and adds one or more fingers with or without a position (one can also add things like palm prints, iris scans, voice recognition, etc to this as well), and then generates a template from all of it . Of course, one could also decide to limit a template to just a single fingerprint, and generate a template from this, and do this several times for the same patient, storing different patient identifiers for different fingerprints, though in this case I might advocate more strongly for storing these as Obs, not sure.
Hope this helps and we can find a common way forward!