Category Archives: Interoperability

Date validation for exchanged data

Posted on October 21, 2012 by
2 Comments

A question arose in the PCEHR program: is the date 00010101 a valid date in CDA, and if not, what is the valid date range allowed?

Well, firstly, as far as the TS data type is concerned, 00010101 is a valid date – the 1/1/01, the nominal year of Jesus’ birth (only he wasn’t born that year). But just because it’s legal according to the type doesn’t mean that it makes sense – especially as the date of onset of a patient’s problem. This caused some discussion about what dates the national program should accept for clinical dates – what should be valid? When I looked around, I discovered remarkably little good information about the general subject of what dates are reasonable to accept in clinical records.

Here’s some suggestions for the kind of date ranges to test clinical programs against:

  • The oldest living Australian was born 1901. There doesn’t appear to be any need to test clinical programs for older date of births than that (other countries go a little further back, but not far)
  • For medicare testing, Medicare has a system limitation – no creation of records for DOB greater than 80 yr old
  • Date of onset of a condition or a diagnosis could conceivably be up to or before date of birth, but not before date of birth for older Australians, so anything to 1901. For these dates, years, and year/month should be acceptable to the system
  • Date of a clinical action – it’s really difficult to imagine records going back prior to 1980 for actual clinical records (date of action, prescription, immunization), but I know of records going back to the late 80s
  • Scheduled dates – up to 10 years in the future

There’s no real reason to accept dates in the future for other than scheduled dates, though now + a few seconds is always a rational thing to allow.

While these seem reasonable limits – anything outside these is quite likely to be a clerical error (I’ve seen appointments for 3013, date of birth of 23-Apr 1048 etc). But should a system reject dates like this? In most cases, a human inspecting the date will be able to infer the likely clerical error if it’s bad enough to fall outside these reasonable ranges (they won’t pick up subtle errors, but neither can these rules). On the other hand, a computer trying to process these rules can only know that the dates are wrong – no inferences there. So I’m not sure when systems should reject dates that fall outside the reasonable dates ranges I put above.

btw, I’m not sure what the pcEHR is going to do, and couldn’t provide formal advice here anyway. Comments are welcome, particularly from clinical application test folks (thanks to one who contributed the information about medicare age restrictions, btw).

Categories: Australia, Interoperability

The pulse of the HL7 profession

Posted on October 16, 2012 by
2 Comments

David More drew my attention to “New poll takes pulse of HL7 profession“, and I couldn’t resist making some comments on it.

Most HL7 professionals have experience, but generally have limited tenure at their specific employers.

yep, that’s my experience. And very often this is a reflection of basic economics: organisational requirements for integration come and go, and the value of people who can fulfill these requirements varies accordingly. But people tend to respond badly to holding a fixed job with a variable income – hence the usual resolution to this is a contract/consultant model, or some other variation of a mobile workforce. And this is why many HL7 insiders are contractors or consultants like myself.

Also, they said:

About one-third of all organizations polled are currently lacking staff retention strategy

yep, this is certainly true. Considering my comments above, it’s a hard policy to have. But it’s also crucial, and my number one recommendation to vendors in particular: know your retention policy for integrators, because it will be tested.

The next one made me laugh:

Interface engines show room for improvement. Nearly half of all respondents – including 49.5 percent of CIO/CTOs, 46.6 percent of IT managers and 42.7 percent of HL7 professionals – report that while they’re using their interface engine for what it was initially intended, they know it has more capabilities they are not using

So, since an interface engine has capabilities people aren’t using, it needs “improvement”? That’s an, umm, surprising conclusion. Or maybe, it’s just that what people needs varies? And that the problems are hard, so the solutions are hard?

Finally, security:

While seen as important, security is not listed as a top organizational priority. Just two percent of survey respondents said information security was one of their top their priorities. But when asked how information security affects their top priorities, 89 percent of CIOs and 90 percent of IT managers said security is either integral to at least one their organization’s top priorities, or it is their top priority.

That’s primarily because integration is sufficiently difficult by itself without introducing security to the mix. In practice, you secure comms, and then treat the exchange as trusted. This simple policy mostly delivers the goods, and means that secrity need not be a particular concern for your HL7 integration experts (not compared to all the other things they need to be concerned about).

 

Categories: HL7, Interoperability

Can HL7 derive revenue from Tooling?

Posted on September 6, 2012 by
1 Comment

One of the proposed sources of revenue to replace the IP based income for HL7 is “tooling”. What kind of tooling could generate this kind of income stream for HL7? Since I can’t imagine other SDOs adopting HL7 tooling (RMIM designer, Rosetree etc) for free – let alone for a decent amount of money – it’s going to have to be implementation tooling that HL7 can sell to implementers – whether members or not.

What kind of implementation tooling is there for HL7 related work? Here’s my list:

  • Programming API libraries / generators / Frameworks
  • Interface Engines
  • Middleware
  • Conformance Statement generation, comparison and publication
  • Conformance and Certification Testing
  • Implementation Guide Development

These tools cover

  • HL7 v2
  • CDA
  • V3
  • Terminology
  • EHR-FM

In practice, there’s a high degree of of overlap between the categories, and/or tools cross the boundaries as they seek to value add off the common knowledge base that is needed for any of them. There’s an active market in all of these for the various HL7 specifications, sometimes purely a commercial one, and sometimes with considerable government sponsorship.

From a market perspective, the toolkits range in price from free/open source through into the million dollar range, though no one is getting rich from the tool market. In fact, many participants either give away the tooling or provide it less than cost as marketing for value added services (The simple tools on this site, for instance).

Actual Tools

There are others, but they don’t come to mind as I write this offline on an aeroplane over Mexico.

Prospects for HL7

So can HL7 make money by providing tooling in this space? I don’t think so. Why?

  • The existing toolkits have borderline viability. In the end, this is a supply/demand thing – the market is a fixed size, and there’s many tools at all sorts of price/functionality points. HL7 entering the market will increase supply, but it seems unlikely that demand will increase much, though it’s reasonable to suppose it will increase somewhat due to the free IP (though one would think that the increase in the market that follows that new availability of free IP will be focused on tools at the low end of the market pricing). Further, the market is characterised by a high transaction cost – the cost of changing tools is much more expensive than most of the tools. Most HL7 implementers already have made their architecture/framework choice from amongst the available tooling options, and won’t lightly change
  • Is HL7 prepared to enter the market of some of its most active members and compete with them? how could they respond, and would their response be even more damaging to HL7?
  • The existing tooling providers are mostly small (though some are very big indeed), and either sell a highly customisable tool, or are structured to be highly responsive to user requests. If HL7 enters this market, what will it offer? From a market position point of view, what HL7 has to offer is alignment – that this tool really does mean doing HL7 standards well. That works against both approaches (customisability or responsiveness), and yet my market experience tells me that one of these two – or both – are critical
  • The existing tooling providers are mostly built around the product – someone created something for their own use, saw the potential for wider use, and made it so. I don’t know what the market failure rate for these tools is, but I think it’s not insignificant. The existing tools have already survived the merciless market cull, and HL7 will have to create tools that will have to survive the cull.
  • Who will lead the tool development? Most of the tools are conceived and brought to market by a particular person. Recruiting such a person is a lotto – the people who have already proved that they can do this are very expensive, and mostly already embedded in the market. So you need to recruit for potential, which is highly risky
  • At present, one of the common accusations about HL7 is that it’s dominated by consultants who prefer the standards to be complex in order to feather their own nest. I know that this is not true – things are complicated enough by themselves, and we don’t want to make them more so, but nevertheless, HL7′s specifications are complex. What will happen when HL7 gives away free specifications, but sells tools to make them work? Now complexity will be (perceived as) directly beneficial to the organisation. And I think it will prove harder than ever to solve the complexity problem correctly, by producing standards that align with consumers expectations
  • HL7 could try for an acquisition – that’s just a straight numbers game: the more revenue you are buying, the more it’s going to cost. HL7 finances aren’t my thing, but I’m thinking that this would not be a good way to spend the existing resources of the organisation

So is there any space for HL7? Well, I go back to my observation that many of the organisations are providing tooling at less than cost as loss-leaders for the services they provide. If HL7 is providing services, then maybe some tooling logically falls out of that. But are services a good idea? That’ll be the subject of another post.

 

 

Categories: Interoperability, Standards

Identifying Humans

Posted on August 24, 2012 by
1 Comment

The third requirement for interoperability is good identification policies. And the most common problem in healthcare identification is identifying people.

Identifying humans, especially patients, is stupefyingly hard. Even after too many years of healthcare interoperability, I still can’t believe how hard it is. One of the reasons it’s so hard to grasp is because as humans, we are intrinsically good at identifying other humans. But it just doesn’t scale when it comes to successfully identifying humans in distributed systems with more than a few people who must perform the identification.

Many people look to biometrics to solve this problem. The common candidates are finger prints, retinal patterns, some form of phenotyping and most of all, genetic sequences.  But all these suffer from problems (and see particularly http://www.schneier.com/essay-019.html).  Given the expense and reliability problems associated with biometric markers, most healthcare institutions rely on social identifiers. These typically are a selection taken from the candidates listed in the following table, which briefly discusses the issues associated with them.

Name Patients change their names regularly. Names are often linked to marriage customs, and the relationship between names and marriage is changing quickly around the world. Names can be mis-spelt, or mis-reported, and people often carry multiple names for use in different circumstances, and/or have names that don’t fit with local cultural expectations. People also use aliases for a variety of reasons.
Date of Birth Some people do not know their date of birth. This is more common in less developed countries, but there are immigrants everywhere. In addition, there are sometimes reasons to lie about dates of birth, and these can create persistent records that create confusion for many years
Addresses and
Telephone numbers		 People change these all the time. Some people don’t have them. How people describe their address varies (is it for billing, or their actual living location?). Postal systems occasionally change addresses to suit their own processes
Gender Male and Female. Except when neither is perfectly applicable. There are all sorts of laws and customs about gender change and confusion that vary highly from country to country. Mostly gender doesn’t change – it’s highly reliable, but not a very good differentiator between individuals, since the vast majority of people have one of only 2 values
Externally supplied identifiers The classic examples are driver’s licenses and passport numbers. But these are very unreliable – they are re-issued for all sorts of reasons that are only of interest to the issuing authority. And the issuing authority is also subject to all the same identification problems as well, and also often the target of fraud
Mother’s maiden name This is no longer a guaranteed to be available concept due to changes in naming practices. More generally, it’s used as a shared secret, and shared secrets have no part in identifying a person (won’t be secret once you share it, which is what identification is for)

Given the expense and difficulty of these lists, the notion of some state/national identifier becomes attractive – it makes meeting the expense of doing it properly more viable. The registration authority quality is still variable, but it’s generally better than doing it locally (it’s mainly an economy of scale thing). The biggest problem with this approach is that people lose their details all the time.  Until institutions or governments are able to mark people directly with a master identifier, say with a tattoo, this will be continue to be a problem (and given the historical association of identifying tattoo’s - I’ve seen one myself, from Bergen-Belsen, on a tough old Czech who had been in the resistance and was betrayed to the SS shortly after the assassination of Heydrich – it seems exceedingly unlikely that this will be  acceptable in any culture at all in the foreseeable future).  In addition, the registration authority rapidly becomes the target of fraud for a variety of reasons, mostly to do with how healthcare is funded, or to facilitate fraudulent access to higher quantities of prescription-only drugs. These problems can be resolved, and a successful national registry set up – it has happened in a few countries. However it appears to me that the prospects for success have more to do with national cultural factors than administration policy.

Healthcare is occasionally provided to people whose identity is completely unknown. They present unconscious, and care is hardly going to wait until they are conscious. In English speaking countries it is customary to refer to such patients as “John Doe” or “Jane Doe”. Usually their identity is resolved unless they die. (In one case at a hospital I worked at, a John Doe spent 3 weeks in ICU after an automotive accident. Even when he was conscious, he refused to provide any identifying details. Eventually he passed away, and his body was collected somewhat sheepishly by the staff from an embassy of an “unfriendly” country – still with no identification details provided)

New born babies also often do not have a name, though they are not unidentified (though identifying them is a challenge). Also there is a variety of contexts in which patients are not prepared to be identified. Sexual health clinics are a common case in the developed world, and Red Cross and other similar relief agencies often work with patients who refuse to be identified for a number of valid reasons.

All these problems are well recognized and appreciated in Healthcare Administration and Healthcare informatics texts books etc, but I cover them here because they have potential to cause difficulties in interoperability. It’s easy, when doing interoperability, to get trapped between two slightly different policies. On their own, they might each work about as well as the other – but when you try to hook up different business processes, the clash between them creates problems that are difficult to resolve.

Patient Merging

This is particularly true when it comes to patient merging.

Patient Sarah Smailes attends the emergency department at Acme Hospital with an acute attack of abdominal pain. She is admitted to the hospital for a Cholecystectomy. The emergency department clerical assistant who enters her details gets her name right, but mishears her birthday as 30-Mar 1973, not 13-Mar 1973, because of a screaming match between other patients in the background. Later that year, Sarah finds herself back at the hospital with a severe flu attack (H1N1?). The clerical assistant didn’t quite catch Sarah’s surname, and Sarah can’t be bothered telling the him about the previous admission – she’s too sick, and clerical assistant can’t find a Sarah Sm*** with a birth date of 13-Mar 1973, so he just creates a new patient entry. Now Sarah has two patient records. Later, in the ward, another clerical assistant over hears Sarah complaining about her treatment during the previous stay, and goes looking. He finds that the system has two records for her.

 There are several options for what happens now. One is to simply leave things as they are, with two different records. But this raises the prospect of a mistreatment due to missing information from her record, so hospital records staff are very reluctant to do this. Another is to create a “link” between the two records – an entry in the system claiming that they are the same patient. But this leaves another problem – which record should be used going forward? What happens when Sarah comes back next time? A third option is to instruct the system to merge those two records. This means that you pick one of the two records, and move all the information about it into the other record. The patient identifier associated with the first record is deprecated. All the hospital systems that have information about Sarah must follow suit, or their (potentially life-saving) information will in effect be lost.

Let’s try another scenario.

Sue, a Health Information manager finds that there is a record for Sarah Ann Smailes, born 30-Mar 1973, and a record from 6 months later for Sarah Ann Petersen, born 13-Mar 1973. Both records have the same address. Are these the same person? Sue decides that this is the same person, and merges the records.

 Is Sue right? Is this the same woman, now married, with a common typo in the birth date? Or is it a different person who happened to have similar details? It can be tremendously hard to tell, even upon investigation. Let’s say that in this case, Sue was wrong: they are different people, but now the records have been merged. The laboratory notices that this is in error (they have two blood groups that are incompatible, so they dig deeper and prove it’s wrong). Now what?

If the records were only linked, then the link can be broken. But if the records have been merged, and further details added to the record (which happens every few minutes in a busy hospital), now what? How do you unwind this? So merges are much more dangerous than links – except that this is misleading: if the records are linked, so that it is asserted that the two records are the same patient, how do we know that things have been done on the right record?

All we know for sure is that mistaken links or merges are trouble. Yet they happen all the time. My own experience is that in Australia, it’s extraordinarily hard to get the number of merges needed down below 1% of the admission rate, and about 2-3% of the merges will be in error for one reason or another. It seems remarkably hard to get down below these numbers.

So that’s the theory. Now imagine an interconnected system or systems, with the PAS at the hub, but many of the systems exchanging data with each other directly, not mediated by the hub, and with a variety of policies for following patient merges (or initiating their own), and the sibling problem, episodes assigned to the wrong patient. When you consider this picture, all you can say for sure is that no one who does healthcare interoperability is going to be out of work any time soon.

Categories: Interoperability

What can a Vendor do to prepare for Interoperability Challenges?

Posted on August 14, 2012 by
No Comments

This content is taken from a presentation that I made to the Australian Aged Care IT Vendors Association AGM today.

Interoperability presents many demands for a vendor, especially a small vendor. What can do you to prepare for them?

Financial

My experience is that the costs of developing and supporting an integration between two systems is generally more than it’s worth to the purchaser. Yet they still need the integration, and if you don’t provide it, that will look really bad and hurt sales. So you have to recover the costs elsewhere. Possible sources:

  • Direct Charging for the development
  • Licensing the developed code for multiple uses of the same integration
  • Selling more software licenses because you did the integration (this is the Ponzi equivalent)
  • Ongoing support changes for some/all customers
  • Government subsidies (I note that government subsidies to consumers are passed onto vendors with great reluctance, btw)

A vendor that is prepared has a very clear picture about how they finance integration development. I’ve seen lots of models that work, but I’ve also seen that if you don’t have a plan for this, you’ll get yourself into trouble.

Staffing

You need skilled staff that understand the relevant standards, that know how to work with other people, that can get things done. These people are rare… expensive… where are you going to get them from?

  • Are you going to train them up? how?
  • Are you going to buy them? where from?

And once you have them, the most important thing to do is to hang on to them. Perhaps it costs you in the region of $50-$100k to acquire and embed a capable person… you really need to hold on to them. And at least in Australia, you can’t have a person like that without them becoming known, and once they’re known, they’re going to have people calling them offering them jobs. So you need a really good retention policy for them.

Data Policy

Opening up your data to exchange is more challenging than just implementing a closed system. It makes more demands on your data. Here’s some principles I’ve learnt:

  • Normalise your data
  • Don’t hide blobs of data in some syntax that needs code to read it
  • Pay attention to likely applicable standards when you design your data store (if you go different, simpler, or more complex, you’re going to have problems)
  • Keep good metadata and make it available in the code (as the format becomes less context specific – i.e. national EHRs – that’s going to become more important)
  • Keep your data store design as consistent as you can
  • Make sure your code is modular and limit the dependencies between logic modules (and no dependencies on UI modules from logic modules!)

External Integration Point

Use an external integration point – a single sub-system that all the external exchange flows through (or as much of it as possible). Mostly these are called interface engines, though sometimes they are called Message Transfer Agents, or Gateways. There’s any number of commercial engines (including my own), and Mirth is a pretty good engine. Using something like this is a really good idea because:

  • It isolates your application from variable site specific requirements and partner application life cycles
  • They provide advanced troubleshooting options and installation robustness
  • You can leverage them to support multiple standards more cheaply

 

I still see vendors that don’t do some of these things. And we know that there’s going to be winners and losers in the never ending battle between vendors. And the losers…. go bust. These are the things that I know you can do to avoid going bust when the government leans on you to provide better integration functionality.

If you know other things – drop me a line in the comments.

 

 

Categories: Australia, Interoperability

Understanding v2 Acknowledgements

Posted on August 2, 2012 by
No Comments

Almost always, when you send an HL7 v2 message, you need or get an acknowledgement message back from the destination system. This post describes how these acknowledgements work.

Scenarios

There’s 2 main uses for acknowledgement messages:

  • You need some content returned from the destination (i.e. accepting an order, getting an answer to a query)
  • You simply need to know that the message was received and processed without error

There’s a few corner cases where you don’t even need acknowledgement – the sender simply doesn’t care whether the receiver gets it or not. In the real world, the only case that I’ve seen for this is a vital signs monitor that sends an observation message with the current vital sign measurements once every minute. It’s assumed that some other system will raise an alert if the messages aren’t getting through. In every other case I’ve seen, there’s some kind of acknowledgement.

Response message

Each HL7 v2 message Event has a defined message type, and also a defined response message type. The most common response message is the simple ACK message:

That’s the v2.6 version, with the SFT and UAC segments that I’ve never seen in production. Otherwise, it’s got a message header (MSH), the MSA segment, which summarises the acknowledgement status of the message, and it may have one or more ERR segments that list specific issues in the message. I have seen ERR segments in production, but not often.

There are response messages with a much more complicated structure, such as the response to an R02 event, which is a full blown order message with an MSA added – a query for an order. In this post, I’m solely going to deal with the issues around message level acknowledgements.

MSA Segment

The MSA Segment has the following fields:

 # Description Data Type Table
1 Acknowledgment Code ID: Coded Value for HL7 Defined Tables Acknowledgment code (0008)
2 Message Control ID ST: String Data
3 Text Message ST: String Data
4 Expected Sequence Number NM: Numeric
5 Delayed Acknowledgment Type -: withdrawn
6 Error Condition CNE : Coded with No Exceptions Message error condition codes (0357)

The first field contains the acknowledgement code, where the possible values are:

Code ID Description
AA 1 Original mode: Application Accept – Enhanced mode: Application acknowledgment: Accept
AE 2 Original mode: Application Error – Enhanced mode: Application acknowledgment: Error
AR 3 Original mode: Application Reject – Enhanced mode: Application acknowledgment: Reject
CA 4 Enhanced mode: Accept acknowledgment: Commit Accept
CE 5 Enhanced mode: Accept acknowledgment: Commit Error
CR 6 Enhanced mode: Accept acknowledgment: Commit Reject

I’ll discuss the enhanced mode acknowledgement below. So you can receive 3 different kinds of codes:

  • Accept – the message was accepted without error
  • Error – the message had an error and was rejected
  • Reject – the message was rejected because of an error

I’ve always wished that there was some consistent difference between “error” and “rejection”, but I’m not at all sure what it is. In fact there’s no particular definitions of these two concepts. The best I can find is that a reject (CR) is returned if the one of the values of MSH-9-message type, MSH-12-version ID or MSH-11-processing ID is not acceptable to the receiving application, and an error is returned if the message cannot be accepted for any other reason (e.g., sequence number error). However this is rather confused by the table of values for MSA-6:

Code ID Description
0 1 Success: Message accepted
100 2 Error: Segment sequence error
101 3 Error: Required field missing
102 4 Error: Data type error
103 5 Error: Table value not found
200 6 Rejection: Unsupported message type
201 7 Rejection: Unsupported event code
202 8 Rejection: Unsupported processing id
203 9 Rejection: Unsupported version id
204 10 Rejection: Unknown key identifier
205 11 Rejection: Duplicate key identifier
206 12 Rejection: Application record locked
207 13 Rejection: Application internal error

I don’t know how to make systematic sense of this. If the database is down, so you can’t accept the message, should you return an error, or a reject? Beats me. And in practice, implementers seem to pretty much toss a coin. I think I’ve seen more AEs than ARs, on about a 4:1 ratio.

Processing Failures

I find this particularly frustrating because the question I always need to ask when I get an AE or an AR back is simple: should I send this message again?

In practice, the single most common cause of a message error/rejection being returned is some transient system error. Things like:

  • database is down / backing up
  • message handling process has become corrupt
  • deadlock contention
  • network unavailability

In all these cases, the correct thing to do is wait a while, and resend the same message again, and to keep doing so until it succeeds. If, on the other hand, the destination is working as expected, and there’s some content problem with the message, then what you want to do is to discard the message, make an entry some error log, and move on. So how can you tell the difference? Well, there’s no general method, and quite often, you can’t. I think this is one of the worst aspects of HL7 v2 messaging.

As a follow up to this, there’s a related question: do I need to send the messages in order or not? This is also a rather difficult question. There’s no technical requirement anywhere in the HL7 standard I know of that says that messages have to be delivered in order, but the messages reflect a series of transactions, and these generally do need to be delivered in order. Consider the following scenarios:

  • An ADT feed pushing patient and episode updates out. What happens if you drop a patient merge message, and then send it later, after other transactions on the patient record? (and in practice, merge messages are particularly prone to cause issues)
  • A results feed from a lab to an EHR. Lab results are amended periodically. What happens if you hold a message, and then release it – will it overwrite an subsequent version of the same lab report that was sent later?

In practice, this depends on the fine details of the identity and timestamp processing of the receiving system. HL7 has made no rules about how this works, so you can take nothing for granted. In practice, most v2 processing feeds are unreliable and fragile in this regard, whether from big or small vendors (that’s my experience) so it’s best to be very conservative unless you specifically know otherwise : If you get an error, hold everything until some knowledgeable human intervenes. Assuming, of course, that there is one available… where as there very often isn’t.

More

I’ve run out of time for now. I’ll make a follow up post that deals with enhanced mode acknowledgements, with the impact of intermediaries, and with a commentary about the sequence number protocol.

 

 

 

Categories: Interoperability, v2

MSIA’s Clinical Messaging Profile

Posted on August 2, 2012 by
No Comments

Yesterdays’s post about Healthlink’s Messaging Quality Initiative created some email chatter, and I need to issue a couple of clarifications. But I should also explain the process:

The MSIA Process

In late 2010, it became obvious that the Australian Governments’s various initiatives that focused on more secure, robust exchange that was intended to make it easier to exchange content with any healthcare participant would require more robust interoperability at the content level. This underlying cause manifested in the impact that SMD would have on the existing content distribution networks. The way they currently work (roughly) is that they transfer HL7 v2 messages from source to destination, but while doing so, they consult a large lookup table to compare source and destination systems, and see what changes they need to make to the message actually work. Changes are required to work around differences in:

  • Message parsing
  • Message routing and storing
  • Content Processing and Presentation

Some of these things are utility/functionality, but some are basic clinical safety considerations.

As a consequence, MSIA invited any interested vendors – the source systems, the destination systems, and the guys in the middle – to discuss the problems, and come up with solutions, with the intent that all the MSIA members would be required to change their systems to implement the agreements. The overall goal was to remove the need for messaging vendors to modify the messages as they transfer them.

The initial problem list was primarily contributed by Medical Objects, who were enthusiastic participants. Other participants included Kestral (my employer at the time), Healthlink, Genie Systems, Healthscope, AHML, DCA, Queensland Health, Argus, Global Health, Totalcare, Medisecure, Medinexus, and Smarthealth. (If you participated, and you’re not on the list, you didn’t make the minutes, sorry).

The outcome of a couple of meetings over a 3 day period was a report describing the problems and their agreed solutions. This was prepared by Vince Macauley on behalf of AHML/MSIA, and distributed internally to the participants.

I volunteered as a follow up to rewrite the report as a formal message profile with conformance points. This hasn’t gone anywhere, and is what I posted yesterday.

In terms of outcomes, the process hasn’t really ever come to completion. I know that several vendors did make changes to align with the decision that were made, but I suspect that the overall impact has been pretty minor so far. On the other hand, the decisions that were made have been fed back into the standards process for future versions of the AS 4700 standards, and have also informed and influenced decisions on the same or similar issues in the NEHTA specifications.

My Clarifications

Firstly, while Healthlink participated in the MSIA consensus process that defined the clinical messaging profile, they did not lead or initiate it. And, while I’m at it, Healthlink’s initiative wasn’t particularly focused on the MSIA profile, just on standards generally. It’s me that made that link.

Secondly, while I volunteered to write the profile, this was editorial work. The decisions it represents, and any authority it has, are vested in the consensus process shared by the participants. The important parts aren’t my work, and I wasn’t intending to claim otherwise.

Categories: Australia, Interoperability, Standards, v2

Validating Name Characters

Posted on July 4, 2012 by
16 Comments

Well, the pcEHR go-live hasn’t gone that well. One particular feature that’s attracted some attention is that fact that the pcEHR won’t accept people with some unusual characters in their surnames.

From http://www.medicalobserver.com.au/news/punctuation-a-stumbling-block-for-ehealth:

Medical Observer has found patients with apostrophes or hyphens in their name cannot register for an e-health record, as the government scrambles to get the rest of the patient registration process working.

It sounds like a glaring oversight… only, just what characters do you need to allow in a patient’s surname? I suspect that real experts would be fairly circumspect in commenting on this – it’s harder than it looks.

Firstly, in general, this is a good assessment of requirements: http://www.w3.org/International/questions/qa-personal-names. But this is for the entire world. Do you have to support all these in an Australian context? What’s the point of supporting name characters that Medicare don’t support, for instance? (there’s some, but is it worth it). Since most systems we have were designed pre-unicode, the answer can never be as simple as, any unicode character.

Perhaps there’s an applicable Australian standard? How about AS 5017, “Health Care Client Identification”? Now what is has to say about this is:

Family Name Verification rules:  Alphabetic characters, tilde (~), punctuation (.,-) and spaces only (2006 version)

It shouldn’t come as a surprise to anyone that AS 5017 is the standard which has been followed in the design of the HI service and the pcEHR, and you’ll note that apostrophes aren’t on the list (though hyphens are, so I’m guessing that hyphens are actually ok, but the spokesmen was confused on the fine details – pretty likely in my experience).  Now it sounds like a glaring oversight not to accept apostrophe’s, but all you need is one developer to faithfully follow the rules – that is what you want, after all – and the tester’s to miss this minor point, and bingo – you have a public relations disaster…. (I must say, I have no idea why tilde’s are on the list – I’ve never seen them in a name?)

For given name, AS 5017 doesn’t specify any verification rules. There’s some good advice in Meteor for family name and given name, but again, no comprehensive list of characters there either. While writing this blog, I spent some time perusing the medicare web site for the rules around name character verification – they obviously do have them, since there’s error codes relating to invalid characters in names, but I couldn’t find what they are.

At an HL7 meeting, I heard about a US family that named their son φ, and expected systems to cater for this, but I’m pretty sure that you wouldn’t need to cater for this in Australia.

If anyone has more information, it’d be great to have them in the comments. Thanks

Categories: Australia, Interoperability, Standards

The fly in the XHTML ointment: CSS

Posted on June 10, 2012 by
9 Comments

In CDA R2, the narrative portion of the document is a format that is based on XHTML, but is not actually XHTML. HL7 provides an xslt that does a reasonable job of transforming it to XHTML for display, but the consequence of this is that authoring the narrative is hard – there’s no off the shelf authoring tools for the CDA narrative.

So for CDA R3, the committee has decided to use XHTML. Well, a subset of XHTML, anyway. I think it’s not too hard to describe a reasonable subset of XHTML:

the basic html formatting elements described in chapters 7-11 (except section 4 of chapter 9) and 15 of the HTML 4.0 standard, <a> elements (either name or href), images

(that’s from the FHIR rules for XHTML). In other words, a clinical document isn’t going to contain executable code, forms, objects, frames etc. And that’s not an unreasonable set of restrictions – it’s not going to restrict you from using an off-the-shelf xhtml editor, including the clever little DHTML editor that’s part of word press (which I’m using now).

Images are a problem though:the img source is another resource located somewhere else. This is a problem for CDA because the image is inherently part of the document, and the document loses it’s integrity if the image is lost. The image needs to be available and to move with the document when it is transferred (CDA R2 spec section 3).  There’s various ways to organise that, but as far as I can figure out, none of them are supported out of the box by off-the-shelf xhtml editors. So either you need to modify the editor – not for the faint hearted (and that’s what we were trying to avoid) – or you need to do post-processing to repatch the img src location. Not nice, but possible.

But CSS – there’s a series of problems here for which I don’t see an obvious solution. Just to recap, you can styles to elements in a document 3 different ways:

  • Including a reference to a stylesheet (a css) in the document header
  • Including a set of named styles in the document header
  • Specifying a set of style attributes on the element itself

See tutorial. It turns out that you can include a set of named styles anywhere in the document (at least you can with ie, firefox, and webkit), though where ever you put them they are global to the document. Generally, use of the last method is frowned upon (see here, here, and here). In particular, quoting from the last link:

  1. Separate content from design
    One of the main goals of CSS is to remove the design elements from the HTML and place them in another location for the designer to maintain. That means that a designer doesn’t have to also be the content developer to maintain the look of the Web site.
  2. Make maintenance easy
    One of the most forgotten elements of Web design is the maintenance. Unlike print materials, once you put out a Web “magazine” it doesn’t go away. Things change – from the look of your site to the content and links within it. And having your CSS in a central place makes it that much easier to maintain.

Perhaps it’s just me, but I don’t find that CSS makes maintenance easy – I often have to load the web page and debug the style stack to figure out why a particular style is being used, and unless you are extremely disciplined about your styling style, you’ll end up in a mess where you aren’t sure what the side effects of changing some particular style might be. As for separating content from design, I find this more true in the aspirational sense than in the reality – using css lets you change colours without touching the content, but it doesn’t take much redesign work before you’re once again playing around with divs and tables in the content to get the effect you want.

This all brings us to using xhtml in CDA. It’s hard to use xhtml without using CSS. You don’t have to want anything fancy or dynamic – you want a font color, underlined text? <u> and <font> are deprecated in HTML 4, and not in the xhtml schema, so you have to use css. But system designers aren’t going to be happy with the basics – documents have to look good when they are displayed to the user. Font rendering, images, page layout- these matter.

But the other thing that matters is fidelity – the document as rendered needs to match what the author intended. If the author creates and attests to a document where some of the text is red, then that text needs to render red when any clinical user looks at it. This is an important clinical safety issue. And colour and style are frequently used to convey information of clinical importance (abnormal results in diagnostic reports, instructions in clinical summary documents, alerts to adverse reactions…) Though computer centric users (both IT devs and clinicians) frequently forget that a lot of content is faxed, and their look-at-me-colors degrade to a pale grey through the fax process.

The beauty of the existing CDA design – the custom narrative – is that it clearly delineates between what is the author’s responsibility, and what freedom of the rendering system has to present the document.

Replacing the narrative with XHTML presents the following issues:

  • If the styles are provided by reference, and the referenced style isn’t available, the document won’t display correctly – and may not display safely. Unfortunately, the lack of correct display may not be catastrophic (the document may look like it has rendered properly, but something important is missing).
  • Putting the styles in the document – either in line or in the header (which would mean a special place in the CDA document for before it’s transformed to real xhtml) would work, but it would mean that the renderer loses all control over the document

There’s one more issue to consider: Often, documents are assembled from information gathered from multiple sources. Some of it’s mastered in the application preparing the document. But other parts – significant parts – the application will be gathering narratives prepared by other applications, and maybe in other formats. For instance, a clinical summary that includes diagnostic reports. What if these different sources are using different incompatible styles?

From an engineering/standards viewpoint, it’s starting to sound as though we’ll need a single fixed CSS for all users of xhtml in CDA – effectively replicating the current system, where there’s only a fixed set of style codes that you can use. But unlike the current design, where there’s a transform separating the authored and rendered styles, we’ll need a very fine grained and precise list of styles that the author can use, and ones that the renderer can use, and I don’t like the sound of that. More generally, I don’t like the sound of having a fixed CSS for all uses of clinical documents either. And we can abandon all hope of using off-the-shelf authoring tools…

None of these options are any good. Which is why I always preferred CDA to use it’s own narrative.

But in FHIR, we’ve said from the start that the narrative portion is xhtml. Which means we need to solve this properly. I figured we’d solve it when we got to it, but now that we have, I’ve drawn a blank. I’m hoping that someone will explain a simple, elegant and obvious solution that I’ve completely overlooked in the comments to this post.

 

Categories: CDA, FHIR, Interoperability

Lifecycle of an Interface

Posted on May 2, 2012 by
No Comments

In the beginning, there’s a rush of excitement, and the interface is conceived.

Then there’s a difficult gestation, as the interface slowly becomes ready for birth. During this stage, people swing wildly between excitement about what the interface can be, and worrying about what might go wrong

Then, the interface goes live. There’s going to be lot of sleepless nights, and much wailing and gnashing of teeth (and that’s on the part of the new interface)

Eventually, things settle down, and the interface even stops falling over.

Finally, the interface is fully mature, and it knows how to behave properly in all circumstances. Now the interface enters the really profitable stage of it’s life – the bit that justifies the rest – it just sits in the background doing it’s job, and making money without fuss.

Finally, though, the changes around the interface start to catch up with it, and it’s starts to look rather aged. But it’ll soldier on, doing what it knows how to do, while people get increasingly frustrated with it.

Eventually, it moves onto life support – hardly anyone knows how to work with it anymore, and those that do would rather not – unless copious quantities of money are exchanged.

And then, way after anyone is happy anymore, the interface is finally laid peacefully to rest.

 

No wonder we think of them as individuals with their own personality…

Categories: Interoperability