Monthly Archives: May 2012

Inviting you to the FHIR connectathon

On Saturday September 8, we will be holding a FHIR connectathon in Baltimore, MD (USA) as a prelude to the next HL7 Working Group Meeting, where we’ll practice interoperability using FHIR.

It’s still early in the development cycle, and no one’s going to be using FHIR for real clinical systems yet… but we already have full implementations of the specification. A connectathon will be a way to find out exactly whether FHIR is as easy and practical as we intend to be, and to learn how to make it even easier, if possible. Also, it’s our chance to start building an enthusiastic user community around FHIR.  We’re going to be testing implementations around RESTful use of Profile and person – servers, mobile clients, pub/sub using Atom (i.e. mashing up blogs and operational registries), and especially focused on a clinical template registry infrastructure. The exact details are still being clarified.

From an organization perspective, it looks like we’ll be able to call on some experienced IHE connectathon participants to run the day – more on that once it’s firmed up, and the FHIR technical leads will be present and testing our own implementations too.

The connectathon will be free – there’ll be no charge to attend. It’s a first time, and we’re just testing the notion. But because we need to plan the day, we’ll be asking people to commit in a couple of months time.

Why you should participate:

  • It’s a great way to get to know the community
  • FHIR is a much simpler and more robust specification than the alternatives
  • It will give you a leg up on getting to the market quicker than your competitors – and if FHIR delivers on it’s promise, there’s plenty of opportunity for creative destruction coming!
  • Turning up and testing real code at the connectathon will give you a much more effective voice in the development of FHIR (+ it looks likely that there’ll be a formal process where companies who participate in the connectathon get their own representation in FHIR Governance)
  • It’s free – this time.
  • Because connectathons are fun

If you’re interested, let me know at grahame@healthintersections.com.au, or track this blog, where I’ll announce more news regarding the connectathon as it develops.

Updated list of FHIR Sessions at Vancouver WGM

Here, as promised, is an updated list of FHIR Sessions here in Vancouver WGM, starting from now:

  • Sun Q3 (in 45 minutes time), a tutorial to show committees how to build resources
  • Mon Q3 (MnM): Datatypes R3 proposals arising from FHIR data types
  • Mon Q4 (SOA): FHIR discussion with SOA (part of the session)
  • Tues Q1 (MnM): profiles and extensions
  • Tues Q2 (MnM): governance and ballot plans
  • Tues Q4 (Devices): general discussion, CIMI and FHIR (first 30 minutes)
  • Wed Q1 (ITS): formats – xml, atom, and json
  • Wed Q1 (MnM/Vocab): Vocab binding Methodology in FHIR
  • Wed Q2 (ITS): REST related issues
  • Thurs Q1 (RIMBAA): FHIR implementation session
  • Thurs Q4 (ArB): FHIR/SAIF/governance wrap-up
  • Fri Q1 (Templates): Profiles and clinical templates
  • Fri Q2 (Pharmacy): Prescription model design

There’s also some discussion about FHIR governance at TSC on Sunday evening (this evening).

 

Updates:

  • methodology and SAIF implementation guide will be discussed MnM Mon Q1
  • MnM Q1 will include FHIR SAIF IG
  • RIMBAA Mon. Q2 will include CIMI & FHIR compare/contrast
  • Tues Q3 in PA

* Tuesday Q3: PA FHIR next steps

Question: Identifying the organisation of a referring provider (AS 4700.6)

Question:

We are looking at receiving referrals REF I12. Currently they are V2.3.1 AS 4700.6-2004. In these referrals we need to be able to identify the organisation of the referring provider, preferably with an HPI-O. It seems that the only place that this can go is in PRD.4. Do we need to use HL7 V2.5 and put the values in PRD.4.10 & PRD.4.11? Is there a better place we could put this in HL7 a V2.3.1 message?

Well, PRD.4 is named “Provider Location”, with the rather confusing definition (v2.3.1):

This field contains the location of the provider as needed when a provider that may be external to a given enterprise must be referenced.  For example, if this provider represented the referred-to physician, the PRD-4-provider location should identify the clinic of the physician or provider to whom this referral has been sent.  The identification of the provider’s location is specified by an application and facility identifier carried in the facility field.  The application ID and facility ID would be used in the same manner as their corresponding fields in the MSH segment (MSH-3-sending application, MSH-5-receiving application MSH-4-sending facility, MSH-6-receiving facility).

The facility field is PRD-4-4. This definition is… not helpful, because it confuses the physical, logical and organisational place, all of which are different perspectives. The definition is untouched through to HL7 v2.7. But given that the definition of the PL data type is quite orientated to physical location, and the definition of PRD-4 is orientated towards the logical/messaging place, I’d be wary of putting the organisational identifier there, particularly an HPI-O which is very location independent.

v2.6 provides more of an answer to this question, in the definitions of fields 10 – 14 in the PRD segment:

 10 Provider Organization Name and Identifier XON : Extended Composite Name and Identification Number for Organizations 250
11 Provider Organization Address XAD : Extended Address 60
12 Provider Organization Location Information PL : Person Location 60
13 Provider Organization Communication Information XTN : Extended Telecommunication Number 250
14 Provider Organization Method of Contact CWE : Coded with Exceptions 705

Given that v2.6 defines these fields, then it would be best to preadopt these in v2.3, particularly PRD-10

Pre-adopting v2 fields

This is a fairly widespread practice in Australia; it’s preferable to using a Z-segment, because the definition of the field is known – you have to look far enough forward to where the field is defined. It’s also the anointed “right place” for the information, and if you asked the relevant committee, you’d get the same answer again. Pre-adopting fields – and also lengths – can have the effect of breaking implementations, though it shouldn’t (same can be said for adding z-segments too).

In this case, you’ll have to have a trading partner negotiation whatever, and of the various choices – misusing PRD-4, using a Z-segment, and pre-adopting PRD-10, I’d be wanting to choose the latter, though your choice is always constrained by your trading partner(s).

 

HL7 Progress Report

 

This blog post is based on a presentation I made to The Australian Medical Software Industry Association (MSIA) at a recent meeting. The focus of this presentation was a CEO level summary of where HL7 is at, as context for how to understand the use of HL7 standards in Australia. Note that interoperability is a major piece of the landscape here in Australia, and most CEOs are somewhat (through to intimately) involved in it, and therefore at least familiar with the innards of a v2 message.

Use of HL7 in Australia

HL7 v2 was first used for exchanging patient management information in single-campus hospitals. Over the last 20 years, the use of HL7 v2 has grown from that to be used for diagnostic reports in hospitals and then between clinical providers, and also referrals and discharge summaries within and between providers. There is also some use for pharmacy messaging, though I am only aware of this internally to an institution.This use has been aided and fostered by a series of Australian standards known by AS 4700.x where x indicates the intended use of the standard.

Recently, the National e-Health Transition Authority (NEHTA) has been introducing a new set of exchange specifications based on a more recent HL7 specification called CDA (“Clinical Document Architecture”) and the first round of implementation is in high gear at the moment.

HL7 v2

HL7 v2 is a messaging based standards – the content is exchanged in messages that have codes that indicate what real world events they relate to. The messages are divided into segments, segments into fields, fields into components, and components into sub-components – 5 levels of nesting. The syntax is based on delimiter characters for each level. HL7 v2 messages are backwards compatible – what you see in the message will never move to a new “place”, or be re-used for something else. Here’s an example:

V2 has lasted amazingly well – it’s still getting a lot of use, new adoption, and has a serious fan club. What’s good about v2?

  • It’s a real simple syntax – you can roll your own parser pretty quickly (though a caveat: we consistently have problems in Australia with characters not being escaped or un-escaped properly)
  • The v2 concept is simple – it takes about 5 minutes to explain the various parts, and the implementation stack is shallow (programmer, analyst, support people – everyone looks at it the same way)
  • There’s a heck of lot of v2 adoption out there- toolkits are mature, libraries thoroughly debugged
  • it’s easy (relatively) to find experienced people – there’s lots of them
  • the strictly enforced backwards compatibility preserves investment (in fact, it’s actually at least an order of magnitude easier to switch between versions than to deal with the variation between implementations, though this doesn’t stop large vendors charging $100,000+ for changing versions – shame on them)

On the other hand, there’s some real problems with v2:

  • It really is old tech – you have to roll your own parser, it’s not xml or json, and you just can’t leverage it; it’s not a good fit to any coherent architecture
  • The definitions and approach were never rigorous – the definitions are inconsistent and also – worse – incomplete. Much is left to two implementers coming to joint agreement about, and the messages can’t be understood outside that agreement
  • The described syntax is very focused on admin/support
  • The 5 level hierarchy, and the fact that things are defined at a particular level of the hierarchy, means that it’s very difficult to describe sophisticated clinical information well in v2. Clinical information is delegated to a tree of name-value pairs with no good way to control them
  • Formatted text support is still based on a grid of fixed font characters and console features such as moving the cursor around
  • The strict backwards compatibility rule ensures that old decisions seriously limit new ideas, and any kind of fix for these other issues
  • And “if you’ve seen one v2 interface, you’ve seen one v2 interface” – every interface is different

A long time ago HL7 looked at that list and decided to do something better.

HL7 v3

The next version of HL7 would be different:

  • Based on rigorous and complete definitions – no more needing to consult local agreements to understand the content
  • Consistency would be enforced by deriving all instances from a common reference model that also imposed thorough and reliable modeling
  • The base would be constrained to useable artifacts for particular business requirements
  • which would produce generated artifacts and a specified XML format for exchange
  • the whole stack would be computable to aid with implementation
  • There would be notional backwards compatibility – it would be understood how to migrate from old to new formats, but changes would be possible

HL7 has spent 15+ years developing v3 now. It’s had an immense amount of work, but adoption is disappointing. But it’s not that there’s nothing good about v3:

  • It does have rigorous definitions
  • There is a computable base, and there’s a number of software tools and applications out there that use the RIM as a computable base (including Oracle’s HTB at the core of the Australian pcEHR)
  • There was an absolutely massive requirements gathering effort that provides a very comprehensive international view of the healthcare landscape.
  • And it’s XML, so you can use and leverage the XML tool stack

But that just hasn’t been enough to overcome the rather evident problems with v3:

  • There’s a really deep implementation stack; it takes months to build it, and different participants have radically different perspectives on it once it’s built.
  • V3 has complex concepts and syntax – everything must be understood at multiple levels and is documented in multiple long documents
  • The core concept – constraint on a common model – fails to deliver on it’s basic goals (mostly because it’s just too hard not to introduce new semantics by stealth in the derived models)
  • Common semantics doesn’t produce common engineering
  • “if you’ve seen one v3 interface, you’ve seen one v3 interface”

So after 15+ years, there’s a few implementations by large national programs that cost lots of dollars, and require lots of implementation support and tooling. Realistically, there’s not going to be any more implementations, and v3 development is tailing off….

But all is not lost: enter v3 lite: CDA.

If you’ve seen one interface

But before we talk about CDA, a diversion about interfaces. They say “if you’ve seen one v2 interface, you’ve seen one v2 interface” – and it’s true. But I think that if I’ve seen one set of interface requirements, I’ve seen one set of interface requirements. The question we need to ask is “how much of the variation between interfaces is due to things internal to v2, and how much is external – because you won’t be able to get rid of the external variation.

There’s no question that some of the variation is due to v2’s incomplete and inconsistent definitions. But I think it turns that this is a small proportion of the total. With v3, we consciously delivered a standard that pushed back against variation between interfaces – and we discovered that it didn’t present a coherent way of dealing with that variation – in fact, it made the problem worse. With v3, you could actually joke that if you’ve seen one interface, you already seen lots of interfaces…

CDA

CDA is a clinical document. It has a header that identifies the document, who it is about, who wrote it and/or signed it, and a few other useful context things, some document narrative (formatted text with images), and some supporting structured data. The header and the structured data are based on the V3 RIM with constraint (which means that CDA is a v3 thing, though not “v3 messaging”). Compared to v3, CDA is easy to adopt. But CDA is a very different idea from a v2 message indeed.

It’s important to understand that CDA is a document – and it should be thought of like a word document. Word documents have properties, and you can make comments on them. Wouldn’t it be good if you the properties included some medically useful things, and you could add structured data in the comments?

That’s just what CDA is – a format for doing that. Because CDA is the bit of v3 that actually worked, a lot of people are using it for data exchange, rather than as a document but it’s not really a good fit for that use.

So what’s good about CDA?

  • Its’ (relatively) easy to adopt – at least compared to some alternatives including v3
  • It’s very flexible and adaptable, and all CDA documents have the same basic XML structure
  • It’s got wide adoption across the world, and there’s a lot of implementation guides published
  • The document semantics suit large EHR’s (i.e. national ones) where there is poor clinical governance across the scope of the EHR

(Aside: That last point is very definitely the context here in Australia. We are implementing a national EHR (the pcEHR – it is a national EHR, though carefully limited in functionality for political reasons), and we are doing so in the context of poor clinical governance. Now making that statement at the MSIA meeting seems to have caused some waves for me, because some thought I was criticizing NEHTA’s clinical leadership and governance (which I contribute to, btw). But no – that’s not my point. My point is, NEHTA and/or DOHA or anyone else can’t simply decide how a certain clinical fact (an allergy, say) should be represented, and then have everyone in Australia agree (let alone actually implement the agrement – hell we’re lucky if they even comment). Given that there’s no prospect of getting the clinical users to agree with each other, we have poor clinical governance, and we have to live that. In that context, a document based EHR – the EHR you can have – is better than a data based EHR – the one you can’t have.)

But there are also problems with CDA:

  • A document is not a good fit with transactions
    • We still have ongoing concern and confusion about narrative vs text
    • Limping along with v2 transactions and CDA data sets (and I have a Standards Australia task against my name to somehow do something about that)
  • The constraint methodology is time consuming and resource intensive – both to produce and implement the CDA Implementation Guides
  • The structured data part of CDA is both too complex and too simple
    • It’s too simple because it’s difficult to represent the agreed Australian clinical models (such as they are) cleanly in the CDA data
    • It’s too complex because I work with the implementers every day at the moment, and I feel their pain

CDA is the near term future for Australia, but I hear rumbles across the community: there has to be a better way…

Where does that leave HL7?

Well, v2 is widely implemented, and we’ve used it harder than anyone else (so far as I can see), but it’s self limiting. There won’t be any more v3 implementations, and the national programs that used v3 will have to figure out what to do. CDA is a good for clinical documents, though I suspect there has to be an easier way, and it’s not a good fit for exchanging data. So what should HL7 do?

Few people at HL7 are happy with the current situation. They’ll support change – a fresh look – but what would you do. Well, there’s two ideas around: CIMI and FHIR. I’ve commented on them at length elsewhere (though my blog posts are a bit dated now – I’ll have to update them). But both CIMI and FHIR are still very early in their process. We’ll have to see what develops.

 

 

Clinical Safety Case: Email Sending Rules

It seems like there’s been a meme running around Australian clinical circles about how the coming of e-health, and particularly the deluge of mobile apps that is just around the corner means that there needs to be good clinical safety governance. Here’s a good example:

Dr Fernando called for clinical software for personal mobile devices to be regulated now rather than “waiting and letting the courts decide”. “I don’t want to constrain the use of what I think will be a potentially wonderful medical device, but I do think there is some guidance required and litigation is not the way to provide guidance,” she told Australian Doctor. Dr Fernando called on the TGA and the Australian Communications and Media Authority to work together with professional organisations to “list, evaluate and classify” software.

(cited from here, but the source is here). And also there was this, though the focus of that is different.

The thing is, this whole clinical safety governance thing is pretty arcane in the context of software. What does clinical safety actually mean? What would regulation actually achieve? I don’t think there’s any easy answers, and I thought I’d illustrate this using a safety case that we can all get our heads around: email.

The Problem

The problem is actually easy to describe, and I’m sure most of us have seen it in one way or another: when you hit send, where is your email going? Here’s two cases:

  • When I look at an email that I have sent in gmail, and reply to it, the new message goes to the person(s) I sent the original to. When I do the same in outlook, the new message goes to me.
  • When I respond to an email from a mailing list, some lists configure the mail to respond to the list by default, and some to respond to the sender by default.

What’s the safety risks here?

In the first case, I may think that I’ve sent a response to someone, but actually I haven’t. Of course, I’ll notice almost immediately – unless I’m in a hurry, and I rush off before checking for new email. The second case, on the other hand is both common and serious. It leads to one of two problems:

  • You respond to a message, thinking that you’re sending it everyone, but you accidentally only send it to the person you are replying directly to. Sometimes you realize later, but only once the consequences of mis-sending the email become clear
  • You respond to a message, thinking that you’re sending it just to the person you are responding to, as a side note, but you accidentally send it to everyone

The second case can be quite serious – in fact, I’m sure it’s cost lives in the wrong place. It seems like a regular occurrence on email lists where the default reply is to the lists: a passionate argument gets going, and someone sends a message worded on the lines of “gee, Bob, I don’t know why you bother, Alice is a total Moron”. No amount of “Eve desparately wishes to withdraw that last email which was sent, written and conceived entirely in error and Eve would like to assure you that she never meant a word of it” emails are going to undo the damage that’s been done.

So we have three problems with escalating levels of seriousness, but quite different manifestations of risk. But how do you quantify these risks and compare them to each other? And there’s a more insidious level of risk that’s even more intangible: the cumulative effect of these problems is to leave people wary of email, and to not use/rely on it too much (and, of course, I’ve only barely begun to scratch the surface of that problem, but it’s enough just to deal with these specific things for now).

I think that this is a good case for considering clinical safety not because I particularly think that clinicians should use email – though it is widely used – but because any e-health solution is going to involve messaging tools, and email is an instructive case. You can rewrite the use cases above around clinical messaging – I’ll leave that as an exercise for the reader.

Root Causes

As far as I am concerned, there’s three root causes underlying these problems:

  • inconsistent behaviour between software products (the second case is complicated by inconsistent behavior between applications, though all the ones I use are now consistent around this case)
  • (in the second case) the email standards allows emails to specify a reply-to address – usually from: and reply-to: are the same, but not always
  • people send lots of emails (I send on average >100 emails per day)

If we’re going to do something useful in email safety in regards to governance and regulations, then clearly this is an important area to address: it costs us efficiency, lost opportunities, and has occasional social disasters from which anything will happen, and there’s a background loss of trust in the overall useability and reliability of the system.

Mitigation

What controls can we put in place to mitigate the danger here?

  • The most obvious thing to try it to nag the user to ask if they’re sure. But this won’t help. Users will quickly come to click “yes” in the check as a pure reflex action, and even if they realise it’s wrong, they’ll still probably hit “yes” (a problem I have in different contexts where the software nags me about things I do all the time). Making the “yes” and “no” buttons appear in random places will annoy a user no end, but won’t make them think
  • A better approach  is to implement an automatic 5 minute delay between sending, and actual sending. During this period, the message can be genuinely recalled. For various workflow and psychological reasons, users are more likely to realise that there’s a problem in those first 5 minutes rather than later (until the evidence of the mistake arises). Obviously this will only catch a portion of errors. (Note that this solution is implemented in several clinical reporting packages – reports sit in a holding tray for a configurable period of time before being distributed)
  • It’d be nice to show the destination address in a different colour if it was for yourself, a single other person, or a whole list. Unfortunately, while this seems innately obvious to a person, it’s not at all obvious to software – addresses are all the same, and how would it know? but you could reliably show if the from: and reply-to: addresses are different – that’d be something.
  • Gee, the rules so far haven’t achieved much, let’s just impose firewalls across all the email system ports and shut the entire system down. Not such a good idea? alright let’s try something else:
  • It would be good to insist that all messaging systems work the same way, so that people only have to get used to one way of doing things, not more
  • Similarly it would be good to insist that all email lists work the same way

So that’s my list of “controls” or mitigations. 1 that doesn’t work. 1 that mitigates a little on a % basis, but has an obvious price when you’re in a hurry, 1 that lead to a useful but still limited idea but that hasn’t been implemented, and 2 regulation ideas. If you have other ideas, feel free to make them in the comments. (I didn’t bother listing providing safety training – real users don’t show up for training, or don’t bother paying attention, and anyway, training would never address such a complex issue successfully if at all)

Regulation

Guess we’ll just have to regulate. We clearly can’t trust the software developers to have any idea what they are doing; they sure never think things through or do anything like useability and safety assessments. So let’s just go ahead and make two new regulations that all email systems have to follow:

  • When a user chooses to reply to an email that they themselves sent, the reply should go to the destination address of the email
  • All email lists must hence forth be set to fix the reply-to: header to the reply-to: header of the original email

Sounds good…. no. I’m sure I just made anyone who understands email and/or software development blow up. These rules are utterly ridiculous. There’s so many problems with them – they mean well, but they just won’t work. And by the time you’ve finished scoping and qualifying them enough so that they actually are realistic, they won’t mean anything anymore. Just a short list of problems with them:

  • What’s email? Do you want to include facebook messaging? Internal system email? Or external email?  (Outcome: you can’t define the scope)
  • What’s your governance scope? Do you have clean-room governance where all the systems inside the sandbox are under your governance, and all the systems outside your governance are outside the box? (Answer: no)
  • Software packages actually work differently for reasons – both commercial and utility related. You can legislate against these factors, but you can’t make them actually go away
  • The actual way that email addressing and routing works is way more complex that those rules describe. There’s all sorts of legitimate reasons for the complexity, and the rules as above would prevent many valid safe uses of email accidentally
  • They still don’t actually fix the problem – just make it less likely

That’ll do -I could go on, but I think that’s enough to make the point. Regulation won’t work. But even worse, as well as not working, regulations are always written – have to be written – for today’s problems. And they require specific solutions for todays problems that end up preventing tomorrow’s solutions. (Email too open to abuse? build a social network and move your messaging in there…)

So if regulation isn’t the answer, then what? Some say, trust the developers

Trust the developers

Naturally, I’m drawn to this. I’m one myself, and I know how hard all the developers I’ve worked with work to develop safe useful software. We think about it (obsess about it). And most of us get judged on our success in this regard in a particularly harsh environment – the market.

On the other hand, I talk to users too. And so I know the gap between acceptable behaviour, and the things vendors/developers actually do. One story: one vendor had a system that only had one first name field. Users routinely entered middle names in the first name field. The vendor was required to write an interface that only accepted the actual given name in the first name field of the message. Solution: write a script to just delete all the middle names from the production clinical database. Enough said….

Conclusion

The safety risks are genuine, but we can’t mitigate them, and we can’t legislate them away, and we can’t trust the software developers? what to do…..?

Ideas are welcome in the comments as well, but what I think we should do is:

  • Set up an e-health adverse clinical event reporting authority (like AusCert)
  • Require every vendor selling clinical software in Australia to sign up for event notifications from the authority
  • create a new sub-committee of IT-14 (Australian Health Informatics Standards committee) that tracks the notifications and develops handbooks and/or standards in response to reported the clinical events (yes, I know this is closing the door after the horse bolts, but this is how airlines work – and look, I’ve finally succumbed and made an airline comparison)

 

 

FHIR Sessions at HL7 WGM in Vancouver

Several people have asked me about when there will be FHIR sessions at the Vancouver Meeting.

These are the ones I know about:

  • Tutorial: Introduction to FHIR – Sun Q2
  • Tutorial: Building with FHIR – Sun Q4 (FHIR for committees i.e. building resources)
  • MnM: FHIR methodology & issues – Tues Q1?
  • MnM/Vocab: FHIR / Vocab – Wed Q1  ?
  • ITS: XML / JSON – Wed Q1
  • ITS: REST – Wed Q2
  • RIMBAA: Implementation Experience  – Thurs Q1
  • Templates: Fri Q1
  • Pharmacy: Fri Q2

In addition I’ll be presenting to the board about FHIR during Tues Q4, and I’ll be attending one of the two Mobile sessions with the aim of connecting the FHIR work with the mobile community that is forming.

Further, there may be a session with SOA – still working on that (or more correctly, trying to find a time to work on that)

If there’s anything else , make a comment. I’ll provide an updated list next week

 

Lifecycle of an Interface

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…