FYI..
A thought provoking post from John Halamka on decision support providers as service.
http://geekdoctor.blogspot.com/2010/06/decision-support-service-providers.html
Some of you might have complementary/alternative views as to how this might work within an openEHR enabled landscape...
Rong
Would you like to comment?
Your recent work covered some of this key territory..
Regards,
Tony
There is ‘Virtual EMR’ project going on in HL7 do to exactly this sort of work i.e a relatively simple interface/ service against which decision support cab operate consistently - http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR)
The big problem they will face, as ever, is defining the detailed clinical content in a manageable and scalable fashion.
I think the openEHR approach to content definition has definite advantages.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk
Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
Colleagues,
I would like to develop a high level ontology model of the health information and integration platform showing the entities, concepts and their various relationships as a means of enabling us to clearly show what this is all about and to enable us to communicate to non technical people the implications (and limitations imposed) of decisions made regarding the adoption of such a national infrastructure platform. It’s about all the stuff that sits between the hardware and software applications. This area is not well understood by non technical people (including me) yet the term ‘ platform’ is used heavily for marketing purposes by big software suppliers. An ontological model of this domain should serve us well for educational purposes. I’d like to adopt the clinical knowledge artifacts (my generic term for archetypes or detailed clinical models) as central to such a platform as these provide the foundation for all health information and processing needs at the individual, local, organisational, national and international levels.
I would welcome your views on which entities and concepts (and their associated generic names) to include in such an ontological model. At this stage my review of the literature etc has resulted in the following list but I need help in defining these and their relationships in a generic mutual exclusive sense as clearly the adoption of one or more specific entities/concepts influences others either positively or negatively. Many different platforms are in existence but how does one evaluate their completeness, functionality, efficiency, effectiveness, impact on patient safety or outcomes? The terms below are used in non standard ways making it difficult to gain a clear understanding about these from the literature.
Reference information model
Data types
Service Oriented Architectures
Web services
Clinical Knowledge Repository
Terminology server
Clinical modelling tools
Tooling to convert clinical knowledge to machine processable schema or templates
EHR services
Longitudinal EHR services
Technology platform eg .net, java, mobile versions
Middleware products
GUI Standards & frameworks
Identifiers standard
Demographic service
Application development platform
Knowledge management platform
Semantic interoperability
Functions such as authentication of users and applications, guaranteed delivery of messages between components and users, logical connections
Consent management services
I look forward to your comments.
Evelyn
Evelyn J.S Hovenga RN PhD FACS FACHI
Professor & Director eHealth Education Pty Ltd
Director of EJSH Consulting,
PO Box 9783 Frenchville, Rockhampton Qld 4701
Editor in Chief, eJHI http://www.ejhi.net
Adjunct Professor, Victoria University, Melbourne
ACHI Council member
Standards Australia member
e.hovenga@ehealtheducation.net
Mob +61 (0)408 309839
Qld Office Ph. +61 (0)7 4921 3029
Colleagues,
I would like to develop a high level ontology model of the health information and integration platform showing the entities, concepts and their various relationships as a means of enabling us to clearly show what this is all about and to enable us to communicate to non technical people the implications (and limitations imposed) of decisions made regarding the adoption of such a national infrastructure platform. It’s about all the stuff that sits between the hardware and software applications. This area is not well understood by non technical people (including me) yet the term ‘ platform’ is used heavily for marketing purposes by big software suppliers. An ontological model of this domain should serve us well for educational purposes. I’d like to adopt the clinical knowledge artifacts (my generic term for archetypes or detailed clinical models) as central to such a platform as these provide the foundation for all health information and processing needs at the individual, local, organisational, national and international levels.
I would welcome your views on which entities and concepts (and their associated generic names) to include in such an ontological model. At this stage my review of the literature etc has resulted in the following list but I need help in defining these and their relationships in a generic mutual exclusive sense as clearly the adoption of one or more specific entities/concepts influences others either positively or negatively. Many different platforms are in existence but how does one evaluate their completeness, functionality, efficiency, effectiveness, impact on patient safety or outcomes? The terms below are used in non standard ways making it difficult to gain a clear understanding about these from the literature.
Reference information model
Data types
Service Oriented Architectures
Web services
Clinical Knowledge Repository
Terminology server
Clinical modelling tools
Tooling to convert clinical knowledge to machine processable schema or templates
EHR services
Longitudinal EHR services
Technology platform eg .net, java, mobile versions
Middleware products
GUI Standards & frameworks
Identifiers standard
Demographic service
Application development platform
Knowledge management platform
Semantic interoperability
Functions such as authentication of users and applications, guaranteed delivery of messages between components and users, logical connections
Consent management services
If you look at the domain model on which the vMR is designed (http://wiki.hl7.org/index.php?title=Image:HL7vMR_vMR_Domain_Analysis_Model_v2010-03-22.zip) you will see that it is a very fixed model of clinical concepts. I am not sure how they expect that queries for changed versions of these concepts or different concepts be done. The vMR job is actually the kind of thing openEHR is really designed to do well, with the following elements:
standard reference model
standard way of representing any clinical or other domain concept - archetypes & templates
standard way of querying the data - AQL, a-path or other archetype-based approaches
service interface for making fine-grained changes to data (some specification proposals at http://www.openehr.org/wiki/display/spec/vEHR+Service+Specification)
GELLO or something similar then has a place ‘above the line’ for representing guidelines that need to be executed against the EHR.
thomas beale
Hi Thomas,
I am now back at Duke in a full time capacity. The work within HL7 is
being lead by Ken Kawamoto from Duke, a colleague of mine. Duke has one fo
the best clinical research enterprises in the world - the Duke Clinical
Research Institute and the new Duke Translational Medical Institute, where
the Duke Center for Health Informatics is based. We have asignificant
weffort committed to defining detailed clinical content. I'd say let's
postpone the decision (as ever) for a couple of years and see if we are as
bad as you think.
Actullay, we have an effort similar to Evelyn's and look forward to working
with her.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
<thomas.beale@oce
aninformatics.com To
> openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: Decision Support Providers
06/26/2010 11:57
AM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
Hi Ed,
I didn’t say it was bad (it is probably very good) - I said it was ‘fixed’. Like CCR - which as far as I understand is very good domain modelling - but also pretty fixed. The debate here is about ‘how’ not ‘what’. If I was working on the vMR in HL7 right now, the first thing I would do would be to copy exactly the content you have modelled in the diagram I referred to - in to archetypes and templates. Then I would get for free:
regards
Actually, my e-mail was more of a hello. I didn't think you were giving
Duke a hard time. Our approach is similiar to what you are doing, however,
we are focusing at the atomic level. Building from that is simply a
construct. It will be i nteresting to find out what stays packaged and
what breaks out. My approach is to make the data independent of the
construction. If the data element is never dealth with without thw full
structure we will keep it packaged; else not. I think we let our
experiences influence how we move forward. But as you know, I try to pay
attention to what everyone is doin g so I can use the best approaches.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
<thomas.beale@oce
aninformatics.com To
> openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: Decision Support Providers
06/26/2010 04:16
PM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
Hi Ed,
I didn't say it was bad (it is probably very good) - I said it was 'fixed'.
Like CCR - which as far as I understand is very good domain modelling - but
also pretty fixed. The debate here is about 'how' not 'what'. If I was
working on the vMR in HL7 right now, the first thing I would do would be to
copy exactly the content you have modelled in the diagram I referred to -
in to archetypes and templates. Then I would get for free:
the ability to change it with no changes to any reference model
(information remains valid)
the ability to add completely new things, also without requiring any
changes in the underlying information model
the ability to query everything in a generic fashion using queries
based directly on the domain models
This argument is the same as with all the *MIMs in HL7 - as a technology I
don't think they work, but I don't question their content (in most cases I
am not competent to do that). I would really love the opportunity to show
you how nice this model could be if modelled in archetypes in an openEHR
system. You would get just what you want with much greater flexibility.
Please don't think I would seriously question Duke's clinical work. I just
think you are working with the wrong IT;-)
regards
- thomas
Hi Evelyn, what a fantastic initiative…I am really quite disturbed how these fundamental terms are being used inconsistently. Here are the most difficult ones for me:
Clinical model (can be a model patient for med students! If context is not given)
Clinical information model (originally this refers to knowledge artifacts as you say but that is difficult to comprehend by non-openEHR/13606/HL7 aware people. This is commonly mistaken for RIM)
Concept model (too generic)
Clinical concept model (not too bad – but doesn’t say much about the nature of modelling)
Ed,
this is an interesting technical point. One key aspect of the archetype approach is the heavy use of dependable paths through the data for querying. It means you can always get to the finest grain item, regardless of whether the data stay as a ‘package’ or not. This is the kind of flexibility that I think would be useful in your environment.
I generally agree. However, I thin k it depends on the higest level to
which the archetype is defined. Some are carrying architypes to a complete
collection of data for a disease encounter, any encounter and a medical
record. Obviously some data elements would appear in more than one
archetype. I view archetypes as more for data collection and some data
presentations rather than an architectural model for the EHR, although in
some cases I would keep the data bundled. In any case, navigation of the
database is the issue.
I have left my emeritus status and returned to full time at Duke. I am the
Director of the Center for HEalth Informatics which involves both teaching
a informatics research. My time with HL7 will probably be limited. My
focus will be more on standards for the clinical commun ity.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
<thomas.beale@oce
aninformatics.com To
> openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: Decision Support Providers
06/27/2010 06:00
AM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
Ed,
this is an interesting technical point. One key aspect of the archetype
approach is the heavy use of dependable paths through the data for
querying. It means you can always get to the finest grain item, regardless
of whether the data stay as a 'package' or not. This is the kind of
flexibility that I think would be useful in your environment.
- thomas
Now you are getting into archetypes and templates. Templates are used to
a) choose archetypes to be composed to make larger structures from
smaller re-usable pieces b) to remove those data points not needed in
the larger structure, i.e. for the use case at hand (could be most data
points and c) to further constrain remaining data points to e.g.
mandatory, or reduced terminology subsets etc. A template in ADL 1.5
(forthcoming specification) is just a specialised archetype, and the new
generation of tooling will be able to treat it as such. A new release of
the ADL Workbench will appear in the next week or so, demonstrating ADL
1.5 archetypes and templates.
There is of course a remaining wider discussion about 'standards' and
what they can possibly mean, and how we can improve them.
regards
- thomas
Agreed. We do use different words for the same and different things. I
still use the words compound data types and complex data types resulting
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Thomas Beale
<thomas.beale@oce
aninformatics.com To
> openehr-technical@openehr.org
Sent by: cc
openehr-technical
-bounces@openehr. Subject
org Re: Decision Support Providers
06/27/2010 09:11
AM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
Now you are getting into archetypes and templates. Templates are used to
a) choose archetypes to be composed to make larger structures from
smaller re-usable pieces b) to remove those data points not needed in
the larger structure, i.e. for the use case at hand (could be most data
points and c) to further constrain remaining data points to e.g.
mandatory, or reduced terminology subsets etc. A template in ADL 1.5
(forthcoming specification) is just a specialised archetype, and the new
generation of tooling will be able to treat it as such. A new release of
the ADL Workbench will appear in the next week or so, demonstrating ADL
1.5 archetypes and templates.
There is of course a remaining wider discussion about 'standards' and
what they can possibly mean, and how we can improve them.
regards
- thomas
I generally agree. However, I thin k it depends on the higest level to
which the archetype is defined. Some are carrying architypes to a
complete
collection of data for a disease encounter, any encounter and a medical
record. Obviously some data elements would appear in more than one
archetype. I view archetypes as more for data collection and some data
presentations rather than an architectural model for the EHR, although in
some cases I would keep the data bundled. In any case, navigation of the
database is the issue.I have left my emeritus status and returned to full time at Duke. I am
the
Director of the Center for HEalth Informatics which involves both
teaching
Thanks Evelyn,
You're not afraid of a "grand challenge" then.. ;o)
Without going into any detail, the distinct areas that I would describe as;
#Information management -specific to a patient patient (eg EHR for
patient with Chest Pain and Diabetes)
and
#Knowledge management - agnostic of a patient patient (eg passive/active
Decision Support for management of Chest Pain/ Diabetes)
..are poorly understood with most people, often knitting them together
in their thinking and solutions.. is a key area where this could help..
Kind 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
Koray Atalag wrote:
Thanks Tony. I have always tried to be open to the best solutions to my
problems. Frequently it is a combination of resources. Of course, we also
have a lot of local debbates and discussions.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Tony Shannon
<tony.shannon@nhs
.net> To
Sent by: For openEHR clinical discussions
openehr-technical <openehr-clinical@openehr.org>
-bounces@openehr. cc
org "openehr-technical@openehr.org"
<openehr-technical@openehr.org>
Subject
06/28/2010 08:39 Re: Decision Support Providers
AM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l@openehr.org>
Thanks Ian,
Glad to see Tom and Ed's debate on this in the technical list.
Ed,
Sounds like your taking a "support the frontline/bottom-up innovation"
approach to solve Dukes Informatics Challenges, which I think is a
critical element needed for success here..
While I instinctively share Ian and Toms view that openEHR will offer a
more agile approach to scaling and maintaining the clinical content
management in the long term.... openEHR needs to have more working
examples of effective decision support in the action within the
ecosystem to prove that point...
Time will tell what the right level of granularity is needed for
archetypes/compound data types.
Any lessons from the Duke frontline that you can share with us on that
issue would be valuable I'm sure..
Kind 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
Ian McNicoll wrote:
There is 'Virtual EMR' project going on in HL7 do to exactly this sort
of work i.e a relatively simple interface/ service against which
decision support cab operate consistently -
http://wiki.hl7.org/index.php?title=Virtual_Medical_Record_(vMR)The big problem they will face, as ever, is defining the detailed
clinical content in a manageable and scalable fashion.I think the openEHR approach to content definition has definite
advantages.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com <
mailto:ian.mcnicoll@oceaninformatics.com>
ian@mcmi.co.uk <mailto:ian@mcmi.co.uk>
Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org
<http://www.phcsg.org> / BCS Health ScotlandFYI..
A thought provoking post from John Halamka on decision support
providers as service.
http://geekdoctor.blogspot.com/2010/06/decision-support-service-providers.html
Hi Tony,
I take the challenge to comment 
We start to see this kind of CDS services emerging now in Sweden.
Web-services based drug interaction check is a good example of this.
The difference is that the content (drug database) is available to the
users. So it's not really a black-box. I doubt that a black-box CDS
implementation will be very popular among the clinicians.
I also think remote-service based CDS for raising single
alerts/reminders can be useful in some limited scope but will not
scale up to provide more comprehensive CDS functions. I am more in
favour of developing CDS content based on standardised EHR models so
CDS applications can be implemented directly within EHRs.
We start to exploring representing clinical guidelines using openEHR
archetypes/templates and rules. Using EHR models to represent
guidelines could give several potential benefits: 1) reuse of existing
EHR content models as building blocks of guidelines; 2) increase
interoperability between CDS applications and EHRs; 3) facilitate
guideline compliance checking.
More details can be found in our MIE2009 paper:
http://www.imt.liu.se/~ronch/MIE2009_Representing_Lymphoma_Guideline_5page_v3.pdf
Cheers,
Rong
Many thanks Rong,
The approach you outline which reuses archetypes and templates from EHR
models resonates as a logical way to tackle this.
John Halamka mentions in his blog...
"Thus, Anvita has defined clinical decision support (CDS) standards to
transmit decision support recommendations from the service provider back
to the EHR. I am unaware any widely implemented standards that do this
today. "
Can you comment on his quote/article?
Also can you say some more about the rules element of your work..
Many thanks,
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
Rong Chen wrote:
Hi Rong,
I am also interested to hear a little more about your thoughts on further development.
Since guidelines, ordersets and protocols all represent the optimal path fora notional patient, and will interact with the record for that patient, it makes sense to base the patient data aspects on the same structures as the actual patient data.
In particular I would be interested to know your thought on how much additional metadata / ref model support might be required to support simple ordersets based on openEHR archetypes properly, leaving the more complex rules requirements to the side for the moment.
By orderset, I mean a simple collection of related instructions or requests for a common clinical scenario, such as ‘Suspected MI’.
As well as the traditional static orderset and UI dialog, I am interested in driving data entry from such a typical ’ clinical scenario’ but in more of a narrative fashion. i.e start from a blank page and build up content from the scenario, some being Instructions, others observations and evaluations. I have had some experience of a real, if rudimentary, implementation and it seemed popular with clinicians. My interest in openEHR originally arose from looking for a generic information model to support this approach.
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
ian@mcmi.co.uk
Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group
Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland
Many thanks Rong,
The approach you outline which reuses archetypes and templates from EHR
models resonates as a logical way to tackle this.
Though it was redesigned to use CDA in order to hopefully gain
acceptance with vendors EGADSS was originally designed (by me) for use
with archetypes and templates. The implemented concepts and possibly
the source code could be reused.
http://egadss.sourceforge.net/
HTH,
Tim
Hello Tim,
are you aware of any deliverables that can be downloaded and
test-driven ? I haven't been able to find much by browsing
the site(s) and googling.
The specification docs are nice, though !
Karsten