Quoting Peter Machell <[EMAIL PROTECTED]>:
> On 16/06/2007, at 6:41 PM, David Guest wrote: > > >> Does the hcnreader give you access to an SQL command line prompt > >> or do you > >> pass it SQL formatted statements from a program as with an ODBC > >> driver. > >> > > The latter. Not sure about the former. > > > Both. OSQL is the command line interface supplied even with MSDE, but > it has it's limits. > Every popular high level language can directly query MSSQL. > > The way I see it, we don't need an API, just a definition of what > data is needed, some funding to make it happen, and a developer with > enough vision to include many EHRs in the process. I think this is what my Gen Data Analytics Language (GDAL) is trying to do. here are some pointers about the way we are trying to think about this problem. Principle of DESIGN The principle by which it is designed is that you should be able to state a query for every question that is answerable from data in the database. I don't know how we can prove that such a langauge has such definitional power but it least we have to have a go at it with heurisitic strategies. Principle of IMPLEMENTATION That every question that can be stated is computable. This means building an engine that can convert the high level language into basic operations on the data in the database. Those two operations are Retrieval and Statistical analyses. The first is achieved by SQL or a look-alike and the second is a whole world of itself. We have started by providing the statistical functions available in SQL-99, modest but it works in the prototype. Tim Churches has made the crucial observation of our work that true analytics doesn't occur until you can state comparisons between records or classes of records. We can only do that through multiple queries at the moment but we are not far off doing it in a simple way. Principle of UNIVERSALITY This is the task of answering Peter's comment "include many EHRs". I take it that he means access to the EHFolders in many different EHR Apllications, that is, not just the GP information systems but also the hospital and other systems. We have tackled this by creating a layer in our system for mapping between the language of descriptions ( our GDAL) and the language of implementation, that is, the schema and data domains of the application. We have this working for the CareVue system but it was hand crafted. Our next step is to understand how to make it learn from an incumbent system e.g. MD, about its internal data management and so be able to access the correct data structures for a given GDAL query. The other dimension of universality is to allow the use of a very wide range medical vocabulary. We will provide this initially by allowing the use of any term from SNOMED CT (and/or ICD 10AM,...). The issue will be on how to map elements of the GDAL terminology to the terminology of the application developers BOTH at the schema level AND the data contents level. In summary we are thinking about how to achieve this higher order processing and we have some parts implemented but still have a way to go. cheers Jon > > cheers, > Peter. > -- Jon Patrick Chair of Language Technology Australian R&D Centre for Health Informatics School of Information Technologies University of Sydney > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
