Compact XML format...?
Hi Thilo, One theoretical question (probably you Ocean guys have already looked into it), would it be possible to generate a second schemtron schema to express the asseration type constraints that can't be expressed with XML schema. If possible, by validating against both schemas there wouldn't be a need to use an openEHR kernel component in this integration by TDS scenario. But maybe this is (1) to complicated or (2) superflous as the data is checked anyways with a kernel before being committed. The only advantage would perhaps be that a more or less complete validation could take place in an XML based environment at the client side. [Heath Frankel] No reason why you couldn't use schematron as far as I can see. We choose to use the kernel. Heath
Compact XML format...?
On Wed, 2007-11-28 at 14:49 +1100, Hugh Leslie wrote: Hi Tim I think we are saying the same thing. What I was trying to say was that we see the ability for openEHR systems to continue to consume HL7 v2 messages as being very important and that our tools support this now. However, where the HL7v2 message isn't going to cut it, rather than jump into a full blown openEHR implementation, this is another way of approaching it that is easier. Hi Hugh, After spending the day harrassing the entire development staff of OpenMRS regarding the creation, use and management of Concepts. http://openmrs.org/wiki/Category:Concept I have realized that what you are describing with TDSs are the answer to the exact use case of sharing information with and implementation like OpenMRS. Thanks, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Compact XML format...?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071127/b1321651/attachment.html
Compact XML format...?
On Mon, 2007-11-26 at 15:52 +0100, Heath Frankel wrote: All this will become clear when we publish a draft of the TDS generation and transformation rules on the wiki. Out of curiosity. Do you have any idea of a time frame for this publication? Thanks, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Compact XML format...?
My argument is that the world of healthcare data exchange has been built (so far) on HL7 v2.x If my understanding of your proposal is correct then I will argue that we will have very little success in getting these vendors to incorporate a message format for openEHR. I believe it is better to just continue doing what you are now by consuming HL7 messages. I don't think we should be so pessimistic. The course that Hugh is describing offers a graceful way to become involved with openEHR, a way that allows for gradual development of piece meal solutions into an already existing ediface in a business friendly fashion. I think it makes a lot of sense for both parties to find this common ground. Grahame
Compact XML format...?
Were HL7 messages exist and are working, we will continue to consume them using the TDS intermediate form. As stated previously, the TDS is not intended for information exchange, but as a tool for integration. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Tuesday, 27 November 2007 11:11 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? Hello Hugh, Thanks for the reply. I think we have a communications issue though. My questions/comments weren't about the technical aspects. As I understood the proposition. It was to encourage other system vendors to create these templates in order to communicate with an openEHR based application. My argument is that the world of healthcare data exchange has been built (so far) on HL7 v2.x If my understanding of your proposal is correct then I will argue that we will have very little success in getting these vendors to incorporate a message format for openEHR. I believe it is better to just continue doing what you are now by consuming HL7 messages. Again, I think we are saying the same things but I'm not positive. :-) Cheers, Tim On Tue, 2007-11-27 at 09:12 +1100, Hugh Leslie wrote: Hi Tim Yes, I absolutely agree with this - our tools are capable of receiving V2 messages and producing openEHR data - we did this at MedInfo for the interoperability demo. The problem with V2 is that the ability to put clinical content in there is limited (which is why all the work on v3!) and so we are also working on these other methods. As I said previously we are currently capable of creating and sending CDA R2 messages from openEHR and so as soon as there are applications out there capable of receiving them, we are capable of sending. regards Hugh Tim Cook wrote: Hugh, Tom, Heath, et.al. I agree that openEHR systems MUST interact with everyone else. I also agree that MOST healthcare information providers only have a small segment of healthcare information to consider. I agree that if we (as an openEHR community) do not work with the broader, more established world we will be isolated (no matter that our approach is superior :- ). However, (I always have a BUT or a HOWEVER to present) I do think that it is more prudent to do these translations INSIDE an openEHR implementation instead of trying to coax outside entities into doing them to communicate with openEHR implementations? A different approach says that; openEHR can translate ANYTHING thrown at it via these really cool translations (TDS?). Instead of trying to get various vendors to support our (strange) formats that they do not understand. We certainly know that not many vendors are providing HL7 v3 messages at this point. Shouldn't we concentrate on providing HL7 v2 lab, rad, etc. input to EHR's/PHR's instead of trying to convince the uninformed world that they should be giving us openEHR EHR_Extracts or even transformed XML data? Thanks, Tim On Mon, 2007-11-26 at 20:25 +1100, Hugh Leslie wrote: I also think the problem is that we have to accept the pragmatics of the current situation in health care where companies are not immediately going to re-engineer their systems to become openEHR compliant, no matter how much we would like that. In time, many companies will re-engineer their software, and other new applications will arrive on the scene that are fully openEHR compliant. In the meantime, this pragmatic approach allows for archetypes and templates to completely model clinical medicine and to enable everyone to participate at, initially, minimum cost and effort. The exciting thing about the openEHR approach, is that these Template Data Schemas are not hand coded, but are generated directly from templates and archetypes using tools. In Australia, we are using this approach to enable the completely tool driven generation of CDA R2 documents (because in a pragmatic world, we have to interact with everyone!) with data going both in and out of CDA. Of course we are doing this with openEHR as well. Hugh Leslie Thomas Beale wrote: Rong Chen wrote: Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM
Compact XML format...?
Hi Heath, On Tue, 2007-11-27 at 11:32 +0100, Heath Frankel wrote: As stated previously, the TDS is not intended for information exchange, but as a tool for integration. This may be getting too philosophical for my small brain. I do apologize for being so dense. But I cannot reconcile the difference you are claiming between information exchange and integration. Isn't 'integration' the process of validating/coordinating 'information exchange'? Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook ?I don?t know. I only work here.? :-)
Compact XML format...?
Hi Heath, On Tue, 2007-11-27 at 11:32 +0100, Heath Frankel wrote: As stated previously, the TDS is not intended for information exchange, but as a tool for integration. This may be getting too philosophical for my small brain. I do apologize for being so dense. But I cannot reconcile the difference you are claiming between information exchange and integration. Isn't 'integration' the process of validating/coordinating 'information exchange'? Heath is just using this terminology to distinguish between local systems that feed into EHR systems from self-standing EHR/EMR systems which might talk to each other. Actually, the division is not that clear - we use the TDS message to handle CDA documents from some sources (which may be EMR-like) because it works better, and writing a generic transform for CDA level 3 (fully structured) is hard. - thomas beale
Compact XML format...?
Rong Chen wrote: Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM, some intelligent use of the data won't be possible, e.g. AQL queries of the data. This unfortunately is a purist view. I know - I used to have it ;-) Realistically, many vendors of software used in places like laboratories will only use simple XML or other message-based solutions - they just will not go into the nice theories or modelling that we are interested in here. So the TDS approach is designed to allow them to have a simple schema (i.e. with tags they understand) whose instance data is guaranteed to map directly into a proper openEHR server. THe developers who build that software just have to generate conformant instance, and there is nothing else to do. The data are not widely usable until converted into openEHR form, which is why this approach is really only appropriate for source systems feeding to an EHR system. But - that might be 50% or more of all health information communications in the world, so it is a major use case. Also one-template-one-schema seems to imply software changes whenever new templates are introduced. well it might at their end, e.g. if the lab wants to create a new lab message, but that's what they expect. This is good economics of software building for such vendors. Such changes will not be necessary if the openEHR RM can be mapped directly into a generic internal model, which is constrained in runtime using semantics in the archetypes/templates. So even it seems to be harder than TDS based integration, it does offer full benefits of using archetypes and makes the system more adaptive. Yes, but only some people want adaptive systems. It all comes down to software engineering economics. If your system only generates 25 different pathology result messages which change very little over the years (as is true for the basic biochemistry, bloods, micro etc) then it doesn't make any sense to build a fully adaptive generic system; it will be far cheaper to more or less hard-wire the messages into some part of your software. For such vendors, the main game isn't the diversity or rate of change of the content, it is the volume of throughput, security, uptime and other such issues that are far more important - as would be for the case for any large lab company with a contract with e.g. a regional or state government health service. The semantics are not the most important thing for suppliers whose systems only deal with a relatively small section of health data types. - thomas beale
Compact XML format...?
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071126/04026522/attachment.html
Compact XML format...?
Hugh, Tom, Heath, et.al. I agree that openEHR systems MUST interact with everyone else. I also agree that MOST healthcare information providers only have a small segment of healthcare information to consider. I agree that if we (as an openEHR community) do not work with the broader, more established world we will be isolated (no matter that our approach is superior :- ). However, (I always have a BUT or a HOWEVER to present) I do think that it is more prudent to do these translations INSIDE an openEHR implementation instead of trying to coax outside entities into doing them to communicate with openEHR implementations? A different approach says that; openEHR can translate ANYTHING thrown at it via these really cool translations (TDS?). Instead of trying to get various vendors to support our (strange) formats that they do not understand. We certainly know that not many vendors are providing HL7 v3 messages at this point. Shouldn't we concentrate on providing HL7 v2 lab, rad, etc. input to EHR's/PHR's instead of trying to convince the uninformed world that they should be giving us openEHR EHR_Extracts or even transformed XML data? Thanks, Tim On Mon, 2007-11-26 at 20:25 +1100, Hugh Leslie wrote: I also think the problem is that we have to accept the pragmatics of the current situation in health care where companies are not immediately going to re-engineer their systems to become openEHR compliant, no matter how much we would like that. In time, many companies will re-engineer their software, and other new applications will arrive on the scene that are fully openEHR compliant. In the meantime, this pragmatic approach allows for archetypes and templates to completely model clinical medicine and to enable everyone to participate at, initially, minimum cost and effort. The exciting thing about the openEHR approach, is that these Template Data Schemas are not hand coded, but are generated directly from templates and archetypes using tools. In Australia, we are using this approach to enable the completely tool driven generation of CDA R2 documents (because in a pragmatic world, we have to interact with everyone!) with data going both in and out of CDA. Of course we are doing this with openEHR as well. Hugh Leslie Thomas Beale wrote: Rong Chen wrote: Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM, some intelligent use of the data won't be possible, e.g. AQL queries of the data. This unfortunately is a purist view. I know - I used to have it ;-) Realistically, many vendors of software used in places like laboratories will only use simple XML or other message-based solutions - they just will not go into the nice theories or modelling that we are interested in here. So the TDS approach is designed to allow them to have a simple schema (i.e. with tags they understand) whose instance data is guaranteed to map directly into a proper openEHR server. THe developers who build that software just have to generate conformant instance, and there is nothing else to do. The data are not widely usable until converted into openEHR form, which is why this approach is really only appropriate for source systems feeding to an EHR system. But - that might be 50% or more of all health information communications in the world, so it is a major use case. Also one-template-one-schema seems to imply software changes whenever new templates are introduced. well it might at their end, e.g. if the lab wants to create a new lab message, but that's what they expect. This is good economics of software building for such vendors. Such changes will not be necessary if the openEHR RM can be mapped directly into a generic internal model, which is constrained in runtime using semantics in the archetypes/templates. So even it seems to be harder than TDS based integration, it does offer full benefits of using archetypes and makes the system more adaptive. Yes, but only some people want adaptive systems. It all comes down to software engineering economics. If your system only generates 25 different pathology result messages which change very little over the years (as is true for the basic biochemistry, bloods, micro etc) then it doesn't make any sense to build a fully adaptive generic system; it will be far cheaper to more or less hard-wire the messages into some part of
Compact XML format...?
Rong, XML documents populated against a Template Data Schema are turned into pure openEHR, so you do not lose any semantics. There is enough meta data in the TDS to maintain the semantics. What you may lose are some of the ADL assertions which cannot be expressed in XSD, but these will be picked up by an openEHR kernel before being committed. The schema provides enough constraints to get a non-openEHR developer started. All this will become clear when we publish a draft of the TDS generation and transformation rules on the wiki. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: Monday, 26 November 2007 1:38 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? On Nov 25, 2007 10:09 PM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Erik, I will forward a schema based on a Microbiology Result generated using the Ocean Template Designer separately. See comments below, you have stated exactly the problem that the TDS was designed to solve. We are using this approach to integrate existing vendor software to the Ocean EhrBank where the vendor has no openEHR expertise or desire to do so (yet), they just want to have an openEHR repository. Hi Heath, Tom and others, I clearly see there is a need for TDS based integration. But I am also concerned with the side-effects of it. By offering this 'easy' way of integrating openEHR systems, we make it possible for vendors to ignore the 'hard' way of integrating openEHR systems using archetypes and the generic RM. As you have indicated TDS doesn't contain all the semantics of the archetypes and RM, some semantics will be forever lost when data are received using TDS. Without the knowledge of archetypes and RM, some intelligent use of the data won't be possible, e.g. AQL queries of the data. Also one-template-one-schema seems to imply software changes whenever new templates are introduced. Such changes will not be necessary if the openEHR RM can be mapped directly into a generic internal model, which is constrained in runtime using semantics in the archetypes/templates. So even it seems to be harder than TDS based integration, it does offer full benefits of using archetypes and makes the system more adaptive. Regards, Rong Heath The reason for asking is that in a context where openEHR/13606 has been compared to HL7 (mainly v3 I believe) some parties claimed it would be easier for vendors to support HL7 than openEHR. In practice, what they mean is probably that they are used to follow (map their internal/legacy structures to) specific HL7 xml schemas that come out after the long HL7 modeling process. I doubt that the vendors in this case internally are using any HL7 v3 models. This is sometimes forgotten when comparing HL7 and openEHR. So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. [Heath Frankel] As you know, a template is the knowledge artefact designed for a particular use case, the TDS is a technical artefact to support the implementation of that use case. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. [Heath Frankel] Most but not all the semantics of the archetypes and templates are represented in the TDS. The reason it is not all, is due to the limitations of XML schema to do assertions between XML elements. If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the just give me a simple XML schema and instance examlpe use-case. A use case more important than one might think at first... [Heath Frankel] The TDS is simply a set of XML elements with names from the archetypes. If you look at the schema in an graphical XML tool
Antw: Re: Antw: Re: Compact XML format...?
No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). should it? I'm not so sure that this is the correct definition of a good standard. While I certainly see it's appeal, it seems to me that there's a tension between interoperable and flexible, and the business managers - the people that actually spend money on systems - do not wish to have systems that are fully locked down. In this sense, standards that lock things down are not what is desired, and the standards need to search for a happy medium. This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. Out of idle interest, would you care to nominate an IT interoperability standard that actually meets your criteria? One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. I don't agree with that either. In fact, if only one implementation can satisfy it, it's not an interoperability standard. As for Barry Smith. Ho hum. I wish such HL7 naysayers would actually move things along, and contribute to the overall picture, instead of whining about such trivia as version management. Of course the problem he describes is painful, but this problem is not new, nor specific to HL7. Other HL7 naysayers have gone and done something useful at least; that's why we're on this list. (though, strictly, the doing something useful came first. That's why I've stopped bothering to read Barry Smith) But I was of the impression that that was not the intention of the international health care community. in as much as such a diverse group can be said to have an intention, it wanders somewhere between cheap, flexible, and interoperable. But you can only have two of those three. Grahame
Antw: Re: Antw: Re: Compact XML format...?
Dear Bernie, The experiences that I have had the last 13 years in HL7, CEN/tc251 and ISO/tc251 indicate that many standards depend on many other standards. And many times the standard defines things on an abstract level, needing other standards to make it concrete in a particular situation. In other words things are not so simple and straightforward as the nut and the bold standard. What you describe is a specific extreme situation. In the case of the latest European standard for the EHR produced one implementable specification for this EHR standard. In the case of HL7v2 and HL7v3 message standards it has been proven necessary that an organisation like IHE was needed to produce for a specific context one specification to be used for implementation. One of the reasons is that standards are consensus products for the general case of requirements. In particular contexts the open ends need to be closed and specified. In the near future it will become clear that in order to create semantic interoperability that flexibly can support the ever changing requirements in healthcare the standardisation processes and the process leading to an implementable specification will not be enough. In addition to the above we need databases where the most recent (and old) local context specific constraints are kept and published. Semantic interoperability in healthcare (and outside it) needs other more flexible organisations and publication methods to keep pace with developments in healthcare. The next weeks and months I will be involved in the creation of all this for Europe in the European Institute for Health Records. Greetings, Gerard On Nov 24, 2007, at 5:14 PM, b.cohen wrote: No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. But I was of the impression that that was not the intention of the international health care community. Am I wrong?
Compact XML format...?
Tim, I don't know anything about MIRTH but I will assume it does something like take a HL7 v2 message and turn it into some XML document based on a provided schema, I would call this a transformation, just not XSLT. Assuming that the XML Schema used in MIRTH is a Template Data Schema, then you are only one further transformation away from openEHR. Any integration engine can be used to implement this approach using whatever mapping tools it provides. Again I don't know about how MIRTH works but the catch in this is the Template Data Schemas might be too specific to allow MIRTH to be used against the TDS in one step. What I mean by this is that a TDS is specific to a use case such as a Microbiology Report, not a generic Observation Result equivalent to the HL7 OUR message. When receiving a ORU message you need to determine that it has a Microbiology observation within and apply the transform to the Microbiology Report TDS, if it contains a Lipids result then you need to apply the transform to a TDS containing laboratory-lipids OBSERVATION archetype in it. You could certainly come up with a template containing a generic laboratory OBSERVATION archetype in it and map everything in an ORU to that but you lose some of the semantics of the specialised archetypes. Using our current integration engine of choice, we have a mechanism where we can apply logic to determine what kind of lab report has been received based on data within the message and apply the appropriate TDS transformation and anything else we don't yet support we transform to a generic laboratory report TDS. This gives the ability to take all results from a lab into openEHR but can progressively utilise specialised archetypes for common results as we develop those transformation mappings. The benefit of this Archetype-based Integration approach is that we can start building a library of HL7 V2 to TDS transformations that can be used as a starting point for integrating with a specific HL7 interface, customising to suit the local HL7 and terminology implementation. This library could be an open resource. This is something that I have not seen possible in system integration before. BTW, this approach is not limited to integration with openEHR, but it is the Archetype that makes it work. The Archetype is the implementation independent logical concept model that is used derive the implementation to semantic mapping in and out of the Archetype-based normalised intermediate format. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Sunday, 25 November 2007 7:35 AM To: For openEHR technical discussions Subject: Re: Compact XML format...? On Sat, 2007-11-24 at 08:47 +, Heath Frankel wrote: Think of it as standard mechanism for data transformation rather than a standard data exchange, where the semantics of the archetypes are maintained at each stage in the pipeline. Would it be fair to say then that when working with HL7 v2 messaging. I would want to use this data transformation process against the XML output of MIRTH ( http://www.mirthproject.org/ )so that I can use all the management facilities of MIRTH and only have to have (essentially) one transform?? Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Compact XML format...?
Dear Erik, The European Institute for Health Records is executing a European project: Q-Rec. Next to quality labelling and certification we have to set up registries of approved artefacts like: - archetypes and templates - coding systems - EHR related standards and - XML implementable Information definitions. I hope and expect that these Template Data Schemas can find a place there to be disseminated. Gerard conexis --- Gerard Freriks, MD Huigsloterdijk 378 2158LR Buitenkaag the Netherlands M:+31 620347088 T: +31 620347088 E:gf at conexis.nl KvK 34264021 On Nov 25, 2007, at 9:38 AM, Erik Sundvall wrote: Hi! On Nov 23, 2007 7:17 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: I believe you are referring to what we call Template Data Schemas (TDSs). These are an alternate schema-per-message approach, where one template generates one schema - in such schemas, you find tagnames coming from the archetypes, e.g. systolic rather than the generic openEHR tag names. This seems to be exactly what I was looking for. I will find out about example messages. Wonderful, if it was possible to get it soon that would be helpful. The reason for asking is that in a context where openEHR/13606 has been compared to HL7 (mainly v3 I believe) some parties claimed it would be easier for vendors to support HL7 than openEHR. In practice, what they mean is probably that they are used to follow (map their internal/legacy structures to) specific HL7 xml schemas that come out after the long HL7 modeling process. I doubt that the vendors in this case internally are using any HL7 v3 models. This is sometimes forgotten when comparing HL7 and openEHR. So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the just give me a simple XML schema and instance examlpe use-case. A use case more important than one might think at first... Sometimes the use case is to decide on an XML format (for data exchange) based on one of the following 1. HL7 CDA 2. 13606/openEHR 3. A custom tailored XML schema Imagine that we using something like TDS could give an easy-to-produce alternative to 3 that with some deterministic transformations at the receiver also conforms to 2. (An open or free tool to produce the schema would be of tremendous help of course.) Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071125/4a02e02d/attachment.html
Antw: Re: Antw: Re: Compact XML format...?
hi If compliance to a standard does not guarantee interoperabilty with everything alse that complies to the standard, then what exactly is being standardised? My point of view is simple. I do this for a living - apply these standards to make interoperability happen. Without healthcare standards, I must choose some lower level standards, such as xml, figure out my own data and process models, agree with someone else, and implement. Using HL7 v2, v3, or archetypes/templates gives me a pre-existing language and process model, a set of shared assumptions, and also allows me to share existing code and information models across different interoperability implementations. So they are all interoperability framework standards, rather than interoperability standards - a lot like the W3C standards; http, html, soap, xml etc, these are interoperability frameworks. I think that what we are doing in health stands up well when compared with W3C and OMG. These problems arise mainly through the industry's failure to address these three criteria, which necessarily introduce concepts of formal definition and proof that have been beyond the capability, and even comprehension, of most IT systems suppliers and their customers. so, why complain? the users buy what the users want. It's like complaining about insecure software. Give a user a choice of a $100 package and a $1 equivalent that is more secure. Which are they going to choose? Yet people see this problem as a supplier side problem. I don't understand why. On the contrary. A standard that's defined by an implementation guarantees interoperability among the users of that implementation. That's how MS won its market share. I'm not convinced that such a standard is actually a better outcome; it's still going to be shot through with technical flaws, and probably no process for managing it which is not subject to commercial corruption. But I was of the impression that that was not the intention of the international health care community. in as much as such a diverse group can be said to have an intention, it wanders somewhere between cheap, flexible, and interoperable. But you can only have two of those three. Can you demonstrate that these three properties are necessarily mutually incompatible? And, if it is indeed so, which of them would you advocate prioritising in the domain of healthcare? I'm not sure that I can demonstrate it. It's a truism I adapted from Martin Fowler, though he probably got it from Fast, cheap, or good; you can have any two. My experience is strongly in support of this; there is an inherent tension between interoperability - being standard, doing things the common way - and offering a product that delivers features that the users want. You can over engineer to try and do both, but it takes a huge amount of extra work. So I think you can't have all three. As for which I advocate, I'm just a jumped up programmer who makes my living doing interoperability for customers, so naturally I don't recommend cheap ;-) But the reality is that there's only a given amount of money to spend on healthcare, however it's organised, and given the amount of waste involved in any human endeavour, cost will always be first and last. And, err, try doing sales where you say to a customer, well, we can't actually solve your business problem because HL7 doesn't support it. I can assure you, that doesn't help you land the sale. I am in favour of open source, of course, I believe it offers the best mix of the three, but it's frustratingly hard to make things align. I'm still living in hope that the various open source initiatives can come together productively Grahame CTO Kestral Computing co-chair Infrastructure Messaging TC (HL7) editor - HL7 datatypes templates specifications Project Lead - Eclipse Open Healthcare Foundation
Compact XML format...?
Erik Sundvall wrote: So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. thi is a reasonable statement, practically speaking. The question is\; if you are vendor that needs to increase the diversity of content being handled - in other words, you are need semantic scalability - and, if you need to be able too use other derived products from the same content models, then the difference starts to manifest itself. There isn't any easy way I know of to convert a v3 RMIM to an Xform, a PDF, various kinds of XML and HTML and so on. And before people simply say: 'its just an XML transform', you must remember that in the RIM/RMIM world, there are dozens of attributes specifically to do with message transfer that don't make sense in other representations of the same content. Any transformation software has to sift through all these, as well as work out all the context conduction etc. It is not trivial. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. see other responses on this (yes is the answer). If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the just give me a simple XML schema and instance examlpe use-case. A use case more important than one might think at first... that's why we made them in the first place ;-) For vendors who just want to send a bunch of messages (they usually see them as messages), that can be converted by smart software doing a standard transform, generating guaranteed correct openEHR content. - thomas beale
Compact XML format...?
Hi Erik, I will forward a schema based on a Microbiology Result generated using the Ocean Template Designer separately. See comments below, you have stated exactly the problem that the TDS was designed to solve. We are using this approach to integrate existing vendor software to the Ocean EhrBank where the vendor has no openEHR expertise or desire to do so (yet), they just want to have an openEHR repository. Heath The reason for asking is that in a context where openEHR/13606 has been compared to HL7 (mainly v3 I believe) some parties claimed it would be easier for vendors to support HL7 than openEHR. In practice, what they mean is probably that they are used to follow (map their internal/legacy structures to) specific HL7 xml schemas that come out after the long HL7 modeling process. I doubt that the vendors in this case internally are using any HL7 v3 models. This is sometimes forgotten when comparing HL7 and openEHR. So far we have had a look at some fairly equivalent examples of XML instances (e.g. blood pressure) from HL7 CDA (v2) and openEHR RM. Both were fairly easy to understand when knowing the underlying models (HL7 RIM +CDA and openEHR RM+AM) and both were a bit verbose if you were just interested in the blood pressure. To be honest if I was a vendor not interested in underlying models I'd probably prefer whichever I was already used to and had people trained to work with - since none of them tries to make life easier to me by being tailored to the specific use case. [Heath Frankel] As you know, a template is the knowledge artefact designed for a particular use case, the TDS is a technical artefact to support the implementation of that use case. To validate clinically both were dependent on other artifacts (HL7 Templates or openEHR archetypes). An information provider not interested in the underlying validation mechanisms could easily produce data instances that are clinically invalid even though they are valid from the perspective of the respective XML schemas. Does the TDS-approach produce an XML schema that enforces more or all of the specific archetype+template semantics? If not, could it be enhanced to do that? If so I believe that some safety would be gained - if data providers do not care to learn the full semantics of openEHR then at least their schema-based XML-validators would enforce some of the semantics. [Heath Frankel] Most but not all the semantics of the archetypes and templates are represented in the TDS. The reason it is not all, is due to the limitations of XML schema to do assertions between XML elements. If we could standardize the TDSs and have accompanying standard determinstic transformation mechanism then openEHR would have a competitive advantage in the just give me a simple XML schema and instance examlpe use-case. A use case more important than one might think at first... [Heath Frankel] The TDS is simply a set of XML elements with names from the archetypes. If you look at the schema in an graphical XML tool such as Oxygen you will see a tree that has the same structure as the template tree displayed in the Ocean Template Designer. Sometimes the use case is to decide on an XML format (for data exchange) based on one of the following 1. HL7 CDA 2. 13606/openEHR 3. A custom tailored XML schema Imagine that we using something like TDS could give an easy-to-produce alternative to 3 that with some deterministic transformations at the receiver also conforms to 2. (An open or free tool to produce the schema would be of tremendous help of course.) [Heath Frankel] This is exactly the plan for the TDS.
Antw: Re: Compact XML format...?
In een bericht met de datum 23-11-2007 16:55:12 West-Europa (standaardtijd), schrijft timothywayne.cook at gmail.com: IHMO, any system that is not interested in the full semantics of the openEHR model is not compliant with openEHR and is just a stand alone system. Much like the various HL7 implementations that require interface engines to make the transition. This seems only relevant to compare with the HL7 v2. V3 has no various implementations, but one standard implementation of messages. The v3 content can vary, similar to archetype variations. Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 /HTML -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071124/fe2ed215/attachment.html
Antw: Re: Compact XML format...?
Op 24-nov-2007, om 7:45 heeft Williamtfgoossen at cs.com het volgende geschreven: V3 has no various implementations, Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (http://hl7-watch.blogspot.com/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef --- The Dialects of RIM The latest Minutes of Evidence of the House of Commons Select Committee on Health, on the UK National Programme for IT, contain this comment from Richard Granger: In terms of the core Spine infrastructure, there was some mythology in the Health Informatics Community that the standards existed, HL7 was mature, and so forth. That was completely untrue. Dr Granger goes on: We have had to put an awful lot of effort into specifying the standards for messages, around demographics, around booking, around prescriptions, and then the software that BT have built with a number of sub-contractors is brand new software that has been custom-built for the NHS; so that is high-risk, new build software. There was no other way of doing it. I am very pleased a number of other jurisdictions are getting very interested in using that. He thereby inadvertently touches on another issue currently causing concern in HL7 circles. The HL7 Reference Information Model or 'RIM' was, we will remember, introduced as the solution to the problems created by the appearance of multiple dialects in earlier versions of the HL7 standard. HL7 would prevent the appearance of dialect versions by enforcing conformity to the RIM. Now, however, it is becoming increasingly clear that the RIM itself exists in multiple dialects. This is more than just a problem of successive, incremental improvements. As the RIM Document Editorial Assessment from 8 June 2007 points out: ... the 2006 Normative Edition contains a RIM document based on the last balloted RIM [from 2003]: this gap creates the opportunity for conceptual conflict between the document and current practice. A reader must choose between a normative edition of the RIM published for ANSI, which contains nothing extraneous but is out of date; an extract of the current RIM as maintained by MnM, which will be the most up-to-date, but which is not readily available to the membership at large; or, which is most probable, the RIM document published in the Normative Edition, which both contains extraneous information and is out of date. It seems, in fact, that we have at least: 1. the version of the RIM adopted by ISO as an international standard 2. the balloted RIM document that describes those parts of the RIM designated as 'normative', the latest (and still current) version of which, it seems, dates back to June 2003 3. an ANSI publication based on 2. 4. a CEN Standard EN 14822-1:2005 Health informatics - General purpose information components - Part 1: Overview (see also CEN Standard EN 14720-1:2005), based on 3. 5. the 'living' RIM UML model (regularly updated through harmonization) as it exists at any given stage. This RIM contains content that existed at the time of balloting in 2003 but was not then balloted, together with four years worth of cumulated changes. Some of this material is, I am told, intended to be balloted in the future; some (e.g. in CoreInfrastructure subject area) is not. 6. an idealized 'frozen' version consisting of those parts of 5. which have, at any given stage, passed through the process of harmonization, 7. the UK rebuild. As I understand matters (and as always this understanding may be for various reasons imperfect) the RIM documentation included in any publication of the V3 standard more recent than 2003 should be based on the latest working version of the model as maintained by the Modeling and Methodology (MnM) committee. The publication label ?Normative Edition? may cause confusion, however, if it is taken by the reader as suggesting that the contents so labeled are all normative (though this issue should be addressed in the relevant document preface). -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071124/573e33f8/attachment.html
Antw: Re: Compact XML format...?
There is only one openEHR implementation, the template data schemas are just a tool to transform data from other formats into and out of the openEHR reference model using the semantics of the clinical archetypes models. The TDS are not intended to replace openEHR, but enable it for those that are not openEHR compliant. The result of using a TDS is openEHR for standard information sharing. The reality is, most systems are not built on a particular standard reference model such as HL7 or openEHR, they are proprietary models which move their data into these standard models for interoperable exchange. The TDS provides a means for these systems to move their data into clinical data models and mechanically transform them into technical data models, such as openEHR. Think of it as standard mechanism for data transformation rather than a standard data exchange, where the semantics of the archetypes are maintained at each stage in the pipeline. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: Saturday, 24 November 2007 6:46 AM To: openehr-technical at openehr.org Subject: Antw: Re: Compact XML format...? In een bericht met de datum 23-11-2007 16:55:12 West-Europa (standaardtijd), schrijft timothywayne.cook at gmail.com: IHMO, any system that is not interested in the full semantics of the openEHR model is not compliant with openEHR and is just a stand alone system. Much like the various HL7 implementations that require interface engines to make the transition. This seems only relevant to compare with the HL7 v2. V3 has no various implementations, but one standard implementation of messages. The v3 content can vary, similar to archetype variations. Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071124/83bd2f97/attachment.html
Antw: Re: Compact XML format...?
Thanks for your explanations Heath. I had misunderstood what Erik was asking about and jumped to the totally wrong conclusion. Regards, Tim On Sat, 2007-11-24 at 08:47 +, Heath Frankel wrote: There is only one openEHR implementation, the template data schemas are just a tool to transform data from other formats into and out of the openEHR reference model using the semantics of the clinical archetypes models. The TDS are not intended to replace openEHR, but enable it for those that are not openEHR compliant. The result of using a TDS is openEHR for standard information sharing. The reality is, most systems are not built on a particular standard reference model such as HL7 or openEHR, they are proprietary models which move their data into these standard models for interoperable exchange. The TDS provides a means for these systems to move their data into clinical data models and mechanically transform them into technical data models, such as openEHR. Think of it as standard mechanism for data transformation rather than a standard data exchange, where the semantics of the archetypes are maintained at each stage in the pipeline. Heath From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Williamtfgoossen at cs.com Sent: Saturday, 24 November 2007 6:46 AM To: openehr-technical at openehr.org Subject: Antw: Re: Compact XML format...? In een bericht met de datum 23-11-2007 16:55:12 West-Europa (standaardtijd), schrijft timothywayne.cook at gmail.com: IHMO, any system that is not interested in the full semantics of the openEHR model is not compliant with openEHR and is just a stand alone system. Much like the various HL7 implementations that require interface engines to make the transition. This seems only relevant to compare with the HL7 v2. V3 has no various implementations, but one standard implementation of messages. The v3 content can vary, similar to archetype variations. Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Antw: Re: Antw: Re: Compact XML format...?
In een bericht met de datum 24-11-2007 8:30:05 West-Europa (standaardtijd), schrijft stef at vivici.nl: Op 24-nov-2007, om 7:45 heeft A HREF=mailto:Williamtfgoossen at cs.comWilliamtfgoossen at cs.com/A het volgende geschreven: Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (A HREF=http://hl7-watch.blogspot.com/;http://hl7-watch.blogspot.com/A/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef Hi Stef, Yes, here you have a point! Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 /HTML -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071124/574043dc/attachment.html
Antw: Re: Antw: Re: Compact XML format...?
No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. But I was of the impression that that was not the intention of the international health care community. Am I wrong? Quoting Williamtfgoossen at cs.com: In een bericht met de datum 24-11-2007 8:30:05 West-Europa (standaardtijd), schrijft stef at vivici.nl: Op 24-nov-2007, om 7:45 heeft A HREF=mailto:Williamtfgoossen at cs.comWilliamtfgoossen at cs.com/A het volgende geschreven: Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (A HREF=http://hl7-watch.blogspot.com/;http://hl7-watch.blogspot.com/A/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef Hi Stef, Yes, here you have a point! Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 /HTML -- __ Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq. London EC1V 0HB tel: ++44-20-7040-8448 fax: ++44-20-7040-8587 b.cohen at city.ac.uk WWW: http://www.soi.city.ac.uk/~bernie Patterns lively of the things rehearsed This message was sent using IMP, the Internet Messaging Program.
Antw: Re: Antw: Re: Compact XML format...?
Op 24-nov-2007, om 17:14 heeft b.cohen het volgende geschreven: No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. I agree. I guess I should have written 'a good standard' should have only one version that is used by all who underwrite that standard. Of course it must comply to these 3 requirements above One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. But I was of the impression that that was not the intention of the international health care community. Am I wrong? Can you please elaborate on this statement? My feeling is that your right but don't know what you mean exactly. As far as I know there are at least 3 different openEHR implementations on 3 different software platforms (Eiffel, .net and Java (and soon one on Ruby)), and these should be able to communicate seamlessly. So it seems that openEHR meets at least the first 2 the requirements and, if I'm correct, complying to the third is well on it's way Cheers, Stef Quoting Williamtfgoossen at cs.com: In een bericht met de datum 24-11-2007 8:30:05 West-Europa (standaardtijd), schrijft stef at vivici.nl: Op 24-nov-2007, om 7:45 heeft A HREF=mailto:Williamtfgoossen at cs.comWilliamtfgoossen at cs.com/A het volgende geschreven: Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (A HREF=http://hl7-watch.blogspot.com/;http://hl7- watch.blogspot.com/A/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef Hi Stef, Yes, here you have a point! Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 /HTML -- __ Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq. London EC1V 0HB tel: ++44-20-7040-8448 fax: ++44-20-7040-8587 b.cohen at city.ac.uk WWW: http://www.soi.city.ac.uk/~bernie Patterns lively of the things rehearsed This message was sent using IMP, the Internet Messaging Program. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Antw: Re: Antw: Re: Compact XML format...?
This is how I see it as well. Realistically, various vendors implement only some pieces of larger, more comprehensive systems - like compay A makes nuts and company B makes bolts, but the standard for nuts + bolts must either be one standard or 2 totally compatible standards. Any given implementation in e-Health is likely to be responsible for just a few things out of the universe, e.g. some kinds of messages, patients, who knows what. Bigger vendors may implement a substantial amount, but I don't expect any single implementation will be the one stop shop - because no implementation can satisfy all business needs, even if it completely satisfies the standards. On the other hand, if you take an interoperability component, like the openEHR kernel, or some message parser or whatever, is there any sense in having more than one good, free, and open implementation in each of the major technologies, i.e. .Net, Java, Python...(add your favourite)? I think the more related to interoperability the component is, and the more widely it is needed, the less argument there is for multiple implementations, since they don't serve any purpose. Good quality can be achieved by an engineering-based open source approach like Eclipse does; once you have an open component, then all other requirements can be engineered into it, rather than companies inventing their own varieties. For components not needing to be directly interoperable, e.g. an enterprise EHR server (most of the software is about data storage and local serving), and also satisfying varied business needs, competition is more appropriate. I am coming to the view that open source projects for full domain specific systems like EHR, etc do not make sense - all they do is try to replicate commercial systems for a given business context - this is ok for small systems, but for fully scalable EHR, knowledge services, etc I don't see it. Reusable components seemn to me to be the the more sensible purview of open source in a specialised domain. (Things like Apache are different - they are not domain specific and the business context is pretty much the same everywhere.) - thomas beale b.cohen wrote: No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. But I was of the impression that that was not the intention of the international health care community. Am I wrong? Quoting Williamtfgoossen at cs.com: In een bericht met de datum 24-11-2007 8:30:05 West-Europa (standaardtijd), schrijft stef at vivici.nl: Op 24-nov-2007, om 7:45 heeft A HREF=mailto:Williamtfgoossen at cs.comWilliamtfgoossen at cs.com/A het volgende geschreven: Can you, in this light explain what Barry Smith is talking about in his HL7-watch blog (A HREF=http://hl7-watch.blogspot.com/;http://hl7-watch.blogspot.com/A/, the text is also underneath). Probably I don't understand it correctly, so if you could enlighten me that would be very helpful. I think that we all agree that a good standard should have only one implementation Cheers, Stef Hi Stef, Yes, here you have a point! Sincerely yours, dr. William TF Goossen director Results 4 Care b.v. De Stinse 15 3823 VM Amersfoort email: Results4Care at cs.com phone + 31654614458 fax +3133 2570169 Dutch Chamber of Commerce number: 32121206 /HTML -- please change your address book entry for me to Thomas.Beale at OceanInformatics.com *Thomas Beale* /Chief Technology Officer/ Ocean Informatics http://www.oceaninformatics.com/ Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * *
Antw: Re: Antw: Re: Compact XML format...?
Grahame Grieve wrote: in as much as such a diverse group can be said to have an intention, it wanders somewhere between cheap, flexible, and interoperable. But you can only have two of those three. *not a bad summary. Especially if 'flexible' can be read as 'scalable'... - thomas *
Antw: Re: Antw: Re: Compact XML format...?
Quoting Grahame Grieve grahame at kestral.com.au: No. A good standard should ensure that all implementations that satisfy it are mutually interoperable (see, for example, the Whitworth stanard for nuts and bolts!). should it? I'm not so sure that this is the correct definition of a good standard. While I certainly see it's appeal, it seems to me that there's a tension between interoperable and flexible, and the business managers - the people that actually spend money on systems - do not wish to have systems that are fully locked down. In this sense, standards that lock things down are not what is desired, and the standards need to search for a happy medium. If compliance to a standard does not guarantee interoperabilty with everything alse that complies to the standard, then what exactly is being standardised? This requires that: 1. the standard include the the tests that supposdly conformant implementation must pass; 2. that test be necessary and sufficent to guarantee compliance; and 3. Proven compliance to the standard be necessary and sufficient to guarantee interoperability. Out of idle interest, would you care to nominate an IT interoperability standard that actually meets your criteria? That's not an idle question. Merely asking it reveals serious problems that have plagued the IT industry for over half a century, re programming languages, operating systems, comms protocols, office applications, databases, etc. etc. These problems arise mainly through the industry's failure to address these three criteria, which necessarily introduce concepts of formal definition and proof that have been beyond the capability, and even comprehension, of most IT systems suppliers and their customers. One way to do this is to for the standard to overdetermine implementation to such an extent that exactly one implementation satisfy it. This is how 'de facto standards' work. I don't agree with that either. In fact, if only one implementation can satisfy it, it's not an interoperability standard. On the contrary. A standard that's defined by an implementation guarantees interoperability among the users of that implementation. That's how MS won its market share. As for Barry Smith. Ho hum. I wish such HL7 naysayers would actually move things along, and contribute to the overall picture, instead of whining about such trivia as version management. Of course the problem he describes is painful, but this problem is not new, nor specific to HL7. Other HL7 naysayers have gone and done something useful at least; that's why we're on this list. (though, strictly, the doing something useful came first. That's why I've stopped bothering to read Barry Smith) But I was of the impression that that was not the intention of the international health care community. in as much as such a diverse group can be said to have an intention, it wanders somewhere between cheap, flexible, and interoperable. But you can only have two of those three. Can you demonstrate that these three properties are necessarily mutually incompatible? And, if it is indeed so, which of them would you advocate prioritising in the domain of healthcare? Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- __ Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq. London EC1V 0HB tel: ++44-20-7040-8448 fax: ++44-20-7040-8587 b.cohen at city.ac.uk WWW: http://www.soi.city.ac.uk/~bernie Patterns lively of the things rehearsed This message was sent using IMP, the Internet Messaging Program.
Compact XML format...?
Hi! During Medinfo2007 I believe Ocean Informatics presented a compact XML format for interchange of predefined information snippets that was used for integration purposes. I do not believe it was based on the official RM-schemas that cover everything but instead a compact form for a specific purpose (e.g. using a specific template or set of archetypes). Does anybody understand what I am referring to or was I just dreaming? Could somebody please send a snippet with an example of that format and possibly some description or documentation. I believe a brief discussion regarding this on the list could be valuable since there are use cases where having a standardized such a format would be of value. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579
Compact XML format...?
Hi Erik, I understand what you are saying. It seems to be a customized XML Schema for data exchange. The schema is not a full-blown openEHR schema and used when the receiving system is not interested to understand the full semantics of the openEHR reference model and archetypes. Regards, Rong On Nov 23, 2007 3:47 PM, Erik Sundvall erisu at imt.liu.se wrote: Hi! During Medinfo2007 I believe Ocean Informatics presented a compact XML format for interchange of predefined information snippets that was used for integration purposes. I do not believe it was based on the official RM-schemas that cover everything but instead a compact form for a specific purpose (e.g. using a specific template or set of archetypes). Does anybody understand what I am referring to or was I just dreaming? Could somebody please send a snippet with an example of that format and possibly some description or documentation. I believe a brief discussion regarding this on the list could be valuable since there are use cases where having a standardized such a format would be of value. Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071123/dbc3d54c/attachment.html
Compact XML format...?
I believe you are referring to what we call Template Data Schemas (TDSs). These are an alternate schema-per-message approach, where one template generates one schema - in such schemas, you find tagnames coming from the archetypes, e.g. systolic rather than the generic openEHR tag names. This is similar to HL7, except that here the message schemas are generated from content models (archetypes templates) rather than hand-built as in HL7. What this does is provide a message capability to openEHR based on the content models, just like any other generated artifact, e.g. Xforms or HML or code skeletons. We have only just developed this capability (it is still under test), and we expect it to be attractive to certain types of provider, e.g. pathology software vendors and labs, since it means they can use 'simple XML' to transfer their result messages, rather than having to understand all that weird openEHR stuff. This approach means any message (e.g. anything currently expressed in HL7 or Edifact) can now be generated from archetypes and templates (obviously the literal XML is different, we don't use RIM-based XML, but the logical purpose is exactly the same). I will find out about example messages. I would expect that we will provide the relevant specifications for this process to openEHR.org at some point, when it has stabilised. - thomas beale Erik Sundvall wrote: Hi! During Medinfo2007 I believe Ocean Informatics presented a compact XML format for interchange of predefined information snippets that was used for integration purposes. I do not believe it was based on the official RM-schemas that cover everything but instead a compact form for a specific purpose (e.g. using a specific template or set of archetypes). Does anybody understand what I am referring to or was I just dreaming? Could somebody please send a snippet with an example of that format and possibly some description or documentation. I believe a brief discussion regarding this on the list could be valuable since there are use cases where having a standardized such a format would be of value. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- please change your address book entry for me to Thomas.Beale at OceanInformatics.com *Thomas Beale* /Chief Technology Officer/ Ocean Informatics http://www.oceaninformatics.com/ Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * *
Compact XML format...?
Just to clarify one thing about these Template Data Schemas, they are NOT intended for exchange across system boundaries. They are used as an intermediary format, which is normalised based on archetypes and templates, for the purposes of integration between system components (note that I use the term system in the sense of a system of systems within an enterprise). For example, to import HL7 V2 messages into openEHR it is easier to move the data into an intermediate form and then into openEHR. Similarly, to export data from a proprietary database to openEHR, you can go via a intermediate form. The key here is that the intermediate form are based on normalised content models and can be the same for different data sources. It allows developers to work with the content models without being openEHR experts, resulting in reduced barriers to the take up of openEHR. The real clincher, is that there is a single transformation from any of these template-based XML schemas into openEHR. We are refining the rules for generating these schemas and the openEHR transformation and will share it with the openEHR community soon. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Friday, 23 November 2007 6:17 PM To: For openEHR technical discussions Subject: Re: Compact XML format...? I believe you are referring to what we call Template Data Schemas (TDSs). These are an alternate schema-per-message approach, where one template generates one schema - in such schemas, you find tagnames coming from the archetypes, e.g. systolic rather than the generic openEHR tag names. This is similar to HL7, except that here the message schemas are generated from content models (archetypes templates) rather than hand-built as in HL7. What this does is provide a message capability to openEHR based on the content models, just like any other generated artifact, e.g. Xforms or HML or code skeletons. We have only just developed this capability (it is still under test), and we expect it to be attractive to certain types of provider, e.g. pathology software vendors and labs, since it means they can use 'simple XML' to transfer their result messages, rather than having to understand all that weird openEHR stuff. This approach means any message (e.g. anything currently expressed in HL7 or Edifact) can now be generated from archetypes and templates (obviously the literal XML is different, we don't use RIM-based XML, but the logical purpose is exactly the same). I will find out about example messages. I would expect that we will provide the relevant specifications for this process to openEHR.org at some point, when it has stabilised. - thomas beale Erik Sundvall wrote: Hi! During Medinfo2007 I believe Ocean Informatics presented a compact XML format for interchange of predefined information snippets that was used for integration purposes. I do not believe it was based on the official RM-schemas that cover everything but instead a compact form for a specific purpose (e.g. using a specific template or set of archetypes). Does anybody understand what I am referring to or was I just dreaming? Could somebody please send a snippet with an example of that format and possibly some description or documentation. I believe a brief discussion regarding this on the list could be valuable since there are use cases where having a standardized such a format would be of value. Best regards, Erik Sundvall erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel: +46-13-227579 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- please change your address book entry for me to Thomas.Beale at OceanInformatics.com *Thomas Beale* /Chief Technology Officer/ Ocean Informatics http://www.oceaninformatics.com/ Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
