Thomas Beale wrote: > > Bert Verhees wrote: > >> Hi, >> >> Thomas Beale asked me to write more to this mailinglist, and I have >> an important issue to discuss. >> >> Last thursday, I had a meeting wherein Thomas was present, in fact, >> it was education about EN13606. After a whole day of talking, by >> Thomas, he really did a good job. I noticed there was no mention >> about GPICs, and I asked Thomas, how GPICs fitted in his story. He >> said to my surprise, that they didn't. GPICs were in fact, obsoleet. >> But one could still use them to migrate data to an archetype-ready >> data layer. >> >> > Looks like I have to clarify somewhat! Here is my take on GPICs: > - GPICs are approximately an equivalent of HL7 CMETs, but developed > for European use > - as such, they define reusable parts of messages > - messages are defined in advance, essentially as hardwired > definitions of packets of information to be sent between two systems. > - In contrast, EN13606 is defined as a generic approach to carrying > information, with the semantics defined in archetypes, and applied > flexibly at runtime. > - Thus, EN13606 does not use GPICs directly, apart from a small number > of demographic ones which have been replicated in the UML of the > demographic part of the 13606 part 1 model. However, it is expected > that any GPICs deemed useful for EHR systems will be re-engineered > into archetypes. > - note also that the scope of messaging is generally wider than the > EHR, i.e. there are messages for communications which we do not desire > to put in the EHR, e..g fine-grained ordering and workflow events, > many admin and billing events and so on. So EN13606 would not be used > in such situations (of course, if we were starting from scratch in > this area, we would use the generic information model + archetype > approach for such things, but we are not - there is much > implementation already based on the message paradigm). > > So in summary, I don't see GPICs as being obsolete. They are not used > directly in EN13606, but rather in various messages being defined in > Europe.
It is a bit difficult to address everybody who helped me think about this last few days in discussion. But I welcome everybody to reflect on my writings here below. I also have CC-ed a few people which do not read this mailinglist. -------------------- Thanks Thomas, for your (let's call it) architectural approach, which is very good and needed. I am the builder (Bob the Builder, can we make things?) what people like you design. The approach changed. That doesn't matter, it is good to change when it results in improvement. (Maybe I still do not understand your approach well, and if you want to correct me in this, you are very welcome.) So let me summarise in my own words: Except from demographic GPICs, the GPIC's are (on code-base) left behind in EN13606. Meaning: if someone wants GPIC's he can build still them with the archetype-editor. GPIC's will still exist as information-blocks and as a standard (but not in En13606), and they are not anymore thought of as classes, which are to be implemented at the base of the information-system. In fact, it is good news, I always found the GPICs as code-classes a bit too complex, too concrete, and also bad inheritance-rules, etc. One could see that they were designed to hold information, not to work inside code-design/architecture. But for grouping information in blocks, GPICs can be very handy (beside other archetypes), designed by people with knowledge of the domain. My approach till now, based on information from december 2002, was different, and as it appears now, not very useable in the archetype-editor-approach. But, as you say, it is not done for nothing, it is in fact very useable, and I could even, if there is demand for it, build even more GPICs in code-classes and fill them up with the proper information. As I understand from Gerard, GPICs will have an own standard besides EN13606, customers like standards, give something an ISO number, and they buy it. They have no choice, they do not have the opportunity to study the ins and outs of the different standards, so their choice is based on information they get from people they respect. So no problem at all, in the end, one could say. ------------ The holy grail is a more generic approach which allows archetypes written as simple scripts which can use an information-system flexible and even allows ad-hoc creations of archetypes. Creating a new information-structure will then be work of days, or maybe a few weeks, instead of months or years, and can be done by people with not much knowledge of programming.` This holy grail can be reached much more simple if one has the possibility to create a specially formed shadow-database, or better, to do a data-migration to a new database-structure. Unfortunately, that is not my case, I do live queries on different datamodels and using different interfaces. Some aren't SQL-based, but API-based, very old stuff. So I wonder if it is possible to migrate data in live queries to a needed generic virtual database structure. I have to study on this. GPICs are a much easier approach in my case. kind regards Bert Verhees - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
