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

RCMR issues

From HL7Wiki
Revision as of 15:12, 12 January 2009 by Porrasmaa (talk | contribs)
Jump to navigation Jump to search

This page documents open issues related to the RCMR (v3) domain.

  • Fix Receiver Responsibilities van request msgs, Rene spronk and Juha Mykkänen / HL7 Finland
    • all requests should have had application acknowledgements, for requests can be accepted or refused. This looks like a serious omission in this domain.
  • Fix CACT wrapper on document query responses (it is the wrong one), Rene spronk and HL7 Finland
    • In the response interactions, they are using the wrong ControlAct wrapper - it should be a registry wrapper. Currently it is Query Control Act Response / Acknowledgement QUQI_MT120001UV01 this should be Master File / Registry Query Response Control Act (MFMI_RM700710UV01) - although I know they did this on purpose, for (to me) misguided reasons.
    • The registry response wrapper has similar metadata to the medical records payload (custodian, author, replacements). What is the additional value of using the registry wrapper? (Jari Porrasmaa)
    • In the Data Consent interactions, the ControlAct wrapper should be the registry wrapper Master File / Reg Registration Request Control Act, Act subject (MFMI_MT700722UV01) for at least these Request interactions:
    • In the Composite Privacy Consent topic (draft for comment) the Data Consent topic interactions are continued, and query/response interactions were added with the same type of issues. Unfortunately one may only view these in a PDF
  • create new doc query with less parameters, Rene spronk and HL7 Finland
    • what parameters would you keep, and what would you omit? Tony Julian
    • the query is too rich in detail which makes it too hard to implement for applications. A new query (next to current one) would only include those parameters with known usage, the parameters commonly used in queries (as identified in proposal 910, discussed by the Medical Records TC in 2004):
      • PatientId: Identifies the recordTarget for which documents are requested.
      • DocumentType: The document type (a code taken from the DocumentType vocabulary domain) of the requested document should be one of the codes specified by this parameter value. This parameter identifies what type of documents should be included in the response.
      • EffectiveTime: The effective time of the requested documents should fall within the time interval specified by this parameter value.
      • AuthorId: The Author of the requested documents should equal one of the authors identified by this parameter value.
      • CustodianOrganization: Identifies the custodian organization of the requested documents.
      • DocumentId: The ID of the requested document. If this parameter is used none of the other parameters needs to be valued; the ID is unique.
    • Queries are hard to implement with so many parameters, but is the standard the right place to limit what kind of queries you can create. I think this should be done in an implementation guide or a profile. Profile also has to specify which attributes are required and which optional in each query. (Jari Porrasmaa)
    • Also additional parameters shoudl be considered: (Jari Porrasmaa)
      • setId (get full document version history)
      • relatedDocument.setId (get appends and transforms)
      • intendedRecipient (support solutions where document delivery is done by polling a centralized service)