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 - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
