This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

InM fhir messaging

From HL7Wiki
Revision as of 17:17, 18 September 2017 by Lmckenzi (talk | contribs) (→‎Introduced in Sept.2017 San Diego)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Topics for FHIR

Introduced in Sept.2017 San Diego

GF#13848 Change messageheader.event data type from code to URI

  • This allows the sender to link to the formal event definition
    • Lloyd: This seems way too heavy. It prevents just pointing to a code - with its accompanying standard display or any definition. It's far from intuitive for someone familiar with v2 or v3 messaging to have any clue how to fill out EventDefinition.
    • Tony: The alternative is to
      1. force each of the resources to declare events. So far the committees have been recalcitrant to do so.
      2. Add events that the v2 folks would recognize
    • We only need to define events at the international level where there's interest in the community to do that. Work Groups shouldn't define events until/unless someone asks them to. A great deal of messaging to date has been in "closed" communities where they're happy to define their own events.

GF#13849 change event element in messagedefinition to URI, and make optional.

  • This allows the sender to link to the formal event definition
    • Lloyd: I don't understand how a message definition could ever not identify an event.
    • Tony: I will defer to Grahame - it was his thought to make this optional.

GF#13850 add messagedefinition element to messageheader

This allows the message to contain a link to the appropriate definition.

GF#13851 align messageheader.extension-messageheader-response-request with MessageDefinition.responserequired

  • messageheader.messageheader.extension-messageheader-response-request has the following codes
CodeIdSystemParentDisplayDefinition
alwaysAlwaysinitiator expects a response for this message
on-errorError/reject conditions onlyinitiator expects a response only if in error
neverNeverinitiator does not expect a response
on-successSuccessful completion onlyinitiator expects a response only if successful
  • messageDefinition.responserequired
    • Boolean
  • MessageDefinition.response-code has the following codes
CodeIdSystemParentDisplayDefinition
ok1OKThe message was accepted and processed without error.
transient-error2Transient ErrorSome internal unexpected error occurred - wait and try again. Note - this is usually used for things like database unavailable, which may be expected to resolve, though human intervention may be required.
fatal-error3Fatal ErrorThe message was rejected because of some content in it. There is no point in re-sending without change. The response narrative SHALL describe the issue.

GF#13852 Change messagedefinition maturity level to 1, and ballot status to STU

GF#13853 Change Maturity level on Messageheader to FMM4