RM ideas to deal better with orders, workflow, panels, order sets

[Thomas Beale]

A problem the community has been looking at in openEHR for some time is 
how to deal clearly with order-related meta-data (typically: requestor 
and receiver ids of various sorts). The topic of 'orderables' has been 
mentioned in some recent discussions in CIMI 
, and 
as a result, some model changes proposed. One is the addition of an 
'ENTRY_GROUP' class. A similar idea may be useful in openEHR. The 
problems it could address include the following:


 * provide a clear place to put order-related information
 * better match for Panel/Analytes in Lab data
 * provide a container structure that matches Order Sets

See this page 
with 
some modelling ideas on this topic.


- thomas

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: RM in OWL

[Erik Sundvall]

The master thesis of Roland Hedayat could also be of interest in this
context, see
http://www.diva-portal.org/smash/get/diva2:310787/fulltext01.pdf

Copy of abstract text below.

Best regards,
Erik Sundvall

Abstract

Semantic Web Technologies in the Quest for Compatible Distributed Health
Records

Roland Hedayat

There is a proliferation of patient bound Electronic Health Record (EHR)
data in systems that are incompatible - challenging the goal of granting
authorized access to the accumulated medical history of a patient, whenever
requested, and whichever the source, in order to secure a safe treatment.

A common semantic representation is a prerequisite for validating
the semantics of one EHR system against another. Therefore, assessing the
semantic compatibility between systems implies having a formal method for
extracting their semantics, and for validating the consistency of their
combined semantics. A guiding hypothesis is that Semantic Web Technologies
and Ontology Web Language (OWL) are potential bridging technologies between
the EHRs and medical terminologies, and can be used to represent the
combined semantics of the systems to be integrated. Furthermore, that
automatic reasoners can perform semantic validation of the combined
subsystems.

Some experimental steps in this direction are taken, preceded by a
discussion on Medical Terminologies, Ontologies, EHR-systems and their
interrelationships, and a summary overview of Description Logics, the
Semantic Web and the Web Ontology Language, OWL.

The OpenEHR reference model is transformed from an XML-schema
representation to OWL, and a couple of archetypes are transformed into OWL
in a manual procedure. Subsequently, validation runs with a formal reasoner
on the transformed results were performed, demonstrating the feasibility of
the process.

The problems of EHR semantic interoperability are complex. Awareness of the
necessity of applying formal semantic methods when dealing with inherently
semantic problems will catalyze the process of solving them.

Handledare: Daniel Karlsson

Ämnesgranskare: Hans Åhlfeldt

Examinator: Anders Jansson

IT 10 007

onsdag 13 juli 2016 skrev Matheus Wichman :

> I uploaded my ontologies to a Git repository, you can download here
> https://bitbucket.org/uhospital/openehr-rm.
>
> Yes, my approach to handle generics was to create a specialized version
> for every possible T type. For example, to create a DV_INTERVAL locked to
> DV_QUANTITY I would subclass DV_INTERVAL adding a restriction so lower and
> upper properties only accepts DV_QUANTITY values.
>
> My other problem was with lists. The OWL language doesn't have a
> construction for data containers, only RDF do (through rdf:list). I tried
> to use a linked list like described here
> 
>  but
> I would not be able to create inferences. Currently, lists are represented
> just with multiples values for a single property.
>
> 2016-07-13 4:03 GMT-03:00 Seref Arikan  >:
>
>> Hi Matheus,
>>
>> I'd be interested to hear about your problems. I'd also be curious to
>> learn how you handled generics/parameterized types. Unless one defines a
>> meta layer in owl with semantics for generics, I guess the only option is
>> to materialize every possible type parameter T to its own type.
>>
>> All the best
>> Seref
>>
>>
>> On Tue, Jul 12, 2016 at 7:26 PM, Matheus Wichman <
>> matheus.wich...@gmail.com
>> > wrote:
>>
>>> Hi Seref,
>>>
>>> The ontologies available on the link you posted were developed using an
>>> old specification of RM.
>>>
>>> I converted the current RM to OWL, like Isabel did. However I had some
>>> problems to represent list structures.
>>>
>>> 2016-07-12 13:02 GMT-03:00 Seref Arikan <
>>> serefari...@kurumsalteknoloji.com
>>> >:
>>>
 Greetings,

 I was wondering if there is any projects out there that provide an OWL
 version of the RM.

 I found this page: http://trajano.us.es/~isabel/EHR/ where an OWL
 version is kindly provided, though I'll need to get in touch with the
 author to clarify the terms and conditions of use.

 There are papers out there that use an OWL representation of archetypes
 etc but I could not find any RM representation other than the link above.
 Any pointers would be appreciated.

 Cheers
 Seref

 ___
 openEHR-technical mailing list
 openEHR-technical@lists.openehr.org
 

 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

>>>
>>>
>>>
>>> --
>>> Atenciosamente,
>>>
>>> Matheus Wichman
>>>
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>> 
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> ___
>> openEHR

Re: initial states for instructions / when do we need actions?

[Thomas Beale]

Hi Pablo

can you raise a PR for this, with some summary of the changes you think 
are needed?


thanks

- thomas


On 14/07/2016 05:16, pablo pazos wrote:
Hi Heath, thanks for taking the time to answer, this is really useful 
and I think your comments should be included in the specs as examples 
of how the instruction/action interaction and the effect of that 
interaction on the ISM should work.


First it makes total sense for me to have INITIAL as the current state 
when no ACTION was recorded for the INSTRUCTION. And it also makes 
sense to include a "placeholder" ACTION (might not have much info but 
the next state) for INSTRUCTIONS that need to be on PLANNED when the 
INSTRUCTION is created (like the medication case).


About 3.1 I was thinking of a case where the event of creating the 
INSTRUCTION also includes the coordination/scheduling of ACTIONs that 
will be performed. I think this is just another case of my previous 
paragraph: we need an ACTION to change the state to SCHEDULED.


Thanks a lot!

--
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com 


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org