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 ----- Original Message ----- From: "Christopher Feahr" <[email protected]> To: <lakewood at copper.net>; "Thomas Beale" <thomas at deepthought.com.au>; <openehr-technical at openehr.org> Sent: Tuesday, August 05, 2003 1:05 PM Subject: Re: certification and verification of OpenEHR > 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 > ----- Original Message ----- > From: <lakewood at copper.net> > To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > Sent: Tuesday, August 05, 2003 9:24 AM > Subject: Re: certification and verification of OpenEHR > > > > Hi Chris, > > > > Great response! > > > > Would like to learn what the US Providers want and need from a system > > like the proposed OpenEHR project. Contributors to the project are at > > liberty to publish; but the remaining, quite numerous, Providers may > well > > be unaware of the existence of such projects and unable to respond. > > > > 'Pass the baton to the healthcare associations' seems appropriate. Why > not > > have them poll their members? > > > > Nothing like designing a system that a majority of the users reject. > > > > -Thomas Clark > > > > ----- Original Message ----- > > From: "Christopher Feahr" <chris at optiserv.com> > > To: "Thomas Clark" <tclark at hcsystems.com>; "Thomas Beale" > > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > > Sent: Monday, August 04, 2003 10:20 AM > > Subject: Re: certification and verification of OpenEHR > > > > > > > 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 > > > ----- Original Message ----- > > > From: "Thomas Clark" <tclark at hcsystems.com> > > > To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" > > > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > > > Sent: Sunday, August 03, 2003 12:50 PM > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > 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 > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Christopher Feahr" <chris at optiserv.com> > > > > To: "Thomas Beale" <thomas at deepthought.com.au>; > > > > <openehr-technical at openehr.org> > > > > Sent: Sunday, August 03, 2003 7:09 AM > > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > > > > 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 > > > > > ----- Original Message ----- > > > > > From: "Thomas Beale" <thomas at deepthought.com.au> > > > > > To: <openehr-technical at openehr.org> > > > > > Sent: Saturday, August 02, 2003 4:33 PM > > > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > lakewood at 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 > > > > > > > > > > > > > > > > > > - > > > > > > If you have any questions about using this list, > > > > > > please send a message to d.lloyd at openehr.org > > > > > > > > > > - > > > > > If you have any questions about using this list, > > > > > please send a message to d.lloyd at openehr.org > > > > > > > > > > - > > > If you have any questions about using this list, > > > please send a message to d.lloyd at openehr.org > > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
