Quote Of The Year

Quote Of The Year - Paul Shetler - "Its not Your Health Record it's a Government Record Of Your Health Information"

Sunday, January 21, 2007

Archetypically Stupid!

Recently (December 1, 2006) the Health Informatics Technical Committee of the International Standards Organisation (ISO) released a draft Standard entitled Health informatics — Electronic health record communication — Part 2: Part 2: Archetype interchange specification. The closing date for comments is in March, 2007.

The draft document is on its way through the various ISO and CEN processes towards being approved as one of the five parts of the TC 215 Standard on Electronic Record Communication. (pr13606).

Overall the Standard – if approved - aims to define how extracts of patient records can be safely and reliably moved between two EHR systems which are compliant with the Standard once approved.

Key to the success of the approach being adopted is the use of an information construct called an Archetype which defines how clinical content within the record is to be laid out and interpreted.

Without going into too much detail an example of how the Archetype is intended to be used can be better understood as follows.

Assume we wish to place a patient’s blood pressure into an Electronic Health Record (EHR).

In the context of a defined and identified individual patient, an identified healthcare provider (the observer) and the date and time of the observation, it is possible to use an Archetype which has the concept name of ‘blood pressure’. This permits recording of the systolic and diastolic blood pressure values along with associated information (e.g. is this blood pressure part of an assessment for postural hypotension where body position is important or is this blood pressure measured with a described cuff size, etc). Given the detail that may be needed to handle electronic measurements, continuous or 24 hour measurements and so on, the possible complexity becomes obvious if a single archetype is required to handle the concept of ‘blood pressure’. (I guess the response from proponents of Archetypes would most likely be that this would be handled by higher level assemblages of Archetypes, but clearly the downside of this approach is the ultimate number of Archetypes needed).

All the actual data entered is intended to be stored, along with the patient and Archetype identifying information, in an EHR system that can access, when requested, the Archetype ‘framework’ into which the recorded values have been placed. This allows the re-creation of the ‘whole’ of the observation, as needed, in any compliant system. An individual patient record can of course be made up of many data elements (described and constrained by many different Archetypes) to build up a fuller and more complex EHR record.

The benefit claimed for this approach is that any computer system which can locate and ‘interpret’ the correct Archetype can accurately re-present and re-use the EHR information (i.e. provide semantic interoperability between EHR systems). The importance of finding the correct Archetype to utilise becomes obvious here as using a different version of an Archetype, or the wrong Archetype, could be very problematic. This has a range of obvious consequences around the need for effective naming and version control conventions.

Why am I bothering to comment on this somewhat obscure standards balloting event?

The answer is that I simply do not believe use of Archetypes is ready for ‘prime-time’, especially as a global standard, until a vast amount more work is done.

My specific concerns are as follows:

1. The draft standard admits it is unclear how many Archetypes are needed for a successful general purpose EHR and the amount of work needed to create them.

To quote:

Archetype Repositories

“The range of archetypes required within a shared EHR community will depend upon its range of clinical activities. The total set needed on a national basis is presently unknown, but there might eventually be several thousand archetypes globally. The ideal sources of knowledge for developing such archetype definitions will be clinical guidelines, care pathways, scientific publications and other embodiments of best practice. However, “de facto” sources of agreed clinical data structures might also include:

• the data schemata (models) of existing clinical systems;
• the lay-out of computer screen forms used by these systems for data entry and for the display of analyses performed;
• data-entry templates, pop-up lists and look-up tables used by these systems;
• shared-care data sets, messages and reports used locally and nationally;
• the structure of forms used for the documentation of clinical consultations or summaries within paper records;
• health information used in secondary data collections;
• the pre-coordinated terms in terminology systems.

Despite this list of de facto ways in which clinical data structures are currently represented, these formats are very rarely interoperable. The use of standardised archetypes provides an interoperable way of representing and sharing these specifications, in support of consistent (good quality) health care record-keeping and the semantic interoperability of shared EHRs.

In the longer term, it is anticipated that the involvement of national health services, academic organisations and professional bodies in the development of archetypes will enable this approach to contribute to the pursuit of quality evidence-based clinical practice. In the future regional or national public domain libraries of archetype definitions might be accessed via the Internet, and downloaded for local use within EHR systems.”

What is clear here is that not only do we not know how many are needed, but that no-one knows, and more importantly the needed Archetypes do not exist anywhere on the planet!

If one considers the number of diagnostic tests, types of observations and so on that exist I believe “several thousand” is just hopeful guesswork. Of course who is going to develop and pay for all the work required is a separate question.

2. The writers of the quotation above seem to me to be conceiving Archetypes at a level (clinical guidelines and the like) above where Archetype development and definition is needed (i.e. at the level of individual observations and investigations). Only once these basics are developed and stable can construction of the more advanced information constructs and uses begin.

3. It is also obvious that without a global reference source for Archetypes (as well as global governance mechanisms and the required technical, development and managerial infrastructure) the stated goal of sharable, interoperable EHR extracts is little more than a pipe dream. This reference source does not exist and is unlikely to anytime soon. The prospect of local divergent Archetype repositories dotted all around the world, resulting in all sorts of interoperation difficulties, is too horrible to contemplate.

4. There is no reference implementation of a system deploying even a slightly comprehensive set of Archetypes to prove the conceptual and performance capability of Archetype based systems. There seems to me to be little doubt that scalability of Archetype services could be a significant issue.

5. There seems to be some evangelical thrust on the part of Standards Australia (and possibly NEHTA) to spread the use of Archetypes globally (as a special pestilential and mind befuddling treat for the rest of the world) when the local investment in their development and deployment has been minimal, to say the least. If they really think Archetypes are such a great idea putting ‘the money where their mouths are’ would be a good idea!

6. The literature supporting the contemporary use of Archetypes in the draft standard comprises a total of four citations predominantly by only two people.

7. The HL7 Template Special Interest Group is still working (as of October 2006) to resolve how CEN Archetypes and HL7 Templates can be harmonised in ways that make them interoperable whilst recognising that many of the conceptual and operational problems with Archetypes exist just as significantly in the HL7 Template proposals.

8. It seems to me there are much more basic and important things to be standardised before attacking a problem of this complexity which has not been applied or asked for by the real world. Getting basic clinical information available at local points of care reliably and improving care-coordination with the simplest of care records would be a very good start rather than developing this misguided, over-engineered and over-complex standard which I doubt will be seriously considered by more than 50 people and which I suspect will never be actually implemented as intended by its creators. To posit adoption of this Standard without describing the governance, provisioning and funding of the necessary Archetype sever infrastructure is naïve in the extreme.

To be creating 150+ page specification documents on the basis of what seems to be a conceptually ‘good idea’ and to then, without proven reference implementations, launch such documents on an unsuspecting world is downright dangerous.It is likely to hamper more useful and important e-Health developments globally, as an overly complex mess is sorted out – if that is possible.

It is really time for the proponents of Archetypes to ‘put up or shut up’. This is way to serious to just allow this proposed standard to wander though the approval processes without some very hard questions being asked.

Until reference implementations exist and are working and harmonisation with other standards (HL7 etc) is finalised and demonstrable all involved really need a ‘cold shower’ as our politicians are so keen on saying.

David.

14 comments:

Anonymous said...

Are you seriously holding HL7 up as a benchmark standard? If so then you are obviuosly too naive to be commenting on this field.

Aus HIT Man said...

Hi,

I think if you read my blog a little more thoroughly you will find I consider that all the current major programs for standardisation are a cause for concern because they are at the bleeding edge they have yet to be implemented. The time taken to get any of 13606, HL7V3.0, openEHR or SNOMED CT (less so) really out the door must make one wonder how practical and real they are.

They are all very complex and may prove to be very intractable in implementation.

HL7 V2.x on the other hand has the runs on the board!

David.

william goossen said...

dear David,

I agree with your points of view and after 2+ years of implementing archetypes that are written out in HL7 v3 specification I can tell you that your points are valid and currently happening.
see www.zorginformatiemodel.nl for the set of about 90 HL7 v3.0 archetypes (I deliberately use archetypes, templates, GPIC, detailed clinical models and care information models as synonyms).

Unfortunately the papers on this in the peer reviewed literature are about 4 to 5 and all by this author. So given that I will go into your 8 points:

1. I found that several low level discrete atomic or small molecular data items are used in every clinical domain: e.g. the vitals, activities of daily living, family history etc.
Attempts to get these standardised do not fully get the recognition they should and could.
the top 100 of discrete items will solve a lot of the basic exchanges, all on top can be developed specialty driven in feasible projects. Average costs: 1000 Euro per discrete variable if single, 5000 for a set up to ten and 10.000 for a set up to 100.
clinimetric features like assessment scales require more due to necessary review of clinical literature.

2. I fully agree we need this 100 discrete observations / variables first before moving to complexer structures. The problem of 13606 is the top down approach where we actually need this bottom up approach.

3. Global work: this is not a pipe dream. August 25 there will be a meeting in Brisbane (after Medinfo) to discuss the global work in this area: developers of clinical templates from UK, NL, Aus, US, will join to arrange work on a global repository.You are invited.

4. there is a reference cite for piloting the HL7 v3 archetypes approach: see www.portavita.nl for the stroke and diabetes ASP systems.

5. I also find such evangelists here in Europe.

6. As said: I have only 4-5 references, implementing cost to much time to write everyting up.

7.
Look at the HL7 v3 Care Provision D-MIM, R-MIM and especially the R-MIM for schale representation and vital signs representation. These fit the record exchange and referral message and the CDA model. Work is ongoing.

8. That is exactly what we are doing and it works.

William Goossen

Gerard Freriks MD said...

1- For ages clinicians define clinical constructs that fit their own, local and national requirements. Each community defines its own.
ICT-systems in healthcare all develop systems meeting all these needs.
The message paradigm make large communities conform to a consensus process. Each ICT-system vendor implements it in its own way.
2- Archetypes are the result of 20 years of European R&D. Much of the literature is not published using the Archetype or Template buzz words.
Concepts in the European standards have been researched and tested more extensively than many HL7 and other standards.
Projects that played a role: GEHR, HANSA, I4C, Synapsis, Synapsis in Use to name a few.
3- Archetypes provide uniform ways to express the needs of large and small communities.
Archetypes provide the uniform way to use 'plug-and-play' archetypes (and the associated data) in ICT-systems that are conformant.
4- Archetypes and Templates on one hand make use of very comprehensive archetypes to compose fit for purpose local arrangements, called Templates. In short in provides a lot of flexibility.
On the basis of a limited number of archetypes , zillions of Templates will be made. Each Template being the local agreement of what will be stored, ued and exchanged.
5- On the basis of top-down tooling based on the CEN/tc251 EN13606 and OpenEHR bottum-up flexible definition and deployment is possible.
Compared to the message paradigm the Archetype Paradigm has many advantages.
6- The Archetype paradigm is used. In the Netherlands alone I know of two implentations. I know for shure that several systems all over the world use the same methodology but NOT based on standards, but using proprietary specs. More deployments can be found at UCL in the UK, Norway,Turkey to mention a few that come to mind.
7- Recently I learned that IBM started to investigate the Archetype paradigm. And the NHS-England made some intersteting statements and decisions recently at the HL7 meeting and their intended use of EN13606 part 1 and OpenEHR Archetypes..
8- The Archetype/Template paradigm is used extensively in the highly standardised Telecom-industry, is what my colleagues in a large telecom R&D research institute told me.
9- In summary.
a) It is my opinion that systems using Archetypes and Templates and based on CEN/tc251 EN13606 and OpenEHR are a major improvement over systems deploying Edifact and HL7v2 and HL7v3 messages.
b) It is the result of extensive European R&D, demonstrators and clinical use.
c) It is at present the only way to achieve well researched 'plug-and-play semantic interoperability, supporting in a very flexible way large and small clinical communities.
Top-down the tools are defined. Bottom-up the communities using the standardised tool define what they have to store, retrieve, present and exchange without any reprogramming by the system vendors.


Gerard Freriks,
former convenor of CEN/tc251 wg1

Aus HIT Man said...

Hi Gerard

Great to hear from you. Where is all this working so me and William can be convinced it is a sound idea?

David.

Anonymous said...

Dear David,

Thank you for setting up this blog as a window through which to air your concerns. As the primary author of the section of prEN13606-2 that you quote, I am surprised and a little disappointed to find that you are so critical of something which rather transparently admits its limitations and points to the wider challenge of which it is a part.

The goal of defining data structures to represent key clinical information in systematic ways is an old one, going back decades, and is vigorously being accelerated now in many national eHealth programmes such as yours (Data Groups etc.). These bodies are finding many of the challenges you describe: how to contain the number of data structures whilst catering for as much of real clinical diversity as is wise, how to bind record structures with new-generation large terminology such as SNOMED-CT, how to define editorial and governance policies and publishing infrastructures for these data structures and data sets, how to maintain them in the light of evolving practice, and how to deliver a coherent set of distributed knowledge services to support authorship and EHR systems. Despite these many challenges, it is recognised that this kind of approach is necessary if we are to aspire towards even modest semantic interoperability of health records.

One key problem is that all such sets of defintions internationally use rather ad hoc representation formalisms. Part 2 of 13606 is therefore an important stepping-stone contribution towards harmonisation in this area, drawing as it does on the openEHR Archetype approach. The ability to foster an international standard for how such data structures can be represented and shared has been widely supported by many of the nations who are already building up such data structure libraries (including the UK and Australia, voting positively for 13606-2 in historic ballots). It is recognised that the challenge of building up content needs to be internationally shared, and that vendors (often being global) wishing to exploit such knowledge artefacts would in general prefer a single standarised representation.

The truth is that this is an area in which research, standardisation and productisation need to proceed hand in hand. The solutions cannot be found by waiting for research alone to finish, because research needs to learn from wide scale practical experience and vice versa.

You will know, I am sure, that 13606 Part 1 does not require the use of archetypes i.e. it is recognised that much useful EHR sharing can and will take place before archetypes become widely used. Part 2 is seeking to standardise that part of the archetype approach that is reasonably well established (a comprehensive representation of what needs to be specified when a data structure is defined). Future standards will be able to address most of the other areas you raise, but we are not yet at a point where best practice is established for those areas. The openEHR Foundation and its Clinical Review Board, and a new Detailed Clincial Models Collaborative of openEHR plus HL7, are seeking to build up an understanding of best practice in these other areas. There are also many running systems (some research and some commercial products) that have adopted an archetype-like approach from which we can learn. And there are substantial national efforts, such as the Dutch work that William refers to, which are identifying important issues and solutions.

I hope therefore that you can use your efforts, given that you have taken the trouble to study the field, to help contribute to the future learning we still need to make. If you do have specific rewordings to propose to 13606 Part 2 I am very happy to receive them, and to put them into the consensus standardisation process for consideration.

I hope that you and your readers can recognise that the various organisations, be it a national effort like the Australian or Dutch, a standard like 13606 or HL7 Templates, or research like openEHR's or our own at UCL, are all working rather unusually closely and harmoniously towards tackling these difficult challenges. I hope you will also find that, as a community, we are open to constructive critique and to fresh inputs from others.

I look forward to your reply.
With best wishes,
Dipak Kalra
d.kalra@chime.ucl.ac.uk

Aus HIT Man said...

Dipak,

My simple point was that deployment of archetypes (and like models) had not been brought to the stage of development required to be incorporated into an ISO standard..its really as simple as that.

I will persist in my view you create Standards after something has established its utility, viability, applicability etc - not after! I have had a deluge of e-mail supporting that view.

I am also of the view that some of the smartest people working in the area are involved with all this and have a feeling they would make more impact attacking more tractable problems..but obviously it is their call.

If you have browsed my blog you will be aware I have been suggesting for a while that a focus on solving those problems we can get our heads around before addressing "life the universe and everything" is more likely to be a successful way forward. I am sure others will have a different view - that's life! An example of my view is that I think semantic inter-operability is a much less important problem that getting systems which provide quality decision support into the hands of clinical users. Doing this would save more lives in the next decade in my view.

You can all disagree or agree, but that is simply how I see it after 25 years at the field.

I understand lots of work has been done on all this but I really would suggest a focus on the practical and when its proven moving to Standards drafting not the other way around.

Many thanks for your considered response.

Best wishes

David.

Anonymous said...

Dear David,

When you say:
"An example of my view is that I think semantic inter-operability is a much less important problem that getting systems which provide quality decision support into the hands of clinical users."

you actually expose the need for the challenges that I described to be tackled. Without some measure of semantic interoperability (consistently represented clinical meaning) decision support is not very safe.

I don't think we are in disagreement about the need to progress the learning via practical and usable approaches, and the need for standards to in general endorse approaches that have some track record.

Dipak

stef said...

Dear David,

This ("An example of my view is that I think semantic inter-operability is a much less important problem that getting systems which provide quality decision support into the hands of clinical users.") is exactly the reason why we chose to use a system based on EN 13606.

We're in the business of developing clinical decision (support) systems. There are at least 2 important issues with clinical decision support systems: 1. data integrity/ quality and 2. liability.
Semantic interoperability is also an issue, but less in systems which rely on human interpretation. When a clinical decision is provided by a machine (for instance during the ambulance ride to the hospital) semantic interoperability is an absolute requirement

For example: Dr. A sees a patient in the ER and has access to a clinical decision support system. This system is useless unless it provides access to a (minimal data set) of the patients EHR, so that is provided as well. Let's assume that this system has access to the EHR of the GP of this patient via a communication and patient identification service based on an internationally accepted open standard.
Although the communication works fine, nothing is guaranteed about the integrity and quality of the data since there are no 'watertight' requirements for data storage on local systems. On top of that the sender of the data (the GP), didn't sign/ took responsibility for each data entry in its original context.
Based on this input the decision support system provides an advice, which is taken by Dr. A.

Unfortunately the patient on the ER dies. As it later turned out, the decision of the support system provided an incorrect advice, due to an error in a critical data point in the EHR system of the GP (the value given was 8 instead of 80).

Now the critical question is: who’s responsible?
The GP will not likely take full responsibility for the data error and probably blame this on somebody else (an assistant or other co-worker). Since not every data entry is signed personally by the GP with a valid signature, it can’t be proven that the mistake is the responsibility of the GP.
So now the following situation occurs (under Dutch law): both doctors (A and the GP) are both held equally responsible. The GP for (partially) providing incorrect data and Dr A for relying on data, which isn’t officially signed by the GP and therefore not valid.

So my question to you is: do you think that Dr A will ever rely on a clinical decision support system based on standards and systems as described above?

In our opinion the only way to overcome these liability issues is using a complete system based on the EN 13606 standards, since these standards tackle (among other things :-) ) the issues I’ve described above.

Yes, the introduction of such a system is cumbersome and the implementation of a ‘complete’ EHR in which every caretaker can note every aspect of a patient, will require a lot of efforts, time and money of a lot of people.
Therefore we’ve chosen to start with some partial solutions. I totally agree with William Goossen that one can start with a limited subset of archetypes to overcome a lot of the urgent problems everybody is aware of. Most doctors would be more than happy if they could access a reliable, actual and complete problem and medication list (including allergies and adverse events) of their patients, especially in after hours or emergency situations. Basically this is the system that is already being rolled out in the Netherlands, but that has the ‘problems’ that I’ve described above. The good thing is that the infrastructure is already there and that if we can tackle these issues we would have a great system that really would be the basis for the ‘ideal’ EHR of the 21th century. Our aim is to merge the ‘best of both worlds’.

Add to this for instance the data that patients nowadays are collecting in their home situation (weight, blood pressure, glucose values, cholesterol and so on) and a ‘personal health care record’ is born, which is owned and controlled by the client/ patient. I don’t know the situation in Australia but this is where we (and with us the European government) want to go. Our opinion is that such a PHR is the way to true client/patient empowerment. In the near future the client/patient will demand high quality and semantic interoperable (I love the term ‘plug and play” in this context) data. This includes coverage of the responsibility issues, since otherwise such a PHR (or EHR) is useless.

Best wishes,


Stef Verlinden, MD
CEO Vivici

Gerard Freriks MD said...

David,
You wrote: "I will persist in my view you create Standards after something has established its utility, viability, applicability etc - not after! I have had a deluge of e-mail supporting that view."

How does one solve the chicken and egg problem?

By making standards to make tools clinicians use to produce archetypes and use archetypes in EHR-systems?
Or by making archetypes and using them in EHR-systems and then standardise the tools?

The only way is to produce the tools first.
Then produce the archetypes.
Create systems that are able to read and process archetypes and associated data.
Next we need a process to collect the archetypes, harmonise and publish them in a controlled way.

EuroRec (the European Institute for Health Records) will become one place where they will host a Archetype/Template registries and repositories. Plus they expect to perform a quality control process fro Europe.

Gerard Freriks

Lisa said...

David and all, addressing your concern #4 that "there is no reference implementation of a system deploying even a slightly comprehensive set of archetypes"...

I want to point you towards an archetype-enabled EHR system demonstration we here at Ocean have recently opened for public viewing. This is a simulation of 70,000 EHRs which together contain over 40 million compositions (composition = the smallest committable unit of health information in openEHR).

As to the questions of how many archetypes we need and how many actually exist, see the information about the archetypes used in the demo to get an idea...

Aus HIT Man said...

Hi Lisa,

Logged on a Guest. Searched for patient Fred. Took top one. Got a total load of rubbish back - e.g. a discharge summary for a neonate when the patient seems to be born in 1995.

Sorry - vastly more work needed. Let me know when you have something I can play with sensibly.

David.

Heath Frankel said...

David,
As Gerard says, standards development is like the chicken and the egg. I do agree that recently too many Health IT standards have been developed without implementation. I also agree that the new DSTU paraidigm and OMG processes are providing an improved platform that should result in more implementable Health IT specifications.
However there are market forces that push for standards to be released, perhaps before they are ready. These market forces include vendors and national programs.
The HL7 V3 RIM is one example, it wasn't even intended to be made normative, but HL7 was lobbied hard by members of HL7 UK to do so otherwise the recommendation to their national program to use V3 could not stand up as the vendors wouldn't invest their development money on something that wasn't a standard.
I was heavily involved in the development of the V3 Care Provision messages and struggled in the early days to get the interest of parties to reviewn the proposed designs while they had a draft status. Once they were balloted as a standard we got all sort of feedback. This demonstrated that people will only care once it might actually affect them by being a standard.
So if it is CDS you want, and to get CDS you need common representation of data, to validate common representation of data you need a language to describe that representation, to share common representations of data you need a common language for describing that representation. What better way is there to get a common language than to do create a standard so that vendors can feel safe in implementing it.
When I first started going to HL7 meetings in the US in 2002 they were trying to develop the similar concept of templates. 5 years later HL7 are no further along than they were then (they still discuss the definition of a template and still use 4 or 5 different techniques to represent them). Several (including myself) gave up waiting for a HL7 solution to this and have adopted Archetypes. I wonder if Archetypes being a CEN/ISO standard had anything to do with that?
At least with the Archetype specification out of the way we can start discussing the requirements for a shared Archetype repository, development and governence process. HL7 has barely recognised the need for these (even though I suggested this to them a couple of years back when I was involved with the Clinical Statement project).
Perhaps making Archetypes an ISO standard is premature, but perhaps making the HL7 RIM an ISO standard was also premature. But at least now national programs and vendors are commiting resources to implementing HL7 V3 and can also do the same with Archetypes. Then you should get the evidence you are looking for one way or another rather than just on paper.

Aus HIT Man said...

Heath,

Many thanks for that thoughtful comment. I think you are right suggesting we will have to wait for a clear outcome to all this. Hence my enthusiasm for some baby steps to be taken while we are all waiting.

David.