Christopher Feahr wrote:
>Ideally, we should have one geo-politically neutral SDO >maintaining robust communications with a solid, global network of >medical subject matter experts. Then we build "straw man" >model-components and run them through our expert vetting pool until no >one has substantial objection. Eventually, these converge into a >generally accepted model of the persons, places, things, actions, >relationships, and data elements of healthcare... the aspects of these >things that our distributed panel of experts agree are or should be >"always true". > I largely agree, but you are missing one crucial element. Without substantial implementation projects and feedback from these implementations into the public specifications, the specifications will most likely be very lacking. In my view, the whole standards development process for technical standards in health and much of IT has been lacking this for years - what happens is standards are published which are the result of what are essentially brainstorming sessions plus refinement according to the debating rules of the organisation. Publishing standards at this point (which is almost always what happens) is absolutely wrong in my view. Implementation is where executing the standard transforms it from static ideas on paper into dynamic systems which interact with the domain of interest. Implementation does not lead to a few small adjustments, it can lead to substantial design lessons, and changes in requirements. It's just a fact that we humans have a hard time thinking ahead enough moves to figure out how specifications will work in our heads; what we always have to do is to implement them and treat them as a simulator of some kind. >There is much (about the process of CARE) that the industry can and will >agree on. (much of this agreement already exists as "evidence based >practice guidelines" or "standard of care"). We need a way to further >formalize that agreement into a technical model of *core* healthcare >processes and information. Then we can build on it. As >healthcare-paradigms shift, we will have to absorb the shift into the >model, just as practitioners will have to implement the shift in real >care processes. Obviously, we require a model-technology that is >flexible enough to be changed... but remember, this is a MODEL... of a >REAL process. If the process can be changed (and society agree that is >SHOULD change)... and that change impacts information management... then >the world has no choice. We must change both the model and the real >processes and the information structures and record architectures... to >accommodate the better way of caring for people. > this is essentially why we use two-level modelling in our endeavours - to provide a powerful framework for doing this, without causing constant maintenance to installed systems. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
