Fwd: PRIORITY: Prepping for the Stanford Hackathon
Gregory Kelleher
Begin forwarded message:
From: Gregory Kelleher <gr...@kelleher.cc>
Date: October 18, 2011 11:02:00 PM EDT
To: "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rd...@cdc.gov>
Cc: Saptarshi Purkayastha <sun...@gmail.com>, Daniel Pepper <daniel...@gmail.com>, Surajit Nundy <nun...@gmail.com>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
Roger,It's pretty clear to me from the discussion that the lab needs a system built for lab management by developers familiar with the workflow of a medical lab. Such systems (called 'LIMS') can not only help technicians follow best practices but are often fitted with lab equipment interfaces so the can monitor, control, and read results from analytical devices (they can "chip-in", if you like).I'm sure we can find open-source LIMS. Our time would be better spent, and JSS better served, if we searched for a system with a good fit rather than trying to rebuild this wheel. BTW, if we were to undertake this task, we'd find that neither CouchDB nor OpenMRS would be the right platform.-- GregDo no harm, waste no fortune.Hi Saptarshi, see below
From: Saptarshi Purkayastha [mailto:sun...@gmail.com]
Sent: Tuesday, October 18, 2011 3:55 PM
To: Friedman, Roger (CDC/CGH/DGHA) (CTR)
Cc: Daniel Pepper; Gregory Kelleher; Surajit Nundy
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
Hi Roger,
On 19 October 2011 00:34, Friedman, Roger (CDC/CGH/DGHA) (CTR) <rd...@cdc.gov> wrote:
Saptarshi --
I see three problems with your tasks.
1. Many of the tasks are impossible without new tables. For example:
a. There is a need to connect the pre-condition questions with the tests to which they relate.
These can be designed to in the program workflow/concept dictionary. So, for e.g. if a patient is visiting the AIDS program lab, and enrolled into the ANC program, she will go through a set of questions, than a patient going for a HIV test after a session with the counsellor. So, the pre-condition questions can be recorded as observations in an encounter form
No, these are questions specific to particular tests, like for fasting cholesterol, “Have you had anything to eat since midnight”. They shouldn’t go on a form because the same question might be asked for more than one ordered test, and it should only be asked once. See the mockup.
b. There is a need to store the age-sex-specific normal ranges and connect them with a test.
hmmm... this might be a challenge, but I wonder how it is done in current OpenMRS concept dictionary. I've not encountered this issue and it has generally been the common range for all in the concept dictionary and then the clinicians interpret the range depending on patient age etc.
The OpenMRS numeric concept does not have this properly modelled. Clinicians cannot interpret this, it is derived from lab data.
c. There is a need to know what type of specimen is collected for each test panel and what type of specimen is actually needed for each test in the panel.
I am hoping this can be done through instructions, accession number fields from the Order and the correlation between the corresponding Concept. May be I am understanding you incorrectly. So, if an Order consists of a panel with the underlying Concept as COMPLETE BLOOD COUNT (CBC), then the specimen is BLOOD. The technician knows what they have to do with the BLOOD sample and after they've done their work, they will enter values for results for HEMATOCRIT, HEMOGLOBIN, PLATELETS, WBC etc etc. I dont recognize the need for having technicians to store intermediate steps of adding vile number 1 for plasma or vile number 2 for WBC etc etc. That will be too much work and paper works best I feel.
This is not something that should be left to the technicians. It is very common for the test requested and the sample supplied not to correlate, this is an error that should be checked for. Most lab specimen registrations first ask what type of specimen has been received and then offer a test pick list containing only those tests appropriate to the specimen type. If you look at the phlebotomy system in most US labs, they take in required tests and then display pictures of all the supplies needed and print out bar codes for the tubes.
Is that what you are referring to as specimen or have I misunderstood you??
I have actually combined things a little in specimen type. The fact that the analyzed specimen type is different from the received specimen type identifies the need for a particular preprocessing step. For example, the bullets used in the WBC machine each contain part of the specimen from the tube containing the patient’s blood. The original specimen is blood in a yellow-top vacutainer (look up vacutainer in Wikipedia, each color represents a different additive) , which is the received specimen type; the bullet is the analytical specimen type. That they are different means there is a processing step to take the blood from the tube and put it in the bullet. I know that they are not numbering the bullets, but they should be! Also, if you notice the flow diagram, every time they need a retest, they go back to the patient and draw another sample. This is not good practice; the original specimen should be kept until all tests on it are complete so that if a test needs to be redone, another aliquot can be drawn from it for testing. Of course, if the specimen is hemolyzed or otherwise too damaged to test, or if the entire specimen is consumed in the test, the patient will have to have another specimen drawn (on another order).
d. There is a need to know what orders/tests are to be reported together.
I think this can be done through LabSets and these can be ordered or reported together. If CBC is orders, all those individual tests need to be done and reported together.
Not without a big mess. For example, most labs offer 3 sets of test on whole blood, each larger than the next; although they run all the tests, they only report what the physician requests. None of the 3 sets includes a sickle cell test. So if the same specimen can be used for both the whole blood panel and the sickle cell test, you now need to define 6 panels, 3 with and 3 without the sickle cell test. Too difficult for physicians!!
2. The move to HL7 is not really necessary at this time, but if you want to go that direction, there are some challenges:
a. There is no uniform way of coding tests and test results. Therefore, for each test panel, test and coded result there needs to be a lab-specific concept map from the internal reference to the code the lab uses.
b. The OpenMRS webservices REST implementation provides only the unparsed HL7 message body. The main work of the lab module will be to create OBR and OBX segments. Given that the OBX segment has a variable format depending on the observation type, just understanding that task would be a lot for a hackathon, let alone the parsing of the HL7 message and understanding the whole concept of HL7.
ok... may be that was a little thinking-out-loud syndrome. We can avoid the HL7 conversions for the time being and just use the ORDER and CONCEPT and OBS resources for REST calls.
The lab should not be using OBS for results. Not all results seen in the lab are reported to the physician, but they are important for the lab. As I say/said elsewhere, intermediate results need to be kept but not shown on the report. Only results shown on the report should go into OBS, and only on release of the report.
3. I don't think drag-and-drop is quite the right way of doing lab reports; the reports are highly structured and about the only things the reviewer can do is hide intermediate results or add comments.
The drag-drop was a designer for designing reports by the lab admin. Once they are designed it will be static. The reason I mentioned this is that, there may be changes in implementations and how they design patient reports. It will be sad if we require HTML skills to make reports. BIRT is nice, but even that's a learning curve. If we can have a designer where you can design patient reports by placing that will be useful.
More complicated than necessary. There’s a page header with the lab logo and address etc. There’s a report header that has the ordering physician and patient information. There’s an order-specimen-test header for each panel (the entire panel can be hidden if rejected). There’s a detail line for each test result, which can be hidden. There’s an order-specimen-test footer for the panel indicating the lab tech who ran the test, whether it was rejected by whom and why, and any comments at that level. There’s a report footer that has the approver’s signature and any comments at that level, the report type (preliminary, final, corrected) and date/time.
---
Regards,
Saptarshi PURKAYASTHA
My Tech Blog: http://sunnytalkstech.blogspot.comYou Live by CHOICE, Not by CHANCE
From: Daniel Pepper [mailto:daniel...@gmail.com]
Sent: Wednesday, October 12, 2011 11:47 AM
To: Saptarshi Purkayastha; Gregory Kelleher
Cc: Friedman, Roger (CDC/CGH/DGHA) (CTR); sam...@cs.stanford.edu; Surajit Nundy; abhinavg...@gmail.com; natha...@gmail.com; angad...@stanford.edu; Bhushan Mohan; rya...@icgcreative.com; vishwa...@gmail.com; hlb...@gwmail.gwu.edu; shi...@gwmail.gwu.edu; kevin...@gmail.com; emdo...@gmail.com; ssa...@gmail.comSubject: Re: PRIORITY: Prepping for the Stanford Hackathon
Sorry – just seeing this now. Agreed: this sounds both realistic and important.
On 10/12/11 8:07 PM, "Saptarshi Purkayastha" <sun...@gmail.com> wrote:Also to keep this real, Roger's example of tasks isn't suited to a 1-day hackathon model. Eventually we will do it and hopefully the hackathoners will continue post the hackathon. But to get something that can be used,
So as I see it, 3-tasks from the top of my head, given that we will have 4 ppl assigned to our project.
1.) Design HTML pages (may 4-5 pages depending on the UX team's designs) for the different workflows with JavaScript
2.) REST representation of the HL7 messages for Lab results. Gives us flexibility (can be passed to another LIMS or Couchapps or OpenMRS API)
3.) HTML5 layouts for patient report printout. (A customizable drag-drop layout to be able to print individual patient lab results)
None of these require deep understanding or atleast running OpenMRS locally. We will host a server that the "hackathoners" can use and make REST calls and work against.
---
Regards,
Saptarshi PURKAYASTHA
My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
On 12 October 2011 19:37, Gregory Kelleher <gr...@kelleher.cc> wrote:Roger,
There may be a slight delay while the architectural design is re-examined. As I understand it, the choice is to be confirmed on Friday.
-- Greg
Do no harm, waste no fortune.
On Oct 12, 2011, at 8:39 AM, "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rd...@cdc.gov> wrote:Dear Sam King,
I don't know how much of the materials Surajit has shared, let me know if you need a copy. Given the architecture that the project has chosen, I think the best thing would be for this group to develop a object model/database structure that represents the workflow and lab technical requirements and make the task of the hackathoners to be to move the model into Hibernate and Liquibase; build the OpenMRS module structure, DAOs and the basic data service; and build the REST interface to the data structures. This limits the technologies to be understood to 4 -- Hibernate, Liquibase, the OpenMRS module architecture and the OpenMRS REST object architecture. This is probably a 4 week task for a single CS undergrad from an Indian technical college.
Let us know how this fits with your thinking. I would expect to have a review copy of a data model with some business rules out by Sunday's phone call. Everyone else, what are your thoughts?
Saludos, Roger
From: Sam King [mailto:sam...@cs.stanford.edu]
Sent: Wednesday, October 12, 2011 03:53 AM
To: Surajit Nundy <nun...@gmail.com>
Cc: ABHINAV GHAI <abhinavg...@gmail.com>; Nathan Leiby <natha...@gmail.com>; Angad Singh <angad...@stanford.edu>; Daniel Pepper <daniel...@gmail.com>; Bhushan Mohan <mo...@cs.virginia.edu>; Reza Yazdi <rya...@icgcreative.com>; Saptarshi Purkayastha <sun...@gmail.com>; Vishwa Sanjay Parekh <vishwa...@gmail.com>; Jianhua Wang <hlb...@gwmail.gwu.edu>; shi...@gwmail.gwu.edu <shi...@gwmail.gwu.edu>; Kaiwen Xu <kevin...@gmail.com>; emdo...@gmail.com <emdo...@gmail.com>; Sidharth <ssa...@gmail.com>; Friedman, Roger (CDC/CGH/DGHA) (CTR); Gregory Kelleher <gr...@kelleher.cc>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
In general, I find that projects that are more self contained work best (ie, projects that rely on knowledge of large code bases like OpenMRS tend to work less well).
Let me and/or Angad know if you have any questions about how the hackathon will work.
Sam King
Director | Code the Change <http://codethechange.org> - we have a hackathon for social good coming up!
Teacher | CS1U: Practical Unix <http://cs1u.stanford.edu> - videos and exercises are available free online!
facebook <https://www.facebook.com/samjking> , linkedin <http://www.linkedin.com/profile/view?id=55518052> , google+ <https://plus.google.com/111459971983433860521> , verbose letters <http://stanford.edu/~samking/personal/>
On Tue, Oct 11, 2011 at 12:44 AM, Surajit Nundy < <mailto:nun...@gmail.com> nun...@gmail.com> wrote:Hi everyone:
I just had a long and illuminating discussion with Angad, one of the coordinators of the Stanford "Code the Change" Hackathon on Oct 22. This instance of the Hackathon will coincide with the Facebook Hackathon and will also be special because it goes from 5 pm on Oct 21 to 5 pm on Oct 22 and will last 24 hours. The Hackathon has very kindly assigned a team of one Project Leader (who is usually an experienced programmer) and a total of 3-5 developers to get our project off the ground. Our Project Leader should be assigned in about 2 days and will be someone well-versed in the technologies we are using.
In order to make this a worthwhile experience for the hackers and us, we need to now take our Laboratory Module and make definable objectives out of it. Sam King has experience in this process and will (very kindly) advise us how to convert our User Story into something that is *hackable*. It would be great if our Laboratory Module team cc'd here led by our Cross-Module and Lab Module Coordinators, Nathan and Abhinav, could do that. I'd suggest using our JIRA system to task out this conversion as well as being something that the hackers can use for their work. One aspect that is important and doable but not in the User Story is the opening up of user and computer interfaces (via HL7) for external Laboratories so that our patients can import their data from labs other than at JSS into their records. Another (that might be a bridge too far for Oct 22 but one can always hope) is so that patients will be able to call up their lab data on the phone and interact with it. Reza, our UX lead is planning to have the UX done by Sunday, Oct 16, and that will really help us move the ball forward. Lastly, by Thursday we will have decided if we are going to stick with OpenMRS' current database implementation or be moving to Apache CouchDB.
Speaking for all of us on the project, Angad and Sam, we are very grateful to the Hackathon for including us in this special instance of it. Saptarshi and I are coming to Stanford's campus (actually Facebook in this instance) from India for the Hackathon and it would be a great experience for the project and the hackers if Reza, Sidharth and some of the other UI/UX designers with real-world experience who live in the area could be around to make this happen. We are a bit behind because the other Hackathon projects are already quite well-defined, but I think with some work we should be able to make this a great experience for all of those involved. This is very exciting because the Hackathon will flag off the first lines of code that get written for our project. I am looking forward to it.
Shuro
Gregory Kelleher
Begin forwarded message:
From: Gregory Kelleher <gr...@kelleher.cc>
Date: October 19, 2011 3:30:32 AM EDT
To: "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rd...@cdc.gov>
Cc: Saptarshi Purkayastha <sun...@gmail.com>, Daniel Pepper <daniel...@gmail.com>, Surajit Nundy <nun...@gmail.com>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
All,I agree that the HL7 development task is both too complicated and not really needed (at least, at this time). Having suggested that the lab should consider a custom system -- which isn't a one day project for any number of programmers -- I offer my opinion on the remaining item on the menu (forms development task) with considerable reluctance and a half-baked alternative.Saptarshi has noted that OpenMRS has so far only been implemented in post-event data collection settings, not in direct use by care providers. Since the interface is only used for transcription it's natural to underestimate the amount of domain knowledge required to fit the new forms to their intended use. (I hope you see this as the same point Roger made about lab procedures, although there is a great difference in degree.)There are three important functions implicite in the workflows that are largely independent of both clinical knowledge and existing systems. Furthermore, they belong early in the dev process and are interconnected, relatively simple to satisfy, and encourage creativity. They are:1) Patient Registration -- search appointment schedules, master registry for patient identity; correct errors, resolve duplicates; add registration and issue ID card, if necessary; update contact, residence, employment, insurance info. Sign patient into roster for appropriate clinics, services; record major complaints for walk-ins. Issues unique single-visit, color coded, sequentially numbered ID token. Target interface: desktop browser.2) Patient Roster -- multi-view patient tracker showing patient's schedule and current status on various devices from cellphone to 20+inch wall-mounted touch screen. Role- and relationship-appropriate info available to all parts with need to know, eg:Registrar: due for 10am appt in PT Clinic; not checked inFamily: by token #, location & stage (post-procedure recovery; 30 min)Any physician in clinic: patient's major complaints, vitals, triage note, status (awaits lab results), other scheduled encounters, physician seen last visit.Assigned physician: also link to med recordLab, Pharmacy, Consultant: status, outstanding orders, completed orders & results.Billing: a history of the visit and billable services.3) Appointment history & scheduling system: includes followup actions (routine, random, requested, failed appointments)Together they can improve coordination, load balancing, process improvement and patient satisfaction; enable real-time monitoring of geo-local complaints trends, M&E counters; increase reliability of patient identification, and provide for opportunistic screening and treatment.This may seem exaggerated. With less fanfare and typing I can suggest one other direction for the Hackathon: drag-and-drop conversion of OpenMRS concepts into HTML form elements. For both directions I have code fragments, data in CouchDB, and a partial coding standard as a FreeMind map. Just short on time.
Gregory Kelleher
Begin forwarded message:
From: Gregory Kelleher <gr...@kelleher.cc>
Date: October 19, 2011 6:51:13 PM EDT
To: Saptarshi Purkayastha <sun...@gmail.com>, Roger Friedman <rd...@cdc.gov>
Cc: Daniel Pepper <daniel...@gmail.com>, Surajit Nundy <nun...@gmail.com>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
Roger, Saptarshi,You both know more about LIS/LIMS than I do (though I did work in labs 40 years ago). It seems we agree on the need for a LIMS for the usual reasons and there's no viable open source option. I think we also agree that purchase is not an option and that we should only replace the current program when we are confident that we'd be making improvements in the eyes of the users.Questions and answers that come to mind, from least to most controversial:1). JSS needs to build a LIMS;2). Work, specs and road map require open involvement of lab mgmt and staff who must approve implementation plan;3). An adequate LIMS will generate and persist many times the volume of data interesting to clinicians or researchers, so it's likely to work best as a separate system, providing a service through a standards-based interface.4). If we are to share data with researchers or the world (via an OpenMRS repository), we need a common or inter-translatable lexicon, so we should start by adopting LOINC (?) for lab orders and reporting. (Are we now in the process of restating the language without ensuring translatability?)5). We are all in agreement on the evolutionary approach Daniel describes. However, we may have different recommendations about the starting points. (We can't start with single-cell organisms for all features... As Roger pointed out, for the lab that would be a regression.). If we don't start with some sort of skeleton -- such as a reliable convention for naming/identifying people, places and things -- there won't even be a fossil record to study.6). We won't need to pay the price (in complexity) for HL7 until JSS exchanges data with a system that requires it.7). Enterprise messaging (of JSON data) will be the backbone for the mature, maximally efficient JSS EMR and the sooner we implement, the more we'll benefit. (Just a reminder that we haven't had that conversation yet.)The evolving EMR will benefit from the schema-optional, make-as-few-demands -as-possible nature of CouchDB. But we require SOME schema for document matching and just plain coherence. We can also accommodate the equivalent of the marginal note.
-- GregDo no harm, waste no fortune.
Hi Roger,On 19 October 2011 17:36, Friedman, Roger (CDC/CGH/DGHA) (CTR) <rd...@cdc.gov> wrote:Greg --
I'm familiar with the idea of LIMS and the specific LIMS which you describe, as well as a number of other proprietary and open source efforts (after all, I had to learn this stuff somewhere). As Saptarshi noted, there are significant failures of openness in the open source products.
This was in regards to the OpenELIS specifically, where I've had many failed attempts to get their code. The community is also raw. So open-source is not necessarily open all the time. This is one reason why I love OpenMRS so much
Saptarshi initially proposed the Simple Lab Entry module, which merely uses lab orders and obs. The problem from my point of view is that they already have an MS Access system for the lab, and while it may be that they hate it, nonetheless you don't want to retrogress in capability. And if you're going to do anything for the lab, you may as well do it right. I know there are lots of OpenMRS sites that are looking for a more capable lab system, either built into OpenMRS or communicating with it.
I agree with your points and now that I re-read the lab user-story and also asked a few questions to Daniel about the number of technician.After those details, I feel its more comfortable to be with a full-blown LIS system. Daniel says we should build our own LIMS system as none of the existing ones are couchDB-based and since we are going to do all new schema on couchDB, depending on if everyone agrees, we'd extend the lab module as the LIMS system
I do think that a LIMS is necessary, i.e. a specimen-centric system based on lab workflow and quality management. As a result, there are a number of new tables related to specimens and tests and so forth. A good LIMS will interface directly to the instruments, but this is quite time-consuming to architect and develop and frequently not worth the effort in resource-poor areas where the instruments are often out-of-date. For now, the results will still be entered manually.
Yes, LIMS is necessary. What does everyone feel about starting with a lab module and evolving it to be fully functional LIMS system... all as a couchapp??
Initially, I was looking for a sharp system boundary between lab data and clinical data, indeed I contemplated running the lab system in a separate instance of OpenMRS. However, in response to comments, I loosened this constraint to allow the use of patient, provider and order information in place. This made it possible to eliminate the need for messaging, another high overhead task. In the future, we can develop HL7 messaging for orders, patient information and results and then the system will be able to run stand-alone as well as embedded. I also made the quality system separable so that we can get something up and running, but think it's the first priority once we get the workflow and interface right.
All of which is to say that I think there's a need to develop a LIMS module.
Agreed... May be instead of a LIMS module, once we have a fully functional system, even separate system that can be called Raxa-LIMS ??
---
Regards,
Saptarshi PURKAYASTHA
My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
From: Gregory Kelleher [mailto:gr...@kelleher.cc]
Sent: Tuesday, October 18, 2011 11:52 PM
To: Friedman, Roger (CDC/CGH/DGHA) (CTR)
Cc: Friedman, Roger (CDC/CGH/DGHA) (CTR); Saptarshi Purkayastha; Daniel Pepper; Surajit Nundy
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
Bika, Labkey and LabMatica are listed in the following on-line guide as having open source LIMS'.
-- Greg
Do no harm, waste no fortune.
On Oct 18, 2011, at 11:02 PM, Gregory Kelleher <gr...@kelleher.cc> wrote:
Roger,
It's pretty clear to me from the discussion that the lab needs a system built for lab management by developers familiar with the workflow of a medical lab. Such systems (called 'LIMS') can not only help technicians follow best practices but are often fitted with lab equipment interfaces so the can monitor, control, and read results from analytical devices (they can "chip-in", if you like).
I'm sure we can find open-source LIMS. Our time would be better spent, and JSS better served, if we searched for a system with a good fit rather than trying to rebuild this wheel. BTW, if we were to undertake this task, we'd find that neither CouchDB nor OpenMRS would be the right platform.
-- Greg
Gregory Kelleher
Begin forwarded message:
From: Gregory Kelleher <gr...@kelleher.cc>
Date: October 20, 2011 7:34:58 PM EDT
To: "Friedman, Roger (CDC/CGH/DGHA) (CTR)" <rd...@cdc.gov>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
Thanks. I was aware of the REST/JSON because I got Ben Wollfe to add it 2yrs ago when we were both in Eldoret. I've been trying to get them to seriously consider implementing enterprise message queues for at least a year. They've been helful in providing excellent examples of system failures to illustrate their need, but when they say messaging is coming it always means to them HL7.They have received donations of MIRTH appliances, but I don't think there's been time to install.
-- GregDo no harm, waste no fortune.
The HL7 feature of OpenMRS comes from the strong HL7/LOINC orientation of the Regenstief Foundation where the project is seated. Infopath data was reformatted as HL7 as a way to get data into OpenMRS but proved to be a problem because it was processed through a queue and didn't show up immediately, so later input methods used the API. Lab data exchange is the current primary use case for HL7.
There isn't a JSON queue in OpenMRS that I know of. The JSON output comes from the REST module GET method and JSON input through the REST module POST method. The only HL7 out is via the lab support module. The currently recommended way is to use MIRTH.
From: Gregory Kelleher [mailto:gr...@kelleher.cc]
Sent: Thursday, October 20, 2011 07:02 PM
To: r.fri...@mindspring.com <r.fri...@mindspring.com>
Cc: Friedman, Roger (CDC/CGH/DGHA) (CTR); sun...@gmail.com <sun...@gmail.com>; daniel...@gmail.com <daniel...@gmail.com>; nun...@gmail.com <nun...@gmail.com>; sharath...@gmail.com <sharath...@gmail.com>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
>> Interlined also...
-- Greg
Thanks for you thoughtful comments, I have interlineated my own below marked **.
From: Gregory Kelleher [mailto:gr...@kelleher.cc]
Sent: Wednesday, October 19, 2011 06:51 PM
To: Saptarshi Purkayastha <sun...@gmail.com>; Friedman, Roger (CDC/CGH/DGHA) (CTR)
Cc: Daniel Pepper <daniel...@gmail.com>; Surajit Nundy <nun...@gmail.com>
Subject: Re: PRIORITY: Prepping for the Stanford Hackathon
Roger, Saptarshi,
You both know more about LIS/LIMS than I do (though I did work in labs 40 years ago).
>> trying to find my golden years...**Hip hip hooray for the over 50s
It seems we agree on the need for a LIMS for the usual reasons and there's no viable open source option. I think we also agree that purchase is not an option and that we should only replace the current program when we are confident that we'd be making improvements in the eyes of the users.
Questions and answers that come to mind, from least to most controversial:
1). JSS needs to build a LIMS;
2). Work, specs and road map require open involvement of lab mgmt and staff who must approve implementation plan;
**Daniel, how would this differ from the rest of the process?
>> I don't know the current process, but I would expect more>> pressure from lab for features and greater expectations,>> as they aren't discovering and evolving with the system but>> get ideas from existing systems.>> One tactic to avoid requirements creep is to add the timeline>> as a dimension, ie, roadmap.
3). An adequate LIMS will generate and persist many times the volume of data interesting to clinicians or researchers, so it's likely to work best as a separate system, providing a service through a standards-based interface.
**There are various scales and scopes of LIMS. I think one of the problems that has impacted LIMS development is scope creep. I think if we focus fiercely on what is needed at the low level of the JSS lab, we can make a contribution. By "needed", I refer to meeting information requirements for lab quality improvement and certification, as well as accurate receipt of specimens and return of reports. I am even willing to delay lab data exchange so long as we have hooks for it.>> understood, but see bottom insertion.
4). If we are to share data with researchers or the world (via an OpenMRS repository), we need a common or inter-translatable lexicon, so we should start by adopting LOINC (?) for lab orders and reporting. (Are we now in the process of restating the language without ensuring translatability?)
**Unfortunately, there are competing standards in use in different places. The important thing to remember is that these are messaging standards, not data representation standards. So we can have a concept for Whole Blood Count or CD4 Count or Negative. We can also have a map from each of these concepts to an HL7 coding element particular to a messaging partner (map source). In this way we can build an appropriate HL7 message using any desired coding scheme.
>> i'll try to find time to draft a brief (1page including examples) contrasting>> message transport and content standards because this topic is likely to be>> addressed by a broader group at some point.
5). We are all in agreement on the evolutionary approach Daniel describes. However, we may have different recommendations about the starting points. (We can't start with single-cell organisms for all features... As Roger pointed out, for the lab that would be a regression.). If we don't start with some sort of skeleton -- such as a reliable convention for naming/identifying people, places and things -- there won't even be a fossil record to study.
6). We won't need to pay the price (in complexity) for HL7 until JSS exchanges data with a system that requires it.
7). Enterprise messaging (of JSON data) will be the backbone for the mature, maximally efficient JSS EMR and the sooner we implement, the more we'll benefit. (Just a reminder that we haven't had that conversation yet.)
**In my simplest approach, on release of a report the results would simply be moved into the obs table without any intermediation. Once things reach the HL7 level, messaging seems the natural way. Whether JSON or XML or straight ASCII piped into the OpenMRS HL7 message queue need not be decided now.>> if we can preserve simplicity without sacrificing functionality, I'll all for it.
>> [Occam ca. 900 AD?]>> I suspect the team in Eld*r*t implemented HL7 for bragging rights rather than>> for functionality. It's used for lab data:LIMS -> JSON queue -> HL7 queue -> REST -> HL7 queue -> XML -> AMRS>>. and for FormEntry:MS InfoPatch -> XML -> HL7 queue -> XML -> AMRS>> Don't quote me but let's first get this question more context.
The evolving EMR will benefit from the schema-optional, make-as-few-demands -as-possible nature of CouchDB. But we require SOME schema for document matching and just plain coherence. We can also accommodate the equivalent of the marginal note.
**There are different understandings of just how soon JSS will move to Couch. Since I see the lab module as a valuable contribution to OpenMRS and an important reason for my participation, I would like to see it implemented using OpenMRS tables, services, API and REST.
>> I agree on the value and importance of this OpenMRS module. I'd prefer>> 1) the data exchanged with the LIMS be queued or duplicated in such a>> manner that that the separate projects could proceed at their own pace;>> 2) that a direct route from lab to the couchdb record be preserved>> however the results get to OpenMRS.A.>> That should be achievable and provides greatest flexibility for JSS and>> future adopters: OpenMRS only, CouchMRS only, both together>> and preserves fault-tolerance and avoids a latency hit.[