|Subject:||Re: [Gnumed-devel] LDAP vs. SQL - RT comments|
|Date:||Fri, 1 Aug 2003 08:18:34 +1000|
On Thu, 31 Jul 2003 10:50, Ian Haywood wrote: > I've been doing some research into LDAP, we may be able to get equivalent > functionality using LDAP alone, remaining compatible with other services, > depending on what's in Richard's schema. > > If not, this is a good solution. It is, and it can be done. Together with Peter Schloeffel from GEHR/OpenEHR we made a joint submission for funding of a "demographic service" which is not only badly needed by gnumed but by everybody else also. I have attached the proposal paper which outlines a few alternatives. I am currently adapting my "person" business objects and the data entry/display panels to reflect future availability of such service. Peter and I are confident that the funding will get through, and I am absolutely confident that the project specifications will require GPL licensing and use of gnumed compatible programming languages and tools. On another positive note: Looks like OpenEHR is about to get serious funding by SUN - who of course made it a requirement for it to be written in JAVA. The prospect of bolting our frontend and perhaps busines objects onto a OpenEHR server/service becomes more realistic too (will not stop us (yet) from continuing development of our current own backend, but it is a nice prospect for the future and an encouragement to go ahead with the business object abstraction layer in any case) Horst
The Need For Demographic Information Services (DIS) in Health Care
Demographic information is the pivotal data virtually any other information segment in health care depends on. Even anonymous study results will at least initially require some form of demographic information to be collected and administered, before the data is de-identified. In the domain of electronic health records (EHR), the presence of demographic information is the least common denominator.
Accepting that most if not all medical information management will deal with demographic information, it is astounding to find out that there are no de facto standards in place to store, administrate and access demographic information.
Out of the several dozen EHR packages available in Australia, there are no two packages that can reliably and completely share demographic data. The situation appears no better in the realm of hospital information systems.
In the domain where data exchange does already happen, as in the case of pathology results, mismatching demographic information and failure to identify identities correctly remain a major problem, making expensive human interaction a mandatory requirement whenever data is exchanged.
The purpose of this document is to
What does a DIS do?
When we need the phone number of a person or company, we look it up in the "white pages" or the "yellow pages", unless we have that number stored in our own personal address book. We might also choose to ring an information service for that purpose.
A demographic information service typically works in a similar way: often needed information is cached locally, and information not available locally is queried in a hierarchical manner until the information is found or all sources exhausted.
In health care, we do not only need information regarding a person's name, address and phone number. We also want to know other basic demographic attributes like gender and date of birth. Administration might need to know about the role of a person or entity, and doctors will be interested in relationships between people, both of social and genetic nature. Some of this information will of course be confidential, and could not be accessed as openly as the "white pages". Some information will change over time (like surnames in people re-marrying) and yet both versions might still be of interest to epidemiologists or forensic specialists decades after the change. Stored information will of course not be limited to actual people, but will also include institutions, companies and other "entities" in the widest sense.
Information of such kind can be administered by a demographic information service (DIS). Since almost every single software application in health care will need to access such demographic information, it is pointless to reimplement that effort again and again. Not only pointless in the sense of unneccessary multiplication of effort and waste of ressources, but also with hindsight to non-interactive data processing and exchange.
If a single widely accepted demographic service model could be built, software developers could simply forget about the tedious task of collecting and administering demographic data. Once implemented, savings would materialize with every single new software project in the health domain, and possibly even in other domains. If demands for demographic data change (like the sudden availability of a nationwide or even world wide PIN or changes in privacy legislation) there would be only one single code to be changed instead of hundreds if not thousands of software packages needing substantial modifications!
When would a DIS be useful?
What should we expect from a DIS specification and implementation?
Present state of demographic information management in health care
As mentioned in the introduction, demographic services are still lacking in Australian health care. The dominant market player in Australian EHR software uses a simplicistic denormalized flat file schema to store demographic information, and most of the competition follows that thread. Pathology, the main entity currently deploying electronic data exchange between health care providers, depends largely on the openly defined but not standardized PIT format or HL7 V 2.x - both methods creating substantial problems due to their inherent ambiguity.
The following non-exclusive listing gives a brief overview over existing models for possibly suitable demographic service models. Suggestions range from access protocols / APIs like LDAP to concrete service implementations with remote object access like CORBAMED PIDS - while not directly comparable, these different efforts emphasize how broad the scope can be.
The OMG has specified a Person Identification Service (PIDS) as part of the CORBAMED specifications i. The primary goal is to provide unique patient identification across heterogenous systems requiring interoperabilityii. A number of PIDS implementations have been in use for several years iii. However, the complexity of CORBA in general and CORBAMED PIDS specifically (the interface definition alone consists of more than 900 lines of code!) as well as possible compliance costs (branding of CORBAMED PIDS) appear to have prevented more widespread use. There are also concerns regarding granularity of access privileges, the CORBAMED PIDS relying solely on the "CORBA Security Services" for confidentiality enforcement iv. Versioning of demographic information (non destructive administration of information changes) is not specified. Identity mapping (one demographic entity can have multiple identifiers) is supported
Development of at least one free and open source (FOSS) PIDS compliant service has been started with a project called CIRCARE v, but the project appears to have stalled since 2001. Nevertheless, the still available code base providing a functional partial CORBAMED PIDS implementation would be a good starting point for other projects.
The "entity" and "role" subject areas within the HL7 reference information model (RIM) deal with basic demographic information vi. Biological relationships appear to be poorly supported. Versioning of information appears possible, but I could not find detailed specifications. Unambiguous identification of demographic entities appears problematic. Identity mapping is possible, but I could not find detailed specifications. Implementation as a service is not specified.
While there are several free implementations of HL7 V2.x libraries available, there is no specific implementation of the demographic part in itself, and no implementation as a service. There is no free implementation of the HL7 V3 specification available.
openEHR specifies a demographic reference model vii., but there has as yet been no reference implementation. The model appears to be expansible through the use of archetypes. Implementation of the demographic reference model as a service is planned but has not yet been undertaken in currently available documents, though the design clearly suggests implementation as a service. The openEHR demographic model gives more consideration to relationship between demographic entities than the HL7 RIM or CORBAMED PIDS - the latter models appear more business and administration focused rather than clinical. Versioning is specified in the openEHR demographic model but the details of access privileges have not yet been specified. From the documentation, it is not clear how demographic access privileges are handled. Identity mapping is possible, but not yet clearly specified.
While not limited to the medical domain, the "light weight directory access protocol" LDAP has established itself as widely accepted standard for access of demographic information within the Internet. The design goal was to lower the threshold of using X.500 directory services. However, LDAP has become increasingly independent of X.500, so that LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface.viii Authentication is still not standardized, but a number of standard proposals have been submitted to the IETF (Internet Engineering Taskforce) ix. Following a "white pages" paradigm, there are no standardized ways of expressing relationships between demographic entities. There are no standadized ways of versioning information. Identity mapping is possible, but no standards for this in place. Most LDAP servers nowadays have replication, synchronization and load balancing features available.
At least one freely available reference implementation exists x. Implementation of the client side is trivial, and a number of freely available interfaces to many popular programming languages exist. Using such a domain -independent standard would also facilitate integration with domains other than health care.
At least one Australian health care application uses LDAP for demographic information - Argus xi, "a suite of programs developed by the Collaborative Centre for eHealth that provides a secure mail-exchange system for the dissemination of documents between health service providers".
In order to get started with a DIS implementation, it might be practical simply to start out with plain LDAP and the most basic demographic information (name, title, contact details, gender, date of birth). It has the significant advantage that many existing "address book" applications such as those integrated into email clients would support this approach out of the box, providing users with user interfaces to their demographic data they are already used to.
The next step could be to map the openEHR demographic model onto the LDAP protocol, and finally to bolt a CORBAMED PIDS compatible interface onto that evolving service as an option for performance hungry (or already PIDS compliant) applications. Advanced features such as synchronization, replication and load balancing would be supported right out of the box, and impressive scalability has already been demonstrated in real life.
Since implementation of LDAP client facilities is trivial and most software vendors can make use of a plethora of tested and readily (often even freely) available client libraries for most if not all programming languages in use, I would expect that early adoption would be high.
The nature of LDAP would enable us to use existing server software (like OpenLDAP) without any modification; information not already covered regarding for example personal relationships can be specified in server configuration schemas as needed.
ixhttp://www.ietf.org/rfc/rfc2829.txt, http://www.ietf.org/rfc/rfc2830.txt, http://www.ietf.org/rfc/rfc2820.txt, http://www.ietf.org/rfc/rfc3112.txt, http://www.ietf.org/rfc/rfc3062.txt,
|[Prev in Thread]||Current Thread||[Next in Thread]|