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

acceptackCode

What should happen when HL7 v3 acceptAckCode is set to "AL" or "NE"?

From the HL7 standpoint the answer is very easy:

If the acceptAckCode of the interaction that was received is set to AL
then the receiver SHALL sent an accept acknowledgement interaction
MCCI_IN000002, and subsequently SHALL execute the receiver
responsibilities associated with the interaction it has received.

If the acceptAckCode of the interaction that was received is set to NE
then the receiver SHALL NOT sent an accept acknowledgement interaction
MCCI_IN000002, and SHALL only execute the receiver responsibilities
associated with the interaction it has received.

How one deals with this at the services level is out of scope of HL7.
(although an interesting implementation issue ;-)

TTYL,

-Rene

iEHR team

Steven Schnider and/or Ryan Liu - IdM and Security
Manuj Aggarwar - SOAP Message Header and Orchestrations
Marc Boissonneault - Location Registry
David Boa and/or Jim Mann - Logging/Auditing
Sophia Yap - LRS and Notifications/Subscriptions
Hugh Montgomery - Business Requirements for PRS
Pat Jeselon - Privacy, Logging/Auditing and Consent
Ryan O’Connor and/or Louise Harris - Cross Project Architecture

eHealth Collaboratory

We know about the eHealth collaboratory - it's an initiative funded by Infoway and hosted by University Health Network in Toronto. The intent is to host a set of applications which can be tested for conformance against specific messaging profiles. So they can host a CR, for example, and prove that it conforms to a particular HL7 specification

Active and Passive EMPI

Passive (or “back-end”) Integration: This mode is typically used to pass client data
“updates” from the various stakeholder systems to the EMPI. Where feasible, data should be exchanged using a transaction message-based approach (store and forward) with HL7 as the application protocol. The integration would use an interface engine (i.e., message broker), delivering messages either in real time or batch. The proposed solution must account for possibly taking the data from a stakeholder application and formatting it into HL7 messages.

Active (or “front-end) Integration: This mode is typically used when integrating the EMPI search components with the existing stakeholder ADT systems. There are basically two implementation options available. The 1st available option (non-invasive) involves integrating the EMPI and stakeholder system presentation services through the use of a scripting or screen scraping technology. The 2nd available option (invasive) involves modifying the stakeholder system to access the EMPI through HL7 query response messaging or published API’s.

Active vs Passive Integration

Passive and Active Mode

Passive mode implementation involves the setup of real-time ADT (admissions, discharge and transfer) transactions from a registration system through an interface engine to an EMPI. We use the HBOC STAR registration system for our five hospitals and clinics.

In Feb. 1999, passive mode gave us a database of patients across all enterprise systems updated in real-time with a unique enterprise identifier assigned to each individual. This allowed us to have real-time reports of potential duplicates, improving data quality and patient identification. The EMPI database now houses close to 1 million records and handles 1,500 ADT transactions a day.

Active integration involves connecting the EMPI with all systems. "Active front-end integration is the most difficult and time consuming part of any EMPI implementation," says Mike Epplen, vice president of product management, Healthcare.com. "True front-end integration allows an EMPI to act as an enabler of other enterprise systems and creates a standardized way for collecting, transferring and reporting information."

Through active integration with Saint Alphonsus' registration and practice management systems, the EMPI searches its enterprise-wide database. Patients are identified in real time at registration and users receive the most up-to-date demographic information. The data is automatically pulled into Saint Alphonsus' registration system, reducing the creation of duplicate records and the need to rekey information.


From http://findarticles.com/p/articles/mi_m0DUD/is_4_22/ai_73232319