On 20/01/2015 02:19, pablo pazos wrote:
> Just for the sake of discussion,
>
> See slides 22 and 23:
> http://www.healthit.gov/sites/default/files/c-cda_and_meaningfulusecertification.pdf
>
> "As disparate SDOs (HL7, IHE, HITSP, etc.) developed CDA IGs, multiple
> approaches for documenting template requirements began to diverge
> threatening interoperability?"
>
> IG = Implementation Guide
>
> So my wild guess is they created a new artifact with the same problems
> the current artifacts have, like the need for an IG, instead of doing
> a little research and find a better solution like using archetypes to
> model and "consolidate" CDA templates.
>
> Does anyone know more about CCDA? Do you think this is a good area of
> work for openEHR in the US? I mean, maybe we (as a community) can
> propose an openEHR-based solution or make some kind of statement, for
> documental consolidation than having another implementation guide +
> CDA templates.
>
technically speaking, the main problem with CDA is its lack of easy
computability. Like other message-based 'models', A CDA template is a
manually defined model of some content, expressed directly in a concrete
implementation format, namely a specific kind of document XSD, which
imposes all kinds of RIM-originated features. It also lacks any
equivalent of the archetype /template separation, i.e. re-usable
components, as well as any easy way to semantically query data based on
it, other than devising ad hoc Xpath-based queries.
In openEHR - far from perfect itself as we know - I believe we have
achieved some useful architectural principles, namely:
* *Abstract modelling*: we build models of domain content in a
format-independent representation - this allows domain specialists
to directly do the modelling in a way unknown outside of openEHR
* *Model re-usability and componentisation*: the modelling formalism
has re-use built-in - componentisation (slots, ext-refs),
inheritance, and templating
* *Single-source modelling*: we can machine-generate
implementation-specific representations of these models into any
number of formats - we already do this into XSDs and 'template data
objects' (one of the jobs this year in the specifications work is to
publish specifications of these transforms); some very good UI
generations exist today; it has also been done even with a CDA
target in the past. I believe we can get very close to doing it FHIR
as the target.
With this we get a lot more flexibility - what many people know of as
'standards', in openEHR, we treat as the output of the machine
generation step. So openEHR is designed more like a standards generator,
than a standard itself.
We are not the only ones to do this. There is an almost identical
mentality at Intermountain Health historically, and the only reason it's
less visible on the global stage is to do with corporate IP issues. But
look at clinicalelement.com <http://www.clinicalelement.com/#/> - these
are their equivalent of archetypes and templates. They have internal
tools that compile these into concretely usable schemas, code, and other
artefacts. Over the years, they have had to change suppliers (they now
have Cerner, previous GE) and products, but those models remain the
statement of semantics - they just have to rewrite the generators.
The reason CIMI <http://opencimi.org>is coming together (however slowly)
is that this general approach does work. In CIMI, we will publish
openEHR and Intermountain models in ADL 2.
The MDHT project in OHT is the other effort I know of built on the
single-source modelling idea, initially with CDA as the target.
As I said in a blog post
<http://wolandscat.net/2014/12/15/semantic-scalability-the-core-challenge-in-e-health/>,
I think there is no hope for sustainable, scalable 'modelling' of domain
semantics without the separation models and downstream generation.
Manually building the models directly into a specific implementation
format a) compromises the models and b) kills or severely limits any
hope of downstream generation into unrelated formats (because the
abstract semantics are inextricably mixed in with the concrete low-level
semantics / features of the concrete format and/or schema).
Can we make CDA a downstream target? It's certainly technically
possible, although not that easy, because the CDA is RIM-based, and
imposes a lot of tricky attributes that make the mapping definition
difficult. But I believe it is doable. I am not convinced that the US
cares that much, because CDA is mostly used only at level 2, i.e.
structured headings, with text as the content. In Europe, South America,
Australia etc, we tend to use structured data to a much greater extent.
In 2010 (I think) I was at a CDA conference in Scotland attended by
probably 200-300 people from e-health around the UK. Long explanations
of CDA were given by HL7 experts. Someone in the audience said 'but
apart from psychiatry and some anaesthetics etc, most of our data here
are structured - how do we use CDA?' The speaker replied that 'CDA
wasn't really designed for such use'. Now, it has been used in the UK
for some structured data, but it's expensive to make it work, and I
suspect it won't survive, because our main use case here isn't
transmitting narrative hospital notes / summaries - we have vastly more
structure in GP data for example. So I suspect CDA won't find much use
in the long run here in the UK, and I think in Europe it won't be a
dominant approach either.
FHIR will start taking care of resource-level provision of health data
to apps. The FHIR team are doing a great job on sorting out aspects of
how to actually make REST work for health data - exactly the scenarios
discussed on the other thread. But there remains the question of
building all the FHIR resources and profiles, in a sustainable way.
Apart from that, we are still in the business of building other kinds of
interoperability - services for major hospital applications like
medication management, care plans, and so on. doing this properly
requires a different approach than just resources.
- thomas
_______________________________________________
openEHR-implementers mailing list
openEHR-implementers at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150120/3deba37b/attachment.html>
