Entities & Relationships within the EHR
Many thanks for your responses Heath and Thomas. Please see below
On 05/09/2012 05:02, Thomas Beale wrote:
> On 04/09/2012 18:05, Heath Frankel wrote:
>>
>> Anthanasios,
>> What we have Don in research based projects is use a persistent
>> composition to record the cohort that the subject belongs too.
I was thinking of something similar with a list of some form of ID as an
Archetype but it looks a bit like a hack because these IDs would not
make sense if they were to be transferred outside of a system.
This is why i thought that if we are talking about a graph based openEHR
model it would probably be better to formalise the edges.
From the look of things, different sets of entities will be required to
deal with domain variations. Everyday clinical practice uses one set,
Clinical Trials will probably require a different one. Formalising those
links between these entities would allow both to co-exist.
Realising the links themselves is not difficult but if at some point you
would like to constraint things like:
*) No self connections are allowed (reasonable / easy)
*) Given Entities [A,B,C,D,E], A can only connect to [B,C]
Then some form of "Relationship Template" would be required.
>> It
>> could be done using demographics where we have a registration
>> relationship associated with the party but when you want population
>> query on the ehr data you don't want to be doing a lookup on
>> demographics to find the members of the cohort.Using this approach we
>> didn't need to provided a hard link between an particular composition
>> and the cohort as we were able to use aql t determine cohort
>> membership and the composition template of interest was enough. But of
>> you do need a hard link for some reason then as Thomas suggested links
>> would be one way to do it, which allows a type property on the link.
>> An archetyped DV_EHR_URI element value is another way that has been
>> used mainly because it is supported by the archetype editor but I find
>> this a softer link which is harder to implement queries against
>> because it is not an intrinsic part of the RM.
>> Personally I think the locatable_ref class is a more computable
>> structure since you don't need to parse the URI and account for the
>> variations of absolute/relative URIs and latest or specific versions,
>> to extract the object id to retrieve the object to traverse the path.
>> Perhaps a more restful implementation would work better with URIs.
>> Problem is locatable_ref is only used in one place in the RM, not sure
>> why this instruction details link was handled different.
My main worry with anything that is not a hard link is that somehow the
IDs will get into a mess and that would disassociate everything or that
different organisations will agree to different patterns and then you
would not be able to exchange anything. The same applies to Folders. I
think Folders are purely cosmetic. Not to be used as sets.
Why not look up the demographics? Would that make the query too complex
and slow? So far, if something is already provided by openEHR i attempt
to re-use it that's why i would set-up Clinical Trial groups through the
Demographics package.
>> All this is implentation specific and we need to find a logical best
>> practice, which I think is link since there is no restrictions where
>> it can be used, but this is also it downside until we understand how
>> to constrain, validate and query links efficiently.
LINK Templates on the horizon? :)
> A conversation that came up today at Intermountain was that their LINKs
> ('Associations') can be a) written to the EHR separately from other
> things, and b) contains both a source pointer and N x target pointers.
From my (limited) experience that's the most common relationship. That
makes the graph directed and is general enough (Reciprocal connections
just need two edges)
> In openEHR the LINK is a bit anaemic, with only a single target
> reference. Adding it separately to the EHR is not hard, that's just a
> question of where, and creating new version of something, which may be a
> dedicated COMPOSITION to hold LINKs to other things, but then if you do
> that, you might as well just use DV_EHR_URIs. The 13606 LINK has target
> as a Set.
The Set is a better alternative (than nothing) but sometimes you might
also need a List. If i am retrieving a patient's Data Collection
Sessions for a specific Arm in a Trial then i can add something like
"order by date" and get them in the right order. There might be cases
where you need order but there is no obvious key to use other than the
order by which the data was entered.
All the best
Athanasios Anastasiou
Entities & Relationships within the EHR
Anthanasios, What we have Don in research based projects is use a persistent composition to record the cohort that the subject belongs too. It could be done using demographics where we have a registration relationship associated with the party but when you want population query on the ehr data you don't want to be doing a lookup on demographics to find the members of the cohort. Using this approach we didn't need to provided a hard link between an particular composition and the cohort as we were able to use aql t determine cohort membership and the composition template of interest was enough. But of you do need a hard link for some reason then as Thomas suggested links would be one way to do it, which allows a type property on the link. An archetyped DV_EHR_URI element value is another way that has been used mainly because it is supported by the archetype editor but I find this a softer link which is harder to implement queries against because it is not an intrinsic part of the RM. Personally I think the locatable_ref class is a more computable structure since you don't need to parse the URI and account for the variations of absolute/relative URIs and latest or specific versions, to extract the object id to retrieve the object to traverse the path. Perhaps a more restful implementation would work better with URIs. Problem is locatable_ref is only used in one place in the RM, not sure why this instruction details link was handled different. All this is implentation specific and we need to find a logical best practice, which I think is link since there is no restrictions where it can be used, but this is also it downside until we understand how to constrain, validate and query links efficiently. Heath On 04/09/2012 8:26 PM, "Athanasios Anastasiou" < athanasios.anastasiou at plymouth.ac.uk> wrote: > Hello everyone > > I am coming across an openEHR use case for which there seem to be more > than one ways to deal with and that i would appreciate your help with. > > The main question is this: > When creating COMPOSITIONs that describe Template(able) stand-alone > entities that are well defined and should have clear relationships with > each other, is it a good practice to include "ID"s and references in order > to establish these relationships? > > A representative example: > In a Clinical Trials setting, there exist entities that should have clear > relationships with each other in order for queries to return properly > structured data that can later be used in analysis. > > For example, a COMPOSITION describing a "Site" should have a harder way of > linking it to the "Trial" than simple membership to the same EHR Folder > (The naming of the Folder will become an issue). > > All the same, the most interesting COMPOSITION, the one that contains the > data collected, should have a hard way of referencing [the "Trial", "Site", > "Stage", "Research Staff performing the data collection"] or other entity. > > Some of these relationships are already there (A Trial Group (e.g. Control > / Condition A, B, C), can possibly be expressed via the entities in the > Demographics package) and i suppose that it is advisable to use them but > what about describing new relationships? > > Looking forward to hearing from you > Athanasios Anastasiou. > > P.S. Do you think that it would be beneficial to add an > "OBJECT_RELATIONSHIP" entity to the Content package just like the > "Party_Relationship" of the Demographics Package? This would completely > describe relationships between entities (source, target, ordering, > multiplicity,...). In this way, we could even do away with the "strict" > tree organisation of the EHR and express the whole storage as a graph of > Template(able) entities interconnected with (proper) > "OBJECT_RELATIONSHIP"s. What do you think? > > __**_ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120905/c7e6cd6d/attachment.html>
HL7 opens up
I think I have read they want to move to a more W3C kind of model: if you want the standards you can use them, but if you want to contribute to their development you still have to be an HL7 member 2012/9/5 Dr Lavanian : > Dear All, > I have been asking for more than 2 years for HL7 to become simplified and > free- to-use, so that it could proliferate globally. So this is good > news.however I still await details. Like - (1) what is free, (2) how > long is it free, (3) what does 'free' really mean, (4) how soon will it > become free(time lines) and (5) what are the rules for commercial use and > localisation . > It is V2.x that especially needs to be made free as this is the version that > is the real work horse. > > There is also a related issue. How will this effect HL7 membership fees - > for members and franchisees. > > With warm regards, > > Dr D Lavanian > MBBS,MD > CEO and MD > HCIT Consultant > www.hcitconsultant.com > www.telemedconsultant.com > > Certified HL7 Specialist > Joint Secretary - Indian Association for Medical Informatics > Co-Chair, Memberships - HL7 India > Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth > > Former Vice President - Healthcare Products, Bilcare Ltd > Former Vice President - Software Division, AxSys Healthtech Ltd > Former Co-convener Sub committee on Standards , Government of India, Task > force for Telemedicine > Former Vice President - Telemedicine (Technical), Apollo Hospitals Group > > For useful updates in Healthcare IT, visit us at > www.facebook.com/HCitConsultant and 'friend' us. > > HL7, DICOM, ICD 10, HIPAA 5010 - strategy, training, implementation > The Right Solution, at the Right Time, at the Right Place and at the Right > Price >Call us Right Now! > > - Original Message - From: "Bert Verhees" > To: "For openEHR technical discussions" > > Sent: Wednesday, September 05, 2012 3:14 AM > > Subject: Re: HL7 opens up > > > On 04-09-12 20:06, Diego Bosc? wrote: >> >> The big question is, how does it affect us? > > > HL7 is primary a way of messaging. In the Netherlands HL7 is very > important, as message format. All (I mean ALL) the underlying systems > which create the messages have legacy datamodel-storage. > There is no such thing as an HL7v3 storage system on the dutch market. > > Also an OpenEHR system can create HL7 messages, especially those > message-definitions which are created for the Netherlands, which are > created with focus on interoperability, to get all the legacy-systems > possible to join. > > So, I see no big change for the Dutch market. Anyway, costs were never > an issue. > > HL7 is also a storage concept, and I have been to some HL7-meetings, > where they discuss these kind of things. > > Without any hesitation, I saw people admiring HL7 systems which needed > 50 to 100 tables to store their thing, and which auto-created > SQL-statements from 250!!! lines to query the thing. > > That is not my way to go, especially if the purpose is interoperability > by creating the specially defined RMIM-messages, which are written with > focus on legacy to incorporate in the messaging-EPD. > > As I know the market in the Netherlands, I know it well, my expectation > is that legacy will dominate the progression next ten years, or even longer. > > We even have systems which are just five years ago ported to 32 bits > Windows (from 16 bits), and still use an old fashioned API-based > database. This is one of the richest healthcare-environments in the world. > > That is what is going on. > > So HL7 for free, nice, we can conform to the message-definitions for > free, and if system-builders succeed in free themselves from their > academic way of software-constructing and legacy and can use HL7 > constructs to store their data quick, they have an easy way for creating > the messages. > > (Hey HL7 folks, the secret for you is XPath, oops, now I gave away the > secret.) > > Fine. Let a thousand flowers bloom. > > When we are confident in our own software, there is nothing to fear from > HL7. > > That is my opinion. > > kind regards > Bert Verhees > > > >> >> 2012/9/4 Timothy Cook : >>> >>> Finally: >>> http://www.hl7.org/about/faqs/FreeIP.cfm >>> >>> >>> >>> -- >>> >>> Timothy Cook, MSc +55 21 94711995 >>> MLHIM http://www.mlhim.org >>> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook >>> Skype ID == timothy.cook >>> Academic.Edu Profile: http://uff.academia.edu/TimothyCook >>> >>> ___ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > _
HL7 opens up
Dear All, I have been asking for more than 2 years for HL7 to become simplified and free- to-use, so that it could proliferate globally. So this is good news.however I still await details. Like - (1) what is free, (2) how long is it free, (3) what does 'free' really mean, (4) how soon will it become free(time lines) and (5) what are the rules for commercial use and localisation . It is V2.x that especially needs to be made free as this is the version that is the real work horse. There is also a related issue. How will this effect HL7 membership fees - for members and franchisees. With warm regards, Dr D Lavanian MBBS,MD CEO and MD HCIT Consultant www.hcitconsultant.com www.telemedconsultant.com Certified HL7 Specialist Joint Secretary - Indian Association for Medical Informatics Co-Chair, Memberships - HL7 India Senior Consultant and Domain Expert - Healthcare Informatics and TeleHealth Former Vice President - Healthcare Products, Bilcare Ltd Former Vice President - Software Division, AxSys Healthtech Ltd Former Co-convener Sub committee on Standards , Government of India, Task force for Telemedicine Former Vice President - Telemedicine (Technical), Apollo Hospitals Group For useful updates in Healthcare IT, visit us at www.facebook.com/HCitConsultant and 'friend' us. HL7, DICOM, ICD 10, HIPAA 5010 - strategy, training, implementation The Right Solution, at the Right Time, at the Right Place and at the Right Price Call us Right Now! - Original Message - From: "Bert Verhees" To: "For openEHR technical discussions" Sent: Wednesday, September 05, 2012 3:14 AM Subject: Re: HL7 opens up On 04-09-12 20:06, Diego Bosc? wrote: > The big question is, how does it affect us? HL7 is primary a way of messaging. In the Netherlands HL7 is very important, as message format. All (I mean ALL) the underlying systems which create the messages have legacy datamodel-storage. There is no such thing as an HL7v3 storage system on the dutch market. Also an OpenEHR system can create HL7 messages, especially those message-definitions which are created for the Netherlands, which are created with focus on interoperability, to get all the legacy-systems possible to join. So, I see no big change for the Dutch market. Anyway, costs were never an issue. HL7 is also a storage concept, and I have been to some HL7-meetings, where they discuss these kind of things. Without any hesitation, I saw people admiring HL7 systems which needed 50 to 100 tables to store their thing, and which auto-created SQL-statements from 250!!! lines to query the thing. That is not my way to go, especially if the purpose is interoperability by creating the specially defined RMIM-messages, which are written with focus on legacy to incorporate in the messaging-EPD. As I know the market in the Netherlands, I know it well, my expectation is that legacy will dominate the progression next ten years, or even longer. We even have systems which are just five years ago ported to 32 bits Windows (from 16 bits), and still use an old fashioned API-based database. This is one of the richest healthcare-environments in the world. That is what is going on. So HL7 for free, nice, we can conform to the message-definitions for free, and if system-builders succeed in free themselves from their academic way of software-constructing and legacy and can use HL7 constructs to store their data quick, they have an easy way for creating the messages. (Hey HL7 folks, the secret for you is XPath, oops, now I gave away the secret.) Fine. Let a thousand flowers bloom. When we are confident in our own software, there is nothing to fear from HL7. That is my opinion. kind regards Bert Verhees > > 2012/9/4 Timothy Cook : >> Finally: >> http://www.hl7.org/about/faqs/FreeIP.cfm >> >> >> >> -- >> >> Timothy Cook, MSc +55 21 94711995 >> MLHIM http://www.mlhim.org >> LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook >> Skype ID == timothy.cook >> Academic.Edu Profile: http://uff.academia.edu/TimothyCook >> >> ___ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
HL7 opens up
Part of the "hl7 fresh look" or just common sense. Anyway,this is the right way if they want global adoption :)The internet/web is the better example of global interoperability, the key?: open standards -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos > From: timothywayne.cook at gmail.com > Date: Tue, 4 Sep 2012 15:02:14 -0300 > Subject: HL7 opens up > To: openehr-technical at openehr.org > > Finally: > http://www.hl7.org/about/faqs/FreeIP.cfm > > > > -- > > Timothy Cook, MSc +55 21 94711995 > MLHIM http://www.mlhim.org > LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook > Skype ID == timothy.cook > Academic.Edu Profile: http://uff.academia.edu/TimothyCook > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120905/1dc06767/attachment.html>
