Composition commit format to EHR
d anyone mix the commit with HL7-like communication info? > >> > >> It would be very nice to know your thoughts, thank you! > >> > >> BTW: for anyone wanting to follow the development and/or contribute: > >> https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: > >> https://www.youtube.com/watch?v=D-hs-Ofb8SY) > >> > >> -- > >> Kind regards, > >> Eng. Pablo Pazos Guti?rrez > >> http://cabolabs.com > >> > >> ___ > >> 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 > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > 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/20140410/ef0e93b3/attachment-0001.html>
Composition commit format to EHR
d anyone mix the commit with HL7-like communication info? > >> > >> It would be very nice to know your thoughts, thank you! > >> > >> BTW: for anyone wanting to follow the development and/or contribute: > >> https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: > >> https://www.youtube.com/watch?v=D-hs-Ofb8SY) > >> > >> -- > >> Kind regards, > >> Eng. Pablo Pazos Guti?rrez > >> http://cabolabs.com > >> > >> ___ > >> 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 > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > 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/20140410/9318552e/attachment-0001.html>
Composition commit format to EHR
d anyone mix the commit with HL7-like communication info? > >> > >> It would be very nice to know your thoughts, thank you! > >> > >> BTW: for anyone wanting to follow the development and/or contribute: > >> https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: > >> https://www.youtube.com/watch?v=D-hs-Ofb8SY) > >> > >> -- > >> Kind regards, > >> Eng. Pablo Pazos Guti?rrez > >> http://cabolabs.com > >> > >> ___ > >> 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 > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > 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/20140410/1ad4e0bc/attachment.html>
Composition commit format to EHR
d anyone mix the commit with HL7-like communication info? > >> > >> It would be very nice to know your thoughts, thank you! > >> > >> BTW: for anyone wanting to follow the development and/or contribute: > >> https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: > >> https://www.youtube.com/watch?v=D-hs-Ofb8SY) > >> > >> -- > >> Kind regards, > >> Eng. Pablo Pazos Guti?rrez > >> http://cabolabs.com > >> > >> ___ > >> 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 > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > 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/20140410/3d76ae3b/attachment.html>
Composition commit format to EHR
d anyone mix the commit with HL7-like communication info? > >> > >> It would be very nice to know your thoughts, thank you! > >> > >> BTW: for anyone wanting to follow the development and/or contribute: > >> https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: > >> https://www.youtube.com/watch?v=D-hs-Ofb8SY) > >> > >> -- > >> Kind regards, > >> Eng. Pablo Pazos Guti?rrez > >> http://cabolabs.com > >> > >> ___ > >> 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 > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > ___ > 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/20140410/5ddccb2a/attachment-0001.html>
Composition commit format to EHR
__ 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/20140410/26960d55/attachment.html>
Composition commit format to EHR
Hi Pablo, I agree with the comments so far questioning whether you really need to store this within the openEHR composition but if you did need to do so, you should have a look at the feeder_audit attribute available to any LOCATABLE node, including the root node of any archetyped data. There is also a lot of information in the 'common' specification document. I suspect you know all this already but others lurking might find it useful! Ian On 10 April 2014 12:30, Seref Arikan wrote: > Hi Pablo, > I may be wrong, but I'm getting the impression that you are considering the > extra data you're talking about as something that is outside the > composition. It can certainly be processed that way, but the openEHR spec > has significant consideration for this type of information. The context, > composer, setting fields of your composition would let you keep a lot of > information. We keep sender system ids etc in these fields regularly. If > this is what you meant, then you may consider asking more specific openEHR > modelling questions, as in, 'how do I represent this hl7 id in a > composition?' etc. If you're talking about some out of openEHR mechanism, > you may not need it, keeping things within openEHR would help you make them > available to queries in a more consistent way plus all the other benefits > where you'd like to have interoperability. > > There is a limit to what you can model within openEHR of course, and if you > start talking about logging etc, then you would probably like to consider > mechanisms which are not necessarily specified in the specs. My personal > opinion is that there is always some non openEHR functionality an > implementer would have to support: audit, some demographics, terminology > services etc. You have to set priorities though as an implementer, add these > things on top of your EHR related functionality as use cases arise. If you > try to develop in advance for everything you can think of you'll have a > lng journey ahead :) > > Best regards > Seref > > > > On Thu, Apr 10, 2014 at 12:04 AM, pablo pazos > wrote: >> >> Hi all! >> >> I'm wondering how implementers are sending/committing COMPOSITIONs to >> their openEHR EHR implementations. >> >> A little context about what I'm doing right now: >> >> 1. I've implemented an openEHR Service-Oriented (REST) repo that accepts >> commits of COMPOSITIONS in XML >> 2. I use flat archetypes to define those COMPO's (i.e. one archetype with >> all slots resolved, so it's auto-contained) >> 3. Now I'm changing the flat archetypes for OPT support, yay! :) >> 4. The XML accepted by the EHRServer have "version" as the root node >> (VERSION contains one COMPOSITION). >> 5. The commit is composed by an EHR_ID and an array of VERSION. >> >> >> I was thinking of adding more info to the commit so the EHRServer can keep >> a better log of the messages received and the sending applications, >> something like the MSH in HL7v2.x or like the Transmission Infrastructure >> Domain Model of HL7 v3 (basically info about sending and receiving >> apps/devices and facilities, info about the protocol e.g. the ACK mode, id >> of the message, date, ...). >> >> >> What information do you send in your commits? >> Do you send more info for tracking & logging? >> Did anyone mix the commit with HL7-like communication info? >> >> It would be very nice to know your thoughts, thank you! >> >> BTW: for anyone wanting to follow the development and/or contribute: >> https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: >> https://www.youtube.com/watch?v=D-hs-Ofb8SY) >> >> -- >> Kind regards, >> Eng. Pablo Pazos Guti?rrez >> http://cabolabs.com >> >> ___ >> 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 -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at freshehr.com Clinical modelling consultant freshEHR Director openEHR Foundation Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org
Composition commit format to EHR
Hi Pablo, I may be wrong, but I'm getting the impression that you are considering the extra data you're talking about as something that is outside the composition. It can certainly be processed that way, but the openEHR spec has significant consideration for this type of information. The context, composer, setting fields of your composition would let you keep a lot of information. We keep sender system ids etc in these fields regularly. If this is what you meant, then you may consider asking more specific openEHR modelling questions, as in, 'how do I represent this hl7 id in a composition?' etc. If you're talking about some out of openEHR mechanism, you may not need it, keeping things within openEHR would help you make them available to queries in a more consistent way plus all the other benefits where you'd like to have interoperability. There is a limit to what you can model within openEHR of course, and if you start talking about logging etc, then you would probably like to consider mechanisms which are not necessarily specified in the specs. My personal opinion is that there is always some non openEHR functionality an implementer would have to support: audit, some demographics, terminology services etc. You have to set priorities though as an implementer, add these things on top of your EHR related functionality as use cases arise. If you try to develop in advance for everything you can think of you'll have a lng journey ahead :) Best regards Seref On Thu, Apr 10, 2014 at 12:04 AM, pablo pazos wrote: > Hi all! > > I'm wondering how implementers are sending/committing COMPOSITIONs to > their openEHR EHR implementations. > > A little context about what I'm doing right now: > > 1. I've implemented an openEHR Service-Oriented (REST) repo that accepts > commits of COMPOSITIONS in XML > 2. I use flat archetypes to define those COMPO's (i.e. one archetype with > all slots resolved, so it's auto-contained) > 3. Now I'm changing the flat archetypes for OPT support, yay! :) > 4. The XML accepted by the EHRServer have "version" as the root node > (VERSION contains one COMPOSITION). > 5. The commit is composed by an EHR_ID and an array of VERSION. > > > I was thinking of adding more info to the commit so the EHRServer can keep > a better log of the messages received and the sending applications, > something like the MSH in HL7v2.x or like the Transmission Infrastructure > Domain Model of HL7 v3 (basically info about sending and receiving > apps/devices and facilities, info about the protocol e.g. the ACK mode, id > of the message, date, ...). > > > What information do you send in your commits? > Do you send more info for tracking & logging? > Did anyone mix the commit with HL7-like communication info? > > It would be very nice to know your thoughts, thank you! > > BTW: for anyone wanting to follow the development and/or contribute: > https://github.com/ppazos/cabolabs-ehrserver (there is a demo here: > https://www.youtube.com/watch?v=D-hs-Ofb8SY) > > -- > Kind regards, > Eng. Pablo Pazos Guti?rrez > http://cabolabs.com <http://cabolabs.com/es/home><http://twitter.com/ppazos> > > ___ > 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/20140410/fcdba6e3/attachment.html>
Composition commit format to EHR
Hello Pablo > I was thinking of adding more info to the commit so the EHRServer can > keep a better log of the messages received and the sending applications, > something like the MSH in HL7v2.x or like the Transmission > Infrastructure Domain Model of HL7 v3 (basically info about sending and > receiving apps/devices and facilities, info about the protocol e.g. the > ACK mode, id of the message, date, ...). Not sure if there is a need to include this type of data within the structure that bears the COMPOSITION as it is irrelevant to its content. You can still keep track of those data at server side by examining sources such as protocol headers and store those to entities that are in place specifically for monitoring. Hope this helps All the best Athanasios Anastasiou
Composition commit format to EHR
Hi Athanasios, My question is not about what to put IN the COMPOSITION, is more about the COMMIT itself. I need to know how others do things to try to be closer as possible to current implementations. Inspecting lower layer protocols, means that the system might need to have and maintain a mapping between systems (application level concept) and IP/port/User-Agent and other HTTP headers (comm level concepts). I think the idea from HL7 was to have information at the application layer and not rely on lower layer protocols, because in the middle you can have several components that can change the original IP/port/headers, etc. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com > Date: Thu, 10 Apr 2014 11:49:14 +0100 > From: A.Anastasiou at swansea.ac.uk > To: openehr-technical at lists.openehr.org > Subject: Re: Composition commit format to EHR > > Hello Pablo > > > I was thinking of adding more info to the commit so the EHRServer can > > keep a better log of the messages received and the sending applications, > > something like the MSH in HL7v2.x or like the Transmission > > Infrastructure Domain Model of HL7 v3 (basically info about sending and > > receiving apps/devices and facilities, info about the protocol e.g. the > > ACK mode, id of the message, date, ...). > Not sure if there is a need to include this type of data within the > structure that bears the COMPOSITION as it is irrelevant to its content. > > You can still keep track of those data at server side by examining > sources such as protocol headers and store those to entities that are in > place specifically for monitoring. > > Hope this helps > > All the best > Athanasios Anastasiou > > ___ > 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/20140410/c67e9f2b/attachment-0001.html>
