The one egadds.jar I did find said:
ncq@hermes:~/$ java -jar egadss.jar
Failed to load Main-Class manifest attribute from
egadss.jar
Karsten
The one egadds.jar I did find said:
ncq@hermes:~/$ java -jar egadss.jar
Failed to load Main-Class manifest attribute from
egadss.jar
Karsten
Hi Karsten,
Did you try the big green Download button here? ![]()
https://sourceforge.net/projects/egadss/
HTH
Cheers,
Tim
Ahhh, well in that case you'll need to find someone to debug the issue.
There used to be a running demo server with that version but I guess
funding ran out. You also may try contacting Jeff Buchbinder (Freemed)
about two years ago they were interested in picking up management of the
project so I help facilitate that but I did not follow up.
Cheers,
Tim
Hi Rong,
Thanks for your comments. I've been following this thread for my personal
interest. Briefly a CDS links clinical data (such as clinical observations)
with clinical knowledge (such as guidelines or rules) to assist health
professionals in decision makings.
You indicated that you are in favour of developing CDS content based on
standardised EHR models ... Can you please clarify what CDS content means?
Is it the clinical data, or clinical knowledge, or both?
What're your comments about the approach of using archetypes & templates to
represent clinical guidelines and rules? Did you experience many issues with
this approach?
Cheers,
Chunlan
I did ![]()
Karsten
Thanks, Tony!
I failed to find any mentioned CDS standards (or in fact design
specifications since it's probably not a SDO
published by Anvita.
Perhaps others have better luck. What's interesting here is this is
perhaps yet another example of creating a new 'standard' for the
purpose of CDS.
In the chemotherapy guideline paper, we studied half-dozen well-known
guideline representation formats and concluded that to overcome the
interoperability problem between EHRs and CDSS, guidelines can be
expressed with EHR models directly together with rules and process
definitions. Since both the CDS rule triggering conditions and
recommendations (order sets, dose adjustments, lab requests etc) are
in fact either based on data from EHR or candidate EHR entries, it
seems reasonable to express guidelines with EHR models.
Rules are needed to express guideline logic. The fact that openEHR has
no its own rule language or an ambition to develop one is a very good
thing. This means external rule language can be plugged into openEHR
framework when necessary. Well-established rule engines like CLIPS,
Jess or JBoss Drools are good candidates here. What we need to do in
the openEHR community is to develop a good mechanism allowing rule
plug-ins, e.g. necessary syntax in template/archetype for attachment
of rules.
I will try to document some of our experiences on the wiki in the coming months.
Cheers,
Rong
Hi Ian,
Ordersets are probably a good starting point for further development.
They are less complex than full-blown guidelines, mostly static (no
need for process language) and close to the level of existing building
blocks like medication, lab investigation archetypes.
If my assumption that ordersets are to be expressed on the template
level is correct, we need to make sure it is possible to reuse
templates as building blocks for larger templates (ordersets as part
of careplans), to specialise (further constraining) templates for
local adaptations, and equally important that they are human language
independent (just as archetypes).
Regarding meta-data required by ordersets, I think it's too early to
have conclusions. It's best to leave room for any arbitrary meta-data
in additions to a few mandatory ones (authorship, references,
indication etc).
Later on, after we gain more implementation experiences on ordersets,
we may want to introduce a dedicated RM class ORDER_SET in the ehr
package in order to mandate good designs around ordersets and
facilitate software implementation.
Cheers,
Rong
Hi Chunlan,
We share very similar interest then ![]()
What I meant really is clinical knowledge in the form of
machine-readable formats, more specifically:
1. Orders of medication, lab/imaging investigation requests in the
form of openEHR archetypes/templates;
2. Decision support rules in the form of formal rule language;
3. Process definitions in the form of workflow language for
coordinating guideline steps
4. Queries for triggering CDS events and process steps in the form of AQL
5. Terminology/ontology resources for necessary reasoning in the
background knowledge
Now we can in fact express these artifacts in the form of formal
standards or publicly available specifications backed up by open
source software implementations.
Regarding your question on guidelines, you can probably find some
input from my previous posts.
Cheers,
Rong
Thanks Tim
Sounds like that work was ahead of its time. I hadn't come across it before.
Any key conclusions you drew from that work?
Regards,
Tony
Hi Everyone,
My apologies if you receive this message twice – I got a “message too large” error from the list-serv, so I am re-posting without attachments.
I’m new to the OpenEHR list, but thought I’d comment on this discussion with hopefully some relevant insights.
I am a co-chair of the HL7 Clinical Decision Support (CDS) Work Group, and we have been working on several relevant standards around CDS services. Of note, these standards are based on our operational use of this approach, including for a point-of-care chronic disease management system used by approximately 500 clinicians at Duke University Health System; a population health management system that supports care managers, clinicians, and patients within North Carolina Medicaid; and systems that remotely access our CDS service from Argentina and from Massachusetts.
Below are several standards and resources that may be relevant to this discussion thread:
The HL7 Decision Support Service draft standard, which provides a common functional specification for how CDS services should work:http://www.hl7.org/v3ballot2009jan/html/infrastructure/dss/dss.htm
The OMG Decision Support Service draft standard (soon to be a full normative standard), which was adopted in December 2009 and provides an implementable Web service specification based on the HL7 standard:
http://hssp-dss.wikispaces.com/omg_specification
Of note, both the HL7 and OMG Decision Support Service standards support the use of semantic payloads defined outside of HL7, such as OpenEHR Archetypes.
As the above standards specify interaction models but not the semantic payloads, we are also working on a specification for service input and output data known as the HL7 virtual medical record (vMR) standard. This standard will be compatible with using HL7 v3 information models as the input, but we also intend to allow the use of other sources of data (e.g., CCR, HL7 V2 messages, and hopefully OpenEHR Archetypes). This work is based on an an analysis of CDS data needs across 20 institutions from 4 countries, and it underwent initial balloting last month. More information on this work can be found at the following wiki: http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR). Of note, myself and other members of this project team have been following some of the comments regarding this project posted on the OpenEHR lists, and have found them to be quite helpful and aligned with some of the issues we are grappling with. We are trying to learn more about OpenEHR to see how we can leverage it for this emerging HL7 standard, and we hope to learn more from the expertise available in the OpenEHR community.
A presentation I recently gave that provides an overview of these standards and describes a recently initiatied effort to develop an open-source, IP-free reference implementation compliant with the HL7/OMG Decision Support Service standard. This system will be an evolution from the currently operational CDS service I developed known as SEBASTIAN, with the key differentiators being: (1) full standards compliance, (2) use of an open-source rules authoring, management, and execution environment (Drools), and (3) adoption of an open-source, IP-free model to facilitate collaboration and adoption. I am spear-heading this multi-institutional effort.
http://community.jboss.org/servlet/JiveServlet/download/14964-115-12135/Kawamoto%20K%20–%20CDS%20with%20HL7%20and%20Drools,%20v03.ppt
A recent JAMIA article describing the broader HL7-OMG effort to develop standard service interface specifications for healthcare:
http://jamia.bmj.com/content/16/6/874.abstract
A paper on how this kind of a standards-based, service-oriented approach to CDS could be leveraged to enable personalized medicine in a highly scalable manner. I have a strong interest in this area and am currently supported by the National Human Genome Research Institute to explore how to enable scalable CDS for genomic and personalized medicine.
http://www.biomedcentral.com/1472-6947/9/17
We also have two potentially relevant papers pending e-publication, one analyzing the landscape of standards related to CDS (including for CDS services) and another providing an experience-based analysis of the pros and cons of using a services-based approach to CDS. Once these manuscripts are publicly available, I will plan to post them to the list for reference.
Thanks!
Ken Kawamoto
HL7 CDS Work Group Co-Chair
Project Lead, HL7/OMG Decision Support Services project and HL7 Virtual Medical Record project
Thanks Rong
Tony
Rong Chen wrote:
Thanks Ken,
Its very good to see your work in this area.
Your BMC paper makes a good case for greater collaboration on the
infrastructure required to underpin all the many ambitions that surround
decision support, personalised medicine, links to genomics etc..
Very glad to see your open source reference implementation approach to
the challenge. I think there is much merit in that approach.
You may be interested in Opereffa as a related openEHR effort.
http://opereffa.chime.ucl.ac.uk/
Your openness to openEHR archetypes is also welcome. I think you will
find real value within, have you seen the openEHR clinical knowledge
manager already?
http://openehr.org/knowledge
You may have questions of the list about archetypes..
Rong,
Would you be able to comment on the overlap between your openEHR work on
DSS and Kens..?
Regards,
Tony
Dr. Tony Shannon
Consultant in Emergency Medicine, Leeds Teaching Hospitals
Clinical Lead for Informatics, Leeds Teaching Hospitals
Chair, Clinical Review Board, openEHR Foundation
+44.789.988 5068 tony.shannon@nhs.net
Kensaku Kawamoto wrote: