# certification and verification of OpenEHR **Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156) **Created:** 2003-07-28 23:51 UTC **Views:** 35 **Replies:** 46 **URL:** https://discourse.openehr.org/t/certification-and-verification-of-openehr/14449 --- ## Post #1 by @lakewood Hi All, Been off looking at some operational considerations associated with supporting, maintaining and updating global EHRs\. The following types of users were considered: 1\)CREATORS \-individual, groups or organizations that must, or want to, generate new or updated EHRs 2\)REVIEWERS \-overseers, peers and formal reviewers 3\)ADMINISTRATORS \-Data management/processing 4\)CERTIFIERS \-Handles tasks associated with correctness, e\.g\., prior to use or archiving There has to be user toolkits, possibly with custom components, available for the EHRs, and perhaps many different implementations of EHRs\. There must also be administrative \(e\.g\., configuration management\), QA \(e\.g\., does it work\), evaluation \(e\.g\., workflow\) and performance \(e\.g\., does it take less time to perform a task using pen and paper?\) tools to address related operations \(note that the supporting networks and systems have been left out\)\. What kind of tools? SUGGESTION: graphical, possibly remote access and possibly wireless enabled\. WHY? Not everyone loves computers, scripting and software plus is willing to dedicate the time and energy to get some script to play right\. OPINION: Would like to see a tool that can access/breakdown different types of EHRs, support information transfer and synthesis of additional records, even a modified EHR\. Are there others on the list interested in this topic? \-Thomas Clark --- ## Post #2 by @Bill_Walton1 /big snip/ > OPINION: Would like to see a tool that can access/breakdown different types > of EHRs, support information transfer and synthesis of additional records, > even a modified EHR\. > > Are there others on the list interested in this topic? > > \-Thomas Clark Definitely\. Best regards, Bill --- ## Post #3 by @Elizabeth_Barham lakewood writes: \[ \.\.\. \] > What kind of tools? > SUGGESTION: graphical, possibly remote access and possibly wireless enabled\. > > WHY? Not everyone loves computers, scripting and software plus is > willing to dedicate the time and energy to get some script to play > right\. I'd like to see some kind of CORBA implementation personally, or at least an interface defined in IDL\. > OPINION: Would like to see a tool that can access/breakdown > different types of EHRs, support information transfer and synthesis > of additional records, even a modified EHR\. > > Are there others on the list interested in this topic? Yes\. I'm also interested in demographics and data mining FWIW\. Elizabeth --- ## Post #4 by @Sam Hi There has been some discussion on what sort of tools we need and I am interested in how to approach the whole problem\. It seems to me that messages define and information model for each transfer and that each message has to be agreed in advance\. The problem space is message definition and HL7 is filling this space at the moment\. If we have a candidate EHR reference model and archetypes to enable the development of clinical models which can be shared post hoc, then everyone can develop a 1:1 transform to this space\. The technical detail comes in understanding the set of archetypes, which we hope will be developed in chunks that mean they are relatively stable \(with development through the specialisation and revision approachs\) and only come up as candidates for a redesign that would break existing software very infrequently \(versioning\)\. We now have considerable experience in the breadth of the openEHR RM and its ability to cope with systems that are out there \- hospital and primary care\. We have only limited experience in managing the archetype space, but our new archetype development environment is coming on well and will address another generation of recording requirements in what we hope will be a solution for the next 20 years or so\. The simple description of the new approach is: Information is divided into DATA \- information for clinical care HISTORY \- timing and time scope of the data STATE \- information about the person or thing being measured that is required for interpretation of results PROTOCOL \- how the information was derived, basis of measurement To use the old blood pressure DATA \- systolic and diastolic readings HISTORY \- a one\-off or reading, a series, an average over a period, maximum or minimum over a period, variation in a series etc \(This will include 0, 5 min and 10 minute readings, a change between readings \(postural drop\) etc\) STATE \- patient position, exercise etc PROTOCOL \- sphygmomanometer, intra\-arterial Our analysis at the moment is that the following configurations are useful: \[ \] = optional DATA \+/\- PROTOCOL DATA \+ STATE \+/\- PROTOCOL HISTORY \+ DATA \+/\- PROTOCOL HISTORY \+ DATA \+ STATE \+/\- PROTOCOL DATA \+/\- PROTOCOL HISTORY\+DATA --- ## Post #5 by @thomas.beale Hi Thomas, lakewood@copper\.net wrote: > Hi All, > > Been off looking at some operational considerations associated with > supporting, maintaining and updating global EHRs\. > What was your study to do with? Our analysis of possible EHR users is that most people would use regional EHRs, i\.e\. EHRs which are embedded in the healthcare network in which they normally live\. Issues of consent, privacy, security, as well as technical and clinical issues can be determined in advance on a regional basis, and set up wiith appropriate contracts\. When such patients have a health problem outside this jurisdiction, e\.g on holiday overseas, and ad hoc requeest for health data needs to be possible \- where there will be no advance contracts, security clearances etc\. However, some patients are always on the move\. Military, aid workers, elite athletes, conference speakers, entertainers, airline staff and so on\. THey can routinely have a problem anywhere in the world\. So their EHR needs to be set up in a different way \- probably served from a secure webportal which the network of carers for that kind of person will have secure access, also set up in advance\. But these people can also need medical help outside their routiine care network, and communications of part of the EHR will again devolve to ad hoc requests and replies, where security and privacy have to be worked out on the spot\. > The following types of > users were considered: > 1\)CREATORS > \-individual, groups or organizations that must, or want to, generate new or > updated EHRs > 2\)REVIEWERS > \-overseers, peers and formal reviewers > can you define this role in more detail to do with EHRs? Do you mean senior medical staff? > 3\)ADMINISTRATORS > \-Data management/processing > 4\)CERTIFIERS > \-Handles tasks associated with correctness, e\.g\., prior to use or archiving > also this role > There has to be user toolkits, possibly with custom components, available > for the EHRs, and perhaps many different implementations of EHRs\. There must > also be administrative \(e\.g\., configuration management\), > you will see that the basic of configuration management are in the COmmon RM \(http://www.openehr.org/Doc_html/Model/Reference/common_rm.htm) > QA \(e\.g\., does it > work\), evaluation \(e\.g\., workflow\) > clinical workflow is a big area, and will most likely have its own services, but very closely bound in with the EHR > and performance \(e\.g\., does it take less > time to perform a task using pen and paper?\) tools to address related > operations \(note that the supporting networks and systems have been left > out\)\. > I think all of what you are saying relates to IT / software engineering quality assurance measures? > What kind of tools? > SUGGESTION: graphical, possibly remote access and possibly wireless enabled\. > > WHY? Not everyone loves computers, scripting and software plus is willing to > dedicate the time and energy to get some script to play right\. > > OPINION: Would like to see a tool that can access/breakdown different types > of EHRs, support information transfer and synthesis of additional records, > even a modified EHR\. > there are two approaches to this\. One is where the source "EHR" systems are legacy databases, and don't obey any models\. THere are approaches to getting data using archetypes to model it, but of course they are not completely simple \- most legacy databases have different, annoying schemas\.\.\.\.you have to extract the raw data, match columns and rows to target structures, synthesis missing bits etc etc\. The other approach is when we are talking about moving information from/to EHR systems which obey openEHR or some other accepted standard for which we can write interoperability software much more easily\. Then interoperability is largely a matter of archetypes\. \- thomas --- ## Post #6 by @Christopher_Feahr Dear Group, I have just recently joined your listserve, and have been actively participating in the HL7 EHR ballot discussion for only a few weeks\. During the four years prior to that, I had been swimming in the HIPAA\-EDI ocean, trying to figure out how the operational costs for 450,000 smaller providers would ever be lowered under our transaction rule\. The answer is, "they won't\.\.\. costs will increase"\. While HIPAA is arguably "another story", but I believe that the failure of the transaction rule to be embraced by our fragmented US provider community is closely related to the elusive success of the "standard EHR" effort\. I have the distinct sense that our global EHR conversation is much closer to the heart of The Beast for small providers than the HIPAA slugfest will ever be\.\.\. and much more likely to bring sanity to providers lives\. Hence, my keen interest in it\. Nevertheless, I sense an implied constraint throughout most of the discussions I have listened to\.\.\. caused I think, by the almost single\-minded focus on the attributes of the information \*container\*, rather than on the health information, itself\. Containers and container systems were certainly a major constraint in the days of paper, and most providers still seem to cling to that "primary repository" or "medical chart" model even after "going paperless"\.\.\. as doctors like to say in the US\. "EHR" discussions seem to presume that we are still constrained by an overwhelming need for a monolithic, physical record system that has to "live" somewhere\.\.\. all in one piece\. Constraining every enterprise system to the same physical record architecture is always denied as an ultimate objective of "EHR"\.\.\. although that \*would\* be a path to a fairly high level of user\-system interoperability\.\.\. it's just that no one would agree to do it\. EHR Dream \#2 seems to be a Big\-EMR\-in\-the\-sky, with which all user systems could remain synchronized\. Again, that would certainly lead us toward a useful level of interoperability, assuming that the most trustworthy entity \(the U\.S\. govt\.? United Nations?\) agreed to maintain the repository\-in\-the\-sky, to which over one million enterprise systems would have to be rigorously mapped\. But even if that were reasonably implementable, it makes providers uncomfortable\.\.\. the idea of their records being "stored" with millions of "foreign" records in some far off place \(like India\), rather than in the safety of their back rooms\.\.\. or just down the street\.\.\. or at least in the same state or county\. Have we asked providers to sit down and \*really\* articulate these fears?? These are paper\-tiger issues\. Attempting to standardize PMS applications on a generic record format for each major care domain/setting is obviously pointless\. Doctors and PMS vendors simply will not agree\.\. mainly because neither will even bother attending the standards meetings\. \(note how enthusiastically this community is embracing EDI under the federal mandate of HIPAA\.\.\. and how compelling small provider demand currently is for EDI\-enabled products\. Lack of perceived demand is the main reason that small PMS vendors don't bother attending SDO meetings to learn how to build them\)\. On the other hand, I believe that a standard \*information\* model for the entire industry, with granular sub\-models developed for each care domain/setting\.\.\. would not only be possible to create, but would pave the most direct road toward useful interoperability\. I believe that PMS vendors would voluntarily respect such a standard\.\.\. and would hugely appreciate the freedom to design whatever record architectures they wanted\. Step \#1 would be to develop a universal \*process\* model, by painstakingly abstracting the non\-controversial requirements of published, evidence\-based practice guidelines\. That will be the "heavy lifting" and the part requiring documented and extensive vetting by practicing physicians and other stakeholders\. From the process model, however, we should be able to spin off a universal information model for Healthcare\. Who would choose not to conform to such a model? Providers will happily agree to execute care processes in almost exactly the same way\.\.\. according to standard\-of\-care guidelines\. And all machine\-to\-machine messaging would have to be concerned with is the use of standard information elements, defined by a standard XML schema, driven by the standard model\. It seems to me that the thing most in need of standardizing across the healthcare industry, is the information that goes INTO \[an almost uncountable \# of\] user\-specific record formats\. We need to encourage providers to shift their focus from the \*records\* to the elements of health care information\. The goal is to have the right information elements in front of the right eyes just in time to support the execution of the right healthcare process\. It should not matter what sort of centralized or distributed record architecture the information either came from or is headed toward\. All you need is a \*standard\* registry connected to the user system that knows where to look for the information that the user is demanding\. If that registry doesn't point directly to a repository containing the desired patient information, it could poll the other registries\. We could have millions of fragmented/distributed and even duplicative repositories of health information, but only one registry is required\.\.\. although a handful of standard registry services could also be supported without significant degradation in service\. \(Consider, for example, our DNS system and how smoothly the internet functions, despite the number of domain name registrars and DNS services that exist\.\) Has the group discussed this general approach? For a longer and, perhaps more organized dissertation, please see my article at http://visiondatastandard.org/draftstandard.html , along with a draft ISO report, providing some additional background\. Thanks for listening\! Best regards, \-Chris Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #7 by @Thomas_Clark Hi All, I would like to add a big 'RIGHT\-ON' to Christopher's contribution\! > From the operations viewpoint cost is a major factor and when significant precludes participation by parties and organizations that should be involved\. Also, the healthcare industry cannot be described as a homogeneous group of individuals working for the common good, and perhaps the Patient's health\. What is noticeable is that different groups/disciplines rarely communicate effectively and are often at odds over even small matters with 'turf control' a common factor\. I recently attempted to get a handle on how county operations handle everything from budgets to HIPAA\. Unfortunately even volunteers have a difficult time being accepted and integrated\. What is noticeable is that they jealously guard their current processes, procedures and suppliers to the extent that modifications, upgrades and new methods and technologies are rejected\. My suspicion is that they have learned this behavior simply because budget constraints and consecutive budget cuts have placed them in a primarily survival mode\. Administrators are less friendly and politicians are notable for their lack of commitment\. The healthcare system is already 'locked' in a mode where even small sections are unable to modify and/or improve current operations\. An expanding population will render this state of affairs defunct\. My characterization of the healthcare industry is a group of not\-necessarily\-connected small universes within which specialties withdraw into semi\-permeable spheres in an attempt to create another small universe\. Imposing order in a cost\-efficient/effective manor is likely to be rejected soon or very soon after introduction, i\.e\., failure is a sure bet\. Occasionally bright stars appear but too often are teaching/research personnel and organizations\. En masse the deficiency in Patient\-centric care is having major impacts on public sentiment which in turn has a dark side\. Patient\-centered healthcare is the main target\. HOW DOES OpenEHR FIT INTO THIS? It is a global healthcare industry that is of interest with regional and local industries playing major roles\. Important are major factors covering healthcare disciplines and Patient specifics, e\.g\., cultural, ethnic, language, social, age, medical, dental, mental and work \(certainly not an all\-inclusive list\)\. Within the five minutes allocated per Patient by an HMO try resolving some of these issues during an office visit or, perhaps, a visit to an Emergency Room\. Before IT can approach and render a local design for a significant number of these issues there are important criteria, requirements, objectives, goals and administrative issues that need to be resolved positively\. OpenEHR must be accommodating to the extent that global regions and a global industry can use it as a bridge and transport\. It must be more than a simple record\-keeping system; it must include content management and communications capabilities\. As a tourist with a medical condition from Chicago, traveling in Paris and requiring immediate medical attention my preference would be for a system that supports language translations and common record sub\-formats that allow the attending physician to diagnose the problem, attend to it and update Paris and Chicago records\. > From an IT viewpoint it is a pipeline that supports applications requiring access, filtering, data translation, communications \(perhaps with another Practitioner\), auditing, backup, anticipatory storage and all in real\-time\. An adaptable 'standard \*information\* model' with 'granular sub\-models' is necessary and can incorporate Practitioner, Patient and Administrator components\. Interoperability with existing and 'planned' systems is necessary as well\. Merging one or more foreign data sources into a single data source would be desirable in an integration effort\. Quote \(Chris\): 'We need to encourage providers to shift their focus from the \*records\* to the elements of health care information' Practitioners need to look at how they use current records systems and how multiple Practitioners interface on healthcare processes, procedure and issues\. Medical errors occur too frequently when Patients are passed from one group/Practitioner to another, e\.g\., a trip to the operating room involving insufficient or incorrect information\. GLOBAL SUPPORT SYSTEM This remain a tough nut to crack, a major problem involving different social/ economic/ethnic/political/insurance/access boundaries\. It is not an impossible task since other industries function well today across the same boundaries\. KNOWLEDGE\-BASED SUPPORT Many repetitions of a process/procedure may be necessary/required \(e\.g\., policy/regulations\)\. Many may not so constrained\. Automatic Knowledge\-based processes and procedures can alleviate workloads and bottlenecks\. When properly identified, processes and procedures included within an OpenEHR record can significantly contribute to data mining and processing that will support future evaluations and performance studies that could lead to further enhancements and modifications\. Decision\-support and feedback on past, current and planned processes and procedures can support Practitioners as well evaluate them\. It can also benefit Patients\. RECORD ARCHITECTURE Chris's comments about: 'centralized or distributed record architecture' are significant because: 1\)Patients are unique 2\)Patient healthcare is unique and may be affected in different ways by applied processes, procedures, medications, Practitioners 3\)There are considerably more Patients than models and exceptions are bound to kill the model quickly 4\)Healthcare evolves through research, application, experience and learning\. Such evolutionary processes should not be burdened with model modifications\. My preference is for viewing a Patient's healthcare as an adaptable object that can inherit from ancestors and healthcare\-related objects \(e\.g\., disease, ethnic, cultural, social, mental, work, environmental\)\. Embedded in this is OpenEHR as much more than a record\-based system\. Regards\! \-Thomas Clark --- ## Post #8 by @Tim_Churches > Hi All, > > I would like to add a big 'RIGHT\-ON' to Christopher's contribution\! > > >From the operations viewpoint cost is a major factor and when significant > precludes > participation by parties and organizations that should be involved\. Also, > the healthcare > industry cannot be described as a homogeneous group of individuals working > for the > common good, and perhaps the Patient's health\. > > What is noticeable is that different groups/disciplines rarely communicate > effectively > and are often at odds over even small matters with 'turf control' a common > factor\. > > I recently attempted to get a handle on how county operations handle > everything from > budgets to HIPAA\. Unfortunately even volunteers have a difficult time being > accepted > and integrated\. What is noticeable is that they jealously guard their > current processes, > procedures and suppliers to the extent that modifications, upgrades and new > methods > and technologies are rejected\. My suspicion is that they have learned this > behavior > simply because budget constraints and consecutive budget cuts have placed > them in a > primarily survival mode\. > > Administrators are less friendly and politicians are notable for their lack > of commitment\. > > The healthcare system is already 'locked' in a mode where even small > sections are > unable to modify and/or improve current operations\. An expanding population > will > render this state of affairs defunct\. > > My characterization of the healthcare industry is a group of > not\-necessarily\-connected > small universes within which specialties withdraw into semi\-permeable > spheres in an > attempt to create another small universe\. Imposing order in a > cost\-efficient/effective > manor is likely to be rejected soon or very soon after introduction, i\.e\., > failure is a > sure bet\. > > Occasionally bright stars appear but too often are teaching/research > personnel and > organizations\. En masse the deficiency in Patient\-centric care is having > major impacts > on public sentiment which in turn has a dark side\. Patient\-centered > healthcare is the > main target\. > That might be an accurate description of the US healthcare system, but thankfully the US system is restricted \(more or less\) to the US, despite attempts to export it and despite attempts by misguided politicians elsewhere to copy it\. For example, in the UK the NHS provides an rather more unifying funding and governance body for the majority of healthcare activity\. Sure, the NHS itself is a series of fifedoms and city\-states, but there is still a sense that it is one organisation, and influence on the fifedoms via purse strings is strong\. A similar situation for secondary and tertiary care obtains here in Australia, and even primary care is notonally covered by universal health insurance\. Thus, although dreams of regional or national EHRs seem far\-fetched in the US, they are achievable elsewhere, I think, and perhaps within a decade\. Tim C --- ## Post #9 by @Thomas_Clark Hi Thomas, Comments in text\. --- ## Post #10 by @thomas.beale Christopher Feahr wrote: > Dear Group, > I have just recently joined your listserve, and have been actively > participating in the HL7 EHR ballot discussion for only a few weeks\. > During the four years prior to that, I had been swimming in the > HIPAA\-EDI ocean, trying to figure out how the operational costs for > 450,000 smaller providers would ever be lowered under our transaction > rule\. The answer is, "they won't\.\.\. costs will increase"\. While HIPAA > is arguably "another story", but I believe that the failure of the > transaction rule to be embraced by our fragmented US provider community > is closely related to the elusive success of the "standard EHR" effort\. > I have the distinct sense that our global EHR conversation is much > closer to the heart of The Beast for small providers than the HIPAA > slugfest will ever be\.\.\. and much more likely to bring sanity to > providers lives\. Hence, my keen interest in it\. Nevertheless, I > sense an implied constraint throughout most of the discussions I have > listened to\.\.\. caused I think, by the almost single\-minded focus on the > attributes of the information \*container\*, rather than on the health > information, itself\. > > Containers and container systems were certainly a major constraint in > the days of paper, and most providers still seem to cling to that > "primary repository" or "medical chart" model even after "going > paperless"\.\.\. as doctors like to say in the US\. "EHR" discussions seem > to presume that we are still constrained by an overwhelming need for a > monolithic, physical record system that has to "live" somewhere\.\.\. all > in one piece\. Constraining every enterprise system to the same physical > record architecture is always denied as an ultimate objective of > "EHR"\.\.\. although that \*would\* be a path to a fairly high level of > user\-system interoperability\.\.\. it's just that no one would agree to do > it\. > I see the state of thinking as follows: \- existing providers, including hospitals, labs, GPs, will in many cases keep their existing EMR systems \(all different etc\) \- the shared\-care health record is likely to be installed as a new system on a regional or even national basis in some places\. \- what is standardised is the shared\-care EHR and its interfaces\. EMR systems have to send some percentage of their innformation to the EHR \- most likely, GPs will start using the EHR directly \- providers that decide to adopt the same technology as the shared care EHR will obviously have an easier time of shipping information in and out Our analysis so far is that these EHRs will have to be "consolidated" rather than purely federated \(i\.e\. pieces integrated in real time for display\), since there are many problems with relying on feeder EMR systems to be responsive for real\-time queries\. These include different querying languages, different security models, differing latencies, network unavailability etc\. Another major reason for consolidation is that soure systems may have all kinds of detail which is of no long term interest to the shared care, longitudinal EHR \- hence some kind of filtering between feeder systems and the EHR has to occur\. \(Defining the filter functions will not necessarily be that simple\.\) A third major reason is that doing writes to the EHR can only be realistically be done to one place with a defined architecture\. Doing distributed writes to a multitude of different back\-ends has been proven many times to be nearly impossible to do reliably; to make it reliable would cost exorbitantly\. The kind of communication needed to enable EMR <\-> local shared care EHR communication can be based on contractual agreements set up in advance\. Regional EHRs would take care of most people, most of the time\. However, there stil needs to be a way of enabing ad hoc requests and replies for situations in which patients have health problems in unexpected places\. There also need to be communication mechanisms for patients who are always mobile, such as military, aid workers etc\. These mechanisms will be virtual federation, supported by resource location/indexing systems\. So in the end, I believe a distributed system of consolidated EHRs, with will be the way to go\. > EHR Dream \#2 seems to be a Big\-EMR\-in\-the\-sky, with which all user > systems could remain synchronized\. Again, that would certainly lead us > toward a useful level of interoperability, assuming that the most > trustworthy entity \(the U\.S\. govt\.? United Nations?\) agreed to maintain > the repository\-in\-the\-sky, to which over one million enterprise systems > would have to be rigorously mapped\. But even if that were reasonably > implementable, it makes providers uncomfortable\.\.\. the idea of their > records being "stored" with millions of "foreign" records in some far > off place \(like India\), rather than in the safety of their back rooms\.\.\. > or just down the street\.\.\. or at least in the same state or county\. > Have we asked providers to sit down and \*really\* articulate these > fears?? These are paper\-tiger issues\. > firstly, anyone who thinks it is a good idea to put EHR data for e\.g\. US citizens living in Idaho, in India, has not studied the problem\. Secondly, the issues of fear are not necessarily "paper tigers" \- one fear that occurs is that providers who currently have total local control over patient information think they will lost control, or become irrelevant when shared EHRs come into being\. This has to be addressed, and mechanisms for identifying who is managing the patient's health have to be thought about, to allow clinicians to continue to operate with confidence, even when their information is now part of a shared database\. > Attempting to standardize PMS applications on a generic record format > for each major care domain/setting is obviously pointless\. Doctors and > PMS vendors simply will not agree\.\. mainly because neither will even > bother attending the standards meetings\. \(note how enthusiastically this > community is embracing EDI under the federal mandate of HIPAA\.\.\. and > how compelling small provider demand currently is for EDI\-enabled > products\. Lack of perceived demand is the main reason that small PMS > vendors don't bother attending SDO meetings to learn how to build them\)\. > well\.\.\. this situation is probably different around the world\. In the UK, France, Netherlands, Germany, Australia\.\.\.GPs are very interested in standardisation, and in the UK it has the greatest foothold in GP systems\. > On the other hand, I believe that a standard \*information\* model for the > entire industry, with granular sub\-models developed for each care > domain/setting\.\.\. would not only be possible to create, but would pave > the most direct road toward useful interoperability\. I believe that PMS > vendors would voluntarily respect such a standard\.\.\. and would hugely > appreciate the freedom to design whatever record architectures they > wanted\. > this is the work of openEHR, as you may have guessed by now\.\.\.\.the key to understanding what is going on here is that it is a "two\-level modelling" approach\. THis is a new paradigm of modelling in which relatively simple, generic information models are developed \(you can see them all documented at http://www.openehr.org/cgi-bin/document_list) and domain and business definitions are created in the form of archetypes, which is part of the "knowledge space", or second level of modelling\. \(See http://www.oceaninformatics.biz/adl.html for a primer on archetypes\. THere are already two prototype tools that edit archetypes based on information models prior to openEHR; openEHR tools are now starting to emerge\) > Step \#1 would be to develop a universal \*process\* model, by > painstakingly abstracting the non\-controversial requirements of > published, evidence\-based practice guidelines\. That will be the "heavy > lifting" and the part requiring documented and extensive vetting by > practicing physicians and other stakeholders\. From the process model, > however, we should be able to spin off a universal information model for > Healthcare\. Who would choose not to conform to such a model? Providers > will happily agree to execute care processes in almost exactly the same > way\.\.\. according to standard\-of\-care guidelines\. > well, I don't know if this is true\. And in any case, process models are one way of seeing things, but not all clinical information is an instance of a process model\. Our approach so far has been to provide \_very\_ generic models of record management and information recording \(including version control, auditing, attestation, linking, etc\), and enable almost all domain level concepts to be expressed in the second level of models, whose job at runtime is to configure data defined by the information models\. > And all > machine\-to\-machine messaging would have to be concerned with is the use > of standard information elements, defined by a standard XML schema, > driven by the standard model\. > > It seems to me that the thing most in need of standardizing across the > healthcare industry, is the information that goes INTO \[an almost > uncountable \# of\] user\-specific record formats\. We need to encourage > providers to shift their focus from the \*records\* to the elements of > health care information\. The goal is to have the right information > elements in front of the right eyes just in time to support the > execution of the right healthcare process\. > that's certainly the goal we see \- "the right information in the right place, at the right time", and it's one of the reasons why pure federation systems will probably never work as EHRs\. But to standardise the information that goes into records, you need to standardise: \- the logical information model\(s\) in which it is expressed \(how it ends up in databases is local business\) \- the knowledge models that defiine its validity > It should not matter what sort of centralized or distributed record > architecture the information either came from or is headed toward\. All > you need is a \*standard\* registry connected to the user system that > knows where to look for the information that the user is demanding\. > here you are getting back to pure federated systems, which I think are probably a nice fantasy for EHRs, but won't work well in practice, for reasons I mentioned above\. However, it will be needed for the ad hoc category of queries between systems where no previous contractual arrangement was set up, as will occur with patients outside of their normal healthcare environment \(e\.g\. overseas or interstate on holidays\)\. > If that registry doesn't point directly to a repository containing the > desired patient information, it could poll the other registries\. We > could have millions of fragmented/distributed and even duplicative > repositories of health information, but only one registry is required\.\.\. > although a handful of standard registry services could also be supported > without significant degradation in service\. \(Consider, for example, our > DNS system and how smoothly the internet functions, despite the number > of domain name registrars and DNS services that exist\.\) > yes, this is what is required to support global EHR communication\. Some aspect of registry may be needed for regional shared care EHRs as well, if it is thought that there needs to be an index of every item in every EMR available inthe shared care environment, but I have doubts about the cost\-benefit of this one\. A talk I gave in mexico recently about this whole subject is here \(http://www.oceaninformatics.biz/publications/EHR_vision.zip \- sorry it's in PPT, but contains a lot of animation, so might serve as a useful illustration of the ideas\)\. > Has the group discussed this general approach? For a longer and, > perhaps more organized dissertation, please see my article at > http://visiondatastandard.org/draftstandard.html , along with a draft > ISO report, providing some additional background\. > thanks for a very interesting post\. \- thomas beale --- ## Post #11 by @thomas.beale I should have also mentioned another reason why local EMRs have to be left intact, at least for the time being \- it is te psychological one that their owners will not feel as if they are having their system taken away from them\. \- t --- ## Post #12 by @thomas.beale Thomas Clark wrote: >> What was your study to do with? >> this is the meat of the problem\.\.\. > STUDY: > > \-several counties in California and Nevada ranging from agriculture to > forestry > and their current healthcare systems > \-current budgetary constraints and potential for new funding > \-can they develop county\-wide and state\-wide healthcare systems that > incorporate an OpenEHR\-based system > \-can they get support from the federal government > \-how are they handling HIPAA > \-can they integrate individual and small groups of Practitioners > \-can they handle current levels of care for current populations > \-are their open\-source solutions currently available that could be used by > county personnel to introduce and maintain a EHR/EMR system > I certainly can't answer all these questions, and clearly answers would take time to emerge based on actually doing some trials there\. However, I think we can say the following: \- openEHR is certainly destined for regional EHR systems, with mixed users, including small providers \(and big ones\) \- there are open source solutions which are leaning toward openEHR eventually becoming the EHR engine, including Torch \(http://www.openparadigms.com/), Gnumed \(http://www.gnumed.org/resources.html), openEMed \(http://sourceforge.net/projects/openmed). A community worth belonging to is the Open Source HealthCare Alliance \(OSHCA\), see http://www.oshca.org/. \- openEHR is an open community, and is essentially an open but disciplined software engineering enterprise, so people in the community can make changes and have influence\. US govt support is always an interesting question \- the US government is congenitally doomed to think that solutions from outside the US a\) don't exist, b\) are rubbish or c\) should be secretly replicated and then badged as US innovations\. This is not a point of view held by all experts or developers inthe health IT domain, particularly OS developers, but it is certainly entrenched\. Breaking it requires internal advocacy on the part of the enlightened\! > NOTE: > \-restricted to individual counties and counties that have an established > inter\-county organization > i\.e\. ones who can agree to set up compatible information governance and sharing agreements? > \-homeless and transient healthcare a major problem and remains so\. > I think that the approach of indexes/health resource location service \+ ad hoc requests/replies will be the go for transients\. Homeless people is a challenge in the health system in general, and I suspect a lot of the problem is outside the realm of IT, i\.e\. identification, compliance, recalls etc\. But we do need to design for the reality of processes which don't go according to plan \- we certainly cannot design for perfect patients\. Here in Australia dodgy/multiple patient identifiers are a big problem in rural & indigenous population, and somewhat so elsewhere\. Connecting fragments of health information together form inside multiple patient contact points where the id information is unreliable is a known challenge, and I have seen some good work in France on this \(based on the idea that even if you can't figure out who this person \_really\_ is, you don't care that much; what you do care about is determining if the various fragments of health inforation actually relate tothe same person, to give some hope of building a coherent picture of them\)\. openEHR is trying to be cognisent of such problems \- the EHR design makes nearly no assumptions about ids \- that problem is outsoruced to the demographic system\. Status/state of execution of treatment regimes, recalls etc we think will be pretty well handled by archetyped state machines and process models which are under development now in the workflow area\. But \- making sure this stuff works will of course be up to the whole community to be invlved in design, implementation testing and feedback\. > \-within each county there are major disconnects between different > departments > and services > \-county healthcare services are over\-burdened, under\-funded, under\-staffed > and in constant danger of closure > i think these points relate to deployment strategies \(if you were ever to get that far;\-\) \- don't change the work practices of clinical & allied health workers in a revolutionar way \(make it evolutionary\), and make sure the overall and ongoing costs can be met, including retraining etc\. But the promise of clinician involvement in writing their own archetypes and templates could also have a benficial effect \- this is where the health workers get to be inthe driving seat\. Compared to the classic kind of IT in most current systems, this is one area we hope will drive engagement and positive reception of things like openEHR\. > \-governments seem to make matters worse > \-charities and welfare agencies are unable to participate for a long list of > reasons > \-in\-place IT Departments are over\-loaded > this last one could be radically changed it things moved to standards\-based relatively lightweight back\-end EHR components with a knowledge framework built around that, instead of enormous, unmaintainable databases and chaotic cross\-feeds etc\. >> can you define this role in more detail to do with EHRs? Do you mean >> senior medical staff? >>    > CREATORS > > The bulk of Patients are handled by staff, some untrained, e\.g\., admitting\. > They > \(admitting, etc\) require automatic, form\-based software applications and > lots of it\. > > RNs and LVNs carry the load; fewer numbers of doctors do the major work, > senior medical staff, where present, and chasing funding and performing > administrative duties\. A local county hospital can admit a Patient and setup > billing but does not know how long a Patient is resident or when they > actually > leave\. The floor nurse has to check the beds and report on who is in and who > is out\. > I guess this is really an argument for a proper analysis of time\-wasting admin procedures, and how better IT systems can reduce the loss and get doctors back to working with patients\. > Certainly better than nothing but needing considerably more\. The hospital > Administrator was just involved in a serious controversy because of a budget > item for an ABSOLUTE BOTTOM\-LINE Catscan system \(first in the county\)\. > There will be no computer system connection\. > > This has been added to show that there are many Practitioners and staff that > SHOULD be CREATORS but cannot be because of UNAVAILABILITY\. > A local county resident can travel globally with the assurance than NO > medical > record could be accessed by any regional, national or foreign Practitioner\. > I would say that that is the situation for most patients globally\.\.\. There is a lot of other interesting stuff in this post which I'm sure the list will be interested in chewing over\.\.\. \- thomas beale --- ## Post #13 by @Philippe_AMELINE1 Hi, >> Constraining every enterprise system to the same physical >> record architecture is always denied as an ultimate objective of >> "EHR"\.\.\. although that \*would\* be a path to a fairly high level of >> user\-system interoperability\.\.\. it's just that no one would agree to do >> it\. > > I see the state of thinking as follows: > \- existing providers, including hospitals, labs, GPs, will in many cases keep their existing EMR systems \(all different etc\) > \- the shared\-care health record is likely to be installed as a new system on a regional or even national basis in some places\. > \- what is standardised is the shared\-care EHR and its interfaces\. EMR systems have to send some percentage of their innformation to the EHR > \- most likely, GPs will start using the EHR directly > \- providers that decide to adopt the same technology as the shared care EHR will obviously have an easier time of shipping information in and out There is certainly a feeling in the air that each place of care can't remain a "care island" in the ocean\. We probably can talk a very long time about models, architectures, standards\.\.\. in order to allow various form of communication\. As someone that as been working on very practical solutions in that field for some years, I can introduce \(very\) shortly two major concepts : \- Be usefull It certainly seems to be a dumb advice ; of course no one will ever build a useless system ;o\) However, since we are talking about communication, the system must be usefull for each and every party\. So, if you want to adress the continuity of care issue, the system must be usefull for the patient, the GP, the hospital practitionner and so on\. I mean they must use it, and not only benefit from it ; so I mean the patient must use it and not only be the "center of it"\. \- Subsidiarity It is a complex word, but the meaning is simple : let the wider system concentrate ONLY on functions that narrower systems can't offer\. For us it means two orthogonal considerations : a genuine "functionnal axis" \(put the proper functionnalities on the proper system\), and a "data storage axis" \(store the proper data on the proper systems\)\. Best regards, Philippe --- ## Post #14 by @Christopher_Feahr Thomas, Thank you for your comments\. At the moment, the healthcare industry relies on a federated, duplicative system of paper and electronic records\. The fragmentation of provider\-resources and of healthcare tasks themselves, combined with the long life spans and great mobility of patients are probably the main causes for a person's health data to be spread around so much\. I don't foresee any social or other changes that would ever drive the data to be more contiguous\. In a particular instance of CARE, however, it can be vitally important to create an ad hoc, record or view of SOME of the patient's health data\.\.\. just enough to support what the clinician or administrator needs to do at that moment\. Each user will want his local EHR system designed expressly to support his local needs\.\.\. and he will want to maintain a local repository of all the data he has created or collected about his patients\. I think that's a good idea\. If agencies like CDC were to also create giant, global repositories for specific purposes\.\.\. say, to collect data about all communicable disease events in the world\.\.\. then each provider system might be required \(perhaps by regulation, in the U\.S\.\) to continuously update this disease registry with defined report\-messages\. The resulting CDC repository would, in addition to its utility in helping CDC control spread of disease, also become a useful historical record of a person's diseases over his lifetime\.\.\. but not necessarily a record of all the patient's surgeries, dental procedures, eyeglass prescriptions, etc\.\. Presumably other repositories would be built by people who cared about those areas of public health\. Each user of health information essentially maintains a repository\. Large repositories, constructed for specific purposes, would have a secondary utility as points of synchronization for doctor's records\. If 6 different doctors are treating Mrs\. Jones over a 10 year period, but during the last year she has seen primarily her oncologist\.\.\. each time the oncologist updates a cancer registry or other big data repository, that little part of her "federated, global health record" is essentially updated for all "interested providers" to see\. As her other5 doctors connect to these registries \(for reasons having nothing to do, necessarily, with Mrs\. Jones\) their systems will also "notice" the presence of an updated record for Mrs\. Jones\.\.\. downloading her latest cancer status info, what drugs she is taking now, new drug allergies discovered, etc\.\.\.\. what ever these 5 other provider systems have been programmed to "care about"\.\.\. and her local records in those 5 other offices become \[more\] current\. I'm not sure we are quite ready to think about the big "EHR\-in\-the\-Sky" repository that exists ONLY for the purpose of keeping local user records in synchrony\.\.\. although we seem to be drifting toward that model and it is probably an achievable model\. The main repository for such a model could live nicely in India or anywhere\. I am NOT a security expert, but I know that you would have at least a couple mirror sites and other redundancy built in\. AND\.\.\. perhaps of greatest comfort to providers\.\.\. each provider's local EHR system remains always intact and always kept up\-to\-the\-minute through record refreshes each time he connects to the \[hopefully, small number of\] global repositories\. Step \#1 still seems to be agreement on ONE standard information model\.\.\. with only the constraints that are invariably required for each particular element of health data\. Archetypes that express additional business rules about the information and relate it to other information elements will be much more difficult to agree on\. I think we should try to standardize that layer eventually, but that will require a very efficient mechanism to be constructed for getting input from doctors without them having to attend standards meetings \(because they won't attend\!\)\. In my view, the EHR effort\.\.\. partly by virtue of the inclusion of the "record" concept\.\.\. is starting at too complex a level\.\.\. at a point where we are almost designing a particular business management system in the standard\. A rule\-free standard model for the INFORMATION should exist first\. From what I understand, SNOMED CT is a very good start on that\. Also as a standard, we should make an effort within each care domain to model the actors, places, and things in healthcare, the relationships between them that are always true, and the relationships among the information elements that are always true\. This can serve as a useful framework or high\-level model for the much more granular and often unique process and information models of each local user\-enterprise\. \-Chris Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #15 by @Thomas_Clark Hi, The 'users (hospitals and specially the doctors)' are contributors to the fragmentation and isolation that prevails in the healthcare fields globally. Other contributors include governments at all levels, insurance companies, regulators and judicial systems at all levels. Which political systems attempt to support individuals with rights, rules, regulations that ensure proper, sufficient, competent healthcare practiced by properly trained, administered and regulated Practitioners? There are some but too few. I am mindful of the state of the healthcare industry in the US and the EU and often debate the differences. Setting levels of expectation at just a percentage of GDP is insufficient. Finding someone in the EU that will trade insurance premium payments with me is considerably harder to accomplish. Yes I believe that politics plays a role in healthcare, especially since governments are great 'allocators of resources'. Having said this I should point out that individuals are ultimately responsible for their governments and hence responsible for the allocation of resources to healthcare. We are contributors as well. I agree that in some respects 'users (hospitals and specially the doctors)' 'get what they deserve...'. Drilling deeper into each category (hospitals and doctors) has convinced me that this requires modifications since individual cases point out that control is absent. Doctors working for US HMOs are a case in point. Where you find the healthcare industry today is exactly where they put themselves. Historically they have received widespread unquestioning support which has gradually eroded. People understand the needs better and realize that there is a better way. Suppliers are typically business selling products and services into an industry that has established requirements, needs and objectives. They have some impact on the market based upon the products and services they provide. Would not place them in the key groups of parties responsible for the current for the current healthcare industry. The OpenEHR project is not a solution to the current state of the healthcare industry. It does, however, represent a trend that can place tools in the hands of Practitioners and Patients permitting them exercise control over information in a cost-effective and efficient manner. The 'users (hospitals and specially the doctors)' are quite diverse globally. A basic requirement for the OpenEHR project should be adaptable structure and applications. -Thomas Clark --- ## Post #16 by @Christopher_Feahr Philippe, Thank you for the comments\. I believe that we will have "islands" of health information for a very long time\.\.\. for many reasons, some of which are not technically sound, but more the result of convention\. On the other hand, the "islands" do facilitate an inherent security and fault\-tolerance\. "Bombing" one island would never destroy the greater system\. We just need to ensure that each island is able to connect periodically to a global repository\-network\.\.\. for updating/refreshing\.\.\. and that we have robust access control and ways to determine how reliable the data is\. Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #17 by @Christopher_Feahr Thomas, Thanks\! And I hardly know where to begin responding\.\.\. but I do like all of your comments\. The thing about providers being considered "a homogeneous group of individuals working for the common good" is really a matter of philosophical and, perhaps, spiritual orientation\. I agree that we \(providers\) do not always behave this admirably\! But you are also DEAD ON with your comments suggesting that single\-minded user\-focus \(on the user's OWN needs, as opposed to the needs of the greater healthcare community\) is related to most users being permanently stuck in "survival mode"\. Businesses are struggling to survive\.\.\. more and more BECAUSE of the escalating costs of driving the health care bus through the information quagmire\. Insurance interests ARE taking more control over who does what in healthcare\.\.\. but not \[always\!\] out of a megalomaniacal interest in controlling providers\.\.\. but mostly to get control of the COSTS that providers seem to be powerless to control themselves\.\.\.\. again, because providers have pathetic software\.\.\. because no one can build the software they need\.\.\. because we lack sufficient standards to give application developers sufficient confidence that doctors would actually buy the software if they did build it\! We are not trying to decide whether breaking out of this death\-spiral is a good idea\. Our only task now is to decide HOW to break out of it\. It's not sufficient to say that providers have what they deserve because they've refused to agree on something better \(for their patients\)\.\.\. unless we first imagine and then create for them a mechanism whereby they CAN agree\. 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"\. 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\. We never want to change\.\.\. yet we always do\. The proponents of change always want it to go faster, but I am learning that rapid change ALWAYS causes unnecessary suffering within a system as brittle, fragmented, and interdependent as healthcare\. The minute we stop kicking at it, however, it STOPS changing\! So the collective "government" role is NOT to write regulations like HIPAA that foist a particular IT\-paradigm onto 500,000 providers by a "deadline"\. The proper government role is to FUND the mechanism whereby provider \(and other user\) needs can be abstracted into a standard\. Then\.\.\. with a robust and RELIABLE standards floor beneath our feet, we let COMMON SENSE be the driver to build, purchase, and implement interoperable software\. Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #18 by @Christopher_Feahr Tim, RE: "That might be an accurate description of the US healthcare system, but thankfully the US system is restricted \(more or less\) to the US, despite attempts to export it and despite attempts by misguided politicians elsewhere to copy it\.\.\.\.\(snip\)\.\.\. Thus, although dreams of regional or national EHRs seem far\-fetched in the US, they are achievable elsewhere, I think, and perhaps within a decade\." I share your concerns about the US healthcare model, which differs mainly in the area of payment\. Allowing 6000 insurance companies to become so firmly wedged between patients and providers was NOT a good idea\. The only possible benefit to patients and the common good is risk\-mitigation\.\.\. something that the US govt\. is in a MUCH better position to do fairly, and something that commercial health plans have not really given us anyway\. In fact "risk mitigation by my rules" being obviously better than shouldering the full risk, has become the chief subscriber\-retention strategy for many health plans\. Some people even choose to remain in jobs and careers they despise, in order to have SOME health coverage\. But it took us 40\+ years to get into this jam in the US and we cannot expect to back out of it overnight\. If there is anything inherently "unfair" about the US situation \(besides the government failing to accept its role of chief risk\-mitigator\) it is the lack of representation of provider needs in the general area of "information management" and standards development\. I believe that we could live with the US payer\-model if our govt\. found a way to even out the $\-risk of health problems for all patients\.\.\. assure that all Americans had access to a reasonable level of care\.\.\. and funded a mechanism for discovering and publishing provider requirements in the form of at least a national, if not global standard\. \-Chris Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #19 by @Tim_Churches > Tim, > RE: "That might be an accurate description of the US healthcare system, > but thankfully the US system is restricted \(more or less\) to the US, > despite attempts to export it and despite attempts by misguided > politicians elsewhere to copy it\.\.\.\.\(snip\)\.\.\. Thus, although dreams of > regional or national EHRs seem far\-fetched in the US, they are > achievable elsewhere, I think, and perhaps within a decade\." > > I share your concerns about the US healthcare model, which differs > mainly in the area of payment\. I would say it differs mainly in funding\. "Payment" implies a market and transactions, and many healthcare systems just don't operate like that\. For example, the public hospital system \(about 75% of all acute beds\) here in NSW doesn't \- they are block funded, not paid on a patient\-by\-patient basis\. Attempts elsewhere to introduce an artifical market into a centraly\-funded model eg "funder\-provider split" have met with only partial success elsewhere\. It is a mistake to assume that the only way to organise the delivery of healthcare is as a market in which services are bought and sold\. > Allowing 6000 insurance companies to > become so firmly wedged between patients and providers was NOT a good > idea\. The only possible benefit to patients and the common good is > risk\-mitigation\.\.\. something that the US govt\. is in a MUCH better > position to do fairly, and something that commercial health plans have > not really given us anyway\. In fact "risk mitigation by my rules" being > obviously better than shouldering the full risk, has become the chief > subscriber\-retention strategy for many health plans\. Some people even > choose to remain in jobs and careers they despise, in order to have SOME > health coverage\. Here in Australia the conservative government has had to provide all sorts of absurd tax and financial incentives to induce people to take out private health insurance \(which funds access to private hospitals and a few other fringe benefits\), and still the take\-up is poor \(less than 30% with private insurance\) \- simply because people feel confident that the publicly\-funded system will deliver adequate care when they need it \(and they are correct\)\. Cost\-containment? Our health expenditure is about 8\.3% of GDP \- well below that of the US\. Quality and effectiveness? Population health outcomes here are much bettrer than in teh US, and other quality measures of hospital care are as good or better\. Australia is not unique in this respect \- most developed countries do better than the US\. > But it took us 40\+ years to get into this jam in the US and we cannot > expect to back out of it overnight\. If there is anything inherently > "unfair" about the US situation \(besides the government failing to > accept its role of chief risk\-mitigator\) it is the lack of > representation of provider needs in the general area of "information > management" and standards development\. I believe that we could live > with the US payer\-model if our govt\. found a way to even out the $\-risk > of health problems for all patients\.\.\. assure that all Americans had > access to a reasonable level of care\.\.\. and funded a mechanism for > discovering and publishing provider requirements in the form of at least > a national, if not global standard\. Note that even private health insurance here is "community\-rated", which means that the insurers are not allowed to charge different fees for different risks i\.e\. the well subsides the sick\. They are allowed to exclude coverage for pre\-existing conditions \(which are still covered by the public system, of course\)\. The relevance of all this is that the macro\-level architecture community EHRs will be driven largely by the organisation of the healthcare ecosystem in which they will exist\. Thus US EHRs will necessarily operate quite differently to Australian or UK EHRs\. The components of the EHR, such as archetypes or terminologies, might be the same, but the way those components are used will be quite different\. Tim C --- ## Post #20 by @thomas.beale 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 --- ## Post #21 by @thomas.beale Christopher Feahr wrote: > I'm not sure we are quite ready to think about the big "EHR\-in\-the\-Sky" > repository that exists ONLY for the purpose of keeping local user > records in synchrony\.\.\. > I don't think "keeping local records in synchrony" makes much sense in a lot of cases\. If I were a clinician in hospital A, I want to see the local EPR system \+ the views available from the regional EHR system\. I don't see much value in pulling down copies of all that data into my EPR system, with all the transformation software that that would usually imply \(usually object \-> relational, archetyped \-> non\-archetyped etc\)\. In general performing writes to disparate back\-end systems is expensive and error\-prone\. However, if you are positing a local EHR cache, sure, why not\. That's just a performance measure\. > although we seem to be drifting toward that > model and it is probably an achievable model\. The main repository for > such a model could live nicely in India or anywhere\. I am NOT a > security expert, but I know that you would have at least a couple mirror > sites and other redundancy built in\. AND\.\.\. perhaps of greatest comfort > to providers\.\.\. each provider's local EHR system remains always intact > and always kept up\-to\-the\-minute through record refreshes each time he > connects to the \[hopefully, small number of\] global repositories\. > Opinion here obviously differs, and specifications like openEHR are agnostic, but as an engineer, I would not design EHR systems like this\. I would distribute them, and have the primary instance of most records in EHR systems which served the needs of "most of the carers for a patient most of the time, plus the patient"\. As noted in another post, a different model is needed for mobile patients, which is more likely a small number of national/global secure e\-health webportals\. > Step \#1 still seems to be agreement on ONE standard information model\.\.\. > with only the constraints that are invariably required for each > particular element of health data\. Archetypes that express additional > business rules about the information and relate it to other information > elements will be much more difficult to agree on\. I think we should try > to standardize that layer eventually, but that will require a very > efficient mechanism to be constructed for getting input from doctors > without them having to attend standards meetings \(because they won't > attend\!\)\. > archetypes will be much more difficult to agree on\. But the point is: \- it is up to domain experts to do the agreeing, not IT people as in the past\. \- tools can be \(are being\) written for handling archetypes, ensuring authors create technically correct archetypes \- standards are emerging for expressing archetypes, and showing how they are related to underlying information models I don't expect that many globally standardised archetypes, but I do expect a lot of national and regionally standardised archetypes, and a lot of archetype\. standardised in specialties\. THe evolution of this process will largely be up to domain organisations like specialist bodies, medical colleges etc\. Organisations like WHO also could be involved\. > In my view, the EHR effort\.\.\. partly by virtue of the inclusion of the > "record" concept\.\.\. is starting at too complex a level\.\.\. at a point > where we are almost designing a particular business management system in > the standard\. > The EHR models around at the moment include openEHR and the CEN ENV 13606 standard\. If you think these are too complex, we need to know how, in order to improve them\. > A rule\-free standard model for the INFORMATION should > exist first\. From what I understand, SNOMED CT is a very good start on > that\. > SNOMED\-CT is not a model of information, but an ontological terminology \- it is an expression of knowledge\. There are no conclusions whatever to draw from it in terms of EHR information models other than at the data level\. You will see that in the Coded term data types of openEHR, HL7 and other specifications, that certain relationships etc which exist in places like SNOMED are catered for\. But this is just data types\. Structuring information comes after that, and it is not SNOMED\-CT's business\. What it's business is \- is supporting decision support\. > Also as a standard, we should make an effort within each care > domain to model the actors, places, and things in healthcare, the > relationships between them that are always true, and the relationships > among the information elements that are always true\. This can serve as > a useful framework or high\-level model for the much more granular and > often unique process and information models of each local > user\-enterprise\. > right\. This is exactly the openEHR approach\. Have a look at the reference models, including for demographics \(http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and you will see that is exactly what the approach is\. Actually, the demographics model is intended to work for all care domains\. Undoubtedly it has to be improved before it does that, but that's what implementation and testing are for\.\.\. \- thomas --- ## Post #22 by @Tim_Churches > > > right\. This is exactly the openEHR approach\. Have a look at the > reference models, including for demographics > \(http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and > you will see that is exactly what the approach is\. Actually, the > demographics model is intended to work for all care domains\. Undoubtedly > it has to be improved before it does that, but that's what > implementation and testing are for\.\.\. Why are parties versioned? Human cloning is banned in most countries, and so far unsuccessful in the rest\. Maybe for a Raelian EHR? Seriously, the attributes of a party change, but the identity of the party remains the same? Or is versioning just an easy way of incorporating the time domain into the model? If so, it is easy, but inefficient\. Tim C --- ## Post #23 by @thomas.beale Tim Churches wrote: >> right\. This is exactly the openEHR approach\. Have a look at the reference models, including for demographics \(http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and you will see that is exactly what the approach is\. Actually, the demographics model is intended to work for all care domains\. Undoubtedly it has to be improved before it does that, but that's what implementation and testing are for\.\.\. >>    > Why are parties versioned? Human cloning is banned in most countries, > and so far unsuccessful in the rest\. Maybe for a Raelian EHR? Seriously, > the attributes of a party change, but the identity of the party remains > the same? Or is versioning just an easy way of incorporating the time > domain into the model? If so, it is easy, but inefficient\. > the attributes do change\. The point is to know what the party looked like at any given point in time in the past \- so if you reconsititute the EHR for 2 years ago, you also get the 2\-years ago view of all the demographic entities mentioned in it, including the patient\. Without versioning of demographic information, medico\-legal investigations into past states of the EHR can't work\.\.\. Not sure what you mean by "inefficient"\.\. \- thomas --- ## Post #24 by @Christopher_Feahr Tim, I can imagine several workable funding models for healthcare\. The one we have in the US is simply the straightforward "selling services for $", perverted by the brokerage model that insurance has superimposed on it\. In my personal opinion, neither model makes sense for a service like healthcare\.\.\. a service that even the most Scrooge\-like among us believe everyone should be have in a time of need\. So I think we are in agreement that a national health service is more socio\-ethically correct than the U\.S\. mercantile model\. I have not studied the metrics for success of the NHS model, but your numbers sound credible\. We are good at a lot of things in the US, but we seem to struggle with and mostly reject the value proposition inherent in considering the needs of the greater community along with one's own\. That's why US feet have so many bullet holes in them\! With regard to EHRs of all sizes\.\.\. yes, they will look different, and if some of those differences were not there, a higher level of interoperability MIGHT result\. But again, I contend that it is the DATA that is most desperately in need of a standard\. The EHR efforts seem to want to standardize both the data AND the horse it rode in on\. I think that is too much\.\.\. and will simply not be adopted fast enough to ever reach critical mass\. The real question is, "Where is the best place to start enforcing a degree of uniformity?" I believe it is best to begin with an understanding of how healthcare processes are alike around the world\.\.\.\. then derive a common set of functional requirements that support the universe of \[important/critical\] care processes\.\.\. then build a model of the DATA to support the functional requirements\. If we can massively involve providers in such an effort, I believe providers would accept standardizing at the process/requirement level\.\.\. because they already feel like they are doing that with our published "evidebce\-based practice guidelines"\.\.\.\. but they will argue til the cows come home about what the darned records should look like\! Eventually we might have to create standards for giant data repositories\.\.\. the big EHR\-in\-the\-sky\.\.\. but maybe not\. If there aren't very many such repository systems, or if a very large one \(say, one maintained by the US govt\.\) made its architecture specifications public, then that might be all the world requires as a de facto standard\. We may have too many cooks in the EHR kitchen at the moment\. Many of these proposed record models look useful, but which flavor\(s\) of which ones are likely to become the ubiquitous standard? \(The rest will have to go away or risk diluting the success of the ONE\.\.\. thus, reducing interoperability for ALL\)\. It just doesn't seem to be the right place to be digging for what we are after\. Regards, \-Chris Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #25 by @Tim_Churches > Tim Churches wrote: > > > > > > >>right\. This is exactly the openEHR approach\. Have a look at the > >>reference models, including for demographics > >>\(http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and > >>you will see that is exactly what the approach is\. Actually, the > >>demographics model is intended to work for all care domains\. Undoubtedly > >>it has to be improved before it does that, but that's what > >>implementation and testing are for\.\.\. > >> > >> > > > >Why are parties versioned? Human cloning is banned in most countries, > >and so far unsuccessful in the rest\. Maybe for a Raelian EHR? Seriously, > >the attributes of a party change, but the identity of the party remains > >the same? Or is versioning just an easy way of incorporating the time > >domain into the model? If so, it is easy, but inefficient\. > > > the attributes do change\. The point is to know what the party looked > like at any given point in time in the past \- so if you reconsititute > the EHR for 2 years ago, you also get the 2\-years ago view of all the > demographic entities mentioned in it, including the patient\. Without > versioning of demographic information, medico\-legal investigations into > past states of the EHR can't work\.\.\. Yes, yes, of course, that is taken for granted\. > Not sure what you mean by "inefficient"\.\. Well, I have changed my address several times during my life, but not my sex or my name\. This can be modelled by either keeping an address history within my demographic record \(that is, explicitly modelling the time domain\), or by keeping timestamped versions of my entire demographic record\. openEHR seems to adopt the latter approach\. That approach is less efficient space\-wise, but that hardly matters these days\. It is more efficient if the \(medico\-legal\) query is "what was my demographic record at date yyyy\-mm\-dd?" Much less efficient if the query is "how many times did I change my address?"\. Very, very inefficient if the query is "what is the mean number of address changes in the entire population?"\. I am thinking from an aggregate epidemiological POV, not a clinical/medico\-legal individual patient POV\. But then, satisfying the former POV is what data warehouses, populated from EHRs, are for\.\.\. Tim C --- ## Post #26 by @thomas.beale Christopher Feahr wrote: > With regard to EHRs of all sizes\.\.\. yes, they will look different, and > if some of those differences were not there, a higher level of > interoperability MIGHT result\. But again, I contend that it is the DATA > that is most desperately in need of a standard\. The EHR efforts seem to > want to standardize both the data AND the horse it rode in on\. I think > that is too much\.\.\. and will simply not be adopted fast enough to ever > reach critical mass\. > not sure what you mean here\.\.\. three specifications relating to the EHR are: \- the CEN ENV 13606 EHR Exchange standard \(abstract\) \- the HL7 CDA \(an XML standard\) \- the openEHR models \(abstract \+ XML\) All of these have a pure information component or container, which is equivalent and converging, as follows: \- CDA Document \- CEN Composition \- openEHR Transaction \(soon to be renamed Composition\) You can have a look at all these and you will see that they are all models of the minimum information that can be sensibly included in an EHR commit\. None are particularly complex\. Inside the Document/Composition container, you find "Sections"/"Organisers" and then something like "Entries"\. How Entries are structured depends on what you are trying to record\. Basic models, or "analysis patterns" available for Entries are: \- the CEN generic hierarchy data structure \- the stricter but still generic openEHR subtypes of Observation \(past information\), Evaluation \(decisions\), Instruction \(prospective information\) \- the HL7 RIM model of acts \- models of plans \- etc These specifications have been converging for some time now, and continue to do so with people from all 3 organisations working with each other\. I would say we are making pretty good progress overall\. \(We'll know more at the HL7 meeting in Memphis, the CEN meeting in Aarhus in September;\-\) \- thomas beale --- ## Post #27 by @thomas.beale Tim Churches wrote: >> Not sure what you mean by "inefficient"\.\. >>    > Well, I have changed my address several times during my life, but not my > sex or my name\. This can be modelled by either keeping an address > history within my demographic record \(that is, explicitly modelling the > time domain\), or by keeping timestamped versions of my entire > demographic record\. openEHR seems to adopt the latter approach\. > Actually, it doesn't, but it's not obvious I agree\. If you look at the common RM \(http://www.openehr.org/Doc_html/Model/Reference/common_rm.htm) you will see that there is a class VERSION\_REPOSITORY<T> and a class VERSION<T>\. The former is a functional interface to the stack of versions for one versioned entity, which might be a PARTY, a TRANSACTION of whatever\. But it does not say how to implement this\. A space\-inefficient, but simple, implementation would be to just have successive complete copies\. A more efficient way would be to adopt the algorithm used in versioning object databases which only stores new objects in each version, and uses special markers for deleted objects\. Normally this would be done backwards, so that it is always the most recent version that is complete, since it is the one most likely to be retrieved all the time\. > That > approach is less efficient space\-wise, but that hardly matters these > days\. It is more efficient if the \(medico\-legal\) query is "what was my > demographic record at date yyyy\-mm\-dd?" Much less efficient if the query > is "how many times did I change my address?"\. > for a single patient, neither of these is much work \- it's trivial, regardless of the representation of versions > Very, very inefficient if > the query is "what is the mean number of address changes in the entire > population?"\. I am thinking from an aggregate epidemiological POV, not a > clinical/medico\-legal individual patient POV\. But then, satisfying the > former POV is what data warehouses, populated from EHRs, are for\.\.\. > sure \- and I agree \- this is what data warehouses are for\. This kind of querying requires forethought\. If you know you are going to be collecting say 50 statistica, including "number of times change address", then you start designing software agents to capture the data as they go into the EHR, e\.g\. a simple address change counter for your query\. Then generating the result is trivial\. \- thomas --- ## Post #28 by @Tim_Churches > sure \- and I agree \- this is what data warehouses are for\. This kind of > querying requires forethought\. If you know you are going to be > collecting say 50 statistica, including "number of times change > address", then you start designing software agents to capture the data > as they go into the EHR, e\.g\. a simple address change counter for your > query\. Then generating the result is trivial\. Alas, the nature of discovery dictates that that one does not always \(in fact, rarely\) know what questions need to be answered \(which statistica\) in advance\. But making ad hoc queries against massive data warehouses efficient is outside the scope of this list \(but of considerable interest to future epidemiologists\)\. Tim C --- ## Post #29 by @Christopher_Feahr Tim, Data mining and ad hoc queries does not sound out of scope to me\. Sounds like a primary use for the EHR\-data\. Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #30 by @thomas.beale Christopher Feahr wrote: > Tim, > Data mining and ad hoc queries does not sound out of scope to me\. > Sounds like a primary use for the EHR\-data\. > well, a "secondary" use \- clinical patient care is the "primary" use;\-\) \(sorry \- just had to say that since it is in most papers, projects you will find on the EHR\)\. But I agree largely \- you can't have big epidemiological or research queries from the CDC or somewhere killing your production hospital database \- that's what data warehosing is for \- transforming data for efficient population querying , and separating out the resources for the primary production use of the information from all other uses\.\. \- thomas beale --- ## Post #31 by @Karsten_Hilbert Chris, > If there > aren't very many such repository systems, or if a very large one \(say, > one maintained by the US govt\.\) made its architecture specifications > public, then that might be all the world requires as a de facto standard\. The US govt\. has zero credibility right now in many parts of the world \(among the people, that is, not their governments\)\. OTOH, there already IS one maintained by the US govt\. that has public specs: Vista\. Uptake has not exactly skyrocketed since \(although it did accelerate in the last 6 months or so\)\. Karsten --- ## Post #32 by @system Dear Chris, CEN/TC251 is co\-operating with OPENEHR\. We are in the process to define a next version of our EHR standard\. It is basicly a standard that defines a Document and facilities for handling it properly\. Plus it will enable to locate doucment items in space and time\. On top of this the standard \(EN136060\) will include Archetypes\. With these archetypes all kinds of clinical concept models can de defined by national, loca', regional organisations\. Where appropiate the Archetypes will be able to use items like SNOMED\-CT\. And record coded information\. The Archetype \(=clinical concept model\) The Archetypes need a stable set of archetype\-fragments that define for instance the demographics of persons and organisations, but also the generic structure of a referral letter,the generic investogation, etc\. We at CEN think it is a tractable problem\. And the people from OPENEHR have demontrated that it is in several beta implementations\. I can refer you to the OPENEHR website and the CEN one \(www\.CENTC251\.org\) for kore information\. Gerard --- ## Post #33 by @Christopher_Feahr Thomas, Thanks for the comments\. My only caution about asking physicians to comment on the desirability of EHR\-system proposals is that they may not understand \[what we mean by\] our questions\.\.\. and we probably won't really understand \[what they mean by\] their responses\. When we ask for input from practicing physicians, I would rather pose very discrete questions, such as: "When you do this procedure, our committee believes that these information components are absolutely necessary\.\.\. do you agree?" Anyway\.\.\. this has been a busy few days with all the activity in the HL7 EHR SIG, and I guess I was in a particularly verbose mode\.\.\. even for me\.\.\. yesterday\! \(I saw several "please remove me\! messages posted today\.\.\. I hope I didn't drive away any of your "regulars customers"\!\) Take care, \-Chris Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #34 by @Thomas_Clark Hi Chris, Good comments\. Don't hold back\! Regarding Providers I must say that they surprise me at times\. My primary Physician obtained a degree in Electrical Engineering prior to his medical degrees\. He has modernized his internal medicine department proficiently\. He could use some help on the records systems but I believe he has the basics in\-hand\. Ask him and one might get a verbose response\. \-Thomas Clark --- ## Post #35 by @Christopher_Feahr Absolutely\! I'm sure there are thousands of un\-tapped pockets of technical brilliance out in our provider community\.\.\. but most very busy with patients and, with the exception of nut\-cases like myself, probably not THAT passionately interested in information technology\. However, virtually all of these folks are experts with respect to the "business requirements" of medical management software\.\.\. as are many of their office managers\. We need a mutually agreeable methodology for "mining" this business knowledge, without taking up too much of their time\. So the task is to construct a mechanism for proactively reaching out to a \[self\-registered\] vetting pool of provider business experts around the world\. We would build our straw\-man models, requirements\-lists, etc\.\.\.\. then decompose them \(using special tooling\) into discrete questions that make sense to the provider community\.\.\. perhaps supplemented with diagrams and graphics that they would readily understand \(without first attending UML Boot Camp\)\.\.\. and collect their structured responses into a database\. Clearly, we will have to give some thought to \(and find a source of funding for\) the tool set I am describing\. But at the end of the day, we should have a mechanism for formally vetting each section of our user\-specific, functional model of health care processes\. \(This will also be a way, incidentally, to find those pockets of tech\. brilliance, and to draw these "cursed" individuals further into the bottomless time\-sink of "healthcare standards development"\. Based on my US\-experience, I often say that "doctors won't attend SDO meetings"\. But I don't think that's entirely true\. When we have an SDO that is focused squarely on the business needs of smaller providers\.\.\. and doctors have gained an understanding of what is being discussed at SDO meetings\.\.\. then I suspect that quite a few will be interested in a more active role\. However, the SDO\-labor\-model needs to be changed too\.\.\. so that fewer face\-to\-face meetings are necessary\.\) regards, \-Chris Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #36 by @Norbert_Lipszyc This discussion which has been going on recently on the openEHR system and its uses is of major interest\. In follows the attempts in France to ensure "continuity of care"\. I completely agree with the comments of Thomas Clark on overkill\. The exchanges and sharing of data must be standardized\. Standardizing the systems for all the uses of the data is unrealistic\. Norbert Lipszyc \-\-\-\-\- Message d'origine \-\-\-\-\- --- ## Post #37 by @Cenbiotech **PLEASE REMOVE THIS EMAIL ADRESS FROM YOUR MAILING LIST !!** CENBIOTECH Dr ALLAERT TEL : 03 80 29 34 31 FAX : 03 80 29 39 73 -----Message d'origine----- --- ## Post #38 by @thomas.beale Christopher Feahr wrote: > Thomas, > Thanks for the comments\. My only caution about asking physicians to > comment on the desirability of EHR\-system proposals is that they may not > understand \[what we mean by\] our questions\.\.\. and we probably won't > really understand \[what they mean by\] their responses\. > > When we ask for input from practicing physicians, I would rather pose > very discrete questions, such as: "When you do this procedure, our > committee believes that these information components are absolutely > necessary\.\.\. do you agree?" > > Anyway\.\.\. this has been a busy few days with all the activity in the HL7 > EHR SIG, and I guess I was in a particularly verbose mode\.\.\. even for > me\.\.\. yesterday\! \(I saw several "please remove me\! messages posted > today\.\.\. I hope I didn't drive away any of your "regulars customers"\!\) > don't worry about it \- these are interesting topics\. The only alternative is to have numerous lists, and we tried that on GEHR, and it exists on HL7, and all you get is massive cross\-posting all the time\. \- thomas beale --- ## Post #39 by @Patrick_Lefebvre Hi All, > \-\-\- \(\.\.\.\) > Been off looking at some operational considerations associated > with supporting, maintaining and updating global EHRs\. > The following types of users were considered: > 1\)CREATORS > 2\)REVIEWERS > 3\)ADMINISTRATORS > 4\)CERTIFIERS This idea of certification is not only good for EHRs\. Self\-proclaimed openEHR\-conformant software sould also be tested by general, public certification tests, including EHRs & archetypes examples\. Independent organisms should also deliver their stamps, in a scheme like: "Veritas has controlled this software to be openEHR\-compliant with the specifications issued by\.\.\. \(openEHR, CEN, ISO, HL7 ?\) "\. \-\- Patrick Lefebvre     "Ce que j'écris n'engage que moi, et ce jusqu'à ma prochaine idée\." --- ## Post #40 by @lakewood Patrick Lefebvre wrote: > Hi All, > > > \-\-\- \(\.\.\.\) > > Been off looking at some operational considerations associated > > with supporting, maintaining and updating global EHRs\. > > The following types of users were considered: > > 1\)CREATORS > > 2\)REVIEWERS > > 3\)ADMINISTRATORS > > 4\)CERTIFIERS > > This idea of certification is not only good for EHRs\. > > Self\-proclaimed openEHR\-conformant software sould also be tested by general, > public certification tests, including EHRs & archetypes examples\. > > Independent organisms should also deliver their stamps, in a scheme like: > "Veritas has controlled this software to be openEHR\-compliant with the > specifications issued by\.\.\. \(openEHR, CEN, ISO, HL7 ?\) "\. > > \-\- Patrick Lefebvre >    "Ce que j'écris n'engage que moi, et ce jusqu'à ma prochaine idée\." > > \- > If you have any questions about using this list, > please send a message to d\.lloyd@openehr\.org > Hi All, Certification should be identified as well\. This should include information such as: station, date, time, source, results, requestor\. With this information tracking can be performed so that actual/potential problems can be isolated\. \-Thomas Clark --- ## Post #41 by @Christopher_Feahr this, of course, raises the issue of the certification of the certifiers\.\.\. i\.e\., where does the meta\-certification\-buck stop? In my opinion, certification \(that an application, record structure, message, data elements, archetypes, etc\. conform to a particular version of "registered" standard\) should be undertaken ONLY by the SDO who maintains the standard, or by an agent that is directly certified by the SDO to perform this function in its place\. What certification business models have been contemplated by this group? Incidentally, I see "certification services" being a principle revenue stream for the SDO or "maintenance authority", along with license fees to use and advertise conformance to the standard\. Has the group considered specific business plans for the development and maintenance of these EHR standards products? Christopher J\. Feahr, O\.D\. Optiserv Consulting \(Vision Industry\) Office: \(707\) 579\-4984 Cell: \(707\) 529\-2268 http://Optiserv.com http://VisionDataStandard.org --- ## Post #42 by @lakewood Christopher Feahr wrote: > this, of course, raises the issue of the certification of the > certifiers\.\.\. i\.e\., where does the meta\-certification\-buck stop? In my > opinion, certification \(that an application, record structure, message, > data elements, archetypes, etc\. conform to a particular version of > "registered" standard\) should be undertaken ONLY by the SDO who > maintains the standard, or by an agent that is directly certified by the > SDO to perform this function in its place\. > > What certification business models have been contemplated by this group? > > Incidentally, I see "certification services" being a principle revenue > stream for the SDO or "maintenance authority", along with license fees > to use and advertise conformance to the standard\. Has the group > considered specific business plans for the development and maintenance > of these EHR standards products? > > Christopher J\. Feahr, O\.D\. > Optiserv Consulting \(Vision Industry\) > Office: \(707\) 579\-4984 > Cell: \(707\) 529\-2268 > http //Optiserv\.com > http //VisionDataStandard\.org > From: <lakewood@copper\.net> > To: "Patrick Lefebvre" <patrick\.lefebvre@psl\.ap\-hop\-paris\.fr> > Cc: <openehr\-technical@openehr\.org> > Sent: Thursday, August 14, 2003 11:14 AM > Subject: Re: certification and verification of OpenEHR > >> Patrick Lefebvre wrote: >> >>> Hi All, >>> >>>> \-\-\- \(\.\.\.\) >>>> Been off looking at some operational considerations associated >>>> with supporting, maintaining and updating global EHRs\. >>>> The following types of users were considered: >>>> 1\)CREATORS >>>> 2\)REVIEWERS >>>> 3\)ADMINISTRATORS >>>> 4\)CERTIFIERS >>>>        >>> >>> This idea of certification is not only good for EHRs\. >>> >>> Self\-proclaimed openEHR\-conformant software sould also be tested by >>> general, >>> public certification tests, including EHRs & archetypes examples\. >>> >>> Independent organisms should also deliver their stamps, in a scheme >>>      > > like: > >>> "Veritas has controlled this software to be openEHR\-compliant with >>>      > > the > >>> specifications issued by\.\.\. \(openEHR, CEN, ISO, HL7 ?\) "\. >>> >>> \-\- Patrick Lefebvre >>>   "Ce que j'écris n'engage que moi, et ce jusqu'à ma prochaine >>>      > > idée\." > >>> \- >>> If you have any questions about using this list, >>> please send a message to d\.lloyd@openehr\.org >>> >> >> Hi All, >> >> Certification should be identified as well\. This should include >> information such as: >> station, date, time, source, results, requestor\. With this information >> tracking >> can be performed so that actual/potential problems can be isolated\. >> >> \-Thomas Clark >> >> \- >> If you have any questions about using this list, >> please send a message to d\.lloyd@openehr\.org >>    Hi All, certification, and verification, can be performed by appropriate software packages\. Hence, different jurisdictions can require more/less in the package, which fits nicely into the model permitting different jurisdictions developing their own versions of record\-based systems, including their own archetypes\. Localization is important; localized certification is therefore important\. Problem solved if a set of basic goals/objectives/results are defined/developed/tested\. A "maintenance authority" in this case may be a "big chunk" or work especially if within a single facility a group of records may be certified multiple times, e\.g\., \-incoming \-emergency care \-radiology \-surgery \-admitting \-in\-patient care \-discharge At each stage this is a change someone will 'modify' the records\. At each stage there can be justification for certifying the records, e\.g\., 'I don't want to deal with the problems someone created in the records\!'\. Finally, one should insure that upon discharge the records at 'incoming' are in the final result along with the one that 'should' be there from the facility and providers\. It appears to be a good application for a set of basic tools \(language translators optionally or provided by the Client\) that is modified for the end\-user\. On a regional, national, internation scale I don't think a standards body should be this far into it\. License fees are a much better source of revenue\. \-Thomas Clark --- ## Post #43 by @thomas.beale Christopher Feahr wrote: > this, of course, raises the issue of the certification of the > certifiers\.\.\. i\.e\., where does the meta\-certification\-buck stop? In my > opinion, certification \(that an application, record structure, message, > data elements, archetypes, etc\. conform to a particular version of > "registered" standard\) should be undertaken ONLY by the SDO who > maintains the standard, or by an agent that is directly certified by the > SDO to perform this function in its place\. > > What certification business models have been contemplated by this group? > > Incidentally, I see "certification services" being a principle revenue > stream for the SDO or "maintenance authority", along with license fees > to use and advertise conformance to the standard\. Has the group > considered specific business plans for the development and maintenance > of these EHR standards products? > this is the openEHR model \- everything is free to use \(of course;\-\) but openEHR would need to change something for certification of a claimed openEHR vX\.X compliant component \- essentially for the right to be able to use the conformance mark "openEHR xxx compliant"\. The testing will be conducted by a group whcih acts independently, and will be based on published test specifications\. A licence fee structure has not been determined, apart from the basic principle of "dual\-licencing" \(free for non\-commercial use under open source licence, else under a normal commercial licence\)\. Some interesting models have been suggested, including runtime "licencing" called a "penny a patient per annum"\. \- thomas beale --- ## Post #44 by @Norbert_Lipszyc Hi all, Concerning certification, the model developed in Europe \(through CEN and eEurope Smart Card\) for electronic signature apply very well to the openEHR environment\. Norbert Lipszyc \-\-\-\-\- Message d'origine \-\-\-\-\- --- ## Post #45 by @Patrick_Lefebvre Hi all, > Christopher Feahr wrote: > >> this, of course, raises the issue of the certification of the >> certifiers\.\.\. i\.e\., where does the meta\-certification\-buck stop? In my >> opinion, certification \(that an application, record structure, message, >> data elements, archetypes, etc\. conform to a particular version of >> "registered" standard\) should be undertaken ONLY by the SDO who >> maintains the standard, or by an agent that is directly certified by the >> SDO to perform this function in its place\. >> >> What certification business models have been contemplated by this group? >> >> Incidentally, I see "certification services" being a principle revenue >> stream for the SDO or "maintenance authority", along with license fees >> to use and advertise conformance to the standard\. Has the group >> considered specific business plans for the development and maintenance >> of these EHR standards products? >> > > this is the openEHR model \- everything is free to use \(of course;\-\) but openEHR would need to change something for certification of a claimed openEHR vX\.X compliant component \- essentially for the right to be able to use the conformance mark "openEHR xxx compliant"\. The testing will be conducted by a group whcih acts independently, and will be based on published test specifications\. A licence fee structure has not been determined, apart from the basic principle of "dual\-licencing" \(free for non\-commercial use under open source licence, else under a normal commercial licence\)\. Some interesting models have been suggested, including runtime "licencing" called a "penny a patient per annum"\. > > \- thomas beale About certification mechanisms\.\.\. a few remarks\. \(1\) openEHR \(eventually CEN\) has to publish a list of "standard tests"\. I think of conformant messages in different syntaxes \(XML, Corba, etc\)\. These messages may be part of the openEHR &/or EHRcom specification\. \(1bis\) Anyone could do so\. People will adopt the good work ;\-\)\) \(2\) National organisations, Universities, CEN, openEHR, other\.\.\. independent or not, profit and non\-profit organisations may certificate "openEHR compliant"\. Compliant with what ? Only the public, published specs should be a serious test\. \(2bis\) As for benchmarks, anyone should be able to verify that the certification results were serious\. So anyone has to get the tests\. \(3\) People \(Hospitals, Health Care Organisations, etc \) will pay for a product, but will not accept paying an undefinite fee\. Product may be "certified by Veritas" or "Certified by TNO": the stamp value is/will be the certifier's reputation\. \(4\) Such schemes are widely in use in Quality Insurance \(ISO 9000 for example\)\. The test is published and well\-known; The tester/certifier is independent from the vendor/buyer; \-\- Patrick Lefebvre \-\-\-\-\-\-\-\-\-\-\-\-\- \( plefebv@wanadoo\.fr \) --- ## Post #46 by @thomas.beale Patrick Lefebvre wrote: > Hi all, > > About certification mechanisms\.\.\. a few remarks\. > > \(1\) openEHR \(eventually CEN\) has to publish a list of "standard tests"\. I think of conformant messages in different syntaxes \(XML, Corba, etc\)\. These messages may be part of the openEHR &/or EHRcom specification\. agree > \(1bis\) Anyone could do so\. People will adopt the good work ;\-\)\) agree > \(2\) National organisations, Universities, CEN, openEHR, other\.\.\. independent or not, profit and non\-profit organisations may certificate "openEHR compliant"\. Compliant with what ? Only the public, published specs should be a serious test\. correct\. But any certification has to be managed by openEHR \- other there is no point of trust for the whole process\. > \(2bis\) As for benchmarks, anyone should be able to verify that the certification results were serious\. So anyone has to get the tests\. well, they're needed anyway, for any vendor or developer who wants to get certified \- obviously they need the "exam questions" to know how to practice;\-\) > \(3\) People \(Hospitals, Health Care Organisations, etc \) will pay for a product, but will not accept paying an undefinite fee\. Product may be "certified by Veritas" or "Certified by TNO": the stamp value is/will be the certifier's reputation\. no doubt\. Clearly openEHR has to make sure these certification processes are not uneconomic for those getting certified\. On the other hand, commercial vendors should expect to pay something \- openEHR saves them millions by giving away free specifications\.\.\. > \(4\) Such schemes are widely in use in Quality Insurance \(ISO 9000 for example\)\. The test is published and well\-known; The tester/certifier is independent from the vendor/buyer; yep\. \- thomas --- ## Post #47 by @lakewood Hi All, Be sure to include certification boundaries, e\.g\., certify records available in a single facility\. Records may be resident in multiple remote facilities with the Providers attempting to deal quickly with the Patient in their facility, e\.g\., traveling salesman \(has a known homebase\)\. If the remote records are not accessible for some reason, e\.g\., the latest security issue, then the local Providers may be able to certify the records \(incoming/outgoing\) at that facility and proceed\. Reconciling distributed records can be treated as a separate issue\. The current Patient/Provider requirements may be superior\. These type certification issues are spread between the Provider and the IT fields, the IT field flush with examples\. What is important here is whether the Providers can live with certification of locally available records perhaps with the knowledge that others exists but are currently unavailable\. Some decision process is needed\. If not, then I would appreciate knowing what issues need to be resolved\. If the Patient can wait and the occupied resources could be put to no better use, then let the Patient wait\. However, that doesn't seem to be the 'usual' situation\. \-Thomas Clark Thomas Beale wrote: --- **Canonical:** https://discourse.openehr.org/t/certification-and-verification-of-openehr/14449 **Original content:** https://discourse.openehr.org/t/certification-and-verification-of-openehr/14449