The necesssity of electronic health records

http://www.e-health-insider.com/news/4894/patient_told_no_electronic_record_no_care

This little article is about a patient seeking mental health care who didn't want his records in electronic form. The mental health trust said that it couldn't provide care without doing so, citing legal obligations.

Canadian Healthcare Technology - News 764

Canadian Healthcare Technology - News 764: "New eHealth consulting group formed in Vancouver
VANCOUVER – Four leading healthcare IT professionals have launched a new consulting company called The ClearView Group. The new entity will focus on assisting health-related organizations assess, implement and optimize their usage of eHealth solutions.

The four principals of the ClearView Group are:

• Colin King – President (pictured)
• Dr. Alan Brookstone – Managing Partner
• Diane Gerwin – Managing Partner
• Blair Stickland – Managing Partner

The ClearView Group’s objective is to establish a leading-edge consulting company comprised of premier senior and junior consultants driven by a desire to provide optimum value to its clients.

According to King, “The company has a balanced approach and believes that the combination of technical expertise and strong clinical skills are a differentiating factor for the consultancy.”

Dr. Alan Brookstone, a high-profile eHealth consultant who has advised governments and organizations across Canada, noted that the newly formed group has expertise across the continuum of health – in acute care, continuing care and primary care.

In the near term, the company plans to concentrate on opportunities in British Columbia, and will then expand into other provinces and the United States.

The ClearView Group will launch a web site in February. In the meantime, interested parties can contact Colin King at: colin.king@clearviewgroup.ca or Dr. Alan Brookstone at: alan.brookstone@clearviewgroup.ca."

Client Registry integration in BC

Of the six health authorities in BC, three are sending client information to the client registry: VCHA (through several applications), PHSA and NHA.

The other three, VIHA, IHA and FHA are not yet integrated. IHA and FHA havce Meditech and can share their solution, but VIHA has Cloverleaf.
FHA and IHA will use BizTalk 2006 ot integrate using a modified Ministry provided (Sierra written) adaptor.

The HIAL will make direct calls to the EMPI API for Client Queries, but pass-thru the add/update client registry HL7v3 interactions to the EMPI solution. The EMPI API is available thru JMS, making it convenient for efficient above the hial conversations to the EMPI.

Research Idea

It would be great to do some research on how standards are created and maintained in different domains. Infoway is struggling to create and maintain standards - and HL7 seems to be getting itself into some hotwater.
There's room for a big survey of how industry standards are created, how they are published and how they are maintained, and the outcomes would be very beneficial for standards development organisations in the future.

my eHealth 2007 Presentation

http://www.e-healthconference.com/_ehealth2007web/pdf_presentations/wed_use_of_ehr_cripps.pdf

optional elements in HL7

If an HL7 TC does not specify that an element is required then each implementation must choose whether to make it required or not permitted. If your implementation requires the element then the 1..1 cardinality means that each message instance must have a value for that element but that value could be a nullFlavor. (Gregg Seppala)

XML namespaces for HL7

Charlie et al.,
Please understand that many developers are going to work at the schema
level. I do sympathize that the present means of importing schemas is very
wordy. Since complexType definitions are identified by their name and target
namespace, overloading of type names can cause problems. In large projects,
the use of the same name for different datatypes is hard to avoid. In XML
schema, the unambiguous identification of the namespace where the type was
created is achieved by the use of prefixes. The combination of prefix and
type are validated.

I agree that a single namespace is easier for the original programmer of the
schema generator; however, minimization of the number of keystrokes required
to create code is of a low priority. HL7 is used in medical devices, which
requires that good software engineering principles be followed. The schemas
need meaningful names. The present design is too hazardous to be used in
medical devices. Readability and traceability reduce mistakes. A single
namespace will result in a horrible maintenance problem. How many lines of
code are included in the present XML schemas? One of the first rules of
software engineering is to divide and conquer. The present design does not
permit one to readily trace the source of a datatype.

There are only two places where I might use an include element: 1) to make
directly visible parent schemas into their children and 2) for the types of
the schema for XML. Placing xs: before all of the common datatypes is
incongruous and clutters up the schema code. Periods or another separator
can be used in the names to show inheritance trees.

"Creating a separate namespace for every message type results in a huge
proliferation of different representations for the same underlying semantic,
and this problem persists to a lesser degree as you walk back up the stack
towards the most abstract (ie the RIM)."

No! One can group closely related datatypes into one schema. Inheritance by
extension and composition (group containing a sequence of elements,
attribute groups, and substitution groups) works in XML schema. We need an
expert opinion to determine if in XML schema 1.1 inheritance by restriction
works between schemas (see quotation below).

From: XML Schema 1.1 Part 1: Structures
W3C Working Draft 31 August 2006
(http://www.w3.org/TR/2006/WD-xmlschema11-1-20060831/)
"Issue (RQ-17i):Issue 2820 (RQ-17 simplify restriction rules)"

"Version 1.0 made clear that the intention for derivation by restriction was
that restrictions validated a subset of what their base validated. However,
the constructive rules for what constituted valid content model restrictions
for complex type definition not only failed to enforce this completely
correctly, but also ruled out various cases which evidently should have been
allowed. The Working Group has decided to shift to a much higher level
statement of what constitutes a valid restriction, appealing directly to the
subset requirement, in order to address these problems."

"Resolution:

A major change in definition/presentation, with only modest changes in
consequences for schemas and validity, will be made, by defining restriction
for complex type definitions in terms of the desired result, that is that
all members of a restricted type are members of its base type. In the
normative part of the spec. this will be done by appeal to local validity."

"Clarifying: R restricts B: any EII that is locally valid [per R] must also
be locally valid [per B], with side conditions on properties on terms you
appeal to [to] get same child allowed by two content models." [-F2F
2004-03-12, section Subsumption (W3C-member-only link)]"

This appears to mean that the XML schema language will have a significant
improvement in the capacity to design and create datatypes according to
object-oriented techniques. I should note that the capacity to group
related complexTypes in one schema appears to be persevered. This permits
construction of large projects, such as HL7 from a hierarchy of schemas that
is based upon a reasonable number of schemas. It also minimizes the size of
small projects that are developed by domain experts and derived from HL7
schemas. The capacity to create this type of small project will permit the
development of a web of clinical and research services based on HL7.

Yours,
Bob Leif